Skip to main content

Getting Started with Infracost Fix

First, Infracost Fix needs read access to your live cloud estate to start finding waste. Source control and ticketing systems come next: they let agents investigate and remediate findings.

1. Connect your cloud account​

Infracost Fix uses the same AWS Integration as the rest of Infracost Cloud: a read-only IAM role, deployed via Terraform or CloudFormation, into your AWS organization's management account and each member account you want covered. To setup the integration, login to dashboard.infracost.io > Org Settings > Integrations > Add integration > Amazon Web Services, and follow the AWS Integration guide to deploy the integration into your management account and each member account, then add the role ARNs from your dashboard's Org Settings. This step requires access to your management account and permission to create IAM roles.

2. Connect your source control​

Follow the GitHub App or GitLab App setup guide to integrate Infracost with your VCS provider. If you've already installed the app for Infracost Cloud, you don't need to reinstall it: Infracost Fix uses the same connection to investigate findings, open pull requests, and, on GitHub, create issues. It's also how agents map cloud resources back to code.

If your existing install only covers IaC repos, expand it to your application code repos too. Agents like the Cost Anomaly Investigation Agent trace issues back through application changes, not just infrastructure changes, so the more of your codebase Infracost can see, the more it can explain.

3. (Optional) Connect Jira​

If you want fixes routed to an engineer instead of opened directly as a PR, connect the Jira integration. Infracost Fix uses the same connection Infracost Cloud already uses to sync cost data with Jira, no separate setup. Skip this step if you don't plan to use that workflow: agents will still open PRs and apply fixes without it.

4. Add an agent​

From the Agents page, click New agent, then Add on the agent you want to run.

If you're not sure where to start, add Idle & unused resources first. It's the fastest path to visible savings, since idle infrastructure is usually the easiest waste to confirm and safest to act on.

Each agent comes with pre-built checks and instructions out of the box, you don't need to configure anything to get your first findings.

Use the Additional instructions box to give an agent context about your organization that it can't infer on its own. Instructions shape how the agent works, not what it scans. They influence four things:

  • How it investigates. Point the agent at context it would otherwise have to guess at: which repos hold your IaC, where your tagging standard lives, which accounts are production, which resources are load-bearing base infrastructure.
  • How findings are presented. Tell the agent what to lead with, and what a useful finding looks like to your team.
  • How tasks are grouped. For example, scope each task to a single AWS account rather than grouping across accounts.
  • What fixes it proposes. Encode your conventions: which module patterns to follow, whether to prefer a code change over a console action, what needs extra validation before anyone acts on it.

Editing Additional instructions is a reset. Saving a change clears all current findings and re-investigates your estate from scratch with the new context. That is the point: when your instructions were wrong, the findings they produced should go away with them. It also means you lose work in progress, so use it deliberately.

That tradeoff makes Additional instructions a tool for early adoption. In your first few weeks you are still learning how the agents behave and what is actually in your estate, and starting over costs you almost nothing because little is in flight. Later, once teams are working through findings, use Knowledge instead. It shapes future investigations without touching anything already open. Tuning your agents covers it.

Don't use either surface to exclude resources, accounts, or regions. Exclusions are easier to get right once you can see real findings, and the Dismiss workflow in Tuning your agents is built for exactly that.

Start in Notify (audit mode). In this mode, the agent surfaces findings but never takes action on its own: every PR, ticket, or coding-agent handoff still requires you (or another authorized user) to click and approve it. Review what the agent finds, then correct it with whichever surface fits: Knowledge for a targeted nudge, Additional instructions for a clean slate. Expect to iterate here: your first pass at configuration is a starting point, not a final answer.

Note: Additional autonomy levels are on the roadmap but not yet fully supported.

5. Review your first findings and continue training your agent​

Saving an agent kicks off its first scan immediately. After that, each agent scans your estate every 24 hours, or on demand when you click Run now on the agent's page. You can also Pause an agent to stop it scanning without removing it. From the Findings page, review what each agent surfaced.

If a finding looks right, act on it: open a PR, create a ticket, or send it to a coding agent. If something's off, you have two options:

  • Dismiss it. Closes the finding and, optionally, creates a rule so findings like it stop appearing.
  • Iterate on your configuration. If the agent misunderstood something about your environment, tell it. Add a Knowledge entry to shape future investigations without disturbing findings already in flight, or edit Additional instructions to clear everything and start over.

For more information, check out Tuning your agents.

Every action stays gated by your approval in Notify mode, nothing happens without you clicking it first.