Infrastructure as CodeBeginner4-6 hours
Production-Ready AWS VPC with Terraform
TerraformAWS VPCEC2Security GroupsNAT GatewayRoute TablesS3
Best for: Cloud/DevOps Engineer, Cloud Architect, Platform Engineer
Overview
Build a reusable, production-ready AWS VPC using Terraform with a clear three-tier subnet layout: public (load balancers), private app (compute), and private database. By the end you will have a network foundation that a real production workload could run on, plus hands-on experience with Terraform state management, drift detection, and parameterisation.
What you will build
- →Design a VPC with public subnets, private app subnets, and private database subnets across two availability zones
- →Provision an Internet Gateway, NAT Gateway, and correct route tables for each subnet tier
- →Create least-privilege security groups for a web tier and an application tier
- →Configure remote Terraform state in S3 with DynamoDB locking to prevent concurrent applies
- →Parameterise every value - no hardcoded CIDR blocks, region, or environment names
Before you start
- •Basic AWS knowledge - what a VPC, subnet, and security group are
- •Terraform installed locally (or Terraform Cloud free tier)
- •An AWS account with permissions to create VPC resources
Deliverables
A complete submission should include all of the following.
- ✓main.tf provisioning the VPC, subnets, gateways, and route tables using only variables
- ✓variables.tf with sensible defaults (region, CIDR blocks, environment name, AZs)
- ✓outputs.tf exporting VPC ID, subnet IDs, and security group IDs for use by other modules
- ✓backend.tf configuring remote state in S3 with DynamoDB locking
- ✓A terraform.tfvars.example showing how to configure dev vs prod
- ✓A README explaining the architecture and instructions for running terraform plan and apply
Stretch goals
Optional extras that demonstrate deeper understanding and make your project stand out.
- +Add a bastion host in the public subnet with SSH restricted to a specific CIDR range
- +Create VPC Flow Logs writing to CloudWatch Logs for network traffic visibility
- +Add a VPC Endpoint for S3 to keep S3 traffic off the public internet and reduce NAT Gateway costs
- +Write a basic module test using the native terraform test command
Interview talking points
When you discuss this project in an interview, be ready to answer these questions specifically.
- 1Why you separated subnets into three tiers and what the security benefit is - database servers should never be reachable from the public internet
- 2How DynamoDB locking prevents two engineers running terraform apply at the same time and corrupting state
- 3What Terraform does when it detects drift between the state file and actual AWS resources - plan shows the diff, apply reconciles it
- 4The NAT Gateway vs NAT instance trade-off: managed vs cheaper, and why NAT Gateway is almost always right for production
- 5How you handle secrets in Terraform - never in state, reference AWS Secrets Manager or SSM Parameter Store instead