AWS Databases: When and Why to Use Each Service

Imagine you’re building an app. Your app needs to store data — user profiles, orders, product listings, session tokens, activity feeds. But where do you put it all?

AWS offers a whole family of database services — each designed for a different kind of problem. Picking the wrong one can mean slow queries, high bills, or rebuilding your data layer from scratch six months later.

Practice Resources for AWS Solutions Architect Associate Exam

If you are preparing for the AWS Certified Solutions Architect — Associate exam and looking for topic-wise practice questions, structured learning paths, and study materials, check out the following resource repository:

👉 https://amitpnk.github.io/AWS-Solutions-Architect-Associate-Exam/

It includes categorized preparation content designed to help you strengthen your concepts and improve exam readiness effectively.

AWS Database Family

The quick cheat sheet

Before we go deep, here’s the one-liner for each service:

Deep dives

Now let’s understand each service in depth — what makes it special, when to use it, when not to.

Amazon RDS — The Reliable Workhorse

Think of RDS as hiring a full-time DBA who handles all the boring but critical stuff: backups, patching, failover, monitoring. You just write SQL and let AWS handle the infrastructure.

The analogy: Renting a house instead of building one. The landlord (AWS) handles plumbing, electricity, and roof repairs. You just live there.

• Supports 6 engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora
• Automated backups retained up to 35 days, with point-in-time recovery
• Multi-AZ deployment — synchronous standby in a second AZ, automatic failover
• Read Replicas — async copies to offload read-heavy queries (up to 5 for MySQL/Postgres)
• RDS Proxy — connection pooler that reduces failover time and manages Lambda connections
• Encryption at rest (KMS) and in transit (SSL/TLS)
• Automated minor patching — you control the maintenance window

SAA-C03 Exam Tips:

• Multi-AZ is for high availability (HA), NOT for performance — the standby is not readable.
• Read Replicas are for read scaling and can be promoted to standalone DB.
• Multi-AZ failover is automatic and typically takes 1–2 minutes.
• RDS Proxy is the answer when Lambda functions are exhausting DB connections.
• You cannot SSH into an RDS instance — it is a managed service.

Example: E-commerce backends, CRM systems, ERP software, WordPress / CMS, Lift-and-shift migrations

Amazon Aurora — The Speed Demon

Aurora is AWS’s own database engine. It looks like MySQL or PostgreSQL to your app, but the storage layer is completely rebuilt — distributed across 6 copies in 3 Availability Zones, growing automatically in 10 GB increments up to 128 TB.

The analogy: RDS is a Toyota Camry — reliable, practical. Aurora is a Tesla — same roads, same destination, but a fundamentally different engine and substantially faster.

• Storage auto-grows in 10 GB increments up to 128 TB — no capacity planning needed
• Up to 15 Aurora Read Replicas with near-zero replication lag (versus 5 for RDS)
• Failover to a replica in under 30 seconds (faster than RDS Multi-AZ)
• 6 copies of data across 3 AZs — can lose 2 copies without data loss (write quorum = 4 of 6)
• Aurora Global Database — primary in one region, up to 5 read-only secondary regions, sub-1s replication lag, cross-region disaster recovery in under 1 minute
• Backtrack feature — rewind Aurora DB in place to a past point without restoring a snapshot
• Custom Endpoints — route different query types to different replica groups

SAA-C03 Exam Tips:

• Aurora stores data in a shared cluster volume — NOT on instance local storage.
• Replicas share the same storage (no replication lag like RDS). If the question mentions “high availability + high performance relational DB” → Aurora.
• Aurora Global Database is the answer for cross-region DR with RPO of seconds.
• Backtrack is Aurora-only — used to undo mistakes without a restore. One writer endpoint + one reader endpoint, plus optional custom endpoints.

Example: SaaS platforms, High-traffic APIs, Fintech, Global applications, When RDS isn’t fast enough

Aurora Serverless — The Sleeping Giant

Aurora Serverless v2 adjusts capacity in fine increments as small as 0.5 Aurora Capacity Units (ACUs). Traffic spike? It scales up in milliseconds. Nobody using it at 3am? It scales down. v1 can even fully pause and resume.

The analogy: A regular Aurora is a restaurant with 20 chefs at all times. Aurora Serverless is a ghost kitchen that spins up exactly as many chefs as there are orders — automatically.

• Pay per ACU-second — no charges when paused (v1) or at minimum (v2)
• v2 scales much faster than v1, supports Multi-AZ, Read Replicas, Global Database
• v1 supports autopause — DB shuts down after inactivity period (saves cost for dev/test)
• Accessed via Data API — no persistent connections needed (great for Lambda)
• No connection pool limits when using the Data API

SAA-C03 Exam Tips:

• When the question says “unpredictable traffic” or “intermittent usage” or “dev/test environment” and asks for a relational DB → Aurora Serverless is likely the answer.
• v1 autopause = cost savings for rarely-used databases.
• v2 = production-grade serverless with better scaling.
• Aurora Serverless v2 works with Aurora Global Database; v1 does not.

Example: Dev/test environments, Infrequent workloads, New projects (unknown traffic), Batch processing

Amazon DynamoDB — The Scale Monster

DynamoDB is the database AWS built to handle Amazon.com itself — Black Friday spikes, Prime Day, all of it. There are no servers to manage. You define throughput (or use on-demand mode), and it handles everything else. It’s truly serverless — scales to handle trillions of requests per day.

The analogy: A relational database is a filing cabinet — organised, but you have to go to one spot. DynamoDB is a massive warehouse with instant barcode scanning. Extremely fast if you know the barcode. Not great if you want to browse.

• Single-digit millisecond reads at any scale — no degradation as you grow
• DAX (DynamoDB Accelerator) — in-memory caching in front of DynamoDB, microsecond reads
• Two capacity modes: Provisioned (predictable load) and On-Demand (unpredictable load)
• DynamoDB Streams — ordered log of item-level changes, triggers Lambda in real time
• Global Tables — multi-active replication across multiple AWS regions (active-active)
• TTL (Time to Live) — automatically delete expired items, no cost
• Transactions — ACID transactions across multiple items/tables
• Point-in-time recovery (PITR) up to 35 days

SAA-C03 Exam Tips :

• DynamoDB is the go-to for “serverless”, “key-value”, “NoSQL”, “massive scale”, or “session management” questions.
• DAX = microsecond reads (add in front of DynamoDB).
• DynamoDB Streams + Lambda = event-driven architecture.
• Global Tables = multi-region active-active (not just DR, actual writes in multiple regions).
• On-Demand mode = no capacity planning, cost scales with requests.
• Key limitation: you must define your access patterns upfront — no ad-hoc SQL queries.

Example: Shopping carts, Session storage, Gaming state, IoT telemetry, Real-time bidding, Serverless apps

Amazon DocumentDB — The JSON Lover

DocumentDB stores data as JSON-like documents — nested, flexible structures without rigid schemas. It’s compatible with MongoDB 3.6, 4.0, and 5.0 drivers, so you can move existing MongoDB applications with minimal code changes.

The analogy: A relational database is a spreadsheet — every row has the same columns. DocumentDB is a folder of sticky notes — each note can have completely different information.

• Schema-free — add fields to documents without migrating the whole collection
• Rich queries on nested fields, arrays, and embedded documents
• Storage scales automatically up to 64 TB
• 6 copies of data across 3 AZs (same storage architecture as Aurora)
• Up to 15 read replicas for read scaling
• Continuous backup to S3 with PITR

SAA-C03 Exam Tips:

• If the question mentions “MongoDB”, “document database”, or “JSON data with complex queries” → DocumentDB.
• Key differentiator from DynamoDB: DocumentDB supports richer, ad-hoc queries on nested JSON. DynamoDB is faster and infinitely scalable but requires predefined access patterns. DocumentDB is the managed AWS option when a customer is migrating from MongoDB and wants to stay on AWS.

Examples: Content management, User profiles, Product catalogs, MongoDB migrations

Amazon ElastiCache — The Memory Master

In-memory caching — Redis or Memcached, sub-millisecond latency

ElastiCache keeps your most-requested data in RAM — which is orders of magnitude faster than reading from disk. A database query that takes 50ms might take under 1ms from cache. At scale, that difference is everything.

The analogy: Your main database is a library. ElastiCache is your desk — the books you’re reading right now are right there, no walking to the stacks.

• Sub-millisecond latency — consistently faster than any disk-based database
• Redis Cluster mode — partitions data across multiple shards for horizontal scale
• Redis Multi-AZ with automatic failover (like RDS Multi-AZ)
• ElastiCache Serverless — no cluster to size, scales automatically (Redis only)
• At-rest and in-transit encryption for Redis

SAA-C03 Exam Tips:

• ElastiCache is the answer when the question asks about reducing database load, caching query results, or sub-millisecond latency.
• Redis vs Memcached: choose Redis if you need persistence, replication, Pub/Sub, sorted sets, or complex data structures.
• Choose Memcached for simple, multi-threaded, pure caching with no persistence needed.
• ElastiCache is NOT a primary database — it complements one. Data loss is possible (unless Redis persistence is enabled).

Examples: API response caching, Session management, Leaderboards, Rate limiting, Pub/sub messaging

Amazon Neptune — The Relationship Expert

Graph database — traverse millions of relationships in milliseconds

In a relational database, relationships are stored as foreign keys and JOINs. For simple relationships, that works fine. But when data is deeply connected — six degrees of separation, fraud ring detection, knowledge graphs — JOINs become unbearably slow. Neptune stores relationships as first-class citizens.

The analogy: A regular database tracks people in rows and relationships in separate tables, requiring complex JOINs. Neptune is like a whiteboard with circles (nodes) and lines (edges) between them — traverse the network directly.

• Two graph models: Property Graph (Gremlin, openCypher) and RDF (SPARQL)
• Traverse millions of relationships in milliseconds
• Up to 15 read replicas, Multi-AZ, automatic failover
• 6 copies of data across 3 AZs (same architecture as Aurora)
• Neptune Analytics — fast analytics on large graphs using graph algorithms
• Neptune Streams — ordered change log for graph data

SAA-C03 Exam Tips:

• Whenever you see “social network”, “fraud detection”, “recommendation engine”, “knowledge graph”, or “highly connected data” in a question → Neptune is the answer.
• Graph databases excel when the relationships between data are as important as the data itself.
• Neptune is NOT good for simple key-value lookups or analytics on flat data.

Examples: Fraud detection, Social networks, Knowledge graphs, Recommendation engines, Network topology

Amazon Keyspaces — The Time Series Champion

Apache Cassandra compatible — wide-column, serverless, write-heavy workloads

Keyspaces is the managed version of Apache Cassandra. Cassandra shines at write-heavy workloads with massive datasets — billions of time-series events, sensor readings, or log records. It organises data in wide rows with flexible columns, making range queries by time or partition key very efficient.

The analogy: If DynamoDB is great for finding one record instantly by key, Keyspaces is great for reading “all sensor readings from device-7 between 9am and 10am” — range scans across massive, write-heavy datasets.

• Cassandra Query Language (CQL) — similar to SQL, familiar for Cassandra users
• Serverless — no cluster to provision, patch, or manage
• Automatically replicated 3 times across multiple AZs
• Point-in-time recovery and encryption at rest
• Two modes: On-Demand and Provisioned (with auto-scaling)
• Compatible with existing Cassandra application drivers

SAA-C03 Exam Tips:

• If the question mentions “Apache Cassandra”, “migration from Cassandra”, “wide-column database”, “IoT time-series data”, or “billions of rows with write-heavy workloads” → Keyspaces.
• Key difference from DynamoDB: Keyspaces supports Cassandra’s flexible schema and CQL; DynamoDB requires fixed partition + sort key design.
• Both are serverless NoSQL, but they target different data models.

Examples: IoT sensor data, Time-series events, Audit logs, Cassandra migrations, Write-heavy workloads

Key features the exam tests heavily

Beyond knowing which database to pick, the SAA-C03 tests your understanding of specific features. Here’s what comes up most often:

Database selection decision tree

Below is decision tree for selecting right database

Quick comparison for SAA-C03

The one rule to remember

There is no “best” database. There’s only the right tool for the job — and the right answer for the exam scenario.

Most real-world applications use multiple databases simultaneously. A typical e-commerce platform might use Aurora for orders, DynamoDB for session state and cart data, ElastiCache for caching product listings, Redshift for analytics, and Neptune for recommendations.

For the SAA-C03 exam: Read the scenario carefully. Look for keywords:

• “relational” → RDS/Aurora.
• “serverless NoSQL” → DynamoDB.
• “millisecond reads, cache” → ElastiCache.
• “MongoDB” → DocumentDB.
• “graph, social, fraud” → Neptune.
• “analytics, warehouse, OLAP” → Redshift.
• “Cassandra, IoT, time-series” → Keyspaces.
• “variable traffic, auto-scale SQL” → Aurora Serverless.