Amazon Aurora separates database compute from a distributed storage layer, which changes how architects think about high availability compared with a traditional database server and attached disk. A regional Aurora cluster can keep copies of data across multiple Availability Zones and promote a replica when the writer fails. Aurora Global Database extends the design across Regions for local reads and regional recovery, but the data model still needs a clearly understood write path.<\/p>\n
The current SAA-C03<\/a> perspective includes resilient and high-performing database design. Aurora is useful because several availability mechanisms can be combined: multi-AZ storage, read replicas, automatic failover, backups and point-in-time recovery, and cross-Region global clusters. The architecture is strongest when each mechanism is mapped to a specific failure mode.<\/p>\n Aurora stores a cluster volume across three Availability Zones in a Region and maintains multiple copies of the data. Current AWS documentation describes six-way replication across three AZs and storage that is designed to tolerate the loss of copies while preserving read and write availability. The storage layer is shared by the DB instances in the cluster.<\/p>\n This means a reader instance does not maintain an independent copy of the entire database in the same way a traditional asynchronous replica might. Writer and Aurora Replicas use the same distributed cluster volume. Failover can therefore promote a replica without copying the database first.<\/p>\n A general database clustering<\/a> model is useful, but Aurora\u2019s architecture should be understood on its own terms. Compute failover and storage durability are related but separate layers.<\/p>\n An Aurora cluster can include multiple Aurora Replicas. These readers can serve read traffic and are candidates for promotion when the writer instance fails. AWS allows failover tiers so architects can influence which replica should become the new writer based on instance capacity or placement.<\/p>\n Application connection behavior matters during failover. Use cluster and reader endpoints appropriately rather than hard-coding an instance endpoint that becomes stale after promotion. Connection pools and DNS caching should also respond quickly enough to the endpoint change for the business RTO.<\/p>\n Replica capacity should match the role it may inherit. A very small reader is economical for analytics traffic but may be a poor failover target for a large writer. Availability design should account for the capacity needed after promotion, not only the steady-state read workload.<\/p>\n Instance failure can often be handled by promoting another DB instance in the same cluster. Because the storage spans multiple AZs, the cluster is not dependent on the local disk of the failed writer. An AZ failure can be handled by promoting a replica in another AZ if the cluster was deployed with appropriate instances across zones.<\/p>\n Keep client infrastructure redundant too. If the application instances, NAT path, or load balancer exist in only one AZ, database multi-AZ resilience does not make the whole service highly available. End-to-end availability is a property of the request path.<\/p>\n The availability objective<\/a> should therefore include the application and database together. A database SLA cannot compensate for a single-AZ application tier.<\/p>\n Aurora provides automatic continuous backups and point-in-time recovery within the configured retention period, and it supports manual snapshots that remain until deleted. These mechanisms address data corruption, accidental changes, and historical recovery in ways that high-availability replicas do not.<\/p>\n Replication is not backup. A mistaken DELETE statement or corrupted logical value can be replicated quickly to every live replica. Recovery points preserve the ability to restore an earlier state. The recovery process should include how applications reconnect to the restored cluster and how data written after the recovery point is reconciled if necessary.<\/p>\n A broader backup strategy<\/a> helps place database-native recovery alongside account isolation, cross-Region copies, and retention governance.<\/p>\n Aurora Global Database links a primary cluster with secondary clusters in other AWS Regions. The primary writer remains the source of truth, while storage-based replication sends changes to secondary Regions. Secondary clusters can serve local reads, reducing read latency for globally distributed users.<\/p>\n For an unplanned regional outage, a secondary Region can be promoted through a global database failover. AWS describes the RPO as typically nonzero and dependent on replication lag at the time of failure. That makes monitoring replication lag part of disaster-recovery readiness.<\/p>\n For planned operations, a global database switchover synchronizes the secondary before changing the primary, allowing a zero-data-loss planned transition. Treat switchover and failover as different operating procedures rather than interchangeable buttons.<\/p>\n Global write forwarding can allow applications connected to a secondary Aurora cluster to issue supported write statements that are forwarded to the primary cluster. This can simplify application connection logic for workloads that mostly read locally but occasionally need to write.<\/p>\n The data still changes on the primary cluster first. Write forwarding therefore does not make every Region an independent writer. Cross-Region latency remains part of the write path, and supported SQL behavior, transactions, and consistency settings need to be reviewed for the database engine and version.<\/p>\n If the application truly needs multi-active regional writes, evaluate whether another data model such as DynamoDB global tables fits better. Technology choice should follow write semantics, not the desire to label an architecture \u201cactive-active.\u201d<\/p>\n Promoting a database in another Region is only one step in regional recovery. The application tier, secrets, certificates, DNS or global routing, queues, object storage, observability, and security controls must also exist or be recoverable in the destination Region. Database recovery should be embedded in a complete regional runbook.<\/p>\nUnderstand the storage architecture before the failover features<\/h3>\n
Use Aurora Replicas for availability and read scaling<\/h3>\n
Distinguish instance failure from Availability Zone failure<\/h3>\n
Use backups for point-in-time recovery and historical state<\/h3>\n
Use Aurora Global Database for cross-Region reads and recovery<\/h3>\n
Understand what global write forwarding does and does not do<\/h3>\n
Design regional failover for the whole application stack<\/h3>\n