Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS architecture questions often describe a workload requirement rather than naming the service directly. The key is to map requirements such as high availability, cross-Region reads, microsecond latency, multi-Region writes, SQL analytics, or durable streaming storage to the appropriate AWS database or analytics pattern.
This guide organizes those decision points across relational databases, NoSQL and in-memory stores, streaming, and analytics services.
Key Concepts
Amazon RDS for MySQL
Use Amazon RDS for MySQL when a managed MySQL-compatible relational database is required.
- High availability: Configure a Multi-AZ deployment. The standby is synchronously replicated and is intended for failover, not read scaling.
- Read scaling: Create a read replica and direct read traffic to the replica’s endpoint. Read replicas use asynchronous replication and are suitable for read-heavy workloads.
- Write or instance performance: Increase the DB instance class when more CPU, memory, or network capacity is needed. Increasing allocated storage or provisioning higher storage performance may also be necessary when the storage subsystem is the bottleneck.
- Storage limits: Storage can generally be modified independently from the instance class. Do not select a read replica merely because the primary is running out of storage or experiencing write latency.
Encrypting an Existing RDS Database Before Cross-Region Replication
An unencrypted RDS database cannot directly be used as the source for an encrypted cross-Region read replica. A typical conversion path is:
- Create a snapshot of the unencrypted DB instance.
- Copy or create an encrypted snapshot using an AWS KMS key.
- Restore a new encrypted DB instance from that snapshot.
- Create the encrypted cross-Region read replica from the encrypted source.
This process involves a migration window and may require application cutover planning.
Amazon Aurora Replication Patterns
Aurora provides several replication choices:
- Aurora Replicas: Same-Region read replicas designed for low-latency replication and read scaling. Replicas can be placed in different Availability Zones.
- Aurora Global Database: A primary cluster in one Region and read-only secondary clusters in other Regions. Applications in a secondary Region can use the local reader endpoint, reducing cross-Region read latency.
- Aurora Multi-Master: Supports writes across multiple database instances within a Region. Use it when the requirement is concurrent writes to multiple Aurora nodes, rather than simply high availability or read scaling.
A cross-Region Aurora design should distinguish between a conventional cross-Region replica and Aurora Global Database. Global Database is the stronger fit when the requirement emphasizes low-latency cross-Region reads, disaster recovery, and fast regional failover.
ElastiCache and DynamoDB for Low-Latency Data
The correct service depends on persistence, availability, data model, and latency requirements.
- ElastiCache for Memcached: In-memory caching with simple key-value access and easy horizontal scaling. It does not provide durable persistence or the same high-availability capabilities as Redis. It is a possible fit for multithreaded applications that need a distributed cache and can tolerate cache loss.
- ElastiCache for Redis: In-memory data structures, replication, automatic failover options, and persistence features. Choose Redis when the cache or data store must support durability and high availability.
- DynamoDB: Serverless, managed NoSQL database for key-value and document workloads.
- DynamoDB Accelerator (DAX): An in-memory cache for DynamoDB that can provide microsecond-scale reads for supported access patterns. DAX does not replace DynamoDB as the durable system of record.
Serverless Relational and NoSQL Databases
- DynamoDB: Use for a serverless key-value or document workload, including workloads that require multi-Region writes through DynamoDB Global Tables.
- Aurora Serverless: Use for Aurora-compatible MySQL or PostgreSQL workloads when capacity demand is variable, intermittent, or difficult to predict. It is also a fit for relational workloads with low or changing utilization.
Athena Performance for Date-Range Queries
Amazon Athena queries data directly in Amazon S3. For large datasets queried by date ranges:
- Partition the data in a Hive-compatible layout using a date-based partition key, such as
year=2026/month=09/day=01. - Ensure queries include partition predicates so Athena scans only relevant partitions.
- Prefer columnar formats such as Apache Parquet or ORC to reduce scanned data.
- Compress data and avoid excessive small files.
- Use schema and partition metadata that accurately reflects the S3 layout.
Partitioning reduces the amount of data scanned; columnar formats reduce the amount of data read from each object.
Streaming Ingestion and Processing
A common pattern is to separate ingestion from processing:
- Accept events through API Gateway or another producer.
- Put events into an Amazon Kinesis Data Stream.
- Process records asynchronously in batches with Lambda or another consumer.
This absorbs traffic bursts and avoids overwhelming Lambda with a request for every incoming event.
For stream processing requirements:
- Kinesis Data Streams: Durable, ordered streaming ingestion within a shard and support for multiple consumers.
- Kinesis Data Analytics: SQL-based analysis of streaming data, commonly using Kinesis Data Streams or Firehose as an input.
- Amazon Data Firehose: Managed delivery of streaming records to destinations such as Amazon S3, Amazon Redshift, OpenSearch Service, or an HTTP endpoint. It is useful when records must be delivered to a data store or external auditing system without building a custom delivery application.
For AWS WAF logs that must reach a third-party auditing application, a suitable pattern is WAF logging to Kinesis Data Firehose with the external application configured as an HTTP endpoint destination, subject to the destination’s authentication and delivery requirements.
Redshift for Consolidated Analytical Queries
Operational relational databases are optimized for OLTP: frequent transactions, point lookups, and updates. Amazon Redshift is designed for OLAP workloads such as complex aggregations, historical analysis, forecasting, and queries across consolidated datasets.
A typical architecture extracts or replicates data from multiple production databases into a Redshift data warehouse. This separates analytical workloads from production OLTP systems and allows the warehouse to use an analytical storage and query model.
Exam-Relevant Takeaways
- RDS Multi-AZ provides high availability and failover; it is not a read-scaling mechanism.
- RDS read replicas handle read scaling but use asynchronous replication and do not replace Multi-AZ protection.
- An encrypted cross-Region RDS read replica requires an encrypted source. Convert an unencrypted database through an encrypted snapshot and restored instance first.
- Use Aurora Replicas for low-latency same-Region read scaling.
- Use Aurora Global Database for low-latency reads from another Region and regional disaster recovery.
- Use Aurora Multi-Master when multiple Aurora instances must accept writes in one Region.
- Choose Memcached for a simple, nonpersistent distributed cache; choose Redis for persistence and high availability.
- The word microsecond in a DynamoDB caching scenario commonly points to DAX.
- Use DynamoDB Global Tables for a multi-Region, multi-writer key-value or document workload.
- Use Aurora Serverless for compatible relational workloads with variable or unpredictable demand.
- Optimize Athena with date partitioning, Parquet or ORC, compression, and partition predicates.
- Buffer API traffic in Kinesis Data Streams before batch processing when direct Lambda invocation causes throttling or excessive request volume.
- Use Kinesis Data Analytics when streaming data must be analyzed with SQL.
- Use Firehose to deliver streams to destinations such as S3, Redshift, OpenSearch Service, or an HTTP endpoint.
- Use Redshift for consolidated OLAP and forecasting rather than running complex analytical queries against production OLTP databases.
Architecture Decision Guide
| Requirement | Recommended pattern | Important distinction |
|---|---|---|
| Managed MySQL with automatic failover | RDS MySQL Multi-AZ | Standby is for availability, not read traffic |
| Read-heavy RDS workload | RDS read replica | Asynchronous replication; application must route reads |
| RDS source is unencrypted but encrypted cross-Region replica is required | Encrypted snapshot, restore encrypted instance, then create replica | Encryption cannot be added in place to an existing unencrypted database |
| Same-Region Aurora read scaling | Aurora Replica | Low-latency replication; place replicas across AZs |
| Cross-Region Aurora reads with low latency | Aurora Global Database | Use the local secondary Region’s reader endpoint |
| Writes accepted by multiple Aurora nodes | Aurora Multi-Master | In-Region multi-writer design |
| Simple distributed in-memory cache | ElastiCache for Memcached | No durable persistence or Redis-style failover model |
| Persistent, highly available in-memory store | ElastiCache for Redis | Supports richer data structures and persistence features |
| Microsecond caching for DynamoDB | DAX | Cache in front of DynamoDB, not a standalone durable database |
| Serverless key-value/document database | DynamoDB | Model access patterns around partition and sort keys |
| Multi-Region writes for key-value data | DynamoDB Global Tables | Multi-Region replication and local regional writes |
| Serverless MySQL/PostgreSQL-compatible relational database | Aurora Serverless | Best for variable or intermittent capacity needs |
| Date-range queries over S3 data | Athena with date partitions and Parquet/ORC | Queries must filter on partition columns |
| Burst-resistant stream ingestion | Kinesis Data Streams before consumers | Decouples producers from processing capacity |
| SQL over streaming data | Kinesis Data Analytics | Use a streaming input such as Kinesis Data Streams |
| Managed delivery to an HTTP auditing endpoint | Kinesis Data Firehose | Focuses on delivery rather than arbitrary stream processing |
| Complex queries across multiple operational databases | Redshift data warehouse | OLAP is separated from OLTP |
Common Exam Traps
- Treating an RDS Multi-AZ standby as a read replica. The standby is not intended for application read traffic.
- Choosing a read replica to solve a write-latency or storage-capacity problem. Read replicas primarily scale reads.
- Assuming an unencrypted RDS instance can directly create an encrypted cross-Region read replica.
- Confusing an Aurora Replica with Aurora Global Database. The former is primarily a same-Region replica; the latter supports cross-Region secondary clusters.
- Selecting Redis whenever the question says “in-memory.” Memcached is often correct when persistence, replication, and failover are explicitly unnecessary.
- Selecting DAX for arbitrary non-DynamoDB data. DAX is specifically a DynamoDB accelerator.
- Using DynamoDB Global Tables for relational joins or transactional relational schemas. Global Tables address multi-Region NoSQL replication.
- Querying every object in an S3 data lake with Athena when date partitioning and columnar formats could reduce the scan.
- Invoking Lambda directly for every high-volume event when a stream buffer and batch consumer would provide better flow control.
- Using Redshift as the primary transactional database or placing heavy analytical queries directly on production RDS instances.
Real-World Engineer Notes
- Multi-AZ and read replicas solve different failure and scaling dimensions. Production systems often use both: Multi-AZ for the writer and read replicas for read capacity.
- Cross-Region replication introduces eventual consistency and network delay. Applications using remote replicas must tolerate replication lag and stale reads.
- Database encryption changes often require snapshot-based migration, KMS key planning, permissions, and a controlled cutover.
- Cache invalidation, eviction behavior, and cache warming matter as much as raw latency. A cache should not silently become the only copy of business-critical data unless its durability model is explicitly designed for that role.
- Kinesis capacity and consumer behavior must be designed together. Partition-key distribution, shard capacity, batch size, retries, and iterator age affect throughput and lag.
- Athena cost is primarily influenced by data scanned. Good S3 object layout, partition pruning, compression, and columnar formats improve both performance and cost.
- A warehouse ingestion design should account for schema evolution, late-arriving data, duplicate records, reconciliation, and isolation from production database workloads.
Quick Reference Summary
- Availability: RDS Multi-AZ
- RDS read scaling: Read replicas
- Aurora same-Region reads: Aurora Replicas
- Aurora cross-Region reads and DR: Aurora Global Database
- Aurora multi-writer: Aurora Multi-Master
- Simple ephemeral cache: ElastiCache Memcached
- Persistent HA in-memory store: ElastiCache Redis
- DynamoDB microsecond cache: DAX
- Serverless NoSQL: DynamoDB
- Multi-Region NoSQL writes: DynamoDB Global Tables
- Variable relational capacity: Aurora Serverless
- S3 SQL analytics: Athena with partitions and Parquet/ORC
- SQL stream analysis: Kinesis Data Analytics
- Managed stream delivery: Kinesis Data Firehose
- OLAP warehouse: Redshift
Flashcards
- Q: What does RDS Multi-AZ primarily provide?
A: High availability and automatic failover through a standby deployment; it is not a read-scaling endpoint.
- Q: Which RDS feature is used to scale read traffic?
A: Read replicas, with the application routing read requests to the replica endpoint.
- Q: What must be done before creating an encrypted cross-Region replica from an unencrypted RDS database?
A: Create an encrypted snapshot, restore an encrypted DB instance, and use that encrypted source for replication.
- Q: When should Aurora Global Database be selected?
A: When applications in other Regions need low-latency read access and the design benefits from cross-Region disaster recovery.
- Q: Which Aurora option supports writes to multiple database instances in one Region?
A: Aurora Multi-Master.
- Q: When is Memcached preferable to Redis?
A: When a simple, distributed, nonpersistent cache is sufficient and durable data or advanced failover is not required.
- Q: What AWS service provides microsecond-scale caching for DynamoDB?
A: DynamoDB Accelerator, or DAX.
- Q: Which service supports multi-Region writes for a serverless key-value workload?
A: DynamoDB Global Tables.
- Q: What database fits a variable-demand MySQL or PostgreSQL-compatible workload?
A: Aurora Serverless.
- Q: How can Athena date-range queries over S3 be optimized?
A: Use date-based Hive partitions, query partition predicates, and store data in compressed Parquet or ORC format.
- Q: What pattern helps prevent high-volume API events from overwhelming Lambda?
A: Ingest events into Kinesis Data Streams and process them asynchronously in batches.
- Q: Which service provides SQL analysis of streaming data?
A: Kinesis Data Analytics.
- Q: Which Kinesis service can deliver records to an HTTP endpoint?
A: Kinesis Data Firehose.
- Q: Which AWS service is intended for complex analytical queries across consolidated datasets?
A: Amazon Redshift.
Practice Questions
Question 1
A company runs a MySQL database on Amazon RDS. The database must automatically fail over if its primary Availability Zone becomes unavailable, and the company also needs to increase read capacity for reporting queries. Which architecture meets both requirements?
Correct answer: Configure an RDS Multi-AZ deployment and create one or more read replicas.
Explanation: Multi-AZ provides high availability and failover. Read replicas provide read scaling. A Multi-AZ standby should not be used for reporting queries.
Question 2
An unencrypted RDS for MySQL instance must have an encrypted read replica in another Region. Which sequence should an architect recommend?
Correct answer: Create an encrypted snapshot, restore an encrypted RDS instance from it, and create the cross-Region read replica from the encrypted instance.
Explanation: The source database must be encrypted before it can be used for the required encrypted replication design. Encryption is not simply enabled in place on an existing unencrypted RDS instance.
Question 3
An application in Europe reads data from an Aurora cluster whose primary is in North America. The application requires low read latency and the organization wants a regional recovery option. Which solution is most appropriate?
Correct answer: Deploy an Aurora Global Database secondary cluster in Europe and direct European read traffic to its local reader endpoint.
Explanation: Aurora Global Database provides cross-Region secondary clusters and local reads. Sending reads across the Atlantic to the primary Region would increase latency.
Question 4
A public API receives sudden bursts of events. Each event currently invokes Lambda directly, causing throttling and excessive request errors. The events must also be analyzed using SQL while they are in flight. Which design is most suitable?
Correct answer: Send API events to Kinesis Data Streams, process them in batches, and use Kinesis Data Analytics for SQL-based stream analysis.
Explanation: Kinesis buffers and decouples ingestion from consumers. Batch processing reduces invocation pressure, while Kinesis Data Analytics is designed for SQL analysis of streaming data.
Question 5
A data lake stores several years of transaction records in Amazon S3. Analysts frequently run Athena queries for a specific date range. Which change most directly improves query performance and reduces scanned data?
Correct answer: Store the data using date-based Hive partitions and compressed Parquet or ORC files, and require queries to filter on the partition columns.
Explanation: Partition pruning prevents Athena from scanning unrelated dates. Columnar formats and compression further reduce the amount of data read.