> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Setting Up the First Group of Resources VPC

> Provision a reusable AWS VPC across environments using the terraform-aws-modules VPC module with Terragrunt, environment-specific inputs, and recommended init plan apply workflow.

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.

![A slide titled "Setting up the first group of resources (VPC)" showing two circular icons: a community/people icon for a community-contributed Terraform module and an AWS logo for terraform-aws-modules/vpc/aws. A rounded "Community Module" button is shown below.](https://mintcdn.com/kodekloud-c4ac6d9a/guoie6wQNxAcGKSL/images/Terragrunt-for-Beginners/Building-our-first-AWS-Demo-with-Terragrunt/Setting-Up-the-First-Group-of-Resources-VPC/terraform-aws-vpc-community-module.jpg?fit=max\&auto=format\&n=guoie6wQNxAcGKSL\&q=85\&s=a00453b3a18563685b6b981716c9d54f)

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.

```hcl theme={null}
# 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

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

```bash theme={null}
cd live/dev/vpc
```

2. Initialize the working directory (downloads modules and providers):

```bash theme={null}
terragrunt init
```

3. Generate and inspect a plan for the proposed changes:

```bash theme={null}
terragrunt plan
```

4. Apply the planned changes to create the VPC:

```bash theme={null}
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](https://github.com/terraform-aws-modules/terraform-aws-vpc)
* Terragrunt documentation: [https://terragrunt.gruntwork.io/](https://terragrunt.gruntwork.io/)
* Terraform documentation: [https://www.terraform.io/docs/index.html](https://www.terraform.io/docs/index.html)

> **[Watch Video](https://learn.kodekloud.com/user/courses/terragrunt-for-beginners/module/07066843-7439-443b-b2d4-d31be3c50c97/lesson/b7c0dd38-e5e9-4dd4-984c-0e42b0b01ba2)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.