What's changed: In-scope coverage: added machine learning (SageMaker AI/Comprehend/Kendra/Polly/Rekognition/Textract/Transcribe/Translate), storage (FSx/Storage Gateway), media (Elastic Transcoder/Kinesis Video Streams), frontend/API (API Gateway/Amplify/Device Farm), analytics (Kinesis Data Streams/Data Firehose/MSK/Glue/Lake Formation/Athena/EMR/OpenSearch/QuickSight/Data Exchange), and additional databases (Aurora Serverless/DocumentDB/Keyspaces) across sections
3.3Choosing and Scaling Databases
Understand RDS/Aurora (relational), DynamoDB (serverless NoSQL), scaling reads with read replicas, and choosing purpose-built databases.
High performance means choosing a database that fits the data: RDS/Aurora for relational, DynamoDB for low-latency NoSQL at scale.
3.3.1Choosing a database
- RDS / Aurora: relational (SQL); scale reads with read replicas, HA via Multi-AZ. Aurora is MySQL/PostgreSQL-compatible, high-performance and durable.
- DynamoDB: serverless NoSQL; single-digit-ms latency at scale, for key-value/document; auto-scaling, minimal ops.
- Purpose-built: Redshift (warehouse/analytics), ElastiCache (cache), Neptune (graph)—pick the best fit.
High performance means picking a purpose-built database that fits the data and use case. Structured with important relationships (joins) → RDS/Aurora (SQL); key-value/document with ultra-low latency at scale → DynamoDB (NoSQL); large-scale aggregation/analytics → Redshift (data warehouse); graph data → Neptune. Scaling differs by what you scale: read load = read replicas (add copies), availability = Multi-AZ (auto failover—different), and DynamoDB tunes throughput auto/provisioned. Scaling writes needs different thinking (sharding, DynamoDB partition design) than reads.
| Data/use | Service |
|---|---|
| Relational (joins, transactions) | RDS / Aurora |
| Key-value/doc, ultra-low latency, scale | DynamoDB |
| Large-scale analytics (warehouse) | Redshift |
| Graph (traverse relationships) | Neptune |
| Scale reads | Read replicas |
Scenario: choosing databases. Core order data needing consistency (joins, transactions) → Aurora (SQL), with read replicas if reads are heavy. Ultra-low-latency, large-scale key-value like sessions or carts → DynamoDB. Large-scale executive dashboards → Redshift. Ensure availability separately with Multi-AZ. Combine purpose-built DBs per use.
Watch the mix-ups: (1) read replica = scale reads (performance) / Multi-AZ = availability (auto failover)—different aims. (2) RDS/Aurora (SQL, joins) vs DynamoDB (NoSQL, key-value)—choose by use. (3) Large-scale analytics use Redshift, not OLTP RDS. (4) DynamoDB is designed around access patterns, not joins.
Q. Read replica vs Multi-AZ? Read replicas scale reads (performance); Multi-AZ provides availability (auto failover). Q. RDS or DynamoDB? RDS/Aurora for joins/transactions; DynamoDB for ultra-low-latency, large-scale key-value/document. Q. Analytics? Large-scale aggregation uses Redshift (data warehouse).
Common: scale reads = read replicas, availability = Multi-AZ, serverless low-latency NoSQL = DynamoDB, large-scale analytics = Redshift, graph = Neptune. Note read-scaling and availability use different means.
3.3.2Other key in-scope services (analytics and additional databases)
For collecting, transforming, and analyzing large-scale data there is a family of purpose-built managed services. For ingest (streaming): Amazon Kinesis Data Streams ingests real-time stream data for multiple consumers; Amazon Data Firehose auto-delivers streams to S3/Redshift/OpenSearch with buffering and transforms; Amazon MSK provides a managed Apache Kafka-compatible streaming platform. For transform/catalog: AWS Glue (serverless ETL and data catalog); for centralized data-lake permissions: AWS Lake Formation. For query/search/visualize: Amazon Athena runs SQL directly over data in S3 (serverless); Amazon EMR runs large-scale distributed processing with Spark/Hadoop; Amazon OpenSearch Service handles log/full-text search and analytics; Amazon QuickSight provides BI dashboards. To obtain external data, AWS Data Exchange lets you subscribe to third-party datasets.
Beyond relational/key-value, there are more purpose-built databases. Amazon Aurora Serverless auto-scales Aurora capacity with demand—choose it for intermittent or unpredictable workloads where you want to avoid capacity management. Amazon DocumentDB is a MongoDB-compatible document database, and Amazon Keyspaces is an Apache Cassandra-compatible wide-column database—pick them to run an existing MongoDB/Cassandra data model and API as a managed service on AWS.
| What you want | Service |
|---|---|
| Ingest real-time streams | Amazon Kinesis Data Streams / Amazon MSK |
| Auto-deliver streams to S3, etc. | Amazon Data Firehose |
| Serverless ETL and catalog | AWS Glue |
| Centralize data-lake permissions | AWS Lake Formation |
| Run SQL over data in S3 | Amazon Athena |
| Large-scale Spark/Hadoop | Amazon EMR |
| Log/full-text search and analytics | Amazon OpenSearch Service |
| BI dashboards | Amazon QuickSight |
| Obtain third-party datasets | AWS Data Exchange |
| Auto-scaling Aurora | Amazon Aurora Serverless |
| MongoDB / Cassandra compatible | Amazon DocumentDB / Amazon Keyspaces |
3.3.3Section summary
- Choose RDS/Aurora (SQL/joins) / DynamoDB (NoSQL/low latency) / Redshift (analytics) / Neptune (graph) by use
- Scale reads = read replicas; availability = Multi-AZ (different aims)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which scales the "read load" of a relational database?
Q2. Which is a serverless NoSQL database with low latency at scale?
Q3. Which AWS service suits large-scale analytics (data warehouse)?