Almost every organization that moves to the cloud goes through the same arc. Year one: excitement and speed. Year two: a bill that makes finance ask pointed questions. Then comes a frantic cost-cutting sprint, a one-time cleanup, and — six months later — the bill creeps right back up.
The cleanup isn't the problem. The lack of a routine is. FinOps, at its core, is the practice of making cost a normal engineering input rather than an after-the-fact surprise. These ten habits are where most teams get the biggest, most durable returns.
Habit 1: Tag everything, and enforce it
You can't optimize what you can't attribute. A consistent tagging scheme — at minimum team, environment, and product — turns one giant bill into line items with owners. Activate those keys as cost allocation tags in the Billing console so they show up in cost reports, and enforce them with tag policies or infrastructure-as-code defaults so new resources can't skip them.
Habit 2: Make spend visible to the people who cause it
A monthly PDF to finance changes nothing. A weekly cost view in the team's own channel, broken down by service, does. Engineers make better decisions when the bill is a number they see regularly, not a surprise they hear about.
Habit 3: Set budgets and anomaly alerts
AWS Budgets can notify you when forecast spend crosses a threshold, and AWS Cost Anomaly Detection flags unusual spikes by service or tag. Together they catch the runaway test environment or misconfigured data job within days instead of at month end.
# List your current budgets
aws budgets describe-budgets --account-id 123456789012 \
--query 'Budgets[].{Name:BudgetName,Limit:BudgetLimit.Amount}'Habit 4: Right-size before you commit
The most common waste is simply overprovisioned compute. Look at actual CPU and memory utilization over a few weeks and move oversized instances down a size. AWS Compute Optimizer can generate right-sizing recommendations from your usage data, which is a good starting list. Do this before buying any commitments, so you don't lock in capacity you didn't need.
Habit 5: Turn off what nobody's using
Non-production environments often run around the clock while being used for a fraction of the week. Schedule dev and test environments to stop outside working hours. Hunt for the quiet leftovers too: unattached EBS volumes, idle load balancers, old snapshots, and forgotten Elastic IPs that are billed while unused.
Habit 6: Match commitments to steady usage
For workloads that run steadily, Savings Plans and Reserved Instances trade a usage commitment for a meaningful discount compared with on-demand pricing. The discipline is to commit only to your reliable baseline and leave spiky or uncertain demand on-demand. Review commitment coverage and utilization regularly rather than buying once and forgetting.
Habit 7: Use Spot capacity where interruption is fine
Spot Instances offer spare capacity at a steep discount, with the catch that AWS can reclaim it. That's fine for stateless, fault-tolerant, or batch work — build jobs, data processing, some container workloads — and not fine for a single database. Design for interruption and Spot becomes a cheap default for the right workloads.
Habit 8: Pick storage tiers on purpose
Data you rarely read shouldn't sit in the most expensive tier. S3 lifecycle rules can move objects to cheaper storage classes automatically as they age, and S3 Intelligent-Tiering can do it based on access patterns when you can't predict them.
{
"Rules": [{
"ID": "archive-old-logs",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 365 }
}]
}Check retrieval costs and minimum storage durations for each class before choosing; the cheapest tier to store isn't always the cheapest to use.
Habit 9: Watch the hidden line items
Data transfer, NAT gateway processing, cross-AZ traffic, and verbose logging are the "death by a thousand cuts" charges that don't show up in anyone's mental model of the architecture. If a bill line surprises you, trace the traffic path. Often a small architectural change — a VPC endpoint for S3, for instance — removes a surprisingly large recurring charge.
Habit 10: Review monthly, with the owners in the room
Fifteen minutes a month, per team: top three cost drivers, what changed, one action. The point isn't blame; it's to keep cost in the same conversation as latency and reliability. This is the habit that makes all the other nine stick.
What not to do
- Don't optimize by decree. Mandating "cut 20%" without context produces cuts to the wrong things — usually reliability.
- Don't treat cost as the only metric. The cheapest architecture that misses its availability target isn't cheaper.
- Don't wait for a crisis. The cheapest time to build the habit is before the bill becomes a problem.
Build the practice, not just the savings
Cost optimization is partly technical and partly cultural, and the culture part is the harder one. Our Cloud Cost Optimization and FinOps course works through real bills and teaches teams to run this loop themselves. If your costs are heading up because of migration decisions made early on, our post on the real cost of skipping a cloud migration strategy is a good companion read.