DEV Community

Benjamin Tetteh
Benjamin Tetteh

Posted on

Building My First AWS VPC with Terraform: A Beginner-Friendly Guide for Career Changers

#aws #terraform #devops #beginners

Terraform VPC setupNot long ago, terms like “VPC,” “subnet,” and “Terraform” would have made my eyes glaze over. While my background wasn’t originally rooted in cloud engineering, I’ve always been fascinated by how modern infrastructure is designed, automated, and scaled behind the scenes.

Now, partway through my DevOps journey, I’ve gone from simply reading about cloud infrastructure to actually building it, using Terraform to provision a fully functional AWS network entirely through code.

If you're reading this while sitting at a career crossroads — maybe you're a teacher, an accountant, a customer service rep, or anyone wondering "can I really break into tech?" I want this post to be your proof that yes, you absolutely can.

Before we touch any code...

Let's understand why everything exists. Tools make a lot more sense that way. Think of it like building a neighbourhood. Imagine you're a city planner given a plot of land. Your job is to:

Draw the boundary of the land — this is your VPC (Virtual Private Cloud). It defines your space in AWS. Nothing gets in or out unless you say so.

Divide the land into zones — some areas are public (like a shopping street anyone can visit) and some are private (like a gated estate — no outsiders allowed).

Build a gate to the outside world — this is the Internet Gateway (IGW). The single controlled entrance between your network and the internet.

Set the traffic rules — Route Tables tell your network traffic exactly where to go, like road signs.

💡 Why Terraform instead of clicking around in AWS?
Clicking in the AWS console is slow, hard to repeat, and easy to mess up. Terraform lets you write your infrastructure as code — describe what you want, run one command, and it builds everything consistently every time. This is called Infrastructure as Code (IaC) and employers actively look for this skill.

The project structure 

terraform-vpc/
├── main.tf       # The blueprint — everything to build
├── variables.tf  # The settings — values we can change
└── outputs.tf    # The receipt — shows what got created
Enter fullscreen mode Exit fullscreen mode

Think of main.tf as the architect's drawing, variables.tf as the customizable options, and outputs.tf as the summary report after construction is done.

Step 1: Setting up Terraform — the provider block

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

provider "aws" {
  region = var.region
}
Enter fullscreen mode Exit fullscreen mode

The first block tells Terraform: "We're working with AWS, and we want version 5 of the AWS plugin." That plugin is called a provider — think of it as an adapter that lets Terraform talk to AWS.

The second block specifies which AWS region to build in. A region is a physical location with Amazon data centres — us-east-1 is Northern Virginia, USA.

Notice var.region? That means: "look up the value of region in my variables file."

Step 2: Creating the VPC — your cloud neighbourhood

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name = "main-vpc"
  }
}
Enter fullscreen mode Exit fullscreen mode

The cidr_block defines the total size of your network. 10.0.0.0/16 gives us room for up to 65,536 addresses — a big plot of land!

tags are just labels to help you find your resources in the AWS console. Always tag. Your future self will thank you.

Step 3: Internet Gateway — the front gate

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}
Enter fullscreen mode Exit fullscreen mode

Without this, your VPC is sealed off — like a neighbourhood with no road to the outside world. Notice vpc_id = aws_vpc.main.id? Terraform links resources like this. It figures out the build order automatically.

Step 4: Subnets — carving the zones

# Public subnet (the shopping street)
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  tags = { Name = "main-public-subnet" }
}

# Private subnet (the gated estate)
resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
  tags = { Name = "main-private-subnet" }
}
Enter fullscreen mode Exit fullscreen mode

We're carving our big VPC into zones. The public subnet (10.0.1.0/24) is for resources that need internet access, like web servers. The private subnet (10.0.2.0/24) is for sensitive things like databases — no direct internet access. The /24 gives each subnet 256 addresses.

Step 5: Route tables — the traffic signs

# Public route table + association + internet route
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-public-rt" }
}
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}
resource "aws_route" "public_igw" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.main.id
}

# Private route table + association (no internet route)
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-private-rt" }
}
resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private.id
  route_table_id = aws_route_table.private.id
}
Enter fullscreen mode Exit fullscreen mode

The key line is destination_cidr_block = "0.0.0.0/0" pointing to the IGW. 0.0.0.0/0 means "any address on the internet" — this is what makes the public subnet actually public.

The private subnet gets its own route table but no internet route — isolated by design. The associations are the connectors that glue each table to its subnet.

Step 6: Variables — the settings file

variable "region" {
  type        = string
  description = "AWS region to deploy resources in"
  default     = "us-east-1"
}

variable "vpc_cidr_block" {
  type        = string
  description = "CIDR block for the VPC"
  default     = "10.0.0.0/16"
}
Enter fullscreen mode Exit fullscreen mode

Instead of hardcoding "us-east-1" everywhere, we define it once here. Want to deploy to a different region? Change it in one place, not everywhere. Clean, reusable, professional.

Step 7: Outputs — the receipt

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
}
Enter fullscreen mode Exit fullscreen mode

After Terraform finishes, outputs are printed in your terminal — like a receipt. Instead of logging into AWS to find your VPC ID, Terraform just hands it to you.

The full architecture
The full architecture

Challenges I Faced
Like every beginner, I made mistakes:

  • Using quotes incorrectly around variables inside main.tf which broke my configuration
  • Confusion around route tables and associations
  • Understanding how IGW actually connects to subnets
  • Debugging Terraform errors for the first time

But each error helped me understand AWS networking better.

What's next?

This VPC is the foundation. In future posts, I'll be covering launching EC2 instances inside this VPC, adding security groups (the bouncers of the cloud), and exploring remote state management with S3. Follow along!

Top comments (1)

Collapse
 
devjp profile image
Justin •

An excellent introductory post with good security posture, very clean examples too. I look forward to reading your next posts on populating your new TF-managed VPC.