Running a monthly cost review

Cost optimisation is not a one-time project; it is an ongoing practice, because costs drift continuously — new workloads, forgotten resources, growing data, changing usage. The habit that keeps a bill under control is a regular cost review: a short, scheduled look at where the money is going and what to do about it. This final lesson of the course pulls the whole cost module — and the cost theme running through every module — into a repeatable routine. It closes the AWS DevOps in Practice course.

Why a regular review

You have the skills now: reading the bill, finding waste, right-sizing, scale-to-zero, Savings Plans. But applied once and forgotten, they decay — because the account keeps changing:

• New resources appear — a new service, a new environment, a workload that grew.
• Old waste re-accumulates — orphaned volumes, idle load balancers, forgotten environments creep back.
• Usage shifts — a workload that was right-sized last quarter is now over- or under-sized; a baseline you committed to has grown.
• Data grows — logs, snapshots and storage accumulate cost over time.

Cost drift caught early is a small, cheap fix; discovered after months it is an entrenched, large cost. So the discipline is a regular cadence — typically monthly — of looking at cost deliberately, catching drift while it is small. This is the same "review regularly to catch problems early" principle the course applies to reliability (incident postmortems) and security — applied to cost.

What a monthly cost review covers

A practical monthly review, using the tools from this module, runs through a checklist:

1. Look at the trend. In Cost Explorer (the bill lesson), view total spend over the last few months. Is it growing? By how much, and is that expected (real growth) or drift (waste)?
2. Break it down and compare to last month. By service and by tag (environment, team, project — the tagging payoff). What grew? A line item that jumped is the thread to pull. "Why did data transfer double?", "Why is the dev account up 40%?"
3. Sweep for waste (the common-waste lesson) — a quick check for the usual culprits: unattached volumes, idle load balancers, unused Elastic IPs, old snapshots, environments that should be gone. Delete what is idle.
4. Check right-sizing (the rightsizing lesson) — review Compute Optimizer's recommendations; resize the worst over-provisioned resources; confirm non-production is scaling to zero out of hours.
5. Review commitments (the savings-plans lesson) — is your Savings Plan coverage still right for the current baseline? Any unused commitment, or baseline now uncovered that warrants more?
6. Check budgets and anomalies — did any Budget alert fire (the billing-setup lesson)? AWS Cost Anomaly Detection can flag unusual spend automatically; review anything it surfaced.

This takes an hour or so a month and reliably keeps the bill controlled — because it catches each kind of drift while it is still small. Assign an owner, put it on the calendar, and make it routine.

Make cost everyone's concern (FinOps)

The most effective cost management is cultural, not just a monthly review by one person. The practice often called FinOps is about making cost visible and owned across the engineering team:

• Attribute cost to teams via tags (the tagging payoff, again) — so each team can see their spend, not just a total. Cost that is attributed is cost that gets managed; an unattributable lump is nobody's problem.
• Make engineers cost-aware — surface the cost of what they build (a dashboard of spend by team/service), so cost is a design consideration, not a surprise finance raises later. This is the "cost as a first-class engineering concern" idea from the whole course, made organisational.
• Give cost an owner — someone (or the platform team) responsible for the review, the trends, and driving optimisation, so it does not fall through the cracks.

When teams see and own their costs, they optimise continuously — right-sizing their own workloads, cleaning up their own waste — rather than a central review chasing everyone. That distributed ownership, seeded by tagging and visibility, is what keeps cost controlled at scale.

The course, in one line

This lesson closes the cost module and the course, so a final synthesis. AWS DevOps in Practice has been about running production AWS well: structured accounts and least-privilege access; networks designed once and not unpicked; compute chosen honestly for the workload; EKS operated properly; Terraform structured for teams and environments; pipelines that deploy safely and roll back fast; observability that tells you what is happening; and — throughout — cost treated as a first-class concern, because in practice it always is. The cost review is the fitting end because it embodies the course's deepest theme: production infrastructure is not set up once and left — it is operated, continuously and deliberately, with attention to reliability, security and cost alike. Do that — read the bill, find the waste, right-size, commit wisely, review regularly, and make cost everyone's concern — and you run AWS the way it should be run: not just working, but working well, and affordably.

Check your work

Why review regularly: costs drift continuously (new resources, re-accumulating waste, shifting usage, growing data). Drift caught early = small fix; found late = entrenched. A monthly cadence catches it while small — the review-early principle applied to cost.

Monthly review checklist: (1) trend in Cost Explorer (growing? expected or drift?); (2) break down by service + tag, compare to last month (what jumped?); (3) sweep waste (unattached volumes, idle LBs, unused EIPs, old snapshots, dead environments); (4) check right-sizing (Compute Optimizer; non-prod scale-to-zero); (5) review commitments (Savings Plan coverage vs current baseline); (6) budgets + Cost Anomaly Detection. ~1 hour/month, owned and scheduled.

FinOps (cultural): attribute cost to teams via tags (attributed cost gets managed; a lump is nobody's problem); make engineers cost-aware (surface their spend — cost as a design input); give cost an owner. Distributed ownership keeps cost controlled at scale.

The course: running production AWS well — structured accounts/access, durable networks, honest compute, proper EKS, team-scale Terraform, safe pipelines with fast rollback, real observability, and cost as first-class throughout. Infrastructure is operated continuously and deliberately, not set up once.

Practice

1. Explain why cost optimisation must be ongoing, and what kinds of drift a regular review catches.
2. Write a monthly cost-review checklist from the module's lessons.
3. Explain how tagging enables both the review's breakdown and team-level cost ownership.
4. Explain the FinOps idea of making cost visible and owned, and why it beats a single central reviewer.
5. Describe how you'd investigate a month where total spend rose 25%.
6. Summarise, in your own words, what "running production AWS well" means across the course's modules.

Official documentation

• AWS — Cost Anomaly Detection — Automatically flagging unusual spend.
• AWS — Well-Architected cost optimisation pillar — Ongoing cost management practices.
• FinOps Foundation — What is FinOps? — Making cost a shared, visible engineering concern.

Congratulations — you have completed AWS DevOps in Practice, and the RizTech Academy DevOps track. Go and run something real, well.