Cross-Service Decision Framework

In the previous lesson, you explored the foundational building blocks that support production database architectures, including networking, security, monitoring, and disaster recovery. Those capabilities are essential, but they only deliver value after you have selected the right database service for the workload. Choosing the wrong engine creates problems that no amount of infrastructure hardening can fix. Performance bottlenecks emerge, costs spiral, and operational teams spend their energy working around limitations instead of delivering features.

AWS offers multiple purpose-built database engines, and each one is optimized for a specific data shape and access behavior. The challenge is not learning what each service does in isolation. The challenge is comparing them against each other for a given workload and making a defensible architecture decision. This lesson provides a repeatable decision framework organized around four pillars that drive every database selection: data model and access patterns, scalability behavior, operational burden, and total cost. The services in scope include Amazon RDS and Aurora for relational workloads requiring SQL, joins, and ACID transactions; DynamoDB for high-scale key-value and document access with single-digit-millisecond latency; DocumentDB for MongoDB-compatible document workloads; Neptune for graph traversals and relationship queries; and ElastiCache for caching layers rather than primary persistence.

Attention: The most common architectural mistake is choosing a database based on team familiarity or industry popularity rather than matching the engine to the workload's data model and access patterns. This lesson gives you the tools to avoid that trap.

The framework you build here applies equally to real-world architecture reviews and exam scenarios, where the correct answer almost always maps to the service whose strengths align with the stated workload characteristics.

Data model and access pattern analysis

The first and most decisive filter in any database selection is whether the workload's data model and access patterns align with the engine's core strengths. Getting this wrong at the start creates friction that scaling, caching, and cost optimization cannot resolve.

Relational vs. access-pattern-driven design

Relational data models use normalized schemas with foreign keys, enforce referential integrity, support complex joins across multiple tables, and guarantee ACID transactions. When a workload requires these capabilities, Amazon RDS or Aurora is a natural fit. A financial application that must join customer, account, and transaction tables while enforcing strict consistency is a textbook relational use case. Aurora extends this with higher availability and faster replication across up to 15 read replicas.

In contrast, access-pattern-driven designA data modeling approach where the schema is shaped around known query patterns rather than normalized relationships, typically using denormalized structures optimized for specific read and write operations. fits DynamoDB. Here, ...