Since launching Infracost in 2021, we’ve been pulled by engineers who all want to Shift FinOps Left. Today, we’re taking a major leap forward. We’re announcing five powerful new features designed to help engineers proactively find and fix cloud cost issues, including bringing rightsizing recommendations into the workflow. These features lay the foundation for a new FinOps engineering workflow—one where FinOps teams set priorities and engineers take action. From campaign-driven priorities to automatic pull requests with fixes, this is how FinOps becomes a daily habit across your org.

1. Drive Results with Campaigns

FinOps is everyone’s job. Infrastructure-as-code and self-service provisioning have decentralized cloud ownership—giving engineers autonomy, but also making it harder for FinOps teams to drive action at scale.

FinOps initiatives like tagging or adopting Graviton require coordination across many teams and code repos. The challenge? Communicating what matters, and when, without adding noise to engineers’ workflows (engineers hate noise).

If I tell an engineer to fix 20 things, they’ll say “Non, merci”! But if I say here are the 3 most important things you should fix, we get more action. Once those are done, I then pick the next 3 most important things. So engineers are always working on the most important things.

— Head of Cloud Engineering at an Enterprise Customer

Today, we’re excited to launch Campaigns, a new way to focus engineering efforts on the FinOps policies that matter most to your business. Campaigns follow the S.M.A.R.T. framework, helping you set Specific, Measurable, Achievable, Relevant, and Time-bound goals.

This ensures your FinOps initiatives are clear, focused, and trackable. Here’s how it works:

1. Start with data: Infracost shows you which policies are failing the most across your code repos.
2. Prioritize with context: FinOps and engineering leaders choose the most relevant policies to focus on. For example, a Graviton campaign starting with just Lambda and ECS is high-impact and easier to implement.
3. Set a clear goal: Define what success looks like, e.g., “Fix 80% of selected issues within 60 days.” Some issues cannot be fixed, for example, an app not compatible with Graviton, so Campaigns encourage you to choose achievable goals.

As shown in the following screenshot, once a campaign starts, Infracost tracks two key metrics:

1. Percentage of issues fixed: see how close you reach your campaign goal.
2. Percentage of new issues prevented: measure how well engineers follow the policy going forward.

Campaigns empower teams to focus, act, and make measurable progress—without adding process overhead.

2. AutoFix: Generate Pull Requests to Fix Issues

FinOps teams find Jira tickets and planning meetings slow and frustrating—they often get deprioritized and delayed. Security teams learned this lesson years ago: if you want engineers to take action, lower the effort by making fixes part of the developer workflow—through pull requests.

When we share recommendations with end users, 99% of the time, we’re asked why we can’t automate the remediation PR generation. The challenge is linking resources to Infra-as-Code files in the GitHub repo.

— Sr Staff Engineer at a Fortune 100 Customer

That’s why we’re excited to introduce Infracost AutoFix. With AutoFix, you can enable pull request generation at the Campaign level—helping FinOps teams measure and speed up the mean-time-to-remediation, just like modern security teams do today.

Here’s how it works:

• Infracost automatically opens PRs with actionable code fixes, intelligently paced so engineers aren’t overwhelmed.
• It combines context from our static analysis engine (the Infracost CLI), and customer-specific policies and price books to generate actionable code fixes, using AI to power the code generation.
• Our static analysis engine validates each fix, ensuring it solves the issue without introducing new costs or breaking changes.

This keeps the blast radius small and trust high—engineers can review, customize and deploy fixes without leaving their familiar workflow. AutoFix is currently in private beta for GitHub, with support for Azure Repos and GitLab on the roadmap.

3. Cloud Rightsizing: From Insights to Action

Enterprises don’t need more rightsizing insights—they already have those. What they’re missing is action. Rightsizing recommendations live in the cloud, but implementing them means updating infrastructure code scattered across hundreds of repos and teams. That’s the hard part. It’s another example of decentralized action that’s too slow and manual today. That’s why customers ask us to go beyond infra-as-code and help close the loop—from insight to impact.

When I’m writing code, I don’t look at AWS Trusted Advisor. And when I’m looking at Trusted Advisor, I’m not writing code.

— Sr Software Engineer at an Enterprise Customer

That gap is what we’re closing. This is a technically complex problem: cloud recommendations (like AWS Compute Optimizer) and infrastructure-as-code are completely different data sources. Bridging the two requires mapping algorithms that connect live cloud resources back to the specific lines of Terraform that provisioned them.

Infracost turns rightsizing into scalable, trackable policies. FinOps teams can use Campaigns to define goals, e.g. “optimize 80% of EC2 rightsizing opportunities this quarter.”

Infracost now fetches AWS Compute Optimizer recommendations, and AutoFix opens pull requests with the suggested changes—directly in engineers’ workflows. Engineers can review, tweak, or dismiss changes with a reason, enabling a two-way feedback loop between FinOps and engineering. Rightsizing is currently in private beta for AWS, with Azure support on the roadmap.

4. Custom Policy Builder

Large enterprises often need custom FinOps policies tailored to their cloud strategy. Recent examples from our customers include:

• Enforcing preferred instance families for prod vs non-prod environments to maximize Savings Plan discounts.
• Requiring specific object storage tiers to take advantage of negotiated pricing.
• Setting limits on OpenAI Tokens-Per-Minute to control spend.

Some teams try to implement these with tools like Open Policy Agent (OPA), AWS Service Control Policies (SCP), or Azure Policy—but they hit major challenges:

• Too late in the process: Engineers only see errors after a deployment fails. They’re frustrated by vague errors, forced to open another pull request, wait for another code review, and deploy again; which wastes their time.
• No way to dismiss or snooze: As described in the next section, these tools don’t offer a developer-friendly way to provide feedback and dismiss issues.
• No visibility: These tools don’t show all current issues across repo main branches, so tracking progress over time and seeing a burndown chart is difficult.
• Too complex: Writing policies requires deep expertise and CI/CD changes—something most FinOps teams can’t do on their own.

We have around 70 OPA policies already, OPA is hard to write, and I have no visibility on if it’s working, pass-rate/fail-rate, burn down chart etc.

— Director of Cloud Engineering, Cybersecurity & Compliance at one of our customers

Today we’re excited to announce our Custom Policy Builder—a simple, powerful way to define FinOps policies that solves the above challenges. The following screenshot shows how easy it is to create rules around services and attributes. Custom policies can also be used in Campaigns with AutoFix, so you define the rules and Infracost drives engineering action!

5. Enforcing FinOps Policies in a Developer-Friendly Way

About a year ago, I posted a simple question on LinkedIn:

Why do FinOps folks tend to shy away from stricter policies compared to their security counterparts?

Fast forward to today, we now regularly see Infracost customers confidently switch policies into enforcement mode—with full support from engineering. So, what changed?

The key blocker was fear: the fear of disrupting engineers.

We solved this by building a better way for engineers and FinOps teams to collaborate—through the Infracost bot in GitHub, GitLab, and Azure Repos. Engineers can now interact directly with FinOps teams via pull request comments like:

@infracost dismiss app isn't compatible with Graviton

This unblocks the pull request and creates a two-way feedback loop: engineers stay focused on what’s actionable in their workflow, and FinOps teams get clear visibility into why issues were dismissed—without needing Jira tickets or coordination meetings.

Rolling out enforcement is a journey. Most large enterprises progress through three phases:

1. Inform (FYI comments): ~20% issue prevention
2. Soft enforcement: ~50% issue prevention
3. Hard enforcement: ~90% issue prevention. Why not 100%? Because that’s not how FinOps works—some issues are unfixable in the short term. For example, tags that require changes to a 3rd-party Terraform module, or Graviton migrations blocked by app incompatibility.

By making enforcement developer-friendly, FinOps teams are no longer forced to choose between governance and velocity—they can have both.

See a live demo!

If you’re attending the FinOpsX conference in San Diego, drop by our booth to see a demo of all the new Infracost features! Request a live demo or email us at hello@infracost.io  and set up a proof-of-concept to see how you can Shift FinOps Left in your organization.