Design Cost-Optimized Database Solutions

Core Idea

Database cost optimization is really about not defaulting to a relational database for everything — RDBMS-for-all-data drives up both performance risk and total cost of ownership. Match the data store to access pattern, expected scale/growth, and access frequency.

Migration-Time Cost Levers

When moving data to AWS, three concrete cost-reduction moves are named:

1. Move a subset of the relational data to EC2/RDS (don't lift-and-shift everything as-is).
2. Move large objects out of the relational DB into S3 (BLOBs are expensive to keep in a relational engine).
3. Move a subset of relational data into a NoSQL store like DynamoDB.

Deciding What to Move

Diagnostic questions to ask about a given dataset before choosing its target store:

• Does this data rely on database-specific features?
• Will the schema stay fixed as the app evolves, or does it need flexibility?
• Do you need cross-table constraints enforced by the data model?

Answers pointing toward "no database-specific features, evolving schema, no cross-table constraints" favor moving that subset to DynamoDB — offloading admin burden (no hardware provisioning, setup/config, replication, patching, or cluster scaling to manage).

Service Selection Over Instance Tuning

Sometimes the cheaper move is a different service, not a different instance size — e.g., Aurora Serverless over standard Aurora for workloads with unpredictable or intermittent usage.

Scaling Strategy — Cost-Ranked

For a CPU-bound database suffering under heavy read load, the options in ascending cost order:

1. Vertical scale (bigger instance) — works, but is the most expensive option.
2. Horizontal scale — generally more cost-effective than vertical.
3. Read Replica or caching layer — usually the most cost-effective: offloads read requests from the primary instance entirely rather than paying for more primary capacity. This is called out explicitly as often beating instance-size scaling on cost while still meeting the performance requirement.

Backup Cost Discipline

• Design the backup plan to meet your RPO, at the right frequency — not more.
• Know which managed database services support point-in-time recovery.
• Set a retention policy so snapshots aren't kept past their useful life — unnecessary retained snapshots are a quiet, easy-to-miss storage cost.

Engine Choice Still Matters for Cost

Know the different RDS engine options and why you'd pick one over another — engine choice affects both licensing cost (see the compute-lesson note about Aurora/RDS eliminating licensing costs vs. commercial engines) and operational fit.

Managed Services as a Cost Principle

Restated as a closing principle for this task statement: managed services remove operational burden (server maintenance for apps/databases), and because they run at cloud scale, they can offer a lower cost per transaction than self-managed equivalents — use managed services by default unless there's a specific reason not to.

Exam Angle

Expect "read-heavy RDS instance under CPU pressure, most cost-effective fix" → Read Replica/cache before vertical scaling; "unpredictable/intermittent workload" → Aurora Serverless; and "reduce TCO of a relational-database-for-everything design" → subset migration to S3/DynamoDB.

Practical Examples

Migrating BLOBs out of the relational DB: An e-commerce RDS database stores product images as BLOB columns, ballooning both storage cost and backup time/cost (every backup re-copies the images). Moving the images to S3 and storing only the S3 URL in the RDS row cuts RDS storage cost dramatically and makes backups faster/cheaper, since S3 storage is far cheaper per GB than provisioned RDS storage.

Subset migration to DynamoDB, concretely: A relational user_sessions table has no cross-table foreign-key constraints, a simple flexible schema, and extremely high write volume with a short TTL — a textbook fit to peel off into DynamoDB (with TTL auto-expiry), leaving the core relational tables (orders, customers, with real referential integrity needs) in RDS.

Read Replica/cache beating vertical scaling on cost: A reporting dashboard is hammering the primary RDS instance with read queries, and the team's first instinct is to bump the instance class up two sizes (roughly 4x the hourly cost). Instead, adding one Read Replica dedicated to reporting traffic costs roughly the same as one extra instance (not 4x) and directly removes the read load causing the CPU pressure — cheaper and more targeted than blanket vertical scaling.

Aurora Serverless for a dev/test environment: A company keeps 6 separate dev/QA Aurora clusters running 24/7 "just in case," even though engineers only actively query them during work hours. Switching these to Aurora Serverless v2 (or v1 with auto-pause) lets each cluster scale down to near-zero (or fully pause) outside active use — a substantial cost cut for environments that are idle more than they're busy.

Backup retention discipline, concretely: A team's RDS automated backup retention is set to 35 days (the max) "for safety," and they've also accumulated 200 manual snapshots over 2 years, none ever deleted. Auditing shows their actual RPO requirement is 7 days. Trimming automated retention to 7 days and deleting manual snapshots older than the compliance-mandated retention window removes pure storage-cost waste with zero risk reduction lost.

Choosing the RDS engine for licensing cost: A team is about to lift-and-shift an on-prem SQL Server app that's currently paying steep per-core Microsoft licensing fees. Migrating to Aurora PostgreSQL (open-source-compatible engine, no database licensing fee) instead of "RDS for SQL Server" eliminates that licensing cost entirely — often a bigger saving than any instance-sizing optimization.