Express Create Migration

Express Configuration mechanics may evolve. Verify in the AWS User Guide before migrating, especially for production-adjacent clusters.

In-place conversion

AWS provides no modify-db-cluster operation that flips an express cluster into a customer VPC — no “convert to VPC-attached Full Configuration” button or call. What AWS does document is restoring out of the express flow: a snapshot or point-in-time restore lands in a full-configuration VPC cluster by default. If AWS later publishes in-place conversion (a modify flag or wizard), update this file.

Pick the path that matches your cluster size, downtime tolerance, and connectivity:

• Snapshot-and-restore — simplest, widest applicability.
• Logical replication — lowest downtime; suitable when both clusters reach the same replication orchestrator.
• pg_dump / pg_restore — quickest for small datasets where a maintenance window is acceptable.

Path 1: Snapshot and restore

Best for most migrations, especially with a short maintenance window.

1. Snapshot the Express cluster. Source: Creating a DB cluster snapshot (opens in a new tab).
2. Stop application writes (writes after the snapshot are lost unless you add a logical-replication catch-up pass).
3. Restore the snapshot to a new Aurora PostgreSQL cluster in Full Configuration mode, in the target VPC and subnet group, with customer security groups, customer-managed KMS key, and customer parameter group as needed. Source: Restoring from a DB cluster snapshot (opens in a new tab).
4. Validate the restored cluster — connectivity, extensions, roles, data integrity.
5. Update the application’s connection string to the new endpoint.
6. Decommission the Express cluster once the new cluster is stable.

KMS: an Express cluster is encrypted at rest with an AWS owned key (SSE-RDS), which customers cannot view or manage. If the target must use a customer-managed KMS key, snapshot-and-restore with a key change is the standard Aurora pattern. Source: Copying an encrypted snapshot to a different KMS key (opens in a new tab). Verify in the AWS User Guide.

Engine version: restore must target a version supported for restore from the source snapshot. The express flow applies the AWS default engine version; if the target needs a different major version, route the user to aurora-upgrade-advisor for post-restore upgrade planning.

Downtime scales with cluster size; the application is unavailable from when writes stop until cutover.

Path 2: Logical replication

Best for migrations with strict downtime targets, typically production-adjacent workloads.

1. Create the target Full Configuration cluster in your VPC, with the desired engine version, parameter group, and KMS key.
2. Set up logical replication from the Express source to the target. Two mechanisms are common with Aurora PostgreSQL:
   • PostgreSQL built-in logical replication (PUBLICATION / SUBSCRIPTION, PostgreSQL 10+). Source: PostgreSQL Logical Replication documentation (opens in a new tab).
   • pglogical extension. Source: Using the pglogical extension on Aurora PostgreSQL (opens in a new tab). Verify availability in the AWS User Guide.
3. Let the target catch up. Validate row counts, sequences, and non-replicated objects (DDL, large objects, certain extensions).
4. Cut over: stop source writes, wait for the target to reach the final LSN, then point the application at the target.
5. Decommission the Express cluster.

Prerequisites:

• Connectivity: the target must reach the Express cluster over its public endpoint (or vice versa), and your replication orchestrator must reach both. Because Express clusters sit behind the AWS-managed connectivity layer (not a customer VPC), network planning differs from VPC-to-VPC replication — verify in the AWS User Guide.
• Version compatibility: both clusters must run a PostgreSQL version that supports the chosen mechanism.
• Parameters: logical replication requires wal_level = logical, max_replication_slots, and max_wal_senders on the source. Whether the Express flow permits these changes is subject to change — verify in the AWS User Guide.

Downtime shrinks to the cutover moment (seconds to a few minutes), not the full data copy time.

Path 3: pg_dump / pg_restore

Best for small datasets where a maintenance window is acceptable. Full steps, commands, and considerations: migration-pgdump.md. Downtime is dump + restore time, scaling roughly linearly with data size; for anything larger than a dev dataset, Path 1 or Path 2 is usually better.

Choosing a path

When in doubt, start with Path 1: most broadly documented and fastest for most Express clusters (which tend to be small and dev-shaped).

Verify before migrating

Before executing any path, verify in the AWS Aurora User Guide:

• Whether AWS has published an in-place conversion path, new migration tooling, or wizards since this file was written.
• AWS documents this explicitly — a default restore (restore-db-cluster-from-snapshot or restore-db-cluster-to-point-in-time without EnableVPCNetworking/EnableInternetAccessGateway) lands in a full-configuration VPC cluster; restoring back to express requires VPCNetworkingEnabled=false and InternetAccessGatewayEnabled=true. Verify the restore-target constraints (engine version, KMS, storage type).
• Whether the Express cluster’s parameter group can be adjusted to enable logical replication (wal_level = logical, max_replication_slots, max_wal_senders).

Do not skip verification for production-adjacent clusters. The AWS User Guide is authoritative; this file is a planning aid.

Source documentation

Links for each step appear inline above. Additional references:

• Create with express configuration: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html (opens in a new tab)
• Aurora serverless: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html (opens in a new tab)