7. Database

Solutions Architects must choose between Relational (SQL) and Purpose-Built (NoSQL/Other) engines based on performance and schema requirements.

Amazon Aurora / Aurora Serverless

Service Introduction: Engine: Relational. A cloud-native, MySQL and PostgreSQL-compatible database that is up to 5x faster than standard MySQL.

Common Usage: High-performance enterprise applications requiring 99.99% availability and global read replicas. Key Sub-Features (exam-critical):

• Aurora Serverless v2 — Auto-scales compute capacity in fine-grained increments for spiky, intermittent, or unpredictable workloads (e.g., dev/test databases used a few minutes a day); minimizes cost for underutilized clusters.
• Aurora Global Database — A primary Region plus up to 5 secondary read-only Regions, with typical replication lag <1 second and a secondary-Region promotion time of <1 minute — the standard answer for cross-Region RPO≈1s / RTO≈1min requirements.
• Aurora Replicas — Up to 15 low-latency read replicas within a Region, sharing the same underlying storage volume as the primary.

Project Examples:

• Primary transactional database for a global e-commerce platform.
• Serverless database for an application with highly unpredictable traffic patterns.

Amazon DocumentDB

Service Introduction: Engine: Document (NoSQL). A fast, scalable, highly available, and fully managed MongoDB-compatible database.

Common Usage: Storing and querying semi-structured data (JSON) with high durability and automated scaling.

Project Examples:

• Managing user profiles and content metadata for a streaming service.
• Building a flexible Content Management System (CMS) for a news portal.

Amazon DynamoDB

Service Introduction: Engine: Key-Value / Document (NoSQL). A serverless database that delivers single-digit millisecond performance at any scale.

Common Usage: High-traffic applications (gaming, ad-tech) requiring consistent latency and horizontal scalability via partitioning. Key Sub-Features (exam-critical):

• DynamoDB Accelerator (DAX) — In-memory cache in front of DynamoDB; reduces read latency from milliseconds to microseconds for read-heavy/hot-key workloads without application-level cache logic.
• Global Tables — Fully managed, active-active multi-Region replication for low-latency global access and multi-Region disaster recovery.
• On-Demand vs Provisioned capacity — On-Demand auto-scales instantly for unpredictable/spiky traffic (e.g., flash sales); Provisioned (with Auto Scaling) is cheaper for steady, predictable traffic.
• TTL (Time to Live) — Automatically expires and deletes items past a given timestamp, at no extra cost.
• Streams — Time-ordered change log of item-level modifications, consumable by Lambda for event-driven processing.

Read Consistency Models (exam-critical, frequently tested):

• Eventually Consistent Reads (the default) — Cheapest option (half the read-capacity cost of strongly consistent); may return stale data for a brief window (typically <1 second) after a write. Correct answer whenever a question doesn't require "the absolute latest data" — e.g., displaying a product catalog.
• Strongly Consistent Reads — Always returns the most up-to-date data, reflecting all writes that completed before the read began — at double the read-capacity cost, and slightly higher latency. Correct answer when a question says data must reflect the most recent write (e.g., reading your own just-placed order immediately after submitting it).

Project Examples:

• Managing session state for a mobile game with millions of concurrent users.
• Implementing a high-speed shopping cart for a retail application.

Amazon ElastiCache

Service Introduction: Engine: In-Memory. A fully managed, sub-millisecond latency caching service supporting Redis and Memcached.

Common Usage: Offloading read-heavy workloads from relational databases to improve application response times. Caching Strategies (exam-critical): See Caching Strategies for the full vendor-neutral breakdown (5 strategies, tradeoffs table, failure modes). The two ElastiCache-specific exam patterns:

• Lazy Loading (cache-aside) — App checks cache first; on a miss, reads from DB and writes the result into the cache. Cache only holds requested data (efficient), but data can go stale and there's a cache-miss penalty on first read.
• Write-Through — App writes to the cache at the same time it writes to the DB. Cache data is never stale and read latency is minimized, at the cost of writing (and paying for) data that may never be read. This is the correct answer when a question demands "cache is never stale" + "minimize read latency."

Don't confuse with DAX or TTL (both live under DynamoDB, not ElastiCache):

Strategy	Primary Benefit	Key Use Case
Lazy Loading	Efficient memory use	Unpredictable access patterns.
Write-Through	Data consistency	When the cache must never be stale.
DAX	Microsecond reads	High-velocity DynamoDB hot-keys — see the Amazon DynamoDB section above.
TTL	Automatic cleanup	Expiring sessions or old audit logs — see the Amazon DynamoDB section above.

Exam Example (SAA-C03 pattern): "An Amazon ElastiCache implementation requires that the cache data is never stale and that read latency is minimized, even if it increases the cost of write operations. Which caching strategy should be used?" Answer choices: Lazy Loading / DAX / TTL / Write-Through.

• Correct Answer: Write-Through — Updates the cache at the same time as the database, so data is never stale and reads stay fast; the trade-off is a "write penalty" and the cost of caching data that may never be read.
• Why not Lazy Loading? — Only updates the cache on a miss, which can leave stale data if the DB is updated without clearing the cache.
• Why not DAX? — A specific caching service for DynamoDB, not a general strategy used across ElastiCache engines.
• Why not TTL? — A mechanism to expire data, not a guarantee that the cache is never stale during its active period.

Project Examples:

• Implementing a real-time leaderboard for a gaming application.
• Caching frequently accessed SQL query results for a data-intensive dashboard.

Amazon Keyspaces

Service Introduction: Engine: Wide-Column (NoSQL). A scalable, highly available, and managed Apache Cassandra-compatible database service.

Common Usage: Running high-throughput Cassandra workloads without managing server clusters.

Project Examples:

• Storing massive volumes of time-series data from industrial IoT sensors.
• Migrating a legacy Cassandra-based recommendation engine to AWS.

Amazon Neptune

Service Introduction: Engine: Graph. A fast, reliable, fully managed graph database service built for highly connected datasets.

Common Usage: Navigating complex relationships like social graphs, fraud patterns, or knowledge graphs.

Project Examples:

• Building a real-time fraud detection system for financial transactions.
• Creating a "Suggested Friends" feature for a social media application.

Amazon RDS

Service Introduction: Engine: Relational. A managed service for six familiar database engines: Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server.

Common Usage: General-purpose relational workloads where automated backups, patching, and Multi-AZ failover are required. Multi-AZ vs. Read Replicas (exam-critical distinction):

• Multi-AZ — A synchronously replicated standby copy in another AZ, for high availability/failover only. It is not readable and doesn't help with read scaling.
• Read Replicas — Asynchronously replicated, independently readable copies (same or cross-Region), for read scaling, not failover (though a Read Replica can be manually promoted to standalone).

Encrypting an Existing Unencrypted Instance (exam-critical, heavily tested): RDS encryption cannot be toggled on for a live unencrypted instance. The only supported path is: snapshot → copy the snapshot with encryption enabled → restore a new instance from the encrypted snapshot → cut the application over → delete the old instance. This is a critical limitation that appears frequently on SAA-C03.

Why Other Approaches DON'T Work (exam-critical):

• You cannot enable encryption directly — RDS encryption must be configured during instance creation or restoration; toggling it on an existing unencrypted instance is not possible.
• You cannot create an encrypted Read Replica from an unencrypted primary — RDS does not support creating an encrypted replica from an unencrypted primary instance. The encryption status must match the source.
• AWS DMS is overkill for this use case — While DMS can migrate to a new encrypted instance, it's significantly more complex and operational overhead than the simple snapshot-restore method for a single database.

Exam Example (SAA-C03 pattern): "A solutions architect needs to apply encryption to an existing Amazon RDS MySQL database that was initially created without encryption. What is the most effective way to achieve this?"

• Correct Answer: Take a snapshot, copy the snapshot with encryption enabled, and restore a new instance from that snapshot.
• Why this is best: Simplest procedure, minimal operational overhead, preserves all data integrity, and is the standard AWS-recommended approach.
• Common wrong answers:
  • ❌ Direct toggle in console (impossible — encryption can't be enabled after creation)
  • ❌ Promote encrypted Read Replica (can't create encrypted replica from unencrypted primary)
  • ❌ Use AWS DMS (too complex for single database encryption)

Offloading BLOBs to S3 (exam-critical cost pattern): Storing large binary objects (images, PDFs, videos) directly in RDS as BLOB columns wastes expensive provisioned relational storage — every GB of BLOB data inflates the DB instance's storage size and its snapshot cost. The fix is to store the object in S3 and keep only the S3 key/URL as a small reference column in the relational table. The primary saving is that S3 storage is significantly cheaper per GB than provisioned RDS storage, not IOPS scaling, query cost, or any Aurora Serverless prerequisite.

Storage Auto Scaling ceiling (exam-critical): RDS Storage Auto Scaling only adds capacity in increments that fit within the configured maximum threshold. If the next required increment would push allocated storage past that maximum, the service does not partially scale, silently raise the ceiling, or exceed it — it simply does not trigger the scaling event. Hitting the ceiling requires manually raising the maximum threshold.

Project Examples:

• Hosting a Multi-AZ MySQL database for a production ERP system.
• Managing a fleet of SQL Server instances for a corporate HR application.
• Encrypting an existing unencrypted production database via snapshot-restore process.
• Moving product image BLOBs out of RDS into S3, storing only the S3 key in the database, to cut provisioned storage and snapshot costs.

Amazon Redshift

Service Introduction: Engine: OLAP (Relational Data Warehouse). A petabyte-scale data warehouse service using columnar storage.

Common Usage: Heavy analytical querying (OLAP) across structured and semi-structured data for BI reporting. Redshift Spectrum (exam-critical — the Redshift-vs-Athena distinguisher): Lets Redshift query data sitting directly in S3 (as external tables) without first loading it into the cluster's own storage — combining data already in a Redshift warehouse with vast unloaded S3 data lake data in a single SQL query. Compare with Athena (Analytics domain), which queries S3 directly with no cluster to manage at all — Spectrum is the answer when a question already has an existing Redshift cluster/warehouse and wants to extend its queries into S3 data; Athena is the answer when there's no data warehouse at all, just ad-hoc serverless querying of S3.

Project Examples:

• Consolidating enterprise data sources for unified quarterly financial reporting.
• Performing historical trend analysis on ten years of global logistics data.
• Joining structured warehouse data with a raw S3 data lake using Redshift Spectrum, without an ETL load step.

7.1 Choosing the Right Database (Exam-Critical Decision Framework)

The exam frequently poses a business scenario and expects you to pick the correct engine purely from the data shape and access pattern described — not from a service name. Use this as the first filter:

Data / Access Pattern	Correct Engine
Structured, relational, needs ACID transactions/joins	Amazon RDS (or Aurora for higher performance/availability)
Same as above but need MySQL/PostgreSQL compatibility at 5x throughput + fast failover	Amazon Aurora
Key-value / document access, millisecond latency at massive scale, flexible schema	Amazon DynamoDB
MongoDB-compatible document workloads (existing MongoDB app/skillset)	Amazon DocumentDB
Cassandra-compatible wide-column workloads (existing Cassandra app/skillset)	Amazon Keyspaces
Highly connected data — relationships/traversals matter more than the records themselves (social graphs, fraud rings, recommendation engines)	Amazon Neptune
Petabyte-scale analytical (OLAP) reporting/BI across structured data	Amazon Redshift
In-memory sub-millisecond caching layer in front of another database	Amazon ElastiCache

The tell to watch for: if the scenario mentions "relationships between entities" or "connections" as the primary query need (not just related tables), that's Neptune, not RDS — a heavily-tested trap since a graph problem modeled in a relational DB works but performs and scales far worse for deep traversal queries.

Exam Example (SAA-C03 pattern): "A social media company wants to build a 'people you may know' feature that traverses multiple layers of mutual connections between users in real time. Which database is best suited for this requirement?" Answer choices: Amazon RDS / Amazon DynamoDB / Amazon Neptune / Amazon Redshift.

• Correct Answer: Amazon Neptune — Purpose-built graph database; multi-hop relationship traversals (friend-of-a-friend queries) are its core strength and are inefficient as recursive joins in a relational engine.
• Why not RDS? — Would require expensive recursive joins across a relationship table that gets slower as connection depth grows — the wrong tool for graph traversal at scale.
• Why not DynamoDB? — Excellent for key-value lookups by a known key, but has no native concept of graph traversal across arbitrary relationship depths.
• Why not Redshift? — Built for analytical aggregation over structured data (BI reporting), not real-time relationship traversal.