There are two broad aspects to running a successful business. These are (a) creating a product that generates revenue and (b) managing the product cost that is lower than the revenue. E.g., if the product generates $100 in revenue and costs $90, then the business can survive because it is generating a 10% profit margin. Predicting sales is like predicting the future -no one knows with surety. But compared to sales, cost (to a large extent) is relatively predictable. When it comes to hosting a product on the AWS cloud, you want to know the cost of the AWS resource/s beforehand and not from the AWS Billing dashboard when it has already accrued or at the end of the month.

Many organizations hosting their products on the AWS cloud have benefitted from adopting IAC principles like automation, scalability, consistency, repeatability, and testability using tools like Terraform. In addition, using a CI-CD approach to deploying IAC enables teams to collaborate and benefit from automation: automated testing and automated deployment, thereby increasing team productivity.

Infrastructure changes can be deployed by a CI-CD pipeline using the familiar pull-request-based approach, like product features and bug fixes. This approach allows the pull-request reviewer to review the infrastructure changes in a pull request. GitHub Actions does this by posting the terraform plan command output as a comment in the pull request. Here is a link to a closed pull request where GitHub Actions updated the pull-request comments with the terraform plan command output. A reviewer can review the comments to evaluate the resources that will be created once the pull request is merged and determine if the pull request can be merged or not.

However, the AWS resource cost is missing in the pull request. Could the pull request reviewer also review the cost of deploying the infrastructure in the pull request? Having the resource cost information in a pull request enables them to evaluate and eventually approve or decline it. And that is what Infracost addresses.

Setting up Infracost (creating an account and generating the TOKEN) took me less than 15 mins. I stored the TOKEN as a GitHub repo secret where I wanted to run Infracost. As of writing this note, there are three ways to generate an AWS resource cost estimate using Infracost in a pull request for Terraform code: (a) by comparing the HCL code difference between the two branches in a pull request, (b) from the terraform plan output in the pull request, and (c) based on the AWS cloud resource usage.

In this note, I demonstrate generating a cost estimate in a pull request by (1) comparing the HCL code and (2) the terraform plan output review. Instead of having separate workflows for both these use cases (a project team will use only one use case in a repository), I merged both into the same workflow using a flag variable. I created a GitHub variable (INFRACOST_SCAN_TYPE) and added conditions based on the variable’s value to all the impacted steps in the GitHub Actions workflow YAML file.

Option 1: Comparing the HCL code difference in a pull request I followed this approach in the GitHub repo: add-asg-elb-terraform. The process could be broken down into three steps. Step 1: Store the value of the TOKEN as a GitHub repository secret (INFRACOST_API_KEY) so that the GitHub Actions Yaml pipeline can reference it. Step 2: Add a GitHub variable INFRACOST_SCAN_TYPE and set its value as hcl_code. Step 3: Add the following steps with the condition to the GitHub workflow Yaml file - GitHub Actions ensures that the below steps are run when both conditions $ are true, which would be the case if the trigger is a pull_request and the variable’s value is hcl_code. The logic to generate the cost estimate is straightforward inside the YAML file. (a) generate a cost baseline from the base (main) branch, (b) compare that against the cost estimate from the pull-request branch to generate the difference, and (d) publish the result as a comment in the pull request. Here is a link to a pull request comment where you may review the cost estimate. As you can see, the comment is descriptive. This option covers 90% of the use cases, as per Ali (founder).

Although it is easy, I prefer the next option because it covers 100% of the use cases.

Option 2: From the terraform plan output I prefer this option because it is generated from the terraform plan output file. The first and second step of storing the TOKEN as a GitHub secret and the GitHub variable is applicable under this option too. However, unlike Option #1, the value of INFRACOST_SCAN_TYPE is set to tf_plan. Since Infracost needs to run only during a pull request, all those steps have an additional condition of if: github.event_name == 'pull_request'. You may review one such file here. The workflow logic is as below: (a) generate a TFPlan.json file as an output of the terraform plan command, (b) generate a cost estimate from the TFPlan.json file, and (c) publish the result as a comment in the pull request. Here is a link to a pull request comment (Infracost-estimate) where you can review the Infracost-generated cost estimate from the TFPlan output file.

I hope you found this note informative. I’ve provided a detailed description of the Infracost options and the pipeline YAML files, which should be sufficient for you to start. Let me know if you have any questions. Adding the cost estimate of the AWS resources in a pull request will empower the reviewer to decide to approve or decline the change. This integration will also inform the project team about their project’s running cost, which can trigger them to identify if they are using the most cost-efficient mechanism to host their product. I think Infracost is an innovative solution that organizations and projects will find helpful.