YugabyteDB Aeon — Immutable & mutable cluster settings

Reference for which Aeon cluster settings are fixed at creation versus changeable later. Based on official YugabyteDB Aeon documentation and our Terraform provider definitions; compiled by Matthias Käppler in work item 587284. Linked from the YugabyteDB Aeon runbook.

Settings that require a new cluster (immutable after create)

These must be chosen correctly at initial provisioning. Changing them later requires creating a new cluster and typically migrating via backup/restore (or equivalent cutover).

Setting	What is fixed at create
Cloud provider	AWS, Azure, or GCP — no cross-provider migration
Topology / data distribution	Single-region to multiple regions, or partition by region — no documented in-place conversion between modes
Cluster type (API/Terraform)	SYNCHRONOUS vs GEO_PARTITIONED
VPC	The VPC assigned to the cluster cannot be switched after creation. VPC CIDR/size cannot be changed after the VPC is created. On GCP custom VPCs, you cannot add new regions to the VPC after creation — include all planned regions when the VPC is created.
Primary region(s)	For single-region and replicate-across-regions clusters, the deployment region(s) are fixed; scaling applies within those regions only
Security profile	Standard vs Advanced — Advanced requires VPC, disallows public access, and enforces scheduled backups; profile is selected at create
Database release track	Extended vs Rapid — upgrades stay on the track chosen at create
Initial DB admin credentials (Terraform/API)	Set at creation only
Multi-cloud placement	If a cluster is created as single-cloud but must later support multi-cloud read replicas, it may need to be recreated on the correct YBM infrastructure — backup/restore to a new cluster is the supported path

Docs: VPC overview · Plan your cluster · Choose a topology · YBM FAQ (tier & release track)

Settings that can be changed on the existing cluster

Setting	Notes
Node count, vCPUs, disk (increase), IOPS	Via Edit Infrastructure
Preferred region	On replicate-across-regions clusters
Read replicas	Add, edit, remove, scale
Partition-by-region secondary regions	Can add regions; non-primary regions can be removed after dropping tablespaces
Connection pooling	Enable/disable post-create
Enhanced Postgres Compatibility	Toggle post-create
Public access	Can enable/disable (except Advanced security profile clusters)
Encryption at rest (CMK/EAR)	Enable, disable, or rotate post-create (supported DB versions)
IP allow lists, backup schedules, pause/resume, DB upgrades	Standard cluster management
Private Service Endpoint (PSC/PSE)	Can be added to an existing cluster — not a recreation blocker

Docs: Scale and configure clusters · Read replicas · Encryption at rest · Connection pooling

Same cluster, but with constraints

Setting	Constraint
Fault tolerance	Not changeable in the UI; changeable via API/CLI
Disk size	Increase only — cannot decrease
FT = NONE clusters	vCPUs cannot be changed; disk/IOPS changes cause downtime
Advanced security profile	Scheduled backups cannot be disabled
CMK-enabled clusters	Fault tolerance cannot be NONE
AWS disk/IOPS	6-hour cooldown after disk or IOPS changes

Practical guidance for GitLab (GCP us-east1 prod)

For the current plan — single-region GCP prod with future AWS read replicas — the main recreation risk is infrastructure placement at create time, not PSC/PSE or connection pooling:

1. Confirm topology and multi-cloud intent before provisioning.
2. Size the GCP VPC/CIDR for prod scale at VPC create (VPC cannot be resized later).
3. Choose the Extended release track and Advanced security profile at create if those are prod requirements — both are fixed afterward.
4. PSC/PSE, connection pooling, CMK, scaling, and read replicas can be handled on the same cluster without recreation.

Source document