DEV Community: Jessica Aparecida Bueno

FinOps Hands-On: AWS Costs + CO_2e in Every PR with Infracost & Terraform

Jessica Aparecida Bueno — Sat, 02 May 2026 14:45:53 +0000

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:

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
}

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:

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.
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.
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.

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
}

Compute Module (modules/compute/)
This is where Infracost focuses most of its analysis, as it houses the resources that generate direct hourly usage charges.
variables.tf: It receives the IDs coming from the network module and the instance classes defined in the root terraform.tfvars.
recursos.tf: (Which we have already detailed) where we create the EC2, RDS, and S3.
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?

Connectivity: Without the public IP or the database endpoint, the infrastructure exists in AWS but remains inaccessible.
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)

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

Step 2: Create the IAM Role for GitHub Actions

In the IAM sidebar, click Roles and then Create role.
Select Web Identity.
Under Identity provider, select the one you just created.
Under Audience, select sts.amazonaws.com.
Click Next, add the necessary permissions (e.g., specific Terraform policies), and click Next.
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:

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

Workflow Jobs Breakdown

Baseline Main: Captures the current infrastructure cost from the main branch.
Diff Analysis: Compares your new Pull Request code against the baseline to calculate the exact financial impact.
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!

JessicaApBueno / infracost_aws

FinOps Hands-On: Custos AWS + CO₂e em Todo PR com Infracost & Terraform

Este repositório contém um laboratório prático de FinOps na AWS usando Terraform, GitHub Actions e Infracost.

A proposta é trazer visibilidade de custos para mais perto do desenvolvimento, permitindo que cada Pull Request mostre o impacto financeiro da mudança antes do deploy.

Objetivo

O projeto demonstra como integrar:

Terraform para provisionamento de infraestrutura.
Infracost para estimativa de custos antes da implantação.
GitHub Actions para automação do fluxo de CI/CD.
OIDC para autenticação segura na AWS sem chaves de longa duração.
Tags padronizadas para governança e rastreabilidade.
CO₂e como apoio a decisões mais sustentáveis.

Arquitetura

A infraestrutura está organizada em módulos:

modules/network: cria a base de rede com VPC, subnets e componentes de conectividade.
modules/compute: cria os recursos de aplicação e banco.
.github/workflows/infracost.yml: executa o fluxo de custo no Pull Request.
providers.tf…

View on GitHub

Cloud Simplified: Hands-on DevSecOps Lab with Terraform and LocalStack

Jessica Aparecida Bueno — Thu, 19 Mar 2026 01:54:52 +0000

Demystifying the Cloud: A Practical DevSecOps Lab with Terraform and LocalStack

Imagine being able to test your entire AWS infrastructure with rigorous security validation and professional automation, without spending a single cent.

In the real world, cloud mistakes are expensive. That's why simulation environments and well-structured CI/CD pipelines are "game changers" for a Cloud Engineer.

🚀 The Protagonist: LocalStack

To make this zero-cost environment possible, I used LocalStack. It is a cloud service emulator that runs in a single Docker container on your local machine or within CI/CD environments.

How does it work? LocalStack intercepts the API calls you would send to the real AWS and processes them locally. For your Terraform, it's as if it were talking to the true cloud, but the data and resources never leave your controlled environment.
How to start locally? If you want to run it manually on your machine for quick experiments, just run:

localstack start -d

In this project, however, LocalStack is started automatically by the GitHub Actions pipeline — you don't need to run it locally for the CI/CD flow to work. The local command above is optional, useful for manual testing before pushing.

Official Documentation: To explore all supported services, you can access the LocalStack Documentation.

🌟 Overview

This project was born from the need to unite theory and practice in a DevSecOps scenario. The main goal isn't just to "create a resource," but to build a learning journey on how IaC (Infrastructure as Code) and Automation technologies integrate into the daily routine of a technology team.

🛡️ The "Sec" in DevSecOps: Why is this not just another automation project?

We often hear the term DevOps, but when we add Sec (Security) in the middle, we are talking about a paradigm shift called Shift Left. In practice, this means bringing security to the beginning of the development cycle rather than leaving it as a final task before deployment.

In this lab, security is not optional; it is a structural part of the pipeline. Here's how I transformed a delivery flow into a secure delivery flow:

Shift Left with Static Analysis (tfsec)

Unlike a traditional flow where you would create the resource and then run a scanner, here I used tfsec directly in GitHub Actions — running it before LocalStack even starts:

The code is analyzed even before any resource is simulated or created.
In this lab, soft_fail: true is configured so that security warnings appear in the logs without blocking the pipeline — allowing you to observe and learn from each finding. In a real production environment, this flag would be removed, making tfsec a hard gate: any critical vulnerability would immediately stop the pipeline.

Secure Infrastructure by Design (Hardening)

The developed S3 module doesn't just focus on creating the bucket, but on its Hardening:

Public Access Block: I implemented features that prevent the bucket from being accidentally exposed to the internet.
AES256 Encryption: Ensures that data at rest is always protected.
Versioning: Added a recovery layer against accidental deletions or malicious attacks.

Security as a Troubleshooting Culture

During development, the pipeline "broke" several times due to tfsec alerts. In a common scenario, a developer might simply disable the scanner. Here, the approach was remediation: understanding the pointed risk (like the lack of public_access_block) and updating the code to meet market security standards.

"DevSecOps is not about tools; it's about not allowing delivery speed to compromise data integrity."

🎯 Why this Lab?

Often, when studying cloud, we hit the fear of costs or the complexity of setting up a pipeline from scratch. This lab was designed to be a safe learning environment, where I applied concepts of:

Modularization: How to organize files so that the code is reusable.
Preventive Security (Shift Left): How to use scanning tools (tfsec) to block security errors before the resource even exists.
Local Simulation: How to bypass physical and financial limitations using LocalStack to emulate complex AWS services.

🛠️ The Tech Stack: The Automation "Engine"

For this ecosystem to work in harmony, I selected industry-standard tools that complement each other perfectly:

Terraform: The choice for IaC. It allows defining infrastructure through declarative code, ensuring the environment is replicable and free from error-prone manual configurations.
LocalStack: Emulates a complete AWS cloud inside a Docker container on the GitHub runner, allowing testing of resources like S3 without generating real costs on the AWS account.
GitHub Actions: The CI/CD engine. It orchestrates the execution of validation, security, and simulation jobs on every git push.
tfsec: The static analysis tool that ensures the "Sec" of DevSecOps, scanning the code for insecure configurations before deployment.

📂 Organization and Structure: Thinking at Scale

A professional infrastructure project cannot be a "single file." The folder organization reflects the maturity of the code and facilitates maintenance by other engineers.

localstack-terraform-lab/
├── .github/workflows/
│   └── terraform.yml       # Where the automation magic happens
├── modules/
│   └── s3-bucket/          # Our reusable and secure component
│       ├── main.tf         # Security logic and S3 resources
│       └── variables.tf    # Module parameterization
├── main.tf                 # Entry point (calling modules)
├── provider.tf             # LocalStack and AWS Provider configuration
└── variables.tf            # Global project variables

In this structure, the highlight goes to the modules/ folder. Instead of creating the bucket directly in the root, the logic was isolated within a reusable module. This means that if 10 more buckets are needed tomorrow, they will all strictly follow the same security standard we defined once.

🏗️ Dissecting the Pipeline: The `terraform.yml` Workflow

The heart of this automation resides in the .github/workflows/terraform.yml file. It is divided into three major pillars (Jobs) that ensure project integrity.

Header and Trigger

name: Terraform Professional CI
on: [push]

name: The name that will appear in the GitHub "Actions" tab. Choosing a professional name helps quickly identify the purpose of the automation.
on: [push]: Defines the trigger. Every time new code is sent to the repository, the pipeline comes to life automatically.

Job 1: Check Code Quality (Validation)

This is the first quality filter. It ensures the code is well-written before anything else happens.

jobs:
  validate:
    name: "Check Code Quality"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init -backend=false
      - run: terraform validate

runs-on: ubuntu-latest: Tells GitHub to provision a clean Linux virtual machine to run these commands.
actions/checkout@v4: Makes the virtual machine download your code from the repository.
terraform init -backend=false: A crucial learning. Since we use local modules, Terraform needs to "install" them before validating. We use -backend=false because we don't need a real cloud connection at this stage.
terraform validate: The command that checks for missing brackets, typos, or incorrectly declared variables.

Job 2: Security Scan

This is where DevOps becomes DevSecOps.

  security:
    name: "Security Scan"
    needs: validate
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tfsec
        uses: aquasecurity/tfsec-action@v1.0.0
        with:
          soft_fail: true

needs: validate: Creates the dependency between jobs. The Security Scan only starts if the Quality Validation passes.
aquasecurity/tfsec-action: The "security inspector." It scans the code for vulnerabilities, such as S3 buckets without encryption or with public access enabled.
soft_fail: true: A deliberate choice for this lab context. It allows security warnings to appear in the logs without blocking the pipeline, so you can observe all findings and plan your remediations. Important: in a real production pipeline, this flag should be removed — making tfsec a hard blocker that stops the pipeline on any critical finding.

Job 3: LocalStack Plan (Simulation)

The final stage, where the infrastructure is simulated in the zero-cost cloud.

  terraform-plan:
    name: "LocalStack Plan"
    needs: security
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Start LocalStack
        uses: localstack/setup-localstack@main
      - uses: hashicorp/setup-terraform@v3
      - name: Terraform Init & Plan
        run: |
          terraform init
          terraform plan
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_DEFAULT_REGION: us-east-1

localstack/setup-localstack: Starts a Docker container with LocalStack, creating an AWS simulator inside the GitHub runner.
terraform plan: Generates the execution plan, showing exactly what would be created in real AWS.
env & secrets: Uses GitHub Repository Secrets to inject credentials safely, simulating exactly how you would protect access keys in a real production project.

📦 Hands-on: Building a Secure S3 Module

To keep the project organized and scalable, I developed an isolated module for S3. My intention was to create a security standard I could replicate in any other project. Here is the main.tf of the module, block by block:

The Base Resource

resource "aws_s3_bucket" "this" {
  bucket = var.bucket_name
}

This is where the bucket itself is defined. I used a variable (var.bucket_name) to make the module flexible, allowing different names to be set without changing the module's internal security logic.

Public Access Block (The "Vault Lock")

resource "aws_s3_bucket_public_access_block" "this" {
  bucket = aws_s3_bucket.this.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Four security locks that ensure that even if someone tries to change permissions manually, the bucket will remain private — preventing sensitive data from being accidentally exposed on the internet.

Versioning

resource "aws_s3_bucket_versioning" "this" {
  bucket = aws_s3_bucket.this.id
  versioning_configuration {
    status = "Enabled"
  }
}

With versioning enabled, it's possible to recover previous versions of deleted or accidentally modified files. It's an essential protection layer against human error or ransomware attacks.

Encryption at Rest

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.this.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

This block was added to address the security findings identified by tfsec during the CI/CD pipeline execution. AES256 encryption ensures that all files stored on disk (or simulated in LocalStack) are protected by default.

📥 Flexibility with `variables.tf`

To avoid a "hardcoded" project, I followed one of Terraform's golden rules: never leave fixed values in the middle of the code. Think of variables as function parameters — they allow you to use the same module to create different buckets just by changing the name at the "entry point," without touching the security logic you already validated.

variable "bucket_name" {
  description = "Unique name of the S3 bucket"
  type        = string
}

Description (Living Documentation): In a real team scenario, this avoids any doubt about what that field expects to receive — for other engineers and for your future self.
Type Constraint (Type Safety): By defining the type as string, Terraform validates the input. If a list or number is accidentally passed, Terraform warns you immediately, preventing strange errors during deployment.

"Working with variables is what separates a simple script from professional, scalable infrastructure."

🏗️ The Command Center: Root Files

With the security modules properly built and "locked," it was time to organize the Command Center of the project: the root folder. This is where the pieces connect to LocalStack. Separating the files into provider.tf, main.tf, and variables.tf ensures that each one has a single responsibility, avoiding the hard-to-maintain "monolith."

`provider.tf`: The Bridge and the Security Lock

The Terraform Block: Ensuring the Correct Version

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

Why this? During testing, I noticed that the more recent versions (v6.x) of the AWS Provider had protocol XML errors when talking to LocalStack v4. By pinning the version to ~> 5.0, I ensured stability and avoided the MalformedXML error.

The Provider Block: Pointing to LocalStack

provider "aws" {
  region                      = "us-east-1"
  access_key                  = "test"
  secret_key                  = "test"
  s3_use_path_style           = true
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    s3 = "http://localhost:4566"
  }
}

Skip configurations: These flags (skip_credentials_validation, skip_metadata_api_check, skip_requesting_account_id) are specific to the LocalStack test environment. They tell Terraform not to try validating the "test" keys against real AWS servers. Never use these settings in a real production provider configuration.
Path Style: s3_use_path_style = true because LocalStack handles this URL format for buckets better than the subdomain format used in real cloud.
Endpoints: The most important line — it redirects all S3 traffic to localhost:4566, where LocalStack is listening.

🔐 What About Secrets?

Although the code uses "test" keys (which LocalStack accepts by default), I took care to configure GitHub Secrets in my CI/CD pipeline. This means the real access values are never exposed in the code — they are injected via environment variables, simulating exactly how you would protect access keys for a real AWS account.

`main.tf`: The Conductor

If the modules are the musicians, the root main.tf is the conductor. It doesn't create the bucket by itself; it calls the module I developed and passes the necessary instructions.

module "my_bucket" {
  source      = "./modules/s3-bucket"
  bucket_name = var.bucket_name
}

source: Points to the path of the module folder.
Variable passing: The global variable bucket_name is passed directly into the module's bucket_name input, creating a clean and consistent hierarchy.

`variables.tf`: The Global Control Panel

variable "bucket_name" {
  description = "Bucket name defined at the root level"
  default     = "my-devsecops-study-bucket"
}

This file at the root concentrates all definitions that might change from one environment to another, acting as the project's central control panel.

🔗 How Does It All Connect?

Unlike a manual process where you would run commands one by one in your terminal, the intelligence here lies in the automation. The flow works like a synchronized gear every time I perform a git push:

The Trigger: The moment I send my code to GitHub, the CI/CD pipeline identifies the change and starts the jobs.
The Inspection: Before even thinking about creating the bucket, GitHub Actions runs the validation and security scan. If there's an error in the S3 module or an exposed bucket, the pipeline stops here, protecting the environment.
Scenario Building: Once security gives the green light, GitHub starts a LocalStack container within the execution environment itself.
The Silent Connection: The provider.tf file acts as a GPS, guiding Terraform to the local container using the credentials configured in the repository Secrets.
Plan Delivery: The global main.tf calls the S3 module, injects the name defined in variables.tf, and Terraform generates the final Plan.

This structure allows me to test different configurations simply by changing the code and pushing to the repository — with agility and the confidence that the infrastructure is secure by design and automatically validated.

🏁 Conclusion: What Do I Take from This Lab?

Finishing this project brought me much greater clarity on the role of automation for a Cloud Engineer. More than just writing .tf files, I understood that true excellence lies in creating processes that are secure, repeatable, and cost-efficient.

My biggest lessons:

Security is not the end, it's the beginning: Implementing tfsec taught me that "Shift Left" isn't just a buzzword; it saved me time and prevented vulnerable infrastructure from ever being deployed.
Troubleshooting is part of learning: Solving the MalformedXML error by adjusting the AWS Provider v5.x versions and LocalStack v4 configurations gave me the confidence to handle the real-world "traps" that arise when integrating different tools.
Zero Cost, Maximum Value: LocalStack proved to be an indispensable ally. The freedom to fail, destroy, and rebuild a simulated environment accelerated my learning without the worry of an AWS bill at the end of the month.

The journey to the cloud is continuous, and tools like Terraform and GitHub Actions are the engines that allow me to navigate with safety and agility.

Did you like this project?

You can check out the full code in my repository: JessicaApBueno/localstack-terraform-lab