DevOpsAWSCloud

AWS Databases Guide: RDS, Aurora, DynamoDB & ElastiCache

Master AWS database services — RDS managed relational databases, Aurora serverless, DynamoDB NoSQL, and ElastiCache caching. Complete SAA-C03 guide.

TT
Sarah Mitchell
7 min read
AWS Databases Guide: RDS, Aurora, DynamoDB & ElastiCache

Choosing the right database is one of the most consequential architectural decisions you'll make in AWS. Use a relational database when you need ACID transactions and structured schemas. Use a NoSQL database when you need millisecond latency at any scale. Use a cache when you need to stop hitting your database entirely.

AWS offers a managed database for every pattern — and the SAA-C03 exam tests your ability to choose the right one.


Amazon RDS

Amazon Relational Database Service (RDS) is a managed service that runs relational databases in the cloud. AWS handles hardware provisioning, OS patching, backups, and failover — you focus on your schema and queries.

Supported Database Engines

EngineBest For
MySQLWeb applications, open-source workloads
PostgreSQLComplex queries, GIS, JSONB documents
MariaDBMySQL-compatible, community-driven
OracleEnterprise legacy systems
SQL Server.NET applications, Windows shops
Amazon AuroraAWS-native, high-performance (see below)

RDS Key Features

Multi-AZ Deployment: RDS creates a synchronous standby replica in a different AZ. If the primary fails, RDS automatically fails over to the standby — typically within 60–120 seconds. The endpoint DNS name stays the same; your application reconnects automatically.

text
Primary DB  →  synchronous replication  →  Standby DB
(us-east-1a)                               (us-east-1b)

Read Replicas: Asynchronous replicas that serve read traffic. Up to 15 read replicas per instance. Reduces load on the primary for read-heavy workloads. Can be promoted to a standalone database if needed.

Exam tip: Multi-AZ is for high availability (automatic failover). Read Replicas are for read scalability (performance). They are different features — Multi-AZ replicas do not serve reads.

RDS Backups

Backup TypeRetentionRestore
Automated backups1–35 days (configurable)Point-in-time restore to any second within the retention window
Manual snapshotsUntil you delete themRestore to a new DB instance

Amazon Aurora

Amazon Aurora is AWS's cloud-native relational database — built from scratch for the cloud rather than adapted from an existing engine. It is compatible with MySQL and PostgreSQL.

Aurora separates compute and storage. The storage layer is a distributed, fault-tolerant, self-healing system that spans 3 AZs automatically — 6 copies of your data (2 copies per AZ).

FeatureRDS MySQLAurora MySQL
Storage replication2 copies (Multi-AZ)6 copies across 3 AZs
Read replicasUp to 5Up to 15
Failover time60–120 seconds~30 seconds
PerformanceBaseline MySQLUp to 5× MySQL performance
StorageUp to 64 TBUp to 128 TB (auto-scales)
CostLower~20% higher than RDS

Aurora Serverless

Aurora Serverless v2 automatically scales database capacity up or down in fractions of an ACU (Aurora Capacity Unit) based on actual load — within seconds. Use it for variable or unpredictable workloads, development and test databases (scale to zero when idle), and multi-tenant SaaS applications.

Aurora Global Database

Replicates your Aurora database across up to 5 AWS regions with sub-second lag. Enables disaster recovery across regions (RPO: ~1 second, RTO: <1 minute) and low-latency reads for global users in their local region.


Amazon DynamoDB

DynamoDB is AWS's fully managed, serverless NoSQL key-value and document database. It delivers single-digit millisecond latency at any scale — from a few requests per second to millions.

DynamoDB Core Concepts

ConceptDescription
TableA collection of items (no schema enforced)
ItemA single record (like a row), up to 400 KB
AttributeA field within an item (like a column)
Partition keyRequired primary key — determines which partition stores the item
Sort keyOptional second part of the primary key — enables range queries

Capacity Modes

On-Demand: DynamoDB scales instantly to handle any traffic. You pay per request. No capacity planning. Best for unpredictable workloads or new applications.

Provisioned: You specify Read Capacity Units (RCUs) and Write Capacity Units (WCUs) per second. Less expensive for steady, predictable traffic. Use Auto Scaling to adjust provisioned capacity automatically.

DynamoDB Indexes

Global Secondary Index (GSI): An index with a different partition key than the base table. Enables queries on non-primary-key attributes. Has its own capacity.

Local Secondary Index (LSI): An index with the same partition key but a different sort key. Must be created at table creation time. Shares capacity with the base table.

DynamoDB Streams

DynamoDB Streams captures a time-ordered sequence of item-level changes (INSERT, MODIFY, REMOVE), available for 24 hours. Use streams to trigger Lambda on data changes, replicate data to other tables, or maintain an audit trail.

DynamoDB Global Tables

Multi-region, multi-active replication. Your table is replicated across chosen regions — reads and writes can happen in any region. Conflict resolution uses "last writer wins" based on timestamps.

RDS vs DynamoDB decision rule: If you need JOIN queries, complex transactions, or a fixed schema → RDS/Aurora. If you need horizontal scale, flexible schema, or single-digit millisecond latency at any volume → DynamoDB.


Amazon ElastiCache

ElastiCache is a fully managed in-memory caching service. It reduces database load by caching frequently read data in memory — eliminating repeated identical queries.

Two Engines

RedisMemcached
Data structuresRich (strings, hashes, lists, sets, sorted sets, streams)Simple (strings only)
PersistenceYes (snapshots + AOF)No
ReplicationYes (primary + replicas)No
Multi-AZYesNo
Pub/SubYesNo
Use caseSessions, leaderboards, queues, rate limitingSimple horizontal caching

Choose Redis for almost everything unless you explicitly need Memcached's multi-threaded architecture for very simple cache workloads.

Caching Patterns

Lazy Loading (Cache-Aside): Application checks cache first. On a cache miss, it reads from the database and writes the result to cache.

python
def get_user(user_id):
    # 1. Check cache
    user = cache.get(f"user:{user_id}")
    if user:
        return user  # Cache hit
    
    # 2. Cache miss — read from DB
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)
    
    # 3. Write to cache with TTL
    cache.set(f"user:{user_id}", user, ttl=3600)
    return user

Write-Through: Write to cache and database simultaneously on every write. Cache is always current. Higher write latency.

TTL (Time To Live): Every cached item should have an expiry. Without TTL, stale data accumulates and memory fills up.


Redshift: Data Warehousing

Amazon Redshift is a petabyte-scale data warehouse optimised for analytical queries (OLAP), not transactional workloads (OLTP). Use Redshift for BI dashboards, data analytics, and reporting on large historical datasets. Redshift Serverless provisions and scales capacity automatically — pay only for the queries you run.


Choosing the Right AWS Database

Use Aurora or RDS for relational data with complex queries — Aurora for high performance or global multi-region, Aurora Serverless for variable traffic. Use DynamoDB for speed at any scale with a flexible schema, and DynamoDB Global Tables for global multi-active workloads. Put ElastiCache Redis in front of any database for read-heavy, slowly changing data. Use Redshift for analytical queries over large datasets.


Previous: Lesson 6 — AWS VPC & Networking | Next: Lesson 8 — High Availability & Auto Scaling


Part of the AWS Cloud Fundamentals course.

External references: