FinOps: definition, method and 10 levers to cut your AWS bill
FinOps is a way of managing cloud spending that brings finance, engineering and business teams together; it is neither a tool nor a one-off savings plan. Here is its definition, its method, and ten practical levers to pull on AWS.
- According to the FinOps Foundation, FinOps is an operational framework and cultural practice that makes teams accountable for their technology spending.
- The approach follows three repeating phases: Inform (visibility and allocation), Optimize (rates and usage), Operate (continuous improvement).
- Without tagging and cost allocation, no optimisation lasts: that is the first workstream.
- The most direct AWS levers: rightsizing, switching off non-production environments, Savings Plans, Spot, Graviton, storage lifecycle and reducing NAT traffic.
- The native tools (Cost Explorer, Data Exports, Cost Optimization Hub, Compute Optimizer, Budgets, Cost Anomaly Detection) are enough to get started.
An AWS bill rarely jumps overnight. It drifts, month after month, driven by environments created for a test and never deleted, instances sized “just in case” and network traffic nobody watches. FinOps is the organised response to that drift. This article gives a simple definition, explains the method, then details ten practical levers on AWS. To see how this fits with the rest of what we do, see our AWS and Azure cloud consulting page.
FinOps: a simple definition
The FinOps Foundation defines FinOps as an operational framework and cultural practice that maximises the business value of technology, enables timely data-driven decision-making and creates financial accountability through collaboration between engineering, finance and business teams.
In other words, FinOps is not about spending as little as possible, but about spending with full knowledge of the facts. A higher bill driven by business growth is healthy; a higher bill driven by forgotten resources is not. FinOps lets you tell the difference.
Where FinOps comes from
The discipline has taken shape around the FinOps Foundation, which publishes the FinOps Framework: principles, roles (personas), practice domains and a maturity model. Six principles form its foundation:
- Teams need to collaborate.
- Business value drives technology decisions.
- Everyone takes ownership of their usage.
- FinOps data should be accessible, timely and accurate.
- FinOps should be enabled centrally.
- Take advantage of the variable cost model of the cloud.
Inform, Optimize, Operate: the three phases
The framework organises the approach into three phases that repeat continuously:
- Inform (visibility and allocation): examine cost, usage and efficiency data to understand who is spending what, and why.
- Optimize (rates and usage): identify improvement opportunities, both on rates (commitments, discounts) and on consumption (sizing, switching off, architecture).
- Operate (continuous improvement): implement the changes identified, build them into processes and measure their effects.
Who does FinOps in an SME or mid-sized company
A large enterprise may have a dedicated FinOps team. In an SME or mid-sized company, FinOps is more of a shared role: a technical lead who runs the tools and optimisations, a finance contact who tracks budget and forecasts, and business owners who validate the value of their applications’ spending. What matters is that one person is clearly responsible for driving it and that a regular meeting brings these three profiles together.
Why AWS bills get out of hand
Orphaned resources, oversizing, non-production running 24/7
Three causes come up almost every time:
- Orphaned resources: detached EBS volumes, old snapshots, unassociated Elastic IP addresses, load balancers with no targets, forgotten test environments.
- Oversizing: instances and databases chosen as a precaution and never resized after go-live.
- Non-production environments running all the time: development, testing and pre-production often run at night and at weekends when nobody is using them.
Data transfer and NAT gateways
Network transfer is the least readable line on the bill. A NAT gateway is billed per hour and per volume of data processed. If your private servers download large amounts of data from Amazon S3 or other AWS services through a NAT gateway, you pay for that traffic even though alternatives exist. Traffic between Availability Zones also adds costs that are often overlooked.
No tagging, no allocation
Without resource tagging, the bill is a single block: impossible to say what an application, a customer or a team costs. Nobody feels responsible, and every optimisation becomes a negotiation. That is why tagging is the first lever.
10 levers to cut your AWS bill
1. Tag and allocate costs
Define a small number of mandatory tags (application, environment, team or cost centre, owner) and apply them through Infrastructure as Code rather than by hand. An often-forgotten point: on AWS, tags must be activated as cost allocation tags in the Billing console before they appear in Cost Explorer and reports, and activation can take up to 24 hours. For what cannot be tagged, Cost Categories let you complete the allocation.
2. Rightsizing with Compute Optimizer
AWS Compute Optimizer analyses the configuration and utilisation metrics of your resources (the last 14 days by default, up to 93 days with a paid option) to recommend resizing or flag idle resources. It covers EC2, Auto Scaling groups, EBS, Lambda, ECS on Fargate, RDS and Aurora, among others. It has to be enabled explicitly. Note: without memory metrics being collected, EC2 recommendations are less reliable.
3. Scheduled shutdown of non-production environments
An environment used only during business hours does not need to run 168 hours a week. The Instance Scheduler on AWS solution automatically starts and stops EC2 and RDS instances according to a tag-based schedule; AWS gives the example of weekly usage reduced from 168 to 50 hours. The same logic applies to development container clusters, which can be scaled down to zero outside working hours.
4. Savings Plans and Reserved Instances
For stable consumption, commitments are the most direct pricing lever. Savings Plans commit you to an hourly spend amount for one or three years, with all, partial or no upfront payment; AWS advertises savings of up to 72% compared with On-Demand pricing. Compute Savings Plans apply to EC2 regardless of instance family, size, operating system or Region, as well as to Fargate and Lambda. Reserved Instances remain useful for services such as RDS, ElastiCache or OpenSearch. A rule of caution: only commit the share of consumption you are sure of, after rightsizing, not before.
5. Spot for fault-tolerant workloads
Spot Instances use spare EC2 capacity, with discounts advertised by AWS of up to 90% compared with On-Demand. The trade-off: AWS can reclaim the instance with a two-minute warning. They suit batch processing, continuous integration, distributed computing or stateless container nodes, not a production database.
6. Graviton
Graviton processors, designed by AWS on the Arm architecture, are presented by AWS as up to 20% cheaper than comparable x86 instances. Migration is often simple for interpreted or bytecode-compiled languages (Python, Java, Node.js) and for managed services (RDS, ElastiCache, OpenSearch). It requires more testing for compiled software or binary dependencies.
7. S3 storage and snapshot lifecycle
S3 lifecycle rules automatically move objects to cheaper storage classes (Standard-IA, Glacier) or delete them after a defined period. They also apply to objects already stored. Two points to watch: transitions are charged per request and some classes have a minimum storage duration. For unpredictable access patterns, the S3 Intelligent-Tiering class moves objects automatically. For EBS snapshots and backups, define an explicit retention policy rather than keeping everything.
8. Reduce network transfer and NAT gateway traffic
AWS recommends two approaches: place resources in the same Availability Zone as their NAT gateway (or provide one NAT gateway per zone), and create VPC endpoints for the most heavily used AWS services. Gateway endpoints for S3 and DynamoDB keep that traffic away from the NAT gateway. Analyse actual traffic flows first before changing the architecture.
9. Budgets, alerts and Cost Anomaly Detection
AWS Budgets alerts you when actual or forecast spending exceeds a threshold. AWS Cost Anomaly Detection uses machine learning to spot unusual spending, taking seasonality into account, and identifies the likely root cause by service, account, Region or usage type. The service runs roughly three times a day, with a delay of up to 24 hours. It does not replace human review, but it saves you from discovering a drift at the end of the month.
10. Continuous governance: monthly review and unit KPIs
The previous levers erode without a regular routine. A short monthly review with engineering, finance and business teams is often enough: how the bill is evolving, anomalies, pending recommendations, commitment coverage. Add unit metrics that link cost to activity (cost per order, per active user, per document processed): these are what tell you whether spending creates value.
FinOps tools: native AWS and third-party
To get started, the native tools cover the essentials:
| AWS tool | Role | FinOps phase |
|---|---|---|
| Cost Explorer | Explore the bill by service, account, tag, period | Inform |
| Data Exports (CUR 2.0, FOCUS) | Export detailed cost data to S3 for analysis | Inform |
| Cost Categories and cost allocation tags | Allocate costs to applications and teams | Inform |
| Cost Optimization Hub | Centralise and prioritise recommendations (rightsizing, idle resources, Savings Plans, Reserved Instances) | Optimize |
| Compute Optimizer | Sizing recommendations | Optimize |
| Budgets and Cost Anomaly Detection | Alert on overruns and anomalies | Operate |
AWS Data Exports can export costs in FOCUS format, the open cost data specification backed by the FinOps Foundation, which is useful if you compare several providers. Third-party tools become relevant in multi-cloud environments, when data volumes grow, or when you need fine-grained allocation of shared Kubernetes costs.
FinOps for generative AI
Generative AI services follow a different cost logic. On Amazon Bedrock, on-demand usage is billed by the number of input and output tokens, with rates specific to each model. Other modes exist: batch inference, which AWS advertises at a price 50% lower for eligible models, provisioned throughput and, for some models, prompt caching.
To allocate these costs, Bedrock lets you create application inference profiles to which you attach cost allocation tags, so each application or team sees its own consumption. The FinOps Foundation also has a dedicated workstream on FinOps for AI, focused on cost visibility across the whole lifecycle and on measuring the value delivered. Good habits: choose the smallest model that meets the need, limit the size of the context sent, cache what can be cached and track a cost per business task. We cover these topics in our approach to putting AI into production.
Where to start: a 30-day checklist
Week 1: make costs visible
- Enable Cost Explorer, Cost Optimization Hub and Compute Optimizer
- Set up a cost data export (Data Exports) to S3
- Create an overall budget and enable Cost Anomaly Detection
Week 2: allocate
- Define 4 to 5 mandatory tags and activate them as cost allocation tags
- Identify unallocated spending and its owners
Week 3: quick wins
- Delete orphaned resources (unused volumes, snapshots, IP addresses, load balancers)
- Schedule shutdown of non-production environments
- Add S3 and DynamoDB endpoints if NAT traffic is significant
Week 4: decide
- Apply the validated rightsizing recommendations
- Review Savings Plans coverage on the stabilised baseline
- Set up the monthly review and choose a first unit KPI
None of these levers guarantees a savings percentage set in advance: gains depend on your architecture and usage, and are measured on your own data.
Next step
If you would like an outside view of your AWS or Azure bill, we can analyse your cost data, prioritise the levers and put in place governance your teams can sustain, from Villeneuve-d’Ascq in the Lille metropolitan area (northern France) or remotely. Find out more about our FinOps and cloud cost optimisation services. And if you are preparing a migration, our article on cloud migration strategy and the 7 Rs will help you build cost control in from the design stage.
Frequently asked questions
What is FinOps?
FinOps is a discipline that aims to maximise the business value of cloud and technology spending. It relies on collaboration between engineering, finance and business teams, on cost data that is accessible and up to date, and on making each team accountable for its own consumption.
How do I estimate the cost of an AWS infrastructure?
For a new project, AWS Pricing Calculator lets you model the planned services and their volumes. For an existing infrastructure, the reference is your actual bill, analysed in Cost Explorer or through detailed cost exports. In both cases, include storage, data transfer and non-production environments, which are often forgotten.
Savings Plans or Reserved Instances?
Savings Plans commit you to an hourly spend amount for one or three years; Compute Savings Plans apply to EC2 regardless of instance family or Region, as well as to Fargate and Lambda. Reserved Instances remain relevant for some services such as RDS, ElastiCache or OpenSearch. The right choice depends on how stable your consumption is.
What is FinOps for AI?
It is the application of FinOps principles to AI services, which are often billed by the number of tokens processed. The aim is to make these costs visible, allocate them by application or team, and check that each use delivers measurable value.
Which FinOps certification should I take?
The FinOps Foundation’s entry-level certification is FinOps Certified Practitioner. It covers the framework, principles, personas and the Inform, Optimize and Operate phases. A more advanced Professional certification exists for experienced practitioners.
Sources
- FinOps Foundation: What is FinOps?
- FinOps Foundation: FinOps Principles
- FinOps Foundation: FinOps Phases
- FinOps Foundation: FinOps for AI
- AWS: Organizing and tracking costs using cost allocation tags
- AWS: What is AWS Compute Optimizer?
- AWS: Instance Scheduler on AWS
- AWS: What are Savings Plans?
- AWS: Amazon EC2 Spot Instances
- AWS: Spot Instance interruption notices
- AWS: AWS Graviton Processor
- AWS: Managing the lifecycle of objects (Amazon S3)
- AWS: Pricing for NAT gateways
- AWS: AWS Cost Anomaly Detection
- AWS: Cost Optimization Hub
- AWS: What is AWS Data Exports?
- AWS: Amazon Bedrock pricing
- AWS: Amazon Bedrock inference profiles