Skip to content
FR

Design Cost-Optimized Database Solutions

Step 25 of 28

AWS Database Cost Optimization: RDS, Aurora and DynamoDB

Where this lesson fits

This lesson covers Domain 4: Design Cost-Optimized Architectures, Task 4.3: Design cost-optimized database solutions. Domain 4 carries 20% of the scored content of SAA-C03. AWS database cost optimization starts with matching the service and billing model to demand. Exam scenarios give you a data model, an access pattern (steady, spiky, rarely used, read-heavy), a retention requirement, and a statement such as "minimize cost" or "reduce operational overhead". You then choose the database service, the capacity model, the purchasing option, the caching layer, and the backup and retention settings that cost least while still meeting the requirement.

Review database engines, replicas, caches and RDS Proxy to establish the required performance and access model first. Here we look at the same services through the price list.

Learning objectives

After this lesson you will be able to:

  • Select between Amazon RDS, Amazon Aurora (provisioned and Serverless v2), Amazon DynamoDB, and other managed engines on cost grounds.
  • Choose DynamoDB on-demand versus provisioned capacity (with auto scaling) and the Standard versus Standard-IA table class.
  • Use Reserved Instances for RDS and Aurora, and understand what Savings Plans do and do not cover for databases.
  • Reduce cost with caching (ElastiCache, DAX), read replicas, and RDS Proxy.
  • Control backup, snapshot, and retention costs, including DynamoDB TTL and Point-in-time recovery.
  • Design cost-aware development, test, and migration paths (stop/start, Aurora clones, AWS DMS and Schema Conversion Tool).
  • Recognize when a different engine (open source instead of commercial, NoSQL instead of relational) is the cost answer.

1. Where database cost comes from

Cost component RDS / Aurora DynamoDB
Compute DB instance hours (or ACUs on Serverless v2) Read/write capacity units or request units
Storage GB-month (RDS: provisioned; Aurora: grows automatically) GB-month of table and index data
I/O Aurora Standard bills per I/O request; Aurora I/O-Optimized does not; RDS Provisioned IOPS storage bills IOPS Included in capacity
Backup Backup storage allocation depends on service and account/Region usage; excess backups and snapshots are billed PITR and on-demand backups per GB-month
Data transfer Cross-AZ for Multi-AZ replication is included for RDS; cross-Region and internet egress are charged Global tables replicate with charges per replicated write
Licensing Engine-specific License Included or supported BYOL options; do not assume every commercial edition supports both None

The consequence: the biggest cost levers are (1) which engine and licensing model, (2) how compute capacity is provisioned and discounted, (3) how much work you offload to a cache or replica, and (4) how long you keep data and backups.

2. Choosing the service on cost grounds

Workload Cost-effective choice Reasoning
Key-value or document access with massive scale or unpredictable load DynamoDB on-demand No instances to size; pay per request
Predictable, steady key-value traffic DynamoDB provisioned with auto scaling, plus eligible Standard-class reserved capacity Lower unit price than on-demand when utilization is steady
Relational, steady load, moderate size RDS (MySQL, PostgreSQL, MariaDB) with Reserved Instances Open-source engines have no licence fee
Relational, high throughput and many read replicas, large storage Aurora (I/O-Optimized if I/O is a large share of the bill) Shared storage, up to 15 replicas, storage autogrows
Relational, spiky, unpredictable, or infrequent use Aurora Serverless v2 Capacity scales in fine-grained ACUs; it can scale down to a minimum (and, in current versions, to zero ACUs with auto-pause)
Commercial engine only because it was already used Consider migrating to Aurora PostgreSQL or MySQL using DMS and Schema Conversion Removes per-core licence cost
Data warehouse, analytic queries Redshift (Serverless for spiky, provisioned plus RIs for steady) See Chapter 10 for data lake alternatives
Time-series, graph, durable in-memory Purpose-built engines ( Timestream for InfluxDB, Neptune, MemoryDB) Verify workload fit and availability; Timestream for LiveAnalytics closed to new customers in June 2025, and QLDB ended support in July 2025

Exam tip. "Relational and the lowest cost" with no feature requirement favors an open-source engine on RDS or Aurora. "Spiky or unpredictable relational workload" favors Aurora Serverless v2. "Minimal operations, key-value, unpredictable traffic" favors DynamoDB on-demand.

3. RDS and Aurora capacity and purchasing

3.1 Instance sizing and family

  • Match instance class to measured CPU, memory, and connection count ( CloudWatch Database Insights, instance metrics and appropriate memory/connection monitoring provide evidence). A database with 15% average CPU on a db.r6g.4xlarge is a right-sizing candidate.
  • Graviton-based classes (db.r6g, db.r7g, db.t4g) can improve price-performance on supported engines; verify engine/version availability and benchmark the actual workload.
  • Burstable db.t classes are cost-effective for dev/test and low-duty-cycle workloads, but sustained high CPU can consume credits and incur surplus-credit charges on applicable unlimited-mode classes. Include credit metrics and pricing in the comparison.
  • Multi-AZ costs depend on the deployment: a DB instance with one non-readable standby differs from a DB cluster with a writer and two readable instances. Use Single-AZ for dev/test only when recovery, availability and failover-testing needs permit it.

3.2 Reserved Instances ( RDS and Aurora)

RDS and Aurora Reserved Instances discount eligible instance usage for one or three years, with engine, family, Region, deployment and size-flexibility constraints. Check commercial license-included restrictions before resizing. EC2/Compute Savings Plans do not cover RDS, but Database Savings Plans are a distinct option: a one-year hourly spending commitment, no upfront payment, across supported managed database usage. Eligibility varies by service, engine and instance generation; storage and all other bill components are not automatically discounted. Compare actual eligible usage, flexibility and total cost rather than assuming the exam favors one purchasing model.

For a steady baseline and matching commitment horizon, compare RIs and eligible Database Savings Plans. For spiky or short-lived usage, compare On-Demand and Serverless first; a predictable baseline may still justify a partial commitment. See Savings Plans, purchasing commitments and rightsizing.

3.3 Aurora storage and I/O pricing

Aurora has two cluster configurations:

Configuration I/O charged separately? Storage price Best when
Aurora Standard Yes, per million I/O requests Lower Low to moderate I/O
Aurora I/O-Optimized No I/O charges Higher per GB, higher instance price I/O costs exceed about 25% of the total Aurora bill

Aurora storage grows automatically (you pay for what is used, with limits depending on engine/version, such as 256 TiB on supported recent engines and 128 TiB on older versions) and does not shrink at the instance level, but billed storage decreases when data is removed and space is reclaimed. This removes the need for over-provisioned storage that RDS requires.

3.4 Aurora Serverless v2

Aurora Serverless v2 scales capacity continuously in Aurora Capacity Units (ACU) within a minimum and maximum you set (one ACU is about 2 GiB of memory plus matching CPU and networking). You pay per ACU-second. It fits:

  • Spiky traffic that would otherwise force a large provisioned instance.
  • Variable multi-tenant workloads.
  • Dev/test and low-use systems, with the minimum set low (or with auto-pause where supported) to cut idle compute cost. Auto-pause requires a supported engine/version and minimum zero; open connections or RDS Proxy can prevent pausing. Storage and backup charges continue, and applications must tolerate resume latency.

For a steady database that sits near its peak all day, a provisioned instance with a Reserved Instance is usually cheaper than Serverless v2, because the serverless unit price is higher. Think "serverless saves money when utilization is low or varies, not when utilization is constant".

3.5 Worked example: choosing capacity model

Scenario. A company runs a reporting application on Aurora MySQL. Production traffic is heavy from 09:00 to 17:00 (peak around 40 ACU-equivalents of load) and almost nothing for the remaining 16 hours (about 4 ACUs). The current setup is one provisioned db.r6g.4xlarge writer (16 vCPU, 128 GiB) running 24/7 on demand. The architects want to reduce cost without affecting reporting during business hours.

Step 1: look at utilization. The provisioned writer is sized for the 8-hour peak and idles at less than 10% CPU the rest of the day. Idle time is two thirds of the day.

Step 2: candidate designs.

  • (a) Buy a 3-year Reserved Instance for the db.r6g.4xlarge. The discount applies to all 24 hours, including the idle ones. Savings per hour are real, but the instance is still oversized for two thirds of the time.
  • (b) Aurora Serverless v2 with a minimum of 2 ACU and a maximum of 64 ACU. Capacity follows demand within those bounds; the stated 4-ACU off-peak workload still needs about 4 ACUs, not the configured minimum of 2.
  • (c) Keep provisioned, but stop and start the writer on a schedule. Aurora clusters can be stopped for up to 7 days, but stopping a production reporting database on a schedule requires automation and may fail the availability expectation.

Step 3: estimate (illustrative prices, compute only). At $2.00/hour, provisioned On-Demand costs 24 × $2 = $48/day. At $0.12/ACU-hour, serverless costs (40 × 8 + 4 × 16) × $0.12 = $46.08/day. Lowering the minimum to 2 does not change the 4-ACU workload. The $42.24/day result would require the off-peak workload itself to consume only 2 ACUs. If an eligible provisioned reservation reduced the hourly compute price by 30%, its equivalent cost would be $33.60/day, before other charges and commitment risk. These illustrative rates prove that variability alone does not establish the cheapest option.

Step 4: decide. With those illustrative rates and a stable long-term workload, the discounted provisioned option is cheaper in compute cost; choose it only after validating commitment duration, capacity and total bill. Serverless offers elasticity and can win with a lower actual off-peak load, shorter peak or eligible discounts. Compare Database Savings Plans where eligible and avoid double-counting overlapping discounts.

Why not reject (a) automatically? Its lower price can outweigh paid idle capacity, as the numbers show. Why not (c)? Scheduled stops do not satisfy availability on demand. The decision follows measured demand, actual prices and the commitment horizon, not a blanket "variable means serverless is cheapest" rule.

4. DynamoDB cost design

4.1 Capacity modes

Mode Billing Choose when
On-demand Pay per read/write request unit New or unpredictable workloads, spiky traffic, many idle tables
Provisioned Pay for RCU and WCU per hour you provision (with auto scaling adjusting capacity to a target utilization) Predictable or gradually changing traffic where steady utilization is high
Provisioned with reserved capacity 1-year, or supported-Region 3-year commitment of eligible Standard-class baseline RCU/WCU Stable baseline of provisioned capacity

Capacity units: one read capacity unit reads one item up to 4 KB per second with strong consistency (eventually consistent reads use half); one write capacity unit writes one item up to 1 KB per second. Rounding up per item size matters: reading a 9 KB item with strong consistency consumes 3 RCUs.

Break-even thinking. On-demand costs a premium per request versus fully utilized provisioned capacity. If traffic is steady and high, provisioned with auto scaling is cheaper; if traffic is spiky or unknown, on-demand avoids provisioned idle-capacity charges but still has throughput, partition and warm-throughput constraints. You can switch modes (with a limit on how often).

4.2 Table class

Table class Storage price Request price Choose when
Standard Higher Lower Throughput is the dominant cost
Standard-IA (Infrequent Access) About 60% lower About 25% higher Storage is the dominant cost (large tables rarely read, such as audit history)

AWS recommends evaluating Standard-IA when storage is a large share of the overall table bill, commonly around 50% or more. Calculate the actual break-even: with 60% lower storage and 25% higher throughput rates, the simplified saving is 0.60 × storage cost − 0.25 × throughput cost. Include discounts and other charges. Standard-IA does not support DynamoDB reserved capacity.

4.3 Other DynamoDB cost controls

  • TTL (Time to Live) removes expired items asynchronously, typically within a few days. The initial deletion consumes no write capacity, but replicated TTL deletes in current global tables are billed. Set a numeric Unix-epoch expiry in seconds and filter expired records from reads while awaiting deletion; TTL is not exact-time erasure.
  • Projection and index design: each global secondary index replicates data and consumes write capacity. Project only necessary attributes and create only needed indexes.
  • Item size: large items cost more RCU/WCU; store big blobs in S3 and keep a pointer in DynamoDB.
  • Eventually consistent reads cost half the RCU of strongly consistent reads when the application can tolerate them.
  • DAX (DynamoDB Accelerator) caches reads in microseconds. For read-heavy tables with repeated reads of hot items it reduces consumed RCUs and may allow lower provisioned throughput.
  • Backups: PITR and on-demand backups bill per GB-month; use AWS Backup with retention rules and avoid unneeded long-lived backups. PITR permits a 1–35-day recovery window, but shortening it does not lower its size-based price. Compare archival export, storage, query, restore and application-change costs before moving old data to S3.
  • Global tables multiply write cost by the number of Regions; justify replica cost with explicit multi-Region availability, latency or recovery requirements.

4.4 Worked example: DynamoDB mode and class

Scenario. A game studio stores player profiles in DynamoDB. The table has 8 TB of data, of which 95% belongs to players inactive for over a year, and traffic is a steady 1,000 reads and 200 writes per second from active players. Storage costs are 70% of the table's bill. The team wants to reduce cost with no application change.

Step 1: identify the dominant cost. Storage is 70% of the total, and the throughput is steady.

Step 2: apply levers. (1) Switch the table class to Standard-IA, which cuts per-GB storage price by roughly 60% at the price of slightly higher request cost. (2) Because traffic is steady, use provisioned capacity with auto scaling without assuming the Standard-class reserved-capacity discount carries into Standard-IA. (3) Add TTL only if the business permits expiration and writers already populate an appropriate expiry attribute. Otherwise TTL requires an application or backfill change, which this scenario forbids.

Step 3: compare. If storage is $2,800 and throughput is $1,200 per month, Standard-IA would reduce storage to about $1,120 and raise throughput to about $1,500, for a total of $2,620 versus $4,000, a saving of about 35%. Staying on Standard keeps the old total.

Why compare provisioned? Stable traffic can favor provisioned capacity, but include auto-scaling headroom and the chosen table class. The $2,620 example isolates the class change; do not count a second capacity-mode saving without another calculation. Why not move inactive players to S3? That is a valid architecture, but it requires application changes, which the stem forbids.

5. Offload work: caching, replicas, and proxies

Cost can be cut by avoiding database work.

Technique Effect on cost
Amazon ElastiCache (Redis/Valkey, Memcached) Absorbs repeated reads, so a smaller database instance suffices; ElastiCache also offers Reserved Nodes and Serverless
DAX Same for DynamoDB read-heavy hot keys
Read replicas Move reporting reads off the writer so the writer can be smaller; a replica is billed like an instance, so use only when it avoids upsizing
RDS Proxy Pools connections so Lambda or many clients do not force a larger instance just for connection count
Query tuning and indexes Database Insights and slow query logs can reveal that an instance upsizing could be avoided
Aurora Global Database / cross-Region replicas Increase cost; justify with explicit disaster recovery or latency requirements

A cache is not free: ElastiCache nodes are billed hourly, and cache invalidation adds complexity. The exam pattern is "read-heavy, repeatedly requested data, database CPU is high, lowest cost" → cache or read replica rather than a bigger instance.

6. Backup, retention, and lifecycle

  • RDS backup storage has a free allocation tied to total provisioned DB instance storage for the account and Region; automated backups and manual snapshots share it. Excess storage is billed. Retention for DB instances can be 0–35 days (0 disables automated backups); DB clusters require at least 1 day. Keep the recovery window the workload needs, and account for retained backups after deletion.
  • Manual snapshots persist until deleted. Configure retention for new AWS Backup recovery points, and inventory existing manual snapshots separately; a new backup plan does not retroactively expire every unmanaged snapshot. Delete only those outside recovery and retention requirements.
  • Aurora backups also bill for storage beyond the free allocation; backtrack (Aurora MySQL) and cloning differ: clones share storage until data diverges, so a clone for testing is cheap.
  • Stop RDS instances that are not in use. A stopped RDS instance is not billed for instance hours (but is billed for storage and backup), and AWS restarts it automatically after 7 days.
  • Export old data to S3 (for example RDS snapshot export to Parquet, or DynamoDB export to S3) and query with Athena instead of keeping rarely used data in a database.
  • Cross-Region copies of snapshots add storage and transfer cost; keep them only for DR requirements.
  • Delete protection and final snapshots protect against accidents; avoid relying on endless manual snapshots as a backup strategy.

7. Migration paths that save money

Situation Cost-effective path
On-premises Oracle or SQL Server with high per-core licence cost AWS DMS plus Schema Conversion to Aurora PostgreSQL or Aurora MySQL (a heterogeneous migration)
Same-engine migration (MySQL to RDS MySQL) DMS (homogeneous), or native dump/replication, with minimal downtime
Self-managed database on EC2 Move to RDS or Aurora to eliminate administration cost and use managed backups
Need to keep the licence and run on RDS License Included versus Bring Your Own License (BYOL); BYOL is cheaper when the company already owns portable licences, with RDS for Oracle (BYOL) and RDS Custom where needed
Large database, little bandwidth Compare a DMS full load plus CDC over upgraded connectivity with a supported offline seed workflow; Snowball is restricted to existing customers, and any seed must have a consistent CDC starting point

Moving from a commercial engine to an open-source engine is often the single largest saving, but it only qualifies when the stem accepts application or schema changes.

8. Common pitfalls and exam tips

  • Match dev/test resilience to its purpose. Single-AZ can save cost when outages are acceptable; failover or production-parity testing may require Multi-AZ.
  • Compare on-demand and provisioned DynamoDB for steady, high-volume traffic. Provisioned can be cheaper at sustained utilization; include utilization, scaling headroom, operations and eligible commitments.
  • Match Reserved Instances to a stable baseline and commitment horizon. A variable workload may still have a reservable baseline; check engine, family, Region and eligible deployment.
  • Serverless is a variability solution. For constant 24/7 load, compare provisioned plus commitment with serverless using actual eligible prices; neither is universally cheaper.
  • Aurora I/O-Optimized wins when I/O is a large part of the bill; Standard wins otherwise.
  • Storage matters for DynamoDB IA. If throughput dominates, stay on Standard.
  • Read replicas and caches cost money too. Use them when they allow a smaller or fewer primary instances, not by default.
  • Old snapshots and stopped-but-forgotten databases keep costing money.
  • Exam tip: "Lowest cost, no code changes" rules out options that rewrite the application (such as migrating to DynamoDB). "Lowest operational overhead" may favor serverless or managed options even when a self-managed approach is slightly cheaper.

9. Mini case study (with solution)

Scenario. RetailPulse runs: (1) an order system on RDS for SQL Server Enterprise (license included) on a db.r5.4xlarge Multi-AZ, steady 24/7, that must remain on SQL Server for the next two years because of vendor software; (2) a customer-session store in a self-managed Redis cluster on EC2; (3) a product-catalog service on a Multi-AZ Aurora MySQL cluster with I/O charges equal to 40% of the Aurora bill; (4) a staging environment with Multi-AZ RDS instances running continuously, used by testers on weekdays only; and (5) a DynamoDB audit-log table with 15 TB of data that is queried a few times a month, using on-demand capacity with TTL disabled, with a 3-year retention policy.

Solution.

  1. Order system: retain SQL Server while the vendor requires it and right-size first. Compare two successive one-year RIs, eligible one-year Database Savings Plans and a three-year RI over the full commitment, including the third year after the two-year need. For illustration, if annual On-Demand cost is $100,000, two one-year commitments at 30% off total $140,000, while three years at 50% off total $150,000. The third-year discount does not justify unused spend; different actual quotes can reverse the choice. Verify SQL Server license-included and generation eligibility before committing.
  2. Session store: compare managed ElastiCache with the full self-managed cost, including node/serverless charges and operations. MemoryDB is an alternative when durable database semantics are required. Managed service does not mean free compute; consider eligible reserved-node or database commitments for a stable footprint.
  3. Catalog Aurora: switch the cluster to Aurora I/O-Optimized, since I/O charges exceed 25% of the bill, which removes the per-I/O charges.
  4. Staging: use Single-AZ instances, smaller classes, and stop them outside working hours (or use Aurora Serverless v2 with a low minimum); delete old snapshots.
  5. Audit-log table: change the table class to Standard-IA because storage dominates, populate and enable TTL for records eligible after the 3-year retention boundary, allowing for asynchronous deletion (storing a long-term copy in S3 Glacier through an export if compliance needs it), and remove unused indexes.

Why not migrate the order system now? The vendor constraint rules it out for two years. Which Savings Plan? EC2/Compute Savings Plans do not apply to RDS. Database Savings Plans may cover eligible usage and must be compared with RIs; an existing EC2 commitment is not interchangeable with a database commitment.

10. Key terms

  • Reserved Instance (RDS): discounted billing for a specific database engine and class for 1 or 3 years.
  • Aurora Serverless v2: Aurora configuration that scales capacity in ACUs.
  • ACU: Aurora Capacity Unit, a unit of compute and memory.
  • Aurora I/O-Optimized: cluster configuration with no per-I/O charges.
  • On-demand capacity (DynamoDB): pay-per-request billing without capacity planning.
  • Provisioned capacity with auto scaling: configured RCU/WCU adjusted to target utilization; distinct from a reserved-capacity purchase.
  • Standard-IA table class: DynamoDB class with lower storage and higher request price.
  • TTL: DynamoDB feature that deletes expired items automatically.
  • DAX: in-memory cache for DynamoDB.
  • RDS Proxy: managed connection pooler.
  • BYOL: bring your own licence.

11. Summary checklist

  • I can choose between RDS, Aurora provisioned, Aurora Serverless v2, and DynamoDB from a workload description with a cost goal.
  • I know which database workloads justify Reserved Instances and which do not.
  • I can decide between DynamoDB on-demand and provisioned (with auto scaling), and between Standard and Standard-IA.
  • I can decide between Aurora Standard and I/O-Optimized.
  • I can use caches, read replicas, and RDS Proxy to avoid upsizing a database.
  • I can control backup retention, snapshots, TTL, and exports to limit storage cost.
  • I can identify when a migration to an open-source engine is the cost answer, and when constraints forbid it.

For retention tiers and exported archives, compare S3 lifecycle, backup and snapshot costs.

Sources