diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/deployment.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/deployment.mdx
deleted file mode 100644
index 40cf2408cf3..00000000000
--- a/advocacy_docs/edb-postgres-ai/cloud-service/deployment.mdx
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: Deployment Options on EDB Postgres AI Cloud Service
-navTitle: Deployment Options
-description: EDB Postgres AI Cloud Service offers a variety of deployment options for EDB Postgres databases for high availability and fault tolerance.
-deepToC: true
----
-
-
-## Availability options
-
-### Single instance
-
-Single instance databases are great for development and testing, but for
-production workloads, you need to consider high availability and fault
-tolerance.
-
-### Primary/secondary replication
-
-Primary/secondary replication is a common high-availability solution for
-databases. In this configuration, a primary database server is responsible for
-processing read and write requests. A secondary database server is setup to
-replicate the primary database server. If the primary database server fails, the
-secondary database server can take over and become the primary database server.
-
-This configuration provides fault tolerance and high-availability in a
-particular location. This is available with EDB Postgres® Advanced Server (EPAS)
-and EDB Postgres Extended Server (PGE).
-
-
-### Distributed high availability
-
-High availability is a critical requirement for mission-critical workloads. EDB
-Postgres Distributed (PGD) provides a distributed database environment designed
-to ensure high availability and fault tolerance for mission-critical workloads.
-PGD can use EPAS, PGE, or PostgreSQL databases as the underlying replicated
-database. PGD is available for self-managed deployment and on the EDB Postgres
-AI Cloud Service (as the Distributed High Availability option).
-
-
-
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/backup_and_restore.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/backup_and_restore.mdx
new file mode 100644
index 00000000000..6f8d9701ad7
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/backup_and_restore.mdx
@@ -0,0 +1,155 @@
+---
+title: "Example - Back up and restore a cluster"
+navTitle: "Example - Backup and restore"
+description: Understand how to do backups and perform restore using those backups.
+indexCards: none
+---
+
+Cloud Service [automatically and continuously](/edb-postgres-ai/cloud-service/managing_your_cluster/backup_and_restore/) saves backups of your clusters. You can restore your cluster to any point in the past after the initial backup on cluster creation. That functionality is included in the free trial as well. While that means you don't have to do anything to generate backups, it's always sensible to test your backups.
+
+If you haven't already, [create a cluster](/edb-postgres-ai/cloud-service/using_cluster/cli/create_cluster_cli/) on EDB Postgres AI Console.
+
+We're going to [add a database](/edb-postgres-ai/cloud-service/using_cluster/postgres_access/database_authentication/#one-database-with-one-application) called "baseball," which we'll populate with some Major League Baseball statistics.
+
+```sql
+create database baseball;
+```
+
+Now you can switch to your new (and empty) baseball database. You're prompted for the `edb_admin` password you provided when connecting to the cluster.
+
+```sql
+\c baseball
+```
+
+Normally you use the log files to determine the moment in time that you want to restore. For the purposes of this demonstration, let's change the prompt to include a timestamp to have an accurate timing of our activities. For convenience, we'll use the (almost) ISO-8601 format that the restore command accepts.
+
+```sql
+\set PROMPT1 '%`date +"%Y-%m-%dT%H:%M:%S%z"` %/%R%# '
+```
+
+For this demonstration, we're just going to import batter data from the [Baseball Databank](https://github.com/cbwinslow/baseballdatabank), which is in CSV form. While it's easy to import the data using [PostgreSQL's COPY command](https://www.postgresql.org/docs/current/sql-copy.html), we'll need to first define a table to put that data into. Most of the columns are integers, but there are a few strings to consider as well. You can copy and paste this command into your terminal.
+
+```sql
+CREATE TABLE batters (
+ id SERIAL,
+ playerid VARCHAR(9),
+ yearid INTEGER,
+ stint INTEGER,
+ teamid VARCHAR(3),
+ lgid VARCHAR(2),
+ g INTEGER,
+ ab INTEGER,
+ r INTEGER,
+ h INTEGER,
+ "2b" INTEGER,
+ "3b" INTEGER,
+ hr INTEGER,
+ rbi INTEGER,
+ sb INTEGER,
+ cs INTEGER,
+ bb INTEGER,
+ so INTEGER,
+ ibb INTEGER,
+ hbp INTEGER,
+ sh INTEGER,
+ sf INTEGER,
+ gidp INTEGER,
+ PRIMARY KEY (id)
+);
+```
+
+Now we can populate the table from the internet using the most recent data.
+
+```sql
+\COPY batters(playerid,yearid,stint,teamid,lgid,g,ab,r,h,"2b","3b",hr,rbi,sb,cs,bb,so,ibb,hbp,sh,sf,gidp) FROM PROGRAM 'curl "https://raw.githubusercontent.com/EnterpriseDB/docs/main/product_docs/docs/biganimal/release/free_trial/detail/experiment/data/Batting.csv"' DELIMITER ',' CSV HEADER
+```
+
+Just to prove there's data loaded, let's look at the home run leaders for the 1998 season.
+
+```sql
+SELECT playerid, yearid, teamid,
+ rank() OVER (PARTITION BY yearid ORDER BY hr desc) hr_rank,
+ hr
+FROM batters
+WHERE yearid = 1998
+ORDER BY hr_rank LIMIT 5;
+```
+
+Suppose someone wanted to revise history a bit.
+
+```sql
+UPDATE batters
+SET hr=0
+where playerid = 'mcgwima01' AND yearid = 1998;
+```
+
+Note the time so we can restore that data later. Verify the data has been changed by rerunning the 1998 home run leader query. Now go ahead and drop the whole table.
+
+```sql
+DROP TABLE batters;
+```
+
+You can verify the table is gone by looking at the list of tables.
+
+```sql
+\dt
+```
+
+Restore the cluster using the timestamp before the time you dropped the table.
+
+```shell
+biganimal cluster restore --id p-xxxxxxxxxxx --from-deleted --restore-point 2022-03-31T02:39:40+0000
+__OUTPUT__
+✔ New Name for Restored Cluster, Leave empty to continue with source cluster data: █
+Restored Cluster Password: *************
+Region: US East 1
+Instance Type: r5.large(2vCPU, 16GB RAM)
+Volume Type: General Purpose SSD (GP3)
+Volume Properties: gp3 (1 Gi - 16384 Gi, 3000 IOPS, 125 MiB/s tput)
+✔ Specify database configuration, for example "application_name=sample_app&array_nulls=true". Leave empty to continue with source cluster data: █
+High Availability: Keep Existing
+Networking: Keep Existing
+Add IP Range to allow network traffic to your cluster from the public Internet: Keep Existing
+Are you sure you want to Restore Cluster ? [y|n]: y
+Restore Cluster operation is started
+Cluster ID is "p-yyyyyyyyyy"
+To check current state, run: biganimal show-clusters --id p-yyyyyyyyyy
+```
+
+!!! Note Optional arguments for the CLI
+
+ We're only providing the information we have handy to the restore command: the ID of the cluster, the fact that
+ the cluster is deleted, and the timestamp for the restore point. The CLI will prompt for additional information,
+ such as the password or the region to restore to, and allow you to enter or select from a list as appropriate.
+
+ If you know ahead of time the options you'll need, you can provide all of them using parameters, and the command
+ will run non-interactively. The values for the other parameters you don't specify will be inherited from the source cluster.
+
+Check the status of the new cluster from the command line.
+
+```shell
+biganimal cluster show
+```
+
+Once provisioning is complete, you'll want to grab the new connection information. The hostname changed!
+
+```shell
+biganimal cluster show-connection --id p-yyyyyyyyyy
+```
+
+Log in to the new cluster. Be sure to use the new hostname, and use the edb_admin password you provided when restoring the cluster.
+
+Verify that the batters table was restored:
+
+```sql
+select playerid, yearid, teamid,
+ rank() OVER (PARTITION BY yearid ORDER BY hr desc) hr_rank,
+ hr
+from batters
+where yearid = 1998
+order by hr_rank limit 5;
+```
+
+## Further reading
+
+[Cloud Service CLI reference](/edb-postgres-ai/cloud-service/using_cluster/cli/) and [Backing up and restoring](/edb-postgres-ai/cloud-service/managing_your_cluster/backup_and_restore/) in the full version documentation.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster.mdx
new file mode 100644
index 00000000000..087a247367c
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster.mdx
@@ -0,0 +1,349 @@
+---
+title: "Creating a cluster"
+description: Describes cluster creation options for single node and high availability deployments
+deepToC: true
+redirects:
+ #adding hierarchy to the structure (Creating a Cluster topic nows has a child topic) so created a folder and moved the contents from 03_create_cluster to index.mdx
+ - ../03_create_cluster/
+ - /biganimal/latest/getting_started/creating_a_cluster/
+---
+
+!!!Note "When using Your Cloud"
+
+Before creating your cluster, make sure you have enough resources. Without enough resources, your request to create a cluster fails.
+
+- If your cloud provider is Azure, see [Preparing your Azure account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/).
+- If your cloud provider is AWS, see [Preparing your AWS account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_aws/).
+- If your cloud provider is Google Cloud, see [Preparing your Google Cloud account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/).
+- Activate a region before cluster creation. See [Activating regions](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/managing_regions/).
+!!!
+
+!!!note "When using EDB Hosted Cloud"
+
+The following options aren't available when creating your cluster:
+
+- AWS IAM authentication
+- Superuser access
+- PgBouncer
+!!!
+
+1. Sign in to the [EDB Postgres AI Console](https://portal.biganimal.com).
+
+2. On the **Overview** or **Clusters** page, select **Create New** > **Database cluster**.
+
+3. On the **Create Cluster** page, specify the cluster settings on the following tabs:
+ - [**Cluster Info**](#cluster-info-tab)
+ - [**Cluster Settings**](#cluster-settings-tab)
+ - [**DB Configuration** ](#db-configuration-tab) (optional)
+ - [**Additional Settings**](#additional-settings-tab) (optional)
+
+4. Select **Create Cluster**. It might take a few minutes to deploy.
+
+!!! Note
+
+ When you don't configure settings on optional tabs, the default values are used.
+
+## Cluster Info tab
+
+1. Select the type of cluster to deploy.
+
+ - [Single Node](/edb-postgres-ai/cloud-service/references/supported_cluster_types/single_node/) creates a cluster with one primary and no standby replicas. Suited for test environments where high availability might not be required. You can create single-node clusters running PostgreSQL, EDB Postgres Extended Server or EDB Postgres Advanced Server.
+
+ - [Primary/Standby High Availability](/edb-postgres-ai/cloud-service/references/supported_cluster_types/primary_standby_highavailability/) creates a cluster with one primary and one or two standby replicas in different availability zones. You can create primary/standby high-availability clusters running PostgreSQL, EDB Postgres Extended Server or EDB Postgres Advanced Server. If you enable read-only workloads, then you might have to raise the IP address resource limits for the cluster.
+
+ - [Distributed High Availability](/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability/) creates a cluster, powered by EDB Postgres Distributed, with up to two data groups spread across multiple cloud regions to deliver higher performance and faster recovery. You can create distributed high-availability clusters running PostgreSQL, EDB Postgres Extended Server, or EDB Postgres Advanced Server. See [Creating a distributed high-availability cluster](creating_a_dha_cluster) for instructions.
+
+ See [Supported cluster types](/edb-postgres-ai/cloud-service/references/supported_cluster_types/) for more information about the different cluster types.
+
+ !!!Note
+
+ You can't switch from a single-node or primary/standby high-availability cluster to a distributed high-availability cluster or vice versa.
+
+2. Select the number of standby replicas for your primary/standby high-availability cluster.
+
+3. Select the type of cloud account for your cluster. You can choose EDB Hosted Cloud Service or Your Cloud Account. For more information, see [Deployment options](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/).
+
+ !!! Note
+
+ If you use EDB Hosted Cloud Service, your estimated cloud infrastructure costs are calculated into your cluster's estimated monthly price shown at the bottom of the page.
+
+4. Select the cloud provider and region for your cluster. If you're using your account and haven't connected it to EDB Postgres AI Console yet, see [Connecting to your cloud](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/).
+
+ !!! Tip
+
+ For the best performance, we strongly recommend that this region be the same as your other resources that communicate with your cluster. For a list of available regions, see [Supported regions](/edb-postgres-ai/cloud-service/references/supported_regions/). If you're interested in deploying a cluster to a region that isn't currently available, contact [Support](/edb-postgres-ai/cloud-service/support_services/).
+
+5. Select **Next: Cluster Settings** to continue to specify the required settings for your cluster.
+
+## Cluster Settings tab
+
+1. In the **Cluster Name** field, enter the name for your cluster.
+
+2. In the **Password** field, enter a password for your cluster. This is the password for the user edb_admin.
+
+3. Under **Tags**, select **+**.
+
+4. To assign an existing tag, in the search bar under **Tags**, enter a tag name. To add a new tag, instead select **+ Add Tag**.
+
+5. In the **Database Type** section:
+
+ 1. In the **Postgres Type** field, select the type of Postgres you want to use:
+
+ - **[EDB Postgres Advanced Server](/epas/latest/)** is EDB's Oracle-compatible database offering. View [a quick demonstration of Oracle compatibility on EDB Postgres AI](/edb-postgres-ai/cloud-service/using_cluster/demonstration_oracle_compatibility/). EDB Postgres Advanced Server is compatible with all three cluster types.
+
+ - **[EDB Postgres Extended Server](/pge/latest/)** is EDB's PostgreSQL-compatible database offering that uses advanced logical replication.
+
+ - **[PostgreSQL](/supported-open-source/postgresql/)** is the open-source, object-relational database management system. PostgreSQL is compatible with single-node and primary/standby high-availability cluster types.
+
+ 2. In the **Postgres Version** list, select the version of Postgres that you want to use. See [Database version policy](/edb-postgres-ai/cloud-service/references/supported_database_versions/) for more information.
+
+6. In the **Instance Type** section:
+
+ 1. Select the category that works best for your applications and workload:
+
+ - Memory optimized for large data sets
+
+ - Compute optimized for compute bound applications
+
+ - General purpose if you don't require memory or compute optimization
+ 2. Select the instance series and size. See [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes), [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/), or the [Google Cloud Machine families resource and comparison guide](https://cloud.google.com/compute/docs/machine-resource) for information to help you choose the appropriate instance type.
+
+ !!!note
+
+ When provisioning a cluster, some CPU and memory resources are reserved for use by EDB Postgres AI and your cloud provider. For example, when using Kubernetes, provisioning a server with 8GB of memory yields only about 6GB of memory after accounting for the requirements of Kubernetes and EDB Postgres AI.
+
+ !!!tip
+
+ To maximize your disk size for AWS, select R5b as your instance and then io2 Block Express as your storage to get a maximum disk size of 64 TB and 256,000 IOPS.
+
+7. In the **Storage** section:
+
+ By default, the **Database Storage** volume stores the Postgres data and the write-ahead logs (WAL) together. If you want to improve write performance for WAL files, you can allocate separate storage volume for the WAL files. To allocate separate storage volume for WAL files, select **Use a separate storage volume for Write-Ahead Logs**. Then select the volume type, size, IOPS, and disk throughput separately for **Database Storage** and **Write-Ahead Logs Storage**. If you allocate separate storage volume for the WAL files, you have to pay cloud infrastructure costs for the second volume. Once separate storage volume is allocated for WAL files, you can't remove it from the cluster settings later on.
+
+ From the **Volume Type** list, select your volume type.
+
+ Azure
+
+ For Azure, in **Volume Type**, select **Premium SSD** or **Ultra Disk**. Compared to Premium SSD volumes, ultra disks offer lower-latency, high-performance options and direct control over your disk's input/output operations per second (IOPS). For EDB Postgres AI, we recommend using ultra disks for workloads that require the most demanding performance. See [Using Azure ultra disks](https://docs.microsoft.com/en-us/azure/virtual-machines/disks-enable-ultra-ssd?tabs=azure-portal) for more information.
+
+ - For Premium SSD, in **Volume Properties**, select the type and amount of storage needed for your cluster. See [Azure Premium SSD storage types](https://docs.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssds) for more information.
+
+ - For ultra disk, in **Volume Properties**, select the disk size and IOPS for your cluster. EDB Postgres AI calculates disk throughput based on your IOPS settings, but you have the option of updating the value.
+
+ !!!important
+
+ While setting the required IOPS for the disk that you selected, consider the VM limits that are tied to the VM size that you selected. See [Ultra disk IOPS](https://docs.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disk-iops) for more information.
+
+ AWS
+
+ For AWS, in **Volume Type**, select **General Purpose SSD (GP3)**, **io2**, or **io2 Block Express**.
+
+ !!!Note
+
+ io2 Block Express is available for selected instance types, such as R5b. However, you can't switch between io2 and io2 Block Express after creating your cluster.
+
+ In **Volume Properties**, select the disk size for your cluster, and configure the IOPS.
+
+ GCP
+
+ For Google Cloud, in **Volume Type**, select **SSD Persistent Disk**.
+
+ In **Volume Properties**, select the disk size for your cluster.
+
+ AWS
+
+ 1. Copy the **Principal** identifier to your clipboard.
+ 2. Go to the AWS console, and navigate to the **Key Management Service**.
+ 3. Select **Customer-managed keys**, and **Edit policy** for your key.
+ 4. Append a new policy statement where the `Principal.AWS` field contains the **Principal** identifier you copied earlier and the `Principal.Action` field contains **kms:Encrypt** and **kms:Decrypt** permissions.
+
+ This example contains the default AWS policy statement and the BigAnimal policy statement that corresponds to the TDE configuration:
+
+ ```
+ {
+ "Version": "2012-10-17",
+ "Id": "key-consolepolicy-3",
+ "Statement": [
+ {
+ "Sid": "Enable IAM User Permissions",
+ "Effect": "Allow",
+ "Principal": {
+ "AWS": "arn:aws:iam:::root"
+ },
+ "Action": "kms:*",
+ "Resource": "*"
+ },
+ {
+ "Sid": "Enable TDE on cluster ExampleCluster",
+ "Effect": "Allow",
+ "Principal": {
+ "AWS": "arn:aws:iam:::role/"
+ },
+ "Action": [
+ "kms:Encrypt",
+ "kms:Decrypt"
+ ],
+ "Resource": "*"
+ }
+ ]
+ }
+ ```
+
+ GCP
+
+ 1. Copy the **service account** to your clipboard.
+ 2. On the Google Cloud console, select **Security**, **VIEW BY PRINCIPALS**, and **GRANT ACCESS** for your key.
+ 3. Paste the service account into the **New principals** field.
+ 4. Assign the `Cloud KMS CryptoKey Decrypter` and `Cloud KMS CryptoKey Encrypter` roles and save.
+
+ Azure
+
+ 1. Copy the **MSI Workload Identity** to your clipboard.
+ 2. On the Microsoft Azure console, navigate to **Key vaults**.
+ 3. Select the key. Go to **Access configuration** and set the **Permission model** to **Vault access policy**.
+ 4. Select **Access policies**.
+ 5. Select **Create**.
+ 6. In **Permissions**, select **Encrypt** and **Decrypt**.
+ 7. In **Principal**, paste the MSI Workload Identity you copied earlier and finish creating the policy.
+
+ Azure
+
+ For Azure, in **Volume Type**, select **Premium SSD** or **Ultra Disk**. Compared to Premium SSD volumes, ultra disks offer lower-latency, high-performance options and direct control over your disk's input/output operations per second (IOPS). For EDB Postgres AI, we recommend using ultra disks for workloads that require the most demanding performance. See [Using Azure ultra disks](https://docs.microsoft.com/en-us/azure/virtual-machines/disks-enable-ultra-ssd?tabs=azure-portal) for more information.
+
+ - For Premium SSD, in **Volume Properties**, select the type and amount of storage needed for your cluster. See [Azure Premium SSD storage types](https://docs.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssds) for more information.
+
+ - For ultra disk, in **Volume Properties**, select the disk size and IOPS for your cluster. EDB Postgres AI calculates disk throughput based on your IOPS settings, but you have the option of updating the value.
+
+ !!!important
+
+ While setting the required IOPS for the disk that you selected, consider the VM limits that are tied to the VM size that you selected. See [Ultra disk IOPS](https://docs.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disk-iops) for more information.
+
+ AWS
+
+ For AWS, in **Volume Type**, select **General Purpose SSD (GP3)**, **io2**, or **io2 Block Express**.
+
+ !!!Note
+
+ io2 Block Express is available for selected instance types, such as R5b. However, you can't switch between io2 and io2 Block Express after creating your cluster.
+
+ In **Volume Properties**, select the disk size for your cluster, and configure the IOPS.
+
+ GCP
+
+ For Google Cloud, in **Volume Type**, select **SSD Persistent Disk**.
+
+ In **Volume Properties**, select the disk size for your cluster.
+
+ Single instance
+Single instance databases are great for development and testing, but for
+production workloads, you need to consider high availability and fault
+tolerance.
+Primary/secondary replication
+Primary/secondary replication is a common high-availability solution for
+databases. In this configuration, a primary database server is responsible for
+processing read and write requests. A secondary database server is setup to
+replicate the primary database server. If the primary database server fails, the
+secondary database server can take over and become the primary database server.
+
+This configuration provides fault tolerance and high-availability in a
+particular location. This is available with EDB Postgres® Advanced Server (EPAS)
+and EDB Postgres Extended Server (PGE).
+
+Distributed high availability
+High availability is a critical requirement for mission-critical workloads. EDB
+Postgres Distributed (PGD) provides a distributed database environment designed
+to ensure high availability and fault tolerance for mission-critical workloads.
+PGD can use EPAS, PGE, or PostgreSQL databases as the underlying replicated
+database. PGD is available for self-managed deployment and on the EDB Postgres
+AI Cloud Service (as the Distributed High Availability option).
+
+
+
+You can deploy EDB's Postgres Advanced Server (EPAS) or Postgres Extended Server (PGE) databases as hosted databases, with a range of [deployment options](../choosing_cluster_type/) for high availability and fault tolerance.
+
+## Deploying a cluster with EDB Hosted Cloud Service
+
+To deploy clusters using EDB Hosted Cloud Service:
+
+- Choose what [Postgres distribution](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_postgres_distro/) available on the Cloud Service best meets your needs.
+
+- Select appropriate regions from the [EDB Hosted Cloud Service regions](<>) to place your cloud resources closest to your users.
+
+- Evaluate how EDB Postgres AI charges you for [cloud infrastructure costs](/biganimal/latest/pricing_and_billing/#biganimals-cloud-account).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/index.mdx
new file mode 100644
index 00000000000..51dc2c0c0db
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/index.mdx
@@ -0,0 +1,17 @@
+---
+navTitle: Choosing deployment
+title: Choosing your deployment option
+description: Choose to use either EDB Hosted Cloud Service or Your Cloud Account.
+indexCards: simple
+redirects:
+ - /biganimal/release/overview/deployment_options/
+navigation:
+- deploying_edb_hosted
+- deploying_using_your_cloud_account
+---
+
+You have two deployment options with EDB Postgres AI®. You can deploy clusters using EDB Hosted Cloud Service, or you can deploy using Your Cloud Account.
+
+To learn about the pricing of these two deployment options, see [Pricing and billing](/biganimal/latest/pricing_and_billing/).
+
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/your_cloud_account.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/your_cloud_account.mdx
new file mode 100644
index 00000000000..24937494b5a
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/your_cloud_account.mdx
@@ -0,0 +1,24 @@
+---
+navTitle: Your Cloud Account
+title: Choosing Your Cloud Account
+description: "EDB Postgres AI Cloud Service is able to manage an EDB Postgres database in your cloud."
+---
+
+To deploy database clusters with Your Cloud Account:
+
+- Understand what it means to use [Your Cloud Account](#your-cloud-account).
+- Understand the requirements of [deploying a cluster with Your Cloud Account](#deploying-a-cluster-with-your-cloud-account).
+
+## Your Cloud Account
+
+For many organizations, managing databases can be a complex and time-consuming task. The Managed option of the EDB Postgres AI Cloud Service provides a fully managed database service that allows you to focus on your applications and data, while EDB manages the database infrastructure. All you need to provide is the cloud account for EDB to deploy into.
+
+
+
+
+The advantage of the Managed option is that the database can deploy directly into your cloud infrastructure, so you have full control over the cloud account and the data. EDB manages the database infrastructure, including backups, monitoring, and updates, and provides a single pane of glass for managing your databases, monitoring performance, and accessing logs and metrics.
+
+## Deploying a cluster with Your Cloud Account
+
+When deploying in your cloud account, you need to set up your cloud service provider. You can use your AWS, Azure, or Google Cloud account. In this deployment model, you are responsible for managing your cloud resources and connecting your cloud to EDB Postgres AI Cloud Service. To set up your cloud service provider, see [Checking your cloud readiness](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/index.mdx
new file mode 100644
index 00000000000..4634002f52c
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/planning/index.mdx
@@ -0,0 +1,9 @@
+---
+title: Planning
+indexCards: simple
+description: To manage your databases, plan and choose your deployment, cluster type and EDB Postgres database.
+navigation:
+- choosing_your_deployment
+- choosing_cluster_type
+- choosing_postgres_distro
+---
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/cluster_networking.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/cluster_networking.mdx
new file mode 100644
index 00000000000..34e2d9ba0fc
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/cluster_networking.mdx
@@ -0,0 +1,55 @@
+---
+title: Cluster networking architecture
+description: Understand the EDB Postgres AI's clusters networking architecture.
+---
+
+BigAnimal clusters can be exposed to client applications in two ways:
+
+- Public — The cluster is available on the internet.
+- Private — The IP address or DNS name is private to the VNet or VPC hosting your BigAnimal services. By default, it isn't routable from other networks. See [Connecting to your cluster from your application](/edb-postgres-ai/cloud-service/using_cluster/connecting_your_cluster/#from-your-applications) for details and instructions on how to properly configure routing for private clusters.
+
+## Basic architecture
+
+BigAnimal deploys a dedicated virtual network (VNet) in Azure, an Amazon Virtual Private Cloud (VPC) in AWS, or a Google VPC in Google Cloud to host clusters and their supporting management services. This VNet or VPC is named after the region where the cluster is deployed. In Azure, for example, if the cluster is deployed in the East US region, the name is `vnet-eastus`.
+
+## Load balancing
+
+BigAnimal uses the following resources for making routing decisions and distributing requests:
+
+### Standard SKU load balancer in Azure
+
+When a cluster is created with public network access, a load balancer is created and configured with a public IP address. Once assigned, this IP address doesn't change unless you change the networking configuration for your cluster. The load balancer always routes to the leader of your cluster.
+
+Only one load balancer is typically deployed in an Azure region. BigAnimal adds more IP addresses to the existing load balancer for subsequent clusters in the Azure region.
+
+Every BigAnimal cluster, regardless of public or private networking status, is assigned a single DNS zone that maps to its exposed IP address, either public or private. When toggling between public and private, wait up to 120 seconds for DNS caches to flush.
+
+Clusters can change from public to private and vice versa at any time. When this happens, the IP address previously assigned to the cluster is deallocated, a new one is assigned, and DNS is updated accordingly.
+
+### Amazon network load balancer in AWS
+
+BigAnimal creates a new load balancer for each cluster and tags it with the cluster ID in the following format:
+
+```text
+service.k8s.aws/stack: default/
+```
+
+An example is `service.k8s.aws/stack: default/p-c4j0jfcmp3af2ieok5eg`.
+
+Because the load balancer IP address used in AWS is dynamic, make sure that your application uses the correct DNS name to access the network load balancer of a particular cluster. In your application's AWS account:
+
+1. Select the **Load Balancers** service.
+2. Search for the load balancer with the cluster ID you want to access.
+3. Use the DNS name provided in the details section to access your cluster.
+
+### Google load balancer in Google Cloud
+
+BigAnimal creates a new load balancer using the Premium Network Service Tier for each cluster and tags it using a unique identifier. The corresponding front-end forwarding rule uses the same unique identifier and includes the cluster ID in the following format:
+
+```
+{"kubernetes.io/service-name":"default/-"}
+```
+
+An example is `{"kubernetes.io/service-name":"default/p-8jz4kedbiy-rw-external-lb"}`.
+
+Because the load balancer IP address used in Google Cloud is dynamic, make sure that your application uses the correct DNS name to access the network load balancer of a particular cluster. To be able to access it, make sure you're using the FQDN that BigAnimal provides in the Cluster Overview or Connect page.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_aws.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_aws.mdx
new file mode 100644
index 00000000000..054caddfcf6
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_aws.mdx
@@ -0,0 +1,56 @@
+---
+title: Connecting your AWS cloud
+navTitle: AWS
+---
+
+## Prerequisites
+
+Before connecting your cloud, make sure that you're assigned the following AWS managed policies or an equivalent custom policy granting full access to resources:
+
+- arn:aws:iam::aws:policy/IAMFullAccess
+
+- arn:aws:iam::aws:policy/ServiceQuotasFullAccess
+
+!!! note
+
+ Cloud Service is deployed in a VPC in your cloud service provider (CSP). To make changes or modify your Cloud Service clusters, use the EDB Postgres AI Console, API, or CLI to manage and execute the activity. You can also open a Support case if you need help. Making changes in the resources in those dedicated VPCs can affect EDB's ability to deliver service.
+
+## Connecting your cloud
+
+!!! tip
+
+ If you're using CloudShell, add the `./` prefix to the `biganimal` command (`./biganimal`).
+
+To connect your cloud:
+
+1. Open AWS CloudShell in your browser.
+
+2. Create a BigAnimal CLI credential:
+
+ ```shell
+ biganimal credential create --name
+ ```
+
+3. To set up your cloud provider, run the `setup-csp` command:
+
+ ```shell
+ biganimal cloud-provider setup
+ ```
+
+ The command checks for cloud account readiness and displays the results.
+
+4. If the following readiness checks aren't met for your cloud service provider, see [Configure your AWS account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_aws/#configure-your-aws-account) to manually configure your cloud:
+
+ - Is the AWS CLI configured to access your AWS account?
+
+ - Is the limit on the number of vCPUs and network load balancers (NLBs) in your region enough for your clusters?
+
+ If the cloud readiness checks pass, your cloud account is successfully set up.
+
+5. Connect your cloud account to BigAnimal:
+
+ ```shell
+ biganimal cloud-provider connect --provider aws --project
+ ```
+
+ After your cloud account is successfully connected to BigAnimal, you and other users with the correct permissions can create clusters.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_azure.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_azure.mdx
new file mode 100644
index 00000000000..9d8990c686c
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_azure.mdx
@@ -0,0 +1,62 @@
+---
+title: Connecting your Azure cloud
+navTitle: Azure
+---
+
+!!! note
+
+ The Cloud Service CLI commands used for connecting your cloud to Cloud Service register an application with Azure AD and create a service principal to delegate identity and access management functions to Azure Active Directory (AD). For more information, see for [Azure EDB cloud utilities](https://github.com/EnterpriseDB/cloud-utilities/tree/main/azure) in GitHub.
+
+!!! note
+
+ Cloud Service is deployed in a dedicated VNET in your cloud service provider (CSP). To make changes or modify your Cloud Service clusters, use the EDB Postgres AI Console, API, or CLI to manage and execute the activity. You can also open a Support case if you need help. Making changes to the resources in those dedicated VPCs can affect EDB's ability to deliver service.
+
+## Prerequisites
+
+Before connecting to your cloud, make sure that you're assigned either the Global Administrator role or the Privileged Role Administrator role in Azure AD and that you have the Owner role for your Cloud Service Azure subscription.
+
+## Connecting your cloud
+
+!!! tip
+
+ If you're using Cloud Shell, add the `./` prefix to the `biganimal` command (`./biganimal`).
+
+To connect your cloud:
+
+1. Open the [Azure Cloud Shell](https://shell.azure.com/) in your browser.
+
+2. Create a Cloud Service CLI credential:
+
+ ```shell
+ biganimal credential create --name
+ ```
+
+3. To set up your cloud provider, run the `cloud-provider setup` command:
+
+ ```shell
+ biganimal cloud-provider setup
+ ```
+
+ The command checks for cloud account readiness and displays the results.
+
+4. If the following readiness checks aren't met, see [Configure your Azure subscription](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/#configure-your-azure-subscription) to manually configure your cloud:
+
+ - Are the necessary Azure resource providers registered for your subscription?
+
+ - Is there a restriction on SKUs for the standard Esv3 family and standard D2_v4 VM size?
+
+ - Is the limit on the number of vCPU and public IP addresses in your region enough for your clusters?
+
+ If the cloud readiness checks pass, your cloud account is successfully set up.
+
+ !!! Note
+
+ At this point, you can't change the Azure subscription, as you have already provided the Azure subscription ID.
+
+5. Connect your cloud account to Cloud Service:
+
+ ```shell
+ biganimal cloud-provider connect --provider azure --project
+ ```
+
+After your cloud account is successfully connected to Cloud Service, you, and other users with the correct permissions can create clusters.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_gcp.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_gcp.mdx
new file mode 100644
index 00000000000..9ddc1ba3ec3
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_gcp.mdx
@@ -0,0 +1,63 @@
+---
+title: Connecting your Google Cloud
+navTitle: Google Cloud
+---
+
+!!! note
+
+ Cloud Service is deployed in a VPC in your cloud service provider (CSP). To make changes or modify your Cloud Service clusters, use the EDB Postgres AI Console, API, or CLI to manage and execute the activity. You can also open a Support case if you need help. Making changes in the resources in those dedicated VPCs can affect EDB's ability to deliver service.
+
+## Prerequisites
+
+Ensure you have at least the following combined roles:
+
+- roles/iam.serviceAccountCreator
+- roles/iam.serviceAccountKeyAdmin
+- roles/iam.roleAdmin
+- roles/resourcemanager.projectIamAdmin
+- roles/compute.viewer
+
+Alternatively, you can have an equivalent single role, such as:
+
+- roles/owner
+
+## Connecting your cloud
+
+!!! tip
+
+ If you're using Cloud Shell, add the `./` prefix to the `biganimal` command (`./biganimal`).
+
+To connect your cloud:
+
+1. Open Google Cloud Shell in your browser.
+
+2. Create a Cloud Service CLI credential:
+
+ ```shell
+ biganimal credential create --name
+ ```
+
+3. To set up your cloud provider, run the `setup-csp` command:
+
+ ```shell
+ biganimal cloud-provider setup
+ ```
+
+ The command checks for cloud account readiness and displays the results.
+
+4. If the following cloud readiness checks pass for your cloud service provider, your cloud account is successfully set up:
+
+ - Is the Google Cloud CLI configured to access your Google Cloud account?
+
+ - Is the limit on the number of vCPUs and network load balancers (NLBs) in your region enough for your clusters?
+
+ If the readiness checks aren't met, see [Configure your Google Cloud account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/#configure-your-google-cloud-account) to manually configure your cloud.
+
+
+5. Connect your cloud account to Cloud Service:
+
+ ```shell
+ biganimal cloud-provider connect --provider gcp --project
+ ```
+
+ After your cloud account is successfully connected to Cloud Service, you and other users with the correct permissions can create clusters.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/index.mdx
new file mode 100644
index 00000000000..55e16173651
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/index.mdx
@@ -0,0 +1,79 @@
+---
+title: Connecting your cloud
+description: How to connect your own cloud account to the Cloud Service
+redirects:
+ - ../02_connect_cloud_account/
+ - /biganimal/release/getting_started/02_connecting_to_your_cloud/01_connecting_your_own_cloud
+---
+
+Use these techniques to connect your cloud if you're using Your Cloud Account as your [deployment option](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/).
+
+## Cloud Service access requirements
+
+Cloud Service needs access to your cloud to perform maintenance. Cloud Service CLI commands used for connecting your cloud to the Cloud Service set some of these permissions for you. For details on these and other permissions or policies required by Cloud Service, refer to the corresponding topic for your cloud provider.
+
+Cloud Service also requires permissions to run Kubernetes cluster services for PostgreSQL workloads and the associated storage services. It requires a set of supporting permissions:
+
+- Services for monitoring and logging to produce service telemetry information
+
+- To set up networking so PostgreSQL workloads are reachable by customer applications and telemetry data is collected
+
+- To provision vaults for safe storage of data at rest encryption keys
+
+- To create workload identities and manage their permissions
+
+- A small set of supporting permissions to ensure access to the services above and availability of cloud account information
+
+The scope of these permissions is limited to the associated cloud account.
+
+## Prerequisites
+
+In your cloud provider shell, make sure that your environment is running:
+
+- Bash shell version 4.0 or above.
+
+- Cloud Service CLI version 2.0 or later. For details, see [Installing the CLI](/edb-postgres-ai/cloud-service/using_cluster/cli/#installing-the-cli).
+
+For additional cloud provider-specific requirements, see [Setting up specific cloud providers](#setting-up-specific-cloud-providers).
+
+## Overview of connecting your cloud
+
+!!! tip
+
+ If you're using Cloud Shell, add the `./` prefix to the `biganimal` command (`./biganimal`).
+
+1. Open your cloud provider shell in your browser.
+
+2. Create a BigAnimal CLI credential:
+
+ ```shell
+ biganimal credential create --name
+ ```
+
+3. To set up your cloud provider, run the `cloud-provider setup` command :
+
+ ```shell
+ biganimal cloud-provider setup
+ ```
+
+ !!! Important
+
+ Don't delete the `ba-passport.json` file created in your working directory. It contains important identity and access management information used by `cloud-provider connect` while connecting to your cloud.
+
+4. If the cloud readiness checks pass, your cloud account is successfully set up. Connect your cloud account to Cloud Service:
+
+ ```shell
+ biganimal cloud-provider connect --provider --project
+ ```
+
+ Once your cloud account is successfully connected to Cloud Service, you and other users with the correct permissions can create clusters.
+
+## Setting up specific cloud providers
+
+For step-by-step instructions for setting up specific cloud providers, see:
+
+- [Connecting your AWS cloud](connecting_aws)
+
+- [Connecting your Azure cloud](connecting_azure)
+
+- [Connecting your Google Cloud](connecting_gcp)
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_aws.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_aws.mdx
new file mode 100644
index 00000000000..f5d8e3ffa17
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_aws.mdx
@@ -0,0 +1,13 @@
+---
+title: Deploying with AWS
+description: Choose AWS to manage databases on EDB Postgres AI Cloud Service.
+---
+
+To use AWS as your cloud account:
+
+- Sign in for the first time with your EDB account, and then either use the EDB Postgres AI Console as your identity provider or [set up your own provider](/edb-postgres-ai/console/using/organizations/identity_provider/) afterward.
+- [Check the readiness of your AWS account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_aws/) before deploying.
+- [Connect your AWS cloud](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_aws/) to Cloud Service.
+- [Connect to Cloud Service](/edb-postgres-ai/cloud-service/using_cluster/connecting_your_cluster/02_connecting_from_aws/) using AWS VPC endpoint service.
+- [Review the supported AWS regions](/edb-postgres-ai/cloud-service/references/supported_regions/#aws-regions) where you can create clusters for the AWS account, enabling you to locate your cloud resources close to your customers.
+- [View metrics and logs](/edb-postgres-ai/cloud-service/using_cluster/monitoring_and_logging/monitoring_from_aws/) sent from Cloud Service with AWS CloudWatch.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_azure.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_azure.mdx
new file mode 100644
index 00000000000..2ebc447ff25
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_azure.mdx
@@ -0,0 +1,14 @@
+---
+title: Deploying with Azure
+description: Choose Azure to manage databases on EDB Postgres AI Cloud Service.
+---
+
+To use Azure as your cloud account:
+
+- Sign in for the first time with your EDB account, and then either use the EDB Postgres AI Console as your identity provider or [set up your own provider](/edb-postgres-ai/console/using/organizations/identity_provider/) afterward.
+- Check the readiness of [your Azure subscription](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/) before deploying.
+- [Connect your Azure cloud](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_azure/) to Cloud Service.
+- [Connect to Cloud Service](/edb-postgres-ai/cloud-service/using_cluster/connecting_your_cluster/connecting_from_azure/) from your application's virtual network in Azure.
+- [Review the supported Azure regions](/edb-postgres-ai/cloud-service/references/supported_regions/#azure-regions) where you can create clusters for the Azure account, enabling you to locate your cloud resources close to your customers.
+- [View metrics and logs](/edb-postgres-ai/cloud-service/using_cluster/monitoring_and_logging/monitoring_from_azure/) sent from Cloud Service in your Azure account.
+- [Configure Azure](/edb-postgres-ai/cloud-service/using_cluster/monitoring_and_logging/alerts/) to trigger real-time alerts based on the metrics in Cloud Service.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_gcp.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_gcp.mdx
new file mode 100644
index 00000000000..dbf7f821609
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/deploy_gcp.mdx
@@ -0,0 +1,12 @@
+---
+title: Deploying with Google Cloud
+description: Choose Google Cloud to manage databases on EDB Postgres AI Cloud Service.
+---
+
+To use Google Cloud as your cloud account:
+
+- Sign in for the first time with your EDB account, and then either use the EDB Postgres AI Console as your identity provider or [set up your own provider](/edb-postgres-ai/console/using/organizations/identity_provider/) afterward.
+- Check the [readiness of your Google Cloud account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/) before deploying.
+- [Connect your Google Cloud account](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/connecting_to_your_cloud/connecting_gcp/) to EDB Postgres AI Console using Google Cloud Shell.
+- [Connect your cluster from Google Cloud](/edb-postgres-ai/cloud-service/using_cluster/connecting_your_cluster/connecting_from_gcp/) to EDB Postgres AI Console using Google Cloud's Private Service Connect.
+- [Review the supported Google Cloud regions](/edb-postgres-ai/cloud-service/references/supported_regions/#google-cloud-regions) where you can create clusters for the Google Cloud account, enabling you to locate your cloud resources close to your customers.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/index.mdx
new file mode 100644
index 00000000000..100451b3260
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/deploying_using_your_cloud_account/index.mdx
@@ -0,0 +1,16 @@
+---
+title: Deploying using your own cloud account
+description: You can choose your own cloud account to manage databases on EDB Postgres AI Cloud Service.
+navigation:
+- deploy_aws
+- deploy_azure
+- deploy_gcp
+redirects:
+- /biganimal/latest/planning/deployment_options/
+---
+
+You can choose your own cloud account to manage databases on EDB Postgres AI Cloud Service:
+
+- [AWS](deploy_aws.mdx)
+- [Azure](deploy_azure.mdx)
+- [Google Cloud](deploy_gcp.mdx)
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/getting_started_with_your_cloud_account.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/getting_started_with_your_cloud_account.mdx
new file mode 100644
index 00000000000..9d43f610e11
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/getting_started_with_your_cloud_account.mdx
@@ -0,0 +1,54 @@
+---
+title: Getting started with Your Cloud Account
+description: Describes high-level steps to get started with Your Cloud Account.
+---
+
+Use the following high-level steps to connect an EDB Postgres AI Project to your own cloud account to allow the Cloud Service to deploy and manage databases on your own cloud.
+
+1. Ensure you have the correct access permissions for your cloud account.
+
+ - **Azure** — Global Administrator or Privileged Role Administrator, and you must be a Subscription Owner.
+
+ - **AWS** — IAMFullAccess policy and ServiceQuotasFullAccess policy.
+
+ - **Google Cloud** — roles/owner or at least the following combined roles:
+
+ - roles/iam.serviceAccountCreator
+
+ - roles/iam.serviceAccountKeyAdmin
+
+ - roles/iam.roleAdmin
+
+ - roles/resourcemanager.projectIamAdmin
+
+ - roles/compute.viewer
+
+2. Set up your own identity provider. For more information see [Setting up your identity provider](/edb-postgres-ai/console/using/organizations/identity_provider/).
+
+3. Set up a CLI. See [Using the Cloud Service CLI](/edb-postgres-ai/cloud-service/using_cluster/cli/). Although we recommend using a CLI, it isn't required.
+
+4. Check that your cloud provider has the resources to work with EDB Postgres AI. You must do this every time you create a new cluster. The required steps vary by cloud provider. See:
+
+ - [Preparing your Azure account](preparing_cloud_account/preparing_azure/).
+
+ - [Preparing your AWS account](preparing_cloud_account/preparing_aws/).
+
+ - [Preparing your Google Cloud account](preparing_cloud_account/preparing_gcp/).
+
+5. Connect to your cloud. See [Connecting to your cloud](connecting_to_your_cloud/).
+
+6. Activate and manage regions. See [Managing regions](managing_regions/).
+
+7. Create a cluster. When prompted for **Where to deploy**, select **Your Cloud Account**. See [Creating a cluster](../creating_cluster/creating_a_cluster/).
+
+8. Use your cluster. See [Using your cluster](/edb-postgres-ai/cloud-service/using_cluster/).
+
+9. Optionally, set up private networking to allow you to connect to your cluster from other applications. The steps depend on your cloud service provider. See:
+
+ - [Connecting from Azure](/edb-postgres-ai/cloud-service/using_cluster/connecting_your_cluster/connecting_from_azure/)
+
+ - [Connecting from AWS](/edb-postgres-ai/cloud-service/using_cluster/connecting_your_cluster/02_connecting_from_aws/)
+
+ - [Connecting from Google Cloud](/edb-postgres-ai/cloud-service/using_cluster/connecting_your_cluster/connecting_from_gcp/)
+
+10. Provide access to other users. See [Managing user access](/edb-postgres-ai/console/using/organizations/users/).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/index.mdx
new file mode 100644
index 00000000000..d6ae119c0b8
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/index.mdx
@@ -0,0 +1,14 @@
+---
+title: Setting up Your Cloud Account
+description: How to prepare, deploy, connect and work with clusters when using Your Cloud Account.
+navigation:
+- getting_started_with_your_cloud_account
+- preparing_cloud_account
+- deploying_using_your_cloud_account
+- managing_regions
+- connecting_to_your_cloud
+- cluster_networking
+- azure_market_setup
+---
+
+Each of this section walks you through how to work with your clusters on EDB Postgres AI if you choose Your Cloud Account.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/managing_regions.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/managing_regions.mdx
new file mode 100644
index 00000000000..5da62b4c464
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/managing_regions.mdx
@@ -0,0 +1,56 @@
+---
+title: "Managing regions"
+description: How to activate, suspend, or delete regions for Your Cloud Account.
+---
+
+!!!note
+
+ If you're using EDB Hosted Cloud Service, you don't need to activate regions. However, you can suspend and delete regions.
+
+## Activate a new region from the Regions page
+
+When you activate a region, Cloud Service prepares the compute and networking resources required to deploy clusters. These added resources can increase your cloud costs.
+
+You must activate a region before creating or restoring a cluster.
+
+Each region you activate displays a status. The status is available on the Create cluster and Restore cluster pages and the Regions page. For more information on the different region statuses, see [Region status reference](#region-status-reference).
+
+You can activate a region ahead of time using the Regions page.
+
+1. To activate a region before creating a cluster, go to the Regions page.
+
+
+2. If you haven't set up your cloud server provider (CSP), you're prompted to do so. See [Connecting your cloud](connecting_to_your_cloud/).
+
+ When your cloud server provider is set up, you see a list of regions associated with it on the Regions page.
+
+3. Select **Activate New Region**, and select your cloud provider and the region you want to activate. You can activate multiple regions where you plan on adding clusters.
+
+4. Select **Activate Region(s)**.
+
+## Suspend, reactivate, or delete a region
+
+Before you suspend or delete a region, you must delete all clusters in that region.
+
+1. On the left panel, select **Regions**.
+
+ A list of previously activated regions appears.
+
+2. Select the icons next to a region to:
+ - Suspend or delete an active region.
+ - Reactivate a suspended region.
+
+## Region status reference
+
+| Status | Description |
+| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Activating | You have activated the region, and Cloud Service is setting up the compute and networking resources to support the cluster you requested. Backups and logs aren't available yet. |
+| Active | Cloud Service has completed setting up the compute and networking resources. The region has at least one cluster, and you can create more. The region has backups and logs. |
+| Suspended | You have deleted any active clusters. Cloud Service has removed the compute and networking resources. The backups and logs are still available. EDB Postgres AI continues to maintain backups and logs based on the retention period set when the cluster was last active. |
+| Deleted | You have deleted the clusters. Cloud Service has removed the compute and networking resources. The backups and logs are no longer available. Only account owners can delete a region. |
+| Error | An error occurred while trying to activate or suspend the region. The cause might be a quota issue. See the topic for your cloud provider under [Checking your cloud readiness](preparing_cloud_account/) for information on checking whether requirements and resource limits are met and how to raise them, if needed. Contact [EDB Support](/edb-postgres-ai/cloud-service/support_services/) if you need additional help troubleshooting the error. |
+
+## See also
+
+- [Creating your cluster](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/)
+- [Supported regions](/edb-postgres-ai/cloud-service/references/supported_regions/)
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/index.mdx
new file mode 100644
index 00000000000..69f6e3607f1
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/index.mdx
@@ -0,0 +1,13 @@
+---
+title: "Checking your cloud readiness"
+indexCards: simple
+description: When using Your Cloud Account, how to ensure its readiness to work with EDB Postgres AI.
+redirects:
+ - /biganimal/latest/getting_started/01_check_resource_limits/
+navigation:
+ - preparing_aws
+ - preparing_azure
+ - preparing_gcp
+---
+
+When using Your Cloud Account, each time you create a cluster, you must ensure the readiness of your cloud to work with EDB Postgres AI. You need to perform this check only if you're not using EDB's Cloud Service as your [deployment option](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_aws.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_aws.mdx
new file mode 100644
index 00000000000..cc5dd25940e
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_aws.mdx
@@ -0,0 +1,85 @@
+---
+title: "Preparing your AWS account"
+description: Prepare your AWS account to manage databases on EDB Postgres AI Cloud Service.
+---
+
+## Prerequisites
+
+Before preparing your cloud account, make sure that you're assigned the following AWS managed policies or an equivalent custom policy granting full access to resources:
+
+- arn:aws:iam::aws:policy/IAMFullAccess
+
+- arn:aws:iam::aws:policy/ServiceQuotasFullAccess
+
+EDB Postgres AI Cloud Service requires you to check the readiness of your AWS account before you deploy your clusters. (You don't need to perform this check if you're using the EDB Hosted Cloud Service as your [deployment option](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/).) The checks that you perform ensure that your AWS account is prepared to meet your clusters' requirements and resource limits, such as:
+
+- Is the AWS CLI configured to access your AWS account?
+- Is there a sufficient limit on the number of vCPUs and Network Load Balancers (NLBs) left in your region?
+
+## Check AWS resource limits for running Cloud Service
+
+EDB provides a shell script, called [biganimal-csp-preflight](https://github.com/EnterpriseDB/cloud-utilities/blob/main/aws/biganimal-csp-preflight), which checks whether requirements and resource limits are met in your AWS account based on the clusters you plan to deploy.
+
+1. Open the [AWS Cloud Shell](https://console.aws.amazon.com/cloudshell) in your browser.
+2. From the AWS Cloud Shell, run the following command:
+
+ ```shell
+ curl -sL https://raw.githubusercontent.com/EnterpriseDB/cloud-utilities/main/aws/biganimal-csp-preflight | bash -s [options]
+ ```
+
+ The required arguments are:
+
+ | Argument | Description |
+ | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+ | <account-id> | AWS account ID of your Cloud Service deployment. |
+ | <region> | AWS region where your clusters are being deployed. See [Supported regions](/edb-postgres-ai/cloud-service/references/supported_regions/) for a list of possible regions. |
+
+ Possible options are:
+
+ | Options | Description |
+ | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | `-h` or `--help` | Displays the command help. |
+ | `-i` or `--instance-type` | AWS instance type for the Cloud Service cluster. The help command provides a list of possible VM instance types. Choose the instance type that best suits your application and workload. Choose an instance type in the memory optimized R5, R5B, or R6I series for large data sets. Choose from the compute-optimized C5 or C6I series for compute-bound applications. Choose from the general purpose M5 or M6I series if you don't require memory or compute optimization. |
+ | `-a` or `--high-availability` | *DEPRECATED* - Enables high availability for the cluster. See \[Supported cluster types(../../overview/02_high_availability) for more information. |
+ | `-x` or `--cluster-architecture` | Defines the Cluster architecture and can be `single`, `ha`, or `eha`. See [Supported cluster types](/edb-postgres-ai/cloud-service/references/supported_cluster_types/) for more information. |
+ | `-n` or `--networking` | Type of network endpoint for the Cloud Service cluster, either `public` or `private`. See [Cluster networking architecture](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/cluster_networking/) for more information. |
+ | `-r` or `--activate-region` | Specifies region activation if no clusters currently exist in the region. |
+ | `--onboard` | Checks if the user and subscription are correctly configured. |
+
+ The behavior of the script defaults to `--onboard` if you provide no other options.
+
+ For example, if you want to deploy a cluster in an AWS account having an ID of `1234-5678-9012`, with an instance type of `r5.24xlarge`, in the `us-east-1` region, in a `public` endpoint, and with no existing cluster deployed, run the following command:
+
+ ```shell
+ curl -sL https://raw.githubusercontent.com/EnterpriseDB/cloud-utilities/main/aws/biganimal-csp-preflight | bash -s \
+ 1234-5678-9012 \
+ us-east-1 \
+ --instance-type r5.24xlarge \
+ --networking public \
+ --activate-region \
+ --onboard\
+ ```
+
+The script displays the following output:
+
+- Whether your AWS account restricts vCPUs, elastic IP addresses, VPCs, or NLBs in your region (and availability zone, if HA is enabled). Open an AWS support request to remove restrictions for the resources with `NotAvailable` displayed in the `Suggestion` column. See [Request quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). For default service quota limits in AWS, see [AWS service information](https://docs.aws.amazon.com/general/latest/gr/aws-general.pdf#aws-service-information.)
+
+ ```
+ ##############################################
+ Checking Service Quotas Limits on us-east-1...
+ ##############################################
+
+ Resource Quota Name Limit Used Required Gap Suggestion
+ -------- ---------- ---- ----- -------- --- ----------
+ m5(a).large vCPUs Running On-Demand Standard instances 512 0 6 410 OK
+ r5.24xlarge vCPUs Running On-Demand Standard instances 512 0 96 410 OK
+ Elastic IP Addresses EC2-VPC Elastic IPs 5 0 3 2 OK
+ VPCs VPCs per Region 5 1 2 2 OK
+ NLBs Network Load Balancers per Region 50 0 1 49 OK
+
+ Note: the first two Instance Types are referring to the same AWS Service Quota.
+ ```
+
+## Configure your AWS account
+
+Open an AWS support request to remove restrictions for the resources with `NotAvailable` displayed in the `Suggestion` column. See [Request quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). For default service quota limits in AWS, see [AWS service information](https://docs.aws.amazon.com/general/latest/gr/aws-general.pdf#aws-service-information).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/01_understanding_qotas_in_azure.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/01_understanding_qotas_in_azure.mdx
new file mode 100644
index 00000000000..0d87d040ac1
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/01_understanding_qotas_in_azure.mdx
@@ -0,0 +1,79 @@
+---
+title: "Understanding requirements in Azure"
+redirects:
+ - /biganimal/latest/getting_started/01_preparing_azure/01_understanding_qotas_in_azure/
+---
+
+Follow these BigAnimal requirements and recommended resource limits in Azure.
+
+## Azure resource provider registrations
+
+BigAnimal creates and manages some of the resources using resource providers. For example, if you want to store keys, you need the Microsoft.KeyVault resource provider. This resource provider offers a resource type called *vaults* for creating the key vault. For more information, see [Azure resource providers and types](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types).
+
+To prevent failures while creating your clusters, ensure that each of the following Azure resource providers are registered in your Azure subscription.
+
+| Provider namespace | Description |
+| ------------------------------ | ------------------------------------------------------------------------------------------------------- |
+| Microsoft.Compute | Runs cluster workloads on a virtual machine managed by the Azure Kubernetes service |
+| Microsoft.ContainerInstance | Manages the Azure resource and regular maintenance job. |
+| Microsoft.Capacity | Checks the Azure resource quota |
+| Microsoft.AlertsManagement | Monitors failure anomalies |
+| Microsoft.ContainerService | Manages cluster workloads run on the Azure Kubernetes Service |
+| Microsoft.KeyVault | Encrypts and stores keys of the clusters' data volume and Azure's credential information |
+| Microsoft.Storage | Backs up data to the Azure Service Account |
+| Microsoft.ManagedIdentity | Manages software access to the local Azure services using Azure Managed-Identity |
+| Microsoft.Network | Manages cluster workloads run in the Azure Kubernetes Service in the dedicated VNet |
+| Microsoft.OperationalInsights | Manages clusters and performs workload logging (log workspace) |
+| Microsoft.OperationsManagement | Monitors workloads and provides container insight |
+| Microsoft.Portal | Provides a dashboard to monitor the running status of the clusters (using aggregated logs and metrics) |
+
+## Regional activation resources and access requirements
+
+The table provides BigAnimal's regional activation resources and access requirements.
+
+| Resource type | Activated region | Network access | Description |
+|--------------------------------------|------------------|----------------|----------------------------------------------------------------------|
+| Virtual network | Yes | N/A | |
+| Storage account for backup | yes | Public | Public is required for faraway replication and cross region restore. |
+| KeyVault for backup | Yes | Public | |
+| Storage account for logs and metrics | Yes | Private | |
+| KeyVault for AKS, logs, and metrics | Yes | Private | |
+| Managed Identify | Yes | N/A | |
+| NSG | Yes | N/A | |
+| Private endpoint | Yes | N/A | |
+| AKS | Yes | N/A | |
+| Application insights | Yes | N/A | Not in use for custom monitoring |
+| Log analytics workspaces | Yes | N/A | Not in use for custom monitoring |
+
+!!!note
+A Storage account for TFstate is created on the first activated region per BigAnimal project. It is in private network access. Private DNS zone are required for private storage account and private key vaults.
+!!!
+## Public IP addresses limits
+
+Every BigAnimal cluster with public network access is assigned a single public IP address, and this IP address counts against the quota for both basic and standard IP address types in a region. BigAnimal can't create more clusters if the IP address limit is reached.
+
+### Recommended limit
+
+The default public IP addresses limits for basic and standard type are set to 10. See [Public IP address limits](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#publicip-address) for more information. If you need more than 10 clusters, increase the limit to the number of clusters you plan to deploy plus current usage.
+
+## vCPU limits
+
+Any time a new VM is deployed in Azure, the vCPUs for the VMs must not exceed the total vCPU limits for the region.
+
+The number of cores required by the database cluster depends on the instance type and cluster type of the clusters. For exampe, if you create cluster with ESv3 instance type, you can calculate the number of ESv3 cores required for your cluster based on the following:
+
+- A virtual machine instance of type E{N}sv3 uses {N} cores. For example, an instance of type E64sv3 uses 64 ESv3 cores.
+- A cluster running on an E{N}sv3 instance without HA enabled uses exactly {N} ESv3 cores.
+- A cluster running on an E{N}sv3 instance with HA enabled and 2 replicas uses 3 \* {N} ESv3 cores.
+
+BigAnimal requires an additional eight Dv4 virtual machine cores per region for management resources.
+
+BigAnimal requires an additional six Dv4 virtual machine cores per region for periodic maintenance upgrades.
+
+### Recommended limits
+
+BigAnimal recommends the following per region when requesting virtual machine resource limit increases:
+
+- Total Regional vCPUs: minimum of 50 per designated region
+- Standard Dv4 Family vCPUs: minimum of 14 per designated region
+- Other Family vCPUs: depending on the instance type, cluster type, and number of clusters.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/index.mdx
new file mode 100644
index 00000000000..ad04b80b081
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_azure/index.mdx
@@ -0,0 +1,211 @@
+---
+title: "Preparing your Azure account"
+description: Prepare your Azure account to manage databases on EDB Postgres AI Cloud Service.
+redirects:
+ - /biganimal/latest/getting_started/01_preparing_azure/
+---
+
+BigAnimal requires you to check the readiness of your Azure subscription before you deploy your clusters. (You don't need to perform this check if you're using BigAnimal's cloud account as your [deployment option](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/).) The checks that you perform ensure that your Azure subscription is prepared to meet your clusters' requirements and resource limits, such as:
+
+- Are the necessary Azure resource providers registered for your subscription?
+- Is there a restriction on SKUs for the standard Esv3 family and standard D2_v4 VM size?
+- Is there a sufficient limit on the number of vCPU or public IP addresses in your region?
+
+## Prerequisites
+
+When preparing your Azure account, make sure that you're assigned either the Global Administrator role or the Privileged Role Administrator role in Azure AD and that you have the Owner role for your BigAnimal Azure subscription.
+
+Before proceeding, see [Understanding requirements in Azure](01_understanding_qotas_in_azure) for details on planning for your clusters' requirements and resource limits in Azure.
+
+## Check for readiness
+
+We recommend using the `biganimal-csp-preflight` script to check whether all requirements and resource limits are met in your subscription. However, you can also manually check the requirements using the Azure CLI or the Azure Portal.
+
+- [Method 1: Use EDB's shell script](#method-1-use-edbs-shell-script) (recommended)
+- [Method 2: Manually check requirements](#method-2-manually-check-readiness)
+
+### Method 1: Use EDB's shell script
+
+EDB provides a shell script, called [`biganimal-csp-preflight`](https://github.com/EnterpriseDB/cloud-utilities/blob/main/azure/biganimal-csp-preflight), which checks whether requirements and resource limits are met in your Azure subscription based on the clusters you plan to deploy.
+
+1. Open the [Azure Cloud Shell](https://shell.azure.com/) in your browser.
+2. From the Azure Cloud Shell, run the following command:
+
+ ```shell
+ curl -sL https://raw.githubusercontent.com/EnterpriseDB/cloud-utilities/main/azure/biganimal-csp-preflight | bash -s [options]
+ ```
+
+ The required arguments are:
+
+ | Argument | Description |
+ | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | <target-subscription> | Azure subscription ID of your BigAnimal deployment. |
+ | <region> | Azure region where your clusters are being deployed. See [Supported regions](/edb-postgres-ai/cloud-service/references/supported_regions/) for a list of possible regions. |
+
+ Possible options are:
+
+ | Options | Description |
+ | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+ | `-h` or `--help` | Displays the command help. |
+ | `-i` or `--instance-type` | Azure VM instance type for the BigAnimal cluster. The `help` command provides a list of possible VM instance types. Choose the instance type that best suits your application and workload. Choose an instance type in the memory optimized ESv3 or ESv4 series for large data sets. Choose from the compute optimized FSv2 series for compute-bound applications. Choose from the general purpose DSv3 or DSv4 series if you don't require memory or compute optimization. See [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for information to help you choose the appropriate instance type. |
+ | `-a` or `--high-availability` | *DEPRECATED* - Enables high availability for the cluster. Replaced with `-x` or `--cluster-architecture` command. |
+ | `-x` or `--cluster-architecture` | Defines the cluster architecture and can be `single`, `ha`, or `eha`. See [Supported cluster types](/edb-postgres-ai/cloud-service/references/supported_cluster_types/) for more information. |
+ | `-n` or `--networking` | Type of network endpoint for the BigAnimal cluster, either `public` or `private`. See [Cluster networking architecture](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/cluster_networking/) for more information. |
+ | `-r` or `--activate-region` | Specifies region activation if no clusters currently exist in the region. |
+ | `--onboard` | Checks if the user and subscription are correctly configured. |
+
+ The behavior of the script defaults to `--onboard` if you provide no other options.
+
+ For example, if you want to deploy a cluster in an Azure subscription having an ID of `12412ab3d-1515-2217-96f5-0338184fcc04`, with an instance type of `e2s_v3`, in the `eastus2` region, in a `public` network, and with no existing cluster deployed, run the following command:
+
+ ```shell
+ curl -sL https://raw.githubusercontent.com/EnterpriseDB/cloud-utilities/main/azure/biganimal-csp-preflight | bash -s \
+ 12412ab3d-1515-2217-96f5-0338184fcc04 eastus2 \
+ --instance-type e2s_v3 \
+ --cluster-architecture ha \
+ --networking public \
+ --activate-region
+ ```
+
+The script displays the following output:
+
+- A list of required Azure resource providers and their registration status. Ensure that you register the resource providers that are displayed as `NotRegistered` in the `RegistrationState` column. See [Register Azure resource providers](#register-azure-resource-providers).
+
+ ```
+ #######################
+ # Provider #
+ #######################
+
+ Namespace RegistrationPolicy RegistrationState ProviderAuthorizationConsentState
+ --------------------------------------- -------------------- -----------------
+ Microsoft.Capacity RegistrationRequired NotRegistered
+ Microsoft.ContainerInstance RegistrationRequired NotRegistered
+ Microsoft.Compute RegistrationRequired NotRegistered
+ Microsoft.ContainerService RegistrationRequired NotRegistered
+ Microsoft.KeyVault RegistrationRequired NotRegistered
+ Microsoft.ManagedIdentity RegistrationRequired NotRegistered
+ Microsoft.Network RegistrationRequired NotRegistered
+ Microsoft.OperationalInsights RegistrationRequired NotRegistered
+ Microsoft.OperationsManagement RegistrationRequired NotRegistered
+ Microsoft.Portal RegistrationFree Registered
+ Microsoft.Storage RegistrationRequired Registered
+ Microsoft.AlertsManagement RegistrationRequired NotRegistered
+ ```
+
+- Whether your Azure subscription restricts vCPUs for the `Standard_D2_v4` and `Standard_E2s_v3` VM size families in your region (and availability zone, if HA is enabled). Open a support request to remove SKU restrictions for the VM families with `NotAvailableForSubscription` displayed in the `Restrictions` column. See [Fix issues with SKU restrictions](#fix-issues-with-sku-restrictions).
+
+ ```
+ #######################
+ # Virtual-Machine SKU #
+ #######################
+
+ ResourceType Locations Name Zones Restrictions
+ ------------ --------- ---- ----- ------------
+ virtualMachines eastus2 Standard_D2_v4 1,2,3 None
+ virtualMachines eastus2 Standard_E2s_v3 1,2,3 NotAvailableForSubscription, type: Zone, locations: eastus2, zones: 1,3
+
+ ```
+
+- Whether your Azure subscription has sufficient limits on vCPUs and IP addresses for your region. Open a support request to raise limits for the vCPUs and IP addresses if they exceed the available VM families with `NotAvailableForSubscription` displayed in the `Restrictions` column. See [Increase Public IP addresses](#increase-public-ip-addresses-limits) and [Increase vCPU limits](#increase-vcpu-limits).
+
+ ```
+ #######################
+ # Quota Limitation #
+ #######################
+
+ Resource Limit Used Available Gap Suggestion
+ Total Regional vCPUs 130 27 103 89 OK
+ Standard Dv4 Family vCPUs 20 14 6 0 Need Increase
+ Standard ESv3 Family vCPUs 20 4 16 8 OK
+ Public IP Addresses — Standard 20 3 17 16 OK
+ ```
+
+### Method 2: Manually check readiness
+
+You can manually check the requirements instead of using the `biganimal-csp-preflight` script.
+
+#### Check Azure resource provider registrations using Azure Cloud Shell
+
+To check if an Azure resource provider is registered, use the following command.
+
+```shell
+az provider show -n Microsoft.ContainerService
+__OUTPUT__
+Namespace RegistrationPolicy RegistrationState
+-------------------------- -------------------- -------------------
+Microsoft.ContainerService RegistrationRequired Registered
+
+```
+
+#### Check for SKU restrictions for the specific VM size
+
+You can check SKU restrictions for the VM size using the Azure Cloud Shell. For example, to check the Standard_E2s_v3 VM SKU restriction in `eastus2` location for all zones, run the following command:
+
+```shell
+az vm list-skus -l eastus2 --zone --size Standard_E2s_v3
+__OUTPUT__
+ResourceType Locations Name Zones Restrictions
+--------------- ----------- --------------- ------- ------------
+virtualMachines eastus2 Standard_E2s_v3 1,2,3 NotAvailableForSubscription, type: Zone, locations: eastus2, zones: 3,2
+```
+
+Alternatively, to check for SKU restrictions using the Azure Portal, see [Solution 3 - Azure portal](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/error-sku-not-available#solution-3---azure-portal).
+
+#### Check the resource limits for vCPUs and public IP addresses for your region
+
+To check if you have adequate Azure resources to provision new clusters:
+
+1. In the [Azure Portal](https://portal.azure.com/), select **Subscription**.
+2. Select your specific subscription.
+3. Select **Usage + quotas** in the **Settings** section.
+4. Search for `Total Regional vCPUs` and select the **Location** to check the regional vCPUs limits.
+5. Search for `Dv4` and `Esv3` to view virtual machine limits.
+6. Search for Public IP addresses to view network limits.
+
+## Configure your Azure subscription
+
+After checking whether the requirements and resource limits are met, configure your Azure subscription.
+
+!!! Note
+
+ Before proceeding, see [Understanding requirements in Azure](01_understanding_qotas_in_azure) for details on planning for your clusters' requirements and resource limits in Azure.
+
+### Register Azure resource providers
+
+To register resource providers using the Azure Portal:
+
+1. In the [Azure Portal](https://portal.azure.com/), select **Subscription**.
+2. Select your specific subscription.
+3. In the navigation panel **Settings** group, select **Resource providers**.
+4. Review the status of the required providers. To register a provider, select the provider and, on the top menu, select **Register**.
+
+To register resource providers using the Azure CLI,
+use the [register command](https://docs.microsoft.com/en-us/cli/azure/provider?view=azure-cli-latest#az-provider-register). For example:
+
+```shell
+az provider register -n Microsoft.ContainerService
+__OUTPUT__
+Registering is still on-going. You can monitor using 'az provider show -n Microsoft.ContainerService
+```
+
+### Fix issues with SKU restrictions
+
+[Open a support request](https://docs.microsoft.com/en-us/troubleshoot/azure/general/region-access-request-process) to remove SKU restrictions in a particular region.
+
+### Increase public IP addresses limits
+
+Increase the limit of `Public IP Addresses - Basic` and `Public IP Addresses - Standard` for the regions where you plan to deploy your clusters with the total number of clusters you plan to use.
+
+You can increase the number of public IP addresses for your account either by using the Azure portal or by submitting a support request. See:
+
+- [Request networking quota increase at subscription level using Usages + quotas](https://docs.microsoft.com/en-us/azure/azure-portal/supportability/networking-quota-requests#request-networking-quota-increase-at-subscription-level-using-usage--quotas)
+
+- [Request Networking quota increase at subscription level using Help + support](https://docs.microsoft.com/en-us/azure/azure-portal/supportability/networking-quota-requests#request-networking-quota-increase-at-subscription-level-using-help--support)
+
+### Increase vCPU limits
+
+You can increase the number of Dv4 or Esv3 family virtual machines per region by using the Azure Portal or by submitting a support request. See:
+
+- [Request a quota increase at a subscription level using Usages + quotas](https://docs.microsoft.com/en-us/azure/azure-portal/supportability/classic-deployment-model-quota-increase-requests#request-quota-increase-for-the-classic-deployment-model-from-usage--quotas)
+
+- [Request a quota increase by region from Help + support](https://docs.microsoft.com/en-us/azure/azure-portal/supportability/regional-quota-requests#request-a-quota-increase-by-region-from-help--support)
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/index.mdx
new file mode 100644
index 00000000000..5074efeff0e
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/index.mdx
@@ -0,0 +1,135 @@
+---
+title: Preparing your Google Cloud account
+description: Prepare your Google Cloud account to manage databases on EDB Postgres AI Cloud Service.
+---
+
+## Prerequisites
+
+Ensure you have at least the following combined roles:
+
+- roles/iam.serviceAccountCreator
+- roles/iam.serviceAccountKeyAdmin
+- roles/iam.roleAdmin
+- roles/resourcemanager.projectIamAdmin
+- roles/compute.viewer
+
+Alternatively, you can have an equivalent single role, such as:
+
+- roles/owner
+
+BigAnimal requires you to check the readiness of your Google Cloud (GCP) account before you deploy your clusters. (You don't need to perform this check if you're using BigAnimal's cloud account as your [deployment option](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/). The checks that you perform ensure that your Google Cloud account is prepared to meet your clusters' requirements and resource limits.
+
+## Required APIs and services
+
+Ensure the following Google Cloud APIs are enabled:
+
+- autoscaling.googleapis.com
+- cloudapis.googleapis.com
+- cloudresourcemanager.googleapis.com
+- compute.googleapis.com
+- container.googleapis.com
+- iam.googleapis.com
+- iamcredentials.googleapis.com
+- run.googleapis.com
+- secretmanager.googleapis.com
+- storage.googleapis.com
+- vpcaccess.googleapis.com
+
+## Check Google Cloud resource limits for running BigAnimal
+
+EDB provides a shell script, called [biganimal-csp-preflight](https://github.com/EnterpriseDB/cloud-utilities/blob/main/gcp/biganimal-csp-preflight), which checks whether requirements and resource limits are met in your Google Cloud account based on the clusters you plan to deploy.
+
+1. Open [Google Cloud Shell](https://cloud.google.com/shell) in your browser.
+2. From Google Cloud Shell, run the following command:
+
+ ```shell
+ curl -sL https://raw.githubusercontent.com/EnterpriseDB/cloud-utilities/main/gcp/biganimal-csp-preflight | bash -s [options]
+ ```
+
+ The required arguments are:
+
+ | Argument | Description |
+ | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | <project-id> | Google Cloud project ID of your BigAnimal deployment. |
+ | <region> | Google Cloud region where your clusters are being deployed. See [Supported regions](/edb-postgres-ai/cloud-service/references/supported_regions/#google-cloud-regions-1) for a list of possible regions. |
+
+ Possible options are:
+
+ | Options | Description |
+ | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | `-h` or `--help` | Displays the command help. |
+ | `-i` or `--instance-type` | Google Cloud instance type for the BigAnimal cluster. The help command provides a list of possible VM instance types. Choose the instance type that best suits your application and workload. Choose an instance type in the memory optimized M1, M2, or M3 series for large data sets. Choose from the compute-optimized C2 series for compute-bound applications. Choose from the general purpose E2, N2, and N2D series if you don't require memory or compute optimization. |
+ | `-x` or `--cluster-architecture` | Defines the Cluster architecture and can be `single`, `ha`, or `eha`. See [Supported cluster types](/edb-postgres-ai/cloud-service/references/supported_cluster_types/) for more information. |
+ | `-e` or `--networking` | Type of network endpoint for the BigAnimal cluster, either `public` or `private`. See [Cluster networking architecture](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/cluster_networking/) for more information. |
+ | `-r` or `--activate-region` | Specifies region activation if no clusters currently exist in the region. |
+ | `--onboard` | Checks if the user and subscription are correctly configured. |
+
+ The behavior of the script defaults to `--onboard` if you provide no other options.
+
+ For example, if you want to deploy a cluster in a Google Cloud account having an ID of `1234-5678-9012`, with an instance type of `n2-standard-8`, in the `us-east1` region, with a `public` endpoint, and with no existing cluster deployed, run the following command:
+
+ ```shell
+ curl -sL https://raw.githubusercontent.com/EnterpriseDB/cloud-utilities/main/gcp/biganimal-csp-preflight | bash -s \
+ 1234-5678-9012 \
+ us-east1 \
+ --instance-type n2-standard-8 \
+ --networking public \
+ --activate-region \
+ --onboard\
+ ```
+
+The script displays the following output:
+
+````
+```
+######################################################
+Run GCP Preflight Checks with Google Cloud CLI 436.0.0
+
+####################################
+# Checking for enabled GCP APIs... #
+####################################
+
+NAME RESULT
+--------------------------------------- ---------
+autoscaling.googleapis.com Enabled
+cloudapis.googleapis.com Enabled
+cloudresourcemanager.googleapis.com Enabled
+compute.googleapis.com Enabled
+container.googleapis.com Enabled
+iam.googleapis.com Enabled
+iamcredentials.googleapis.com Enabled
+run.googleapis.com Enabled
+secretmanager.googleapis.com Enabled
+storage.googleapis.com Enabled
+vpcaccess.googleapis.com Enabled
+
+##############################################
+Checking Service Quotas Limits on us-east1...
+##############################################
+
+Resource Quota Name Limit Used Required Gap Suggestion
+-------- ---------- ---- ----- -------- --- ----------
+n2-standard-2 vCPUs N2_CPUS 500 0 6 494 OK
+e2-standard-8 vCPUs E2_CPUS 2400 0 24 2376 OK
+Shared-Core vCPUs CPUS 2400 0 2 2398 OK
+Static IP Addresses STATIC_ADDRESSES 700 0 1 699 OK
+VPCs NETWORKS 50 14 1 35 OK
+Cloud Routers ROUTERS 20 6 1 13 OK
+
+#######################
+# Overall Suggestions #
+#######################
+```
+
+Make sure the GCP Project ID is the one that you want to use for BigAnimal.
+Make sure the GCP account has rights to create custom roles, service accounts, keys, and assign project grants.
+
+Use the Quotas page in the Google Cloud console if you need to raise any service quota limits.
+See https://cloud.google.com/docs/quota_detail/view_manage#requesting_higher_quota for more information.
+````
+
+## Configure your Google Cloud account
+
+If any APIs are listed as not enabled, see [Enabling and Disabling Services](https://cloud.google.com/service-usage/docs/enable-disable) in the Google Cloud documentation to enable the required APIs.
+
+If you need to increase your quotas, see [Request a higher quota limit](https://cloud.google.com/docs/quota_detail/view_manage#requesting_higher_quota).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/understanding_quotas_in_gcp.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/understanding_quotas_in_gcp.mdx
new file mode 100644
index 00000000000..f956cdcf329
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/preparing_cloud_account/preparing_gcp/understanding_quotas_in_gcp.mdx
@@ -0,0 +1,29 @@
+---
+title: "Understanding requirements in Google Cloud"
+---
+
+Follow these BigAnimal requirements and recommended resource limits in Google Cloud.
+
+## vCPU limits
+Any time a new VM is deployed in Google Cloud, the vCPUs for the VMs must not exceed the total vCPU limits for the region.
+
+The number of cores required by the database cluster depends on the instance type and cluster type of the clusters. For example, if you create a cluster with the standard E2 instance type, you can calculate the number of E2 cores required for your cluster based on the following:
+
+- A virtual machine instance of type e2-standard-{N} uses {N} cores. For example, an instance of type e2-standard-32 uses 32 e2-standard cores.
+
+- A cluster running on an e2-standard-{N} instance without HA enabled uses exactly {N} e2-standard cores.
+
+- A cluster running on an e2-standard-{N} instance with HA enabled and 2 replicas uses 3 * {N} e2-standard cores.
+
+BigAnimal requires an additional eight n2-standard virtual machine cores per region for management resources.
+
+BigAnimal requires an additional four n2-standard virtual machine cores per region for periodic maintenance upgrades.
+
+## Recommended limits
+BigAnimal recommends the following per region when requesting virtual machine resource limit increases:
+
+- Total Regional vCPUs: minimum of 50 per designated region
+
+- n2-standard vCPUs: minimum of 12 per designated region
+
+- Other machine family vCPUs: depends on the instance type, cluster type, and number of clusters.
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/hosted.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/hosted.mdx
deleted file mode 100644
index 49a64ea4321..00000000000
--- a/advocacy_docs/edb-postgres-ai/cloud-service/hosted.mdx
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Fully Hosted Databases on EDB Postgres AI Cloud Service
-navTitle: Hosted Databases
-description: EDB Postgres AI Cloud Service is able to host a fully managed EDB Postgres database in the EDB cloud.
----
-
-If you are looking for a fully hosted database solution, the Hosted option of the EDB Postgres AI Cloud Service provides a fully managed database service that allows you to focus on your applications and data, while EDB manages the database infrastructure. All you need to provide is the data and EDB manages the rest.
-
-The advantage of the Hosted option is that the database deploys within the EDB cloud infrastructure, so you have full control over the data. EDB's cloud infrastructure globally spans the major cloud service providers making it easy to co-locate the database with other services.
-
-EDB manages the database infrastructure, including backups, monitoring, and updates, and provides a single pane of glass for managing your databases, monitoring performance, and accessing logs and metrics. All of this is visible through the [EDB Postgres AI Console](../console) and its single pane of glass which provides a unified view of your fully managed databases, self-managed databases (through the [EDB Postgres AI Agent](../console/agent)), analytics lakehouses, S3 stores and machine learning services.
-
-Hosted, fully managed databases are also quick to deploy and easy to scale. You can start with a small database and scale up as your data grows. EDB manages the scaling and performance of the database, so you can focus on your applications and data.
-
-The Hosted option is ideal for organizations that want a fully managed database solution without the complexity of managing the database infrastructure or that want to quickly deploy a database and start building applications without having to provision and manage the database infrastructure.
-
-The Hosted option is available for EDB Postgres Advanced Server (EPAS) and EDB Postgres Extended Server (PGE) databases.To get a fully hosted cluster, select EDB Postgres AI Cloud Service as the deployment option when you create a new database:
-
-
-
-
-You can deploy EDB's Postgres Advanced Server (EPAS) or Postgres Extended Server (PGE) databases as hosted databases, with a range of [deployment options](deployment) for high availability and fault tolerance.
-
-
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/2DataGroups-1.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/2DataGroups-1.png
new file mode 100644
index 00000000000..3272cafb52f
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/2DataGroups-1.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:6bcecfd5c17d3e083c697f7f710572639f9627c2fcec1f5e0e2e4a71578e506c
+size 210452
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/2DataGroups-2.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/2DataGroups-2.png
new file mode 100644
index 00000000000..9f8e82530b9
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/2DataGroups-2.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:b5c2714053a56363a54d3026c7a66febdeaaa2c10fc9a74a591fa78811efefde
+size 208238
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/2dn-1wn-2dn-1wn-1wg.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/2dn-1wn-2dn-1wn-1wg.png
new file mode 100644
index 00000000000..59aaca86864
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/2dn-1wn-2dn-1wn-1wg.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:74d42cebb487b6b1805b444936e3b9081a59c5f6380f525fba195b5c57a98a73
+size 359697
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/2dn-1wn-2dn-1wn-1wg.svg b/advocacy_docs/edb-postgres-ai/cloud-service/images/2dn-1wn-2dn-1wn-1wg.svg
new file mode 100644
index 00000000000..8be40a52eb2
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/2dn-1wn-2dn-1wn-1wg.svg
@@ -0,0 +1,278 @@
+
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/EHA.svg b/advocacy_docs/edb-postgres-ai/cloud-service/images/EHA.svg
new file mode 100644
index 00000000000..b9e8ff12f8a
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/EHA.svg
@@ -0,0 +1,240 @@
+
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/Extreme-HA-Diagram-2x.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/Extreme-HA-Diagram-2x.png
new file mode 100644
index 00000000000..41f973c47ca
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/Extreme-HA-Diagram-2x.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:30461e8c5e0df0e62f34315e3e20e05484c4429f17305f8955ffa1de0d009b73
+size 61239
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/FarawayReplicas-afterpromotion.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/FarawayReplicas-afterpromotion.png
new file mode 100644
index 00000000000..82f41ec7ee4
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/FarawayReplicas-afterpromotion.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:4d41bc03eab7d2e4c90062d98819603f33c90dd3145fa6811f029821b3e1a59a
+size 92189
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/FarawayReplicas-generic.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/FarawayReplicas-generic.png
new file mode 100644
index 00000000000..5ca194c649a
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/FarawayReplicas-generic.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:109337ddf70f1f958e9ce65cb474c7774806b63f72c5c26066cfa37a6bd8194b
+size 84621
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/HA-diagram-2x.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/HA-diagram-2x.png
new file mode 100644
index 00000000000..66dafa45e47
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/HA-diagram-2x.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:437565fba81757714d1327c15e308a7487db42e05579a88b2d471253a3eb60ae
+size 32023
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/Multi-Region-3Nodes.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/Multi-Region-3Nodes.png
new file mode 100644
index 00000000000..cfbb8b4ff33
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/Multi-Region-3Nodes.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:99c0c7b484924972fc3746ef09ddf814a62e4edd8fbe62cdaddfe1c23bcde097
+size 169825
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/Single-Node-Diagram-2x.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/Single-Node-Diagram-2x.png
new file mode 100644
index 00000000000..75e5fca9a21
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/Single-Node-Diagram-2x.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:b9d6b638f6ecbd6873defb748317d2a24f50759a7236f6f69339ab24313c27e5
+size 11826
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/SingleDataGroup-1.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/SingleDataGroup-1.png
new file mode 100644
index 00000000000..547b7d36ca0
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/SingleDataGroup-1.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:01eb5ae6e77befbc5eabaae6789dbb5b46c8f3a5daed126ee3089175f045ea45
+size 111293
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/SingleDataGroup-2.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/SingleDataGroup-2.png
new file mode 100644
index 00000000000..f4ab07eb42d
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/SingleDataGroup-2.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:5955225fd1383258575c0106c7d20b39ee1e2c3f4517418cda9e6e906a1ee0ce
+size 112688
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/eha.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/eha.png
new file mode 100644
index 00000000000..b38c429dd45
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/eha.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:4cf9c6fb91cf9fce3487bd3884947cf335096ceb9fe94de73825b86c19a60c85
+size 246162
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-availability.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-availability.png
new file mode 100644
index 00000000000..13062dcdc16
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-availability.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:d991c511cfbfd3bdc257da62766a46154933e418950cf6da9b98b0a2df32d2fa
+size 228061
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-3-regions.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-3-regions.png
new file mode 100644
index 00000000000..bb2081a64bc
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-3-regions.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:871d962f5d9335fba9b80d37e8e4f8d72e23f828c83228f0d443192e84c79832
+size 311221
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-3-regions.svg b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-3-regions.svg
new file mode 100644
index 00000000000..521f616b8e7
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-3-regions.svg
@@ -0,0 +1,280 @@
+
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-single-region.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-single-region.png
new file mode 100644
index 00000000000..afbacd39f7d
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-single-region.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:d2943ef212745d1b93015457ad184c9e247d29ff2534a98576eaee669446e314
+size 147431
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-single-region.svg b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-single-region.svg
new file mode 100644
index 00000000000..f53b8be67b7
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/extreme-high-availability-single-region.svg
@@ -0,0 +1,123 @@
+
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/ha-not-enabled.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/ha-not-enabled.png
new file mode 100644
index 00000000000..e631af0ca42
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/ha-not-enabled.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:9d170dc1ee7a35f0488c8d5d5f692dc338090a8ce8f5a9be638b856d76d31ed5
+size 120864
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability-old.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability-old.png
new file mode 100644
index 00000000000..54217e9c0a4
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability-old.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:a1bb12fedcac41d1e8f5985494ea31f5ee4b7a0bd966ab1cd3eca38e877ae828
+size 148648
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability.png
new file mode 100644
index 00000000000..7a0d7833450
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:7ad7f716ced4b99a09fb8e297802f8dabc9ef09263fcf39d36f3a4612b8bd629
+size 60881
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability.svg b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability.svg
new file mode 100644
index 00000000000..311cfb541b6
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availability.svg
@@ -0,0 +1,70 @@
+
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availibility.puml b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availibility.puml
new file mode 100644
index 00000000000..8b7d388d2aa
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/high-availibility.puml
@@ -0,0 +1,33 @@
+@startuml
+
+
+!pragma revision 1
+
+!includeurl https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
+
+!define AzurePuml https://raw.githubusercontent.com/plantuml-stdlib/Azure-PlantUML/master/dist
+!includeurl AzurePuml/AzureCommon.puml
+!includeurl AzurePuml/AzureSimplified.puml
+!includeurl AzurePuml/Databases/AzureDatabaseForPostgreSQL.puml
+!includeurl AzurePuml/Networking/AzureLoadBalancer.puml
+!includeurl AzurePuml/Web/AzureWebApp.puml
+
+
+AzureWebApp(app1, "App","")
+AzureWebApp(app2, "App","")
+AzureWebApp(app3, "App","")
+rectangle "EDB Cloud cluster" as src {
+ AzureLoadBalancer(service, "Service", "")
+ AzureDatabaseForPostgreSQL(primary,"PostgreSQL Primary", "Primary" )
+ AzureDatabaseForPostgreSQL(standby1, "PostgreSQL Standby", "Standby" )
+ AzureDatabaseForPostgreSQL(standby2, "PostgreSQL Standby", "Standby" )
+
+ primary -> standby1
+ primary -> standby2
+ service <-d->primary
+}
+
+app1-d->service
+app2-d->service
+app3-d->service
+@enduml
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/image3.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/image3.png
new file mode 100644
index 00000000000..0ac1deb47ff
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/image3.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:b240ec929c3a1720ca6c0a65bd899efffb59398283e0f7bf2404ca6b9cdf7e06
+size 154571
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/image5.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/image5.png
new file mode 100644
index 00000000000..bc941d77f68
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/image5.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:ea69e7751e7f7acdc0bb053221d84763bbde6fde028529d6b8fb764ab53382b6
+size 148677
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/single-node.png b/advocacy_docs/edb-postgres-ai/cloud-service/images/single-node.png
new file mode 100644
index 00000000000..c6b26fa38e9
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/single-node.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:da37ddc038ed979acb7ec6a5ba284cd327ea4883679089b53232a75af5e79e60
+size 16928
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/images/single-node.svg b/advocacy_docs/edb-postgres-ai/cloud-service/images/single-node.svg
new file mode 100644
index 00000000000..99a818ca716
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/images/single-node.svg
@@ -0,0 +1,24 @@
+
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/index.mdx
index 4b8fb25a57b..5b9b6d1d42c 100644
--- a/advocacy_docs/edb-postgres-ai/cloud-service/index.mdx
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/index.mdx
@@ -3,16 +3,18 @@ title: EDB Postgres AI Cloud Service
navTitle: Cloud Service
description: An introduction to the EDB Postgres AI Cloud Service and its features.
navigation:
-- hosted
-- managed
-- deployment
+- getting_started
+- using_cluster
+- using_the_api
+- managing_your_cluster
+- security
+- references
+- release_notes
+- known_issues
+- support_services
---
-The EDB Postgres® AI Cloud Service, formerly known as [BigAnimal](/biganimal/latest/), is an evolution of the service to offer a holistic platform which offers hybrid data estate management, observability, analytics, and AI capabilities.
-
-!!! info
-EDB is currently updating the documentation to reflect the new EDB Postgres AI Cloud Service. Consult the [BigAnimal documentation](/biganimal/latest/) during the transition.
-!!!
+The EDB Postgres® AI Cloud Service is a holistic platform which includes hybrid data estate management, observability, analytics, and AI capabilities.
## Overview
@@ -26,6 +28,4 @@ Databases in the EDB Postgres AI Cloud Service can run on EDB's own cloud accoun
You get full visibility of the databases from the [EDB Postgres AI Console](../console), which is a web-based interface that provides a single pane of glass for managing your databases, monitoring performance, and accessing logs and metrics.
-The Console view isn't limited to managed or hosted database deployments. You can also deploy the databases yourself in your own cloud or on-premises, but still have them visible in your EDB Postgres AI Console as part of your [Estate](../console/estate) using the [Beacon Agent](../console/agent/).
-
-
+The Console view isn't limited to managed or hosted database deployments. You can also deploy the databases yourself in your own cloud or on-premises, but still have them visible in your EDB Postgres AI Console as part of your [Estate](../console/estate) using the [Beacon Agent](/edb-postgres-ai/console/estate/agent/).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/known_issues/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/known_issues/index.mdx
new file mode 100644
index 00000000000..9cc49fb75e3
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/known_issues/index.mdx
@@ -0,0 +1,9 @@
+---
+title: Known issues and limitations
+navTitle: Known issues
+description: Provides the list of Known issues and limitations in the current release of Cloud Service.
+---
+
+These known issues and/or limitations are in the current release of Cloud Service and the Postgres deployments it supports:
+
+* [Known issues with distributed high availability](known_issues_pgd)
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/known_issues/known_issues_pgd.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/known_issues/known_issues_pgd.mdx
new file mode 100644
index 00000000000..d70f45af445
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/known_issues/known_issues_pgd.mdx
@@ -0,0 +1,79 @@
+---
+title: Known issues with distributed high availability/PGD
+navTitle: Distributed high availability/PGD known issues
+deepToC: true
+redirects:
+- /biganimal/latest/known_issues/known_issues_dha/
+---
+
+These are currently known issues in EDB Postgres Distributed (PGD) on Cloud Service as deployed in distributed high availability clusters.
+These known issues are tracked in our ticketing system and are expected to be resolved in a future release.
+
+For general PGD known issues, refer to the [Known Issues](/pgd/latest/known_issues/) and [Limitations](/pgd/latest/planning/limitations/) in the PGD documentation.
+
+## Management/administration
+
+### Deleting a PGD data group may not fully reconcile
+
+When deleting a PGD data group, the target group resources is physically deleted, but in some cases we have observed that the PGD nodes may not be completely partitioned from the remaining PGD Groups.
+We recommend avoiding use of this feature until this is fixed and removed from the known issues list.
+
+### Adjusting PGD cluster architecture may not fully reconcile
+
+In rare cases, we have observed that changing the node architecture of an existing PGD cluster may not complete.
+If a change hasn't taken effect in 1 hour, reach out to Support.
+
+### PGD cluster may fail to create due to Azure SKU issue
+
+In some cases, although a regional quota check may have passed initially when the PGD cluster is created, it may fail if an SKU critical for the witness nodes is unavailable across three availability zones.
+To check for this issue at the time of a region quota check, run:
+
+```
+biganimal-csp-preflight --onboard -i d2s_v3 -x eha
+```
+
+If you have already encountered this issue, reach out to Azure support:
+
+```plaintext
+We're going to be provisioning a number of instances of in and need to be able to provision these instances in all AZs. Can you please ensure that subscription is able to provision this VM type in all AZs of . Thank you!
+```
+
+### Changing the default database name is not possible
+
+Currently, the default database for a replicated PGD cluster is `bdrdb`.
+This cannot be changed, either at initialization or after the cluster is created.
+
+## Replication
+
+### Replication speed is slow during a large data migration
+
+During a large data migration, when migrating to a PGD cluster, you may experience a replication rate of 20 MBps.
+
+### PGD leadership change on healthy cluster
+
+PGD clusters that are in a healthy state may experience a change in PGD node leadership, potentially resulting in failover.
+The client applications will need to reconnect when a leadership change occurs.
+
+### Extensions which require alternate roles are not supported
+
+Where an extension requires a role other than the default role (`bdr_application`) used for replication, it will fail when attempting to replicate.
+This is because PGD runs replication writer operations as a `SECURITY_RESTRICTED_OPERATION` to mitigate the risk of privilege escalation.
+Attempts to install such extensions may cause the cluster to fail to operate.
+
+## Migration
+
+### Connection interruption disrupts migration via Migration Toolkit
+
+When using Migration Toolkit (MTK), if the session is interrupted, the migration errors out. To resolve, you need to restart the migration from the beginning.
+The recommended path to avoid this is to migrate on a per-table basis when using MTK so that if this issue does occur, you retry the migration with a table rather than the whole database.
+
+### Ensure loaderCount is less than 1 in Migration ToolKit
+
+When using Migration Toolkit to migrate a PGD cluster, if you adjusted the loaderCount to be greater than 1 to speed up migration, you may see an error in the MTK CLI that says “pgsql_tmp/': No such file or directory.”
+If you see this, reduce your loaderCount to 1 in MTK.
+
+## Tools
+
+### Verify-settings command via PGD CLI provides false negative for PGD on Cloud Service clusters
+
+When used with PGD on Cloud Service clusters, the command verify-settings in the PGD CLI displays that a “node is unreachable.”
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managed.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managed.mdx
deleted file mode 100644
index dee14838140..00000000000
--- a/advocacy_docs/edb-postgres-ai/cloud-service/managed.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Managed Databases on EDB Postgres AI Cloud Service
-navTitle: Managed Databases
-description: EDB Postgres AI Cloud Service is able to manage an EDB Postgres database in your cloud.
----
-
-For many organizations, managing databases can be a complex and time-consuming task. The Managed option of the EDB Postgres AI Cloud Service provides a fully managed database service that allows you to focus on your applications and data, while EDB manages the database infrastructure. All you need to provide is the cloud account for EDB to deploy into.
-
-
-
-
-The advantage of the Managed option is that the database can deploy directly into your cloud infrastructure, so you have full control over the cloud account and the data. EDB manages the database infrastructure, including backups, monitoring, and updates, and provides a single pane of glass for managing your databases, monitoring performance, and accessing logs and metrics.
-
-
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/backup_and_restore.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/backup_and_restore.mdx
new file mode 100644
index 00000000000..bcedcc9e471
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/backup_and_restore.mdx
@@ -0,0 +1,79 @@
+---
+title: "Backing up and restoring"
+deepToC: true
+---
+
+## Backups
+
+Cloud Service provides two methods of backups:
+
+- Cloud Service backs up the data in your PostgreSQL clusters using Barman. You can change the retention period on the [**Backups** tab](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/#additional-settings-tab) when you create or edit your cluster. Depending on the cloud your cluster is deployed on, Cloud Service uses either of the following cloud object storage solutions.
+
+ | Cloud | Object storage solution |
+ | ------------ | ------------------------------------------------------------------------------------ |
+ | AWS | Amazon S3 (standard tier) |
+ | Azure | Azure Blob Storage (in the "hot" access tier with geo-zone-redundant storage (GZRS)) |
+ | Google Cloud | Cloud Storage |
+
+ Your organization is responsible for the charges associated with the cloud object storage solution.
+
+ You can change the retention period on the [**Additional Settings** tab](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/#additional-settings-tab) when you create or edit your cluster.
+- Volume snapshots are the snapshot backups stored on disk in the same region as your cluster. Volume snapshots represent a snapshot of a volume on a storage system. Volume snapshots are very fast as compared to the backups using Barman. You can opt for volume snapshots from [Additional Settings tab](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/#additional-settings-tab) while creating and editing a cluster. Once you enable the volume snapshots, it captures the snapshot of a volume.
+
+ Volume snapshots are:
+
+ - stored on the disk in the same region as the cluster. It may increase the storage costs as per your cloud service providers.
+ - supported on all the cluster types — single-node, high-availability clusters, and distributed high-availability clusters
+ - supported for both the environments — EDB Hosted Cloud Service and Your Own Account
+ - retained for 30 days
+ - restored to the same region as your cluster
+
+PostgreSQL clusters in Cloud Service are continuously backed up through a combination of base backups (backups using Barman and volume snapshots if enabled) and transaction log (WAL) archiving. When a new cluster is created, an initial "base" backup and a volume snapshot is taken. After that, every time a WAL file is closed, which is, by default, up to every 5 minutes, it's uploaded to the cloud object storage solution. If your cluster has faraway replicas, Cloud Service copies the WAL files from your cloud object storage solution and asynchronously transfers them to the faraway replicas. Your organization is responsible for the charges associated with the cloud object storage solution.
+
+## Replication lag with faraway replicas
+
+With faraway replicas, the primary server writes to the archive, which is moved to the object store. The replica reads from the object store as files arrive. Prior to the archive replicating across to the replica, the log file must write at least 16MB (the WAL segment size) of data to the WAL to cut a new archive file. If the time interval for closing a WAL file is too large, it can introduce a delay until the replica receives the latest record. The amount of time that it takes to fill up the 16MB log file and copy it to the archive is the replication lag. The replication lag is the period of time when data can be lost. It can be minutes or hours, depending on the amount of activity in your database. You need to measure the replication lag to determine if it's acceptable from a possible data-loss perspective. If it isn't acceptable, consider using a distributed high-availability cluster.
+
+To determine the replication lag, you can compare the last log sequence number (LSN) in the 16MB log file on the primary to the LSN in the log file in the replica.
+
+## Restores
+
+If a restore is necessary—for example, in case of an accidental `DROP TABLE` statement—you can restore clusters to any point in the backup retention period.
+
+Cluster restores aren't performed in place on an existing cluster. Instead, a new cluster is created and initialized with data from the backup archive. Restores must replay the transaction logs between the most recent full database backup and the target restore point. Thus restore times (that is, RTO) depend on the write activity in the source cluster.
+
+By default, Cloud Service retains backups for 30 days for both types of backups.
+
+You can restore base backups into a new cluster in any region supported by Cloud Service. However, you can restore the volume snapshots into a new cluster only in the same region.
+
+### Perform a cluster restore
+
+The restore operation is available for any cluster that has at least one available backup. For newly created clusters, the initial backup becomes available a few minutes after the new cluster is fully operational.
+
+#### Restore a single-node or primary/standby high-availability cluster
+
+1. Select the cluster you want to restore on the [Clusters](https://portal.biganimal.com/clusters) page in the [Console](https://portal.biganimal.com).
+2. From **Quick Actions**, select **Restore**.
+3. On the Restore Cluster page:
+ 1. Fill in the required fields.
+ 2. In the **Cluster settings** tab, go to the **Source** section.
+ 3. To restore to the last possible recovery point, in the **Point in Time Restore** field, select **Now**. Or, to restore further back in time, choose a timestamp.
+ 4. Review your selections in **Cluster Summary** and select **Restore Cluster** to begin the restore process.
+ - If you opted for volume snapshots and you're restoring the cluster in the same region as your source cluster, Cloud Service chooses volume snapshots for restoration over Barman object store backups.
+ - If you opted for volume snapshots and you're restoring the cluster in a different region from your source cluster, Cloud Service chooses the Barman object store backup for restoration over volume snapshots.
+4. The new cluster is now available on the [Clusters](https://portal.biganimal.com/clusters) page.
+
+#### Restore a distributed high-availability cluster
+
+1. On the [Clusters](https://portal.biganimal.com/clusters) page in the [Console](https://portal.biganimal.com), select the cluster you want to restore.
+2. Select **Quick Actions > Restore**.
+3. In the **Cluster Settings** tab, enter a cluster name and password for your restored cluster.
+4. Select **Next: Data Group**.
+5. Select the **Node Settings** tab.
+6. In the **Source** section, select **Fully Restore** or **Point in Time Restore**. A point-in-time restore restores the data group as it was at the specified date and time.
+7. In the **Nodes** section, select **Two Data Nodes** or **Three Data Nodes**. For more information on node architecture, see [Distributed high availability](/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability/).
+8. Follow the steps for [Creating a distributed high-availability cluster](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_dha_cluster/).
+9. Select **Restore**.
+ - If you opted for volume snapshots and you're restoring the cluster in the same region as your source cluster, then Cloud Service chooses volume snapshots for restore over base backups.
+ - If you opted for valume snapshates and you're restoring the cluster in the different region from your source cluster, then Cloud Service chooses the base backup for restore over volume snapshots.
+10. The new cluster is now available on the [Clusters](https://portal.biganimal.com/clusters) page.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/deleting_your_cluster.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/deleting_your_cluster.mdx
new file mode 100644
index 00000000000..ecbc8cdaa38
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/deleting_your_cluster.mdx
@@ -0,0 +1,38 @@
+---
+title: "Deleting your cluster"
+---
+
+If you no longer need a particular cluster, you can delete it from the Console. You can restore deleted clusters after you delete the cluster for as long as the backup is available. The backup remains available for the retention period set for each cluster. After the retention period, the backup is deleted.
+
+To stop the management costs on the cluster, contact EDB's Cloud Service Support team, Otherwise, costs might continue to accumulate.
+
+## Delete your cluster
+
+!!!Important
+
+You can delete a cluster only if you have either promoted or deleted each of its faraway replicas. See [Faraway replicas](/edb-postgres-ai/cloud-service/references/supported_cluster_types/faraway_replicas/).
+!!!
+
+1. Go to the [Clusters](https://portal.biganimal.com/clusters) page in the [Console](https://portal.biganimal.com).
+2. To delete the cluster, do one of the following:
+ - Select the **Delete cluster** icon in the row for the cluster.
+ - Select the cluster you want to delete. From **Quick Actions** on the cluster details page, select **Delete**.
+3. Confirm that you want to delete the cluster. When the process finishes, the cluster is listed on the **Deleted** tab of the Clusters page.
+4. To stop the associated management costs, contact [Support](/edb-postgres-ai/cloud-service/support_services/). For more information on management costs, see [Pricing and billing](/biganimal/release/pricing_and_billing/#management-costs).
+
+## Restore your cluster
+
+You can restore your deleted cluster for as long as the backup is available.
+
+1. Select the **Delete** tab on the [Clusters](https://portal.biganimal.com/clusters) page in the [Console](https://portal.biganimal.com).
+2. Select the **Restore** icon for the cluster you want to restore.
+3. On the Restore Cluster page, review your selections in the **Cluster Summary**. Select **Restore Cluster** to begin the restore process.
+
+ When the process completes, the restored cluster is available on the [Clusters](https://portal.biganimal.com/clusters) page.
+
+!!!note
+
+To restore a TDE-enabled cluster, the TDE key material must match the source cluster encryption key material. If a different key material is used, the restore operation will fail.
+
+EDB does not support enabling TDE when restoring a non-TDE cluster.
+!!!
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/index.mdx
new file mode 100644
index 00000000000..15d3ea83626
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/index.mdx
@@ -0,0 +1,12 @@
+---
+title: Managing your cluster
+description: Describes the management tasks for your cluster on the Cloud Service.
+navigation:
+- modifying_your_cluster
+- managing_cluster
+- upgrading_your_cluster
+- migration
+- backup_and_restore
+- deleting_your_cluster
+- periodic_maintenance
+---
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/managing_cluster.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/managing_cluster.mdx
new file mode 100644
index 00000000000..fa54dc0ae4d
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/managing_cluster.mdx
@@ -0,0 +1,43 @@
+---
+title: "Pausing and resuming a cluster"
+description: Describes options for managing clusters
+---
+
+## Pausing and resuming clusters
+
+Pausing a cluster allows you to save on compute costs without losing data or cluster configuration settings. There's no added cost for paused clusters, although you must still pay for any disk and object storage that the paused cluster requires.
+
+Pausing a cluster drops all existing connections, blocks future actions such as editing the cluster, and stops monitoring. While the cluster is paused, you can't make or maintain connections or read, write, or edit cluster settings. Automatic backups are paused. However, backups taken while the cluster was running remain until their retention period expires.
+
+!!! Note
+
+ If you defined the backup retention period for a cluster to be less that the duration of the pause, it's possible for write-ahead logs (WALs) to be deleted from the backup object store, and resumption might fail.
+
+While paused, clusters aren't upgraded or patched, but upgrades are applied when the cluster resumes. Pausing a high availability or Postgres Distributed cluster shuts down all cluster nodes.
+
+After seven days, single-node and high-availability clusters automatically resume. Resuming a cluster applies any pending maintenance upgrades. Monitoring begins again.
+
+With CLI 3.7.0 and later, you can [pause and resume a cluster using the CLI](/edb-postgres-ai/cloud-service/using_cluster/cli/managing_clusters/#pause-a-cluster).
+
+You can enable in-app inbox or email notifications to get alerted when the paused cluster is or will be reactivated. For more information, see [managing notifications](/edb-postgres-ai/console/using/notifications/#managing-notifications).
+
+### Pausing a cluster
+
+1. Go to the [Clusters](https://portal.biganimal.com/clusters) page in the [Console](https://portal.biganimal.com).
+2. Do one of the following:
+ - In the row for the cluster, at right, from the ellipsis menu, select **Pause Cluster**.
+ - Select the cluster you want to pause. From **Quick Actions** on the cluster details page, select **Pause Cluster**.
+3. Confirm that you want to pause the cluster. When the process finishes, the cluster status appears as Paused. It can take up to 15 minutes for the compute instance in your CSP to scale down.
+
+### Resuming a cluster
+
+1. Go to the [Clusters](https://portal.biganimal.com/clusters) page in the [Console](https://portal.biganimal.com).
+2. Do one of the following:
+ - In the row for the cluster, at right, from the ellipsis menu, select **Resume Cluster**.
+ - Select the cluster you want to resume. From **Quick Actions** on the cluster details page, select **Resume Cluster**.
+3. Confirm that you want to resume the cluster. The process might take a few minutes. When it finishes, the cluster status appears as Healthy.
+
+!!!note
+
+A TDE-enabled cluster resumes only if the TDE key status is ready or available. Clusters are automatically paused if there is any issue with the TDE key. You need to resolve/give permissions to the key in your respective cloud region. Resume the cluster manually after resolving the issues.
+!!!
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/cold_migration.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/cold_migration.mdx
new file mode 100644
index 00000000000..6dcd5995ba1
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/cold_migration.mdx
@@ -0,0 +1,186 @@
+---
+title: Importing an existing Postgres database
+---
+
+The simplest way to import a database into Cloud Service is using logical backups taken with `pg_dump` and loaded using `pg_restore`. This approach provides a way to export and import a database across different versions of Postgres, including exporting from PostgreSQL and EDB Postgres Advanced Server versions prior to 10.
+
+The high-level steps are:
+
+1. [Export existing roles](#export-existing-roles).
+2. [Import existing roles](#import-the-roles).
+3. For each database, you are migrating:
+ 1. [logical export using `pg_dump`](#export-a-database)
+ 2. [logical import with `pg_restore`](#import-a-database)
+
+In case your source PostgreSQL instance hosts multiple databases, you can segment them in multiple Cloud Service clusters for easier management, better performance, increased predictability, and finer control of resources. For example, if your host has 10 databases, you can import one database and related users on a different Cloud Service cluster, one at a time.
+
+## Downtime considerations
+
+This approach requires suspending write operations to the database application for the duration of the export/import process. You can then resume the write operations on the new system. This is because `pg_dump` takes an online snapshot of the source database. As a result, the changes after the backup starts aren't included in the output.
+
+The required downtime depends on many factors, including:
+
+- Size of the database
+- Speed of the network between the two systems
+- Your team's familiarity with the migration procedure
+
+To minimize the downtime, you can test the process as many times as needed before the actual migration. You can perform the export with `pg_dump` online, and the process is repeatable and measurable.
+
+## Before you begin
+
+Make sure that you:
+
+- Understand the [terminology conventions](#terminology-conventions).
+- Have the [required Postgres client binaries and libraries](#postgres-client-libraries).
+- Can [access the source and target databases](#access-to-the-source-and-target-database).
+
+### Terminology conventions
+
+| Term | Alias | Description |
+| --------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| source database | `pg-source` | Postgres instance from which you want to import your data. |
+| target database | `pg-target` | Postgres cluster in Cloud Service where you want to import your data. |
+| migration host | `pg-migration` | Temporary Linux machine in your trusted network from which to execute the export of the database and the subsequent import into Cloud Service. The migration host needs access to both the source and target databases. Or, if your source and target databases are on the same version of Postgres, the source host can serve as your migration host. |
+
+### Postgres client libraries
+
+The following client binaries must be on the migration host:
+
+- `pg_dumpall`
+- `pg_dump`
+- `pg_restore`
+- `psql`
+
+They must be the same version as the Postgres version of the target database. For example, if you want to import a PostgreSQL 10 database from your private network into a PostgreSQL 14 database in Cloud Service, use the client libraries and binaries from version 14.
+
+### Access to the source and target database
+
+Access requirements:
+
+- PostgreSQL superuser access to the source database. This can be the postgres user or another user with superuser privileges.
+- Access to the target database in Cloud Service as the edb_admin user.
+
+#### Verify your access
+
+1. Connect to the source database using `psql`. For example:
+ ```shell
+ psql -d "host= user=postgres dbname=postgres"
+ ```
+ Replace `` with the actual hostname or IP address of the source database and the `user` and `dbname` values as appropriate. If the connection doesn't work, contact your system and database administrators to make sure that you can access the source database. This might require changes to your `pg_hba.conf` and network settings. If `pg_hba.conf` changes, reload the configuration with either `SELECT pg_reload_conf();` using a psql connection or `pg_ctl reload` in a shell connection to the database host.
+
+2. Connect to the target database using the edb_admin user. For example:
+ ```shell
+ psql -d "host= user=edb_admin dbname=edb_admin"
+ ```
+ Replace `` with the actual hostname of your Cloud Service cluster.
+
+## Export existing roles
+
+Export the existing roles from your source Postgres instance by running the following command on the migration host:
+
+```shell
+pg_dumpall -r -d "host=pg-source user=postgres dbname=postgres" > roles.sql
+```
+
+The generated SQL file looks like this:
+
+```sql
+--
+-- PostgreSQL database cluster dump
+--
+
+SET default_transaction_read_only = off;
+
+SET client_encoding = 'UTF8';
+SET standard_conforming_strings = on;
+
+--
+-- Roles
+--
+
+--- … Your roles are here ...
+
+--
+-- PostgreSQL database cluster dump complete
+--
+```
+
+## Import the roles
+
+1. Your Cloud Service cluster already contains the `edb_admin` user, as well as the following-system required roles:
+
+- `postgres` — The superuser, needed by Cloud Service to manage the cluster.
+- `streaming_replica` — Required to manage streaming replication.
+
+ As a result, you need to modify the `roles.sql` file to:
+
+1. Remove the lines involving the postgres user. For example, remove lines like these:
+ ```sql
+ CREATE ROLE postgres;
+ ALTER ROLE postgres WITH SUPERUSER ….;
+ ```
+2. Remove any role with superuser or replication privileges. For example, remove lines like these:
+ ```sql
+ CREATE ROLE admin;
+ ALTER ROLE admin WITH SUPERUSER ….;
+ ```
+3. For every role that's created, grant the new role to the edb_admin user immediately after creating the user. For example:
+ ```sql
+ CREATE ROLE my_role;
+ GRANT my_role TO edb_admin;
+ ```
+4. Remove the `NOSUPERUSER`, `NOCREATEROLE`, `NOCREATEDB`, `NOREPLICATION`, `NOBYPASSRLS` permission attributes on the other users.
+
+ The role section in the modified file, then, looks similar to:
+
+ ```sql
+ CREATE ROLE my_role;
+ GRANT my_role TO edb_admin;
+ ALTER ROLE my_role WITH INHERIT LOGIN PASSWORD 'SCRAM-SHA-256$4096:my-Scrambled-Password';
+ ```
+5. From the migration host, execute:
+
+ ```shell
+ psql -1 -f roles.sql -d "postgres://edb_admin@:5432/edb_admin?sslmode=verify-full"
+ ```
+
+ Replace `` with the fully qualified domain name (FQDN) of your Cloud Service cluster.
+
+ This command tries to create the roles in a single transaction. In case of errors, the transaction is rolled back, leaving the database cluster in the same state as before the import attempt. Enforce this behavior using the `-1` option of `psql`.
+
+## Export a database
+
+From the migration host, use the `pg_dump` command to export the source database into the target database in Cloud Service. For example:
+
+```shell
+pg_dump -Fc -d "host=pg-source user=postgres dbname=app" -f app.dump
+```
+
+!!! Note
+ You can use the `--verbose` option to monitor the progress of the operation.
+
+The command generates a custom `.dump` archive (`app.dump` in this example), which contains the compressed dump of the source database. How long it takes the command to execute varies depending on several variables, including size of the database, network speed, disk speed, and CPU of both the source instance and the migration host. You can inspect the table of contents of the dump with `pg_restore -l .dump`.
+
+As with any other custom format dump produced with `pg_dump`, you can take advantage of the features that `pg_restore` provides you with, including:
+
+- Selecting a subset of the import tasks by editing the table of contents and passing it to the `-L` option.
+- Running the command in parallel using the `-j` option with the directory format.
+
+For more information, see the [`pg_restore` documentation](https://www.postgresql.org/docs/current/app-pgrestore.html).
+
+## Import a database
+
+Use the `pg_restore` command and the `.dump` file you created when exporting the source database to import the database into Cloud Service. For example:
+
+```shell
+pg_restore -C -d "postgres://edb_admin@pg-target:5432/edb_admin?sslmode=verify-full" app.dump
+```
+
+This process might take some time depending on the size of the database and the speed of the network.
+
+In case of error, repeat the restore operation after you delete the database using the following command:
+
+```shell
+psql -d "postgres://edb_admin@pg-target:5432/edb_admin?sslmode=verify-full" \
+ -c ‘DROP DATABASE app’
+```
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/dha_bulk_migration.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/dha_bulk_migration.mdx
new file mode 100644
index 00000000000..4c2af8946b9
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/dha_bulk_migration.mdx
@@ -0,0 +1,483 @@
+---
+title: Bulk loading data into PGD clusters
+navTITLE: Bulk loading into PGD clusters
+description: This guidance is specifically for environments where there's no direct access to the PGD nodes, only PGD Proxy endpoints, such as Cloud Service's distributed high availability deployments of PGD.
+deepToC: true
+---
+
+## Bulk loading data into PGD clusters
+
+**This guidance is specifically for environments where there's no direct access to the PGD nodes, only PGD Proxy endpoints, such as Cloud Service's distributed high availability deployments of PGD.**
+
+Without using care, bulk loading data into a PGD cluster can cause a lot of replication load on a cluster. With that in mind, this content describes a process to mitigate that replication load.
+
+## Provision or prepare a PGD cluster
+
+You must provision a PGD cluster, either manually, using TPA, or on Cloud Service. This will be the target database for the migration. Ensure that you provision it with sufficient storage capacity to hold the migrated data.
+
+We recommend that, when provisioning or, if needed, after provisioning, you set the following Postgres GUC variables.
+
+| GUC variable | Setting |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| maintenance_work_mem | 1GB |
+| wal_sender_timeout | 60min |
+| wal_receiver_timeout | 60min |
+| max_wal_size | Set to either: -p -U >> predatadump.log
+```
+
+Consult `predatadump.log` to ensure that the dump was successful. If it fails, you can repeat the dump after resolving the issue.
+
+Once the pre-data is dumped into the predata directory, you can load it into the target cluster using `pg_restore`:
+
+```shell
+pg_restore -Fd --section=pre-data -d "host=ab-node-1-host dbname= user= options='-cbdr.ddl_locking=off -cbdr.commit_scope=local'" predata >> predatarestore.log
+```
+
+The `options=` section in the connection string to the server is important. The options disable DDL locking and set the commit scope to `local`, overriding any default commit scopes. Using `--section=pre-data` limits the restore to the configuration that precedes the data in the dump.
+
+Consult `predatarestore.log` to ensure that the restore was successful. If it fails, you can repeat the restore after resolving the issue.
+
+### Transferring role definitions
+
+Use the pg_dumpall utility to dump the role definitions from the source database:
+
+```shell
+pg_dumpall -r -h -p -U > roles.sql >> rolesdump.log
+```
+
+Consult `rolesdump.log` to ensure that the dump was successful. If it fails, you can repeat the dump after resolving the issue.
+
+Then load the role definitions into the target cluster:
+
+```shell
+psql -h -p -U -d bdrdb -f roles.sql >> rolesrestore.log
+```
+
+Consult `rolesrestore.log` to ensure that the restore was successful. If it fails, you can repeat the restore after resolving the issue.
+
+### Transferring the data
+
+In this step, Migration Toolkit is used to transfer the table data between the source and target.
+
+Edit `/usr/edb/migrationtoolkit/etc/toolkit.properties`. You need to use sudo to raise your privilege to do this, that is, `sudo vi /usr/edb/migrationtoolkit/etc/toolkit.properties`.
+
+```
+SRC_DB_URL=jdbc:postgresql://:/
+SRC_DB_USER=
+SRC_DB_PASSWORD=
+
+TARGET_DB_URL=jdbc:postgresql://:/
+TARGET_DB_USER=
+TARGET_DB_PASSWORD=
+```
+
+Edit the relevant values in the settings.
+
+Ensure that the configuration file is owned by the user you intend to run the data transfer as and read-write only for its owner.
+
+Now, select sets of tables in the source database that must be transferred together, ideally grouping them for redundancy in case of failure:
+
+```shell
+nohup /usr/edb/migrationtoolkit/bin/runMTK.sh -sourcedbtype postgres -targetdbtype postgres -loaderCount 1 -tableLoaderLimit 1 -fetchSize 4000 -parallelLoadRowLimit 1000 -truncLoad -dataOnly -tables ,,... > mtk.log >>mtkerr.log
+```
+
+This command uses the `-truncLoad` option and drops indexes and constraints before the data is loaded. It then recreates them after the loading has completed.
+
+You can run multiple instances of this command in parallel. To do so, add an `&` to the end of the command. Ensure that you write the output from each to different files (for example, `mtk_1.log`, `mtk_2.log`).
+
+For example:
+
+```shell
+nohup /usr/edb/migrationtoolkit/bin/runMTK.sh -sourcedbtype postgres -targetdbtype postgres -loaderCount 1 -tableLoaderLimit 1 -fetchSize 4000 -parallelLoadRowLimit 1000 -truncLoad -dataOnly -tables warehouse,district,item,new_order,orders,history public >mtk_1.log >>mtkerr_1.log &
+
+nohup /usr/edb/migrationtoolkit/bin/runMTK.sh -sourcedbtype postgres -targetdbtype postgres -loaderCount 1 -tableLoaderLimit 1 -fetchSize 4000 -parallelLoadRowLimit 1000 -truncLoad -dataOnly -tables customer public >mtk_2.log >>mtkerr_2.log&
+
+nohup /usr/edb/migrationtoolkit/bin/runMTK.sh -sourcedbtype postgres -targetdbtype postgres -loaderCount 1 -tableLoaderLimit 1 -fetchSize 4000 -parallelLoadRowLimit 1000 -truncLoad -dataOnly -tables order_line public >mtk_3.log >>mtkerr_3.log &
+
+nohup /usr/edb/migrationtoolkit/bin/runMTK.sh -sourcedbtype postgres -targetdbtype postgres -loaderCount 1 -tableLoaderLimit 1 -fetchSize 4000 -parallelLoadRowLimit 1000 -truncLoad -dataOnly -tables stock public >mtk_4.log >>mtkerr_4.log &
+```
+
+This sets up four processes, each transferring a particular table or sets of tables as a background process.
+
+While this is running, monitor the lag. Log into the destination node with psql, and monitor lag with:
+
+```sql
+SELECT NOW(); SELECT pg_size_pretty( pg_database_size('bdrdb') ); SELECT * FROM bdr.node_replication_rates;
+```
+
+Once the lag is consumed, return to the shell. You can now use `tail` to monitor the progress of the data transfer by following the log files of each process:
+
+```shell
+tail -f mtk_1.log mtk_2.log mtk_3.log mtk_4.log
+```
+
+You can also consult the error logs (`mtkerr_1.log`, `mtkerr_2.log`, `mtkerr_3.log`, `mtkerr_4.log`) to troubleshoot any issues that arise.
+
+### Transferring the post-data
+
+Make sure there's no replication lag across the entire cluster before proceeding with post-data.
+
+Now dump the post-data section of the source database:
+
+```shell
+pg_dump -Fd -f postdata --section=post-data -h -p -U
+```
+
+Then load the post-data section into the target database:
+
+```shell
+pg_restore -Fd -d "host=ab-node-1-host dbname= user= options='-cbdr.ddl_locking=off -cbdr.commit_scope=local'" --section=post-data postdata
+```
+
+If this step fails due to a disconnection, return to monitoring lag (as described previously). Then, when no synchronization lag is present, repeat the restore.
+
+## Resume the cluster
+
+### Remove the routing fences you set up earlier on the other nodes
+
+Connect directly to the destination node using psql. Use `bdr.alter_node_option` and turn off the `route_fence` option for each node in the group except for the destination node, which is already off:
+
+```sql
+select bdr.alter_node_option('ab-node-2','route_fence','f');
+select bdr.alter_node_option('ab-node-3','route_fence','f');
+```
+
+Proxies can now route to all the nodes in the group.
+
+### Reset commit scopes
+
+You can now restore the default commit scopes to the cluster to allow PGD to manage the replication load. Set `default_commit_scope` for the groups to the value for [the groups that you recorded in an earlier step](#record-then-clear-default-commit-scopes).
+
+```sql
+select bdr.alter_node_group_option('ab-group','default_commit_scope', 'ba001_ab-group-a');
+```
+
+The cluster is now loaded and ready for production. For more assurance, you can run the `pgd -f pgd-cli-config.yml check-health` command to check the overall health of the cluster and the other PGD commands from when you checked the cluster earlier.
+
+## Verify the data migration
+
+Use LiveCompare to compare the source and target databases. Create a configuration file for LiveCompare:
+
+```ini
+[General Settings]
+logical_replication_mode = off
+difference_tie_breakers = first
+
+[First Connection]
+dsn = host= port= dbname= user=
+
+[Second Connection]
+dsn = host= port= dbname= user=
+
+[Output Connection]
+dsn = host= port= dbname= user=
+```
+
+Save this configuration file as `migrationcheck.ini`. Update the `[First Connection]` and `[Second Connection]` sections with the appropriate values, with the `[First Connection]` section pointing to the source database and the `[Second Connection]` section pointing to the target database. The `[Output Connection]` section defines a database where a `livecompare` schema will be created to store the comparison results.
+
+Run LiveCompare using the configuration file you created:
+
+```shell
+livecompare migrationcheck.ini --compare
+```
+
+LiveCompare compares the source and target databases and generates a report of the differences.
+Review the report to ensure that the data migration was successful.
+
+Refer to the [LiveCompare](/livecompare/latest/) documentation for more information on using LiveCompare.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/index.mdx
new file mode 100644
index 00000000000..1582539d512
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/migration/index.mdx
@@ -0,0 +1,35 @@
+---
+title: Migrating databases to Cloud Service
+---
+
+EDB provides migration tools to bring data from Oracle, PostgresSQL, and EDB Postgres Advanced Server databases into Cloud Service. These tools include Migration Portal and Migration Toolkit for Oracle migrations. More sophisticated migration processes can use tools such as [Replication Server](/eprs/latest/) for ongoing migrations and [LiveCompare](/livecompare/latest/) for data comparisons.
+
+## Migrating from Oracle
+
+For helpful considerations and information when migrating from Oracle, review the EDB [Migration Handbook](/migrating/oracle/).
+
+EDB also provides a tool, [Migration Portal](/migration_portal/latest), which provides the details for executing the migration steps:
+
+1. [Schema extraction](/migration_portal/latest/04_mp_migrating_database/01_mp_schema_extraction/)
+2. [Schema assessment](/migration_portal/latest/04_mp_migrating_database/02_mp_schema_assessment/)
+3. [Schema migration](/migration_portal/latest/04_mp_migrating_database/03_mp_schema_migration/)
+4. [Data migration](/migration_portal/latest/04_mp_migrating_database/04_mp_data_migration/)
+
+You can also use the [Migration Toolkit](/migration_toolkit/latest/) for the data migration step. This toolkit is a good option for smaller databases.
+
+## Accessing remote Oracle servers from Cloud Service
+
+Cloud Service supports the [edb_dblink_oci](/epas/latest/reference/oracle_compatibility_reference/epas_compat_sql/21_create_public_database_link/) extension and a set of [dblink_ora](/epas/latest/working_with_oracle_data/06_dblink_ora/) functions, which you can use to create Oracle syntax-compatible database links and include calls to functions that are only available in Oracle, respectively.
+
+See the following Cloud Service knowlege base articles for step-by-step instructions for creating links to remote Oracle servers from EDB Postgres Advanced Server clusters:
+
+- [Using edb_dblink_oci](https://support.biganimal.com/hc/en-us/articles/5528996025497-How-to-create-a-database-link-from-EnterpriseDB-PostgreSQL-Advanced-Server-EPAS-cluster-to-remote-Oracle-server)
+- [Using dblink_ora_connect()](https://support.biganimal.com/hc/en-us/articles/11737021242649-How-to-establish-a-database-link-from-EPAS-cluster-to-a-remote-Oracle-server-using-dblink-ora-connect-function)
+
+## Migrating from Postgres
+
+Several options are available for migrating EDB Postgres Advanced Server and PostgreSQL databases to Cloud Service. One option is to use the Migration Toolkit. Another simple option for many use cases is to import an existing PostgreSQL or EDB Postgres Advanced Server database to Cloud Service. See [Importing an existing Postgres database](cold_migration).
+
+## Migrating to distributed high availability clusters
+
+When migrating to a PGD-powered distributed high availability (DHA) cluster, we recommend that you follow the instructions in [DHA/PGD bulk migration](dha_bulk_migration). This content provides a step-by-step process for migrating your data to a DHA cluster while minimizing the impact of subsequent replication on the process.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/05_db_configuration_parameters.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/05_db_configuration_parameters.mdx
new file mode 100644
index 00000000000..ff05ae81198
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/05_db_configuration_parameters.mdx
@@ -0,0 +1,103 @@
+---
+title: Modifying database configuration parameters
+---
+
+The database parameters listed on the **DB Configuration** tab are also referred to as Grand Unified Configuration (GUC) variables. See [What Is a GUC Variable?](https://www.enterprisedb.com/blog/what-guc-variable) for more information.
+
+The list of parameters is populated based on the type of database you selected on the **Operational Settings** tab when you created your cluster. For more information about the parameters for your database type:
+
+- For PostgreSQL parameters, see [Setting Parameters](https://www.postgresql.org/docs/current/config-setting.html) and [Server Configuration](https://www.postgresql.org/docs/current/runtime-config.html) in the Postgres documentation.
+
+
+- For EDB Postgres Advanced Server, see [Summary of configuration parameters](/epas/latest/reference/database_administrator_reference/02_summary_of_configuration_parameters/) and [Configuration parameters](/epas/latest/database_administration/01_configuration_parameters/).
+
+- For more information on the types of values parameters accept, see [Parameter Names and Values](https://www.postgresql.org/docs/current/config-setting.html#CONFIG-SETTING-NAMES-VALUES). The types apply to both PostgreSQL and EDB Postgres Advanced Server parameters.
+
+
+!!!note
+Not all database configuration parameters are supported by Cloud Service. Some parameters, such as `wal_level` and `restore_command`, are reserved for EDB to provide the managed database features of Cloud Service.
+!!!
+
+## Using formulas for parameter values
+
+In addition to entering specific values for parameters, for some parameters you can specify formulas to calculate a value. You can use formulas for parameters of type integer and real in ternary formulas, such as the [shared buffer example](#examples), using the following operators: `+ - / * > >= < <= == != && || ! ? : ( )`. Use `?` and `:` . Use `( )` to specify [order of operations](#order-of-operations), if needed. GUCs used in formulas must also be of type integer or real. All arithmetic is done on 64-bit floating point values rounded to an integer result if the target GUC is of type integer and not real.
+
+BigAnimal has what we refer to as *psuedo GUCs* to help with creating equations. These read-only GUCs are:
+- `cpu_cores` — Number of cores provided by the VM running the cluster nodes.
+- `disk_iops` — Number of IOPS allocated to the disks backing the primary data volume.
+- `disk_size` — Amount of memory backing the primary data volume, in KB.
+- `ram` — Amount of memory provided by the VM running the cluster nodes, in KB.
+- `replica_count` — Total number of nodes in the cluster.
+
+Formulas can calculate a value relative to the specifications you selected for the cluster or relative to other non-pseudo GUCs. If you resize your cluster, BigAnimal recalculates formulas using the new values for the pseudo GUCs.
+
+### Order of operations
+`*` and `/` are at the same operator precedence. `+` and `-` are at the same operator precedence. `*` and `/` are evaluated before `+` and `-`. Use parentheses to specify additional order of operations.
+
+### Units
+GUCs can either be a bare number, such as 8, or have a unit, such as GB. Units are categorized into kinds of units, such as size or duration.
+
+The kind of unit of the target GUC must match the kind of unit used in the formula. For example, you can't use a formula that tries to multiply two seconds with three kilobytes (`2s * 3KB`), but you can use a formula that multiplies two sizes even if they have different scales (`2KB * 8GB`).
+
+The unit of the target GUC must match the unit used in the formula. For example, you can multiply two seconds by four days but you can't assign the result to a GUC of unit KB.
+
+If a target GUC has a unit, a bare number in an equation is assumed to be in the default unit for the target GUC.
+
+### Recursion
+We recommend no more than approximately 100 levels of recursion depth.
+
+### Examples
+
+Instead of entering a specific value for the `shared_buffers` parameter, with GUC equations you can specify that the value for `shared_buffers` is a certain percentage of RAM but no higher than a certain size. For example:
+
+`((ram * 0.25) > 8 GB) ? 8 GB : (ram * 0.25)`
+
+What if you want `wal_buffers` to be 3% of `shared_buffers`, up to a maximum of 16MB? The formula is:
+
+`((shared_buffers * 0.03) > 16MB) ? 16MB : (shared_buffers * 0.03)`
+
+The formula refers to the `shared_buffers`, which, in turn, has its own formula in this example. This example shows how GUCs can refer to other GUCs.
+
+### Common errors and error handling
+
+Malformed formulas result in an error. Here are some examples:
+
+- Following a number with two units, for example:
+
+ `work_mem = 10 GB kB`
+
+ This syntax gives the error:
+
+ `unexpected token "kB" at end of input (line 1, col 7)`
+
+- Creating an infinite evaluation loop by having a GUC referring to itself, for example:
+
+ `effective_cache_size = effective_cache_size`
+
+ This syntax gives the error:
+
+ `cycle in equation; GUC "effective_cache_size" already seen`
+
+- Mixing unit types, for example:
+
+ `work_mem = 10kB * 8s`
+
+ This syntax gives the error:
+
+ `both size and time units used in calculation; cannot proceed`
+
+## Modify a parameter
+
+1. Go to the parameter you want to modify using these methods:
+ - To search for a specific parameter, use the search field.
+ - To filter the parameters that show, select one of the following in the **Show only** list:
+ - **Custom Values** — Shows only parameters that changed from the default values, either in the current session or modified in a previous session and applied to the cluster.
+ - **Currently Edited Values** — Shows only parameters that changed during the current editing session.
+
+2. Enter the new value in the parameter value field.
+
+ !!! Danger
+ Parameters identified with a yellow exclamation point icon trigger a restart when you save your changes. The restart terminates all open connections and takes a few minutes to complete. It takes a few more seconds for the new connection to establish. During this process, it isn't possible to connect to the database.
+ !!!
+
+3. Save your changes.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/images/restart_icon.png b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/images/restart_icon.png
new file mode 100644
index 00000000000..6822c1272af
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/images/restart_icon.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:b96a439b94b1de8eb42500a708387f7f527ddf23a6631590a972e68ee1757a86
+size 1495
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/index.mdx
new file mode 100644
index 00000000000..3c2d1975cca
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/modifying_your_cluster/index.mdx
@@ -0,0 +1,64 @@
+---
+title: Modifying your cluster
+# Added this redirect because we removed the Modify and Scale topic
+redirects:
+ - ../03_modify_and_scale_cluster
+---
+
+You can modify your cluster by modifying its [configuration settings](#modify-your-clusters-configuration-settings).
+
+You can also modify your cluster by installing Postgres extensions. See [Postgres extensions](/edb-postgres-ai/cloud-service/references/supported_extension_tools/) for more information.
+
+## Modify your cluster's configuration settings
+
+1. Sign in to the [Console](https://portal.biganimal.com).
+
+2. From the [Clusters](https://portal.biganimal.com/clusters) page, select the name of the cluster you want to edit.
+
+3. From the top-right corner of the **Cluster Info** panel, select **Edit Cluster**.
+
+4. You can modify the following settings on the corresponding tab of the Edit Cluster page.
+
+ !!! Note
+
+ Any changes made to the cluster's instance type, volume type, or volume properties aren't automatically applied to replica settings. To avoid lag during replication, ensure that replica instance and storage types are at least as large as the source cluster's instance and storage types. See [Modify a faraway replica](/edb-postgres-ai/cloud-service/using_cluster/faraway_replicas/#modify-a-replica).
+
+ | Settings | Tab | Notes |
+ | ---------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | Cluster type | **Cluster Info** | You can't switch from a single-node cluster or a high-availability cluster to a distributed high-availability cluster or vice versa. |
+ | Number of replicas (for a high-availability cluster) | **Cluster Info** | — |
+ | Cluster name and password | **Cluster Settings** | — |
+ | Instance type | **Cluster Settings** | Changing the instance type can incur higher cloud infrastructure charges. |
+ | Volume type | **Cluster Settings** | You can't switch between the io2 and io2 Block Express volume types in an AWS cluster. |
+ | Volume properties | **Cluster Settings** | It can take up to six hours to tune IOPS or resize the disks of your cluster because AWS requires a cooldown period after volume modifications, as explained in [Limitations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-volume-requirements.html). The volume properties are disabled and can't be modified while this is in progress. |
+ | Networking type (public or private) | **Cluster Settings** | If you're using Azure and previously set up a private link and want to change to a public network, you must remove the private link resources before making the change. |
+ | Nodes (for a distributed high-availability cluster) | **Data Groups** | After you create your cluster, you can't change the number of data nodes. |
+ | Database configuration parameters | **DB Configuration** | If you're using faraway replicas, only a small subset of parameters are editable. These parameters need to be modified in the replica when increased in the replica's source cluster. See [Modify a faraway replica](/edb-postgres-ai/cloud-service/using_cluster/faraway_replicas/#modify-a-replica) for details. |
+ | Retention period for backups | **Additional Settings** | — |
+ | Custom maintenance window | **Additional Settings** | Set or modify a maintenance window in which maintenance upgrades occur for the cluster. See [Maintenance](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/#maintenance). |
+ | Read-only workloads | **Additional Settings** | Enabling read-only workloads can incur higher cloud infrastructure charges. |
+ | PgBouncer | **Additional Settings** | Enabling PgBouncer incurs additional infrastructure costs that depend on your cloud provider. See [PgBouncer costs](/biganimal/release/pricing_and_billing/#pgbouncer-costs). |
+ | Identity and Access Management (IAM) Authentication | **Additional Settings** | Turn on the ability to log in to Postgres using AWS IAM credentials. You must then run a command to add each user’s credentials to a role that uses IAM authentication in Postgres. See [IAM authentication for Postgres](/edb-postgres-ai/cloud-service/using_cluster/postgres_access/database_authentication/#iam-authentication-for-postgres). |
+ | Superuser access | **Additional Settings** | Disabling the option removes superuser access for edb_admin, but any other superusers existing in the database retain their superuser privileges. |
+
+
+5. Save your changes.
+ !!! Note
+
+ Saving changes might require restarting the database.
+
+## Modify a data group
+
+You can modify the data groups in your distributed high-availability cluster by editing the configuration settings.
+
+1. Sign in to the [Console](https://portal.biganimal.com).
+
+2. On the Clusters page, select the data group you want to edit. Data groups appear under the cluster they reside in.
+
+3. Select **Edit** next to the data group.
+
+4. Edit the cluster settings in the **Data Groups** tab. See the table in [Modify your cluster configuration settings](#modify-your-clusters-configuration-settings).
+
+5. Select **Save**.
+
+6. In the popup window, confirm your changes.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/periodic_maintenance.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/periodic_maintenance.mdx
new file mode 100644
index 00000000000..5f97a9df90d
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/periodic_maintenance.mdx
@@ -0,0 +1,36 @@
+---
+title: Periodic maintenance
+---
+
+EDB performs periodic maintenance to ensure stability and security of your clusters. We perform minor version upgrades and patch updates as part of this periodic maintenance.
+
+## Notification of upcoming maintenance
+
+You're notified in the BigAnimal portal before maintenance occurs. Details are available on the [Cloud Service status page](https://status.biganimal.com/). You can subscribe to get these updates in a feed by selecting **Subscribe to Updates** on the status page. You can also enable the notifications to receive in-app or email notifications for upcoming, successful, and failed cluster maintenance upgrade. For more information, see [Managing notifications](/edb-postgres-ai/console/using/notifications/#managing-notifications).
+
+EDB reserves the right to upgrade customers to the latest minor version without prior notice in an extraordinary circumstance. You can't configure minor versions.
+
+In some cases, these updates might terminate existing network connections to your clusters. If that happens, the outage is typically less than 30 seconds. Be sure your applications are configured to automatically reconnect when connections are interrupted. Most modern database libraries do this by default.
+
+## Specifying maintenance windows
+
+If you want to control when the updates are pushed, you can specify a weekly maintenance window for each cluster or each data group in the case of a distributed high-availability cluster. BigAnimal displays a *scheduled maintenance* message on your cluster list four hours prior to the scheduled maintenance time to remind you of the upcoming maintenance window. This reminder allows you to make any necessary preparations, such as saving your work and closing any open connections. For more information on specifying maintenance windows, see [Maintenance](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/#maintenance).
+
+## Maintenance for high-availability clusters
+
+For primary/standby high-availability clusters, periodic maintenance is performed first on the standby replicas and then on the primary.
+
+While there is no downtime during periodic maintenance, there will be a network connection reset as the primary is failing over.
+
+## Connectivity issues after an automatic upgrade
+
+Most connectivity issues correct themselves when you reopen the connection after waiting for a minimum of five seconds. We recommend that you:
+
+- Wait five seconds before your first attempt.
+- For the next attempt, increase the wait by doubling the previous wait time. Keep trying this approach until you reach a maximum wait time of 60 seconds.
+
+We also recommend that you set a maximum number of attempts to reopen the connection before your application reports that it can't reconnect.
+
+When an active connection that's currently executing a command is interrupted, you might need to take extra action when reopening the connection. (For read-only transactions that were in progress, you can reopen the connection without any extra steps.) For a transaction that was writing to the database, you need to know whether the transaction was rolled back or whether it succeeded to determine whether you need to retry the transaction. If it was rolled back, you need to retry it. If it succeeded, you don't need to retry it. It's possible for a transaction to succeed without sending you the commit acknowledgment from the database server, so you'll need to add some logic to be sure.
+
+Test your retry logic by creating an event that causes a brief downtime to see if it's handling these transactions correctly.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/upgrading_your_cluster.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/upgrading_your_cluster.mdx
new file mode 100644
index 00000000000..5e3b25ceb2c
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/managing_your_cluster/upgrading_your_cluster.mdx
@@ -0,0 +1,233 @@
+---
+title: Performing a major version upgrade of Postgres on Cloud Service
+navTitle: Upgrading Postgres major versions
+deepToC: true
+---
+
+## Using logical replication
+
+!!!Note
+
+This procedure doesn't work with distributed high-availability Cloud Service instances.
+!!!
+
+Logical replication is a common method for upgrading the Postgres major version on Cloud Service instances, enabling a transition with minimal downtime.
+
+By replicating changes in real time from an older version (source instance) to a newer one (target instance), this method provides a reliable upgrade path while maintaining database availability.
+
+!!!Important
+
+Depending on where your older and newer versioned Cloud Service instances are located, this procedure can accrue ingress and egress costs from your cloud service provider (CSP) for the migrated data. Consult your CSP's pricing documentation to see how ingress and egress fees are calculated to determine any extra costs.
+!!!
+
+### Overview of upgrading
+
+To perform a major version upgrade:
+
+1. [Create a Cloud Service instance.](#create-a-cloud-service-instance)
+2. [Gather instance information.](#gather-instance-information)
+3. [Confirm the Postgres versions before migration.](#confirm-the-postgres-versions-before-migration)
+4. [Migrate the database schema.](#migrate-the-database-schema)
+5. [Create a publication.](#create-a-publication)
+6. [Create a logical replication slot.](#create-the-logical-replication-slot)
+7. [Create a subscription.](#create-a-subscription)
+8. [Validate the migration.](#validate-the-migration)
+
+### Create a Cloud Service instance
+
+To perform a major version upgrade, create a Cloud Service instance with your desired version of Postgres. This is your target instance.
+
+Ensure your target instance is provisioned with a storage size equal to or greater than your source instance.
+
+For details on creating a Cloud Service instance, see [Creating a cluster](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/).
+
+### Gather instance information
+
+Use the Cloud Service console to obtain the following information for your source and target instance:
+
+- Read/write URI
+- Database name
+- Username
+- Read/write host
+
+Using the Cloud Service console:
+
+1. Select the **Clusters** tab.
+2. Select your source instance.
+3. From the **Connect** tab, obtain the information from **Connection Info**.
+
+### Confirm the Postgres versions before migration
+
+Confirm the Postgres version of your source and target Cloud Service instances:
+
+```
+psql "" -c "select version();"
+```
+
+Output using Postgres 16:
+
+```
+ version
+-------------------------------------------------------------------------------------------------------------------------------------
+ PostgreSQL 16.2 (Debian 16.2.0-3.buster) (BigAnimal Edition) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
+(1 row)
+```
+
+### Migrate the database schema
+
+On your source instance, use the `dt` command to view the details of the schema to be migrated:
+
+```sql
+/dt+;
+```
+
+Here's a sample database schema for this example:
+
+```
+ List of relations
+ Schema | Name | Type | Owner | Persistence | Access method | Size | Description
+--------+------------------+-------+-----------+-------------+---------------+------------+-------------
+ public | pgbench_accounts | table | edb_admin | permanent | heap | 1572 MB |
+ public | pgbench_branches | table | edb_admin | permanent | heap | 8192 bytes |
+ public | pgbench_history | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_tellers | table | edb_admin | permanent | heap | 120 kB |
+```
+
+Use pg_dump with the `--schema-only` flag to copy the schema from your source to your target instance. For more information on using pg_dump, [see the Postgres documentation](https://www.postgresql.org/docs/current/app-pgdump.html).
+
+```
+pg_dump --schema-only -h -U -d | psql -h -U -d
+```
+
+On the target instance, confirm the schema was migrated:
+
+```
+ List of relations
+ Schema | Name | Type | Owner | Persistence | Access method | Size | Description
+--------+------------------+-------+-----------+-------------+---------------+---------+-------------
+ public | pgbench_accounts | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_branches | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_history | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_tellers | table | edb_admin | permanent | heap | 0 bytes |
+```
+
+!!!Note
+
+A successful schema-only copy shows the tables with zero bytes.
+!!!
+
+### Create a publication
+
+Use the `CREATE PUBLICATION` command to create a publication on your source instance. For more information on using `CREATE PUBLICATION`, see [the Posgres documentation](https://www.postgresql.org/docs/current/sql-createpublication.html).
+
+```sql
+CREATE PUBLICATION ;
+```
+
+In this example:
+
+```sql
+CREATE PUBLICATION v12_pub;
+```
+
+The expected output is: `CREATE PUBLICATION`.
+
+Add tables that you want to replicate to your target instance:
+
+```sql
+ALTER PUBLICATION ADD TABLE ;
+```
+
+```sql
+ALTER PUBLICATION v12_pub ADD TABLE pgbench_accounts;
+ALTER PUBLICATION v12_pub ADD TABLE pgbench_branches;
+ALTER PUBLICATION v12_pub ADD TABLE pgbench_history;
+ALTER PUBLICATION v12_pub ADD TABLE pgbench_tellers;
+```
+
+The expected output is: `ALTER PUBLICATION`.
+
+### Create the logical replication slot
+
+On the source instance, create a replication slot using the `pgoutput` plugin:
+
+```sql
+SELECT pg_create_logical_replication_slot('','pgoutput');
+```
+
+In the current example:
+
+```sql
+SELECT pg_create_logical_replication_slot('v12_pub','pgoutput');
+```
+
+The expected output returns the `slot_name` and `lsn`.
+
+```
+ pg_create_logical_replication_slot
+------------------------------------
+ (v12_pub,0/AC003330)
+```
+
+The replication slot tracks changes to the published tables from the source instance and replicates changes to the subscriber on the target instance.
+
+### Create a subscription
+
+Use the `CREATE SUBSCRIPTION` command to create a subscription on your target instance. For more information on using `CREATE SUBSCRIPTION`, see [the Postgres documentation](https://www.postgresql.org/docs/current/sql-createsubscription.html).
+
+```sql
+CREATE SUBSCRIPTION CONNECTION 'user= host= sslmode=require port= dbname= password=' PUBLICATION WITH (enabled=true, copy_data = true, create_slot = false, slot_name=);
+```
+
+This example creates a subscription on a Postgres 16 instance to a publication on a Postgres 12 instance:
+
+```sql
+CREATE SUBSCRIPTION v16_sub CONNECTION 'user=edb_admin host=p-x67kjhacc4.pg.biganimal.io sslmode=require port=5432 dbname=edb_admin password=XXX' PUBLICATION v12_pub WITH (enabled=true, copy_data = true, create_slot = false, slot_name=v12_pub);
+```
+
+The expected output is: `CREATE SUBSCRIPTION`.
+
+In this example, the subscription uses a connection string to specify the source database and includes options to copy existing data and to follow the publication identified by `v12_pub`.
+
+The subscriber pulls schema changes (with some exceptions, as noted in the PostgreSQL [documentation on Limitations of Logical Replication](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)) and data from the source to the target database, effectively replicating the data.
+
+### Validate the migration
+
+To validate the progress of the data migration, use `dt+` from the source and target Cloud Service instances to compare the size of each table.
+
+```
+ List of relations
+ Schema | Name | Type | Owner | Persistence | Access method | Size | Description
+--------+------------------+-------+-----------+-------------+---------------+------------+-------------
+ public | pgbench_accounts | table | edb_admin | permanent | heap | 1572 MB |
+ public | pgbench_branches | table | edb_admin | permanent | heap | 8192 bytes |
+ public | pgbench_history | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_tellers | table | edb_admin | permanent | heap | 120 kB |
+```
+
+```
+ List of relations
+ Schema | Name | Type | Owner | Persistence | Access method | Size | Description
+--------+------------------+-------+-----------+-------------+---------------+---------+-------------
+ public | pgbench_accounts | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_branches | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_history | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_tellers | table | edb_admin | permanent | heap | 0 bytes |
+```
+
+If logical replication is running correctly, each time you run `\dt+;` you see that more data was migrated:
+
+```
+ List of relations
+ Schema | Name | Type | Owner | Persistence | Access method | Size | Description
+--------+------------------+-------+-----------+-------------+---------------+---------+-------------
+ public | pgbench_accounts | table | edb_admin | permanent | heap | 344 MB |
+ public | pgbench_branches | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_history | table | edb_admin | permanent | heap | 0 bytes |
+ public | pgbench_tellers | table | edb_admin | permanent | heap | 0 bytes |
+```
+
+!!!Note
+
+You can optionally use [LiveCompare](https://www.enterprisedb.com/docs/livecompare/latest/) to generate a comparison report of the source and target databases to validate that all database objects and data are consistent.
+!!!
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/index.mdx
new file mode 100644
index 00000000000..0b03d06aed0
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/index.mdx
@@ -0,0 +1,7 @@
+---
+title: Distributed High Availability on Cloud Service
+navTitle: Distributed High Availability
+description: The PGD defaults and commands for Distributed high availability on EDB Postgres AI Cloud Service.
+---
+
+When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/cli/) to manage cluster operations. Examples of these operations include switching over write leaders, performing cluster health checks, and viewing various details about nodes, groups, or other aspects of the cluster.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_cli_ba.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_cli_ba.mdx
new file mode 100644
index 00000000000..93b5f53c81a
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_cli_ba.mdx
@@ -0,0 +1,115 @@
+---
+title: PGD CLI on Cloud Service
+navTitle: PGD CLI on Cloud Service
+deepToC: true
+---
+
+When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/cli/) to manage cluster operations. Examples of these operations include switching over write leaders, performing cluster health checks, and viewing various details about nodes, groups, or other aspects of the cluster.
+
+## Installing the PGD CLI
+
+To [install the PGD CLI](/pgd/latest/cli/installing/), for Debian and Ubuntu machines, replace `` with your EDB subscription token in the following command:
+
+```bash
+curl -1sLf 'https://downloads.enterprisedb.com/<your-token>/postgres_distributed/setup.deb.sh' | sudo -E bash
+sudo apt-get install edb-pgd5-cli
+```
+
+For RHEL, Rocky, AlmaLinux, or Oracle Linux machines, make the replacement in this command:
+
+```bash
+curl -1sLf 'https://downloads.enterprisedb.com/<your-token>/postgres_distributed/setup.rpm.sh' | sudo -E bash
+sudo yum install edb-pgd5-cli
+```
+
+## Connecting to your Cloud Service cluster
+
+### Discovering your database connection string
+
+To connect to your distributed high-availability Cloud Service cluster using the PGD CLI, you need to [discover the database connection string](/pgd/latest/cli/discover_connections/). From your Console:
+
+1. Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view.
+2. To show only clusters that work with PGD CLI, in the filter, set **Cluster Type** to **Distributed High Availability**.
+3. Select your cluster.
+4. In the view of your cluster, select the **Connect** tab.
+5. Copy the read/write URI from the connection info. This is your connection string.
+
+### Using the PGD CLI with your database connection string
+
+!!!Important
+
+PGD doesn't prompt for interactive passwords. Accordingly, you need a [`.pgpass` file](https://www.postgresql.org/docs/current/libpq-pgpass.html) properly configured to allow access to the cluster. Your Cloud Service cluster's connection information page has all the information needed for the file.
+
+Without a properly configured `.pgpass`, you receive a database connection error when using a PGD CLI command, even when using the correct database connection string with the `--dsn` flag.
+!!!
+
+To use the PGD CLI with your database connection string, use the `--dsn` flag with your PGD CLI command:
+
+```bash
+pgd show-nodes --dsn ""
+```
+
+## PGD commands in Cloud Service
+
+!!!Note
+
+Three EDB Postgres Distributed CLI commands don't work with distributed high-availability Cloud Service clusters: `create-proxy`, `delete-proxy`, and `alter-proxy-option`. These commands are managed by Cloud Service, as Cloud Service runs on Kubernetes. It's a technical best practice to have the Kubernetes operator handle these functions.
+!!!
+
+The examples that follow show the most common PGD CLI commands with a Cloud Service cluster.
+
+### `pgd check-health`
+
+`pgd check-health` provides statuses with relevant messaging regarding the clock skew of node pairs, node accessibility, the current raft leader, replication slot health, and versioning consistency:
+
+```
+$ pgd check-health --dsn "postgres://edb_admin@p-mbx2p83u9n-a.pg.biganimal.io:5432/bdrdb?sslmode=require"
+__OUTPUT__
+Check Status Message
+----- ------ -------
+ClockSkew Ok All BDR node pairs have clockskew within permissible limit
+Connection Ok All BDR nodes are accessible
+Raft Warning There is no RAFT_LEADER, an election might be in progress
+Replslots Ok All BDR replication slots are working correctly
+Version Ok All nodes are running same BDR versions
+```
+
+### `pgd show-nodes`
+
+`pgd show-nodes` returns all the nodes in the distributed high-availability cluster and their summaries, including name, node id, group, and current/target state:
+
+```
+$ pgd show-nodes --dsn "postgres://edb_admin@p-mbx2p83u9n-a.pg.biganimal.io:5432/bdrdb?sslmode=require"
+__OUTPUT__
+Node Node ID Group Type Current State Target State Status Seq ID
+---- ------- ----- ---- ------------- ------------ ------ ------
+p-mbx2p83u9n-a-1 3537039754 dc1 data ACTIVE ACTIVE Up 1
+p-mbx2p83u9n-a-2 3155790619 p-mbx2p83u9n-a data ACTIVE ACTIVE Up 2
+p-mbx2p83u9n-a-3 2604177211 p-mbx2p83u9n-a data ACTIVE ACTIVE Up 3
+```
+
+### `pgd show-groups`
+
+`pgd show-groups` returns all groups in your distributed high-availability Cloud Service cluster. It also notes the node that's the current write leader of each group:
+
+```
+$ pgd show-groups --dsn "postgres://edb_admin@p-mbx2p83u9n-a.pg.biganimal.io:5432/bdrdb?sslmode=require"
+__OUTPUT__
+Group Group ID Type Parent Group Location Raft Routing Write Leader
+----- -------- ---- ------------ -------- ---- ------- ------------
+world 3239291720 global true true p-mbx2p83u9n-a-1
+dc1 4269540889 data p-mbx2p83u9n-a false false
+p-mbx2p83u9n-a 2800873689 data world true true p-mbx2p83u9n-a-3
+```
+
+### `pgd switchover`
+
+`pgd switchover` manually changes the write leader of the group and can be used to simulate a [failover](/pgd/latest/quickstart/further_explore_failover).
+
+```
+$ pgd switchover --group-name world --node-name p-mbx2p83u9n-a-2 --dsn "postgres://edb_admin@p-mbx2p83u9n-a.pg.biganimal.io:5432/bdrdb?sslmode=require"
+__OUTPUT__
+switchover is complete
+```
+
+See the [PGD CLI command reference](/pgd/latest/cli/command_ref/) for the full range of PGD CLI commands and their descriptions.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_defaults_ba.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_defaults_ba.mdx
new file mode 100644
index 00000000000..a99fd7275c4
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_defaults_ba.mdx
@@ -0,0 +1,137 @@
+---
+title: Postgres Distributed (PGD) presets on Cloud Service
+navTitle: PGD presets on Cloud Service
+deepToC: true
+---
+
+## Commit scope
+
+[Commit scopes](/pgd/latest/durability/commit-scopes/) in PGD are a set of rules that describe the behavior of the system as transactions are committed. Because they define how transactions are replicated across a distributed database, they have an effect on consistency, durability, and performance.
+
+The actual behavior depends on the kind of commit scope a commit scope's rule uses: [Group Commit](/pgd/latest/durability/group-commit/), [Commit At Most Once](/pgd/latest/durability/camo/), [Lag Control](/pgd/latest/durability/lag-control/), [Synchronous Commit](/pgd/latest/durability/synchronous_commit/), or a combination of these.
+
+This flexibility means that selecting a balanced combination of rules can take time. To speed up deployment, Cloud Service's PGD has a preset selection of commit scopes for typical user requirements. These presets don't prevent you from creating and applying your own commit scopes as needed.
+
+### Cloud Service's commit scope preset options
+
+The presets include a rule for high consistency in a subgroup and a separate setting for lag control both inside and outside the subgroup. You can use combinations of these rules for high consistency in a subgroup. You can also use lag control for other subgroups and high consistency within the subgroup and with one or more nodes of another subgroup.
+
+| Preset ID | Local group | External groups | Use case |
+|-----------|---------------------|--------------------|--------------------------------------|
+| ba001 | MAJORITY, SYNCHRONOUS_COMMIT | N/A | High consistency for critical data |
+| ba002 | ALL, LAG_CONTROL | ALL, LAG_CONTROL | Manages replication lag locally and externally |
+| ba003 | MAJORITY, SYNCHRONOUS_COMMIT | ANY 1, LAG_CONTROL | Combines high consistency locally with lag control for external|
+| ba004 | MAJORITY, SYNCHRONOUS_COMMIT | ANY 1, SYNCHRONOUS COMMIT | Higher consistency via external validation |
+
+!!! Note
+ba001 is also the only Cloud Service preset that works with PGD clusters that have only one data group. All of the presets, including ba001, work with PGD clusters that have two or more data groups.
+!!!
+
+### ba001
+
+ba001 offers a default setup that optimizes data consistency and reliability across distributed environments. This example shows a definition for transactions originating from the group of nodes `location-a`. The full name of the actual commit scope for this specific group is `ba001_location-a`.
+
+```sql
+SELECT bdr.add_commit_scope(
+ commit_scope_name := 'ba001_location-a',
+ origin_node_group := 'location-a',
+ rule := 'MAJORITY (location-a) SYNCHRONOUS_COMMIT',
+ wait_for_ready := true
+);
+```
+
+This rule says that for transactions originating from a node in `location-a`, the majority of the nodes in `location-a` must acknowledge the transaction before it's committed.
+
+ba001 uses `MAJORITY` instead of `ALL` so that in the case of 3 data nodes, the third can be updated asynchronously. This ability allows for a node failure without interrupting a single region service.
+
+ba001 is the baseline commit scope provided by Cloud Service and the default commit scope for all new subgroups.
+
+### ba002
+
+ba002 allows for asynchronous commits but with lag control for tighter consistency (that is, tighter than the system's default asynchronous behavior) across the distributed system. The following is an example definition of ba002 for nodes in `location-a`:
+
+```sql
+SELECT bdr.add_commit_scope(
+ commit_scope_name := 'ba002_location-a',
+ origin_node_group := 'location-a',
+ rule := 'ALL (location-a) LAG_CONTROL (max_commit_delay=1s, max_lag_size=100MB) AND ALL NOT (location-a) LAG_CONTROL (max_lag_size=1000MB, max_commit_delay=4s, max_lag_time=30s)',
+ wait_for_ready := true
+);
+```
+
+The first part of the rule says that all nodes of `location_a`, which is the `origin_node_group` in this case, are monitored according to `max_lag_size=100MB` and `max_commit_delay=1s`. Specifically, as lag size approaches the set max of 100MB, the system begins injecting commit delays on the origin node of up to 1 second so that replication to the other nodes in the group can catch up.
+
+The second part of the rule (after `AND`) says that for all nodes not in `location_a`, those nodes are monitored according to `max_lag_size=1000MB`, `max_lag_time=30s`, and `max_commit_delay=4s`. Specifically, as lag size or time approaches either of their respective limits (1000MB or 30s), the system begins injecting commit delays on the origin node of up to 4 seconds. This capability allows replication to those nodes outside the origin node group to catch up.
+
+### ba003
+
+ba003 is a combination of Synchronous Commit for the local group with Lag Control parameters being met by at least one external node.
+
+This example definition of a ba003 commit scope uses the `bdr.add_commit_scope` command, again applying to nodes in `location-a`:
+
+```sql
+SELECT bdr.add_commit_scope(
+ commit_scope_name := 'ba003_location-a',
+ origin_node_group := 'location-a',
+ rule := 'MAJORITY (location_a) SYNCHRONOUS_COMMIT AND ANY 1 NOT (location_a) LAG_CONTROL (max_lag_size=1000MB, max_commit_delay=4s, max_lag_time=30s)',
+ wait_for_ready := true
+);
+```
+
+The first part of the rule states that for any transaction originating on a node in the `origin_node_group` (in this case `location-a`), a majority of the nodes in `location_a` must confirm the transaction before it's committed.
+
+The second part of the rule states that at least one node not in `location_a` must keep lag within the `LAG_CONTROL` parameters (`max_lag_size=1000MB, max_lag_time=30s`) with respect to its replicating transactions originating from a node in the `origin_node_group` (here location_a). Otherwise, a commit delay of up to 4 seconds will be used to slow down processing on the originating node to allow for the lagging node to catch up.
+
+
+### ba004
+
+```sql
+SELECT bdr.add_commit_scope(
+ commit_scope_name := 'ba004_location-a',
+ origin_node_group := 'location-a',
+ rule := 'MAJORITY (location_a) SYNCHRONOUS_COMMIT AND ANY 1 NOT (location_a) SYNCHRONOUS_COMMIT',
+ wait_for_ready := true
+);
+```
+
+ba004 says that for all transactions originating from a node in the `origin_node_group` (`location-a` in the example), a majority of the nodes of `location-a`, and at least one node not in `location-a`, must confirm the transaction before it's committed.
+
+Just as in [ba001](#ba001) and [ba003](#ba003), ba004 uses `SYNCHRONOUS_COMMIT` to keep potential data loss at near zero, as the data is replicated before commit success is signaled to the application. Again, `MAJORITY` is used so that in a three-node scenario in a region, one node can experience failure without compromising the cluster. However, to confirm the transaction, in this case the commit scope also requires confirmation from one node outside of the group.
+
+### Setting default_commit_scope
+
+As mentioned, the default Cloud Service PGD commit scope preset is an instantiation of ba001.
+
+To change the default commit scope, you need to know the names of your commit scope presets and the name of the origin node group for your cluster. To see the Cloud Service presets as defined for your cluster's groups, connect to the cluster using psql, and enter:
+
+```sql
+SELECT * FROM bdr.commit_scopes
+```
+
+```
+ commit_scope_id | commit_scope_name | commit_scope_origin_node_group | commit_scope_rule
+-----------------+----------------------+--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+ 1131842441 | ba001_p-mbx2p83u9n-a | 2800873689 | MAJORITY (p-mbx2p83u9n-a) SYNCHRONOUS_COMMIT
+ 2997404763 | ba002_p-mbx2p83u9n-a | 2800873689 | ALL (p-mbx2p83u9n-a) LAG CONTROL (max_commit_delay=1s, max_lag_size=100MB) AND ALL NOT (p-mbx2p83u9n-a) LAG CONTROL (max_lag_size=1000MB, max_commit_delay=4s, max_lag_time=30s)
+ 671768582 | ba003_p-mbx2p83u9n-a | 2800873689 | MAJORITY (p-mbx2p83u9n-a) SYNCHRONOUS_COMMIT AND ANY 1 NOT (p-mbx2p83u9n-a) LAG CONTROL (max_lag_size=1000MB, max_commit_delay=4s, max_lag_time=30s)
+ 1568192748 | ba004_p-mbx2p83u9n-a | 2800873689 | MAJORITY (p-mbx2p83u9n-a) SYNCHRONOUS_COMMIT AND ANY 1 NOT (p-mbx2p83u9n-a) SYNCHRONOUS_COMMIT
+(4 rows)
+```
+
+Note the `commit_scope_name` of the preset you want to set as your default. The origin node group follows `ba00<#>_`. In this case, it's `p-mbx2p83u9n-a`.
+
+To make a commit_scope the `default_commit_scope` for a node group, use the command `bdr.alter_node_group_option`. Replace `` with the origin node group (in this case `p-mbx2p83u9n-a`). Replace `` with the `commit_scope_name` of the desired preset.
+
+```sql
+SELECT bdr.alter_node_group_option(
+ node_group_name := '',
+ config_key := 'default_commit_scope',
+ config_value := ''
+);
+```
+
+!!! Note
+Commit scopes can be applied per transaction. In that case, they override a Cloud Service preset.
+!!!
+
+For more information, see [Commit scopes](/pgd/latest/durability/commit-scopes/) and [Commit scope rules](/pgd/latest/durability/commit-scope-rules/) in the PGD documentation.
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/foreign_data_wrappers.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/foreign_data_wrappers.mdx
new file mode 100644
index 00000000000..2c46d5f97b4
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/foreign_data_wrappers.mdx
@@ -0,0 +1,10 @@
+---
+title: Foreign data wrappers
+description: Using foreign data wrappers in EDB Postgres AI Cloud Service
+---
+
+Cloud Service supports EDB's MongoDB Foreign Data Wrapper and MySQL Foreign Data Wrapper. They allow you to connect your Postgres database server to external data sources. See:
+
+- [MongoDB Foreign Data Wrapper](/mongo_data_adapter/latest/) — Accesses data that resides on a MongoDB database from a Postgres database server.
+
+- [MySQL Foreign Data Wrapper](/mysql_data_adapter/latest/) — Accesses data that resides on a MySQL database from a Postgres database server.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/index.mdx
new file mode 100644
index 00000000000..120060c28cb
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/index.mdx
@@ -0,0 +1,15 @@
+---
+title: Supported configurations
+description: "A reference for all supported configurations of clusters on EDB Postgres AI Cloud Service."
+navigation:
+- supported_cluster_types
+- supported_database_versions
+- supported_regions
+- supported_extension_tools
+- poolers
+- foreign_data_wrappers
+- distributed_high_availability
+---
+
+This reference guide provides information on the supported configurations for EDB Postgres AI Cloud Service.
+
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/poolers.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/poolers.mdx
new file mode 100644
index 00000000000..89cc80b03ed
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/poolers.mdx
@@ -0,0 +1,14 @@
+---
+title: EDB PgBouncer
+description: EDB PgBouncer availability on Cloud Service.
+---
+
+EDB PgBouncer can manage your connections to Postgres databases and help your workloads run more efficiently. It's particularly useful if you plan to use more than a few hundred active connections. You can enable EDB PgBouncer to be entirely managed by Cloud Service, when creating your cluster. See [Creating a cluster](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_cluster/#pgbouncer).
+
+Cloud Service provisions up to three instances per EDB PgBouncer-enabled cluster to ensure that performance is unaffected, so each availability zone receives its own instance of EDB PgBouncer.
+
+!!!Note
+
+ Currently, you can't enable EDB PgBouncer when creating a distributed high-availability cluster.
+
+If you want to deploy and manage PgBouncer outside of Cloud Service, see the [How to configure EDB PgBouncer with Cloud Service cluster](https://support.biganimal.com/hc/en-us/articles/4848726654745-How-to-configure-PgBouncer-with-BigAnimal-Cluster) knowledge-base article.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability.mdx
new file mode 100644
index 00000000000..cd27b9d304e
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability.mdx
@@ -0,0 +1,90 @@
+---
+title: "Distributed high availability"
+---
+
+Distributed high-availability clusters are powered by [EDB Postgres Distributed](/pgd/latest/). They use multi-master logical replication to deliver more advanced cluster management compared to a physical replication-based system. Distributed high-availability clusters let you deploy a cluster across multiple regions or a single region. For use cases where high availability across regions is a major concern, a cluster deployment with distributed high availability enabled can provide two data groups with a witness group in a third region.
+
+This configuration provides a true active-active solution as each data group is configured to accept writes.
+
+Distributed high-availability clusters support both EDB Postgres Advanced Server and EDB Postgres Extended Server database distributions.
+
+Distributed high-availability clusters contain one or two data groups. Your data groups can contain either three data nodes or two data nodes and one witness node. At any given time, one of these data nodes in each group is the leader and accepts writes, while the rest are referred to as [shadow nodes](/pgd/latest/terminology/#write-leader). We recommend that you don't use two data nodes and one witness node in production unless you use asynchronous [commit scopes](/pgd/latest/durability/commit-scopes/).
+
+[PGD Proxy](/pgd/latest/routing/proxy) routes all application traffic to the leader node, which acts as the principal write target to reduce the potential for data conflicts. PGD Proxy leverages a distributed consensus model to determine availability of the data nodes in the cluster. On failure or unavailability of the leader, PGD Proxy elects a new leader and redirects application traffic. Together with the core capabilities of EDB Postgres Distributed, this mechanism of routing application traffic to the leader node enables fast failover and switchover.
+
+The witness node/witness group doesn't host data but exists for management purposes. It supports operations that require a consensus, for example, in case of an availability zone failure.
+
+!!!Note
+
+ Operations against a distributed high-availability cluster leverage the [EDB Postgres Distributed switchover](/pgd/latest/cli/command_ref/pgd_switchover/) feature, which provides subsecond interruptions during planned lifecycle operations.
+
+## Single data location
+
+A configuration with a single data location has one data group and either:
+
+- Two data nodes with one lead, one shadow, and a witness node, each in separate availability zones
+
+ 
+
+- Three data nodes with one lead and two shadow nodes, each in separate availability zones
+
+ 
+
+## Multiple data locations and witness node
+
+A configuration with multiple data locations has two data groups that contain either:
+
+- Three data nodes:
+
+ - A data node and two shadow nodes in one region
+ - The same configuration in another region
+ - A witness node in a third region
+
+ 
+
+- Two data nodes (not recommended for production):
+
+ - A data node, shadow node, and a witness node in one region
+ - The same configuration in another region
+ - A witness node in a third region
+
+ 
+
+### Cross-cloud service providers (CSP) witness node
+
+By default, the cloud service provider selected for the data groups is preselected for the witness node.
+
+To guard against cloud service provider failures, you can designate a witness node on a cloud service provider different from the one for data groups. This configuration can enable a three-region configuration even if a single cloud provider offers only two regions in the jurisdiction you're allowed to deploy your cluster in.
+
+Cross-cloud service provider witness nodes are available with AWS, Azure, and Google Cloud using your own cloud account and Cloud Service's cloud account. This option is enabled by default and applies to both multi-region configurations available with PGD. For witness nodes you pay only for the infrastructure used, which is reflected in the pricing estimate.
+
+## Read-only workloads
+
+When you enable the read-only workloads option during the cluster creation, a read-only connection string is created for the data group. You can use this connection to allow your application or service to route read-only requests through the shadow nodes (non-write leaders) to lighten the load on the write leaders and improve the distributed high-availability cluster's performance.
+
+If you have more than one data group, you can choose whether to enable the read-only workloads option on a per-data-group basis.
+
+Since the infrastructure of a distributed high-availability cluster is almost entirely based on EDB Postgres Distributed, the same [PGD Proxy read-only routing rules](/pgd/latest/routing/readonly/) apply.
+
+!!! Important
+
+ Once you have configured a read-only connection string with your application, read-only workloads are routed to shadow nodes (non-write leaders). The connection is read-only because it accepts read-only queries through the shadow nodes. However, commands that run on read-only connections aren't filtered by Cloud Service, so shadow nodes can still perform write operations to the contents of database tables. We recommend that you use a Postgres role with minimal read-only privileges for your application or pass `default_transaction_read_only=on` in the connection string. This way, you can avoid write operations on shadow nodes that could cause conflicts between the write leader and the shadow nodes.
+
+### IP addresses
+
+If you're configuring read-only workload connections on your own cloud account, you might have to raise the IP address resource limits for the cluster:
+
+- For Azure, the IP address quota is standard public IP address.
+
+- For AWS, the IP address quota is Elastic IP. You might also have to increase the **Network Load Balancers per Region** value.
+
+
+### Advisory locks
+
+Advisory locks aren't replicated between Postgres nodes, so advisory locks taken on a shadow node don't conflict with advisory locks taken on the lead. We recommend that applications that rely on advisory locking avoid using read-only workloads for those transactions.
+
+## For more information
+
+For instructions on creating a distributed high-availability cluster using the Console, see [Creating a distributed high-availability cluster](/edb-postgres-ai/cloud-service/getting_started/creating_cluster/creating_a_dha_cluster/).
+
+For instructions on creating, retrieving information from, and managing a distributed high-availability cluster using the Cloud Service CLI, see [Using the Cloud Service CLI](/edb-postgres-ai/cloud-service/using_cluster/cli/managing_clusters/#managing-distributed-high-availability-clusters).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/faraway_replicas.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/faraway_replicas.mdx
new file mode 100644
index 00000000000..6ec9872512c
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/faraway_replicas.mdx
@@ -0,0 +1,45 @@
+---
+title: "Faraway replicas"
+---
+
+Faraway replicas are read-only replicas of Cloud Service clusters that you can provision in most supported regions. You can create faraway replicas of your single-node and high-availability clusters in different regions of your cloud. Database users and applications can read from a nearby faraway replica instead of the source cluster. This ability relieves some of the workload on the source cluster and frees it up to handle write traffic.
+
+In case of a failure, you can manually promote the faraway replica to a full-fledged Cloud Service cluster, making it capable of accepting writes. See [Managing replicas](/edb-postgres-ai/cloud-service/using_cluster/faraway_replicas/).
+
+In Cloud Service, faraway replicas use log shipping to replicate from their source clusters. This means that a replica cluster accesses the write-ahead log (WAL) of its source cluster and “replays” the changes described in it.
+
+A WAL is a file that logs any changes made to a database. Databases write the change to the WAL before actually making the change. This way, if the database goes down before the change can be applied, the WAL has a record of the intended changes. The replica pulls in the changes from the WAL every time a new WAL file is closed, so replication is asynchronous.
+
+Faraway replicas are priced the same as single-node clusters.
+
+## Advantages
+
+- **Disaster recovery** — You can create faraway replicas in different regions in your cloud. Deploying faraway replicas across regions can help you build a more solid disaster recovery (DR) plan.
+
+- **Improved read-query performance** — For an improved read-query performance, set up the faraway replica in the same region as your application. For example, applications can read the writes made to a cluster in the `us-east` region from a `us-west` replica.
+
+- **Flexibility** — Options you might not find anywhere else:
+ - Your choice of instance type and size
+ - Your choice of storage volume and properties
+ - No limit to the number of replicas you can create
+
+## Limitations
+
+- **Manual intervention** — Unlike standby replicas, Cloud Service doesn't automatically promote faraway replicas to the source cluster in case of a failure.
+
+- **Replication lag** — Promoting a faraway replica to a Cloud Service cluster can result in loss of data. See [Replication lag with faraway replicas](/edb-postgres-ai/cloud-service/managing_your_cluster/backup_and_restore/#replication-lag-with-faraway-replicas).
+
+## Examples
+
+The diagram shows a three-node, high-availability cluster with two faraway replicas.
+
+ 
+
+The diagram shows a faraway replica in Region B that's promoted to a new cluster.
+
+ 
+
+## Related topics
+
+- [Managing replicas](/edb-postgres-ai/cloud-service/using_cluster/faraway_replicas/)
+- [Activating regions](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/managing_regions/)
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/index.mdx
new file mode 100644
index 00000000000..7d16990e21b
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/index.mdx
@@ -0,0 +1,19 @@
+---
+title: "Supported cluster types"
+deepToC: true
+redirects:
+ - 02_high_availibility
+description: "Cloud Service supports three cluster types and faraway replicas."
+navigation:
+- single_node
+- primary_standby_highavailability
+- distributed_highavailability
+- faraway_replicas
+---
+
+Cloud Service supports three cluster types:
+- [Single node](./single_node)
+- [Primary/standby high availability](./primary_standby_highavailability)
+- [Distributed high availability](./distributed_highavailability)
+
+You choose the type of cluster you want on the [Create Cluster](https://portal.biganimal.com/create-cluster) page in the [Console](https://portal.biganimal.com).
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/primary_standby_highavailability.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/primary_standby_highavailability.mdx
new file mode 100644
index 00000000000..515c5302133
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/primary_standby_highavailability.mdx
@@ -0,0 +1,27 @@
+---
+title: "Primary/standby high availability"
+---
+
+The Primary/Standby High Availability option is provided to minimize downtime in cases of failures. Primary/standby high-availability clusters—one *primary* and one or two *standby replicas*—are configured automatically. Standby replicas stay up to date through physical streaming replication.
+
+If read-only workloads are enabled, then standby replicas serve the read-only workloads. In a two-node cluster, the single standby replica serves read-only workloads. In a three-node cluster, both standby replicas serve read-only workloads. The connections are made to the two standby replicas randomly and on a per-connection basis.
+
+In cloud regions with availability zones, clusters are provisioned across zones to provide fault tolerance in the face of a data center failure.
+
+In case of temporary or permanent unavailability of the primary, a standby replica becomes the primary.
+
+
+
+Incoming client connections are always routed to the current primary. In case of failure of the primary, a standby replica is promoted to primary, and new connections are routed to the new primary. When the old primary recovers, it rejoins the cluster as a standby replica.
+
+## Standby replicas
+
+By default, replication is synchronous to one standby replica and asynchronous to the other. That is, one standby replica must confirm that a transaction record was written to disk before the client receives acknowledgment of a successful commit.
+
+In a cluster with one primary and one replica (a two-node primary/standby high-availability cluster), you run the risk of the cluster being unavailable for writes because it doesn't have the same level of reliability as a three-node cluster. Cloud Service disables synchronous replication during maintenance operations of a two-node cluster to ensure write availability. You can also change from the default synchronous replication for a two-node cluster to asynchronous replication on a per-session or per-transaction basis.
+
+In PostgreSQL terms, `synchronous_commit` is set to `on`, and `synchronous_standby_names` is set to `ANY 1 (replica-1, replica-2)`. You can modify this behavior on a per-transaction, per-session, per-user, or per-database basis using `SET` or `ALTER` commands.
+
+To ensure write availability, Cloud Service disables synchronous replication during maintenance operations of a two-node cluster.
+
+Since Cloud Service replicates to only one node synchronously, some standby replicas in three-node clusters might experience replication lag. Also, if you override the Cloud Service synchronous replication configuration, then the standby replicas are inconsistent.
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/single_node.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/single_node.mdx
new file mode 100644
index 00000000000..aa6182ef973
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/single_node.mdx
@@ -0,0 +1,9 @@
+---
+title: "Single node"
+---
+
+For nonproduction use cases where high availability isn't a primary concern, a cluster deployment with high availability not enabled provides one primary with no standby replicas for failover or read-only workloads.
+
+In case of unrecoverable failure of the primary, a restore from a backup is required.
+
+
\ No newline at end of file
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_database_versions.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_database_versions.mdx
new file mode 100644
index 00000000000..dc08f26c4d8
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_database_versions.mdx
@@ -0,0 +1,42 @@
+---
+title: "Database version policy"
+description: "How Cloud Service supports the major Postgres versions."
+---
+
+We support the major Postgres versions from the date they're made available until the version is retired by EDB (generally five years). See [Platform Compatibility ](https://www.enterprisedb.com/platform-compatibility#epas) for more details on support dates for PostgreSQL, EDB Postgres Advanced Server, and EDB Postgres Extended Server. See [End-of-life policy](#end-of-life-policy) for details on our policy for retiring deprecated versions.
+
+## Supported Postgres types and versions
+
+| Postgres distribution | Versions |
+| ---------------------------- | --------------------------------------------------------------------------------------------- |
+| PostgreSQL | 12-16 for (single, high-availability) clusters |
+| EDB Postgres Extended Server | 12-16 for (single, high-availability), 14-16 for (distributed high-availability) clusters |
+| EDB Postgres Advanced Server | 14-16 for all cluster types (single, high-availability, distributed high-availability) |
+
+## End-of-life policy
+
+Cloud Service deprecates support for Postgres versions following the same timeline as PostgreSQL. PostgreSQL, EDB Postgres Advanced Server, and EDB Postgres Extended Server follow the same timelines. We recommend that you take action and upgrade your Postgres databases running on the deprecated version to a later version as soon as possible.
+
+Six months before the PostgreSQL deprecation date, Cloud Service doesn't allow you to create new instances with the deprecated database version.
+
+Six months after the PostgreSQL deprecation date, Cloud Service forces a major version upgrade to all clusters running the deprecated database version.
+
+The only exception is customers who purchased Extended Life Support (ELS) prior to that date. To purchase Extended Life Support, contact EDB Sales.
+
+## Key dates
+
+While PostgreSQL officially deprecated version 11 on November 9, 2023, Cloud Service deprecated PostgreSQL 11 on November 20, 2023 in alignment with the broader EDB portfolio.
+
+On November 20, 2023, Cloud Service deprecated support for PostgreSQL 11 and EDB Postgres Advanced Server 11 using the following schedule. We recommend that you take action and upgrade your Postgres databases running on major version 11 to a later version, such as PostgreSQL version 15.
+
+Cloud Service automatically upgrades your Postgres 11 instances to a later version at the end of six months. Customers who purchased Extended Life Support are exempt. To purchase Extended Life Support, contact Sales. Cloud Service reserves the right to upgrade sooner in case of a security issue.
+
+| Action or recommendation | Dates - Postgres 11 | Dates - Postgres 12 |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------- |
+| Cloud Service no longer supports the Postgres version. | November 20, 2023 | December 9, 2024 |
+| The PostgreSQL community plans to deprecate the version and won't provide any security patches after this date. | November 9, 2023 | November 14, 2024 |
+| Start upgrading your Cloud Service instances to a later major version starting on this date. You can use pg_dump to restore your cluster into a later version. | Until May 20, 2023 | Until June 9, 2024 |
+| You can't create a new instance with the deprecated Postgres version in the Cloud Service interfaces after this date. | May 20, 2023 | June 9, 2024 |
+| If you manually restore a cluster, you can't restore it with the deprecated Postgres version after this date. You need to restore that Postgres cluster into a newer version of Postgres. | May 20, 2023 | June 9, 2024 |
+| Cloud Service will force a major version upgrade and won't allow any new clusters to be provisioned or restored to the old Postgres version. Only customers on Extended Life Support are exempt for the duration of their contract. If you don’t purchase Extended Life Support on this date, your clusters will be upgraded. | April 20, 2024 | May 9, 2025 |
+| Extended Life Support starts six months after PostgreSQL community deprecates the Postgres version. Cloud Service reserves the right to upgrade in case of a security issue. | April 20, 2024 | May 9, 2025 |
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_extension_tools.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_extension_tools.mdx
new file mode 100644
index 00000000000..4504f94bfad
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_extension_tools.mdx
@@ -0,0 +1,38 @@
+---
+title: Supported Postgres extensions and tools
+navTitle: Supported extensions and tools
+description: Cloud Service supported postgres extensions and tools available for use with your cluster.
+---
+
+Cloud Service supports a number of Postgres extensions and tools, which you can install on or alongside your cluster.
+
+- See [Postgres extensions available by deployment](/pg_extensions/) for the complete list of extensions Cloud Service supports if you're using your own cloud account.
+
+- See [Postgres extensions](/edb-postgres-ai/cloud-service/using_cluster/managing_postgres_extensions/) for the list of extensions supported when using EDB Hosted Cloud Service account and for more information on installing and working with extensions.
+
+- Based on your subscription, you may be entitled to a subset of EDB tools that you can access via the EDB Repository. For instructions on using the EDB Repository, see [EDB Repository Access](https://info.enterprisedb.com/rs/069-ALB-339/images/Repository%20Access%2004-09-2019.pdf).
+
+### EDB Postgres extensions and tools
+
+EDB develops and maintains several extensions and tools. These include:
+
+- [EDB Advanced Storage Pack](/pg_extensions/advanced_storage_pack/) — Provides advanced storage options for PostgreSQL databases in the form of table access method (TAM) extensions. These storage options can enhance the performance and reliability of databases without requiring application changes.
+
+ The TAM extensions included in the Advanced Storage Pack include:
+
+ - [Autocluster](/pg_extensions/advanced_storage_pack/#autocluster) — Provides faster access to clustered data by keeping track of the last inserted row for any value in a side table.
+
+ - [Refdata](/pg_extensions/advanced_storage_pack/#refdata) — Can provide performance gains of 5-10% and increased scalability.
+
+
+- [EDB Postgres Tuner](/pg_extensions/pg_tuner/) — Provides safe recommendations that maximize the use of available resources.
+
+- [EDB Query Advisor](/pg_extensions/query_advisor/) — Provides index recommendations by keeping statistics on predicates found in WHERE statements, JOIN clauses, and workload queries.
+
+- [EDB Wait States](/pg_extensions/wait_states/) — Probes each of the running sessions at regular intervals.
+
+- [PG Failover Slots](/pg_extensions/pg_failover_slots/) — Is an extension released as open source software under the PostgreSQL License. If you have logical replication publications on Postgres databases that are also part of a streaming replication architecture, PG Failover Slots avoids the need for you to reseed your logical replication tables when a new standby gets promoted to primary.
+
+- [Foreign Data Wrappers](foreign_data_wrappers) — Allow you to connect your Postgres database server to external data sources.
+
+- [EDB PgBouncer](poolers) — Allows you to manage your connections to your Postgres database.
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_regions/country_reference.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_regions/country_reference.mdx
new file mode 100644
index 00000000000..9111306bddf
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_regions/country_reference.mdx
@@ -0,0 +1,263 @@
+---
+title: Country and geographical region reference
+---
+## Geographical regions
+
+| Geographical region | Short name |
+| ------------------------------- | ---------- |
+| North America | NA |
+| Latin America | LATAM |
+| Europe, Middle East, and Africa | EMEA |
+| Asia and Pacific | APAC |
+
+## Country by geographical region
+
+| Country | Region |
+| --------------------------------------------------- | ------ |
+| Afghanistan | EMEA |
+| Åland Islands | EMEA |
+| Albania | EMEA |
+| Algeria | EMEA |
+| American Samoa | APAC |
+| Andorra | EMEA |
+| Angola | EMEA |
+| Anguilla | LATAM |
+| Antarctica | EMEA |
+| Antigua and Barbuda | LATAM |
+| Argentina | LATAM |
+| Armenia | EMEA |
+| Aruba | LATAM |
+| Australia | APAC |
+| Austria | EMEA |
+| Azerbaijan | EMEA |
+| Bahamas | LATAM |
+| Bahrain | EMEA |
+| Bangladesh | APAC |
+| Barbados | LATAM |
+| Belarus | EMEA |
+| Belgium | EMEA |
+| Belize | LATAM |
+| Benin | EMEA |
+| Bermuda | LATAM |
+| Bhutan | APAC |
+| Bolivia, Plurinational State of | LATAM |
+| Bosnia and Herzegovina | EMEA |
+| Botswana | EMEA |
+| Bouvet Island | EMEA |
+| Brazil | LATAM |
+| British Indian Ocean Territory | APAC |
+| Brunei Darussalam | APAC |
+| Bulgaria | EMEA |
+| Burkina Faso | EMEA |
+| Burundi | EMEA |
+| Cabo Verde | EMEA |
+| Cambodia | APAC |
+| Cameroon | EMEA |
+| Canada | NA |
+| Cayman Islands | LATAM |
+| Central African Republic | EMEA |
+| Chad | EMEA |
+| Chile | LATAM |
+| China | APAC |
+| Christmas Island | APAC |
+| Cocos (Keeling) Islands | APAC |
+| Collectivity of Saint Martin | EMEA |
+| Colombia | LATAM |
+| Comoros | EMEA |
+| Congo | EMEA |
+| Congo, the Democratic Republic of the | EMEA |
+| Cook Islands | EMEA |
+| Costa Rica | LATAM |
+| Côte d'Ivoire | EMEA |
+| Croatia | EMEA |
+| Cuba | LATAM |
+| Curaçao | EMEA |
+| Cyprus | EMEA |
+| Czechia | EMEA |
+| Denmark | EMEA |
+| Djibouti | EMEA |
+| Dominica | LATAM |
+| Dominican Republic | LATAM |
+| Ecuador | LATAM |
+| Egypt | EMEA |
+| El Salvador | LATAM |
+| Equatorial Guinea | EMEA |
+| Eritrea | EMEA |
+| Estonia | EMEA |
+| Ethiopia | EMEA |
+| Falkland Islands (Malvinas) | LATAM |
+| Faroe Islands | EMEA |
+| Fiji | APAC |
+| Finland | EMEA |
+| France | EMEA |
+| French Guiana | EMEA |
+| French Polynesia | EMEA |
+| French Southern Territories | EMEA |
+| Gabon | EMEA |
+| Gambia | EMEA |
+| Georgia | EMEA |
+| Germany | EMEA |
+| Ghana | EMEA |
+| Gibralta | EMEA |
+| Greece | EMEA |
+| Greenland | EMEA |
+| Grenada | LATAM |
+| Guadeloupe | EMEA |
+| Guam | APAC |
+| Guatemala | LATAM |
+| Guernsey | EMEA |
+| Guinea | EMEA |
+| Guinea-Bissau | EMEA |
+| Guyana | LATAM |
+| Haiti | LATAM |
+| Heard Island and McDonald Islands | EMEA |
+| Holy See | EMEA |
+| Honduras | LATAM |
+| Hong Kong | APAC |
+| Hungary | EMEA |
+| Iceland | EMEA |
+| India | APAC |
+| Indonesia | APAC |
+| Iran, Islamic Republic of | EMEA |
+| Iraq | EMEA |
+| Ireland | EMEA |
+| Isle of Man | EMEA |
+| Israel | EMEA |
+| Italy | EMEA |
+| Jamaica | LATAM |
+| Japan | APAC |
+| Jersey | EMEA |
+| Jordan | EMEA |
+| Kazakhstan | EMEA |
+| Kenya | EMEA |
+| Kiribati | APAC |
+| Korea, Democratic People's Republic of | APAC |
+| Korea, Republic of | APAC |
+| Kuwait | EMEA |
+| Kyrgyzstan | EMEA |
+| Lao People's Democratic Republic | APAC |
+| Latvia | EMEA |
+| Lebanon | EMEA |
+| Lesotho | EMEA |
+| Liberia | EMEA |
+| Libya | EMEA |
+| Liechtenstein | EMEA |
+| Lithuania | EMEA |
+| Luxembourg | EMEA |
+| Macao | APAC |
+| Macedonia, the former Yugoslav Republic of | EMEA |
+| Madagascar | EMEA |
+| Malawi | EMEA |
+| Malaysia | APAC |
+| Maldives | APAC |
+| Mali | EMEA |
+| Malta | EMEA |
+| Marshall Islands | APAC |
+| Martinique | EMEA |
+| Mauritania | EMEA |
+| Mauritius | EMEA |
+| Mayotte | EMEA |
+| Mexico | LATAM |
+| Micronesia, Federated States of | APAC |
+| Moldova, Republic of | EMEA |
+| Monaco | EMEA |
+| Mongolia | APAC |
+| Montenegro | EMEA |
+| Montserrat | LATAM |
+| Morocco | EMEA |
+| Mozambique | EMEA |
+| Myanmar | APAC |
+| Namibia | EMEA |
+| Nauru | APAC |
+| Nepal | APAC |
+| Netherlands | EMEA |
+| New Caledonia | EMEA |
+| New Zealand | APAC |
+| Nicaragua | LATAM |
+| Niger | EMEA |
+| Nigeria | EMEA |
+| Niue | APAC |
+| Norfolk Island | APAC |
+| Northern Mariana Islands | APAC |
+| Norway | EMEA |
+| Oman | EMEA |
+| Pakistan | APAC |
+| Palau | APAC |
+| Palestine, State of | EMEA |
+| Panama | LATAM |
+| Papua New Guinea | APAC |
+| Paraguay | LATAM |
+| Peru | LATAM |
+| Philippines | APAC |
+| Pitcairn | APAC |
+| Poland | EMEA |
+| Portugal | EMEA |
+| Puerto Rico | LATAM |
+| Qatar | EMEA |
+| Réunion | EMEA |
+| Romania | EMEA |
+| Russian Federation | EMEA |
+| Rwanda | EMEA |
+| Saint Barthélemy | EMEA |
+| Saint Helena, Ascension and Tristan da Cunha | EMEA |
+| Saint Kitts and Nevis | LATAM |
+| Saint Lucia | LATAM |
+| Saint Pierre and Miquelon | EMEA |
+| Saint Vincent and the Grenadines | LATAM |
+| Samoa | APAC |
+| San Marino | EMEA |
+| Sao Tome and Principe | EMEA |
+| Saudi Arabia | EMEA |
+| Senegal | EMEA |
+| Serbia | EMEA |
+| Seychelles | EMEA |
+| Sierra Leone | EMEA |
+| Singapore | APAC |
+| Sint Maarten | EMEA |
+| Slovakia | EMEA |
+| Slovenia | EMEA |
+| Solomon Islands | APAC |
+| Somalia | EMEA |
+| South Africa | EMEA |
+| South Georgia and the South Sandwich Islands | LATAM |
+| South Sudan | EMEA |
+| Spain | EMEA |
+| Sri Lanka | APAC |
+| Sudan | EMEA |
+| Suriname | LATAM |
+| Swaziland | EMEA |
+| Sweden | EMEA |
+| Switzerland | EMEA |
+| Syrian Arab Republic | EMEA |
+| Taiwan, Province of China | APAC |
+| Tajikistan | EMEA |
+| Tanzania, United Republic of | EMEA |
+| Thailand | APAC |
+| Timor-Leste | APAC |
+| Togo | EMEA |
+| Tokelau | APAC |
+| Tonga | APAC |
+| Trinidad and Tobago | LATAM |
+| Tunisia | EMEA |
+| Turkey | EMEA |
+| Turkmenistan | EMEA |
+| Turks and Caicos Islands | LATAM |
+| Tuvalu | APAC |
+| Uganda | EMEA |
+| Ukraine | EMEA |
+| United Arab Emirates | EMEA |
+| United Kingdom of Great Britain and Northern Island | EMEA |
+| United States Minor Outlying Islands | APAC |
+| United States of America | NA |
+| Uruguay | LATAM |
+| Uzbekistan | EMEA |
+| Vanuatu | APAC |
+| Venezuela, Bolivarian Republic of | LATAM |
+| Vietnam | APAC |
+| Virgin Islands, British | LATAM |
+| Virgin Islands, U.S. | LATAM |
+| Wallis and Futuna | EMEA |
+| Western Sahara | EMEA |
+| Yemen | EMEA |
+| Zambia | EMEA |
+| Zimbabwe | EMEA |
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_regions/index.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_regions/index.mdx
new file mode 100644
index 00000000000..955153d4f4d
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_regions/index.mdx
@@ -0,0 +1,229 @@
+---
+title: "Supported regions"
+description: "CSP Regions supported by EDB Postgres AI Cloud Service"
+deepToC: true
+---
+
+Region support varies by whether you're using [your cloud account](#your-cloud-account) or [EDB Hosted Cloud Service account](#edb-hosted-cloud-service-account) as your [deployment option](/edb-postgres-ai/cloud-service/getting_started/planning/choosing_your_deployment/).
+
+See [Country and geographical region reference](country_reference) for information on geographical region short names and the countries that are in each geographical region.
+
+## Your cloud account
+
+When using your cloud account, to successfully deploy a cluster, you must activate the region to prepare its cloud infrastructure. See [Activating regions](/edb-postgres-ai/cloud-service/getting_started/your_cloud_account/managing_regions/) for more information.
+
+!!! Tip
+
+ You can select a cloud region for deploying your cluster even if it isn't yet active. However, your cluster creation request is added to a queue, and the cluster is created only after you activate the region.
+
+### Azure regions
+
+When using Azure, you can create clusters in the following regions.
+
+#### North America (NA)
+
+| Cloud region | Short name | Notes |
+| ---------------- | -------------- | -------------------------------------------------------- |
+| Canada Central | canadacentral | |
+| Central US | centralus | |
+| East US | eastus | |
+| East US 2 | eastus2 | |
+| South Central US | southcentralus | Not supported for distributed high-availability clusters |
+| West US 2 | westus2 | |
+| West US 3 | westus3 | |
+
+#### Latin America (LATAM)
+
+| Cloud region | Short name | Notes |
+| ------------ | ----------- | -------------------------------------------------------- |
+| Brazil South | brazilsouth | Not supported for distributed high-availability clusters |
+
+#### Europe, Middle East, and Africa (EMEA)
+
+| Cloud region | Short name | Notes |
+| -------------------- | ------------------ | -------------------------------------------------------- |
+| France Central | francecentral | Not supported for distributed high-availability clusters |
+| Germany West Central | germanywestcentral | |
+| North Europe | northeurope | |
+| Norway East | norwayeast | Not supported for distributed high-availability clusters |
+| UK South | uksouth | |
+| West Europe | westeurope | Not supported for distributed high-availability clusters |
+
+#### Asia and Pacific (APAC)
+
+| Cloud region | Short name | Notes |
+| -------------- | ------------- | ----- |
+| Australia East | australiaeast | |
+| Central India | centralindia | |
+| Japan East | japaneast | |
+| Southeast Asia | southeastasia | |
+
+### AWS regions
+
+When using AWS, you can create clusters in the following regions.
+
+#### North America (NA)
+
+| Cloud region | Short name |
+| --------------------- | ------------ |
+| Canada (Central) | ca-central-1 |
+| US East (N. Virginia) | us-east-1 |
+| US East (Ohio) | us-east-2 |
+| US West (Oregon) | us-west-2 |
+
+#### Europe, Middle East, and Africa (EMEA)
+
+| Cloud region | Short name |
+| ------------------ | ------------ |
+| Europe (Frankfurt) | eu-central-1 |
+| Europe (Ireland) | eu-west-1 |
+| Europe (London) | eu-west-2 |
+| Europe (Spain) | eu-south-2 |
+
+#### Asia and Pacific (APAC)
+
+| Cloud region | Short name | Notes |
+| ------------------------ | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Asia Pacific (Tokyo) | ap-northeast-1 | |
+| Asia Pacific (Seoul) | ap-northeast-2 | |
+| Asia Pacific (Mumbai) | ap-south-1 | |
+| Asia Pacific (Hyderabad) | ap-south-2 | |
+| Asia Pacific (Singapore) | ap-southeast-1 | |
+| Asia Pacific (Sydney) | ap-southeast-2 | |
+| Asia Pacific (Jakarta) | ap-southeast-3 | Enable the region through the [AWS console](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)
+__OUTPUT__
+Access key "ba-user-1" is imported, operation succeeded
+Switched the context credential to "ba-user-1".
+```
+
+!!!note
+Avoid adding an access key by way of the `import-access-key` command as plain text in flag mode. Instead you can use:
+
+`biganimal credential import-access-key --name --access-key $(< file_contains_the_key.txt)`
+
+Or, to avoid leaking the key into your shell command history, you can use interactive mode.
+!!!
+
+This example shows how to import an access key in interactive mode:
+
+```shell
+biganimal credential import-access-key
+? Credential Name: ba-user-2
+? Access Key: ******************************************************
+__OUTPUT__
+Access key "ba-user-2" is imported, operation succeeded
+Switched the context credential to "ba-user-2".
+```
+
+### Setting access key environment variable
+
+You can configure an environment variable `BA_ACCESS_KEY`. This setting overrides the default context credential. If you want to use the default context credential, then remove this environment variable, or set it to `""`.
+
+### Switching access keys
+
+You can import multiple access keys and then set one key as the default context credential for all commands. Use `credential show` to list all available credentials, and use `config set context_credential` to set a default credential.
+
+## Authenticating as a valid user
+
+Before using the CLI to manage Cloud Service, you need to authenticate as a valid Cloud Service user. Use the `credential create` command to authenticate through the Cloud Service website and assign a refresh token and an access token to a local credential. For example:
+
+```shell
+biganimal credential create\
+ --name "ba-user1"
+__OUTPUT__
+Querying Authentication Endpoint for 'portal.biganimal.com'
+First, copy your one-time code:
+ CWWG-SMXC
+Then visit: https://auth.biganimal.com/activate
+press [Enter] to continue in the web browser...
+
+Credential "ba-user1" created!
+```
+
+Refresh tokens expire after 30 days. To continue using the credential to access the CLI, use the `credential reset` command to authenticate through the Cloud Service website and receive a new refresh token:
+
+```shell
+biganimal credential reset ba-user1
+__OUTPUT__
+Visit this URL to login: https://auth.biganimal.com/activate?user_code=****-****
+or press [Enter] to continue in the web browser
+
+Credential "ba-user1" reset operation succeeded
+
+```
+
+You can create multiple credentials for different Cloud Service accounts and then set one as context of your current management session. Use `credential show` to list all available credentials, and use `config set context_credential` to set a default credential for the current context. For example:
+
+```shell
+biganimal credential show
+__OUTPUT__
+┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
+│ Credentials │
+├──────────────┬──────────────┬─────────────────┬──────────────────────┬──────────────────────┬──────┬─────────┤
+│ name │ type │ key │ organization │ address │ port │ context │
+├──────────────┼──────────────┼─────────────────┼──────────────────────┼──────────────────────┼──────┼─────────┤
+│ ba-user1 │ AccessKey │ baak_1e2vAJO*** │ │ portal.biganimal.com │ 443 │ x │
+│ ba-user2 │ ClassicToken │ │ My_organization │ portal.biganimal.com │ 443 │ │
+└──────────────┴──────────────┴─────────────────┴──────────────────────┴──────────────────────┴──────┴─────────┘
+```
+
+
+```shell
+biganimal config set context_credential ba-user1
+```
+
+## Creating credentials for an alternative organization
+
+The Cloud Service CLI supports the capability to create credentials for an alternative organization to which you have been invited or are already a member. You can invite users that have an EDB account to join an organization by selecting the **Invite New User** option on the Users page in the Console.
+
+To create credentials for an alternative organization, you can use either interactive mode or specify the settings with flags on the command line:
+
+- Select the organization from the list in interactive mode:
+
+ ```shell
+ biganimal credential create
+ __OUTPUT__
+ ? Credential Name: ba-user2
+ ? Organization: [Use arrows to move, type to filter]
+ My_Organization
+ > My_Organization_2
+
+ ? Organization: My_Organization_2
+ Credential "ba-user2" is created operation succeeded
+ Switched the context credential to "ba-user2".
+ ```
+
+- Specify the organization name in the `credential create` command:
+
+ ```shell
+ biganimal credential create -name ba-user2 --organization "My_Organization_2"
+ ```
+
+You can verify the operation using `credential show`:
+
+```shell
+biganimal credential show
+__OUTPUT__
+┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
+│ Credentials │
+├──────────────┬──────────────┬─────────────────┬──────────────────────┬──────────────────────┬──────┬─────────┤
+│ name │ type │ key │ organization │ address │ port │ context │
+├──────────────┼──────────────┼─────────────────┼──────────────────────┼──────────────────────┼──────┼─────────┤
+│ ba-user2 │ ClassicToken │ │ org_aNR9SNuNcUN6vGSn │ portal.biganimal.com │ 443 │ x │
+└──────────────┴──────────────┴─────────────────┴──────────────────────┴──────────────────────┴──────┴─────────┘
+```
+
+## Configuring
+The initial running of the CLI creates a hidden configuration folder in your user root directory. For example, for Linux it’s `${HOME}/.edb-cli`. The CLI persists the configuration file in this directory as well as the credentials.
+
+Don’t edit files in this directory directly. Instead, use the `config` subcommand to list and update the configuration settings of the CLI. Use the following command to get detailed usage and available configurations information:
+```shell
+biganimal config
+```
+
+### Available configuration settings
+
+| Setting | Description |
+|----------------------|----------------------------------------------------------------------------------------------------------------------------------|
+| `context_credential` | The default credential used in the following commands. |
+| `context_project` | The default project used to run the following commands. |
+| `output_mode` | The command line output format: table, json, xml, or yaml. |
+| `confirm_mode` | If enabled, create/update/delete commands require user confirmation. |
+| `interactive_mode` | If enabled, CLI prompts for missing flags and available options. See [Interactive mode](#interactive-mode) for more information. |
+| `check_update_mode` | If enabled, CLI detects new updates and prompts for download. |
+| `warning_mode` | If enabled, CLI displays warning messages. |
+
+## Usability features
+
+### Online command reference and help
+Use the `-h` or `--help` flags for more information on the CLI commands. You can use these flags on the `biganimal` command to get a listing of all the available subcommands (`biganimal -h`) or on a subcommand to get information on that particular command (for example, `biganimal create cluster -h`).
+
+### Interactive mode
+In interactive mode, the CLI prompts you for any missing mandatory flags and lists any available options for your current context. To enable interactive mode:
+
+```shell
+biganimal config set interactive_mode on
+```
+
+## Sample use cases
+
+See:
+
+- [Managing clusters with the CLI](managing_clusters)
+- [Accessing Cloud Service features with the CLI](using_features)
diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/using_cluster/cli/managing_clusters.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/using_cluster/cli/managing_clusters.mdx
new file mode 100644
index 00000000000..9ffe5013bc7
--- /dev/null
+++ b/advocacy_docs/edb-postgres-ai/cloud-service/using_cluster/cli/managing_clusters.mdx
@@ -0,0 +1,750 @@
+---
+title: Managing clusters using the CLI
+navTitle: Managing clusters
+deepToC: true
+---
+
+These examples show Azure as the cloud provider unless indicated otherwise.
+
+Although the functionality is the same when using AWS or Google Cloud, there may be additional input flags based on the cloud provider type. Use the `-h` or `--help` flags for more information on the CLI commands.
+
+## Managing single-node and primary/standby high-availability clusters
+
+Use the `cluster` commands to create, retrieve information on, and manage single-node and primary/standby high-availability clusters.
+
+### Create a cluster in interactive mode
+
+The default mode for the `cluster create` and `pgd create` commands is an interactive mode that guides you through the required cluster configuration by providing you with the valid values.
+
+!!!Tip
+You can turn off prompting using the `biganimal config set interactive_mode off` command. With prompting disabled, if any required flags are missing, the CLI exits with an error.
+!!!
+
+For example, to create a primary/standby high-availability cluster:
+
+```shell
+biganimal cluster create
+__OUTPUT__
+Cluster architecture: Primary/Standby High Availability
+Number of standby replicas: 2 Replicas
+Enable read-only workloads: No
+Provider: Azure
+Cloud Provider Subscription ID: "111,222"
+Service Account IDs, (leave empty to stop adding): "id1@iam.gcp"
+Cluster Name: my-biganimal-cluster
+Password: ****************
+PostgreSQL type: EDB Postgres Advanced Server
+PostgreSQL version: 14
+Region: East US
+Instance type: E2s v3(2vCPU, 16GB RAM)
+Volume type: Azure Premium Storage
+Volume properties: P1 (4 Gi, 120 Provisioned IOPS, 25 Provisioned MB/s)
+Networking: Public
+By default your cluster allows all inbound communications, add IP allowed list to restrict the access: Yes
+Add CIDR blocks "192.168.1.1/16=Sample Description" leave empty to stop adding:
+Add database config in the format "application_name=sample_app&array_nulls=true", Leave empty for default configuration:
+Backup Retention Period, note backups will incur storage charges from the cloud provider directly. e.g. "7d", "2w" or "3m": 30d
+```
+
+You're prompted to confirm that you want to create the cluster. After the cluster creation process is complete, it generates a cluster ID.
+
+```shell
+biganimal cluster create
+__OUTPUT__
+........
+Are you sure you want to Create Cluster ? [y|N]: y
+Create Cluster operation is started
+Cluster ID is "p-gxhkfww1fe"
+To check current state, run: biganimal cluster show --id p-gxhkfww1fe
+```
+
+Check your cluster was created successfully using the `cluster show` command shown in the return message:
+
+```shell
+biganimal cluster show --id p-gxhkfww1fe
+__OUTPUT__
+
+┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
+│ Clusters │
+├──────────────┬──────────────────────┬──────────┬──────────────┬──────────────────────────┬─────────────┬───────────────┬───────────────────────────────┬────────────────────┬────────────┤
+│ ID │ Name │ Provider │ Architecture │ Status │ Region │ Instance Type │ Postgres Details │ Maintenance Window │ FAReplicas │
+├──────────────┼──────────────────────┼──────────┼──────────────┼──────────────────────────┼─────────────┼───────────────┼───────────────────────────────┼────────────────────┼────────────┤
+│ p-gxhkfww1fe │ my-biganimal-cluster │ Azure │ ha │ Cluster in healthy state │ East US │ E2s v3 │ EDB Postgres Advanced Server │ Disabled │ N/A │
+│ │ │ │ │ │ │ │ │ │ │
+└──────────────┴──────────────────────┴──────────┴──────────────┴──────────────────────────┴─────────────┴───────────────┴───────────────────────────────┴────────────────────┴────────────┘
+```
+
+### Create a cluster using a configuration file
+
+You can use the `create --config-file` command to create one or more clusters with the same configuration in a noninteractive mode.
+
+Here's a sample configuration file in YAML format with Azure specified as the provider:
+
+```yaml
+# config_file.yaml
+---
+clusterArchitecture: ha #
+haStandbyReplicas: 2 #
+provider: azure #
+cspSubscriptionIDs: #
+ - 123123123 #
+ - 456456456 #
+serviceAccountIds: #
+ - service-account-1234567b@development-data-123456.iam.gserviceaccount.com#
+ - service-account-1234567b@development-data-123456.iam.gserviceaccount.com#
+clusterName: biganimal_cluster #
+password: ************ #
+# refer following link for steps to setup IAM: https://www.enterprisedb.com/docs/biganimal/latest/using_cluster/01_postgres_access/iam-authentication-for-postgres
+iamAuthentication: true #
+postgresType: epas #
+postgresVersion: 14 #
+region: eastus #
+instanceType: azure:Standard_E2s_v3 #
+volumeType: azurepremiumstorage #
+volumeProperties: P1 #
+volumePropertySize: 4Gi #
+volumePropertyIOPS: 1000 # : Not Applicable to Azure Premium Storage and GCP:[pd-ssd], volume Input/Output Operations Per Second>
+networking: public #
+allowIpRangeMap: #
+ - cidr: 9.9.9.9/28 #
+ description: Allow traffic from App A #
+ - cidr: 10.10.10.10/27 #
+ description: Allow traffic from App B #
+readOnlyWorkloads: true #
+pgConfigMap: #
+ application_name: test_app #
+ array_nulls: true #
+backupRetentionPeriod: 30d #
+superuserAccess: true #
+pgvector: true #
+postgis: true #
+```
+
+!!! Note
+For backward compatibility, `allowIpRangeMap` and `pgConfigMap` properties also support embedded JSON format.
+ ```json
+ allowIpRangeMap: [["9.9.9.9/28", "Allow traffic from App A"],["10.10.10.10/27", "Allow traffic from App B"]]
+ pgConfigMap: [["application_name","test_app"],["array_nulls","true"]]
+ ```
+!!!
+
+To create the cluster using the sample configuration file `config_file.yaml`:
+
+```shell
+biganimal cluster create --config-file "./config_file.yaml"
+```
+
+To enable you to view valid values to use in the configuration file for Cloud Service and cloud service provider-related properties, the CLI provides a series of cluster subcommands. For example, you can use `cluster show-architectures` to list all Cloud Service database architectures available in your cloud service provider account:
+
+```shell
+biganimal cluster show-architectures
+__OUTPUT__
+┌───────────────────────────────────────────────────────────────┐
+│ Architecture │
+├────────┬───────────────────────────────────────────┬──────────┤
+│ ID │ Name │ Status │
+├────────┼───────────────────────────────────────────┼──────────┤
+│ ha │ Primary/Standby High Availability │ enabled │
+│ pgd │ Extreme High Availability │ disabled │
+│ single │ Single Node │ enabled │
+└────────┴───────────────────────────────────────────┴──────────┘
+```
+
+!!!Tip
+You can turn off the confirmation step with the `biganimal disable-confirm` command.
+!!!
+
+### Get cluster connection information
+
+To use your Cloud Service cluster, you first need to get your cluster's connection information. To get your cluster's connection information, use the `cluster show-connection` command:
+
+```shell
+biganimal cluster show-connection \
+ --name "my-biganimal-cluster" \
+ --provider "azure" \
+ --region "eastus"
+__OUTPUT__
+┌───────────────-----------──┬──────────────────────────────────────────────────────────────────────────────────────────┐
+│ Name │ Details │
+├────────────────-----------─┼──────────────────────────────────────────────────────────────────────────────────────────┤
+│ read-write-connection │ postgresql://edb_admin@p-gxhkfww1fe.30glixgayvwhtmn3.enterprisedb.network:5432/edb_admin │
+│ rw-service-name │ postgresql://edb_admin@p-gxhkfww1fe.30glixgayvwhtmn3.enterprisedb.network:5432/edb_admin │
+│ read-only-connection │ Disabled │
+│ ro-service-name │ Disabled │
+└─────────────────-----------┴──────────────────────────────────────────────────────────────────────────────────────────┘
+```
+
+!!!tip
+You can query the complete connection information with other output formats, like JSON or YAML. For example:
+
+```shell
+biganimal cluster show-connection \
+ --name "my-biganimal-cluster" \
+ --provider "azure" \
+ --region "eastus" \
+ --output "json"
+```
+!!!
+
+### Update cluster
+
+After the cluster is created, you can update attributes of the cluster, including both the cluster’s profile and its deployment architecture. You can update the following attributes:
+
+- Cluster name
+- Password of administrator account
+- Cluster architecture
+- Number of standby replicas
+- Instance type of cluster
+- Instance volume properties
+- Networking
+- Allowed IP list
+- Postgres database configuration
+- Volume properties, size, IOPS
+- Retention period
+- Read-only workloads
+- IAM authentication
+- Cloud service provider subscription IDs
+- Service account IDs
+
+For example, to set the public allowed IP range list, use the `--cidr-blocks` flag:
+
+```shell
+./biganimal cluster update --name "my-biganimal-cluster" --provider "azure" \
+ --region "eastus" \
+ --cidr-blocks "9.9.9.9/28=Traffic from App A"
+```
+
+To check whether the setting took effect, use the `cluster show` command, and view the detailed cluster information output in JSON format. For example:
+
+```shell
+biganimal cluster show --name "my-biganimal-cluster" --provider "azure" \
+ --region "eastus" \
+ --output "json" \
+| jq '.[0].allowIpRangeMap'
+__OUTPUT__
+[
+ [
+ "9.9.9.9/28",
+ "Traffic from App A"
+ ]
+]
+```
+
+### Update the Postgres configuration of a cluster
+
+To update the Postgres configuration of a Cloud Service cluster directly from the CLI:
+
+```shell
+biganimal cluster update --id "p-gxhkfww1fe" \
+ --pg-config "application_name=ba_test_app,array_nulls=false"
+__OUTPUT__
+Update Cluster operation is started
+Cluster ID is "p-gxhkfww1fe"
+```
+To specify multiple configurations, you can use multiple `--pg-config` flags or include multiple configuration settings as a key-value array string separated by commas in one `--pg-config` flag. If a Postgres setting contains a comma, you need to specify it with a separate `--pg-config` flag.
+
+!!! Note
+You can update the cluster architecture with the `--cluster-architecture` flag. The only supported scenario is to update a single-node cluster to a primary/standby high-availability cluster.
+!!!
+
+### Delete a cluster
+
+To delete a cluster you no longer need, use the `cluster delete` command. For example:
+
+```shell
+biganimal cluster delete \
+ --name "my-biganimal-cluster" \
+ --provider "azure" \
+ --region "eastus"
+```
+
+You can list all deleted clusters using the `biganimal cluster show --deleted` command and restore them from their history backups as needed.
+
+
+### Restore a cluster
+Cloud Service continuously backs up your PostgreSQL clusters. Using the CLI, you can restore a cluster from its backup to any point in time as long as the backups are retained in the backup storage. The restored cluster can be in another region and have different configurations. You can specify new configurations in the `cluster restore` command. For example:
+
+```shell
+biganimal cluster restore\
+ --name "my-biganimal-cluster" \
+ --provider "azure" \
+ --region "eastus" \
+ --password "mypassword@123" \
+ --new-name "my-biganimal-cluster-restored" \
+ --new-region="eastus2" \
+ --cluster-architecture "single" \
+ --instance-type "azure:Standard_E2s_v3" \
+ --volume-type "azurepremiumstorage" \
+ --volume-property "P1" \
+ --networking "public" \
+ --cidr-blocks="10.10.10.10/27=Traffic from App B" \
+ --restore-point "2022-01-26T15:04:05+0800" \
+ --backup-retention-period "2w" \
+ --postgis=true
+ --pgvector=true
+ --read-only-workloads: "true"
+ --csp-subscription-ids "123123123,456456456"
+ --service-account-ids "service-account-1234567b@development-data-123456.iam.gserviceaccount.com,
+service-account-1234567b@development-data-123456.iam.gserviceaccount.com"
+ --credential "my_credential"
+```
+
+The password for the restored cluster is mandatory. The other parameters, if not specified, inherit the source database's settings.
+
+To restore a deleted cluster, use the `--from-deleted` flag in the command.
+
+!!! Note
+You can restore a cluster in a single cluster to a primary/standby high-availability cluster and vice versa. You can restore a distributed high-availability cluster only to a cluster using the same architecture.
+!!!
+
+### Pause a cluster
+
+To pause a cluster, use the `cluster pause` command. The `cluster pause` command supports `flag` or `interactive` mode. The syntax for the command is:
+
+```
+biganimal cluster pause {--id | --provider --region --name}
+```
+
+Where:
+- `id` is a valid cluster ID.
+- `provider` is a cloud provider of the cluster.
+- `region` is the cluster region.
+- `name` is the name of the cluster.
+
+If you don't know the `id` of the cluster, use `--provider --region --name` to identify the cluster.
+
+The following examples show common uses of the `cluster pause` command.
+
+To pausing a cluster using the ID:
+
+```
+biganimal cluster pause --id p-c5fh47nf
+```
+
+To pause a cluster using the name, provider, and region:
+
+```
+biganimal cluster pause
+--name my-cluster
+--provider azure
+--region eastus2
+```
+
+To pause a cluster in interactive mode:
+
+```
+./biganimal cluster pause
+? Provider: AWS (Your Cloud Account)
+? Region: AP South 1
+? Cluster Name: user1-test-tags-IA
+__OUTPUT__
+Pause Cluster operation succeeded, "p-94pjd2w0ty"
+```
+
+### Resume a cluster
+
+To resume a cluster, use the `cluster resume` command. The `cluster resume` command supports `flag` and `interactive` mode. The syntax for the command is:
+
+```
+biganimal cluster resume {--id | --provider --region --name}
+```
+
+Where:
+- `id` is a valid cluster ID.
+- `provider` is a cloud provider of the cluster.
+- `region` is the cluster region.
+- `name` is the name of the cluster.
+
+If you don't know the `id` of the cluster, use `--provider --region --name` to identify the cluster.
+
+The following examples show common uses of the `cluster resume` command.
+
+To resume a cluster using the ID:
+
+```
+biganimal cluster resume --id p-c5fh47nf
+```
+
+To resuming a cluster using the name, provider, and region:
+
+```
+biganimal cluster resume
+--name my-cluster
+--provider azure
+--region eastus2
+```
+
+To resume a cluster using interactive mode:
+
+```
+./biganimal cluster resume
+? Provider: AWS (Your Cloud Account)
+? Region: AP South 1
+? Cluster Name: user1-test-tags-IA
+__OUTPUT__
+Resume Cluster operation succeeded, "p-94pjd2w0ty"
+```
+
+
+## Managing distributed high-availability clusters
+
+Use the Cloud Service `pgd` commands to create, retrieve information on, and manage distributed high-availability clusters.
+
+!!!note
+ In addition to the Cloud Service `pgd` commands, you can switch over and use commands available in the [EDB Postgres Distributed CLI](/pgd/latest/cli/) to perform PGD-specific operations. The only EDB Postgres Distributed CLI commands that don't apply to Cloud Service are `create-proxy` and `delete-proxy`.
+
+
+### Create a distributed high-availability cluster
+
+Create a distributed high-availability cluster using a YAML configuration file.
+
+The syntax of the command is:
+
+```
+biganimal pgd create --config-file
+```
+
+Where `` is a valid path to a YAML configuration file.
+
+#### Azure example
+
+```
+clusterName: biganimal-azure-pgd-cluster
+password: Meredith Palmer Memorial
+postgresType: epas
+postgresVersion: "14"
+provider: azure
+dataNodes: 2
+dataGroups:
+ - iamAuthentication: false
+ region: westus2
+ instanceType: azure:Standard_E2s_v3
+ volumeType: azurepremiumstorage
+ volumeProperties: P2
+ customMaintenanceWindow:
+ maintenanceStartTime: 18:00
+ maintenanceStartDay: wednesday
+ networking: public
+ allowIpRangeMap:
+ - cidr: 9.9.9.9/28
+ description: Allow traffic from App A
+ - cidr: 10.10.10.10/27
+ description: Allow traffic from App B
+ pgConfigMap:
+ application_name: test
+ array_nulls: true
+ backupRetentionPeriod: 30d
+ - iamAuthentication: false
+ region: canadacentral
+ instanceType: azure:Standard_E2s_v3
+ volumeType: azurepremiumstorage
+ volumeProperties: P2
+ customMaintenanceWindow:
+ maintenanceStartTime: 18:00
+ maintenanceStartDay: tuesday
+ networking: public
+ allowIpRangeMap:
+ - cidr: 9.9.9.9/28
+ description: Allow traffic from App A
+ - cidr: 10.10.10.10/27
+ description: Allow traffic from App B
+ pgConfigMap:
+ application_name: test1
+ array_nulls: true
+ backupRetentionPeriod: 30d
+witnessGroups:
+ - provider: azure
+ region: uksouth
+ customMaintenanceWindow:
+ maintenanceStartTime: 18:00
+ maintenanceStartDay: monday
+```
+
+#### AWS example
+
+```
+clusterName: biganimal-aws-pgd-cluster #
+password: Meredith Palmer Memorial #
+postgresType: pgextended # (only epas is supported in pgd preview)
+postgresVersion: 16 #
+provider: aws #
+dataNodes: 2 #
+dataGroups: #
+ region: ap-south-1 #
+ instanceType: aws:c5.large #
+ volumeType: gp3 #
+ volumeProperties: gp3 #
+ volumePropertySize: 32Gi #
+ volumePropertyIOPS: 3000 # : Not Applicable to Azure Premium Storage and GCP:[pd-ssd], volume Input/Output Operations Per Second>
+ customMaintenanceWindow: #
+ maintenanceStartTime: 15:00 #
+ maintenanceStartDay: monday #
+ networking: public #
+ allowIpRangeMap: #
+ - cidr: 9.9.9.9/28 #
+ description: Allow traffic from App A #
+ - cidr: 10.10.10.10/27 #
+ description: Allow traffic from App B #
+ pgConfigMap: #
+ application_name: test_app #
+ array_nulls: true #
+ backupRetentionPeriod: 30d #
+
+ - iamAuthentication: false #
+ region: eu-south-2 #
+ instanceType: aws:c5.large #
+ volumeType: gp3 #
+ volumeProperties: gp3 #
+ volumePropertySize: 32Gi #
+ volumePropertyIOPS: 3000 # : Not Applicable to Azure Premium Storage and GCP:[pd-ssd], volume Input/Output Operations Per Second>
+ customMaintenanceWindow: #
+ maintenanceStartTime: 17:00 #
+ maintenanceStartDay: tuesday #
+ networking: public #
+ allowIpRangeMap: #
+ - cidr: 9.9.9.9/28 #
+ description: Allow traffic from App A #
+ - cidr: 10.10.10.10/27 #
+ description: Allow traffic from App B #
+ pgConfigMap: #
+ application_name: test_app #
+ array_nulls: true #
+ backupRetentionPeriod: 30d #
+# cspSubscriptionIds: #
+# - 123123123 #
+# - 456456456 #
+# serviceAccountIds: #
+# - service-account-1234567b@development-data-123456.iam.gserviceaccount.com#
+# - service-account-1234567b@development-data-123456.iam.gserviceaccount.com#
+
+witnessGroups: #
+ region: australiaeast #
+ customMaintenanceWindow: #
+ maintenanceStartTime: 18:00 #
+ maintenanceStartDay: monday #
+```
+
+#### Google Cloud example
+
+```
+clusterName: biganimal-gcp-pgd-cluster #
+password: Meredith Palmer Memorial #
+postgresType: epas # (only epas is supported in pgd preview)
+postgresVersion: 16 #
+provider: gcp #
+dataNodes: 3 #
+dataGroups: #
+ region: europe-west1 #
+ instanceType: gcp:e2-highcpu-4 #
+ volumeType: pd-ssd #
+ volumeProperties: gp3 #
+ volumePropertySize: 32Gi #
+# volumePropertyIOPS: 4000 # : Not Applicable to Azure Premium Storage and GCP:[pd-ssd], volume Input/Output Operations Per Second>
+ customMaintenanceWindow: #
+ maintenanceStartTime: 15:00 #
+ maintenanceStartDay: monday #
+ networking: public #
+ allowIpRangeMap: #
+ - cidr: 9.9.9.9/28 #
+ description: Allow traffic from App A #
+ - cidr: 10.10.10.10/27 #
+ description: Allow traffic from App B #
+ pgConfigMap: #
+ application_name: test_app #
+ array_nulls: true #
+ backupRetentionPeriod: 30d #
+
+ - iamAuthentication: false #
+ region: asia-south1 #
+ instanceType: gcp:c2-standard-16 #
+ volumeType: pd-ssd #
+ volumeProperties: gp3 #
+ volumePropertySize: 32Gi #
+# volumePropertyIOPS: 4000 # : Not Applicable to Azure Premium Storage and GCP:[pd-ssd], volume Input/Output Operations Per Second>
+ customMaintenanceWindow: #
+ maintenanceStartTime: 18:00 #
+ maintenanceStartDay: monday #
+ networking: public #
+ allowIpRangeMap: #
+ - cidr: 9.9.9.9/28 #
+ description: Allow traffic from App A #
+ - cidr: 10.10.10.10/27 #
+ description: Allow traffic from App B #
+ pgConfigMap: #
+ application_name: test_app #
+ array_nulls: true #
+ backupRetentionPeriod: 30d #
+# cspSubscriptionIds: #
+# - 123123123 #
+# - 456456456 #
+# serviceAccountIds: #
+# - service-account-1234567b@development-data-123456.iam.gserviceaccount.com#
+# - service-account-1234567b@development-data-123456.iam.gserviceaccount.com#
+
+witnessGroups: #
+ region: australiaeast #
+ customMaintenanceWindow: #
+ maintenanceStartTime: 21:00 #
+ maintenanceStartDay: monday #
+```
+
+### Add a data group
+
+Add a data group using a YAML configuration file.
+
+The syntax of the command is:
+
+```
+biganimal pgd add-group --config-file 
+
+
-
-