AWS Databases: RDS, Aurora, and ElastiCache

Purpose of This Lesson

This lesson covers three AWS database services and the decisions that distinguish them:

• Amazon RDS for managed relational databases and OLTP workloads.
• Amazon Aurora for AWS-built, MySQL- and PostgreSQL-compatible relational databases with cloud-oriented storage and scaling features.
• Amazon ElastiCache for managed in-memory caching with Redis or Memcached.

For the AWS Certified CloudOps Engineer Associate context, focus on recognizing the workload, selecting the appropriate service or configuration, and understanding scaling, encryption, replication, backup, and high-availability tradeoffs.

Key Concepts

Amazon RDS

Amazon RDS is a managed relational database service that runs on EC2 instances. When creating an RDS database, you select an instance type that provides the required hardware profile.

Supported database engines in this lesson are:

• Amazon Aurora
• MySQL
• MariaDB
• Oracle
• Microsoft SQL Server
• PostgreSQL

Relational databases use SQL and are commonly used for online transaction processing (OLTP), such as transactions for online stores or banking systems. RDS simplifies setup and supports highly available, fault-tolerant, and scalable database deployments.

RDS Encryption

RDS encryption at rest uses AWS Key Management Service (AWS KMS). Encryption must be enabled when the database is created. When encryption is enabled, database snapshots are encrypted as well.

A key operational constraint is that encryption cannot simply be enabled later on an existing unencrypted database. Plan the encryption choice during database creation.

RDS Scaling

RDS scales vertically for database capacity and write performance. Vertical scaling means changing the DB instance type—for example, moving from an m4.large to an m4.2xlarge to obtain more CPU and memory.

Read traffic can scale horizontally by using read replicas or comparable read-scaling designs. The key distinction is:

• Write scaling: vertically scale the RDS instance.
• Read scaling: horizontally scale read capacity.

Amazon Aurora

Aurora is an AWS database engine in the RDS family. It is compatible with MySQL and PostgreSQL and is designed for cloud workloads. The lesson describes Aurora as offering higher performance than standard MySQL and PostgreSQL deployments, along with distributed, fault-tolerant, self-healing storage.

Aurora storage can automatically scale up to 128 TB per database instance. Aurora also provides continuous backup to Amazon S3 and point-in-time recovery.

Important Aurora configurations and capabilities include:

• Aurora Replicas: Read replicas within a Region for read scalability.
• MySQL replicas: Used in the described cross-Region clustering and read-scaling approach.
• Aurora Global Database: Provides cross-Region clustering, low-latency reads, and fast replication.
• Aurora Multi-Master: Supports scaling writes within a Region. Multiple nodes can write to the database simultaneously, providing redundancy for write traffic.
• Aurora Serverless: An on-demand, auto-scaling Aurora configuration. The lesson notes that it does not support read replicas or public IPs.

Amazon ElastiCache

ElastiCache is a fully managed in-memory key-value data store based on either Redis or Memcached. It runs on EC2 instances, so the selected instance family and type determine the available hardware profile.

ElastiCache is commonly placed in front of a persistent database such as RDS or DynamoDB. A typical cache-aside flow is:

1. The application writes persistent data to RDS.
2. Frequently requested data is loaded into ElastiCache.
3. A later read can be served from the cache with much lower latency than retrieving it from the database.

Caching is most appropriate when data is frequently accessed, relatively static, slow or expensive to retrieve, or when the application can tolerate potentially stale values.

Database and Caching Architecture Decisions

RDS Versus Aurora

Choose standard RDS engines when a managed relational database using a familiar supported engine meets the workload requirements. Choose Aurora when MySQL or PostgreSQL compatibility is needed together with Aurora’s distributed storage, automated storage scaling, continuous backup, point-in-time recovery, or specialized read/write and cross-Region configurations.

Redis Versus Memcached

The choice between Redis and Memcached depends on persistence, data structures, encryption, replication, failover, and scaling needs.

Capability	Memcached	Redis, Cluster Mode Disabled	Redis, Cluster Mode Enabled
Persistence and snapshots	Not available in the lesson’s comparison	Available; automatic and manual snapshots	Available; automatic and manual snapshots
Data types	Simpler key-value usage	More complex data types	More complex data types
Encryption	Not supported in the comparison	Supported	Supported
High availability	Nodes may be placed in multiple AZs, but no replication or failover	Replication, read replicas, and automatic failover	Replication and automatic failover, with replicas per shard
Scale out	Add nodes	Add a replica	Add shards
Scale up	Change node type	Change node type	Change node type
Multithreading	Supported in the comparison	Not supported in the comparison	Not supported in the comparison

All three configurations can use nodes in multiple Availability Zones, but multi-AZ placement alone does not mean that Memcached provides replication or automatic failover.

Aurora Configuration Selection

• Select Aurora Replicas for read scaling within a Region.
• Select Aurora Global Database for cross-Region read scaling, low-latency reads, and fast replication.
• Select Aurora Multi-Master when simultaneous write capability and write redundancy within a Region are required.
• Select Aurora Serverless for on-demand, auto-scaling Aurora capacity, while remembering the stated limitations around read replicas and public IPs.

Exam- or Assessment-Relevant Takeaways

• RDS is a managed relational database service, but the database still runs on EC2 instances and requires an instance type selection.
• Relational SQL databases are a natural fit for structured OLTP workloads such as commerce and banking transactions.
• Enable RDS encryption at creation time; AWS KMS supplies the encryption key, and encrypted snapshots are produced for an encrypted database.
• Vertical scaling changes the RDS instance type and is the lesson’s write-scaling approach. Horizontal scaling is used for read traffic.
• Aurora is MySQL- and PostgreSQL-compatible and uses distributed, fault-tolerant, self-healing storage.
• Aurora Replicas provide in-Region read scaling; Aurora Global Database addresses cross-Region clustering and read scaling.
• Aurora Multi-Master is the write-scaling choice within a Region when multiple nodes must be able to write.
• Aurora Serverless is on-demand and auto-scaling, but the lesson identifies no read replicas and no public IPs as limitations.
• Memcached does not provide the Redis capabilities listed for persistence, snapshots, encryption, replication, or automatic failover.
• Redis cluster mode disabled scales out by adding replicas; Redis cluster mode enabled scales out by adding shards.
• ElastiCache is appropriate when low-latency retrieval is more important than guaranteed freshness and the application can tolerate stale data.

Tool / Feature Decision Guide

Requirement	Preferred choice from this lesson	Reason
Managed SQL database for OLTP	RDS	Supports managed relational engines for structured transactions.
MySQL/PostgreSQL compatibility with cloud-oriented storage	Aurora	AWS-built compatible engine with distributed storage and automatic storage scaling.
More read capacity within one Region for Aurora	Aurora Replicas	Replicas provide in-Region read scalability.
Cross-Region Aurora reads and replication	Aurora Global Database	Provides cross-Region clustering, low-latency reads, and fast replication.
Multiple simultaneous Aurora writers within a Region	Aurora Multi-Master	Nodes can write at the same time and provide write redundancy.
On-demand Aurora capacity	Aurora Serverless	Auto-scales on demand, subject to the stated feature limitations.
Simple, fast cache without persistence or failover requirements	Memcached	Suitable for cache use cases where loss of cached data is acceptable.
Cache requiring persistence, snapshots, encryption, or high availability	Redis	Provides the listed persistence, backup, replication, and failover features.
Redis scale-out by distributing data across partitions	Redis cluster mode enabled	Adds shards for scale-out.
Redis primary with replicas for read scaling	Redis cluster mode disabled	Adds replicas and supports automatic failover.

Common Traps / Misconceptions

• Treating RDS as serverless by default: RDS runs on EC2 instances, and the instance type matters.
• Assuming RDS writes scale horizontally: The lesson identifies vertical scaling as the way to scale RDS writes; horizontal scaling applies to read traffic.
• Forgetting the encryption creation-time decision: RDS encryption must be enabled when the database is created.
• Confusing Aurora Replicas with Aurora Global Database: Aurora Replicas are for in-Region read scaling, while Global Database addresses cross-Region clustering and reads.
• Using Multi-Master for read-only scaling: Multi-Master is specifically associated with scaling writes within a Region.
• Assuming multi-AZ Memcached nodes provide failover: Memcached nodes can be placed across AZs, but the comparison states that Memcached has no replication or failover.
• Confusing Redis cluster modes: Cluster mode disabled scales out with replicas; cluster mode enabled scales out with shards.
• Assuming every cache read is current: Cached values can be stale, so the application must tolerate that possibility.
• Assuming Redis and Memcached have identical capabilities: Redis adds persistence, snapshots, encryption, and replication-related capabilities described in the lesson.

Real-World Engineer / Analyst Notes

• Select database and cache capacity based on the workload profile, not only on the service name. RDS and ElastiCache both require an appropriate EC2-backed instance type.
• Treat caching as a consistency and failure-mode decision. A cache improves latency, but the application must define what happens on a cache miss and whether stale data is acceptable.
• Keep the persistent database authoritative when using ElastiCache as a front-end cache. The cache should improve retrieval performance rather than replace durable storage.
• When troubleshooting performance, separate read pressure from write pressure. For RDS, read replicas address read demand, while a larger instance addresses the described vertical capacity and write-scaling path.
• For Redis, determine whether the scaling requirement is replica-based read capacity or partition-based data distribution. That distinction maps directly to cluster mode disabled versus enabled.
• Verify feature constraints before selecting Aurora Serverless, especially if the design requires read replicas or public IPs.

Quick Reference Summary

• RDS: Managed relational SQL databases for OLTP; supports Aurora, MySQL, MariaDB, Oracle, SQL Server, and PostgreSQL.
• RDS encryption: Enable at creation; uses AWS KMS; snapshots are encrypted.
• RDS scaling: Vertical scaling for writes; horizontal scaling for reads.
• Aurora: MySQL/PostgreSQL-compatible RDS engine with distributed self-healing storage, continuous S3 backup, point-in-time recovery, and storage scaling up to 128 TB per database instance.
• Aurora Replicas: In-Region read scaling.
• Aurora Global Database: Cross-Region clustering and read scaling.
• Aurora Multi-Master: Multiple writers within a Region.
• Aurora Serverless: On-demand auto-scaling; no read replicas or public IPs according to the lesson.
• ElastiCache: Managed Redis or Memcached in-memory key-value caching.
• Memcached: No persistence, snapshots, encryption, replication, or failover in the comparison; scales out by adding nodes.
• Redis cluster mode disabled: Replicas, automatic failover, and scale-out by adding replicas.
• Redis cluster mode enabled: Shards for partitioning and scale-out.

Flashcards

Q: A transactional online store needs a managed SQL database for OLTP. Which service family is the natural starting point, and what must be selected during deployment?

A: Start with Amazon RDS and select a supported relational engine plus an EC2-backed DB instance type with the required hardware profile.

Q: An RDS workload needs more write capacity. Should the team add read replicas or change the instance type?

A: Change the instance type to scale vertically. The lesson identifies horizontal scaling for read traffic, not for RDS writes.

Q: When must RDS encryption at rest be enabled, and what AWS service supplies the encryption key?

A: It must be enabled when the database is created, and AWS KMS is used for the encryption key. Encrypted snapshots are created for the encrypted database.

Q: A team wants MySQL compatibility plus distributed, self-healing storage and automatic storage growth. Which RDS engine should it evaluate?

A: Amazon Aurora, because it is AWS’s MySQL- and PostgreSQL-compatible relational engine with those cloud-oriented storage features.

Q: When would Aurora Global Database be a better choice than an Aurora Replica?

A: Use Aurora Global Database for cross-Region clustering and read scaling with low-latency reads and fast replication. Aurora Replicas address read scaling within a Region.

Q: Which Aurora configuration is intended for multiple nodes that can write simultaneously within one Region?

A: Aurora Multi-Master, which provides write scaling and redundancy for write traffic within a Region.

Q: What Aurora Serverless limitations identified in the lesson could affect a design?

A: Aurora Serverless does not support read replicas or public IPs according to the lesson, so designs requiring either feature need another configuration.

Q: An application needs a low-latency cache and can tolerate losing cached values, with no persistence or failover requirement. Which option fits best?

A: Memcached fits that simpler cache profile because the comparison lists no persistence, snapshots, replication, or failover for it.

Q: When should Redis be preferred over Memcached based on the capabilities in the lesson?

A: Prefer Redis when persistence, snapshots, encryption, replication, or automatic failover is required, or when more complex data types are useful.

Q: How does Redis cluster mode disabled scale out, and how does that differ from cluster mode enabled?

A: Cluster mode disabled scales out by adding replicas. Cluster mode enabled scales out by adding shards, which supports partitioning.

Q: What is the operational difference between placing Memcached nodes in multiple AZs and using Redis replication?

A: Multi-AZ Memcached placement does not provide replication or failover in the lesson’s comparison. Redis replication supports the high-availability behavior described for Redis.

Q: A frequently requested database result is expensive to retrieve and may become stale. What service pattern can reduce read latency?

A: Place ElastiCache in front of RDS or DynamoDB and serve repeated reads from the cache, provided the application tolerates stale data.

Practice Questions

Question 1

A company runs an RDS database for an e-commerce system. CPU and memory are insufficient, and the primary problem is transaction write capacity. Which action best matches the scaling approach covered in the lesson?

A. Add a read replica
B. Add a cache node only
C. Change the RDS DB instance to a larger type
D. Enable Aurora Global Database

Correct answer: C. The decisive clue is insufficient CPU and memory with a write-capacity problem. The lesson describes vertical scaling—changing the instance type—as the RDS write-scaling approach.

Question 2

A global application requires low-latency reads in multiple Regions and fast replication from its Aurora deployment. Which feature is the best fit?

A. Aurora Replica within one Region
B. Aurora Global Database
C. Aurora Multi-Master
D. Memcached across multiple AZs

Correct answer: B. Cross-Region clustering, low-latency reads, and fast replication identify Aurora Global Database. An Aurora Replica is the in-Region read-scaling option.

Question 3

An engineering team requires an in-memory cache with automatic failover, snapshots, encryption, and replication. Which option should it choose based on the lesson?

A. Memcached
B. Redis
C. An unencrypted RDS instance
D. Aurora Serverless

Correct answer: B. Redis provides the listed persistence, snapshots, encryption, replication, and failover capabilities in the comparison; Memcached does not.

Question 4

A Redis deployment must distribute data across partitions to scale out. Which configuration and scaling action are appropriate?

A. Cluster mode disabled; add replicas
B. Cluster mode enabled; add shards
C. Memcached; add read replicas
D. Aurora Multi-Master; add database writers

Correct answer: B. Cluster mode enabled uses shards for partitioning and scales out by adding more shards.

Question 5

An application caches frequently accessed product data, but the business accepts that a read may occasionally return an older value. Which concern is most important before deploying ElastiCache?

A. Whether the application can tolerate stale data
B. Whether RDS encryption can be enabled after creation
C. Whether Aurora supports simultaneous writers
D. Whether the cache is a relational SQL database

Correct answer: A. ElastiCache can return stale data, so application tolerance for stale values is a key suitability condition for the caching pattern.

WordPress Metadata

Suggested Slug:
aws-rds-aurora-elasticache-study-guide

Meta Description:
Study RDS, Aurora, and ElastiCache architecture, scaling, availability, encryption, caching choices, and CloudOps decision points for AWS Certified CloudOps Engineer Associate.

Tags:
AWS RDS, Amazon Aurora, ElastiCache, Redis, Memcached, AWS databases, database scaling, high availability, caching, AWS KMS, SOA-C03