Looking at your CloudFormation template, the reason your instances are clustered in two AZs is that you haven't explicitly specified the AvailabilityZone property for each DB instance. AWS assigns AZs automatically when this property is omitted, which can lead to uneven distribution.

Here's how to modify your template to spread the three instances across ap-southeast-2a, ap-southeast-2b, and ap-southeast-2c evenly:

AuroraDBFirstInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    DBInstanceClass: ${self:custom.postgresqlInstanceClass}
    Engine: aurora-postgresql
    EngineVersion: ${self:custom.postgresqlEngineVersion}
    DBClusterIdentifier: !Ref AuroraDBCluster
    PubliclyAccessible: ${self:custom.publiclyAccessible}
    AvailabilityZone: ap-southeast-2a  # Explicitly assign to AZ 2a

AuroraDBSecondInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    DBInstanceClass: ${self:custom.postgresqlInstanceClass}
    Engine: aurora-postgresql
    EngineVersion: ${self:custom.postgresqlEngineVersion}
    DBClusterIdentifier: !Ref AuroraDBCluster
    PubliclyAccessible: ${self:custom.publiclyAccessible}
    AvailabilityZone: ap-southeast-2b  # Match your existing writer instance's AZ

AuroraDBThirdInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    DBInstanceClass: ${self:custom.postgresqlInstanceClass}
    Engine: aurora-postgresql
    EngineVersion: ${self:custom.postgresqlEngineVersion}
    DBClusterIdentifier: !Ref AuroraDBCluster
    PubliclyAccessible: ${self:custom.publiclyAccessible}
    AvailabilityZone: ap-southeast-2c  # Assign to the third AZ in the region

Key Notes: #

• Ensure your Aurora cluster is configured to allow instances in all three AZs (this is enabled by default when creating a cluster in a region with multiple AZs).
• If you want to keep your existing writer instance in ap-southeast-2b, assign that AZ to one of the instances (I’ve mapped AuroraDBSecondInstance to 2b here). AWS will retain the writer’s AZ unless you later promote a reader to writer.
• After updating the CloudFormation stack, AWS will either provision the new instance in ap-southeast-2c (if unused) or move an existing reader to 2c. Note that moving an instance requires a reboot, so plan for minimal downtime if needed.

If you’re starting from scratch or adding instances to an existing cluster, here are reliable methods to ensure even AZ distribution:

1. CloudFormation (As Demonstrated) #

Always include the AvailabilityZone property for each AWS::RDS::DBInstance resource, specifying a distinct AZ for each instance. For regions with more than three AZs, you can rotate assignments for extra redundancy.

2. AWS Management Console #

• Creating a cluster: During the "Configure advanced settings" step, under "Instance configuration", specify the AZ for your initial writer instance.
• Adding readers: Navigate to your Aurora cluster dashboard, select "Actions" > "Add reader", then pick an AZ different from existing instances in the "Availability zone" dropdown.

3. AWS CLI #

Use the create-db-instance command with the --availability-zone parameter to target a specific AZ:

aws rds create-db-instance \
  --db-instance-identifier my-aurora-reader-2c \
  --db-cluster-identifier my-aurora-cluster \
  --db-instance-class db.t3.small \
  --engine aurora-postgresql \
  --availability-zone ap-southeast-2c

Critical Considerations: #

• All Aurora cluster instances must reside in the same region, but spanning AZs boosts high availability.
• Spreading instances across AZs ensures automatic failover to a reader in another AZ if one zone goes down (multi-AZ support is enabled by default for Aurora clusters).
• For PostgreSQL-compatible Aurora, failover is seamless if at least one reader exists in a different AZ from the writer.

内容的提问来源于stack exchange，提问作者Joey Yi Zhao