Cost-Optimized Databases: DynamoDB vs RDS, Aurora Serverless, and Caching

Every database cost question starts from one structural difference. Amazon RDS bills for instance-hours: you provision an instance class, and you pay for every hour it runs whether it serves ten thousand queries or none. Storage (per GB-month), any provisioned IOPS, backup storage beyond the included allowance, and data transfer stack on top, but the instance-hours dominate a typical bill — and they accrue at 3 a.m. on a Sunday exactly as they do at peak. DynamoDB bills for requests and storage: in on-demand mode you pay per read and write request, in provisioned mode you pay per capacity-unit-hour, and in either mode an idle table costs you little more than the gigabytes it stores. There is no instance to leave running.

That difference is the master decision rule: the more idle time a workload has, the more a request-priced or serverless model wins; the steadier the load, the more a provisioned instance (discounted with a commitment) wins. A database that is busy 24/7 keeps every instance-hour productive, so paying for instance-hours is efficient. A database that is busy two hours a day wastes 22 hours of instance cost — the shape of workload where DynamoDB on-demand or a serverless engine is dramatically cheaper.

Two supporting facts round out the model. You can stop an RDS instance to pause instance-hour billing — but storage and backup charges continue, and a stopped instance restarts automatically after seven days, so stopping is a dev-and-test tactic, not an architecture. And Aurora decouples storage from compute: its cluster volume grows automatically and bills for what you use, so you never pre-provision storage headroom the way you would size an RDS volume.

The exam tests this by describing a workload's traffic pattern in the first sentence — "unpredictable", "intermittent", "steady", "spiky" — and expecting you to translate that adjective into a pricing model before you even look at the options. Read the workload shape first; it eliminates half the answers.

The engine you pick sets a cost floor before you size anything. RDS for MySQL, PostgreSQL, and MariaDB carries no license cost — you pay for infrastructure only. RDS for Oracle and SQL Server adds commercial licensing, either bundled into a higher hourly rate (License Included) or brought yourself (BYOL, where supported). When a scenario says an application "can run on any engine" or is being re-platformed, the open-source engine is the cost answer; between MySQL and PostgreSQL specifically there is no meaningful price gap, so that choice is about features and team skills, not cost.

Aurora sits in the middle: MySQL- and PostgreSQL-compatible with no commercial license, but priced at a premium over the same-size RDS instance. What you get back is structural efficiency. Aurora's storage layer is shared by the whole cluster, so up to 15 low-lag replicas read from one storage volume — each replica adds only its instance cost. An RDS read replica, by contrast, is a full copy: another instance plus another complete set of storage. So the rule of thumb: a small, simple workload with zero or one replica is usually cheaper on plain RDS; a workload that needs several replicas, fast failover, or storage that grows unpredictably often ends up cheaper — and better — on Aurora.

Licensing also drives the migration cost angle. A homogeneous migration (Oracle to Oracle, MySQL to Aurora MySQL) uses AWS Database Migration Service (DMS) with minimal conversion work. A heterogeneous migration (Oracle to Aurora PostgreSQL) adds the AWS Schema Conversion Tool (SCT) to convert schemas and code — a real one-time engineering effort. The trade the exam wants you to see: that one-time effort buys the permanent elimination of a recurring license bill. When a scenario complains about Oracle or SQL Server licensing costs, the answer is SCT plus DMS into an open-source-compatible engine.

Expect the exam to test this at recognition level: spot the commercial-license cost in a scenario, know that heterogeneous migrations need SCT while homogeneous ones need only DMS, and price Aurora's premium against its replica and storage efficiencies rather than dismissing it as "more expensive."

When the workload shape is intermittent, spiky, or simply unknown, serverless options convert idle time from a cost into a non-event.

Aurora Serverless v2 is the relational answer. Capacity is measured in Aurora Capacity Units (ACUs), billed per second, and the database scales up and down in fine-grained increments as load changes — including scaling down to zero capacity and pausing when the database sits idle, so a dormant environment costs storage and little else. It is a full Aurora engine, so it keeps SQL, transactions, and MySQL/PostgreSQL compatibility: no application rewrite. The classic fits are development and test databases used only during working hours, internal tools with bursty usage, new products with unknown traffic, and multi-tenant SaaS with unpredictable per-tenant load. The honest limit: at sustained high utilization, ACU-seconds cost more than an equivalently sized provisioned instance running flat out — a steady 24/7 workload should stay provisioned (and reserved). Serverless buys elasticity; it does not discount steady-state compute.

DynamoDB on-demand mode is the non-relational counterpart: no capacity planning at all, pay per request, instant absorption of spikes, and effectively zero cost when nothing is happening. Its mirror-image limit is the same: per-request pricing is set above what fully utilized provisioned capacity works out to, so predictable, steady traffic is cheaper on provisioned capacity with auto scaling (covered later in this lesson).

The shared decision rule: serverless and on-demand are for workloads that are idle much of the time or impossible to forecast; provisioned capacity is for workloads busy enough to keep what you paid for working.

On the exam, the trigger words are unmistakable — "only used during business hours," "a few times a week," "unpredictable traffic," "cannot forecast demand." Any of those plus MOST cost-effective points at Aurora Serverless v2 (relational) or DynamoDB on-demand (key-value). The distractor is usually a Reserved Instance, which commits you to paying for exactly the idle hours the scenario just told you about.

For the workloads that should stay provisioned — steady, predictable, always-on — the cost levers are commitment and sizing.

RDS Reserved Instances apply the familiar commitment model to databases: commit to an instance class for a one- or three-year term and receive a significant discount versus on-demand, deeper with longer terms and upfront payment. Aurora supports the same mechanism, and ElastiCache offers reserved nodes on the same logic — you need these at recognition level: steady, long-lived database or cache capacity plus MOST cost-effective equals a reservation. The one prerequisite the exam checks: the workload must actually run continuously. Reserving an instance that idles nights and weekends locks in waste — that scenario belongs to serverless.

Right-sizing is the unglamorous lever that questions dress up in CloudWatch metrics. An RDS instance showing single-digit CPU and low connection counts for weeks is over-provisioned; the cost answer is to step down the instance class, not to reserve the oversized one. Burstable (t-class) instances suit small, occasionally busy databases; memory-optimized (r-class) instances are for genuinely memory-bound engines — matching the class to the bottleneck is part of the skill.

Storage has its own two levers. RDS storage auto scaling grows the allocated volume automatically when free space runs low, which means you can provision for today instead of padding for next year — eliminating the classic pattern of paying years in advance for empty gigabytes. And provisioned IOPS (io1/io2) storage is a premium product for a specific need: sustained, latency-sensitive, high-IOPS workloads. General purpose (gp3) storage covers the vast majority of databases at a fraction of the cost. Provisioned IOPS on a lightly loaded database is one of the purest forms of database waste — and a detail scenarios plant deliberately.

Exam-wise, expect metric-driven scenarios: a described utilization profile, then options mixing reservations, downsizing, serverless, and storage changes. Match steady-and-busy to reservations, steady-and-underused to downsizing, and treat any mention of provisioned IOPS without an IOPS-heavy workload as the cost problem to remove.

When a database is struggling — or growing expensive — under read load, the reflex answer is a bigger instance. The cost-optimized answer is usually a cache, because a cache node serving repeated reads costs far less than the instance-class upgrades needed to serve those same reads from the database. Every cache hit is a query the database never runs, which means the database itself can stay small.

Amazon ElastiCache (Redis or Memcached) fronts relational databases: the application checks the cache first and falls back to the database on a miss. It shines exactly where read traffic is repetitive — product catalogs, session data, leaderboards, rendered fragments, hot lookup tables. The economics compound: instead of scaling the database instance up (doubling instance-hours) or out (adding full-price replicas), you add a modest cache node and absorb the majority of reads at microsecond latency.

DAX (DynamoDB Accelerator) is the same idea purpose-built for DynamoDB: an API-compatible, write-through cache that serves repeated reads in microseconds. Its cost effect is direct and measurable — reads served by DAX consume no read capacity, so a read-heavy table with a hot item set needs far less provisioned capacity or far fewer on-demand read requests. Because it is API-compatible, adopting DAX is a client-configuration change rather than an application rewrite, which matters when a question weighs it against re-architecting.

Run the arithmetic the way the exam implies it: if 80% of reads hit the same small working set, a cache turns four-fifths of your database read load into cache hits. Serving that same load from the database instead means either a substantially larger instance class or one or more replicas — each a step-change in instance-hours — versus one modest cache node. The cache also improves latency as a side effect, which lets it satisfy performance-framed questions and cost-framed ones with the same answer.

The trade-off the exam loves is read replicas versus caching. A read replica is a full-price database instance (and, outside Aurora, a full copy of storage) that can serve any query with near-fresh data. A cache is much cheaper but only accelerates repeated reads, requires application changes, and serves potentially stale data within its TTL. Decision rule: if the read load is repetitive and the application tolerates seconds of staleness, cache — it is the cheaper fix. If the reads are diverse (reporting, ad-hoc queries, full SQL against fresh data), a replica is the tool, because a cache would miss constantly.

On the exam, "read-heavy," "same items read repeatedly," or "popular products" plus MOST cost-effective points at ElastiCache or DAX; scaling the instance or adding replicas are the costlier distractors. Reverse the trigger — "complex analytical queries must not impact production" — and the replica becomes correct.

Backup cost is a design decision disguised as an operational default, and Task 4.3 names it explicitly: appropriate snapshot frequency and retention.

Start with the fact that anchors it all: for an active RDS or Aurora database, backup storage equal to your provisioned database storage is included at no additional charge. Automated backups within a modest retention window typically live inside that allowance; charges begin when accumulated backup storage exceeds it. That gives you the first rule: retention windows should match the actual recovery requirement, not a comfortable maximum. Automated backups support 1 to 35 days of retention with point-in-time recovery; if the business requirement is "restore to any point in the last 7 days," configuring 35 days simply multiplies stored backup data for no stated benefit.

Manual snapshots are the silent accumulator. They never expire on their own, they persist after the instance is deleted, and every one bills for its storage every month, forever, until someone deletes it. Years of ad-hoc "pre-deployment" snapshots are a classic waste finding — stale snapshots belong on any database cost audit.

Snapshot frequency trades recovery point against storage: more frequent snapshots mean a tighter recovery point objective and more stored data. The design skill is reading the RPO out of the scenario and provisioning exactly that much history.

For long-term archives — compliance data that must be kept for years but will almost never be restored — keeping old snapshots in database backup storage is the expensive habit. The recognition-level pattern: export snapshots to Amazon S3 (RDS supports snapshot export to S3 in an analyzable format), then let S3 lifecycle policies transition the exports to Glacier storage classes, where the per-gigabyte cost is a small fraction of live backup storage.

The exam tests this with retention-mismatch scenarios: a stated recovery requirement, a configuration that exceeds it, or a compliance archive sitting in snapshots. The MOST cost-effective option aligns retention to the requirement and pushes long-term history to S3 and Glacier — and never sacrifices a stated recovery objective to save money.

Capacity planning is where request-priced services get their own right-sizing story.

DynamoDB's two capacity modes are the headline decision. In provisioned mode you specify read and write capacity units (RCUs and WCUs) and pay per capacity-unit-hour — and you should almost always pair it with auto scaling, which adjusts provisioned capacity between a floor and ceiling as consumption changes, so daily rhythms don't force you to provision for the peak all day. In on-demand mode you pay per request with no planning at all. The economics: on-demand's per-request price is set above what well-utilized provisioned capacity costs, so steady or predictably cyclical traffic is cheaper provisioned with auto scaling, while spiky, unpredictable, or brand-new traffic is cheaper (and safer) on-demand. Over-provisioned tables — capacity set for a launch spike that never recurred — are pure waste; badly under-provisioned tables throttle, which fails the "still meets requirements" half of the qualifier. DynamoDB also offers reserved capacity for large, stable provisioned workloads — recognition level: the commitment model exists for DynamoDB too.

On the relational side, capacity planning means the IOPS discipline from earlier — provisioned IOPS only when a measured, sustained IOPS requirement exists — plus one connection-shaped lever: Amazon RDS Proxy. Serverless applications, especially Lambda at scale, can open so many database connections that teams up-size the instance just to hold them. RDS Proxy pools and shares connections, so the database is sized for its query load, not its connection count. The proxy has its own hourly cost, so it earns its keep specifically in high-concurrency, connection-churning architectures.

The exam tests capacity mode selection with traffic adjectives, exactly like the serverless section: "consistent and predictable" means provisioned plus auto scaling, "unpredictable" or "infrequent spikes" means on-demand. Watch for the inverted distractor — on-demand offered for a steady, high-volume table, where it is the more expensive choice dressed up as the modern one.

Most Task 4.3 questions reduce to a single lookup: what shape is the workload, and what is the cheapest design that still meets every requirement?

And when a question hands you an existing architecture and asks what to fix, run the database bill levers checklist — the recurring sources of waste:

1. Idle instances billing 24/7 for part-time work (move to serverless, or stop non-production off-hours). 2. Over-provisioned instance classes flatlining at low CPU (right-size down). 3. Provisioned IOPS without an IOPS workload (drop to gp3). 4. The wrong DynamoDB capacity mode for the traffic shape (steady on on-demand, or spiky over-provisioned). 5. A missing cache in front of repetitive read load (add ElastiCache or DAX, shrink the database). 6. Stale manual snapshots and over-long retention (delete, align retention to RPO, archive to S3/Glacier). 7. Steady instances with no reservation (buy RIs). 8. Commercial licenses the application doesn't need (migrate to open source).

The exam tests this as elimination: several options are plausible, and the table tells you which one is cheapest for the stated shape — while the requirements tell you which cheap options are disqualified.

Scenario 1 — the intermittent workload. An internal reporting application uses a MySQL database on a memory-optimized RDS instance running 24/7 on-demand. Analysts use it weekdays from 9 to 5; it is idle overnight and on weekends. The application must keep MySQL compatibility. What is the MOST cost-effective change?

Reasoning: The workload shape is the giveaway — roughly a quarter of the week busy, the rest idle, on a pricing model that bills every hour. Eliminate DynamoDB: it would erase idle cost, but the requirement says MySQL compatibility, and a rewrite fails "meets every requirement." Eliminate the Reserved Instance: an RI discounts the 24/7 instance-hours, but it still pays for every idle night and weekend — a discount on waste is still waste. Eliminate simply downsizing: cheaper, but the idle-hours problem remains. The answer is Aurora Serverless v2 (MySQL-compatible): full SQL compatibility with no rewrite, capacity that tracks the 9-to-5 usage curve per second, and near-zero compute cost while idle. Idle-heavy plus relational-compatibility-required resolves to serverless Aurora almost every time.

Scenario 2 — the read-heavy cost decision. An e-commerce product-catalog service runs on RDS PostgreSQL. Traffic is 95% reads, concentrated on the same popular products, and the application tolerates data a few seconds old. Read load is pushing CPU toward its limit. Options: (a) scale the instance up two classes, (b) add two read replicas, (c) add an ElastiCache cluster and cache product lookups, (d) migrate to DynamoDB. Which is MOST cost-effective?

Reasoning: All four can relieve the CPU pressure, so this is pure cost elimination. Migration to DynamoDB (d) is a re-architecture project — massive effort against a problem three smaller changes solve, and nothing says the data model fits. Scaling up (a) doubles-plus the instance-hour bill and buys capacity the writes don't need. Two read replicas (b) work — but that is two additional full-price instances, each with its own storage, to serve reads that are repetitive. That repetitiveness is the tell: the same products, staleness tolerated, means cache hits will dominate. (c) ElastiCache absorbs the hot reads on a modest cache node, the primary shrinks back to comfortable utilization, and the total spend is a fraction of either alternative. Replicas would win only if the reads were diverse or had to be fresh — which the scenario explicitly ruled out.

Both scenarios show the Domain 4 method: requirements first to disqualify, workload shape second to rank the survivors by cost. Expect every question in this task to yield to that order of operations.