If your AWS bill keeps climbing while your engineers shrug and say "that's just what the cloud costs," the fix is a FinOps framework: a repeatable practice that gives engineering, finance, and leadership a shared view of cloud spend and the authority to act on it. The fastest wins come from killing idle resources, right-sizing compute, and committing to discounts you are already eligible for. The durable wins come from making cost a first-class engineering metric. This guide walks through a step-by-step approach you can start this week.
What a FinOps framework actually is
FinOps is not a tool you buy. It is an operating model that brings financial accountability to the variable spending of the cloud. The FinOps Foundation defines it as a cultural practice with three iterative phases: Inform, Optimize, and Operate.
- Inform: Get visibility. Allocate every dollar to a team, product, or feature.
- Optimize: Take action. Right-size, schedule, and commit to discounts.
- Operate: Make it continuous. Build cost into your engineering workflow so savings do not regress.
The mistake most teams make is jumping straight to Optimize. They turn off a few instances, save money for a quarter, then watch spend creep back because nobody owns the number. The framework matters because it makes the savings stick.
Step 1: Make spend visible with tagging and allocation
You cannot cut what you cannot see. Before any optimization, you need to allocate cost to owners. In AWS, that starts with a consistent tagging strategy enforced across accounts.
Define a small set of mandatory tags and enforce them:
team = payments
environment = prod | staging | dev
service = checkout-api
cost-center = CC-4412
Enforce tags at creation time rather than chasing untagged resources later. AWS Organizations Tag Policies plus Service Control Policies (SCPs) let you reject non-compliant resources:
{
"tags": {
"team": {
"tag_key": { "@@assign": "team" },
"enforced_for": { "@@assign": ["ec2:instance", "rds:db"] }
}
}
}
Then activate those tags as cost allocation tags in the Billing console so they appear in Cost Explorer and the Cost and Usage Report (CUR). The CUR is the source of truth. Query it directly with Athena when Cost Explorer's UI is too coarse:
SELECT
resource_tags_user_team AS team,
line_item_product_code AS service,
SUM(line_item_unblended_cost) AS cost
FROM cur_table
WHERE billing_period = '2024-10'
GROUP BY 1, 2
ORDER BY cost DESC
LIMIT 25;
By the end of this step you should be able to answer one question for any stakeholder: "What did your team spend last month, and on what?" If you cannot, every later step is guesswork.
Step 2: Kill the obvious waste
With visibility in place, the first cuts are usually the least controversial because they touch nothing anyone is actually using.
- Unattached EBS volumes and old snapshots. Storage from terminated instances often lingers for months. Find unattached volumes and stale snapshots and delete them after a review window.
- Idle load balancers and unused Elastic IPs. AWS charges for Elastic IPs that are not attached to a running instance, and for idle load balancers.
- Orphaned NAT Gateways. These bill hourly plus per-GB processed. Consolidate them where routing allows.
- Forgotten dev and staging environments. Non-production resources rarely need to run nights and weekends.
A simple scheduled stop/start for non-prod can remove roughly two-thirds of runtime for environments that only need business hours. A Lambda on an EventBridge schedule handles this cleanly:
import boto3
def handler(event, context):
ec2 = boto3.client("ec2")
filters = [
{"Name": "tag:environment", "Values": ["dev", "staging"]},
{"Name": "tag:auto-stop", "Values": ["true"]},
]
instances = ec2.describe_instances(Filters=filters)
ids = [
i["InstanceId"]
for r in instances["Reservations"]
for i in r["Instances"]
]
if ids:
ec2.stop_instances(InstanceIds=ids)
These cuts are real money, but they are also a trust-builder. They show engineering that FinOps removes waste, not capacity.
Step 3: Right-size compute and storage
Right-sizing is where the largest recurring savings usually live, and where you need data to avoid breaking things.
- Use AWS Compute Optimizer for EC2, EBS, Lambda, and ECS recommendations based on CloudWatch utilization. Treat its output as a candidate list, not a command.
- Right-size on real percentiles, not averages. A box that sits at 8% average CPU but spikes to 90% at month-end close is not a right-sizing candidate without burst headroom.
- Move to current-generation and Graviton instances. ARM-based Graviton instances often deliver better price-performance for many workloads. Benchmark your own services before migrating.
- Tier your storage. Move infrequently accessed S3 data to Infrequent Access or Glacier classes. S3 Intelligent-Tiering automates this for unpredictable access patterns.
For databases, look at Aurora and RDS instances running oversized classes from a long-forgotten capacity guess. Storage auto-scaling and read replicas can often replace a single oversized primary.
If you want help building a right-sizing program that engineering will actually trust, our cloud and infrastructure capabilities cover the assessment and rollout work end to end.
Step 4: Commit to discounts you already qualify for
Once your baseline usage is stable and right-sized, commit to it. AWS offers two main mechanisms:
- Savings Plans: Commit to a consistent amount of compute spend per hour (e.g., $10/hour) for one or three years in exchange for lower rates. Compute Savings Plans are the most flexible because they apply across EC2, Fargate, and Lambda.
- Reserved Instances (RIs): Best for steady-state RDS, ElastiCache, and similar services that Savings Plans do not cover.
A practical commitment strategy:
- Right-size first. Committing to oversized usage locks in waste.
- Cover your stable baseline, not your peaks. Aim to commit to the portion of usage that runs 24/7/365.
- Start with 1-year, No Upfront terms to limit risk while you build confidence in your forecast.
- Use on-demand and Spot for the variable layer on top.
For batch, CI, and fault-tolerant workloads, Spot Instances can reduce costs substantially compared to on-demand. Combine Spot with Savings Plans on the always-on layer and you cover both stability and burst economically.
Step 5: Operate continuously so savings do not regress
This is the step that separates a one-time cleanup from a FinOps framework. Without it, your bill is back to where it started within two quarters.
Set budgets and anomaly alerts
aws budgets create-budget \
--account-id 123456789012 \
--budget '{
"BudgetName": "payments-prod-monthly",
"BudgetLimit": {"Amount": "40000", "Unit": "USD"},
"TimeUnit": "MONTHLY",
"BudgetType": "COST"
}'
Enable AWS Cost Anomaly Detection to catch unexpected spikes within a day or two rather than at month-end invoicing.
Make cost a review metric
- Put a monthly cost-per-team and cost-per-customer figure into engineering reviews.
- Track unit economics: cost per thousand requests, cost per active user, cost per transaction. Absolute spend can rise while unit cost falls, which is healthy growth.
- Assign a named owner for cloud cost. FinOps fails without accountability.
Shift cost left into engineering
Add cost estimates to infrastructure pull requests using a tool like Infracost so engineers see the dollar impact of a change before it merges. Cost feedback at review time is far cheaper than a surprise at invoice time.
Different sectors carry different cost drivers. Data-heavy regulated workloads behave differently from spiky consumer traffic, and our work across industries shapes how we tune these controls for each context.
A realistic 90-day rollout
| Phase | Weeks | Focus |
|---|---|---|
| Inform | 1-3 | Tagging, allocation, CUR + Athena visibility |
| Optimize (quick wins) | 3-6 | Idle resources, scheduling, storage tiers |
| Optimize (structural) | 6-10 | Right-sizing, Graviton, Savings Plans |
| Operate | 10-12 | Budgets, anomaly alerts, review cadence, ownership |
Resist the urge to do everything at once. Each phase builds the trust and data the next one needs.
The bottom line
Cutting AWS costs is not about a single heroic cleanup. It is about installing a FinOps framework that makes spending visible, removes waste, commits to the right discounts, and keeps cost in front of the people who create it. Do that, and AWS cost optimization stops being a quarterly fire drill and becomes a normal part of how your team ships.
FAQ
How quickly will we see savings from a FinOps framework?
Quick wins like deleting unattached storage, scheduling non-production environments, and removing idle resources typically show up on the next invoice. Structural savings from right-sizing and Savings Plans take a few weeks to validate but recur every month afterward.
Do we need a dedicated FinOps team to start?
No. Most organizations begin with a single named owner who coordinates engineering and finance. A dedicated team or center of excellence makes sense later as cloud spend and the number of teams grow.
Will right-sizing risk breaking production workloads?
Only if you size on averages instead of real utilization percentiles and traffic patterns. Use Compute Optimizer and CloudWatch data, account for peak and burst behavior, and roll changes out to non-production first. Done carefully, right-sizing is low risk.
Should we buy Savings Plans or Reserved Instances?
Right-size first, then commit. Compute Savings Plans are the most flexible option and cover EC2, Fargate, and Lambda. Use Reserved Instances for services Savings Plans do not cover, such as RDS and ElastiCache. Start with shorter, no-upfront terms to limit forecast risk.
How do we keep costs from creeping back up?
Operate continuously. Set budgets and anomaly alerts, review cost-per-team and unit-economics metrics in engineering reviews, assign clear ownership, and shift cost visibility into pull requests so engineers see the impact before they ship.
Production-grade cloud, software, and engineering teams for scaling companies.
