FinOps Principles for AWS Teams

What FinOps is (and isn’t)

FinOps is not about minimising cloud costs. It’s about ensuring the money you spend on cloud infrastructure delivers appropriate business value. A company spending $500,000/month on AWS with a 40% gross margin from cloud-dependent services is in a better position than a company spending $50,000/month with marginal revenue.

The FinOps Foundation (a Linux Foundation project) defines FinOps as “an operational framework and cultural practice which maximises the business value of cloud, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.”

Three principles underpin the FinOps Foundation’s framework:

1. Teams need to own their spending — the people deploying infrastructure should understand what it costs
2. Decisions are driven by business value — spending decisions should be justified by expected business impact
3. Everyone takes responsibility — finance, engineering, and business all play a role; it’s not just a finance problem or just an engineering problem

FinOps is distinct from simply running cost optimisation tasks (which are tactics). It’s the organisational structure and culture that makes those tactics happen consistently and at scale.

The three FinOps phases

The FinOps Foundation describes three phases that organisations move through, often cycling through them repeatedly as their cloud maturity grows.

Phase 1: Inform Before you can optimise, you need visibility. This means knowing what you’re spending, which team or application is responsible for each cost, and whether spend is tracking against expectations.

Key activities in the Inform phase:

• Enable Cost Explorer and set up tagging strategies
• Create per-team or per-project cost dashboards
• Establish cost allocation (which team’s budget pays for which resources)
• Set up anomaly detection and budget alerts

You cannot skip this phase. Teams that jump straight to optimisation without visibility don’t know if their optimisations worked, and they can’t sustain improvements because they can’t measure them.

Phase 2: Optimize Once you have visibility, you can make informed decisions to reduce waste and improve efficiency.

Key activities in the Optimize phase:

• Rightsizing based on actual utilisation (not guess-and-provision)
• Purchasing Reserved Instances or Savings Plans for stable baseline workloads
• Eliminating orphaned and idle resources
• Architectural changes (serverless vs always-on, Spot for batch workloads, storage tiering)

Phase 3: Operate Optimisation without sustainability is temporary. The Operate phase embeds cost awareness into how the team works day-to-day.

Key activities in the Operate phase:

• Cost considerations in architecture reviews and deployment decisions
• Automated cost controls (scheduled shutdowns, auto-scaling policies)
• Regular review cadences (monthly cost reviews, quarterly rightsizing reviews)
• Feedback loops between actual cost and engineering decisions

Most teams reach Phase 2 after a high bill scare, then regress to less rigorous practices once the immediate crisis passes. Phase 3 is where the savings become permanent.

Unit economics: the better measure

Raw dollar amounts are hard to evaluate in isolation. $100,000/month in AWS costs sounds alarming. $0.001 per user per month for a 100 million user service is cheap. They might be the same number.

Unit economics express costs in terms of business outcomes:

• Cost per active user per month — useful for consumer products
• Cost per transaction — relevant for payment processors, e-commerce
• Cost per GB processed — relevant for data pipelines and analytics
• Cost per build — relevant for CI/CD infrastructure
• Cost per API call — relevant for platforms and APIs

For a SaaS product with monthly subscription revenue, a useful unit is infrastructure cost as a percentage of revenue (also called infrastructure gross margin). At early stage, 30–40% infrastructure cost of revenue is common. At scale, 5–15% is a reasonable target for most SaaS businesses.

Example calculation for a SaaS product:

• Monthly AWS bill: $45,000
• Monthly active users: 50,000
• Monthly recurring revenue: $500,000

Unit economics:

• Cost per MAU: $45,000 / 50,000 = $0.90/user/month
• Infrastructure % of revenue: $45,000 / $500,000 = 9%

With these numbers, you can set meaningful targets. If the cost per MAU is growing while user count is stable, efficiency is declining. If it’s falling as users grow, the architecture is scaling well.

Unit economics are more useful than absolute dollar amounts for making infrastructure investment decisions. “Should we spend $20,000 to migrate to a more efficient architecture?” is answered differently depending on whether the current unit cost is $0.90/user (some headroom) or $3.60/user (urgent).

Showback and chargeback in AWS Organizations

In organisations with multiple teams or business units, allocating cloud costs to the teams that generated them creates accountability and better decision-making.

Showback means each team can see what their AWS spending is, but no actual transfer of funds occurs. This is the simpler first step. Teams become aware of their costs, which changes behaviour without the administrative overhead of internal billing.

Chargeback means the cloud costs are actually charged against each team’s budget or cost centre. This creates stronger incentives because over-spending directly impacts the team’s available budget for other things.

In AWS, both models require:

1. Consistent resource tagging — resources tagged with Team, Project, or CostCenter
2. Cost allocation tags activated in the Billing console (so tagged costs appear in Cost Explorer reports)
3. Regular cost reports per team

For organisations using AWS Organizations with multiple accounts, using a separate AWS account per team or application (rather than tagging within a shared account) is the cleanest cost allocation model. Each account has its own Cost Explorer view and separate billing. See AWS Organizations for how consolidated billing works.

Engineering team cost ownership

The most effective cost management happens when the people building systems understand what those systems cost to run. A few principles for building this culture:

Make costs visible where decisions are made — if engineers can see the cost impact of a deployment in the same workflow where they deploy, they make different decisions. Some teams add cost estimates to deployment pull requests, or show projected monthly cost in their internal infrastructure tooling.

Treat cost as a non-functional requirement — just as performance and reliability have acceptable thresholds, so should cost. “This service should process X events per second at Y% availability, within $Z/month” is a complete specification.

Create cost champions — designate someone in each team (not necessarily a full-time role) who owns the monthly cost review for that team’s services. Having a named owner means the review actually happens.

Reward efficiency — teams that reduce cost while maintaining or improving service levels should be recognised. If cost reduction is only noticed when it’s bad, engineers have no incentive to proactively improve it.

Tagging as the foundation of FinOps

Almost every FinOps capability — cost allocation, showback/chargeback, anomaly investigation, resource ownership — depends on resources being tagged consistently.

A minimum viable tagging strategy for FinOps:

• Team or Owner — who is responsible for this resource
• Environment — production, staging, dev, or sandbox
• Project or Application — which product or project does this support
• CostCenter — which business unit or cost centre should be billed

Tags are most effective when enforced at resource creation time. AWS Service Control Policies (SCPs) can deny the creation of resources that don’t include required tags. AWS Config’s required-tags rule can flag non-compliant resources.

Without consistent tagging, Cost Explorer shows you costs by service (EC2: $40,000/month) but can’t tell you which team or application generated that spend. The investigation becomes manual and time-consuming.

See resource tags for practical guidance on designing and enforcing a tagging strategy.