Aurora serverless — Migration & Configuration

This file advises on migration approaches — it never supplies runnable mutation commands. The skill is assessment-only. Mutation actions belong in the customer's change-control process; this file describes the console paths and flag names so the customer (or their IaC stack) can execute them safely.

Migration Approaches (three options)

1. In-Place Modification (minimal downtime)

Add an Aurora serverless reader, test under production traffic, failover to promote it, remove old instances. Steps, with their console path or flag name (never a runnable command):

Add a serverless reader. RDS console → Databases → your cluster → Actions → Add reader. Set the instance class to db.serverless. The underlying API is create-db-instance with --db-instance-class db.serverless, but run it through your IaC / change-control tool, not ad-hoc.
Set scaling configuration. RDS console → your cluster → Modify → Aurora serverless scaling configuration → set MinCapacity and MaxCapacity (typically 2 and your expected peak ACU). The underlying API is modify-db-cluster with --serverless-v2-scaling-configuration MinCapacity=N,MaxCapacity=M.
Failover to promote the serverless reader. RDS console → your cluster → Actions → Failover, choosing the serverless reader as the target. The underlying API is failover-db-cluster with --target-db-instance-identifier.
Remove the old provisioned instance. RDS console → your cluster → the old instance → Actions → Delete. The underlying API is delete-db-instance.

Testing window. Observe the serverless reader under production traffic for at least 24 hours before the failover. Monitor ServerlessDatabaseCapacity in CloudWatch to confirm ACU actually scales up under load.

2. Blue/Green Deployment (recommended for production)

Create a Blue/Green deployment. The green environment is a new cluster (pointed at a new Aurora serverless writer) built as a replica of blue. Test green under mirrored load, then switchover. Rollback is trivial — the blue environment is still intact until you explicitly delete it.

Console path: RDS console → Databases → your cluster → Actions → Create blue/green deployment. API endpoint (for reference, not to run ad-hoc): create-blue-green-deployment. Switchover API endpoint: switchover-blue-green-deployment. Both belong in your change-control workflow.

3. Snapshot Restore (cutover window, highest isolation)

Snapshot the provisioned cluster, restore to a new Aurora serverless cluster, validate end-to-end, then cutover application connections. Highest isolation and test fidelity; requires a maintenance window because the application cuts between two clusters.

Console path: RDS console → your cluster → Actions → Take snapshot → (wait) → Actions → Restore snapshot → set writer instance class to db.serverless. API endpoints: create-db-cluster-snapshot, restore-db-cluster-from-snapshot.

Parameter Group Considerations (critical for Aurora serverless)

Aurora serverless uses the same parameter-group families as provisioned (e.g., aurora-postgresql16).
During scaling, Aurora serverless dynamically resizes shared_buffers and IGNORES any custom value you set. Remove explicit overrides of it before migrating — they will be ignored by the auto-scaling mechanism.
max_connections does NOT scale up/down with ACU — Aurora holds it CONSTANT, derived from the MAXIMUM ACU (not current capacity), as a static parameter that requires a reboot to change. You may still customize it via a formula in a custom parameter group; if you do, prefer a formula tied to capacity rather than a fixed constant.
Aurora PostgreSQL also computes these from the MAXIMUM ACU (like max_connections): autovacuum_max_workers, autovacuum_vacuum_cost_limit, autovacuum_work_mem, effective_cache_size, maintenance_work_mem.
work_mem is NOT Aurora-managed — it behaves exactly as on a provisioned instance (inherited from the cluster parameter group, user-tunable). It does not auto-scale with ACU, so do not assume Aurora sizes it for you.
Common pre-serverless overrides to remove are shared_buffers, maintenance_work_mem, effective_cache_size (the latter two are computed from the maximum ACU). work_mem is not auto-scaled and need not be removed.
Custom parameters for logging, auth, or specific extensions can stay — they don't interact with ACU scaling.

CloudFormation snippet (for IaC migration)

Resources:
  ClusterParameterGroup:
    Type: AWS::RDS::DBClusterParameterGroup
    Properties:
      Family: aurora-postgresql16
      Description: Enforce TLS for Aurora serverless cluster
      Parameters:
        rds.force_ssl: "1"
  AuroraCluster:
    Type: AWS::RDS::DBCluster
    Properties:
      Engine: aurora-postgresql
      EngineVersion: "16.4"
      DBClusterParameterGroupName: !Ref ClusterParameterGroup
      ServerlessV2ScalingConfiguration:
        MinCapacity: 2
        MaxCapacity: 64
      StorageEncrypted: true
      EnableCloudwatchLogsExports:
        - postgresql
  WriterInstance:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceClass: db.serverless
      Engine: aurora-postgresql
      DBClusterIdentifier: !Ref AuroraCluster

The custom cluster parameter group enforces rds.force_ssl=1 (use require_secure_transport=ON for Aurora MySQL). The Aurora PostgreSQL default.* parameter groups ship with rds.force_ssl=0, so a migration that reuses the default would silently drop the in-transit TLS requirement the skill mandates for production.

This is a definition of Aurora serverless infrastructure for your IaC stack (CloudFormation, Terraform, or CDK). Deploy it through your normal change-control process — this skill does not run CloudFormation for you.

CDK (TypeScript) snippet

const parameterGroup = new rds.ParameterGroup(this, 'PG', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_4,
  }),
  parameters: { 'rds.force_ssl': '1' },
});
const cluster = new rds.DatabaseCluster(this, 'Cluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_4,
  }),
  parameterGroup,
  serverlessV2MinCapacity: 2,
  serverlessV2MaxCapacity: 64,
  writer: rds.ClusterInstance.serverlessV2('writer'),
  readers: [
    rds.ClusterInstance.serverlessV2('reader', {
      scaleWithWriter: true,
    }),
  ],
  storageEncrypted: true,
  cloudwatchLogsExports: ['postgresql'],
});

This skill describes what to do and where to do it. It does not emit copy-pasteable mutation commands. If you need the exact CLI for a migration step, copy the API endpoint name from this file (e.g., modify-db-cluster) and build the command yourself from the AWS CLI reference — or use the console path described above. That keeps change-control in your team's hands, which is where it belongs.

/amazon-aurora-postgresql

referencesserverless-advisory-migration.md