AWS Database Services: Categories and Use Cases

AWS does not offer one database that is ideal for every workload. A banking transaction system, a shopping cart, an IoT telemetry stream, and a social graph have different data shapes and access patterns. The purpose-built database approach is to choose a service based on how the application stores, reads, and writes its data.

This is Part 30 of the AWS Cloud Practitioner Study Notes. Part 29 compared self-managed databases, Amazon RDS, Aurora, Multi-AZ deployments, read replicas, and backups.

AWS database categories

Category	Main AWS services	Best suited to
Relational	Amazon RDS, Amazon Aurora	Structured data, SQL, joins, and transactions
Key-value and document	Amazon DynamoDB	Known access patterns and high-scale low-latency lookups
Document	Amazon DocumentDB	JSON-like documents and MongoDB-compatible workloads
In-memory	Amazon ElastiCache, Amazon MemoryDB	Caching or very low-latency data access
Graph	Amazon Neptune	Highly connected data and relationship traversal
Wide-column	Amazon Keyspaces	Apache Cassandra-compatible distributed workloads
Time series	Amazon Timestream	Timestamped telemetry, metrics, and IoT data
Data warehouse	Amazon Redshift	Large-scale analytical queries and reporting
Self-managed	Database on Amazon EC2	Full operating-system and database control

The category is a starting point, not an automatic answer. Consider the data model, query pattern, consistency needs, latency target, scale, availability, and operational responsibility before choosing a service.

1. Relational databases: RDS and Aurora

Relational databases organise data into tables with rows and columns. Tables can be connected with relationships such as a customer ID or order ID.

Customers                  Orders
+-------------+------+     +----------+-------------+--------+
| customer_id | name |     | order_id | customer_id | total  |
+-------------+------+     +----------+-------------+--------+
| 101         | Alice|     | 5001     | 101         | 120.00 |
+-------------+------+     +----------+-------------+--------+

Use a relational database when you need SQL, joins, transactions, a structured schema, referential integrity, or strong consistency for business operations such as orders, payments, inventory, ERP, and CRM.

Amazon RDS

Amazon RDS is a managed service for common relational database engines. Supported engines include MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and IBM Db2, subject to Region and version availability.

Choose RDS when:

• You are migrating a conventional relational database.
• You need a specific supported commercial or open-source engine.
• You want SQL transactions without managing the underlying database host.
• AWS should handle common provisioning, patching, backup, and infrastructure tasks.

Amazon Aurora

Amazon Aurora is a fully managed relational engine compatible with MySQL and PostgreSQL. It uses a cloud-optimised cluster and storage architecture and is designed for workloads that need high availability, read scaling, and automatic storage growth.

Aurora can be a strong fit for large transactional applications, SaaS platforms, and high-traffic systems. RDS can be more appropriate when you need Oracle, SQL Server, Db2, MariaDB, or a specific standard-engine feature.

RDS     → Managed standard database engines
Aurora  → Managed AWS-designed MySQL/PostgreSQL-compatible engine

Neither is universally “better”. The correct choice depends on compatibility, features, workload behaviour, cost, and operational requirements.

2. Key-value and document databases: DynamoDB

Amazon DynamoDB is a serverless, managed NoSQL database that supports key-value and document data models. A key-value record might look like this:

{
  "user_id": "U123",
  "username": "chinsiang",
  "status": "active"
}

The application normally retrieves items using a partition key and designs the table around known access patterns. DynamoDB is a good fit for high-traffic applications that need predictable, low-latency access without managing database servers.

Common workloads include:

• Shopping carts
• User sessions and profiles
• Gaming leaderboards
• IoT device state
• Product catalog lookups
• Mobile and web backends

DynamoDB is not usually the first choice for complex joins, frequently changing ad hoc queries, or deeply relational data. In DynamoDB, the access patterns should influence the table and index design before implementation.

Exam shortcut: serverless key-value database, massive scale, or low-latency lookups by a known key → Amazon DynamoDB.

3. Document databases: Amazon DocumentDB

Amazon DocumentDB is a fully managed document database with MongoDB compatibility. It stores JSON-like documents with nested fields rather than requiring every record to have the same relational columns.

{
  "product_id": "P100",
  "name": "Running Shoes",
  "sizes": [7, 8, 9, 10],
  "attributes": {
    "material": "mesh",
    "waterproof": false
  }
}

DocumentDB can suit content management, product catalogs, user profiles, and applications migrating from compatible MongoDB workloads. Its document query model is richer than a simple key lookup, while its managed cluster model removes much of the infrastructure administration.

The important distinction is that MongoDB compatibility does not mean DocumentDB is the MongoDB service itself. Applications should validate driver, feature, and operator compatibility before migrating.

DocumentDB → MongoDB-compatible document workloads
DynamoDB   → AWS-native key-value/document workloads designed around access patterns

4. In-memory services: ElastiCache and MemoryDB

In-memory systems keep frequently accessed data in memory to provide very fast access.

Amazon ElastiCache

Amazon ElastiCache is primarily used as a managed caching layer. Depending on configuration and Region, it supports engines such as Valkey, Redis OSS, and Memcached.

A common cache-aside flow is:

Application → ElastiCache
             ├── cache hit → return quickly
             └── cache miss → read durable database → populate cache

Use ElastiCache for database query caching, API-response caching, sessions, frequently accessed objects, and leaderboards. The durable source of truth usually remains in RDS, Aurora, DynamoDB, or another database.

Amazon MemoryDB

Amazon MemoryDB is a durable, Redis-compatible in-memory database. It is a better fit when the in-memory data itself is the authoritative application database and losing the data as if it were a disposable cache would be unacceptable.

Service	Primary role
ElastiCache	Temporary performance layer in front of a durable store
MemoryDB	Durable primary database with Redis-compatible data structures

Exam shortcut: cache database reads → ElastiCache; durable Redis-compatible primary database → MemoryDB.

5. Graph database: Amazon Neptune

Graph databases model entities and the relationships between them. This is useful when the connections are as important as the entities themselves.

Alice ──follows──> Bob
  │                 │
works_at          bought
  │                 │
  ▼                 ▼
Company A         Product X

Amazon Neptune is a managed graph database for highly connected datasets. Use it for social networks, recommendation engines, fraud detection, knowledge graphs, identity relationships, and network dependency mapping.

For example, asking which accounts share a device, address, payment card, or connection to known fraudulent accounts is naturally a graph traversal problem. A relational database can represent the data, but a graph database is purpose-built for navigating those relationships.

Exam shortcut: highly connected data, social graph, recommendations, or fraud relationships → Amazon Neptune.

6. Wide-column database: Amazon Keyspaces

Amazon Keyspaces for Apache Cassandra is a managed, highly available, Cassandra-compatible wide-column database. Wide-column systems are designed for large distributed datasets with access patterns based around partition keys and high throughput.

Choose Keyspaces when:

• You already have Apache Cassandra applications.
• You need Cassandra Query Language compatibility.
• The workload needs high write throughput and low latency.
• You want to migrate Cassandra without operating clusters yourself.

Typical workloads include IoT event storage, device history, activity feeds, industrial telemetry, and large distributed messaging data.

Keyspaces  → Cassandra-compatible workloads
DynamoDB   → AWS-native serverless key-value/document workloads

7. Time-series database: Amazon Timestream

Time-series data is recorded with timestamps and commonly queried over time ranges.

Time	Device	Temperature
09:00:00	sensor-1	26.2°C
09:00:05	sensor-1	26.4°C
09:00:10	sensor-1	26.8°C

Amazon Timestream for LiveAnalytics is a managed, purpose-built time-series database. It is suited to IoT telemetry, application metrics, DevOps monitoring, industrial equipment, vehicle tracking, energy consumption, and other measurements where trends and time windows matter.

Use Timestream when queries ask for averages, maximums, changes, or anomalies over a time range. A relational database can store timestamps, but Timestream provides a data model and query features designed around time-series workloads.

8. Data warehouse: Amazon Redshift

Amazon Redshift is a cloud data warehouse for large-scale analytical workloads. It is not normally the primary transactional database for an application.

OLTP application database:
  Create one order
  Update one customer
  Read one product

OLAP data warehouse:
  Analyse five years of sales
  Compare revenue by country
  Aggregate billions of records

Use Redshift for business intelligence, financial reporting, customer analytics, dashboards, historical analysis, and SQL queries that aggregate large datasets from multiple systems.

RDS / Aurora → Run the business
Redshift     → Analyse the business

The distinction is workload-oriented: application transactions favour many small, consistent reads and writes; analytics favours scanning and aggregating large volumes of data.

9. Database on Amazon EC2

You can install almost any database technology on an EC2 instance. This gives you full operating-system access, custom extensions, unusual versions, and control over the configuration.

You are also responsible for installation, patching, backups, replication, failover, monitoring, database security, and operating-system maintenance. Use EC2 when a managed service does not support a required engine or custom dependency, or when the organisation has a specific reason to own the full database stack.

For standard workloads, managed services usually reduce operational effort. For specialised workloads, EC2 may provide the control that a managed service cannot.

Choosing the right AWS database

Use the workload as the decision path:

Need SQL, joins, and transactions?
├── Standard engine or migration → RDS
└── MySQL/PostgreSQL-compatible AWS engine → Aurora

Need key-based, serverless, low-latency access? → DynamoDB
Need flexible JSON documents or MongoDB compatibility? → DocumentDB
Need a cache? → ElastiCache
Need a durable Redis-compatible primary database? → MemoryDB
Are relationships the central problem? → Neptune
Is the workload based on Cassandra? → Keyspaces
Is data continuously measured over time? → Timestream
Need large-scale analytics and reporting? → Redshift
Need complete OS-level control? → Database on EC2

One application can use several databases

Purpose-built does not mean an application must use only one database. An e-commerce platform might use:

Customers and orders       → Aurora or RDS
Shopping carts and sessions → DynamoDB
Frequently viewed products  → ElastiCache
Flexible product documents  → DocumentDB
Recommendations             → Neptune
Click and device data       → Timestream
Business reports            → Redshift

Each service owns a workload that matches its strengths. This can improve performance and fit, but it also increases architectural complexity. Every additional database introduces data synchronisation, operational, security, backup, and observability concerns.

Common exam scenarios

Requirement	Likely answer
Managed MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, or Db2	Amazon RDS
High-performance managed MySQL- or PostgreSQL-compatible relational database	Amazon Aurora
Serverless key-value database at high scale	Amazon DynamoDB
MongoDB-compatible document database	Amazon DocumentDB
Cache database queries or sessions	Amazon ElastiCache
Durable Redis-compatible in-memory database	Amazon MemoryDB
Social-network relationships or fraud graph	Amazon Neptune
Managed Apache Cassandra workload	Amazon Keyspaces
IoT measurements and metrics over time	Amazon Timestream
Large-scale business analytics	Amazon Redshift
Full database and operating-system control	Database on EC2

Common exam traps

DynamoDB versus RDS

• DynamoDB: NoSQL key-value/document model, known access patterns, high scale.
• RDS: SQL, relational tables, joins, and transactions.

ElastiCache versus DynamoDB

• ElastiCache: usually a temporary acceleration layer.
• DynamoDB: a durable application database.

Redshift versus RDS

• RDS: operational transactions.
• Redshift: analytical queries and warehousing.

DocumentDB versus DynamoDB

• DocumentDB: MongoDB-compatible document workloads with richer document queries.
• DynamoDB: AWS-native key-value/document workloads designed around access patterns.

Multi-AZ versus read replicas

These are deployment features discussed in Part 29, not separate database categories:

• Multi-AZ: high availability and failover.
• Read replicas: read scaling.

Conclusion

The purpose-built database approach starts with the workload rather than the service name. Use RDS or Aurora for relational transactions, DynamoDB for key-value access at scale, DocumentDB for MongoDB-compatible documents, ElastiCache for caching, MemoryDB for durable in-memory data, Neptune for connected data, Keyspaces for Cassandra, Timestream for timestamped data, and Redshift for analytics.

The best architecture may use several services, but each additional database should have a clear reason to exist. Matching the data model and access pattern to the service is more useful than memorising a claim that one database is always faster or better.

Sources

• AWS purpose-built databases
• AWS database service overview
• Choosing an AWS database service
• Amazon DocumentDB with MongoDB compatibility
• Amazon Timestream for LiveAnalytics