AWS CLI & Terraform for Beginners: Deploying Infrastructure as Code (Part-2)

In the previous article, we saw how to set up Terraform to build our infrastructure using code. Now, we’ll learn how to use GitLab’s automation to deploy our changes. That means whenever we change something in our code, GitLab will automatically apply those changes—so we don’t have to do it by hand every time.

Setup Overview

• Version Control with GitLab: Store your Terraform configurations in a GitLab repository. This approach takes advantage of GitLab’s version control capabilities to track and review changes in infrastructure code.

• Automated Pipelines: Utilize GitLab CI/CD pipelines to automate the process of testing and deploying the Terraform configurations. Pipelines can be configured to trigger on commits, merging requests, or manual requests.

• AWS Integration: Configure Terraform to manage AWS resources by using the AWS provider. The AWS credentials and access controls should be securely managed, often using environment variables or encrypted secrets in GitLab.

Typical Pipeline Steps

• Initiate: Initialize Terraform configurations in the pipeline. This step sets up Terraform to manage the specified resources.

• Validate: used to verify the correctness of Terraform configuration files within a directory. It performs a static analysis of the configuration to ensure it is syntactically valid and internally consistent.

• Plan: Execute terraform plan to preview changes without applying them. This helps in reviewing potential impacts before changes go live.

• Apply: Run terraform apply to apply the planned changes to your AWS environment. This step can be set to manual to require approval, ensuring changes are reviewed.

• Destroy: The terraform destroy command is used to delete all infrastructure that Terraform has created and is currently managing. it removes all resources defined in your .tf files and tracked in the state file — EC2 instances, VPCs, S3 buckets, etc.

Use Protected Variables
Store sensitive information like cloud provider credentials
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, GITLAB_USERNAME, and GITLAB_TOKEN as protected CI/CD variables.

Please see below guides:

GitLab access token

Amazon access key

GitLab CI/CD variable

Create a .gitlab-ci.yml file:

Define the CI/CD pipeline stages and terraform image.

# Global variables
variables:
  TF_ROOT: "terraform"
  STATE_FILE_NAME: "terraform.tfstate" 
  TF_ADDRESS: "https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${STATE_FILE_NAME}"
  TF_USERNAME: ${GITLAB_USERNAME}
  TF_PASSWORD: ${GITLAB_TOKEN}

default:
  image:
    name: hashicorp/terraform:latest
    entrypoint: [""]
  cache:
    - key: "${CI_COMMIT_REF_SLUG}-terraform"
      paths:
        - $TF_ROOT/.terraform/
        - $TF_ROOT/.terraform.lock.hcl


# Define stages
stages:
  - init
  - validate
  - plan
  - apply
  - destroy


before_script:
  - echo "Initializing Terraform in $TF_ROOT"
  - export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
  - export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
  - cd $TF_ROOT

terraform_init:
  stage: init
  script:
  - terraform --version
  - terraform init 
    -backend-config=address=${TF_ADDRESS}
    -backend-config=lock_address=${TF_ADDRESS}/lock
    -backend-config=unlock_address=${TF_ADDRESS}/lock
    -backend-config=username=${TF_USERNAME}
    -backend-config=password=${TF_PASSWORD}
    -backend-config=lock_method=POST
    -backend-config=unlock_method=DELETE
    -backend-config=retry_wait_min=5
  artifacts:
    paths:
      - $TF_ROOT/.terraform
      - $TF_ROOT/.terraform.lock.hcl
    expire_in: 1 hour


terraform_validate:
  stage: validate
  script:
    - terraform fmt -check -recursive
    - terraform validate
  dependencies:
    - terraform_init


terraform_plan:
  stage: plan
  script:
     - terraform plan -out=tfplan
  dependencies:
    - terraform_validate
  artifacts:
    paths:
      - $TF_ROOT/tfplan
    expire_in: 1 hour  
    when: on_success

  only:
    - main
    - /^feature\/.*$/

# Stage for applying the Terraform apply

terraform_apply:
  stage: apply
  script:
    - terraform show tfplan 
    - terraform apply -auto-approve tfplan

  artifacts:
    paths:
      - $TF_ROOT/terraform.tfstate
    expire_in: 1 hour
  when: manual
  only:
    - main
    - /^feature\/.*$/

terraform_destroy:
  stage: destroy
  script:
    - terraform destroy -auto-approve
  when: manual
  only:
    - main
    - /^feature\/.*$/

⚠️ Note : apply/destroy is not recommended on feature branches.

• Use terraform plan only on feature branches
• Gate apply/destroy behind merge to a protected branch
• Require approvals or deploy tags to trigger apply
• Use plan outputs to validate changes before applying

Amazon web console

Once you run terraform apply, Terraform provisions or updates your EC2 instance(s) based on the configuration in your .tf files. Here's what you'll see in the Amazon Web Console after a successful apply

Terraform destroy

After a terraform destroy, your EC2 instance is gone — but if you want to run a post-destroy job, such as cleanup tasks, notifications, or archiving logs, you’ll need to orchestrate it outside Terraform since Terraform doesn’t natively support post-destroy hooks.

✅ Easy Post-Destroy Steps

• Run a cleanup script after terraform destroy
• Remove leftover resources (like EBS volumes or Elastic IPs)
• Send a notification (Slack, email, etc.)
• Archive logs or Terraform state
• Delete secrets and SSH keys linked to the EC2 instance
• Validate in AWS Console that everything’s gone
• Optional: Use a wrapper script or CI/CD job to automate all this

Terraform Project Structure

repo-root/
├── terraform/
│ ├── main.tf
│ ├── variables.tf
│ ├── outputs.tf
│ └── ...
└── .gitlab-ci.yml

variables.tf

variable "region" {
  description = "AWS region"
  type        = string
  default     = "ap-southeast-2"
}

variable "ami_id" {
  description = "AMI ID for the EC2 instance"
  default     = "ami-0310483fb2b488153"
  type        = string
}

variable "instance_type" {
  description = "Instance type for the EC2 instance"
  type        = string
  default     = "t2.micro"
}

main.tf

provider "aws" {
  region = var.region
}

resource "aws_instance" "my_instance" {
  ami           = var.ami_id
  instance_type = var.instance_type
}

outputs.tf

output "web_server_public_ip" {
  value       = aws_instance.my_instance.public_ip
  description = "The public IP address of the web server."
}

🧩 Workflow Overview

1. terraform init

• Initializes working directory.
• Downloads required provider plugins (e.g., AWS).
• Sets up backend if remote state is configured.

2. terraform validate

• Validates .tf syntax and structure.
• Ensures configuration is logically sound.

3. terraform plan

• Generates an execution plan.
• Displays actions Terraform will take:
  • Create EC2 instance
  • Attach security group
  • Allocate volumes
• Allows review before making any changes.

4. terraform apply

• Executes the plan by interacting with AWS APIs.
• Creates the EC2 instance with specified parameters:
  • AMI ID
  • Instance type
  • Key pair
  • Subnet
• Applies tags and IAM roles (if defined).
• Prompts for approval unless -auto-approve is used.

5. 📡 Provisioning via AWS

• AWS provisions the instance in your chosen region and AZ.
• Network interfaces, volumes, and security configurations are applied.
• Terraform waits until the EC2 reaches the running state.

6. terraform state update

• .tfstate file is modified to reflect actual infrastructure.
• Stores metadata including EC2 instance ID, IP, etc.
• Essential for managing future changes and avoiding drift.

7. Output Variables (optional)

• Displays configured outputs:
  • Public IP
  • Instance hostname
  • EC2 tags, etc.

References

🧠 AI Assistance — Content and explanations are partially supported by ChatGPT, Microsoft Copilot, and GitLab Duo, following AWS documentations.