Domain 4 Wrap-Up — Review Checklist

Framing

Cloud follows a variable-cost model — you pay monthly for what you use, and you can iteratively reduce your bill by continuously optimizing storage, compute, database, and network. The wrap-up frames this as a month-over-month improvement loop, not a one-time design decision: this month right-size EC2, next month turn on S3 Intelligent-Tiering, the month after something else — each change is independently measurable against your bill, which the lesson calls out as a genuinely rare feedback loop compared to on-prem cost accounting.

Compute Recap

Start with instance type/size selection, then layer in the pricing model (On-Demand, Reserved, Savings Plans, Dedicated, Spot) — each has a distinct cost-vs-flexibility profile.
Lambda cost model: charged for resources consumed and execution time — so cost optimization here means writing more resource-efficient, faster-running functions, a code-level lever most other services don't expose directly.
Containers: save by using smaller, more lightweight containers and choosing the right compute platform (EC2 vs. Fargate) for the cluster.
General instruction: review all compute services' use cases and pricing models — cost optimization requires breadth here, not just EC2 depth.

Cost Management Tooling Recap

Cost Explorer, Cost and Usage Report, Budgets — know these well enough to be tested on, not just recognize by name.
Tags configured specifically to feed cost-reporting tools — this is the connective tissue between architecture and cost visibility.

Storage Recap

Pick the most cost-effective storage solution per use case (again: match to actual need, don't default).
Know the automated methods for switching S3 storage classes — worked example: production logs barely accessed after 30 days, archivable after 90 days → Lifecycle Configuration (time-based, known pattern) is the fit here, not Intelligent-Tiering (which is for unknown patterns).
EBS: right volume types/sizes, plus lifecycle management of snapshots (for EBS) and backups (for databases) — don't let old snapshots/backups accumulate silently.

Purchasing Options Recap

Savings Plans, Reserved Instances, Spot Instances — understand mechanics of each, not just definitions, to match against a scenario's tolerance for interruption and commitment length.
Scaling strategies: Auto Scaling and hibernation — hibernation specifically called out as a cost tool (preserve in-memory state while not paying for compute) alongside standard scaling.

Database Recap

Choosing the right database for the use case is the starting cost lever (see D4_CostOptimizedDatabaseSolution_Insights (unresolved)).
From there: caching instead of always scaling up/out, and in some cases query/schema tuning — cost optimization isn't purely an infrastructure decision, it can be a design-level one too.

Networking Recap

Deep familiarity with each networking service's use cases, configuration knobs, and pricing model is required to actually move the needle on cost — service selection alone isn't enough.
Specific cost questions to be able to answer: minimizing VPC cost overall, minimizing NAT Gateway cost in dev, and configuring routes to minimize data-transfer cost across Region-to-Region, AZ-to-AZ, VPC endpoints, and Global Accelerator paths.

Closing Method (the actual exam skill)

The wrap-up's explicit process: first find a solution (or several) that meets the requirements, then evaluate those candidate designs for where to optimize cost — cost optimization is a second pass over an already-valid design, not a substitute for meeting the functional/performance/security bar first.

Practical Examples

Month-over-month optimization loop, concretely: Month 1, Cost Explorer reveals a fleet of over-provisioned m5.2xlarge instances averaging 15% CPU — right-size to m5.large, saving ~50% on those instances immediately. Month 2, S3 cost report shows a large "user-uploads" bucket with unpredictable access — turn on Intelligent-Tiering. Month 3, Trusted Advisor flags 12 unattached EBS volumes and 3 idle Elastic IPs — clean them up. Each month is an independent, measurable win against the prior month's bill — this iterative loop is the actual skill Domain 4 is testing, not a single big redesign.

Lambda cost tuning at the code level: A Lambda function configured with 1024 MB memory (which also scales proportional CPU) runs in 800ms. Profiling shows it's barely using 200 MB and is I/O-bound, not CPU-bound — dropping it to 256 MB barely changes runtime but cuts the per-invocation cost roughly 4x, since Lambda bills on memory × duration. This is a cost lever that's unique to Lambda among compute options: you tune the code and its resource allocation, not just the pricing model.

Fargate vs. EC2 for a container cluster, cost angle: A steady, predictable containerized workload running 24/7 at high utilization is often cheaper on EC2 launch type with Reserved Instances/Savings Plans (you're already paying for dedicated, well-utilized capacity, so Fargate's per-task premium for "no server management" isn't buying much). A spiky, unpredictable set of short-lived batch container jobs is often cheaper on Fargate (no idle EC2 capacity sitting around between bursts).

Known S3 access pattern → Lifecycle, not Intelligent-Tiering: Production logs, per the wrap-up's own worked example — barely accessed after 30 days, archivable after 90. Because the pattern is known and time-based, a straightforward Lifecycle Configuration (no per-object monitoring fee) beats Intelligent-Tiering here; Intelligent-Tiering earns its keep specifically when the pattern is unknown, which isn't the case for a predictable log-aging curve.

Hibernation as a cost tool: A data-science team's EC2 instance takes 20 minutes to reload a large in-memory dataset on every restart, so they've been leaving it running 24/7 just to avoid that reload cost, even though they only actively use it ~4 hours/day. Enabling EC2 hibernation lets them stop the instance overnight (RAM state saved to the root EBS volume, no compute charge while stopped) and resume next morning with the in-memory state intact — getting both the cost savings of stopping and avoiding the reload penalty.

"Meets requirements first, then optimize" in practice: A team designs a multi-AZ RDS + read replica + ElastiCache architecture to hit a strict availability and latency SLA. Only after confirming that design actually meets the SLA do they go back and ask "can we use Aurora Serverless instead of provisioned Aurora, or gp3 instead of io2, without breaking the SLA we already validated?" — cost optimization is explicitly the second pass, not a constraint baked in from the first line of the design.

D4_CostOptimizedComputeSolution_Insights (unresolved)
D4_CostOptimizedDatabaseSolution_Insights (unresolved)
D4_CostOptimizedNetworkArchitecture_Insights (unresolved)
D4_CostOptimizedStorageSolution_Insights (unresolved)