Introduction Like many cloud enthusiasts, I started my AWS journey using the Management Console—clicking through wizards, manually selecting subnets, and hoping I didn’t forget a configuration step. It works, but it’s prone to human error and hard to replicate. This week, I decided to level up. I started learning Terraform to embrace Infrastructure as Code (IaC). In this post, I’ll walk you through my very first hands-on task: provisioning a custom network stack and launching an EC2 instance entirely through code.

The Architecture Instead of just launching a default instance, I wanted to build the network from scratch to understand how the components connect. Here is what I built:

• VPC: A custom Virtual Private Cloud.
• Subnet: A public subnet for the instance.
• Internet Gateway (IGW): To allow internet access.
• Route Table: Configuring routes to the IGW.
• Security Group: Allowing SSH, HTTP, and HTTPS.
• EC2 Instance: The server itself.

Why Terraform? Before diving into the code, here are the immediate benefits I realized while working on this: Speed: I can destroy and recreate the entire infrastructure in seconds with one command. No Human Error: No more accidentally clicking the wrong checkbox. The code is the source of truth. Documentation: The code itself acts as documentation for the infrastructure.

The Code Here is a look at the main.tf file I created.

1. The Network Setup First, we define the VPC and the Internet Gateway. `resource "aws_vpc" "terra-vpc" { cidr_block = "10.0.0.0/16" tags = { Name = "terra-vpc" } }

resource "aws_internet_gateway" "terra-igw" { vpc_id = aws_vpc.terra-vpc.id }

resource "aws_subnet" "terra-subnet1" { vpc_id = aws_vpc.terra-vpc.id cidr_block = "10.0.1.0/24" }`

2. Security Groups This was the trickiest part! I learned that enabling traffic requires specific ingress (incoming) and egress (outgoing) rules. `resource "aws_security_group" "terra-ec2-sg" { name = "terraform-ec2-sg" vpc_id = aws_vpc.terra-vpc.id }

Allow SSH from anywhere resource "aws_vpc_security_group_ingress_rule" "allow_ssh" { security_group_id = aws_security_group.terra-ec2-sg.id cidr_ipv4 = "0.0.0.0/0" from_port = 22 to_port = 22 ip_protocol = "tcp" }

Allow all outbound traffic resource "aws_vpc_security_group_egress_rule" "allow_all" { security_group_id = aws_security_group.terra-ec2-sg.id cidr_ipv4 = "0.0.0.0/0" ip_protocol = "-1" # Represents all protocols }`

3. The Instance Finally, tying it all together by launching the EC2 instance inside our new security group and subnet. `resource "aws_instance" "first_terra_instance" { ami = "ami-02b8269d5e85954ef" # Check your region! instance_type = "t3.micro" key_name = "terra-key-pair" vpc_security_group_ids = [aws_security_group.terra-ec2-sg.id] subnet_id = aws_subnet.terra-subnet1.id

tags = { Name = "Terraform-EC2" } }`

The Workflow: 4 Magic Commands Learning the syntax is one thing, but understanding the lifecycle is another. These are the four commands I used constantly:

- terraform init: Initializes the directory and downloads the necessary AWS providers. - terraform validate: A lifesaver! It checks your code for syntax errors before you even try to run it. - terraform plan: This is my favorite. It shows a "dry run" of what will be created, changed, or destroyed. It gives you confidence before making changes. - terraform apply: The command that actually makes the API calls to AWS to build the resources.

Conclusion Building this project gave me a much deeper appreciation for modern DevOps practices. It’s empowering to see an empty AWS account populate with resources just by typing terraform apply. My next step? I plan to look into Terraform Variables to stop hardcoding values and make this script reusable for different environments. If you are just starting with cloud, I highly recommend picking up Terraform. It changes the way you look at infrastructure!

Have you worked with Terraform? What was the first resource you automated? Let me know in the comments! 👇