Summary: we're excited to announce Infracost v0.9.14 and our new composable GitHub Actions 🎉 This release also includes new GitHub comment and Slack message output formats, 6 new AWS/Azure/Google resources, a summary table in PR comments, improved CLI output, and faster runs. We recommend everyone to upgrade!

How did we get here?​

It's a bit noisy! We'd received a bunch of feedback about Infracost's CI/CD integrations - let's face it, everyone's Terraform workflow is different — so in November we decided to try a new approach… Let's rewind for a second: around a year ago, we made an 86-line bash script that ran Infracost on a repo's main and pull request branches, it then ran git diff with some tricks on the CLI output, and curled it to GitHub to post a PR comment as you can see below:

As with most useful bash scripts, it grew arms and legs over time and went from 86 lines to 647! It handled a bunch of workflows, and edge cases, in GitHub, GitLab, CircleCI, Bitbucket and Azure DevOps - it even made you breakfast! The original bash script was packaged-up in a Docker image, which meant it also had to include Terraform, Terragrunt, git and a bunch of other stuff. We then had to add multiple Terraform versions to support everyone's workflows and the image grew to ~1GB uncompressed 🤮

So in November we went back to the drawing board, put away the 1 year old bash script, and developed a new composable way of using Infracost in CI/CD pipelines. Thank you bash, you served us well and we still love you for prototyping in CI/CD.

New composable GitHub Actions​

The new Infracost GitHub Actions provide a composable way of using Infracost in your workflow. These native JS actions can be used to install Infracost, and comment on pull requests using different behaviors so you can control the noise level (described below). This enables the Infracost output to be used by other actions too, e.g. to set cost policies or post messages to Slack!

If you used our old infracost-gh-actions repo, please follow our migration guide to use the new new actions repo. The infracost-gh-actions repo will be deprecated in the next Infracost release but will continue to work without issues.

Install Infracost​

The "setup" action installs the Infracost CLI using SemVer ranges. This enables you to automatically get the latest backward compatible changes in the 0.9 release (e.g. new resources/features and bug fixes) without worrying about CI/CD pipelines breaking.

You can use other actions to install required versions of Terraform and Terragrunt.

Configure pull request comments​

The "comment" action lets you configure how pull request comments are posted using a behavior and a target attribute.

Behavior describes how and when comments should be posted; we support four options:

• update: Create a single comment and update it on changes. This is a good default. The GitHub comments UI shows what/when changed when the comment is updated. Pull request followers will only be notified on the comment create (not updates), and the comment will stay at the same location in the comment history.
• delete-and-new: Delete previous cost estimate comments and create a new one. Pull request followers will be notified on each comment.
• hide-and-new: Minimize previous cost estimate comments and create a new one. Pull request followers will be notified on each comment.
• new: Create a new cost estimate comment. Pull request followers will be notified on each comment.

The target-type describes where the comment should be posted against, which can be either pull-request (default) or commit.

Examples​

We've created 10 examples of how the Infracost actions can be used in different workflows, including multi-project setups using a build matrix, setting cost or percentage thresholds for comments using the Infracost JSON output, and posting cost estimates to Slack.

We'd love to see the community contribute their examples too; we've even developed automated tests for the examples 😎

New output formats​

The infracost output command can be used to combine and output Infracost JSON files in different formats. This is useful when you want to combine cost estimates across different projects, e.g. Terraform mono repos or Terragrunt projects, or produce different formats from the same cost estimate, e.g. create a GitHub comment, and a Slack message when a threshold is crossed. We've added two new formats to this command:

• github-comment: produces a Github-flavored Markdown comment. This is used internally by the new Infracost GitHub Actions; if you use GitHub with other CI/CD systems, you can also use this format to create comments that can then posted to GitHub.

  

• slack-message: produces a Slack-flavored Markdown message. Slack message blocks have a 3000 char limit so the Infracost CLI automatically truncates the middle of slack-message output format if required.

  

New resources​

We added support for 6 new resources:

• AWS: Transfer Family, RDS additional backup storage
• Azure: Storage Account (V2), Front Door, Private Link Endpoints
• Google: Secret Manager

Our automated tests caught the price changes AWS announced at re:Invent and we've updated CLI to handle them.

Create GitHub issues if you need support for other resources. Checkout our contributing guide if you'd like to join the 50+ community members who have added resource mappings already. Once a mapping has been coded, the whole community enjoys the benefits.

Summary table in PR comments​

Pull/merge request comments in GitHub, GitLab and Azure DevOps Repos now show a summary table. This enables you to quickly understand the overall changes and review the detailed diff if the changes seem significant. Unfortunately we couldn't do the same for Bitbucket comments as they don't support HTML yet; please upvote this GitHub issue if you'd like us to use their markdown format instead.

Improved CLI output​

Infracost CLI commands now include a summary of the resources at the bottom, which can be expanded to show details with the --show-skipped flag. The summary shows the total number of cloud resources, how many include usage-based costs, how many weren't estimated, and how many are free.

The CLI diff output has been simplified to show changes in one line, similar to how Terraform and Pulumi show changes. Previously we showed 2 lines: one showing the old resource being removed, and one showing the new resource being added.

Save to file​

The Infracost breakdown, diff and output commands now support an --out-file flag, which can be used to save the output to a file. This is specially helpful when the --format flag is used as you can save the output and use it in subsequent actions.

Faster runs​

The sync-usage-file flag now runs a lot faster as we've parallelized the API calls to fetch usage data from AWS CloudWatch. If you're using this feature, we highly recommend you upgrade!

Community highlights​

We ❤️ seeing feedback, bug reports and pull requests from the community! To pick a few: Josh Niec and Maksym Vlasov made their first contributions, Simon-jt kept improving the Cloud Pricing API deployment, Pat Myron simplified a bunch of test files, and Hugo Rut and Sina Bakhtiari are making it easier for contributors to add resources.

Especial thanks to the many users who gave us feedback on our old GitHub Action, particularly:

• Jon Leemon, Sushant Pradhan and Semjon Bibow for highlighting the issues with our long/complicated diff.sh bash script.
• AJ Bowen and Didier Caron for pointing us in the right direction about pull request commenting behaviors.
• Frank Chiarulli Jr. for inspiring the pull request summary table.

Help us!​

Up next, we're focusing on the following areas. You keep upvoting and sharing your comments in the following GitHub discussions and we'll keep shipping

1. Sharing cost estimates
2. Learning about your Infracost CI/CD journey
3. Investigating cost policies
4. Improving our Atlantis integration
5. Composable GitLab CI Templates

Message me on Slack or Twitter if you have any questions!

We released Infracost v0.9.12 recently, you can upgrade to use these features. This release includes many bug fixes and we have made Infracost a lot faster to run!

Improved CLI output​

We've simplified the output for AWS S3 and CloudFront. Previously these resources had over 50 lines of output due to their complicated pricing models. We now only output their standard pricing options; other prices are shown when applicable parameters are used in a usage file.

Furthermore, when a new usage file is generated, values are commented-out unless a value is fetched from AWS CloudWatch. This enables you to uncomment required usage-based parameters. Also, cost components with zero usage are hidden in the table and HTML output to simplify the output.

The diff output now groups projects with no usage diffs into one line, which can simplify the output for Terraform mono repos and Terragrunt projects.

The JSON output now includes 4 new fields: the hourly/monthly total cost of all diffs and past totals. This is useful when Infracost is used with other tools such as pre-commit-terraform.

Faster CLI runs​

To speed-up CLI runs, we now cache Terraform plans where possible. This is helpful when the CLI is re-run to do what-if analysis with the usage file or show skipped resources. Caching only happens when the CLI is being used outside of CI/CD integrations and a new --no-cache flag has been added to disable this behavior where required.

Usage-based resources​

The fetch from CloudWatch feature has been expanded to fetch usage data for S3, AutoScaling and EKS node groups. A new CI/CD parameter, sync_usage_file=true, has been added so this can also be triggered in CI/CD runs.

Multi-project runs​

Infracost config files now support a new env parameter that can be used to define environment variables for each project as shown in the following example. The config file syntax is also validated and more helpful error messages are shown. We recommend users add an infracost.yml config file to their projects as well as any usage files to their repos so infracost breakdown --config-file infracost.yml can be run by anyone without having to type all the flags/envs.

version: 0.1
projects:
  - path: dev
    usage_file: dev/infracost-usage.yml
    env:
      AWS_PROFILE: infracost-dev
      AWS_ACCESS_KEY_ID: ${DEV_AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${DEV_AWS_SECRET_ACCESS_KEY}     
  - path: prod
    usage_file: prod/infracost-usage.yml
    ...

New resources​

We have added support for the following resources: aws_dx_connection, aws_mwaa_environment, aws_directory_service_directory, azurerm_synapse_spark_pool, azurerm_synapse_sql_pool and azurerm_synapse_workspace.

Community​

The community has been writing some awesome content around Infracost, and I'd like to give them a shout-out here:

• Florian Pialoux wrote a blog on how to integrate Infracost with Terraform Cloud.

• Anton Babenko, Maxym Vlasov and George Yermulnik added support for Infracost to pre-commit-terraform, checkout the docs for useful tips.

• Alex McFarland wrote a step by step guide on Infracost.

Finally, Vadim joined our team, and I gave a lightning talk at HashiConf. My talk included details of use-cases we're seeing and a demo of the new Terraform Cloud RunTasks integration.

Up next!​

We're focusing on CI/CD integrations and would love to see your upvotes on the ideas mentioned in the GitHub discussion. Checkout our project board to see what else is in flight.

It's been awesome to hear your feedback. Message me on Slack or Twitter if you have any questions!

We released Infracost v0.9.9 recently, you can upgrade to use these features.

Fetch usage from CloudWatch​

When it comes to estimates for resources where the cost fully depends on usage (e.g. AWS S3 or Lambda), we have a usage file, in which users can define how much of those resources they will use. This requires you to manually input the usage numbers. We're now experimenting with fetching the values from CloudWatch or other cloud APIs when --sync-usage-file is used. This enables you to quickly see what the last 30-day usage for those resources have been and adjust if needed. If the CLI can fetch the following values from CloudWatch, it will overwrite them in the usage file.

• aws_dynamodb_table: data storage, read capacity and write capacity units
• aws_lambda_function: function duration and requests
• aws_instance, aws_autoscaling_group, aws_eks_node_group: operating system (based on the AMI)

Please use this GitHub discussion to let us know if you find this useful or have feedback.

Less noisy GitHub PR comments​

We have heard from some users that leaving a new comment every time something is changed, makes Infracost PR comments too noisy. We have added a new post_condition option '{"update": true}' which should help. For our GitHub-based CI/CD integrations (GitHub Actions, Azure DevOps with GitHub repos, and CircleCI with GitHub repos) when a commit results in a change in cost estimates vs earlier commits, the integration will create or update a PR comment (instead of commit comments). The GitHub comments UI can be used to see when/what was changed in the comment. PR followers will only be notified on the comment create (not update), and the comment will stay at the same location in the comment history.

This new post_condition is an addition to the existing ones: has_diff, always and percentage_threshold. Please use this GitHub discussion to tell us what you'd like to see in PR comments.

A few more improvements​

We merged 33 pull requests and closed 20 issues in September, I wanted to highlight a few of these improvements:

• Added support for google_compute_instance_group_manager and google_compute_region_instance_group_manager, azurerm_bastion_host and azurerm_postgresql_flexible_server (v4).
• Improved Terragrunt project detection logic.
• Free resources can be seen when running the CLI with the --log-level debug flag, look for "Skipping free resource" lines. This helps users debug issues with supported resources.

Seed funding​

We announced our $2.2M seed funding from Sequoia, Y Combinator, SV Angel and Yun-Fang Juan as an angel investor. Bogomil Balkansky (our partner at Sequoia) wrote a blog about why they invested in Infracost.

A huge thank you to our amazing open source community of users and contributors for helping us reach this milestone.

Community​

The community has been writing some awesome content around Infracost, and I'd like to give them a shout-out here:

• Joe (Solutions Architect at GitLab) recorded a video demo of how you can create cloud costs estimates with Terraform, Infracost, and GitLab CI.
• Russ (Practice Manager of SRE & DevOps at N4Stack) wrote a detailed blog about tracking costs in Terraform using Infracost.
• Thiago (Cloud DevOps Eng at Dock) wrote a great intro blog for our Brazilian community: estimativa de custo para o Terraform com Infracost.
• Hassan, our co-founder, went on The Production-First Mindset podcast to talk about the complexity of cloud pricing and our open source approach.

Up next!​

We're focusing on usability improvements, for example by generating the usage file with commented-out 0 values and skipping 0-usage line items in breakdown output. Checkout our project board to see what else is in flight.

We're glad to see our community growing; it's been awesome to hear your feedback on features and discuss how you're handling cloud costs as part of your workflows. Message me on Slack or Twitter if you have any questions!

I’m very excited to announce that Infracost has raised $2.2M in seed funding from Sequoia, Y Combinator, SV Angel and Yun-Fang Juan as an angel investor.

People are often surprised to learn that DevOps and SREs, who are launching cloud resources are never shown how much these resources are going to cost until they are charged for them. That is like going to a supermarket and having no price tags, and no checkout; then being told that your card will be charged later. This is not fair as when bills exceed budgets, the DevOps and SREs are asked to fix it.

The way we solve this problem is to show engineering teams how much resources, and the specific options they have selected, cost. This happens within their workflow before anything goes to production.

Ali, Alistair and I launched Infracost in late 2020 as an open source project, and have gained over 4,000 GitHub stars, with a community who are helping direct the roadmap as well as contributing code. We currently track over 3 million price points from AWS, Google Cloud and Microsoft Azure; have support for popular CI/CD systems such as GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines, Jenkins; and support Terraform, with more IaC tools coming soon.

There are many super interesting problems we still need to solve, ranging from supporting many different types of cloud resources, cloud providers and charges, custom pricing discounts for large enterprises, usage-based resources and their consumption estimates (e.g. how much data-transfer will go through these resources, so we can calculate the cost) just to name a few. Just check out our GitHub issue board.

I want to thank our amazing open source community of users and contributors for helping us reach this milestone. I hope to see you around 😊

Hassan, Ali, Alistair

We released Infracost v0.9.7 recently, you can upgrade to use these features.

Currency conversion​

You can now use infracost configure set currency to set your preferred currency (e.g. EUR, BRL or INR). Any ISO 4217 currency code should work, for example use XAG to see how much Silver you're spending on the cloud 😂 The environment variable INFRACOST_CURRENCY can be used to set the currency in CI/CD pipelines. Cloud vendors usually publish prices in USD so the costs will be converted from USD to your preferred currency using the current exchange rate when the CLI is run.

The new infracost configure command can also be used to get/set your API key, and for users who are self-hosting the Cloud Pricing API, setting your API Endpoint.

Improved Terragrunt support​

We have spent a lot of time improving our support for Terragrunt, and we'd love for you to try this out and give us more feedback on how to improve it further. Previously, Terragrunt users had to set INFRACOST_TERRAFORM_BINARY and specify their Terragrunt modules in the Infracost config file manually. These steps are no longer needed as Terragrunt projects are now automatically detected when passed in via the --path flag. You can read more about this initial set of improvements for Terragrunt in our docs. Please open a GitHub issue with feedback and suggestions.

Slack integration​

We have always focused on making it easy to see costs within your workflow. For some companies, Slack is part of their workflow and communication flow. With that, Slack integration is now supported by all of our CI/CD integrations so pull request comments can also be posted to a Slack channel.

A few more improvements​

• When running infracost breakdown and infracost output, you can now use --fields all to output all available fields in the table or HTML output. The JSON format always includes all fields.
• We've added support for the following Azure Terraform resources: azurerm_active_directory_domain_service, azurerm_virtual_network_gateway and azurerm_private_endpoint.

Community​

We hit 4K GitHub stars and now have over 200 people on our community Slack chat! I want to give a warm welcome to new members, we're happy to see you all in Slack and have you share your ideas, feedback, and activity with us.

• Bruno (SRE at iFood) made an awesome two-part video showing how to use the Infracost Atlantis integration in Portuguese: part 1, part 2.
• Praveen (Lead Software Engineer at GS Lab) wrote a blog on how to deploy the Cloud Pricing API.
• Florian (DevOps Engineer at Bluelight Consulting) wrote a blog on how to use Infracost with GitLab.
• Russ (Practice Manager, SRE & DevOps at Node4) wrote a blog on how to use Infracost with Azure DevOps pipelines to warn users if they're making a change that dramatically increases the running costs of the deployment.

Finally, Tim joined our team as Principal Engineer, and I was interviewed by Secfi about employee stock options as we're hiring!

Up next!​

We're prototyping how we can populate the usage file with data from AWS CloudWatch for resources like aws_s3_bucket or aws_lambda_function. We'd love to hear your feedback via this issue.

We're glad to see our community growing; it's been awesome to hear your feedback on features and discuss how you're handling cloud costs as part of your workflows. Message me on Slack or Twitter if you have any questions!

The Cloud Pricing API is an open source GraphQL-based API that includes all public prices from AWS, Azure and Google; it contains over 3 million prices! The prices are automatically updated via a weekly job. You can use our hosted version or self-host (it should take less than 15mins to deploy).

We needed a multi-cloud pricing API that we could use to explore pricing data structures (e.g. what are the various price components for AWS EC2) and filter for specific prices for the Infracost CLI. The cloud vendor pricing APIs do not address these use-cases so we developed and open sourced the Cloud Pricing API, which can also be used independently of the Infracost CLI.

GraphQL is a natural fit for cloud pricing as it can model the JSON structure used by cloud vendors. This enables you to query nested JSON structures using vendor-specific parameters, and request only the attributes you need to be returned in the response. For example, you can find all prices that match AWS EC2 m3.large instance in us-east-1 (over 400 prices), then explore the 30+ attributes that AWS return to describe instances (e.g. clockSpeed or networkPerformance).

Usage​

Infracost runs a hosted version of this API that you can use:

1. Register for an API key by downloading infracost and running infracost register.
2. Pass the above API key using the X-Api-Key: xxxx HTTP header when calling https://pricing.api.infracost.io/graphql. The following example fetches the latest price for an AWS EC2 m3.large instance in us-east-1. More examples can be found here.

curl https://pricing.api.infracost.io/graphql \
  -X POST \
  -H 'X-Api-Key: YOUR_API_KEY_HERE' \
  -H 'Content-Type: application/json' \
  --data '
  {"query": "{ products(filter: {vendorName: \"aws\", service: \"AmazonEC2\", region: \"us-east-1\", attributeFilters: [{key: \"instanceType\", value: \"m3.large\"}, {key: \"operatingSystem\", value: \"Linux\"}, {key: \"tenancy\", value: \"Shared\"}, {key: \"capacitystatus\", value: \"Used\"}, {key: \"preInstalledSw\", value: \"NA\"}]}) { prices(filter: {purchaseOption: \"on_demand\"}) { USD } } } "}
  '

query {
  products(
    filter: {
      vendorName: "aws",
      service: "AmazonEC2",
      productFamily: "Compute Instance",
      region: "us-east-1",
      attributeFilters: [
        { key: "instanceType", value: "m3.large" }
        { key: "operatingSystem", value: "Linux" }
        { key: "tenancy", value: "Shared" }
        { key: "capacitystatus", value: "Used" }
        { key: "preInstalledSw", value: "NA" }
      ]
    },
  ) {
    prices(
      filter: {purchaseOption: "on_demand"}
    ){ USD }
  }
}

{"data":{
  "products":[
    {
      "prices":[
        {
          "USD":"0.1330000000"
        }
      ]
    }
  ]
}}

Concepts​

The API has two main types: Products and Prices. Each product can have many Prices. This simple high-level schema provides flexibility to model the exact values that the cloud vendor APIs return at the same time as having useful top-level product filters. The values returned by the API are the same ones that the cloud vendors return in their APIs.

The main properties of Products are:

The main properties of Prices are:

What will you build?​

Whilst our main use-case for developing the Cloud Pricing API is the Infracost CLI, we're excited to see what the community does with this API. Please share your use-cases and issues with us on GitHub or Slack or email.

Whilst many Infracost CLI users connect to our hosted Cloud Pricing API (since no cloud credentials or secrets are sent to it), large enterprises that have restrictive security policies require self-hosting. Thus in July we focused on improving the self-hosting experience of the Cloud Pricing API. This is a GraphQL-based API that includes all public prices from AWS, Azure and Google; it contains over 3 million prices just now!

This is actually the third Cloud Pricing API our team has built; the complexity in cloud pricing has increased significantly in the last 10 years:

• In 2010 (as part of PlanForCloud), we developed scrapers to fetch cloud prices as vendors didn't offer APIs then. There were over 10,000 prices at the time.
• In 2015 (as part of RightScale), we developed a RESTful API. There were over 100,000 prices at the time.
• In 2021 (as part of Infracost), we developed an open source GraphQL API for use with the Infracost CLI. AS previously mentioned, it containers over 3,000,000 prices just now.

Improvements​

We made the following main improvements in July:

1. The datastore was switched from MongoDB to PostgreSQL since all the major cloud vendors have hosted options for this. Previously some of our users ran into compatibility issues with cloud vendor's hosted MongoDB versions.
2. An official Helm chart was developed; the existing Docker compose file was also updated. This will deploy the Cloud Pricing API and a weekly cronjob to to update prices. By default it will also deploy a PostgreSQL pod/container but it can also be configured to use an external PostgreSQL instance for high availability, e.g. AWS RDS or Azure Database for PostgreSQL.
3. The time it takes to update prices was reduced from around 1.5 hours to 2 minutes.

The pricing DB dump is downloaded from Infracost's API as that simplifies the task of keeping prices up-to-date. We have created one job that you can run once a week to download the latest prices. This provides you with:

• Fast updates: our aim is to enable you to deploy this service in less than 15mins. Some cloud vendors paginate API calls to 100 resources at a time, and making too many requests result in errors; fetching prices directly from them takes more than an hour.
• Complete updates: we run integration tests to ensure that the CLI is using the correct prices. In the past, there have been cases when cloud vendors have tweaked their pricing API data that caused direct downloads to fail. With this method, we check the pricing data passes our integration tests before publishing them, and everyone automatically gets the entire up-to-date data. The aim is reduce the risk of failed or partial updates.

Over to you​

If you require self-hosting, please follow the self-hosting docs. If you had previously deployed the Cloud Pricing API, you can follow the migration guide.

Thanks for being part of the community! We look forward to hearing your feedback via GitHub issues -- you can also join our community Slack chat.

In June we focused on integrations and adding more resource coverage. You can upgrade to the latest version (v0.9.2) to pickup the new features. If you are using v0.8 please follow the v0.9 migration guide.

⚙️ Integrations​

Infracost already has CI/CD integrations with GitHub Actions, GitLab CI, Atlantis, Azure DevOps, CircleCI, Bitbucket Pipelines and Jenkins. This list keeps growing, so please let us know what you'd like to see added next. Infracost can now be used with the following infra-as-code management platforms too:

• Terraform Cloud: we have partnered with HashiCorp to bring cloud cost estimates into Terraform Cloud's new RunChecks (currently in beta). Armon Dadgar, co-founder and CTO of HashiCorp, announced the partnership during HashiConf EU; screenshot below! If your company uses Terraform Cloud and would like to work with us and HashiCorp together on this integration, please reply to this email.

• Env0: cloud cost estimates can easily be enabled in Env0. Our CEO Hassan, Env0's CEO Ohad Maislish, and Tim Davis are doing a webinar about cloud costs shifting left on 14th July. Signup to listen in.

• Spacelift: cloud cost estimates can also be enabled in Spacelift.

⛅ New cloud resources​

Infracost now supports over 200 Terraform resources across AWS, Azure and Google. Over 500 free resources have also been identified; these are not shown in the CLI output since they are free.

We added support for the following cloud resources:

• AWS: Backup, EFS One Zone, Kinesis Firehose & Data Analytics, Neptune.
• Google: BigQuery, Load Balancer, VPN tunnel.
• Azure: Application Gateway, Application Insights, Automation, Cognitive Search, Event Hubs, Kubernetes Load Balancer & HTTP Application Routing, Load Balancer, Redis Cache.

⌨️ Shell completion​

Run infracost completion --help to see how you can generate shell completion scripts for Bash, Zsh, fish and PowerShell. Once enabled, you can use the usual double tab to see autocomplete and help text for commands and flags.

Thanks for being part of the community! We look forward to hearing your feedback via GitHub issues or join our community Slack chat.

Thanks to our awesome community, I'm very excited to announce that you can now use Infracost to get cloud cost estimates for Microsoft Azure in pull requests. Try it now, it's free and open source!

Cloud costs for engineering teams

Cloud costs have become so complex that the industry (ourselves included) started addressing issues around breached budgets after the bill arrived. This is not the way it should be. It is like going shopping and having no idea how much things cost till after your card has been charged.

We are on a mission to empower engineering teams to use cloud infrastructure economically and efficiently. We do this by fitting in the developer workflow via CI/CD integration, reading the Infrastructure-as-code project, picking up the parameters that have a price point, looking up the prices for the configurations and leaving a comment in the Pull Request like "This change will increase your cloud costs by 25%" with a detailed breakdown. This way, the whole team is aware of the cost implications of the change.

Today's announcement

Today we are announcing that in addition to AWS and Google Cloud Platform, we have added support for Microsoft Azure. Not only has Azure support been requested by over 60 of our community members (https://github.com/infracost/infracost/issues/64), but we have seen a lot of growth from Microsoft in terms of the number of resources offered and enterprise adoption.

We have added support for over 65 Azure resources (and another 70 resources which are free), with many more planned. Visit our GitHub issues page and put a thumbs up on the resources you'd like covered and we will prioritize them.

But there is one more thing! We have also added support for Microsoft Azure DevOps Pipelines. This is in addition to our current supported CI/CD integrations such as GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines, Atlantis and Jenkins.

Get started! We have made it super simple to get up and running:

1. brew install infracost # (docker, windows etc options available)
2. infracost register
3. az login # To set cloud creds, see note-1
4. infracost breakdown --path . # Run in your terraform directory. We also have an example Azure terraform file you can use to try it out.

For full details, see our Getting Started guide. From there, you can setup Azure DevOps Pipelines for the CI/CD integration.

note-1: Infracost does not need or access your cloud creds, however, Terraform needs this to create the plan file.

I sat down with David Julia, who is the Head of Engineering at Eagle.io to talk about cost attribution, why it matters, who should care and how Eagle.io achieves this. We worked through their use-case, their tech stack, the tools they use, what worked and what did not work, and ultimately how they have achieved cloud cost attribution.

The following is lightly edited transcript (from YouTube) of the introduction section of our chat:

Ali: Hey everyone, I have David Julia here who is the head of engineering at Eagle.io. David thank you very much for taking time to speak with me today. Would you like to introduce yourself?

David: Yeah absolutely, so David Julia head of engineering at Eagle.io. We do environmental IoT so we're an environmental IoT data platform essentially, you connect up all sorts of devices to us were used in water monitoring, natural resource monitoring, various other things. We are used to monitor the cracks in Mount Rushmore for example, how Mount Rushmore is splitting and how that's going and whether they need to remediate anything so you know a broad variety of use cases, all these data loggers centers, connected to the platform and analytics and processing logic on that. A fun gig for me. I just started that a couple of months ago before that I was in software engineering consulting for a long time, about nine years at Pivotal Labs and then VMware. A fun little project that we're working on now and I had the chance to jump into some cost attribution stuff as part of it, hence the conversation today.

Ali: Which cloud providers are you using and what is the setup?

David: We're a multi-tenant SaaS platform so the whole value proposition of Eagle.io is unlike AWS IoT Core or Azure IoT, we think of those as primitive building blocks which if you want to build your own solution cool go nuts with them but we're much higher up the stack than that. Essentially for engineering firms or big municipal water companies, state water companies, mining companies that they don't really want to mess around with all this code and IoT Core and all of this different stuff that's out there, which is really cool admittedly, but not core to their business so they just hook up to us and very quickly they're able to get data in analyze it alert on it. If you're monitoring a dam for example you want to know if a dam wall is failing you don't really care about configuring microservices or anything like that. So we're a multi-tenant SaaS application lots and lots of different users but a lot of shared resources as well. So that's kind of the layout. We're mostly AWS.

Ali: Can you tell us then in this context, what do you mean by cost attribution and why do cloud costs matter as part of that?

David: So why cost attribution, well it's pretty fundamental especially when you're building a data intensive application like ours, but also in other circumstances you really just want to know 1) can I guarantee that I'm going to make good gross margin, and 2) if I add more customers am I going to be adding more profit or not is it going to be impacting my gross margin positively or negatively and if that's a very big question mark that's something to be nervous about and that's actually the situation we found ourselves in. We were negotiating with a particular enterprise customer who wanted to essentially more than 10x their usage of the platform and so they said well you got to give us a discount, for this to be financially feasible for us to do this and we want to do this deal you guys but we need to make it in the realm of dollars and that we can actually do. We said well we should be able to do this but our current pricing model doesn't scale for them or maybe it's just the numbers but if we give them too deep of a discount are we going to lose money on the thing like we don't know like what are our costs what's their usage what rights like what what's even driving our costs. So that's when we really sat down and said okay we need to figure this out.

Watch the whole interview on Infracost's YouTube channel. Subtitles have also been enabled.

If you are interested in working in environmental IoT, reach out to David on Twitter!