Amazon
Aurora PostgreSQL Global Database
Step-by-Step Guide to Adding a Secondary Region, Switchover and Failover
A practical implementation guide based on an Aurora
PostgreSQL Global Database test across Mumbai and Hyderabad
Figure 1: Example Aurora PostgreSQL Global Database
architecture
1. Introduction
Amazon Aurora Global Database is designed
to provide cross-Region disaster recovery and low-latency read capability. In
this implementation, an Aurora PostgreSQL database is deployed as a Global
Database with a primary cluster in Asia Pacific (Mumbai) and a secondary
cluster in Asia Pacific (Hyderabad).
This article documents the complete
workflow: creating or identifying the Global Database, adding the secondary
Region, validating the topology, performing a planned switchover, testing an
emergency failover, and validating the final roles.
2. Implementation Overview
|
Component |
Example used in this
implementation |
|
Engine |
Amazon Aurora PostgreSQL |
|
Global database |
datalblogs-global |
|
Initial primary Region |
Asia Pacific (Mumbai) – ap-south-1 |
|
Secondary Region |
Asia Pacific (Hyderabad) – ap-south-2 |
|
Initial primary cluster |
datalblogs-prod |
|
Secondary cluster |
datalblogs-prod-dr |
|
Initial writer instance |
datalblogs-mumbai |
|
Secondary reader instance |
datalblogs-hydrabad |
|
Instance class shown in test |
db.r5.large |
3. Important Findings and Recommendations
3.1 Instance Class Consideration
During the implementation, the Global
Database workflow was evaluated using a supported database instance class. A
general-purpose burstable T-series instance family should not be assumed to be
supported for this Aurora Global Database design. For the implementation, use
an instance class explicitly supported by the selected Aurora PostgreSQL engine
version and Region.
|
Recommendation: Before creating the secondary cluster, verify
instance-class availability in both Regions. For this test, db.r5.large was
used. Do not select a T-series family simply because it is available for
another RDS workload. |
3.2 Secrets Manager Consideration
Credential and secret handling must be
validated before production implementation. In the tested add-Region workflow,
the required credential/Secrets Manager behavior did not provide the expected
direct reuse of the primary database secret. Therefore, do not assume that the
primary Region secret is automatically replicated or reused by the secondary
Region.
Recommended approach: document the
credential strategy before deployment, verify the exact Aurora PostgreSQL and
AWS Region behavior in the console or CLI, and test application connectivity
after the secondary cluster is created.
|
Important: Treat Secrets Manager support and secret replication as
configuration-specific. Validate this in your AWS account and selected engine
version before production. Do not rely on automatic secret replication unless
it is explicitly confirmed. |
3.3 Switchover vs Failover
These operations are different and should
be used for different situations:
|
Operation |
When to use it |
Data-loss expectation |
|
Switchover |
Planned maintenance, Regional rotation, DR exercise |
Designed as a planned role change; validate application impact and
completion. |
|
Failover |
Regional outage or emergency where the primary is unavailable |
May result in data loss because replication is asynchronous. |
Figure 2: Recommended implementation and DR testing
workflow
4. Step 1 – Verify the Primary Aurora PostgreSQL Cluster
Figure 19.1: Initial Aurora PostgreSQL Global Database
overview.
Before adding a secondary Region, confirm
that the source Aurora PostgreSQL cluster is healthy and available.
·
The Aurora PostgreSQL cluster
status is Available.
·
The writer instance is healthy.
·
The correct engine and engine
version are identified.
·
The VPC, subnets, security
groups, parameter groups, and KMS requirements are documented.
·
The selected instance class is
available and supported in the target Region.
· A backup and rollback plan exists before any production role change.
5. Step 2 – Create or Identify the Global Database
Figure 19.2: Global Database actions and implementation
workflow.
From the Amazon RDS console, select the
Aurora PostgreSQL cluster and create or identify the Global Database. In this
example, the Global Database identifier is datalblogs-global.
Expected initial topology:
·
Global database:
datalblogs-global
·
Primary cluster:
datalblogs-prod
·
Primary Region: ap-south-1
(Mumbai)
· Writer instance: datalblogs-mumbai
6. Step 3 – Add the Secondary AWS Region
Figure 19.3: Add AWS Region configuration screen.
Figure 19.4: Secondary Region and database configuration
options.
Figure 19.5: Additional configuration for the secondary
Region deployment.
Figure 19.6: Database and instance configuration details.
Select the Global Database in the Amazon
RDS console and choose Actions → Add AWS Region. Choose the target secondary
Region. In this implementation, the secondary Region is Asia Pacific
(Hyderabad), ap-south-2.
Configure the following items:
·
Global database identifier
·
Secondary AWS Region
·
Aurora PostgreSQL configuration
options
·
Supported DB instance class
·
Secondary DB instance
identifier
·
Secondary DB cluster identifier
·
Networking and security
settings
·
Encryption/KMS requirements
· Credential and secret handling strategy
Example CLI Structure
If the secondary cluster and instance
already exist as part of the Global Database workflow, use the identifiers
generated by the deployment. A representative instance creation structure is
shown below. Replace all example identifiers with your own values.
aws rds create-db-instance \
--region ap-south-2 \
--db-instance-identifier
datalblogs-hydrabad \
--db-cluster-identifier
datalblogs-prod-dr \
--db-instance-class db.r5.large \
--engine aurora-postgresql
|
Recommendation: Do not blindly use an instance class from another
Region or deployment. Confirm that the selected class is supported for Aurora
PostgreSQL and available in ap-south-2. |
7. Step 4 – Wait for the Secondary Cluster to Become
Available
Figure 19.8: Global Database status during the implementation workflow.
The secondary cluster and its reader
instance may initially show Creating or Modifying. Wait until the Global
Database and all required clusters and instances reach the expected stable
state.
Verify:
·
Global Database status is
Available.
·
Primary cluster status is
Available.
·
Secondary cluster status is
Available.
·
The secondary Region shows the
expected cluster and reader instance.
· The topology shows two Regions.
8. Step 5 – Validate the Global Database Topology
Figure 19.7: Global Database topology showing the
participating resources.
Before testing DR operations, verify the
role of every resource. The expected initial state is:
|
Resource |
Region |
Role |
Expected state |
|
datalblogs-global |
2 Regions |
Global database |
Available |
|
datalblogs-prod |
ap-south-1 |
Primary cluster |
Available |
|
datalblogs-mumbai |
ap-south-1a |
Writer instance |
Available |
|
datalblogs-prod-dr |
ap-south-2 |
Secondary cluster |
Available |
|
datalblogs-hydrabad |
ap-south-2a |
Reader instance |
Available |
9. Step 6 – Perform a Planned Switchover
Figure 19.10: Switchover/Failover operation dialog and
confirmation.
Figure 19.11: Global Database topology before or during role
transition.
A switchover is the recommended operation
for a planned DR test or planned Regional role change. From the Global
Database, choose Actions → Switchover or Failover global database.
Then:
1.
Select Switchover.
2.
Choose the active secondary
cluster as the new primary cluster.
3.
Review the selected target
Region and cluster.
4.
Confirm the operation.
5.
Monitor the Global Database
status while the role change is in progress.
During the operation, the console may display statuses such as Switching over or Modifying. Do not initiate another role change until the operation completes.
10. Step 7 – Validate the Successful Switchover
Figure 19.12: Role transition status and resource state
validation.
After a successful switchover in this
implementation, the Hyderabad secondary cluster became the new primary cluster,
and the former Mumbai primary cluster became a secondary cluster.
|
Resource |
Region after
switchover |
Role after switchover |
Expected state |
|
datalblogs-prod-dr |
ap-south-2 (Hyderabad) |
Primary cluster |
Available |
|
datalblogs-hydrabad |
ap-south-2a |
Writer instance |
Available |
|
datalblogs-prod |
ap-south-1 (Mumbai) |
Secondary cluster |
Available |
|
datalblogs-mumbai |
ap-south-1a |
Reader instance |
Available |
11. Step 8 – Test Failover (Emergency Scenario Only)
Figure 19.13: Failover confirmation dialog and operational
warning.
Failover should be tested carefully because
it is intended for an unplanned primary Region failure. The console explicitly
warns that failover can result in data loss.
To perform the test:
6.
Select the Global Database.
7.
Choose Actions → Switchover or
Failover global database.
8.
Select Failover (allow data
loss).
9.
Choose the secondary cluster to
promote.
10.
Enter the required confirmation
text.
11.
Confirm the operation and
monitor progress.
|
Warning: Perform
this only in a controlled non-production environment unless there is an
actual disaster. Record replication status, application transactions, and
recovery results as part of the DR test. |
12. Step 9 – Validate the Successful Failover
Figure 19.14: Global Database status after role transition.
Figure 19.15: Final topology validation after the tested
operation.
After the failover completes, the selected
secondary cluster becomes the primary cluster. The former primary cluster is
represented as a secondary cluster after the topology stabilizes and
resynchronization proceeds.
Validate the following:
·
Global Database status returns
to Available.
·
The promoted cluster is Primary
cluster.
·
The promoted instance is Writer
instance.
·
The former primary is no longer
serving as the primary writer.
·
The secondary cluster
resynchronizes successfully.
·
Applications connect to the
correct writer endpoint.
· Read traffic and monitoring are healthy.
13. Application and Endpoint Validation
A database role change is not complete
until the application path is validated. After switchover or failover:
·
Verify the application
connection string and DNS strategy.
·
Confirm that write traffic
reaches the current writer.
·
Validate read-only workloads
against the intended reader endpoint.
·
Test authentication and
credential retrieval.
·
Verify Secrets Manager
integration according to the chosen credential design.
·
Review connection pools and
reconnect behavior.
·
Check CloudWatch metrics, logs,
and database events.
14. Production Readiness Checklist
☐ Supported Aurora PostgreSQL engine
version confirmed
☐ Supported DB instance class confirmed in
both Regions
☐ Primary and secondary Region topology
documented
☐ VPC, subnets, security groups and routing
validated
☐ KMS/encryption design validated
☐ Secrets Manager and credential strategy
tested
☐ Application endpoint strategy tested
☐ Switchover procedure tested
☐ Failover procedure tested in a controlled
environment
☐ Data-loss expectations documented for
failover
☐ Monitoring and alerting configured
☐ Runbook and rollback/recovery procedure
approved
15. Key Lessons Learned
·
A Global Database provides a
clear cross-Region topology, but the secondary Region must be planned with
supported instance classes and compatible configuration.
·
Do not assume that a T-series
instance family is suitable for every Aurora Global Database deployment. Verify
support for the exact engine version and Region.
·
Do not assume that Secrets
Manager credentials or secrets are automatically handled identically across
Regions. Validate the credential design before production.
·
Use Switchover for planned role
changes and DR exercises.
·
Use Failover only for emergency
situations and understand the possibility of data loss.
·
Always validate the final
cluster and instance roles after the operation.
·
Application connectivity and
writer endpoint validation are as important as the database control-plane
operation.
16. Managed and Non-Managed Instance Launch and Disaster
Recovery
16.1 Overview
The Aurora PostgreSQL Global Database
architecture should support both AWS-managed recovery mechanisms and documented
DBA-operated manual recovery procedures. The recovery method must be selected
according to the scope of the incident, the availability of the primary Region,
and the required Recovery Time Objective (RTO).
The recommended model is a hybrid approach
consisting of:
·
AWS-managed high availability
and failover for normal database and instance-level failures.
·
Managed Aurora Global Database
switchover for planned Regional role changes and DR exercises.
·
Managed Global Database
failover for an unplanned Regional disaster, subject to the applicable
data-loss considerations.
·
Manual or non-managed DB
instance launch procedures as an operational fallback when replacement capacity
or additional instances are required.
16.2 AWS-Managed Recovery Method
For normal instance and writer failures,
Amazon Aurora provides managed high-availability behavior. Where an eligible
reader instance is available, Aurora can perform failover operations without
requiring the DBA to manually build a replacement database server.
Typical managed recovery flow:
12.
Aurora detects the database or
writer instance failure.
13.
The cluster selects an
available eligible reader instance.
14.
The selected instance is
promoted to the writer role.
15.
Applications reconnect using
the appropriate database endpoint strategy.
16.
The DBA validates database
availability, application connectivity, and monitoring.
16.3 Managed Regional Disaster Recovery
For this implementation, the Aurora Global
Database spans Mumbai (ap-south-1) as the primary Region and Hyderabad
(ap-south-2) as the secondary/DR Region. A planned role change should use
Switchover. An unplanned Regional disaster should follow the Global Database
Failover procedure and the organization's approved DR runbook.
16.4 Non-Managed / Manual Recovery Method
A manual recovery procedure is required as
a fallback for scenarios where managed recovery alone does not meet the
operational requirement. Examples include a need to create an additional reader
instance, replace a missing instance, restore DR capacity, or perform
controlled recovery activities after a complex incident.
Manual intervention may be required for:
·
Additional DR read capacity.
·
Replacement of a failed or
deleted reader instance.
·
Creation of a new DB instance
in the DR cluster.
·
Operational recovery after an
infrastructure-level incident.
·
Validation of capacity and
Availability Zone placement after a disaster.
16.5 Manual DB Instance Launch in the DR Region
Figure 18.1: Existing Global Database topology before
creating the additional DR reader instance.
Figure 18.2: Aurora Global Database view showing the primary
and secondary clusters.
Figure 18.4: New DR reader instance creation in progress and
subsequent topology verification.
The DBA can launch a new Aurora PostgreSQL
DB instance inside the existing DR cluster using the AWS Management Console,
AWS CLI, or an approved Infrastructure-as-Code process. The screenshots below
demonstrate the manual creation of a reader instance in the Hyderabad DR
Region.
Example implementation:
·
DR Region: ap-south-2
·
DR Cluster: datalblogs-prod-dr
·
DB Instance:
datalblogs-hydrabad
·
DB Instance Class:
db.r5.largege
·
Engine: aurora-postgresql
16.6 Manual Launch Using AWS CLI
Figure 18.3: AWS CLI command used to create the DR Aurora
PostgreSQL DB instance in ap-south-2.
Representative AWS CLI command:
aws rds create-db-instance \
--region ap-south-2 \
--db-instance-identifier
datalblogs-hydrabad \
--db-cluster-identifier
datalblogs-prod-dr \
--db-instance-class db.r5.large \
--engine aurora-postgresql
Verify the instance creation status:
aws rds
describe-db-instances \
--region ap-south-2 \
--db-instance-identifier
datalblogs-hydrabad
Wait until the DB instance reaches the
Available state before considering the recovery activity complete. The DBA
should then verify the reader role, cluster membership, application
connectivity, monitoring, and capacity.
16.7 Managed vs Non-Managed Recovery Comparison
|
Area |
Managed Recovery |
Non-Managed / Manual Recovery |
|
Primary use |
Normal HA and supported failover scenarios |
Exceptional recovery and capacity replacement |
|
Human intervention |
Minimal |
Required |
|
Instance failover |
Aurora-managed where supported |
DBA performs documented recovery actions |
|
Additional instance launch |
Preplanned capacity or managed topology |
DBA launches a new instance |
|
Operational speed |
Typically faster |
Depends on DBA response and provisioning time |
|
Control |
AWS-managed workflow |
Greater DBA control |
|
Best suited for |
Routine failures and planned operations |
Complex incidents and manual fallback |
16.8 Disaster Recovery Decision Matrix
|
Failure Scenario |
Recommended Action |
|
Single reader instance failure |
Validate Aurora-managed recovery; replace or launch a new reader
if required. |
|
Writer instance failure |
Use Aurora-managed failover behavior and validate the promoted
writer. |
|
Planned DR exercise |
Perform Global Database Switchover. |
|
Primary Region outage |
Follow the approved Global Database Failover runbook and validate
data-loss implications. |
|
Additional DR capacity required |
Manually launch an additional Aurora DB instance in the DR
cluster. |
|
Complex recovery or missing capacity |
Use the documented non-managed/manual recovery procedure. |
16.9 Post-Recovery Validation Checklist
·
Confirm Global Database,
primary cluster, secondary cluster, and DB instance statuses.
·
Confirm the correct writer and
reader roles.
·
Verify replication and Global
Database topology.
·
Verify application connectivity
and endpoint/DNS behavior.
·
Validate critical read and
write transactions.
·
Check CloudWatch metrics, logs,
and database events.
·
Confirm security groups, VPC
connectivity, and Availability Zone placement.
·
Document the incident, recovery
action, recovery duration, and any lessons learned.
16.10 Key Recommendation
Use AWS-managed recovery as the primary mechanism for supported high-availability failures and maintain a tested manual/non-managed runbook as a fallback. The runbook should include both AWS Console and AWS CLI procedures for launching replacement or additional Aurora PostgreSQL instances in the DR Region.
17. Conclusion
This document provides a complete implementation and operational runbook for an Amazon Aurora PostgreSQL Global Database deployed across Mumbai (ap-south-1) and Hyderabad (ap-south-2). It covers the complete lifecycle—from validating the primary cluster and configuring the Global Database to adding the secondary Region, launching the DR reader instance, validating cross-Region replication, performing planned switchovers, testing failover scenarios, and completing post-recovery checks.
For production environments, AWS-managed recovery should be the primary approach. Aurora-managed failover, Global Database switchover, and failover operations help reduce manual intervention and support a controlled recovery process. However, a tested manual recovery procedure should also be maintained as a fallback for scenarios such as additional DR capacity requirements, reader instance replacement, or complex disaster situations.
A successful HA/DR strategy depends on more than database replication. Before production deployment, teams should validate supported Aurora PostgreSQL versions and instance classes, network and security configurations, KMS and credential requirements, application endpoints and DNS behavior, monitoring, logging, and alerting.
In summary, the recommended approach is a hybrid model: use AWS-managed HA and DR capabilities as the primary recovery mechanism while maintaining a validated manual instance-launch and recovery procedure as a fallback. Regular DR testing, documented runbooks, and thorough post-recovery validation are essential to ensure a reliable and operationally manageable cross-Region disaster recovery solution.
0 Comments