Cost-Optimized Databases

Amazon RDS and Aurora extend the same commitment-for-discount tradeoff covered for EC2: Reserved Instances commit to a specific database instance class and Region for a 1- or 3-year term, in exchange for a significant discount over On-Demand — the right fit for a production database that runs continuously at a known size. For workloads that don't fit that steady-state shape — development and test databases, new applications with unsettled traffic, or workloads with long idle stretches between bursts — Aurora Serverless v2 bills per Aurora Capacity Unit (ACU) actually consumed, scaling automatically within a range you set. As of a 2024 update, Aurora Serverless v2 can now scale all the way down to 0 ACUs, automatically pausing when idle and resuming (in roughly 15 seconds) on the next connection — a genuine scale-to-zero option for workloads that can tolerate that reconnect delay, which earlier versions of Aurora Serverless couldn't offer.

aws rds modify-db-cluster \
  --db-cluster-identifier my-dev-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4

DynamoDB extends the same idea two ways. Its two capacity modes trade off the same way EC2's purchasing options do: on-demand charges per request with no commitment, ideal for unpredictable traffic; provisioned capacity, sized to a steady, known throughput, costs less per request — and provisioned capacity can itself be purchased as Reserved Capacity for an upfront 1- or 3-year commitment, the same steady-state discount pattern as RDS Reserved Instances.

A second, separate lever is the table class. DynamoDB Standard is the default, tuned for a balance of storage and throughput cost. DynamoDB Standard-IA trades roughly 25% higher throughput cost for roughly 60% lower storage cost — worth switching to specifically when a table's storage is genuinely its dominant cost, such as years of application logs or order history that's rarely read. Neither performance, availability, nor durability changes between the two table classes; it's purely a cost lever, and you can switch between them without touching your application code.

Backup retention has its own cost trap. Deleting an RDS DB instance deletes its automated backups (unless you choose to retain them), but it never deletes manual snapshots — those persist, and keep billing for their storage, until someone explicitly deletes them. A team that deletes a decommissioned database and assumes the cleanup is complete can end up paying for manual snapshots indefinitely.

Caching also has a cost dimension, not just a performance one: an ElastiCache layer that absorbs read traffic (using the lazy loading or write-through strategy from earlier) reduces the read capacity a database needs to be provisioned for, which can lower the database's own cost enough to offset the cache's own cost — especially for a read-heavy, hot-key workload.