AWS Builder Center

Builder Center

Terraform CI/CD: Automate AWS Infrastructure

Learn how GitHub Actions automates Terraform workflows, from validating infrastructure code to reviewing plans and safely managing AWS resources.

Series: My 90-Day AWS & DevOps Learning Journey (27 articles)

  1. 1
    What Is Cloud Computing? Understanding AWS from a Beginner's Perspective
  2. …
  3. 26
    Terraform CI/CD: Automate AWS Infrastructure This article
  4. 27
    Ansible vs Terraform: What's the Difference?

Terraform CI/CD: Automate AWS Infrastructure

Imagine making a small change to your AWS infrastructure configuration.
You update a Terraform file, save it, and prepare to apply the change.
But how can your team check the configuration, review the proposed changes, and reduce the risk of mistakes before modifying real infrastructure?
This is where Terraform CI/CD becomes useful.
As I continue learning AWS and DevOps, I'm exploring how Infrastructure as Code can work together with automation to make infrastructure changes more consistent and easier to review.

What Is Terraform CI/CD?

Terraform CI/CD combines Infrastructure as Code with an automated pipeline.
Instead of relying entirely on manual commands, a pipeline can validate Terraform configuration, generate a plan, and help a team review proposed infrastructure changes.
For this article, I'll use GitHub Actions as the automation tool.
A simplified workflow looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Developer Updates Terraform
↓
GitHub Repository
↓
GitHub Actions
↓
Format and Validate
↓
Terraform Plan
↓
Review Changes
↓
Approved Apply Step
↓
AWS Resources
The important point is that planning and applying infrastructure changes are different steps. A responsible workflow reviews the plan before making changes.

Step 1: Store Terraform Code in Git

A typical repository might look like this:
1
2
3
4
5
6
7
8
terraform-aws-project/
├── main.tf
├── variables.tf
├── outputs.tf
├── versions.tf
└── .github/
└── workflows/
└── terraform.yml
Git helps track changes to the infrastructure configuration.
If a developer changes a security group, for example, the team can review that change before it reaches AWS.

Step 2: Validate the Configuration

Terraform provides commands that are useful in automated pipelines.
Format the code:
1
terraform fmt -check -recursive
This checks whether the Terraform files follow the expected formatting.
Initialize Terraform:
1
terraform init -backend=false
This initializes the working directory without configuring a backend for this validation example.
Validate the configuration:
1
terraform validate
Validation checks the configuration's syntax and internal consistency. It does not prove that the infrastructure will deploy successfully or that the configuration is secure.
These checks provide quick feedback before attempting to change AWS resources.

Step 3: Automate Checks With GitHub Actions

A basic workflow can run formatting and validation checks whenever code is pushed or a pull request is opened.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
name: Terraform Validation

on:
push:
pull_request:

permissions:
contents: read

jobs:
validate:
runs-on: ubuntu-latest

steps:
- name: Checkout repository
uses: actions/checkout@v4

- name: Set up Terraform
uses: hashicorp/setup-terraform@v3

- name: Check formatting
run: terraform fmt -check -recursive

- name: Initialize Terraform
run: terraform init -backend=false

- name: Validate configuration
run: terraform validate
This example demonstrates automated validation. It doesn't authenticate with AWS, create a plan against real infrastructure, or apply changes.
For a real project, pin actions to trusted versions or commit SHAs according to your organization's security practices, and configure the correct Terraform version and providers.

Step 4: Add a Terraform Plan

After basic validation, a more advanced pipeline can generate a Terraform plan.
1
terraform plan -out=tfplan
The plan shows what Terraform proposes to create, update, or destroy.
For example:
1
2
3
Plan: 1 to add,
1 to change,
0 to destroy.
This is an illustrative example, not the output of a real deployment.
A plan can help reviewers identify unexpected changes before they affect AWS infrastructure.
However, plan files can contain sensitive information. They should be protected, access-controlled, and handled carefully when stored or shared.

Step 5: Configure AWS Access Securely

A pipeline that needs to inspect or manage AWS resources requires suitable AWS permissions.
One recommended approach for GitHub Actions is OpenID Connect (OIDC), which can allow a workflow to assume an AWS IAM role without storing long-lived AWS access keys in GitHub secrets.
A secure setup should include:
  • An IAM role with least-privilege permissions
  • A trust policy restricted to the intended repository and workflow context
  • Appropriate GitHub Actions permissions for requesting an OIDC token
  • Protected branches or environments for sensitive deployments
  • Careful handling of Terraform state and plan artifacts
Never put AWS access keys directly in Terraform files or workflow YAML.

Step 6: Require Review Before Applying

Automatically applying every infrastructure change can be risky.
A safer workflow separates validation, planning, and applying.
For example:
1
2
3
4
5
6
7
8
9
10
11
Pull Request
↓
Validate Configuration
↓
Generate Plan
↓
Human Reviews Changes
↓
Approval
↓
Apply to AWS
For production environments, an approval gate can help prevent accidental resource deletion, overly permissive security groups, and unexpected infrastructure changes.
The exact implementation depends on the team's deployment process and how it manages plan artifacts and state.

Why Does This Matter for DevOps?

Terraform defines the infrastructure.
Git tracks configuration changes.
GitHub Actions automates checks and workflow steps.
AWS provides the resources being managed.
Together, these tools can create a more repeatable infrastructure workflow:
Code → Validate → Plan → Review → Apply
This approach can improve consistency and make infrastructure changes easier to understand, review, and audit.

My Learning Journey

My recent learning has moved from Terraform fundamentals to state management and reusable modules.
Now I'm exploring how CI/CD can bring those concepts together.
I want to understand not just how to create an AWS resource, but how a team can safely maintain it as an application grows.
That is an important step toward building practical cloud and DevOps skills.

💬 Let's Discuss

For your first Terraform CI/CD pipeline, which step would you automate first: formatting and validation, generating a plan, or applying changes after approval? Why?
If you've already automated Terraform, what was your biggest challenge: AWS authentication, remote state, reviewing plans, or protecting production deployments?
I'd love to hear what worked for you and what you would recommend to someone building their first project.
# devops# developer-tools# terraform# github

Series: My 90-Day AWS & DevOps Learning Journey (27 articles)

  1. 1
    What Is Cloud Computing? Understanding AWS from a Beginner's Perspective
  2. …
  3. 26
    Terraform CI/CD: Automate AWS Infrastructure This article
  4. 27
    Ansible vs Terraform: What's the Difference?
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article