Databases in AWS – Choosing the Right One

1. Choosing the right database

AWS offers a large catalog of managed databases, and the hard part of the SAA-C03 exam is rarely remembering that a service exists — it is picking the right one for the problem described in the question. This chapter is therefore a summary chapter: it gathers services covered earlier in the course and lines them up so the differences become obvious.

To choose the right database for your architecture, work through the following questions:

Is the workload read-heavy, write-heavy, or balanced? What are the throughput needs? Will that throughput change, does it need to scale, does it fluctuate during the day?
How much data will you store, and for how long? Will it grow? What is the average object size? How are objects accessed?
What are the data durability requirements? Is this database the source of truth for the data?
What are the latency requirements, and how many concurrent users are there?
What is the data model, and how will you query the data? Do you need joins? Is the data structured or semi-structured?
Do you need a strong schema or more flexibility? Do you need reporting? Do you need search? Is this an RDBMS or a NoSQL problem?
What are the license costs, and would switching to a cloud-native database such as Aurora remove them?

2. Database types

The deck groups the services by the kind of data problem they solve:

RDBMS (SQL / OLTP) — RDS and Aurora. These are the services to reach for when the workload needs joins.
NoSQL (no joins, no SQL) — DynamoDB (roughly JSON documents), ElastiCache (key/value pairs), Neptune (graphs), DocumentDB (for MongoDB) and Keyspaces (for Apache Cassandra).
Object store — S3 for large objects, Glacier for backups and archives.
Data warehouse (SQL analytics / BI) — Redshift (OLAP), Athena and EMR.
Search — OpenSearch (JSON), for free-text and unstructured searches.
Graphs — Amazon Neptune, which represents relationships between data.
Ledger — Amazon Quantum Ledger Database.
Time series — Amazon Timestream.

The deck closes the list with a pointer rather than a rule: some of these databases are discussed in the Data & Analytics section, so expect to meet part of this list again in the Data & Analytics chapter.

3. Amazon RDS – summary

Amazon RDS is the managed relational database service. It covers six engines — PostgreSQL, MySQL, Oracle, SQL Server, DB2 and MariaDB — and RDS Custom additionally hands you access to the underlying instance so you can customize it, an option that exists for Oracle and SQL Server only.

Sizing is explicit: you provision the RDS instance size together with the EBS volume type and size, although storage carries an auto-scaling capability so it can grow on its own. Availability and extra read throughput come from Read Replicas and Multi AZ. Protection is assembled from IAM, Security Groups, KMS and SSL in transit, and on top of that sit IAM authentication and an integration with Secrets Manager.

Recovery has two mechanisms. Automated backups support point-in-time restore and are retained up to 35 days; a manual DB snapshot is what you take when a copy has to outlive that window. Maintenance is managed and scheduled by AWS, and it comes with downtime — worth remembering, because most of the other services in this chapter do not say so.

Use case: storing relational datasets (RDBMS / OLTP), and running SQL queries and transactions against them.

4. Amazon Aurora – summary

Amazon Aurora is AWS’s own implementation of a relational engine. It offers a compatible API for PostgreSQL and MySQL, and its defining design choice is the separation of storage and compute.

Underneath, the storage layer keeps the data in 6 replicas across 3 AZ, which is where its high availability, self-healing and auto-scaling behavior comes from. Above it, compute is a cluster of DB instances spread across multiple AZ with auto-scaling of Read Replicas, and the cluster publishes custom endpoints pointing separately at the writer and at the reader instances. Everything around the engine — security, monitoring and maintenance — works as it does on RDS, and the deck expects you to know Aurora’s backup and restore options.

Four Aurora-specific capabilities carry their own exam weight. Aurora Serverless removes capacity planning and is aimed at unpredictable or intermittent workloads. Aurora Global allows up to 16 DB read instances in each region, with storage replication under 1 second. Aurora Machine Learning performs ML on Aurora data through SageMaker and Comprehend. Aurora Database Cloning produces a new cluster from an existing one and is faster than restoring a snapshot.

Use case: the same ground RDS covers, but with less maintenance, more flexibility, more performance and more features.

5. Amazon ElastiCache – summary

Amazon ElastiCache is managed Redis / Memcached — the deck describes it as a similar offering to RDS, only pointed at caches. It is an in-memory data store answering in sub-millisecond latency, and like RDS it is instance-based: you select an ElastiCache instance type, for example cache.m6g.large.

The operational surface mirrors RDS as well. There is support for clustering (Redis), Multi AZ and Read Replicas (sharding); security is drawn from IAM, Security Groups, KMS and Redis Auth; backup, snapshot and point-in-time restore are available, and maintenance is again managed and scheduled. What it does not offer is transparency — leveraging a cache requires some changes to your application code.

Use case: a key/value store for workloads that are read-frequent and write-light — caching the results of database queries, holding session data for websites. SQL is not an option here.

6. Amazon DynamoDB – summary

DynamoDB is AWS proprietary technology: a managed, serverless NoSQL database answering in millisecond latency. Capacity arrives in two modes — provisioned capacity with optional auto-scaling, or on-demand capacity. It is highly available and Multi AZ by default, its reads and writes are decoupled, and it has transaction capability. A DAX cluster can sit in front of it as a read cache, taking read latency down to microseconds. Because a table needs no migration to take a new attribute, DynamoDB is great for rapidly evolving schemas, and with the TTL feature it can replace ElastiCache as a key/value store — session data being the deck’s example.

Security, authentication and authorization are all done through IAM. For event processing, DynamoDB Streams integrates with AWS Lambda or with Kinesis Data Streams, and the Global Table feature produces an active-active setup. On the backup side there are automated backups up to 35 days with PITR, which restore into a new table, as well as on-demand backups; within the PITR window you can export to S3 without using RCU and import from S3 without using WCU.

Use case: serverless application development over small documents (100s KB), and a distributed serverless cache.

7. Amazon S3 – summary

Although it is not usually called a database, S3 is a key/value store for objects and so belongs in this comparison. Its sweet spot is larger objects; a workload made of a great many small objects is a poor match for it. It is serverless and scales infinitely, the maximum object size is 5 TB, and it has a versioning capability.

Storage classes — S3 Standard, S3 Infrequent Access, S3 Intelligent-Tiering and S3 Glacier — pair with lifecycle policies that move objects between them over time. Around the bucket sit versioning, encryption, replication, MFA-Delete and access logs, while access itself is controlled through IAM, bucket policies, ACL, Access Points, Object Lambda, CORS and Object/Vault Lock. Encryption is offered as SSE-S3, SSE-KMS, SSE-C and client-side encryption, with TLS in transit and a default encryption setting on the bucket.

Bulk work is served by S3 Batch for operations across many objects and S3 Inventory for listing files. The performance features to remember are multi-part upload, S3 Transfer Acceleration and S3 Select. Automation comes from S3 Event Notifications, which can target SNS, SQS, Lambda and EventBridge.

Use cases: static files, a key/value store for big files, and website hosting.

8. DocumentDB

If Aurora is an “AWS implementation” of PostgreSQL / MySQL, then DocumentDB is the same idea applied to MongoDB, which is a NoSQL database. MongoDB is used to store, query and index JSON data.

Its deployment concepts resemble Aurora’s. AWS runs the whole thing for you and keeps it available by replicating the data across 3 AZ. Storage grows on its own in increments of 10 GB, and the service scales automatically to workloads of millions of requests per second.

9. Amazon Neptune

Amazon Neptune is a fully managed graph database. The classic graph dataset is a social network: users have friends, posts have comments, comments have likes from users, users share and like posts. Modeling that in a relational schema means many join tables; a graph database stores the relationships directly.

AWS keeps the cluster available across 3 AZ, and it supports up to 15 read replicas.
Built for applications working with highly connected datasets, and optimized for the complex, hard queries those datasets produce.
Can store billions of relations and query the graph with millisecond latency.
Great for knowledge graphs (Wikipedia-style), fraud detection, recommendation engines and social networking.

Neptune Streams

Neptune Streams is a real-time, ordered sequence of every change made to your graph data.

Changes are available immediately after writing.
No duplicates, strict order.
The stream data is accessible through an HTTP REST API — in the deck’s diagram a Streams reader application issues an HTTP GET request against the Streams API.

Use cases named on the slide:

Send notifications when certain changes are made.
Keep your graph data synchronized in another data store, for example S3, OpenSearch or ElastiCache.
Replicate data across regions in Neptune.

10. Amazon Keyspaces (for Apache Cassandra)

Apache Cassandra is an open-source, distributed NoSQL database; Amazon Keyspaces is a managed, Cassandra-compatible database service.

Serverless, scalable, highly available, fully managed by AWS.
Tables scale up and down automatically based on the application’s traffic.
Tables are replicated 3 times across multiple AZ.
You query with the Cassandra Query Language (CQL).
Single-digit millisecond latency at any scale, thousands of requests per second.
Capacity: on-demand mode, or provisioned mode with auto-scaling.
Encryption, backup and Point-In-Time Recovery (PITR) up to 35 days.
Use cases: storing IoT device information and time-series data.

11. Amazon Timestream

Amazon Timestream is AWS’s database for time series data. It is serverless and fully managed, and the deck bills it as both fast and scalable.

Automatically scales up and down to adjust capacity.
Stores and analyzes trillions of events per day.
Thousands of times faster and one tenth the cost of relational databases for this shape of data.
Scheduled queries, multi-measure records and SQL compatibility.
Data storage tiering: recent data is kept in memory, historical data in cost-optimized storage.
Built-in time series analytics functions that help identify patterns in near real time.
Encryption in transit and at rest.
Use cases: IoT applications, operational applications, real-time analytics.

Architecturally, Timestream sits between producers and consumers:

Ingesting into it: AWS IoT, Kinesis Data Streams (directly or through Lambda), Prometheus, Amazon MSK, and Kinesis Data Analytics for Apache Flink.
Consuming from it: Amazon QuickSight, Amazon SageMaker, and any JDBC connection.

Quick recap

Service	What to remember for the exam
RDS	RDBMS/OLTP, six engines plus RDS Custom; Read Replicas and Multi AZ; PITR up to 35 days; storage auto-scaling; RDS Custom is Oracle and SQL Server only; maintenance involves downtime
Aurora	PostgreSQL/MySQL-compatible, storage separated from compute; 6 replicas across 3 AZ, self-healing; separate writer and reader endpoints; Serverless for unpredictable workloads; Global: 16 read instances per region, under 1 second replication; cloning is faster than a snapshot restore
ElastiCache	Managed Redis/Memcached, in-memory sub-millisecond, you pick an instance type, clustering plus Multi AZ plus Read Replicas; requires application code changes; no SQL
DynamoDB	AWS-proprietary serverless NoSQL, Multi AZ by default, provisioned (with auto-scaling) or on-demand; DAX read cache with microsecond latency; Streams into Lambda or Kinesis; Global Tables are active-active; PITR 35 days; export to S3 costs no RCU, import costs no WCU; documents of hundreds of KB
S3	Key/value store for objects, max 5 TB, serverless and infinitely scalable; Standard / IA / Intelligent-Tiering / Glacier plus lifecycle; SSE-S3, SSE-KMS, SSE-C, client-side; good for big objects, poor for many small ones
DocumentDB	The “Aurora of MongoDB”, JSON document NoSQL, 3 AZ, storage grows in 10 GB increments, millions of requests per second
Neptune	Graph database, 3 AZ, up to 15 read replicas, billions of relations, millisecond queries; knowledge graphs, fraud detection, recommendations, social networks; Neptune Streams is strictly ordered, duplicate-free, read over an HTTP REST API
Keyspaces	Managed Apache Cassandra, serverless, CQL, tables replicated 3 times across AZ, single-digit ms, on-demand or provisioned with auto-scaling, PITR up to 35 days; IoT and time-series data
Timestream	Serverless time series, 1000s of times faster and 1/10th the cost of relational databases, trillions of events per day, memory plus cheap storage tiering, built-in time series functions
Choosing map	Need joins: RDS/Aurora · very fast key/value: DynamoDB/ElastiCache · big objects: S3/Glacier · analytics/BI: Redshift, Athena, EMR · free-text search: OpenSearch · graph: Neptune · ledger: Amazon QLDB · time series: Timestream