Design Cost-Optimized Architectures
Cost-Optimized Databases and Retention
CoreOptimize engine/type, capacity, caching, proxying, retention, backup, and migration choices.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Database cost follows the data model and access pattern. Choose the smallest managed architecture that satisfies transactions, consistency, performance, availability, and recovery; then optimize capacity, connections, caches, replicas, retention, and migration without turning a cheaper but incompatible database into the answer.
Must Know
- Choose relational, key-value/document, graph, wide-column, in-memory, or warehouse from the data model and access patterns before comparing price.
- RDS/Aurora fit relational workloads; DynamoDB fits key-oriented serverless scale; Redshift fits analytical warehousing. Purpose-built fit can remove expensive workarounds.
- Provisioned relational capacity fits steady demand; Aurora Serverless can scale Aurora capacity for variable/intermittent relational workloads when its supported behavior meets latency and engine requirements.
- DynamoDB on-demand fits uncertain/spiky traffic; provisioned capacity with scaling can fit predictable sustained demand. Partition design matters in either mode.
- Read replicas add read capacity but also cost; add them for measured distributable reads. ElastiCache can offload repeatable hot reads; RDS Proxy addresses connection pressure.
- Backups, snapshots, point-in-time recovery, replicas, and retention solve different needs. Set policy from RPO, compliance, and recovery value, then expire redundant copies.
- DMS supports ongoing replication and low-downtime data movement. Heterogeneous migration adds schema/application conversion and testing; choose it only when long-term benefit exceeds migration work.
- Use cost allocation, Cost Explorer, Budgets, and CUR to find ownership and trends; avoid letting cost tooling substitute for workload metrics.
Compare and Distinguish
- RDS/Aurora vs DynamoDB: relational transactions/joins versus key access and serverless horizontal scaling.
- Time-series vs relational cost: high-volume time-ordered measurements with time-window queries and retention/downsampling can be more cost-effective in a purpose-built time-series database than in an ill-fitting relational design.
- Provisioned Aurora/RDS vs Aurora Serverless: stable capacity/control versus variable relational capacity with lower idle provisioning when supported behavior fits.
- DynamoDB on-demand vs provisioned: uncertain demand and simplicity versus predictable utilization and planned capacity economics.
- Read replica vs ElastiCache vs RDS Proxy: database read capacity, reusable in-memory data, or connection pooling.
- RDS/Aurora vs Redshift: transactional relational processing versus analytical warehousing.
- Homogeneous vs heterogeneous migration: data-location move versus engine change with schema/code compatibility work.
Scenario examples
- Scenario: An intermittent internal relational application is idle for long periods and tolerates compatible scale behavior. Think: evaluate Aurora Serverless against provisioned capacity.
- Scenario: A predictable DynamoDB workload has stable partitioned demand. Think: provisioned capacity with scaling may be cost-effective after measurement.
- Scenario: Repeated product reads dominate database load and short staleness is acceptable. Think: cache hot data before buying more database capacity.
- Scenario: Thousands of short Lambda connections overwhelm an otherwise healthy RDS database. Think: use RDS Proxy rather than scaling CPU for a connection problem.
- Scenario: A transactional database powers large historical aggregates. Think: move analytical work to a suitable warehouse rather than oversizing OLTP.
Exam traps
- Cheaper capacity mode does not fix a poor partition key or inefficient query.
- Aurora Serverless is not the answer for every relational workload; scaling behavior and compatibility still matter.
- A read replica does not reduce writer-heavy demand.
- RDS Proxy does not cache results; ElastiCache does not pool database connections.
- Short backup retention can violate recovery or compliance; infinite retention can create waste.
- DMS does not make a heterogeneous migration automatic.
Key takeaways
- Choose database family from access pattern before price.
- Match capacity mode to demand predictability.
- Use cache, proxy, and replica for their exact bottlenecks.
- Retain recovery points according to data value and tested recovery.
- Count migration complexity in total cost.
How it works
- Relational capacity serves writers/readers according to topology; replicas and caches redirect eligible reads.
- DynamoDB meters demand according to selected capacity behavior and distributes work from partition keys.
- RDS Proxy multiplexes client connections; ElastiCache returns in-memory entries on cache hits.
- DMS reads source changes and applies them to a target according to task and engine capabilities.
When to use it
- Use provisioned relational capacity for steady demand and Aurora Serverless for supported variable/intermittent relational demand.
- Use DynamoDB on-demand for uncertain demand and provisioned for predictable demand when planning overhead is justified.
- Use ElastiCache for hot reads, RDS Proxy for connections, and read replicas for database reads.
- Use DMS for low-downtime data movement and plan schema conversion/testing for engine changes.
Security and governance implications
- Encrypt databases, backups, caches, and migration paths and scope access by role/network.
- Protect backup deletion and destination keys.
- Do not expose production data through cheaper unmanaged analytical copies.
- Include license/compliance and separation-of-duties requirements in engine decisions.
Operational and diagnostic signals
- For high cost, separate idle capacity, read/write mix, I/O, backups, replicas, cache miss, and transfer.
- For scaling issues, inspect hot partitions, connection limits, replica lag, or writer saturation according to service.
- For migration overruns, separate data transfer from schema and application remediation.
- For recovery-policy waste, compare actual restore needs with retained copies before deleting.
More detail
- Database cost includes compute/capacity, storage, I/O or requests, replicas, backups, transfer, cache/proxy layers, licenses where relevant, and administration.
- Cost-effective retention is a recovery decision: identify required restore points and legal retention before deleting.
- Rightsizing must preserve performance headroom and failover behavior, not just average use.
- A purpose-built database can lower operations and scale cost only when the application can use its model correctly.
Ready for the quiz?
- When does DynamoDB beat RDS economically and architecturally?
- Which demand pattern favors Aurora Serverless?
- How do read replicas, cache, and Proxy differ?
- Why can Redshift reduce OLTP cost?
- What costs appear in heterogeneous migration?
Related objectives
- D4.3.K1
- D4.3.K2
- D4.3.K3
- D4.3.K4
- D4.3.K5
- D4.3.K6
- D4.3.K7
- D4.3.K8
- D4.3.K9
- D4.3.S1
- D4.3.S2
- D4.3.S3
- D4.3.S4
- D4.3.S5