Infrastructure as Code: Building AWS VPC, Security Groups & EC2 with Terraform

Want to stop manually clicking through the AWS console to build your cloud infrastructure? Terraform offers a powerful way to define, deploy, and manage your AWS resources using code. This guide is for DevOps engineers, cloud architects, and developers who need to create repeatable, version-controlled AWS environments.

We’ll walk through setting up a complete AWS environment using Terraform, focusing on creating a custom VPC with proper networking, configuring security groups for controlled access, and deploying EC2 instances that are ready for your applications. You’ll also learn testing strategies to ensure your infrastructure works as expected before you deploy to production.

By the end, you’ll have the skills to transform your infrastructure management from manual processes to automated, code-based deployments that can be versioned, shared, and consistently reproduced.

Understanding Infrastructure as Code Fundamentals

What is Infrastructure as Code and why it matters

Ever tried managing a growing AWS environment manually? It’s like herding cats. You click through the console, set things up, and then somehow need to remember what you did six months later. It’s a nightmare.

That’s where Infrastructure as Code (IaC) comes in. At its core, IaC is about managing your infrastructure through code files rather than manual processes. You write what you want your AWS setup to look like, and tools like Terraform make it happen.

The magic is in the simplicity. Your infrastructure becomes predictable, repeatable, and version-controlled. No more “it works on my account” problems.

Benefits of IaC for AWS deployments

The wins from using IaC with AWS are massive:

Speed: Deploy complex environments in minutes, not days
Consistency: Every deployment is identical, eliminating configuration drift
Version control: Track changes, roll back mistakes, and collaborate like you would with application code
Documentation: Your code IS the documentation of what your infrastructure looks like
Cost control: Easily spin up environments when needed and tear them down when done

Think about the freedom of testing infrastructure changes before applying them. Or spinning up an entire staging environment that perfectly mirrors production with a single command.

Terraform vs. other IaC tools

Why pick Terraform when there are other options? Here’s how it stacks up:

Tool	Approach	Cloud Support	Learning Curve	State Management
Terraform	Declarative	Multi-cloud	Moderate	External state file
AWS CloudFormation	Declarative	AWS only	Steep	Managed by AWS
Ansible	Procedural	Multi-cloud	Moderate	Stateless
Pulumi	Imperative	Multi-cloud	Depends on language	Cloud or local

Terraform strikes the sweet spot with its declarative approach (you describe what you want, not how to do it) and its ability to work across clouds. Plus, HCL (HashiCorp Configuration Language) reads almost like plain English.

Setting up your Terraform environment

Getting started with Terraform is straightforward:

Install Terraform: Download the binary from HashiCorp’s website and add it to your PATH
Configure AWS credentials: Set up your AWS access keys via environment variables or the AWS CLI
Create your workspace: Make a new directory for your Terraform files
Initialize Terraform: Run terraform init to prepare your working directory

After that, you’re ready to create your first .tf file and start defining your AWS infrastructure. The setup might take 10 minutes, but it’ll save you countless hours down the road.

Getting Started with Terraform and AWS

A. AWS provider configuration

Ever tried setting up infrastructure on AWS manually? It’s like playing Jenga with a blindfold on. Terraform makes this way easier, but first you need to tell it how to talk to AWS.

In your Terraform configuration, you’ll need this basic provider block:

provider "aws" {
  region = "us-west-2"
  version = "~> 3.0"
}

Pick a region that makes sense for your use case. If your users are in Europe, maybe go with eu-west-1. For Asia, ap-southeast-1 might be better.

You can also configure multiple providers if you need to deploy resources across different regions:

provider "aws" {
  alias  = "virginia"
  region = "us-east-1"
}

provider "aws" {
  alias  = "oregon"
  region = "us-west-2"
}

B. Authentication and access management

Terraform needs AWS credentials to do its magic. There are several ways to make this happen:

Environment variables – The simplest approach:

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"

Shared credentials file – Terraform will check ~/.aws/credentials
IAM Roles – If you’re running Terraform from an EC2 instance

Never, and I mean NEVER, hardcode your credentials in your Terraform files! That’s a disaster waiting to happen.

For permissions, create an IAM user with only the permissions Terraform needs. The principle of least privilege isn’t just a fancy security term—it’s what keeps you from waking up to a nightmare scenario.

C. Organizing your Terraform project structure

Organization matters. Trust me, you’ll thank yourself later when your project grows.

A solid structure looks something like this:

project/
├── main.tf         # Primary configuration
├── variables.tf    # Input variables
├── outputs.tf      # Output values
├── terraform.tfvars # Variable values (gitignored!)
└── modules/        # Reusable components
    ├── vpc/
    ├── security/
    └── compute/

This modular approach makes your code reusable and easier to understand. Think of modules as Lego blocks you can snap together to build different infrastructures.

For bigger projects, consider using workspaces to manage multiple environments (dev, staging, production) with the same code base.

D. Creating and managing Terraform state

Terraform state is where the magic happens. It maps your configuration to real-world resources.

By default, Terraform stores state locally in a terraform.tfstate file. This works for personal projects, but for team environments, you’ll want remote state:

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "vpc/terraform.tfstate"
    region = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt = true
  }
}

This S3 backend setup gives you:

State locking with DynamoDB (prevents conflicts)
Encryption for sensitive data
Versioning so you can roll back if needed

Always enable versioning on your S3 bucket. I’ve seen too many teams lose their state file and spend days reconstructing their infrastructure.

Building a Robust AWS VPC

A. Designing your network architecture

Building a solid AWS VPC starts with thoughtful network design. Think of your VPC as the foundation of your cloud infrastructure—get it wrong, and you’ll face painful refactoring down the road.

For most production workloads, consider these key elements:

A CIDR block large enough for future growth (typically /16 or /18)
Multiple availability zones for high availability
Separate public and private subnets
Clear network segmentation for different application tiers

Don’t just copy-paste someone else’s architecture. Your network should reflect your specific requirements around isolation, compliance, and scalability.

B. Creating VPC with appropriate CIDR blocks

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  
  tags = {
    Name = "main-vpc"
  }
}

Picking the right CIDR block isn’t just about having enough IP addresses. It’s about preventing overlaps with your on-premises networks or other VPCs you might need to peer with.

The 10.0.0.0/16 block gives you 65,536 IP addresses—plenty for most workloads. But if you’re building a massive multi-tenant system, you might need something bigger.

C. Configuring subnets across availability zones

High availability isn’t optional anymore. Your Terraform code should spread subnets across multiple AZs:

resource "aws_subnet" "public_a" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = true
}

resource "aws_subnet" "private_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = "us-east-1a"
}

Create matching subnets in other AZs too. A good pattern is using the second octet for AZ designation and the third for subnet type (public/private).

D. Setting up Internet and NAT gateways

Your public subnets need an Internet Gateway:

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
}

For private subnets that need outbound internet access (for updates, package downloads, etc.), create NAT Gateways:

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public_a.id
}

Remember, NAT Gateways aren’t cheap. For dev environments, consider sharing one across all private subnets. For production, deploy one per AZ.

E. Establishing route tables for network traffic

Route tables define the traffic flow in your VPC:

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
}

resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main.id
  }
}

Don’t forget to associate these route tables with your subnets:

resource "aws_route_table_association" "public_a" {
  subnet_id      = aws_subnet.public_a.id
  route_table_id = aws_route_table.public.id
}

This setup gives you a VPC with public-facing resources and protected private resources that can still reach the internet when needed.

Implementing Secure Access with Security Groups

Security Group Best Practices

Security groups are your first line of defense in the AWS cloud. Think of them as virtual firewalls that control traffic to your resources. When using Terraform to manage them, you need to be smart about it.

Always name your security groups descriptively. “web-server-sg” beats “sg-1” any day of the week. Your future self will thank you when troubleshooting at 2 AM.

resource "aws_security_group" "web_server" {
  name        = "web-server-sg"
  description = "Allow HTTP/HTTPS traffic to web servers"
  vpc_id      = aws_vpc.main.id
}

Never use the default security group. It’s like using “password123” for your bank account. Create purpose-built security groups instead.

And please, for everyone’s sake, add good descriptions. Your team members shouldn’t need a decoder ring to figure out what each security group does.

Creating Targeted Security Groups for Different Resources

Different resources need different protection. Your database server doesn’t need the same access rules as your web server.

For web servers, you might want:

resource "aws_security_group" "web_tier" {
  name = "web-tier-sg"
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow HTTP from anywhere"
  }
}

For database servers, you’d be more restrictive:

resource "aws_security_group" "db_tier" {
  name = "db-tier-sg"
  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.web_tier.id]
    description     = "Allow MySQL only from web tier"
  }
}

Managing Ingress and Egress Rules

Ingress rules control who can reach in and touch your resources. Egress rules control where your resources can reach out to.

Most folks obsess over ingress and forget about egress. Big mistake. Proper egress rules can prevent data exfiltration if someone does break in.

In Terraform, you can define rules directly in the security group or as separate resources:

# Separate resource approach
resource "aws_security_group_rule" "allow_https_outbound" {
  type              = "egress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.web_tier.id
  description       = "Allow HTTPS outbound"
}

Implementing the Principle of Least Privilege

The principle of least privilege isn’t just security jargon – it’s your best friend. Give resources exactly the access they need and nothing more.

Don’t do this:

# Too permissive!
ingress {
  from_port   = 0
  to_port     = 65535
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

Do this instead:

# Just right
ingress {
  from_port   = 443
  to_port     = 443
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
  description = "Allow HTTPS traffic"
}

Use references between security groups instead of CIDR blocks when possible. It’s cleaner and more secure:

ingress {
  from_port       = 8080
  to_port         = 8080
  protocol        = "tcp"
  security_groups = [aws_security_group.load_balancer.id]
}

And remember to version your Terraform code in Git. When someone asks “who opened port 22 to the world?”, you’ll have an answer.

Deploying EC2 Instances with Terraform

A. Selecting the right instance types

Choosing the right EC2 instance type can make or break your application’s performance and your budget. When using Terraform to deploy EC2 instances, you’re basically shopping for virtual hardware that matches your workload needs.

For compute-heavy applications, consider C-class instances. Data processing? Go with R-class for memory optimization. And if you need balanced resources, T-class instances work great for most general-purpose workloads.

Here’s a quick comparison of some popular instance families:

Instance Family	Best For	Considerations
t3.medium	Development environments, small web apps	Burstable CPU, cost-effective
m5.large	Production applications, medium traffic	Balanced CPU/memory ratio
c5.xlarge	Compute-intensive tasks, batch processing	High CPU-to-memory ratio
r5.large	In-memory databases, analytics	Memory-optimized

In your Terraform code, define instance types as variables to make switching between environments easier:

variable "instance_type" {
  description = "EC2 instance type"
  default     = "t3.micro"
  type        = string
}

B. Creating reusable EC2 modules

Nobody wants to write the same Terraform code over and over. That’s why modules are a game-changer for EC2 deployments.

A solid EC2 module should include:

module "web_server" {
  source = "./modules/ec2-instance"
  
  name           = "web-server"
  instance_type  = var.instance_type
  ami_id         = var.ami_id
  subnet_id      = module.vpc.public_subnets[0]
  security_group_ids = [aws_security_group.web.id]
  key_name       = var.key_name
  
  tags = {
    Environment = var.environment
    Project     = var.project_name
  }
}

The real power comes when you structure your module to handle different use cases. For example, your module could accept parameters for EBS volumes, IAM instance profiles, and user data scripts.

Store these modules in your team’s shared repository and watch deployment time shrink dramatically.

C. Configuring user data for instance bootstrapping

Getting your EC2 instances configured correctly at launch saves tons of headaches. User data scripts are your secret weapon here.

In Terraform, you can specify user data directly in your EC2 resource:

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type
  
  user_data = <<-EOF
    #!/bin/bash
    yum update -y
    yum install -y httpd
    systemctl start httpd
    systemctl enable httpd
    echo "<h1>Hello from Terraform</h1>" > /var/www/html/index.html
  EOF
}

For more complex setups, use the file function to load scripts:

user_data = file("${path.module}/scripts/bootstrap.sh")

Even better, use templates to make your scripts dynamic:

user_data = templatefile("${path.module}/scripts/setup.sh.tpl", {
  db_address = aws_db_instance.main.address
  cache_endpoint = aws_elasticache_cluster.main.configuration_endpoint
})

D. Managing SSH keys and access

SSH keys aren’t something to mess around with. Terraform gives you multiple ways to handle them securely.

First, you can create a key pair directly:

resource "aws_key_pair" "deployer" {
  key_name   = "deployer-key"
  public_key = file("~/.ssh/id_rsa.pub")
}

But for teams, it’s often better to generate keys outside Terraform and reference them:

resource "aws_instance" "app" {
  ami           = var.ami_id
  instance_type = var.instance_type
  key_name      = var.key_name
  # other configuration...
}

Store the key name in your variables file or pass it through your CI/CD pipeline as a variable.

For larger organizations, consider using AWS Systems Manager Session Manager instead of direct SSH. It provides secure shell access without exposing SSH ports.

E. Attaching instances to the correct subnets and security groups

Your EC2 instances need to live in the right neighborhood with the right protections. That means proper subnet placement and security group assignment.

resource "aws_instance" "app_server" {
  ami           = var.ami_id
  instance_type = var.instance_type
  
  subnet_id = var.environment == "production" 
    ? module.vpc.private_subnets[0] 
    : module.vpc.public_subnets[0]
  
  vpc_security_group_ids = [
    aws_security_group.app.id,
    aws_security_group.monitoring.id
  ]
}

Public-facing instances should go in public subnets with security groups that allow specific inbound traffic. Database or backend services belong in private subnets with more restrictive access.

Use count or for_each to deploy instances across multiple subnets for high availability:

resource "aws_instance" "web" {
  count         = length(module.vpc.public_subnets)
  ami           = var.ami_id
  instance_type = var.instance_type
  subnet_id     = module.vpc.public_subnets[count.index]
  
  # other configuration...
}

Advanced Terraform Techniques for AWS Infrastructure

Using variables and locals for flexibility

Getting tired of hardcoding values in your Terraform configurations? Yeah, me too. Variables and locals are your best friends when building flexible AWS infrastructure.

Variables let you customize your deployments without touching the core code:

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  default     = "10.0.0.0/16"
  type        = string
}

Now you can reference it anywhere with var.vpc_cidr. Change it once, it updates everywhere.

Locals are different – they’re like mini-variables you define for calculations or transformations:

locals {
  environment = terraform.workspace
  common_tags = {
    Environment = local.environment
    Project     = "AWS-VPC-Demo"
    ManagedBy   = "Terraform"
  }
}

Then tag all your resources with local.common_tags and boom – consistent tagging across your entire infrastructure.

Implementing conditional resources

Sometimes you need resources only in specific environments. Conditional expressions in Terraform make this dead simple:

resource "aws_instance" "bastion" {
  count         = var.environment == "production" ? 1 : 0
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t3.micro"
  # other configurations...
}

This bastion host only deploys in production. In dev or staging? It doesn’t exist.

You can also use conditionals for resource configurations:

resource "aws_instance" "web" {
  instance_type = var.environment == "production" ? "t3.large" : "t3.micro"
  # other configurations...
}

Bigger instances in production, smaller ones in development. Your wallet will thank you.

Leveraging Terraform modules for reusability

Copy-pasting Terraform code between projects is a recipe for disaster. Modules solve this problem:

module "vpc" {
  source = "./modules/vpc"
  
  cidr_block = var.vpc_cidr
  name       = "main-vpc"
  azs        = ["us-west-2a", "us-west-2b"]
}

Create a VPC module once, use it everywhere. Need to update how you build VPCs? Change the module, not every project.

The best part? You can version your modules or pull them directly from GitHub:

module "security_groups" {
  source = "github.com/yourusername/terraform-aws-security-groups?ref=v1.2.0"
  
  vpc_id = module.vpc.vpc_id
}

Output management for resource information

Terraform outputs are crucial for sharing information between modules or just documenting what you’ve built:

output "vpc_id" {
  value       = aws_vpc.main.id
  description = "The ID of the VPC"
}

output "instance_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

Outputs become even more powerful with modules. Pass VPC IDs to security group modules, or subnet IDs to EC2 modules.

Pro tip: Use outputs with terraform output -json in your CI/CD pipelines to automatically update DNS records or notification systems when your infrastructure changes.

Testing and Maintaining Your Infrastructure

A. Validating Terraform Configurations

Building infrastructure is one thing, but making sure it works as expected? That’s where validation comes in.

Before you hit that terraform apply button, run terraform validate to catch syntax errors and other basic issues. Think of it as spell check for your infrastructure code.

terraform validate

The plan command is your next best friend:

terraform plan

This shows you exactly what Terraform will create, modify, or destroy. No surprises means happy engineers.

For extra validation, try the terraform fmt command to automatically format your code according to best practices. Messy code leads to messy infrastructure.

B. Implementing Automated Testing

Manual testing is so 2010. Automate it!

Tools like Terratest let you write actual code to verify your infrastructure works:

package test

func TestAwsInfrastructure(t *testing.T) {
    terraformOptions := &terraform.Options{
        TerraformDir: "../",
    }
    
    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)
    
    // Test your EC2 instance is running
    instanceID := terraform.Output(t, terraformOptions, "instance_id")
    aws.AssertEc2InstanceExists(t, instanceID, "us-west-2")
}

Other testing approaches include:

Unit testing: Test individual modules
Integration testing: Test how components work together
End-to-end testing: Test the entire infrastructure stack

C. Managing Infrastructure Changes and Updates

Infrastructure evolves. Your Terraform code should too.

When making changes, follow this workflow:

Create a feature branch
Make changes and run terraform plan to see the impact
Get code review from team members
Merge and apply changes in a controlled environment

State management is crucial here. Use remote state storage like S3 with state locking to prevent concurrent modifications:

terraform {
  backend "s3" {
    bucket = "terraform-state-bucket"
    key    = "vpc/terraform.tfstate"
    region = "us-east-1"
    dynamodb_table = "terraform-locks"
  }
}

D. Monitoring and Troubleshooting Your Deployed Resources

Once your infrastructure is live, keep an eye on it.

AWS CloudWatch is perfect for monitoring EC2 instances, VPCs, and other resources. Set up dashboards and alarms to notify you when things go sideways.

For troubleshooting, Terraform’s logging can be your best guide:

export TF_LOG=DEBUG
terraform apply

Common issues and solutions:

Problem	Solution
State drift	Run `terraform refresh` to update state
Apply failures	Check AWS service quotas and permissions
Performance issues	Review resource configurations and right-size
Security concerns	Regularly audit security groups and NACLs

Remember to integrate infrastructure monitoring with your existing observability stack. What you can’t see, you can’t fix.

Automating AWS infrastructure deployment with Terraform transforms how organizations build, scale, and maintain their cloud environments. From designing a secure VPC architecture to implementing precise security groups and deploying EC2 instances, Infrastructure as Code provides the consistency and repeatability that manual processes simply cannot match. The advanced techniques covered for testing and maintaining your infrastructure ensure your cloud environment remains secure and optimized over time.

Take the next step in your cloud automation journey by implementing these Terraform practices in your own AWS environment. Start small with a simple VPC and EC2 deployment, then gradually incorporate more sophisticated components as your confidence grows. Remember that effective Infrastructure as Code isn’t just about technical implementation—it’s about creating a foundation for scalable, secure, and maintainable cloud operations that can evolve with your organization’s needs.