RDS, Aurora, or DynamoDB? Start With the Workload

AWS makes it easy to create a database and surprisingly easy to choose the wrong database for the workload. Amazon RDS, Amazon Aurora, and Amazon DynamoDB can all store application data reliably, but they optimize for different data models, access patterns, scaling behaviors, operational requirements, and failure modes. The decision should begin with how the application uses data, not with which service has the most attractive feature list.

The first split is relational versus key-value/document-oriented access. If the application depends on joins, flexible SQL queries, relational constraints, and established database engines, RDS or Aurora is usually the natural family to evaluate. If the application can model its needs around known key access patterns and requires very high, predictable scale with minimal database administration, DynamoDB may fit better. That requirement-first reasoning is core to SAA-C03.

The useful question is not “Which AWS database is best?” It is “What must this workload guarantee, query, scale, recover, and operate?” Once those requirements are explicit, the trade-offs become much more concrete.

Start with the data model and query model

Relational databases shine when the structure and relationships between entities matter. SQL lets applications join tables, filter across multiple attributes, aggregate data, enforce constraints, and support ad hoc queries that were not all predicted when the schema was created. That flexibility is valuable for transactional systems with rich relationships and for teams with deep relational tooling and skills.

DynamoDB asks for a different mindset. You design keys and indexes around the access patterns the application must serve. A good table can support enormous scale with low operational overhead, but a poor key design can create hot partitions or force expensive scans. The application should know how it will retrieve and update data before the table design is considered finished.

Neither model is more modern by definition. A workload that needs relational integrity should not be forced into key-value access to appear cloud-native, and a simple high-scale key lookup service should not inherit a relational database just because the team already knows SQL.

RDS is a managed home for familiar relational engines

Amazon RDS manages common operational tasks around relational engines such as backups, patching, monitoring, and high-availability options. It is attractive when compatibility with a specific engine matters, when an application depends on engine features or vendor tooling, or when migration risk is lower if the database behaves much like the existing platform.

The architectural work still includes instance sizing, storage, read scaling, Multi-AZ configuration, backup retention, maintenance, connection management, and engine-specific limits. Managed does not mean limitless. A poorly indexed query or connection storm can still become the bottleneck.

RDS is often the pragmatic choice for workloads whose relational requirements are clear and whose scaling needs fit the selected engine. The cloud benefit comes from reducing undifferentiated database operations without forcing the application into a new data model.

Aurora changes the relational operating model

Aurora is MySQL- and PostgreSQL-compatible but uses an AWS-designed distributed storage architecture and a cluster model that separates the writer role from additional readers. That can improve availability, read scaling, and recovery characteristics for workloads that fit Aurora’s supported engines and operational model.

The question should still be workload-specific. Aurora can be compelling when a relational system needs more read capacity, faster failover characteristics, global read options, or managed scaling features. But compatibility is not identical to running the community engine in every detail, and teams should test extensions, parameter behavior, migration tooling, and application assumptions.

For architects progressing toward SAP-C02, this kind of distinction matters because database choice affects organizational migration strategy, resilience, performance, operational complexity, and cost at the same time.

DynamoDB rewards explicit access patterns

DynamoDB distributes data by partition key. Good key design spreads activity across partitions and lets the service scale while maintaining predictable performance. That is why access-pattern discovery comes first: identify the entity lookups, range queries, updates, conditional writes, and alternate lookup paths the application actually needs.

Secondary indexes can add query paths, but each index has storage and write implications. Strongly consistent versus eventually consistent reads, transaction APIs, item size, hot keys, and throughput mode also belong in the design. The table should be shaped around workload behavior rather than copied from a relational schema one table at a time.

DynamoDB is especially strong for use cases such as session state, carts, metadata, high-scale APIs, and event-driven applications when the key relationships are known. It is less attractive when users need arbitrary relational queries that change frequently.

Scaling behavior should match demand shape

Database scale has several dimensions: storage growth, read throughput, write throughput, concurrent connections, query complexity, and geographic distribution. A workload with mostly reads can often scale differently from a write-heavy transactional system. A bursty serverless API has different connection behavior from a stable application server fleet.

RDS and Aurora typically require more deliberate thinking about instance or cluster capacity, connections, replicas, and query efficiency. DynamoDB offers on-demand and provisioned throughput models and scales without database servers, but the application still must respect key distribution, item design, and service quotas.

Architecture should also ask whether caching can remove load more cheaply than scaling the database itself. ElastiCache, application caches, CloudFront for appropriate content, and request coalescing can change the database requirement more dramatically than choosing a larger instance.

Availability is not the same as recovery

Multi-AZ database configurations improve availability during infrastructure failure, but backups and point-in-time recovery still matter for logical corruption, operator mistakes, bad deployments, or malicious changes. A highly available database can faithfully preserve the wrong data if the application writes it.

Define RTO and RPO separately from availability. Determine how failover works, how applications reconnect, how long replicas can lag, how backups are retained, and how restoration is tested. If a multi-Region requirement exists, evaluate the database’s replication model and the application’s ability to operate with regional data behavior.

The AWS Certified Solutions Architect – Associate perspective is useful because resilience decisions should cover both infrastructure failure and data recovery rather than stopping at a “Multi-AZ” checkbox.

Cost follows the architecture, not just the hourly price

Comparing database cost by instance price or request price alone misses important drivers. RDS and Aurora costs can include instances, storage, I/O or storage behavior depending on the configuration, backups, replicas, and data transfer. DynamoDB cost depends on capacity mode, requests, storage, indexes, backups, streams, and related features.

Operational cost matters as well. A service that reduces patching, failover management, or scaling work can be economically attractive even if its direct infrastructure line item is higher. Conversely, moving a stable relational workload to a new data model can create application-development complexity that outweighs infrastructure savings.

Good cost decisions therefore compare the whole workload: expected traffic, growth, engineering effort, availability requirement, recovery model, and the price of future change.

Migration risk deserves equal weight with steady-state performance

A database decision is often made during modernization rather than greenfield design. In that case, schema conversion, stored procedures, extensions, driver behavior, transaction semantics, operational tooling, and cutover strategy can matter more than an attractive benchmark. A theoretically superior target can become a poor business choice if moving to it requires rewriting the application and operating two data models for months.

RDS can reduce migration friction when staying close to a familiar engine is valuable. Aurora can preserve MySQL or PostgreSQL compatibility while changing the managed architecture, but compatibility still needs testing. DynamoDB usually requires the largest modeling shift because tables are designed around application access patterns rather than normalized relational structures.

Architects should compare the cost of change with the expected long-term benefit. A migration that materially improves scale, availability, or operations may justify redesign. A migration done only because a service is fashionable can add risk without changing the workload’s real constraints.

Connection behavior can decide the architecture

Relational databases are often constrained by connections before they are constrained by raw storage. Traditional application servers keep pools of reusable connections, while bursty serverless workloads can create many short-lived execution environments that all try to connect at once. The database may have enough CPU for the transactions but still struggle with connection establishment, memory pressure, or sudden concurrency.

Architects should model connection count, transaction duration, pooling behavior, and failover reconnects. RDS Proxy can help appropriate RDS and Aurora workloads by pooling and managing application connections, but it does not remove the database’s underlying transaction and compute limits. The safer design still controls concurrency and keeps transactions short.

DynamoDB avoids the relational connection model entirely because applications call a managed API, which can be a strong advantage for highly elastic request patterns. The trade-off is that the data model must already fit DynamoDB’s access-pattern approach. Connection simplicity should not be used to justify a key-value model that makes the application’s queries awkward or fragile.

Choose the database by invariants and change patterns

Write down what must always be true. Which transactions must be atomic? Which relationships must be enforced? Which queries are latency-sensitive? Which access patterns are known in advance? How rapidly will query needs change? What is the expected write concentration? What is the recovery requirement? How much database administration can the team own?

PrepAway’s SAA-C03 architecture coverage is most useful when these services are learned through those constraints rather than as isolated feature tables.

RDS is often right when engine compatibility and relational behavior dominate. Aurora fits relational workloads that benefit from its AWS-native cluster architecture and scaling characteristics. DynamoDB fits workloads designed around explicit key access patterns and elastic service behavior. Start with the workload, and the service choice becomes a consequence rather than a guess.