FinOps dashboards make everything look important. Very few things actually are. If you rank your AWS bill by service, the top three or four almost always account for 70% of the number. Fix those; the rest is noise.
What actually shows up in the top three
For most enterprise AWS estates I've seen:
- EC2 — compute for the primary workload. 30–50% of the bill.
- RDS / Aurora — production and non-prod databases. 15–25%.
- S3 — storage, mostly backups and logs. 5–15%.
- Data transfer — inter-AZ, inter-region, egress. 3–10%.
Everything else combined — Lambda, ECS, CloudWatch, SNS, SES, Route53, Secrets Manager — is under 10%. Which means every hour spent optimizing "Lambda cost" is an hour not spent on EC2.
The interventions that actually move numbers
Savings Plans / Reserved Instances. For steady-state EC2, this is a 30-70% cost cut. It is the single largest lever available. The reason not to buy them is if you're actively rearchitecting the workload. Almost every other reason is procrastination.
Rightsizing. CloudWatch's own recommendations catch a lot of over-provisioned EC2. Compute Optimizer catches more. The uncomfortable part is engaging with the application team about why their instance is at 8% CPU average and they say they need the current size "just in case."
S3 lifecycle policies. Most orgs have S3 buckets accumulating for years with no lifecycle. Adding transitions to Infrequent Access at 30 days and Glacier Deep Archive at 180 days routinely saves 40-60% on the S3 line item. Ten-minute change; large impact.
Inter-AZ data transfer. Chatty microservices distributed across 3 AZs generate real costs. Consolidating services onto fewer AZs (giving up some HA) or into VPC endpoints (for AWS services) cuts this. It's often 10-20% of the bill in poorly-designed estates.
CloudWatch log group cleanup. Log groups without retention policies grow forever. Adding a 90-day retention to log groups older than a year saves surprising amounts, and nobody actually needs the logs from 2019.
The interventions that don't move numbers
- Lambda function memory tuning. Fine for a Lambda-heavy workload. Almost never material for an EC2-heavy one.
- Spot instances for stateful workloads. Adds operational fragility for cost savings on a line item that isn't dominant.
- Moving to Graviton for non-optimized workloads. Real savings for optimized workloads. For your legacy Java app that wasn't built with ARM in mind, the migration cost exceeds the savings for a long time.
- Cost anomaly alerts on every service. Alert fatigue. Alert only on services that meaningfully move the total.
The organizational side
FinOps is not primarily a technology problem. It is a "who owns this cost line?" problem. At Total Energy the biggest FinOps win was not any single technical change — it was implementing tag-based cost allocation so that each business unit saw its own AWS bill instead of an aggregate. The month after that landed, three teams shut down environments they'd forgotten they were running.
Cost allocation tags that work:
cost-center(mandatory, enforced by SCP)environment(prod/stage/dev)owner-team(a Slack channel name works)application(business-facing name)
Enforced via SCP means: an EC2 instance without a cost-center tag fails to launch. Not "gets flagged." Fails.
The FinOps rhythm that works
Monthly cadence, not real-time. Weekly reviews are noise. Quarterly is too late.
- Week 1 of month: cost report goes to each business unit for the prior month.
- Week 2: finance + FinOps team review outliers.
- Week 3: business unit responds with actions or acceptances.
- Week 4: slate for next month's changes.
This is boring. Boring is what makes it stick.
Bottom line
You cannot optimize what you don't measure and you don't own. Get tag-based allocation working first, buy Savings Plans on steady-state second, rightsize third, and everything else is a rounding error. The dashboards will tell you dozens of things need attention. Three or four of them actually do.