Setting the file. One moment.
Chapter 57 · Amazon Aurora MySQL
Subchapter 57.16
references/serverless-advisory-migration.mdMarkdown7 KBView on GitHub
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 and so the customer (or their IaC stack) can execute them safely.
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):
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.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-db-cluster with --target-db-instance-identifier.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.
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.
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.
aurora-mysql8.0).innodb_buffer_pool_size, innodb_purge_threads, table_definition_cache, table_open_cache. Remove explicit overrides of these 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.innodb_buffer_pool_size, innodb_buffer_pool_instances, and innodb_log_file_size — Aurora serverless manages buffer-pool sizing with ACU.Resources:
ClusterParameterGroup:
Type: AWS::RDS::DBClusterParameterGroup
Properties:
Family: aurora-mysql8.0
Description: Enforce TLS for Aurora serverless cluster
Parameters:
require_secure_transport: "ON"
AuroraCluster:
Type: AWS::RDS::DBCluster
Properties:
Engine: aurora-mysql
EngineVersion: "8.0.mysql_aurora.3.08.0"
DBClusterParameterGroupName: !Ref ClusterParameterGroup
ServerlessV2ScalingConfiguration:
MinCapacity: 2
MaxCapacity: 64
StorageEncrypted: true
EnableCloudwatchLogsExports:
- error
- slowquery
- audit
WriterInstance:
Type: AWS::RDS::DBInstance
Properties:
DBInstanceClass: db.serverless
Engine: aurora-mysql
DBClusterIdentifier: !Ref AuroraClusterThe custom cluster parameter group enforces require_secure_transport=ON (the Aurora MySQL equivalent of PostgreSQL’s rds.force_ssl=1). The Aurora MySQL default.* parameter groups ship with require_secure_transport=OFF, 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.
const parameterGroup = new rds.ParameterGroup(this, 'PG', {
engine: rds.DatabaseClusterEngine.auroraMysql({
version: rds.AuroraMysqlEngineVersion.VER_3_08_0,
}),
parameters: { 'require_secure_transport': 'ON' },
});
const cluster = new rds.DatabaseCluster(this, 'Cluster', {
engine: rds.DatabaseClusterEngine.auroraMysql({
version: rds.AuroraMysqlEngineVersion.VER_3_08_0,
}),
parameterGroup,
serverlessV2MinCapacity: 2,
serverlessV2MaxCapacity: 64,
writer: rds.ClusterInstance.serverlessV2('writer'),
readers: [
rds.ClusterInstance.serverlessV2('reader', {
scaleWithWriter: true,
}),
],
storageEncrypted: true,
cloudwatchLogsExports: ['error', 'slowquery', 'audit'],
});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.