FinOps policies
The cloud cost optimization formula has two components: usage and unit price. Unit price optimization can be handled centrally by FinOps teams through reserved instances and savings plans. But usage optimization requires engineering involvement as only engineers can change the code that provisions resources.
FinOps policies make usage optimization actionable. Instead of generating reports that lead to meetings and Jira tickets, Infracost identifies issues directly in engineers' pull requests, showing exactly what to change and why. No handoffs, no context switching… just fixes at the source.
Cutting cloud waste
Infracost allows teams to reduce costs by tackling cost saving opportunities in multiple ways.
1. Seal the leaks
With infrastructure controlled by code, adding waste-reducing policies directly into CI/CD workflows is the best way to stop problems before they start. When engineers open a pull request, Infracost checks it against 70+ AWS, Azure, and Google best practices from the Well-Architected Frameworks.
The pull request comment shows the best practice alongside an explanation of why it matters, plus the exact file and line numbers that need to change. Engineers can fix issues before code is merged and no extra deployment required.
2. Burn down existing issues
When you enable FinOps policies, Infracost scans all your connected repositories and shows every resource that doesn't follow best practices. This gives engineering teams a clear backlog they can work through while pinpointing the exact files and lines they need to change, not just flagging problems in the abstract.
FinOps teams can prioritize which policies matter most to their organization, picking the top 3-5 to focus on each quarter. Once priorities are set, enable pull request comments for those policies and let Infracost handle the rest.
3. Track your improvements
Results matter. Infracost makes it easy to see how you're doing by both preventing new issues and burning down existing ones.
Here's a snapshot of one customer's progress:
- Proactive prevention: Out of 8.1K new issues since July 1, 80% (6.5K) were prevented before code was merged
- Burning down the backlog: The team resolved 41% (39K) of existing issues since July, that's 13K fixes per month. At this pace, they'll clear all 55K remaining issues in four months
Update policy settings
From Governance > FinOps policies, click the three dots on any policy to update its settings.
Enforcement level: Choose whether to block pull requests that fail this policy, or just warn engineers.
Trigger on new resources only: Some changes, like modifying a database's instance type, require downtime. Enable this option to only flag issues when engineers are adding new resources, not modifying existing ones. This prevents engineers from feeling pressured to make risky changes within an existing PR.
Custom message: Customize the message shown in pull requests to reference your company's specific standards or link to internal wiki pages.
Preferred regions and instance types
Infracost includes customizable policies that let FinOps teams encourage or enforce specific regions and instance types. These are particularly useful for organizations with Reserved Instances, Savings Plans, or Committed Use Discounts tied to specific regions and instance families.
Using preferred regions
Many enterprises want engineers to use specific cloud regions whether for compliance reasons, data residency requirements, or to encourage low-carbon Google Cloud regions.
To set this up, go to Governance > FinOps policies > Inactive tab and click on "General - consider using preferred regions." Enter the regions you want to encourage, using the provider's region identifiers:
| Provider | Format | Example |
|---|---|---|
| AWS | us-east-1 | List of AWS regions |
| Azure | eastus | List of Azure regions (or run az account list-locations -o table) |
us-west1 | List of Google regions |
Using preferred instance types
If your organization has standardized on specific instance types or families, whether for Reserved Instance coverage or operational consistency, you can encourage or require engineers to use them.
Go to Governance > FinOps policies > Inactive tab and click on "General - consider using preferred instance types." Specify region/instance type pairs, one per line, with each region and instance type separated by a colon.
Using wildcards: Use * to match any region or instance type:
| Pattern | Effect |
|---|---|
*:t3.* | Allow any t3 instance type in any region |
us-east-1:* | Allow any instance type in us-east-1 |
*:t3.medium | Allow t3.medium in any region |
Overriding wildcards: More specific patterns override broader ones. If you add both *:t1.micro and us-west-2:t2.micro, then t1.micro is allowed in all regions except us-west-2, which only allows t2.micro.
Non-production environment policies
Some FinOps policies only apply to non-production environments (for example, using single-AZ databases in dev and staging to save costs). These policies are often overlooked because engineers tend to use the same infrastructure-as-code patterns across environments. In Infracost Cloud, go to Governance > FinOps policies and search for "non-production" to see these policies.
Defining production filters
Infracost needs to know which environments are production so it can identify non-production resources. By default, projects containing "production", "prod", or "prd" are considered production.
To customize this, go to Org Settings > Production filters. You only need to define filters that match your production environments as Infracost treats everything else as non-production.
You can filter by:
- Project names within repos
- Entire repositories
- Branch names
After updating filters, go to Governance > FinOps policies and click Re-run policies to see the updated results.
ℹ️ Note: Module repositories are skipped when evaluating non-production policies. Instead, the repositories that use those modules are checked.
Understanding potential savings
Potential savings values may vary due to the nature of certain configurations. Here are some known cases:
Extended support costs
Some cloud providers calculate extended support costs per resource (e.g., per vCPU/hour). Updating an instance type may increase your extended support costs, which reduces net savings.
Modernization policies
Policies that target instance modernization, like migrating from gp2 to gp3 for AWS EBS, may show minor base cost increases. This is expected: these policies target right-sizing for improved performance and scalability (such as IOPS-heavy workloads), not just cost reduction.
Troubleshooting
If you run into any issues, please join our community Slack channel, we'll help you very quickly 😄
Policy not appearing in PR comments
Common causes: "Include details in pull requests" is disabled in policy settings, the repository isn't connected to Infracost Cloud, or PR filters are excluding the repository.
Solution: Check the policy's settings and verify the repository appears in Settings > Repos.
Savings estimates seem off
Common causes: Extended support costs, modernization trade-offs (see above), or usage-based resources where actual costs depend on runtime behavior.
Solution: Click into the specific issue in Issue Explorer to see the detailed cost breakdown. For usage-based resources, the estimate is based on the resource configuration, not actual usage patterns.
Non-production policies flagging production resources
Common causes: Production filters don't match your naming conventions.
Solution: Go to Org Settings > Production filters and verify your filters capture all production projects, repos, and branches. Then click Re-run policies on the FinOps policies page.