Setting Up the First Group of Resources VPC

Let’s provision our first reusable group of resources: a Virtual Private Cloud (VPC) using Terraform modules and Terragrunt. Goal: deploy a reusable VPC across multiple environments (for example, dev and prod) by leveraging the community-maintained Terraform module terraform-aws-modules/vpc/aws. Community modules accelerate delivery by providing well-tested patterns, reducing duplicate code, and improving maintainability. How this works in brief:

Each environment (for example, live/dev/vpc and live/prod/vpc) contains a terragrunt.hcl that points at the VPC module and supplies environment-specific inputs.
Terragrunt downloads the module, renders variables, and runs Terraform commands (init/plan/apply) for that environment.

Typical workflow and steps

Create a terragrunt.hcl file for each environment (for example, dev and prod). Each terragrunt.hcl references the community VPC module and supplies inputs specific to that environment.
From the environment directory, run the Terragrunt CLI to initialize, plan, and apply the configuration.

Example Terragrunt configuration Below is a minimal terragrunt.hcl that references the terraform-aws-modules/vpc/aws module and provides common inputs. Place one version of this file in each environment directory and customize the inputs as needed.

# terragrunt.hcl
terraform {
  source = "git::https://github.com/terraform-aws-modules/terraform-aws-vpc.git?ref=v3.14.0"
}

inputs = {
  name            = "dev-vpc"
  cidr            = "10.0.0.0/16"
  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  private_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
  enable_nat_gateway = true
}

Best practice: pin the module version (for example via ?ref=v3.14.0) to ensure reproducible builds and reduce unexpected changes from upstream. Common inputs reference

Input	Purpose	Example
`name`	Logical name applied to VPC resources	`dev-vpc`
`cidr`	Primary CIDR block for the VPC	`10.0.0.0/16`
`azs`	Availability Zones to spread subnets across	`["us-east-1a","us-east-1b","us-east-1c"]`
`public_subnets`	CIDR blocks for public subnets	`["10.0.1.0/24","10.0.2.0/24","10.0.3.0/24"]`
`private_subnets`	CIDR blocks for private subnets	`["10.0.101.0/24","10.0.102.0/24","10.0.103.0/24"]`
`enable_nat_gateway`	Controls creation of NAT Gateway(s) for egress from private subnets	`true`

Recommended Terragrunt CLI sequence

Change into the environment directory that contains your terragrunt.hcl:

cd live/dev/vpc

Initialize the working directory (downloads modules and providers):

terragrunt init

Generate and inspect a plan for the proposed changes:

terragrunt plan

Apply the planned changes to create the VPC:

terragrunt apply
# Or to skip interactive approval:
terragrunt apply --auto-approve

Customizing for each environment

Keep environment-specific values such as CIDR blocks, AZ lists, subnet sizes, tags, and naming conventions inside each environment’s terragrunt.hcl.
Use the same module source across environments to ensure consistent architecture while varying inputs to meet environment constraints.

Always review the terragrunt plan output before applying—this helps avoid accidental changes. Keep environment-specific values (for example, CIDR blocks and tags) in each environment’s terragrunt.hcl so deployments remain consistent and reproducible.

Links and references

Module: https://github.com/terraform-aws-modules/terraform-aws-vpc
Terragrunt documentation: https://terragrunt.gruntwork.io/
Terraform documentation: https://www.terraform.io/docs/index.html

Introduction

Terragrunt - Good to Know Concepts & Ideas

Terragrunt Configuration

Terragrunt Commands

Terragrunt Functions

Terragrunt Blocks

Terragrunt Attributes

Managing Remote State with Terragrunt

Terragrunt Modules

Building our first AWS Demo with Terragrunt

Conclusion

Terragrunt - Basic Concepts

Setting Up the First Group of Resources VPC

Watch Video