Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon Aurora provides several deployment patterns for high availability, read scaling, cross-Region disaster recovery, and variable database capacity. The correct choice depends on whether the requirement is primarily in-Region failover, cross-Region read access, global disaster recovery, or automatic capacity scaling.
A critical distinction is that Aurora’s storage replication, Aurora Replicas, cross-Region read replicas, Global Database, and Aurora Serverless address different problems.
Key Concepts
Aurora Replicas for In-Region Availability and Read Scaling
An Aurora cluster has a shared, distributed storage volume replicated across multiple Availability Zones. The cluster normally has:
- One writer instance, which handles read/write traffic.
- Zero or more Aurora Replicas, which normally handle read traffic.
- A cluster endpoint for writer connections.
- A reader endpoint that distributes read connections across Aurora Replicas.
- Individual replica endpoints when an application needs to target a specific instance.
Aurora storage is designed for multi-AZ durability. Compute instances are separate from the underlying storage, so a replica can be promoted if the writer fails.
Aurora supports up to 15 Aurora Replicas per cluster. Replication within the Region is generally very low latency, but an architecture should not treat a specific replica-lag value as an absolute guarantee. Applications requiring read-after-write consistency may need to read from the writer or otherwise account for replica lag.
Failover and Promotion Priority
If the writer becomes unavailable, Aurora can promote a replica to writer. Promotion order can be controlled with failover priority tiers. This is useful when replicas have different characteristics, such as:
- Different instance sizes.
- Different performance capabilities.
- Placement in different Availability Zones.
- Different operational or licensing costs.
For example, an architect may assign higher promotion priority to a suitably sized replica in another Availability Zone rather than allowing a same-AZ replica to be selected first. Promotion priority influences the preferred target; it does not replace multi-AZ design.
Applications should use the cluster or writer endpoint rather than hard-coding an instance endpoint. This allows endpoint resolution to follow the promoted writer after failover.
Aurora Replica Auto Scaling
Aurora Replica Auto Scaling adds or removes Aurora Replicas based on CloudWatch metrics and configured thresholds. It is appropriate when read demand varies and additional read capacity is needed during predictable or recurring load increases.
This feature scales read capacity, not write capacity. The writer remains the write target, and scaling replicas does not eliminate the need to optimize write throughput, transactions, indexes, or instance sizing.
Cross-Region Aurora Read Replicas
A cross-Region Aurora read replica extends read capacity or disaster recovery capability to another AWS Region. The primary Region continues to handle writes, while the secondary Region can serve reads after the replica becomes available.
Important characteristics include:
- Replication across Regions is asynchronous.
- There may be replication lag and potential data loss if the primary Region is lost before all changes arrive.
- Cross-Region traffic introduces additional latency and data-transfer cost.
- The secondary deployment can be promoted for recovery, but promotion is not the same as automatic, zero-downtime failover.
This option is useful when an application needs read locality in another Region or when a simpler cross-Region recovery mechanism is sufficient.
Aurora Global Database
Aurora Global Database is designed for globally distributed reads and cross-Region disaster recovery. It has:
- One primary Region that accepts writes.
- One or more secondary Regions that can serve reads.
- Replication through Aurora’s storage layer.
- Regional reader endpoints for applications near each secondary Region.
Replication remains asynchronous because data must cross Regional boundaries. Consequently, a secondary can be slightly behind the primary, although Aurora Global Database is designed for substantially lower cross-Region replication latency than many traditional database replication approaches.
A secondary cluster can be promoted to read/write operation during a Regional disaster. This is a recovery operation and should be planned and tested; it is not equivalent to synchronous multi-Region active-active writes.
Global Database can also use write forwarding. An application connected to a secondary Region’s reader endpoint can issue supported write operations, which are forwarded to the primary Region. The data is still written in the primary Region; write forwarding does not make the secondary independently writable and does not remove cross-Region write latency.
Aurora Serverless
Aurora Serverless provides automatically managed database capacity for workloads whose demand changes or is difficult to predict. Aurora Serverless v2 uses Aurora Capacity Units (ACUs) and can scale capacity in fine-grained increments within configured minimum and maximum limits.
An ACU represents a combination of database compute and memory capacity. It should not be treated as a simple CPU-only unit. Applications connect through Aurora’s connection-routing layer, which directs connections to available database capacity.
Typical use cases include:
- Infrequently used applications.
- New applications with unknown demand.
- Development and test environments.
- Highly variable or unpredictable workloads.
- Multi-tenant systems with uneven tenant activity.
Aurora Serverless is a capacity-management option, not a replacement for high availability, sound connection management, or query optimization. Confirm engine, version, feature, networking, and scaling behavior requirements before selecting it.
Exam-Relevant Takeaways
- Use Aurora Replicas for in-Region read scaling and writer failover.
- Aurora storage is replicated across multiple Availability Zones, but compute failover still depends on an available replica or a replacement instance.
- Use the reader endpoint to distribute read traffic across replicas.
- Use the cluster/writer endpoint for writes so the application follows the promoted writer.
- Aurora Replica Auto Scaling adds replicas for read demand; it does not scale the writer’s write throughput.
- Cross-Region replicas provide asynchronous replication and can support read locality or disaster recovery.
- Aurora Global Database is the preferred Aurora feature for global read access and fast cross-Region recovery requirements.
- Global Database secondary Regions are not independent write masters. Write forwarding sends writes back to the primary Region.
- Aurora Serverless is suited to variable, intermittent, or uncertain capacity requirements, not automatically to every production workload.
- Cross-Region replication implies data-transfer cost, latency, and a possible recovery point objective greater than zero.
Architecture Decision Guide
| Requirement | Recommended option | Main tradeoff |
|---|---|---|
| In-Region writer failover | Aurora Replicas in multiple AZs | Requires suitable replica capacity and application failover handling |
| Scale reads within one Region | Aurora Replicas and reader endpoint | Does not scale writes automatically |
| Automatically add read instances | Aurora Replica Auto Scaling | Scaling reacts to metrics and may take time to add capacity |
| Serve reads close to global users | Aurora Global Database | Writes remain centralized in the primary Region unless the application changes its write model |
| Cross-Region recovery with Aurora | Aurora Global Database or cross-Region read replica | Asynchronous replication creates possible lag and data loss during disaster recovery |
| Unknown or highly variable database demand | Aurora Serverless v2 | Requires validation of compatibility, scaling limits, and connection behavior |
| Infrequent development/test workload | Aurora Serverless or a smaller provisioned cluster | Cost and operational savings depend on usage and scaling behavior |
| Application writes from a secondary Global Database Region | Global Database write forwarding | Writes still incur primary-Region network latency and are not locally committed |
Common Exam Traps
- Confusing Aurora storage replication with Aurora Replicas: The shared storage is replicated across AZs, while Aurora Replicas are database compute instances used for reads and failover.
- Assuming all replicas are writable: Aurora Replicas and Global Database secondary clusters normally serve reads. A secondary must be promoted before it becomes a writer.
- Treating Global Database as active-active writes: Global Database centralizes writes in the primary Region. It is not a multi-master write architecture.
- Using a replica endpoint for writes: Applications should use the writer or cluster endpoint for writes and the reader endpoint for reads.
- Assuming read scaling increases write capacity: Adding replicas helps read throughput only.
- Assuming cross-Region replication is synchronous: Cross-Region replication is asynchronous, so RPO is not necessarily zero.
- Assuming write forwarding makes writes local: A forwarded write is processed in the primary Region.
- Ignoring failover priority: Replica size and promotion priority can affect which instance becomes the new writer.
- Assuming Serverless removes all database bottlenecks: Queries, locks, connections, storage performance, and engine limitations still matter.
- Choosing Aurora Serverless solely because demand varies: Verify supported features, minimum and maximum capacity, connection patterns, and operational requirements first.
Real-World Engineer Notes
- Place Aurora Replicas across multiple Availability Zones and size at least one failover candidate appropriately for production traffic.
- Use connection pools and endpoint-based discovery. Test DNS caching behavior so applications do not continue using a failed writer after promotion.
- Monitor
CPUUtilization,DatabaseConnections,FreeableMemory,VolumeReadIOPS,VolumeWriteIOPS, and replica lag. Select metrics that reflect the actual bottleneck rather than scaling from CPU alone. - Test failover from the application’s perspective, including transaction retries, connection re-establishment, idempotency, and DNS refresh.
- For cross-Region recovery, define the promotion runbook, application endpoint change, secret/configuration changes, data validation, and failback process.
- Do not route latency-sensitive writes to a Global Database secondary simply because the application is deployed there. Centralized writes can become the dominant latency component.
- Serverless capacity scaling does not excuse poor connection management. Large numbers of idle connections can consume resources and complicate scaling.
- Evaluate data-transfer charges and inter-Region traffic paths when selecting Global Database or cross-Region replicas.
Quick Reference Summary
- Aurora Replicas: In-Region read scaling and failover targets.
- Reader endpoint: Routes read connections across replicas.
- Writer/cluster endpoint: Routes writes to the current primary instance.
- Failover priority tiers: Influence which replica Aurora promotes.
- Replica Auto Scaling: Adjusts the number of read replicas.
- Cross-Region read replica: Asynchronous read and recovery copy in another Region.
- Aurora Global Database: Global reads, centralized writes, and cross-Region recovery using Aurora storage replication.
- Write forwarding: Sends supported secondary-issued writes to the Global Database primary.
- Aurora Serverless v2: Automatically adjusts database capacity using ACUs for variable workloads.
Flashcards
- Q: What is the primary purpose of an Aurora Replica?
A: In-Region read scaling and a potential failover target for the writer.
- Q: Which Aurora endpoint should applications use for writes?
A: The writer or cluster endpoint, allowing connections to follow a promoted writer.
- Q: What does the Aurora reader endpoint do?
A: Distributes read connections across available Aurora Replicas.
- Q: How many Aurora Replicas can an Aurora cluster support?
A: Up to 15 Aurora Replicas per cluster.
- Q: What does failover priority control?
A: The preferred order in which Aurora considers replicas for promotion after writer failure.
- Q: Does Aurora Replica Auto Scaling increase write capacity?
A: No. It adds or removes read replicas and therefore primarily scales reads.
- Q: Is cross-Region Aurora replication synchronous?
A: No. It is asynchronous, so replication lag and non-zero RPO are possible.
- Q: Where are writes processed in Aurora Global Database?
A: In the primary Region.
- Q: What does Global Database write forwarding do?
A: Forwards supported writes issued against a secondary’s reader endpoint to the primary Region.
- Q: What is Aurora Serverless v2 designed to manage?
A: Automatically changing database capacity for intermittent, variable, or unpredictable workloads.
- Q: What is an ACU?
A: A unit of Aurora Serverless capacity representing a combination of compute and memory resources.
- Q: Why should applications avoid hard-coded Aurora instance endpoints?
A: A hard-coded endpoint may continue pointing to a failed instance after failover; cluster endpoints are designed to track roles.
Practice Questions
Question 1
A company runs an Aurora PostgreSQL cluster in one Region. Read traffic increases sharply during business hours, but write traffic is stable. The company wants automatic addition and removal of read capacity based on demand. Which solution best meets the requirement?
A. Increase the writer instance size on a fixed schedule
B. Configure Aurora Replica Auto Scaling
C. Enable Global Database write forwarding
D. Convert the cluster to a cross-Region read replica
Correct answer: B
Explanation: Aurora Replica Auto Scaling adjusts the number of Aurora Replicas to handle changing read demand. Increasing the writer does not provide automatic read-instance scaling, and the cross-Region features address geographic distribution or disaster recovery.
Question 2
A globally distributed application requires users in Europe and Asia to read data from nearby Regions. All writes must remain centralized in the United States, and the company also wants a faster recovery option if the primary Region fails. Which Aurora architecture is most appropriate?
A. Aurora Replicas in multiple Availability Zones in the US Region only
B. Aurora Global Database with secondary Regions
C. Aurora Serverless in each Region with independent databases
D. A single cross-Region read replica used only for backups
Correct answer: B
Explanation: Aurora Global Database provides secondary clusters for regional reads while retaining a primary write Region and supporting cross-Region recovery. Independent Serverless databases would require application-level replication and conflict management.
Question 3
An application connects to an Aurora Global Database secondary Region. It occasionally sends a supported write operation through the secondary’s reader endpoint. The architect wants the write committed locally in the secondary Region to avoid network latency. What should the architect understand?
A. The secondary automatically becomes an independent writer
B. The write is rejected because reader endpoints never accept write requests
C. With write forwarding enabled, the request is sent to the primary Region
D. The write is synchronously committed in both Regions
Correct answer: C
Explanation: Global Database write forwarding allows supported writes issued in a secondary to be forwarded to the primary. It does not make the secondary independently writable or provide synchronous multi-Region commits.
Question 4
A new application has unpredictable traffic and may receive no requests for long periods. The team wants database capacity to scale up and down automatically rather than selecting a fixed instance size. Which option should be evaluated first?
A. Aurora Serverless v2
B. An Aurora reader endpoint without replicas
C. An RDS Multi-AZ standby used for reads
D. A larger provisioned writer with no replicas
Correct answer: A
Explanation: Aurora Serverless v2 is intended for variable or uncertain database capacity requirements. A Multi-AZ standby is for availability, not read scaling, and endpoints alone do not create capacity.
Question 5
An Aurora writer fails. The cluster has three replicas: one in the same AZ as the writer and two in other AZs. The architect wants Aurora to prefer a suitably sized replica in another AZ during promotion. Which configuration should be used?
A. Set replica failover priority tiers
B. Enable reader endpoint load balancing
C. Enable Global Database write forwarding
D. Configure Serverless minimum capacity
Correct answer: A
Explanation: Aurora failover priority tiers influence the order in which replicas are selected for promotion. Reader endpoint balancing affects reads, while write forwarding and Serverless capacity do not control in-Region failover selection.