Have you ever felt that knot in your stomach when running terraform apply, unsure of how many zeros will show up on your AWS bill at the end of the month? As a Cloud professional transitioning into DevOps, my goal isn't just to build infrastructure that works, but infrastructure that is sustainable and governed.

In this article, I'll walk you through a hands-on project where I integrated Infracost directly into my CI/CD pipeline. The goal is simple yet powerful: every time I propose a change via Pull Request, the system automatically calculates the financial impact and posts a detailed comment. This is FinOps in action!

What is Infracost?

For those unfamiliar, Infracost anticipates cloud costs and integrates them into your engineering workflow. It provides cost estimates for Terraform, CloudFormation, and AWS CDK before deployment, identifying FinOps issues aligned with well-architected frameworks—fixable with a single merge.

Fully compatible with AWS, Azure, and Google Cloud, it's essential for multicloud setups. Dive deeper in the official Infracost docs.

Alignment with AWS Well-Architected Framework

My cloud journey taught me that building on AWS goes beyond deploying resources—it's about excellence standards. This project is rooted in the AWS Well-Architected Framework, focusing on two vital pillars:

Cost Optimization: Shift visibility from month-end to code time, spotting oversized resources pre-creation for efficient investment.

Sustainability (GreenOps): Use Infracost to estimate CO_2e emissions, enabling eco-friendly architectural choices.

Project Architecture

To make it easier to understand how everything connects, I’ve prepared this diagram illustrating our automation flow:

As you can see in the diagram, the flow is divided into two fundamental parts:

The CI/CD Pipeline

Pull Request: Upon pushing the code to GitHub, a GitHub Actions workflow is triggered.

Analysis: The pipeline executes a terraform plan and Infracost analyzes this plan, generating the cost table directly as a PR comment.

Project Structure: Organizing Folders and Files

Organization is the foundation of any Infrastructure as Code (IaC) project. A well-defined structure simplifies automation and ensures that the infrastructure is scalable and easy for other developers to understand. To make this lab simple to replicate, the project is built on a modular structure.

Modularization is more than just organization; it is a best practice that allows different layers — such as Network, Security, and Application — to be managed independently, ensuring a proper separation of concerns.

infracost_aws/
├── .github/
│   └── workflows/
│       └── infracost.yml      # Pipeline automation
├── modules/
│   ├── network/               # Network layer (VPC, Subnets)
│   └── compute/               # Cost-generating resources (EC2, RDS, S3)
├── main.tf                    # Module orchestrator
├── providers.tf               # Identity and Governance
├── terraform.tfvars           # Variable values
└── variables.tf               # Global definitions

The Cloud Contract: providers.tf

Every Terraform project begins with the providers file. This is where we establish the connection with the cloud provider and set the governance strategy right from "day zero."

Here is the configuration I used for this project:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"

  # The FinOps and Governance pillar starts here!
  default_tags {
    tags = {
      Project     = "FinOps-Infracost-Study"
      ManagedBy   = "Terraform"
      Environment = "Dev"
      Service     = "FinOps-Project"
    }
  }
}

Why is this configuration strategic?

Provider Versioning: Locking the version (e.g., ~> 5.0) prevents automatic provider updates from breaking the code, ensuring pipeline stability.

The Magic of default_tags: This is the most efficient way to implement cost traceability. By declaring tags in the provider block, all compatible resources (EC2, RDS, S3, etc.) automatically inherit these labels.

Hands-on FinOps: With Environment and Service tags, finance teams can filter invoices with surgical precision, eliminating "orphan" resources and simplifying audits.

Variables: The Power of Parameterization

In Infrastructure as Code, variables act like function arguments. They allow us to write generic code that can be adapted to different environments (Dev, Stage, Prod) without rewriting the core logic. To keep the project organized and simple to replicate, I split this logic into two distinct files:

1. variables.tf: The "Contract" In this file, I define which variables my project accepts, their types (string, number, list), and an optional description. It’s the "blueprint" telling Terraform what to expect.

variable "aws_region" {
  description = "AWS region where resources will be created"
  type        = string
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
}

variable "db_instance_class" {
  description = "RDS database instance class"
  type        = string
}

1. terraform.tfvars: The "Control Panel" This is where the FinOps magic happens. Instead of searching through lines of code for instance sizes, I centralize all values here.

aws_region        = "us-east-1"
instance_type     = "c6g.2xlarge"
db_instance_class = "db.t4g.medium"

Why separate definitions from values?

Adhering to Cloud excellence standards makes this separation essential. It provides three fundamental benefits:

FinOps Agility: If Infracost warns me that costs are too high, I don't need to hunt for instance types across multiple .tf files. I change only the terraform.tfvars, push the update, and see the new cost calculation instantly.

Security and Reusability: The core code (modules) remains immutable. This prevents accidental architecture errors while only adjusting "parts" (values). It also helps avoid hardcoding sensitive data.

Standardization: For those replicating this lab, having a single configuration file makes learning much more intuitive. You focus on the parameters that truly impact infrastructure and costs.

The Orchestrator: main.tf (Root)

The main.tf file at the root of the project acts as the conductor of an orchestra. It doesn’t create resources directly; instead, it calls the modules we’ve defined and passes the necessary information between them.

In this project, modularization is a strategic choice. I separate the Network (base infrastructure) from the Compute (where costs are more volatile). Here is how the module calls look:

# Network Module: Creates VPC, Subnets, and Gateways
module "network" {
  source     = "./modules/network"
  aws_region = var.aws_region
}

# Compute Module: Creates EC2, RDS, and S3
module "compute" {
  source            = "./modules/compute"
  vpc_id            = module.network.vpc_id
  public_subnet_id  = module.network.public_subnet_id
  private_subnet_id = module.network.private_subnet_id

  # Passing the cost-related variables defined in terraform.tfvars
  instance_type     = var.instance_type
  db_instance_class = var.db_instance_class
}

Why Module Integration Matters

The key takeaway here is interdependency. Notice that the compute module receives the vpc_id and subnets directly from the network module outputs.

Security by Design: By passing the private_subnet_id to the RDS database, I ensure it is never exposed to the public internet.

Flexibility: If I need to overhaul the network architecture, my compute module remains untouched as long as the network outputs remain consistent.

The Resource Layer: modules/compute/recursos.tf

Now that we understand how the orchestrator organizes the execution, let's dive into the layer where the "magic" (and the cost) actually happens: the Compute module.

In this file, I have configured three fundamental AWS services: EC2, RDS, and S3. The key point here is not just creating the resource, but how the variables we defined earlier in terraform.tfvars are applied to control costs.

# EC2 Instance for the Web Server
resource "aws_instance" "web_server" {
  ami           = "ami-0c101f26f147fa7fd" # Amazon Linux 2023
  instance_type = var.instance_type
  subnet_id     = var.public_subnet_id

  tags = {
    Name = "WebServer-FinOps"
  }
}

# RDS Database (PostgreSQL)
resource "aws_db_instance" "database" {
  allocated_storage      = 20
  db_name                = "finopsdb"
  engine                 = "postgres"
  engine_version         = "16.1"
  instance_class         = var.db_instance_class
  username               = "admin"
  password               = "password123" # In prod, use Secrets Manager!
  parameter_group_name   = "default.postgres16"
  skip_final_snapshot    = true
  db_subnet_group_name   = aws_db_subnet_group.default.name
  vpc_security_group_ids = [aws_security_group.db_sg.id]
  storage_type           = "gp3" # Strategic FinOps decision
}

# S3 Bucket for Static Assets
resource "aws_s3_bucket" "assets" {
  bucket = "finops-project-assets-jessica"
}

Strategic Decisions in the Code:

1. Instance Flexibility: Notice that both EC2 and RDS use variables for their classes/types. This allows me to switch from an expensive family (like C5) to a more efficient one (like Graviton/C6g) by simply changing a text file.

2. Smart Storage (gp2 vs gp3): In the RDS resource, I set the storage_type to gp3. This is a classic FinOps recommendation, as gp3 is typically 20% cheaper than gp2 while providing better, independent performance.

3. Security and Isolation: The database is linked to private subnets, ensuring that the cost of security (preventing breaches) is mitigated by proper network design from the start.

Visualizing Results: outputs.tf

After Terraform orchestrates our entire AWS infrastructure, we need a way to retrieve essential data for our daily operations. Outputs act as the "receipt" of the operation.

output "web_server_public_ip" {
  description = "Public IP address of the EC2 instance"
  value       = module.compute.web_server_public_ip
}

output "rds_endpoint" {
  description = "Connection endpoint for the RDS database"
  value       = module.compute.rds_endpoint
}

Inside the Modules: Network and Compute

To ensure our architecture is scalable, each folder within modules/ contains its own set of files. This allows me to test the network module in isolation before even considering the servers.

1. Network Module (modules/network/) This is the foundation. Without a configured VPC and subnets, we have nowhere to "park" our instances.

variables.tf: This is where I define parameters like the VPC CIDR block.

main.tf: Contains the logic to create the VPC, Internet Gateway, and Subnets (public and private).

outputs.tf: This is the crucial part. I need to "export" the VPC ID and Subnet IDs so the compute module can use them.

# modules/network/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "public_subnet_id" {
  value = aws_subnet.public.id
}

output "private_subnet_id" {
  value = aws_subnet.private.id
}

1. Compute Module (modules/compute/)
   This is where Infracost focuses most of its analysis, as it houses the resources that generate direct hourly usage charges.

2. variables.tf: It receives the IDs coming from the network module and the instance classes defined in the root terraform.tfvars.

3. recursos.tf: (Which we have already detailed) where we create the EC2, RDS, and S3.

4. outputs.tf: Returns information such as the server's public IP so I can access it.

Just as the network module exports IDs so we can build our resources, the compute module must return essential information for us to interact with the infrastructure after provisioning.

Since this project focuses on FinOps and governance, having well-defined outputs helps with quick auditing of what has been created.

# modules/compute/outputs.tf

output "web_server_public_ip" {
  description = "Public IP address for SSH or HTTP access"
  value       = aws_instance.web_server.public_ip
}

output "rds_endpoint" {
  description = "Connection endpoint for the database"
  value       = aws_db_instance.database.endpoint
}

Why does this matter?

1. Connectivity: Without the public IP or the database endpoint, the infrastructure exists in AWS but remains inaccessible.

2. Transparency: In GitHub Actions, these values can be displayed at the end of the pipeline, confirming that the resources mapped by Infracost were indeed created as planned.

Technical Breakdown: GitHub Actions & Security

Workload Identity Federation (OIDC)

Security is non-negotiable. By using OIDC, we eliminate the need for persistent AWS Access Keys. The id-token: write permission allows GitHub Actions to request short-lived, temporary tokens directly from AWS, ensuring a "Keyless" and highly secure authentication flow.

In our code, this is enabled by this block:

permissions:
  id-token: write   # Obrigatório para solicitar o token JWT da AWS
  contents: read    # Para ler o código do repositório
  pull-requests: write # Para o Infracost comentar no PR

Setting Up the "Bridge" in AWS (Console)

Step 1: Create the Identity Provider (OIDC)

1. Go to the IAM service in the AWS Console.
2. In the left sidebar, click Identity Providers.
3. Click Add provider.
4. Select OpenID Connect.
5. For Provider URL, paste: [https://token.actions.githubusercontent.com](https://token.actions.githubusercontent.com) and click Get thumbprint.
6. For Audience, type: sts.amazonaws.com.
7. Click Add provider.

Step 2: Create the IAM Role for GitHub Actions

1. In the IAM sidebar, click Roles and then Create role.
2. Select Web Identity.
3. Under Identity provider, select the one you just created.
4. Under Audience, select sts.amazonaws.com.
5. Click Next, add the necessary permissions (e.g., specific Terraform policies), and click Next.
6. Name the role (e.g., GitHubActionsInfracostRole) and create it.

Step 3: Refine the Trust Policy

To ensure only your repository can assume this role, edit the Trust Relationship:

1. Open your new Role, go to the Trust relationships tab, and click Edit trust policy.
2. Ensure the sub condition points strictly to your GitHub repository as shown in the JSON block above.

Workflow Jobs Breakdown

1. Baseline Main: Captures the current infrastructure cost from the main branch.

2. Diff Analysis: Compares your new Pull Request code against the baseline to calculate the exact financial impact.

3. Post Results: Delivers a visual cost breakdown directly into the PR. The continue-on-error: true setting ensures that minor commenting issues don't block critical deployments.

Why Developer Feedback Matters?

Bringing cost visibility into the PR phase allows for immediate course correction. It empowers developers to align architectural choices with Cost Optimization and Sustainability (CO_2e) before a single cent is spent.

Impact on Pull Request (PR)

Strategic Insight: Notice that by switching from a t3.micro instance to an m5.large, Infracost immediately alerts us to the spike in monthly costs and CO_2e emissions. Having this visibility empowers developers to make informed architectural choices—such as opting for Graviton instances or gp3 storage—directly impacting the business's bottom line and sustainability goals.

Conclusion: The Future of Infrastructure is Conscious

Implementing FinOps is not just about reducing the bill at the end of the month; it’s about fostering a culture of accountability and transparency. Throughout this lab, we’ve seen that it is entirely possible to bridge security (via OIDC), governance (via Tags), and cost visibility directly within the development lifecycle.By bringing cost estimation into the Pull Request, we eliminate the financial "blind spot."
Developers evolve from simply consuming resources to becoming conscious architects, capable of pivoting toward more efficient solutions—such as Graviton instances or gp3 storage—before a single cent is even spent.This project serves as a practical example of how technology can be leveraged to build more sustainable and well-managed systems.
Ultimately, every CO_2e saved and every dollar optimized contributes to a more mature and resilient operation.

I hope this guide assists fellow students and professionals on their cloud journey! 🚀

📂 Project Repository

All the code detailed in this article, including the networking and compute modules and the GitHub Actions workflow, is available on my GitHub. Feel free to clone, test, and contribute!