← Design Cost-Optimized Architectures

▶ Play from here · 50 min

Starts this lesson and continues through 4 more to the end of certification prep.

Database cost — engine, capacity mode, retention, and the cache in front

Why this lesson matters

Task statement 4.3 is "Design cost-optimized database solutions". The skills, verbatim:

• "Designing appropriate backup and retention policies (for example, snapshot frequency)"
• "Determining an appropriate database engine (for example, MySQL compared with PostgreSQL)"
• "Determining cost-effective AWS database services with appropriate use cases (for example, DynamoDB compared with Amazon RDS, serverless)"
• "Determining cost-effective AWS database types (for example, time series format, columnar format)"
• "Migrating database schemas and data to different locations and/or different database engines"

And knowledge items including "Caching strategies", "Data retention policies", "Database capacity planning (for example, capacity units)", and "Database connections and proxies".

The distinguishing question is: is the load steady or spiky — and do you pay for capacity or for requests?

   steady, predictable         →  provisioned capacity + a commitment (reserved DB instances / Database SP)
   spiky, unpredictable, idle  →  on-demand / serverless (DynamoDB on-demand, Aurora Serverless)
   read-heavy, repeated reads  →  a cache in front, so the database can be smaller
   analytic scans              →  a columnar store, not a bigger OLTP instance

Relational: provisioned vs Aurora Serverless

From Using Aurora serverless and How Aurora serverless works, fetched 2026-09-25:

"Aurora serverless is an on-demand, autoscaling configuration for Amazon Aurora. … You're charged only for the resources that your DB clusters consume."

"This type of automation is especially valuable for multitenant databases, distributed databases, development and test systems, and other environments with highly variable and unpredictable workloads."

And AWS's contrast, which is exactly the exam discriminator:

"Aurora provisioned clusters are suitable for steady workloads. … The provisioned model works well when you can adjust capacity in advance of expected consumption patterns."

⚠️ Scale-to-zero is version-dependent. AWS's table shows the 0–256 range only on Aurora MySQL 3.08.0+ and specific Aurora PostgreSQL minor versions; older versions bottom out at 0.5 ACU. "Serverless" alone doesn't mean "free when idle".

⚠️ Mixed clusters are allowed — "any combination of Aurora serverless capacity, provisioned capacity, or both". A steady writer on provisioned with serverless readers for spiky reporting is a legitimate cost design.

Dev/test tip from AWS: use serverless "with a low minimum capacity instead of using burstable db.t* DB instance classes", and for long idle periods, "stop and start the entire cluster".

DynamoDB: on-demand vs provisioned

From DynamoDB throughput capacity, fetched 2026-09-25:

⚠️ Older study material says provisioned is the default. The current page says on-demand is. Answer from the stem's workload shape, not from which is "default".

Capacity units — the arithmetic

The knowledge item "Database capacity planning (for example, capacity units)". From DynamoDB provisioned capacity mode:

• "For an item up to 4 KB, one read capacity unit (RCU) represents one strongly consistent read operation per second, or two eventually consistent read operations per second."
• "A write capacity unit (WCU) represents one write per second for an item up to 1 KB."
• Round up per item: AWS's example, a 3 KB item → "0.75 or 1 read capacity unit"; 512 bytes → "0.5 or 1 write capacity unit".
• "Read operations in DynamoDB are eventually consistent, by default."

Worked: 80 strongly consistent reads/s of 3 KB items = 80 RCU. Switch to eventually consistent and it's 40 RCU — half the read cost for the same traffic, if the application tolerates it.

Auto scaling (provisioned) uses Application Auto Scaling with a target utilisation; AWS "recommend[s] setting target utilization to 70%". It's enabled by default when you create a table in the console.

Switching: "You can switch tables from provisioned capacity mode to on-demand mode up to four times in a 24-hour rolling window. You can switch tables from on-demand mode to provisioned capacity mode at any time."

Table classes

From DynamoDB table classes: Standard is the default; Standard-Infrequent Access "is optimized for tables where storage is the dominant cost" — AWS's examples are "application logs, old social media posts, e-commerce order history, and past gaming achievements". "The choice of a table class is not permanent."

Commitments for databases

Reserved DB instances, from Reserved DB instances for Amazon RDS, fetched 2026-09-25:

• "one- or three-year term"; "not physical instances, but rather a billing discount".
• Payment: No Upfront ("only available as a one-year reservation"), Partial Upfront, All Upfront.
• Size flexibility within an instance class type, for RDS for Db2, MariaDB, MySQL, Oracle (Bring Your Own License) and PostgreSQL. ⚠️ "Size flexibility does not apply to RDS for SQL Server and RDS for Oracle License Included."
• Multi-AZ is covered: "Reserved DB instance benefits apply to both Multi-AZ and Single-AZ configurations." A Multi-AZ instance counts double in normalized units.
• ⚠️ Compute only: "The price for a reserved DB instance doesn't provide a discount for the costs associated with storage, backups, and I/O."
• "You can't cancel a reserved DB instance."
• Organizations: "all accounts in the organization can receive the hourly cost benefit of reserved DB instances that are purchased by any other account."

Database Savings Plans (lesson 3): up to 35%, applying "regardless of engine, instance family, size, Availability Zone (AZ), or Region, and also apply to serverless usage" — including a move "from RDS to DynamoDB while maintaining your discounted rates".

Engine choice — the licensing signal

The skill is "Determining an appropriate database engine (for example, MySQL compared with PostgreSQL)".

⚠️ I did not fetch a page that compares MySQL and PostgreSQL on cost, and I won't invent one. What the fetched pages do show is that licence-included commercial engines behave differently for cost: reserved-instance size flexibility doesn't apply to SQL Server or Oracle License Included, and reserved instances must match "License type (license-included or bring-your-own-license)". So on the exam, "reduce licensing cost" points toward an open-source engine (MySQL, PostgreSQL, or Aurora's compatible editions), and DMS below is how you get there. Between MySQL and PostgreSQL themselves, the choice is compatibility and features, not a price difference I can source.

Migrating — homogeneous vs heterogeneous

From What is AWS Database Migration Service?, fetched 2026-09-25:

"To migrate to a different database engine, you can use DMS Schema Conversion. This service automatically assesses and converts your source schemas to a new target engine. Alternatively, you can download the AWS Schema Conversion Tool (AWS SCT)."

"You can perform one-time migrations or replicate ongoing changes to keep sources and targets in sync."

AWS names the cost motive directly: DMS "can help you switch to a modern, perhaps more cost-effective, database engine".

Backup retention — the cost of keeping history

From Backup retention period and Introduction to backups, fetched 2026-09-25:

⚠️ Retention beyond 35 days is not an automated-backup setting. If the stem says "keep monthly backups for seven years", automated backups can't do it — use manual snapshots or AWS Backup with cold storage (lesson 2).

⚠️ AWS's own RDS reserved-instance example shows backup storage "(400 GiB free)" for a 400 GiB database, but calls its prices "sample prices". I did not fetch RDS pricing, so I make no general claim about free backup allowance — read aws.amazon.com/rds/pricing/.

Snapshot frequency is the RPO lever from SAA2 lesson 6: more frequent backups → lower RPO → more storage. The cost design is to keep frequent backups for a short window and move only the long-term ones to cheaper storage.

Caching — buy a smaller database

The knowledge item is "Caching strategies". From Caching strategies, fetched 2026-09-25:

AWS's summary: "Lazy loading allows for stale data but doesn't fail with empty nodes. Write-through ensures that data is always fresh, but can fail with empty nodes and can populate the cache with superfluous data. By adding a time to live (TTL) value to each write, you can have the advantages of each strategy."

The cost argument: a cache absorbs repeated reads, so the database behind it can be smaller, or need fewer read replicas. Read replicas and connection proxies are covered in SAA2 lesson 5 (RDS Proxy) and SAA3 lesson 3 (replicas for performance).

Database types — columnar and time series

The skill "Determining cost-effective AWS database types (for example, time series format, columnar format)".

Columnar, from Redshift columnar storage:

"Columnar storage for database tables is an important factor in optimizing analytic query performance, because it drastically reduces the overall disk I/O requirements."

AWS's example: "suppose a table contains 100 columns. A query that uses five columns will only need to read about five percent of the data." And "row-wise storage is optimal for OLTP databases."

Time series, from What is Amazon Timestream for LiveAnalytics?:

"Timestream for LiveAnalytics saves you time and cost in managing the lifecycle of time series data by keeping recent data in memory and moving historical data to a cost optimized storage tier based upon user defined policies."

It is "serverless and automatically scales up or down".

The cost rule: don't scale up an OLTP instance to run analytics or store sensor streams. Put the workload in the store shaped for it.

Choosing, under exam conditions

Check yourself

1. 100 strongly consistent reads per second of 6 KB items. How many RCUs? And if eventually consistent?
2. What's the maximum automated backup retention for an RDS DB instance, and what does 0 do?
3. Name the disadvantage of each: lazy loading, write-through.
4. Does a reserved DB instance discount storage and backups?
5. What does a heterogeneous migration need that a homogeneous one doesn't?

Answers

1. 6 KB ÷ 4 KB = 1.5 → rounds up to 2 RCU per read → 200 RCU. Eventually consistent is two reads per RCU → 100 RCU.
2. 35 days. "Setting the backup retention period to 0 disables automated backups" — and switching to or from 0 causes an outage.
3. Lazy loading: cache miss penalty and stale data. Write-through: missing data on new nodes and cache churn.
4. No — "doesn't provide a discount for the costs associated with storage, backups, and I/O."
5. Schema conversion — DMS Schema Conversion or AWS SCT — before DMS moves the data.

Teaching this section

• Open with the steady-vs-spiky axis and put every service on it: provisioned RDS, Aurora Serverless, DynamoDB provisioned, DynamoDB on-demand.
• Demo: do the RCU arithmetic on the board with three item sizes and both consistency modes. Numbers make capacity mode concrete.
• Best discussion prompt: "DynamoDB on-demand is now the recommended default. When would you still choose provisioned?" Answer: forecastable steady traffic, where paying for capacity beats paying per request.
• Watch for: "reserved instances cover my whole RDS bill". Storage, backups and I/O are separate.
• Timing: 25 min presented, 15 on the choosing table.