Cost-optimized databases: engine, capacity mode, serverless and retention choices
8 min read · about 1 h 5 min with practice3 quick checks≈3% of the testCore: Core: tested on most papers
Reading is free. Sign in to tick off lessons, keep your place and track your mastery.
Task statement 4.3 covers cost-optimized database design. A typical question describes a database workload (its access pattern, traffic shape, idle hours, licence or retention needs) and asks for the MOST cost-effective design that still meets every requirement. The wrong options are real features used in the wrong place: a discount that does not apply to databases, a high-availability feature treated as read scaling, or capacity paid for around the clock when the workload is idle most of the week.
By the end you’ll be able to
Choose the lowest-cost database service and engine that meets the access pattern (DynamoDB vs RDS vs Aurora, serverless options)
Select capacity and pricing modes: reserved DB instances, Aurora I/O-Optimized vs Standard, DynamoDB on-demand vs provisioned, Standard-IA table class
Design backup and retention policies (snapshot frequency, retention periods, export to S3) at minimum cost
Use caching or read replicas to avoid scaling up the primary; pick columnar (Redshift) or time-series storage for analytics
Migrate schemas and data to open-source or managed engines with DMS and Schema Conversion to remove licence cost
What the exam asks
Expect two to four questions on this topic, plus cost qualifiers on database questions in other domains. The patterns are: engine choice (DynamoDB, RDS, Aurora, Redshift, serverless or provisioned), pricing modes (reservations, Aurora I/O-Optimized, DynamoDB capacity modes and table classes), idle capacity, cheap read scaling, retention and licence removal.
Core ideas
The five things you pay for
Cost driver
RDS / Aurora
DynamoDB
Usual lever
Compute
Instance-hours or Aurora capacity units (ACUs)
Request units or provisioned RCUs/WCUs
Rightsize, Graviton, reserve, serverless, stop when idle
Storage
GB-month, plus provisioned IOPS on io1/io2
GB-month by table class
gp3 instead of io1, Standard-IA, TTL
I/O
Per-request charges on Aurora Standard only
Included in request pricing
Aurora I/O-Optimized
Backups
Storage beyond the free allowance, manual snapshots
PITR, on-demand backups
Shorter retention, export to S3
Licences
Oracle and SQL Server License Included
None
Migrate to Aurora PostgreSQL or MySQL
Stems name the driver outright (“I/O is 45% of the bill”, “idle nights and weekends”), and the right answer goes after it.
Match the engine to the access pattern
Signal in the stem
Lowest-cost fit
Key-value lookups by ID, no joins, spiky or unknown traffic
DynamoDB on-demand
Relational, steady 24/7 load for years
vii.Check your understanding
3 questions on cost-optimized databases: engine, capacity mode, serverless and retention choices. Every option is explained once you answer.
Sign in to try the quick check
Answers are checked on our side, every option is explained, and your result feeds your mastery for this topic. It’s free.
The first 3 of 12 cards for this topic. Sign in and finish the lesson to review them with spaced repetition.
PromptCard 1 of 3
When is Aurora I/O-Optimized cheaper than Aurora Standard?
RDS or Aurora provisioned + reserved DB instances
Relational, variable load or long idle periods
Aurora Serverless v2
Heavy aggregations over terabytes of history
Amazon Redshift (Serverless if use is intermittent) or S3 + Athena
Repeated identical reads that tolerate staleness
ElastiCache or DAX in front of the database
Pricing modes
Reserved DB instances (with equivalents for ElastiCache, Redshift and OpenSearch) give 1- or 3-year discounts with All, Partial or No Upfront payment. They cover Multi-AZ deployments. For MySQL, MariaDB, PostgreSQL, Oracle BYOL and Aurora they are size-flexible within an instance family. They discount instance-hours only, not storage, I/O or backups. Compute Savings Plans do not apply to RDS: they cover EC2, Fargate and Lambda. That misconception is the most common distractor in this topic. AWS has since added Database Savings Plans, but for a steady workload on a fixed engine, exam items expect reserved DB instances.
Aurora Standard vs I/O-Optimized. Standard bills every I/O request. I/O-Optimized has no I/O charges but higher instance and storage rates. The AWS rule of thumb is to choose I/O-Optimized when I/O is 25% or more of Aurora spend. It is a cluster setting, so there is no migration and no endpoint change.
Aurora Serverless v2 scales in fine-grained ACU steps. It can also scale to 0 ACUs and pause when idle: compute charges stop, storage is still billed, and the first connection waits about 15 seconds. It suits dev/test databases and occasionally used internal apps.
DynamoDB. On-demand is the default: pay per request, which suits new, spiky or unpredictable traffic. Provisioned with auto scaling is cheaper for steady, forecastable traffic, and reserved capacity discounts the baseline further. The Standard-IA table class lowers storage price and raises request price. It pays off when storage dominates (AWS’s guide is storage above about 50% of throughput cost), with the same performance and APIs. TTL deletes expired items free, without consuming write capacity.
Stop paying for idle
Stop RDS/Aurora on a schedule with EventBridge Scheduler. The endpoint is kept, but storage and backups still bill, and RDS restarts a stopped instance after 7 days.
Aurora cloning makes a writable copy in minutes with copy-on-write. You pay only for changed pages, which is far cheaper than restoring a snapshot for daily test copies.
Delete unused manual snapshots. They are billed until you delete them.
Scale reads without scaling up
Look at the reads first. Repeated identical queries that tolerate staleness call for a cache: a small ElastiCache node with lazy loading and a TTL is cheaper than any replica. Varied queries that need fresh data call for read replicas. A Multi-AZ DB instance standby cannot serve reads. Rightsize from CloudWatch data (CPU, freeable memory, IOPS). Choose Graviton classes for price-performance, and gp3 storage, which includes baseline IOPS, instead of paying for io1/io2 IOPS you never use.
Backups and retention
RDS automated backups give 1 to 35 days of point-in-time recovery. Backup storage up to your provisioned database size is free. Longer retention needs manual snapshots or an AWS Backup plan, billed at snapshot rates. If long-term copies never need to be restored as a database, export snapshots to S3 as Apache Parquet, lifecycle them to S3 Glacier Deep Archive, and query them with Athena after restoring the objects. That is far cheaper per GB. DynamoDB export to S3 consumes no read capacity.
Licences
Removing Oracle or SQL Server licences is often the biggest saving. DMS Schema Conversion (or the AWS Schema Conversion Tool) converts schema and code. AWS DMS then does a full load plus ongoing replication (CDC), so cutover downtime is minimal. For a SQL Server application with the fewest code changes, choose Aurora PostgreSQL with Babelfish, which accepts T-SQL over the SQL Server wire protocol (TDS).
Worked examples
Exam technique
Name the cost driver before reading the options: idle hours, requests, storage, I/O, licences or retention.
Classify the traffic: steady (reserve or provision), unknown or spiky (on-demand or serverless), long idle stretches (stop or pause).
Check that each discount applies: reserved DB instances apply to RDS and Aurora. Compute Savings Plans do not, and RDS has no Spot pricing.
Honour hidden constraints: “without changing the application” keeps the engine and endpoint, “relational” rules out DynamoDB, and “restorable” rules out Parquet exports. In Choose three items, expect compute (smaller or Graviton class), storage (io1 to gp3) and commitment (reserve after rightsizing).
Common mistakes
Quick recap
Steady relational load for years: reserved DB instances. A 3-year All Upfront term gives the largest discount, and Compute Savings Plans do not apply.
Variable or idle relational load: Aurora Serverless v2, which can pause at 0 ACUs.
Aurora I/O at 25% or more of spend: I/O-Optimized.
DynamoDB: on-demand for spiky or unknown traffic, provisioned with reserved capacity for steady traffic, Standard-IA when storage dominates, TTL for free expiry.
Repeated identical reads: cache. Varied fresh reads: replicas. A Multi-AZ standby never serves reads.
Daily Aurora test copies: clone, don’t restore.
Retention: 35 days of automated backups at most. Data that never needs restoring goes to S3 Parquet on Glacier Deep Archive.
Licences: DMS Schema Conversion plus DMS CDC to Aurora. For SQL Server with the fewest changes, Babelfish.