Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon Aurora is a managed relational database engine in the Amazon RDS family. This lesson focuses on Aurora’s storage architecture, in-Region replicas, cross-Region replication options, failover behavior, and scaling capabilities.
Aurora is compatible with MySQL and PostgreSQL, making it a managed option for workloads that require relational database features while benefiting from AWS-managed high availability and storage.
Key Concepts
Aurora’s distributed storage architecture
Aurora separates compute from storage. A database cluster uses a single logical storage volume that is replicated across multiple Availability Zones in a Region. The storage layer is designed to be fault tolerant, self-healing, and automatically scalable.
Important characteristics include:
- Data is replicated across three Availability Zones.
- Multiple copies of data are maintained within the storage subsystem.
- Storage automatically grows as the database requires more capacity.
- Aurora storage can scale up to approximately 128 TiB per database instance, depending on engine and configuration limits.
- Continuous backup and point-in-time recovery use Amazon S3-managed backup storage.
- Compute instances access the same underlying cluster volume, reducing the need for traditional storage replication between database instances.
Aurora’s storage replication does not eliminate the need for database replicas. Replicas provide read scaling and database-instance-level failover, while the distributed storage layer provides durability and storage fault tolerance.
Aurora cluster roles
An Aurora cluster generally contains:
- A primary instance, which handles write operations and can also serve reads.
- One or more Aurora Replicas, which serve read traffic and provide failover targets.
- Cluster and reader endpoints that direct applications to the appropriate database instances.
Writes are sent to the primary endpoint. Read traffic can be sent to the reader endpoint, which distributes connections among available Aurora Replicas.
Aurora Replicas
Aurora Replicas are database instances in the same Region and within the same Aurora cluster. They use asynchronous replication from the primary, but because they share Aurora’s distributed storage architecture, replication lag is generally very low—often measured in milliseconds under normal conditions.
Aurora supports up to 15 Aurora Replicas in a cluster. They provide:
- Read scaling within a Region.
- Failover targets if the primary instance becomes unavailable.
- Independent database endpoints.
- Automatic promotion during a failover event.
- Replica promotion priorities that influence which instance is selected first.
- Optional Aurora Auto Scaling to add or remove replicas based on demand.
An Aurora Replica can be promoted to become the new primary. Promotion priority tiers allow you to control the preferred order of failover candidates.
Cross-Region read replicas
Cross-Region read replicas are distinct from Aurora Replicas. They are used to replicate data to another AWS Region, supporting disaster recovery, geographically distributed reads, and regional migration strategies.
For Aurora MySQL, cross-Region replication can use MySQL-compatible read replica functionality. These replicas:
- Are located in another Region.
- Replicate asynchronously.
- Typically have higher replication latency than in-Region Aurora Replicas.
- Can be used for read traffic in the secondary Region.
- Can be promoted manually during a regional failure.
- May experience data loss during a regional disaster because replication is asynchronous.
- Can support user-defined replication delay and, in some configurations, differences from the source schema or data set.
A cross-Region replica can itself have Aurora Replicas associated with it, allowing read scaling in the secondary Region.
Aurora Global Database
Aurora Global Database is designed for globally distributed applications and cross-Region disaster recovery. It supports both Aurora MySQL-compatible and Aurora PostgreSQL-compatible engines.
A global database uses a primary Region and one or more secondary Regions. Secondary Regions can serve low-latency read traffic, while a secondary cluster can be promoted during a regional outage or planned recovery operation.
Global Database is generally the preferred Aurora feature when an exam scenario requires:
- Cross-Region database replication.
- Low-latency reads close to users in other Regions.
- A cross-Region disaster recovery design.
- A managed mechanism for promoting a secondary Region.
Aurora Serverless
Aurora Serverless provides on-demand compute capacity that can scale based on workload demand. It is useful for variable, intermittent, or unpredictable workloads where maintaining a continuously provisioned database instance is undesirable.
The choice between provisioned Aurora and Aurora Serverless depends on workload characteristics, scaling requirements, connection behavior, and the specific Aurora Serverless version and feature support required by the application.
Architecture Decision Guide
| Requirement | Recommended Aurora capability | Important consideration |
|---|---|---|
| Read scaling within one Region | Aurora Replicas | Up to 15 replicas; use the reader endpoint |
| Automatic database-instance failover | Multi-instance Aurora cluster with Aurora Replicas | Configure promotion priorities and monitor failover behavior |
| Cross-Region read access | Cross-Region read replica or Aurora Global Database | Replication is asynchronous, so replication lag and possible data loss must be considered |
| Cross-Region disaster recovery for Aurora MySQL or PostgreSQL | Aurora Global Database | Secondary Region can be promoted during a regional failure |
| Variable or intermittent workload | Aurora Serverless | Validate version compatibility, scaling behavior, and connection requirements |
| Durable managed relational storage | Aurora cluster storage | Storage is replicated across Availability Zones and backed up continuously |
| Read traffic close to users in multiple Regions | Aurora Global Database | Deploy applications and read workloads near the relevant secondary clusters |
| Controlled failover order | Aurora Replica promotion tiers | Lower-numbered or higher-priority tiers are preferred during promotion, depending on configuration semantics |
Exam-Relevant Takeaways
- Aurora is an RDS-family relational database compatible with MySQL and PostgreSQL.
- Aurora storage is distributed across multiple Availability Zones and uses a single logical cluster volume.
- Aurora Replicas are in-Region and are used for read scaling and automatic failover.
- Aurora supports up to 15 Aurora Replicas per cluster.
- The Aurora reader endpoint helps distribute read connections across replicas.
- Aurora Replicas generally have very low replication lag and impose relatively low performance impact on the primary.
- Cross-Region replicas are asynchronous and have more latency than in-Region Aurora Replicas.
- Cross-Region replicas are useful for regional reads and disaster recovery, but promotion is not the same as automatic in-Region Aurora failover.
- Aurora Global Database supports both Aurora MySQL-compatible and Aurora PostgreSQL-compatible engines.
- Aurora Global Database is a strong answer when a scenario combines cross-Region reads with cross-Region disaster recovery.
- Replication is asynchronous, so a regional failover design must account for potential data loss after the latest replicated transactions.
- Aurora Auto Scaling can automatically adjust the number of Aurora Replicas for read-heavy workloads.
- Aurora Serverless is intended for workloads with variable or unpredictable database capacity requirements.
Common Exam Traps
Confusing Aurora Replicas with cross-Region replicas
An Aurora Replica is normally an in-Region instance in the same Aurora cluster. A cross-Region replica is a separate regional copy used for geographic distribution or disaster recovery.
Assuming all replicas fail over automatically
Aurora Replicas can be automatically promoted when the primary fails. Cross-Region replicas generally require a regional recovery or promotion procedure and are not equivalent to automatic in-Region failover.
Treating asynchronous replication as zero-data-loss replication
Both replica categories use asynchronous replication. If a Region fails before the latest transactions reach the secondary, some data may be unavailable in the promoted database.
Using read replicas to handle writes
Aurora Replicas are primarily read scaling and failover targets. They do not provide independent write capacity for the same database. Writes normally go through the primary endpoint.
Selecting a standard RDS read replica when Aurora Global Database is required
If the question requires Aurora PostgreSQL support, low-latency cross-Region reads, and regional failover, Aurora Global Database is usually a better fit than an engine-specific cross-Region read replica approach.
Assuming replicas replace backups
Replicas improve availability and read capacity, but they do not replace backups. Logical corruption or accidental deletion can be replicated. Use automated backups and point-in-time recovery for data recovery.
Ignoring application endpoint behavior
Applications should use the cluster endpoint for writes and the reader endpoint for read distribution where appropriate. Hard-coding an individual instance endpoint can prevent the application from benefiting from failover and replica changes.
Real-World Engineer Notes
- Design connection handling for failover. Database clients should retry transient connection failures and refresh DNS resolution appropriately.
- Separate read scaling from caching. Aurora Replicas scale relational reads, while services such as Amazon ElastiCache can reduce repeated database queries and lower database load further.
- Test failover rather than relying only on the configured promotion priority. Application reconnect behavior, transaction retry logic, and connection pool settings often determine the real outage impact.
- Monitor replica lag, database connections, CPU, memory pressure, storage activity, and read/write latency. A replica that is available but significantly behind may not be a suitable recovery target.
- Cross-Region recovery requires more than a database replica. Replicate application configuration, secrets, networking, deployment artifacts, and observability components to the recovery Region.
- Consider write locality. A global read architecture does not automatically provide multi-Region writes; the primary Aurora cluster remains the normal write location.
- Use promotion tiers intentionally. Place the most suitable instance types and AZ placement in the preferred promotion tier, and avoid promoting a replica that lacks required capacity.
- Aurora Serverless can reduce the need for continuously provisioned capacity, but connection storms, scaling delays, and feature compatibility should be evaluated before production adoption.
Quick Reference Summary
- Engine type: Managed relational database in the RDS family.
- Compatible engines: Aurora MySQL-compatible and Aurora PostgreSQL-compatible.
- Storage: Distributed, fault-tolerant logical volume replicated across Availability Zones.
- Primary: Handles writes.
- Aurora Replicas: In-Region; read scaling and automatic failover; up to 15.
- Cross-Region replicas: Asynchronous regional copies; useful for DR and remote reads; promotion generally requires intervention.
- Aurora Global Database: Cross-Region Aurora architecture supporting MySQL-compatible and PostgreSQL-compatible engines.
- Backups: Continuous backup and point-in-time recovery using Amazon S3-backed Aurora backup storage.
- Scaling: Aurora Replicas for read scaling, Aurora Auto Scaling for replica count, and Aurora Serverless for variable compute demand.
- Primary tradeoff: Higher availability and read scalability come with additional cost, operational complexity, and possible replication lag—especially across Regions.
Flashcards
1. What database engines are compatible with Amazon Aurora?
Aurora is compatible with MySQL and PostgreSQL.
2. Where are Aurora Replicas located?
Aurora Replicas are located within the same AWS Region and Aurora cluster as the primary instance.
3. What are the two main purposes of Aurora Replicas?
They provide read scaling and failover targets for the primary instance.
4. How many Aurora Replicas can an Aurora cluster support?
Up to 15 Aurora Replicas.
5. What endpoint should normally receive Aurora write traffic?
The Aurora cluster or writer endpoint, which points to the current primary instance.
6. What endpoint is used to distribute reads across Aurora Replicas?
The Aurora reader endpoint.
7. What is the key difference between an Aurora Replica and a cross-Region replica?
An Aurora Replica is in-Region and part of the same cluster; a cross-Region replica is a separate regional copy used for remote reads or disaster recovery.
8. Is Aurora replica replication synchronous or asynchronous?
Replication is asynchronous, so replication lag and possible data loss must be considered during recovery.
9. Which Aurora feature is designed for cross-Region reads and regional disaster recovery for both supported engines?
Aurora Global Database.
10. What feature automatically adjusts the number of Aurora Replicas based on demand?
Aurora Auto Scaling.
11. What is Aurora Serverless designed for?
Workloads with variable, intermittent, or unpredictable compute demand where on-demand database capacity is useful.
12. Do Aurora Replicas replace backups?
No. Replicas improve availability and read scaling, while backups and point-in-time recovery protect against logical errors, accidental deletion, and other recovery scenarios.
Practice Questions
Question 1
A company runs an Aurora PostgreSQL-compatible database in one Region. It needs to increase read capacity and automatically recover from a primary database instance failure. Which design best meets the requirements?
A. Create an Amazon ElastiCache cluster and remove the Aurora primary instance
B. Add Aurora Replicas and use the reader endpoint for read traffic
C. Create an Amazon RDS MySQL cross-Region read replica
D. Export the database to Amazon S3 and query the exported files
Correct answer: B
Aurora Replicas provide in-Region read scaling and can be automatically promoted if the primary fails. The reader endpoint distributes read connections across available replicas.
Question 2
A global application requires low-latency reads in Europe and Asia while keeping writes in a primary AWS Region. It also requires the ability to promote a secondary Region after a regional outage. Which Aurora capability is most appropriate?
A. A single Aurora primary with larger instance capacity
B. Aurora Replicas in different Availability Zones in the primary Region
C. Aurora Global Database with secondary Regions
D. An Aurora Serverless cluster with no replicas
Correct answer: C
Aurora Global Database is designed for cross-Region read access and regional disaster recovery. In-Region Aurora Replicas cannot provide low-latency reads or recovery from a complete regional outage.
Question 3
An Aurora MySQL-compatible workload requires a disaster recovery copy in another Region. The business accepts asynchronous replication and some possible data loss but wants to scale reads in the recovery Region. Which approach is suitable?
A. Create a cross-Region Aurora replica and associate Aurora Replicas with the secondary cluster
B. Add more Aurora Replicas to the primary Region only
C. Use an RDS Multi-AZ standby in the primary Region
D. Use Aurora Auto Scaling without creating a secondary Region
Correct answer: A
A cross-Region replica provides the regional copy. Aurora Replicas associated with that secondary cluster can provide read scaling there. Because replication is asynchronous, the design must account for replication lag and possible data loss.
Question 4
An application uses an individual Aurora Replica endpoint for all read connections. During a failover, the application continues attempting to connect to the old instance and experiences errors. What is the best architectural improvement?
A. Send all reads to the database storage volume directly
B. Use the Aurora reader endpoint for read traffic and implement connection retry handling
C. Disable automatic failover
D. Convert the database to an Amazon DynamoDB table without changing the application
Correct answer: B
The reader endpoint abstracts the set of read-capable instances and allows Aurora to direct connections to available replicas. Applications should also handle transient connection failures and reconnect after failover.
Question 5
A workload has highly variable demand and is inactive for long periods. The team wants database capacity to scale on demand instead of maintaining a continuously provisioned instance, provided application and engine compatibility requirements are met. Which Aurora option should be evaluated first?
A. Aurora Serverless
B. A larger fixed-size Aurora primary
C. A cross-Region read replica
D. An Aurora Replica promotion tier
Correct answer: A
Aurora Serverless is intended for variable or intermittent workloads that benefit from on-demand compute scaling. Cross-Region replicas and promotion tiers address availability or geographic distribution, not dynamic primary capacity in this scenario.