Field notes · FinOps & Cost Optimization
Building a system that catches cloud cost before it catches you
FinOps isn't a one-time cleanup — it's staying current on what each service can do, and building a system that notifies you and lets you act before a small overage becomes an awkward conversation. Here's the system I default to, in order.
FinOps requires staying current on each service in depth — the savings live in the details. It also requires a system: budgets, visibility, cadence, and people who know before a problem shows up on a bill.
01Budgets, first — before anything else
- The moment a new account exists, set up AWS Budgets before deploying anything into it. That's the first action, not an afterthought.
- Get alerts on expected usage, and raise the budget deliberately as usage grows — with management aligned that growing the budget is an expected, tracked decision, not a surprise.
02Know what's actually running
- Audit what's deployed — did something get left running after Sandbox or a test that should've been torn down?
- Use Resource Explorer to see every resource across the org, and Cost Explorer / the Billing console to see what's actually driving spend.
03Region & purchasing strategy
- If region isn't a hard constraint, research which regions are more cost-effective before you deploy — Oregon (us-west-2), for example, tends to run slightly cheaper than other AWS regions for the same services.
- For steady, long-running EC2 workloads, look at Reserved Instances. If you don't want to commit to one instance family, look at the more flexible alternatives (Savings Plans and similar) instead.
- For S3, know the tiers — Standard, Infrequent Access, Glacier — and set lifecycle policies to move data between them automatically as it ages.
- None of this works from a distance — it requires becoming genuinely fluent in each service to know what levers it actually has.
04Automate the obvious waste
Scheduled shutdowns via SSM
Use Systems Manager (SSM) Automation to stop non-production EC2 instances after hours and start them back up when needed — a simple scheduled cycle that removes the most common source of waste: instances nobody remembered were running overnight, over a weekend, or for a month.
05Anomaly detection & forecasting
- Enable Cost Anomaly Detection and cost forecasting alerts — sporadic spikes happen, and often aren't fully in your control, so you want to know the moment one starts.
06Cadence & communication
- Run a monthly cost review with the team — a short deck comparing this month to last, why costs moved, and what to do about it (absorb it, act on it, or adjust the budget).
- Send a summary email even when not everyone can attend, so the whole team stays aware and can flag or escalate before it becomes a bigger issue.
- Loop in the right people before a budget is exceeded, not after — it's a much easier conversation than explaining after the fact why the team is the center of attention for a cost overrun.
- Spread cloud cost literacy across the org. Most cost waste isn't malicious — it's someone who didn't know an EC2 instance left running all weekend costs real money. That knowledge gap is a cloud engineer's job to close.
07Tooling & support
- Use the hyperscaler's native cost management tools as the baseline, and evaluate third-party cost platforms (CloudHealth and its successors, among others) if you need more.
- Keep an eye on built-in savings recommendations — Trusted Advisor and Cost Explorer both surface them, and they're easy to miss if no one's watching.
- Get a paid AWS support tier (Business or Enterprise) — sometimes the fastest path to a fix is an expert on a call. One gotcha: support subscriptions are per account, so you can't lean on a subscription tied to a different account than the one you're troubleshooting.
Budgets before deployment, a real-time inventory of what's running, region and purchasing decisions backed by research, scheduled shutdowns for the obvious waste, anomaly detection for the rest, a monthly cadence that keeps everyone informed before costs escalate, and a support tier for when you need an expert on the line.
FinOps and cost optimization takes a lot of ongoing knowledge and research — staying current, and building a system where you actually get notified and can take action, instead of finding out weeks later on a bill. This is the order I've learned to do it in.
First, always the budget. The moment you create an account, before you deploy a single resource into it, set up a budget. That's what gets you alerted on your expected usage of services in that account. And you increase that budget as you see fit as usage grows — with management already on the same page that going over, or raising the budget, is an expected part of the account growing, not a surprise to react to.
Know what you're actually running
Second, look at everything that's actually deployed. Do you really need all of it? Did something get left running after a sandbox test that should've been torn down? Resource Explorer is what I use to see every resource across accounts, and Cost Explorer and the Billing console tell you what's actually driving the number.
Third, before you deploy anything, figure out which regions are more cost-effective, if region isn't something you're locked into. Oregon, for instance, tends to run a little cheaper than other AWS regions for the same services — so do your own research on where it makes sense to store your data and run your compute.
Automate the obvious waste
One of the most effective things I've set up is shutting EC2 instances down after work hours, using SSM Manager — it runs on a cycle, turns the instance off, and turns it back on when it's needed again. It's a small thing, but it removes the most common source of waste: instances left running all night, all weekend, or all month because nobody remembered.
Watching for what you can't predict
You'll also get sporadic cost increases that aren't fully in your control, so I enable anomaly detection and forecasting alerts across the board — you want to know the moment something moves, not after it's already compounded for a few weeks.
Keeping everyone in the loop
What's worked best on top of all that is a monthly cadence with the team — a short deck comparing this month to last, walking through the increases, and writing down next steps: do we act on this, do we adjust the budget, do we leave it. Even if someone can't make the meeting, send a summary email, so everyone stays aware and can escalate if it gets to a high point.
A lot of cost waste isn't anyone acting badly — it's someone who doesn't know the nuances of the cloud, like leaving an EC2 instance up all weekend without realizing what it costs. Spreading that knowledge so people can make good decisions themselves is part of the job, not separate from it.
Tools and support
Lean on the hyperscaler's own cost management tools first, and keep a lookout for third-party options — CloudHealth was one a lot of people used before it got acquired, and there are others in the market now. Keep an eye on the savings recommendations these tools surface; it's your responsibility as a cloud engineer to catch them, because it's so easy to spend on cloud and just as easy to miss where you're overspending.
And I'd genuinely recommend getting a real support tier — Business or Enterprise. Sometimes you just want an expert on a call to help troubleshoot, in almost any scenario. One thing to know going in: support subscriptions are per account, so you can't get help on an account that isn't covered by the subscription, even if a sibling account in the same org has one.