Cost Optimisation Strategies
By the end of this lesson, you'll be able to:
- Explain why cost is an architecture decision, not an afterthought applied at the end
- Identify the main sources of cost in a described architecture without hardcoded pricing
- Explain overengineering and why unnecessary complexity has its own cost
Prerequisites: "The AWS Well-Architected Framework"
Cost is an architecture decision, not a final checkbox
Every architecture decision this module has covered carries a cost implication, and treating cost as something reviewed only after a design is finished misses the point — it should shape the design itself. Worth asking for any architecture: what runs continuously regardless of load? What scales up and down with actual usage? What stores data, and how much? What transfers data, and how far? What generates logs, and how long are they kept? Are idle resources genuinely needed, or provisioned "just in case"? Does resilience (Multi-AZ, redundant components) duplicate resources that themselves cost money?
Resilience and performance both cost more
This is a direct, honest trade-off worth stating plainly: higher resilience generally increases cost (redundant instances, cross-AZ data transfer, additional monitoring), and the lowest-cost option generally reduces resilience or performance. Neither extreme is automatically correct — architecture is the discipline of finding where a specific workload's actual requirement sits on that spectrum, not defaulting to either "spend as little as possible" or "maximize every property regardless of need." This lesson deliberately avoids quoting current AWS prices for any service — check current pricing directly when a real decision needs it, since specific figures change over time and quickly go stale.
Overengineering: complexity that isn't justified by a requirement
It's worth naming directly: building an elaborate, highly resilient, extensively redundant architecture for a workload that doesn't actually need it isn't careful engineering — it's overengineering, and it has real costs of its own beyond the AWS bill: more to operate, more to monitor, more that can go wrong, and more time spent building it in the first place. A small internal tool with a handful of users may genuinely be well served by a simple, single-instance design; a high-volume system handling real financial transactions may genuinely justify significantly stronger resilience, security, and operational investment. The right amount of architecture is the amount the actual requirement justifies — not the maximum available, and not the minimum either.
Exercise
A small internal tool used by five employees is proposed with a multi-Region, multi-AZ, heavily redundant architecture identical to what a large public-facing e-commerce platform might use. Using this lesson's reasoning, explain what's likely wrong with this proposal, and what questions you'd ask to determine a more appropriately-scoped design.
Show hint
Think about what requirement would actually justify that level of resilience, and whether this specific workload has it.
Cost Optimisation Strategies Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Cost should be weighed as part of every architecture decision — what runs continuously, what scales with usage, what stores or transfers data, and whether resilience duplicates resources all shape the bill — and higher resilience or performance generally costs more, so architecture is fundamentally about balancing requirements against cost rather than maximizing every property at once; unnecessary complexity, built without a requirement that justifies it, is its own kind of cost.