The 3 steps to building a FinOps culture inside a DevOps team

Step 1: Awareness — Build visibility and create urgency

Understand where you stand before you optimize

The first step is getting a factual view of your current cloud spend. Without it, teams try to optimize in the dark and often pour effort into changes that have no real impact.

The goal here isn’t to cut costs immediately, but to answer three foundational questions:

1. Where is our money going? Which AWS services make up 80% of the bill?
2. Who is spending it? Which teams, projects, or environments are driving consumption?
3. Why are we spending this way? Are the costs tied to intentional choices or hidden inefficiencies?

Concrete actions

• Put a minimal but strict tagging schema in place: environment (prod/staging/dev), team, project, etc.
• Audit untagged resources and build a remediation plan
• Activate Cost Allocation Tags for tag-based reporting
• Establish a baseline of costs per team and per environment

Quick wins that build early momentum

Quick wins matter at this stage. They show the value of FinOps before teams commit to deeper architectural work. The best ones never require downtime, can be done in hours or days, and deliver instant impact.

Quick win #1: Clean up orphaned resources

A standard audit almost always reveals forgotten resources eating the budget silently. One company found 847 EBS volumes left behind by old instances, costing them 2,100 dollars a month. Other classics include:

• RDS snapshots kept forever
• Unattached Elastic IPs
• Load balancers serving nothing
• Legacy AMIs and their snapshots

Quick win #2: Reserved Instances and Savings Plans

For workloads running more than 60% of the time, Reserved Instances and Savings Plans deliver 30 to 72% reductions. A quick look at the last three months of usage identifies obvious candidates:

• EC2 instances running continuously
• Production RDS databases
• Fargate and Lambda services with steady load

Teams usually begin with the simplest wins, like always-on instances,  and expand from there. Compute Savings Plans typically offer more flexibility with similar savings.

Step 2: Tooling — Automate governance and monitoring

Turn manual policies into automatic guardrails

Step 2 is where ad-hoc practices from Step 1 turn into sustainable, automated processes. The goal is to prevent waste before it happens instead of cleaning it up afterward.

Smart, segmented budget alerts

Budget alerts move you from reactive detection to proactive action. The most effective setup includes alerts at 75, 90, and 100% of the monthly budget, segmented by:

• Environment (prod, staging, dev)
• Team or business unit
• Major AWS services (EC2, RDS, Lambda)

A spike in dev often means forgotten tests or leftover resources. A spike in staging may indicate unpaused load tests. A spike in production requires immediate investigation.

Data-driven right-sizing

Right-sizing typically unlocks the largest savings, but only with enough usage data. Step 2 is the ideal time.

Right-sizing approach

1. Collect 2–4 weeks of metrics: CPU, memory, IOPS, network
2. Identify candidates: resources averaging under 40% utilization
3. Model the potential savings
4. Test in non-production
5. Roll out gradually to production

Teams often discover 40–60% overprovisioning. For example, an m5.4xlarge running at 25% can safely move to an m5.2xlarge and cut costs in half.

Important note: excessive right-sizing can create bottlenecks that cost more long-term. An underpowered database eventually slows downstream apps.

Lambda and serverless optimization

Serverless workloads hide major optimization opportunities.

Memory right-sizing for Lambda:

Because AWS charges by millisecond and memory, more memory can actually cost less if it shortens execution time.

A Lambda running 3 seconds at 512MB may cost more than the same function running 1.2 seconds at 1024MB.

AWS Lambda Power Tuning tests multiple configurations automatically. One organization cut Lambda spending by 85% (38,000 dollars a year) using this alone.

Cold starts and provisioned concurrency:

Cold starts create latency and cost. Provisioned concurrency eliminates them,  but at a high price.

The right strategy depends on traffic:

• Sporadic traffic: accept the occasional cold start
• Consistent traffic: ECS Fargate often beats Lambda with provisioned concurrency
• Predictable peaks: schedule provisioned concurrency only when needed

Step 3: Autonomy — Shift financial ownership to the teams

Move FinOps from a centralized role to a shared practice

FinOps maturity happens when each team owns its costs and participates in continuous optimization. This requires both tooling and a cultural shift.

Real-time team dashboards

Every team should have a dashboard showing:

• Month-to-date spend vs budget vs previous month
• Breakdowns by AWS service
• The team’s top 10 most expensive resources
• 3–6-month trends
• Anomaly detection alerts

Real-time visibility creates instant feedback loops. A developer launching a new workload sees the financial impact within hours…not weeks.

Efficiency metrics instead of fixed budgets

Mature organizations move beyond rigid budgets toward efficiency metrics that align incentives properly:

• Cost per active user
• Cost per transaction
• Cost per API request
• Cost per dollar of revenue

A team that drops cost per transaction from 0.015 to 0.009 dollars deserves recognition, even if total spend increases due to higher usage.

Architecture reviews with FinOps questions baked in

Architectural decisions have long-term financial consequences. Including FinOps questions early prevents expensive surprises.

Key questions include:

• What’s the estimated monthly cost of this design?
• Have we compared cheaper alternatives?
• Does the cost scale linearly or exponentially with usage?
• Can non-prod environments run on smaller resources?
• Do we have rate limits to prevent runaway costs?

For AI/ML architectures, also ask:

• Are we choosing the right model for cost/performance?
• Are we caching frequent responses?
• Are we trimming prompt history to avoid conversation creep?
• Are there per-user limits to prevent overuse?

FinOps Champions: distribute expertise

Instead of relying on a single FinOps team that becomes a bottleneck, mature organizations appoint FinOps Champions inside each team. They:

• Receive deeper FinOps training
• Join a cross-team practice community
• Serve as the first point of contact for cost questions
• Represent their team in company-wide optimization initiatives

This distributed model accelerates adoption and avoids silos.

Conclusion: The path to FinOps maturity

Building a FinOps culture is a three-step journey. Awareness provides visibility and early momentum. Tooling turns scattered gains into automated safeguards. Autonomy embeds financial responsibility directly in the teams and drives continuous improvement.

Organizations that follow this structured roadmap consistently see 20 to 40% cumulative savings while increasing innovation velocity. More importantly, they stop treating cloud cost management as a reactive constraint and turn it into a competitive advantage.

The journey starts with an honest assessment of your maturity. Are you still reacting to overruns after they happen? Have you established baseline visibility but lack automation? Or are you ready to distribute financial ownership across teams?

At Unicorne, we support organizations at every stage with technical expertise, specialized tools like Stable, and pragmatic approaches adapted to your context. Because FinOps maturity isn’t built alone; it’s built with the right people and the right practices.