When I started learning AWS, I struggled to understand how networking really works. Reading documentation wasn’t enough I needed to build something real. So I created a complete infrastructure from scratch using Terraform that shows how to properly isolate resources and secure SSH access.<\/p>
This project taught me the foundation of AWS networking that every DevOps engineer needs to know.<\/p>
I deployed a three-tier network architecture with:<\/p>
Internet\n \u2193\nInternet Gateway\n \u2193\nPublic Subnets (10.0.101.0\/24, 10.0.102.0\/24)\n \u2193\nBastion Host (with Elastic IP)\n \u2193\nPrivate Subnets (10.0.1.0\/24, 10.0.2.0\/24)\n \u2193\nPrivate EC2 Instances (running Apache)<\/code><\/pre>Technical Implementation Details<\/h3>1. Understanding VPC Module Configuration<\/h3>
Before writing any code, I needed to understand what a VPC actually does. A VPC (Virtual Private Cloud) is like your own private network inside AWS. Without VPC, you can’t launch EC2 instances or any other resources.<\/p>
I used the official Terraform AWS VPC module (version 5.13.0). Here’s my actual configuration:<\/p>
module \"vpc\" {\n source = \"terraform-aws-modules\/vpc\/aws\"\n version = \"5.13.0\"\n\n name = \"${local.name}-${var.vpc_name}\"\n cidr = var.vpc_cidr_block\n azs = var.vpc_availability_zones\n public_subnets = var.vpc_public_subnets\n private_subnets = var.vpc_private_subnets\n database_subnets = var.vpc_database_subnets\n \n create_database_subnet_group = var.vpc_create_database_subnet_group\n create_database_subnet_route_table = var.vpc_create_database_subnet_route_table\n \n enable_nat_gateway = var.vpc_enable_nat_gateway\n single_nat_gateway = var.vpc_single_nat_gateway\n \n enable_dns_support = true\n enable_dns_hostnames = true\n\n tags = local.common_tags\n}<\/code><\/pre>Why these settings matter:<\/p>
- single_nat_gateway = true – I use only one NAT Gateway to save costs<\/li>
- enable_dns_hostnames = true – EC2 instances get DNS names automatically<\/li>
- create_database_subnet_route_table = true – Database subnets are isolated with their own route table<\/li><\/ul>
Deep dive into each parameter:<\/p>
VPC Name with Local Values:<\/p>
name = \"${local.name}-${var.vpc_name}\"\n# Result: \"sap-dev-myvpc\"<\/code><\/pre>I combine business division + environment + vpc name. This makes it easy to find resources in AWS console when I have multiple VPCs.<\/p>
CIDR Block:<\/p>
cidr = var.vpc_cidr_block # 10.0.0.0\/16<\/code><\/pre>The \/16 gives me 65,536 IP addresses (2^16). This is enough for hundreds of servers. I chose 10.0.0.0 because it’s private IP range (RFC 1918) and won’t conflict with internet.<\/p>
Availability Zones:<\/p>
azs = var.vpc_availability_zones # [\"us-east-1a\", \"us-east-1b\"]<\/code><\/pre>Using 2 AZs means if one datacenter fails, my app still works. AWS best practice says use at least 2 AZs for production.<\/p>
Subnet Types Explained:<\/p>
public_subnets = var.vpc_public_subnets # Has route to Internet Gateway\nprivate_subnets = var.vpc_private_subnets # Has route to NAT Gateway\ndatabase_subnets = var.vpc_database_subnets # No internet route at all<\/code><\/pre>The difference is in the route tables:<\/p>
- Public subnet \u2192 Internet Gateway (can receive traffic from internet)<\/li>
- Private subnet \u2192 NAT Gateway (can send to internet, cannot receive)<\/li>
- Database subnet \u2192 No internet (completely isolated)<\/li><\/ul>
NAT Gateway Configuration:<\/p>
enable_nat_gateway = true\nsingle_nat_gateway = true<\/code><\/pre>NAT Gateway allows private instances to download packages (yum update, yum install httpd) without exposing them to internet.<\/p>
With single_nat_gateway = true, I create only ONE NAT Gateway in first AZ. This saves $32\/month but means:<\/p>
- If us-east-1a fails, private instances in us-east-1b lose internet<\/li>
- For production, use single_nat_gateway = false to create NAT in each AZ<\/li><\/ul>
DNS Settings:<\/p>
enable_dns_support = true\nenable_dns_hostnames = true<\/code><\/pre>Without these, EC2 instances don’t get DNS names like ec2-3-80-123-45.compute-1.amazonaws.com. Many applications need DNS to work properly.<\/p>
2. Network Design<\/h3>
My CIDR allocation strategy:<\/p>Subnet Type<\/th> Availability Zone<\/th> CIDR Block<\/th> Purpose<\/th><\/tr><\/thead> Public<\/td> us-east-1a<\/td> 10.0.101.0\/24<\/td> Bastion host<\/td><\/tr> Public<\/td> us-east-1b<\/td> 10.0.102.0\/24<\/td> Future load balancer<\/td><\/tr> Private<\/td> us-east-1a<\/td> 10.0.1.0\/24<\/td> Application servers<\/td><\/tr> Private<\/td> us-east-1b<\/td> 10.0.2.0\/24<\/td> Application servers<\/td><\/tr> Database<\/td> us-east-1a<\/td> 10.0.151.0\/24<\/td> Future RDS instances<\/td><\/tr> Database<\/td> us-east-1b<\/td> 10.0.152.0\/24<\/td> Future RDS instances<\/td><\/tr><\/tbody><\/table><\/figure>I chose this design because:<\/p>
- Public subnets use 10.0.10X.0\/24 range (easy to remember – anything with 10X is public)<\/li>
- Private subnets use 10.0.X.0\/24 range (lowest numbers = app servers)<\/li>
- Database subnets use 10.0.15X.0\/24 range (15X = database layer)<\/li><\/ul>
Why \/24 subnet mask?<\/p>
- \/24 = 256 IP addresses per subnet<\/li>
- AWS reserves 5 IPs in each subnet (network, gateway, DNS, future use, broadcast)<\/li>
- Available IPs = 256 – 5 = 251 usable addresses<\/li>
- This is enough for most applications<\/li><\/ul>
Subnet distribution across AZs: The module automatically distributes subnets across availability zones:<\/p>
- public_subnets[0] \u2192 us-east-1a<\/li>
- public_subnets[1] \u2192 us-east-1b<\/li>
- private_subnets[0] \u2192 us-east-1a<\/li>
- private_subnets[1] \u2192 us-east-1b<\/li><\/ul>
This is important for high availability. If I launch instances without specifying subnet, AWS picks randomly. But I specify exact subnet to control which AZ my instance runs in.<\/p>
How Traffic Flows in This Architecture<\/h3>
Understanding traffic flow helped me debug many issues. Let me explain each scenario:<\/p>
Scenario 1: SSH from Internet to Bastion Host<\/p>
My Laptop (123.45.67.89)\n \u2193 (SSH request to 54.123.45.67:22)\nInternet Gateway\n \u2193 (forwards to 10.0.101.45)\nBastion Host Security Group (checks: is source 0.0.0.0\/0? YES, allow)\n \u2193\nBastion Host (10.0.101.45)\n \u2193 (response goes back same path - stateful!)\nMy Laptop<\/code><\/pre>Scenario 2: SSH from Bastion to Private Instance<\/p>
Bastion Host (10.0.101.45)\n \u2193 (SSH to 10.0.1.23:22)\nPrivate Instance Security Group (checks: is source from 10.0.0.0\/16? YES, allow)\n \u2193\nPrivate Instance (10.0.1.23)\n \u2193 (response)\nBastion Host<\/code><\/pre>Scenario 3: Private Instance Downloads Package (yum install)<\/p>
Private Instance (10.0.1.23)\n \u2193 (request to yum.repo.com:80)\nPrivate Subnet Route Table (check: destination not in VPC \u2192 use NAT Gateway)\n \u2193\nNAT Gateway (10.0.101.75 in public subnet)\n \u2193 (NAT translates 10.0.1.23 \u2192 NAT's public IP)\nInternet Gateway\n \u2193\nInternet (yum.repo.com)\n \u2193 (response)\nNAT Gateway (translates back to 10.0.1.23)\n \u2193\nPrivate Instance<\/code><\/pre>Scenario 4: Internet User tries to access Private Instance (BLOCKED)<\/p>
Internet User\n \u2193 (tries to reach 10.0.1.23)\nInternet Gateway (check: 10.0.1.23 is private IP, no route)\n \u2717 BLOCKED - Private IPs not routable on internet<\/code><\/pre>Even if someone knows my private instance IP, they cannot reach it from internet because:<\/p>
- Private IP (10.0.0.0\/8) is not routable on internet<\/li>
- No public IP attached to private instance<\/li>
- Security group only allows VPC CIDR<\/li><\/ul>
Route Table Configuration (what the VPC module creates):<\/p>
Public Subnet Route Table:<\/p>
Destination Target\n10.0.0.0\/16 local (VPC)\n0.0.0.0\/0 igw-xxxxx (Internet Gateway)<\/code><\/pre>Private Subnet Route Table:<\/p>
Destination Target\n10.0.0.0\/16 local (VPC)\n0.0.0.0\/0 nat-xxxxx (NAT Gateway)<\/code><\/pre>Database Subnet Route Table:<\/p>
Destination Target\n10.0.0.0\/16 local (VPC)<\/code><\/pre>(No internet route at all!)<\/p>
3. Security Groups – The Firewall Rules<\/h3>
Bastion Host Security Group:<\/p>
module \"public_bastion_sg\" {\n source = \"terraform-aws-modules\/security-group\/aws\"\n version = \"5.2.0\"\n\n name = \"public-bastion-sg\"\n description = \"Security group for public bastion hosts\"\n vpc_id = module.vpc.vpc_id\n\n ingress_rules = [\"ssh-tcp\"]\n ingress_cidr_blocks = [\"0.0.0.0\/0\"]\n\n egress_rules = [\"all-all\"]\n tags = local.common_tags\n}<\/code><\/pre>This allows SSH (port 22) from anywhere on the internet. The bastion is our entry point.<\/p>
Private Instance Security Group:<\/p>
module \"private_sg\" {\n source = \"terraform-aws-modules\/security-group\/aws\"\n version = \"5.2.0\"\n\n name = \"private-sg\"\n description = \"Security group for private instances\"\n vpc_id = module.vpc.vpc_id\n\n ingress_rules = [\"ssh-tcp\", \"http-80-tcp\"]\n ingress_cidr_blocks = [module.vpc.vpc_cidr_block]\n\n egress_rules = [\"all-all\"]\n tags = local.common_tags\n}<\/code><\/pre>Important: Private instances only accept SSH and HTTP from VPC CIDR (10.0.0.0\/16), not from internet. This is security best practice.<\/p>
How Security Groups Actually Work:<\/p>
Security groups are stateful firewalls. This means:<\/p>
- If I allow incoming SSH (port 22), the response automatically goes back<\/li>
- I don’t need separate rule for outbound response<\/li>
- Security groups only have ALLOW rules, no DENY rules<\/li><\/ul>
Understanding the ingress_cidr_blocks:<\/p>
Bastion host:<\/p>
ingress_cidr_blocks = [\"0.0.0.0\/0\"] # From anywhere on internet<\/code><\/pre>Private instances:<\/p>
ingress_cidr_blocks = [module.vpc.vpc_cidr_block] # Only from 10.0.0.0\/16<\/code><\/pre>This means:<\/p>
- Internet user \u2192 Can SSH to bastion (allowed)<\/li>
- Internet user \u2192 Cannot SSH to private instance (blocked)<\/li>
- Bastion host \u2192 Can SSH to private instance (allowed, because bastion is in VPC)<\/li>
- Private instance \u2192 Can SSH to another private instance (allowed, both in VPC)<\/li><\/ul>
The egress_rules Explained:<\/p>
egress_rules = [\"all-all\"]<\/code><\/pre>This allows ALL outbound traffic. The instances can:<\/p>
- Download packages from yum repositories<\/li>
- Call AWS APIs<\/li>
- Connect to internet via NAT Gateway<\/li>
- Send responses back to connections<\/li><\/ul>
Security Group vs NACL (Network ACL):<\/p>
- Security groups = instance-level firewall (what I’m using)<\/li>
- NACLs = subnet-level firewall (not configured in this project)<\/li>
- Security groups are stateful, NACLs are stateless<\/li>
- For most cases, security groups are enough<\/li><\/ul>
4. EC2 Instance Deployment<\/h3>
Bastion Host Configuration:<\/p>
module \"ec2_public\" {\n source = \"terraform-aws-modules\/ec2-instance\/aws\"\n version = \"5.7.0\"\n\n name = \"${var.environment}-BastionHost\"\n ami = data.aws_ami.amzlinux2.id\n instance_type = var.instance_type\n key_name = var.instance_keypair\n subnet_id = module.vpc.public_subnets[0]\n vpc_security_group_ids = [module.public_bastion_sg.security_group_id]\n tags = local.common_tags\n}<\/code><\/pre>Private Instances with for_each:<\/p>
module \"ec2_private\" {\n depends_on = [ module.vpc ]\n source = \"terraform-aws-modules\/ec2-instance\/aws\"\n version = \"5.7.0\"\n \n name = \"${var.environment}-vm\"\n ami = data.aws_ami.amzlinux2.id\n instance_type = var.instance_type\n key_name = var.instance_keypair\n \n for_each = toset([\"0\", \"1\"])\n subnet_id = element(module.vpc.private_subnets, tonumber(each.key))\n vpc_security_group_ids = [module.private_sg.security_group_id]\n user_data = file(\"${path.module}\/app1-install.sh\")\n\n tags = local.common_tags\n}<\/code><\/pre>Why for_each instead of count?<\/p>
- for_each creates instances with stable names<\/li>
- If I destroy one instance, others keep their identity<\/li>
- With count, destroying instance[0] would rename instance[1] to instance[0]<\/li><\/ul>
Let me explain this problem with count:<\/p>
Using count (the old way):<\/p>
count = 2\n# Creates: vm[0] and vm[1]<\/code><\/pre>If I destroy vm[0]:<\/p>
- Terraform renames vm[1] \u2192 vm[0]<\/li>
- This recreates the instance!<\/li>
- All data lost<\/li>
- New IP address assigned<\/li><\/ul>
Using for_each (the better way):<\/p>
for_each = toset([\"0\", \"1\"])\n# Creates: vm[\"0\"] and vm[\"1\"]<\/code><\/pre>If I destroy vm[“0”]:<\/p>
- vm[“1”] stays vm[“1”]<\/li>
- No recreation<\/li>
- Data and IP preserved<\/li><\/ul>
Understanding the subnet distribution:<\/p>
subnet_id = element(module.vpc.private_subnets, tonumber(each.key))<\/code><\/pre>Let me break this down:<\/p>
- module.vpc.private_subnets = [“subnet-aaa”, “subnet-bbb”]<\/li>
- each.key = “0” or “1” (from for_each)<\/li>
- tonumber(each.key) = converts “0” to 0, “1” to 1<\/li>
- element(list, index) = picks subnet from list<\/li><\/ul>
Result:<\/p>
- Instance “0” \u2192 private_subnets[0] \u2192 us-east-1a<\/li>
- Instance “1” \u2192 private_subnets[1] \u2192 us-east-1b<\/li><\/ul>
The AMI Data Source:<\/p>
data \"aws_ami\" \"amzlinux2\" {\n most_recent = true\n owners = [ \"amazon\" ]\n filter {\n name = \"name\"\n values = [ \"amzn2-ami-hvm-*-gp2\" ]\n }\n filter {\n name = \"virtualization-type\"\n values = [ \"hvm\" ]\n }\n}<\/code><\/pre>This automatically finds the latest Amazon Linux 2 AMI. I don’t need to hardcode AMI ID like ami-0c55b159cbfafe1f0 which changes every month. The data source always finds the newest version.<\/p>
Why depends_on is critical:<\/p>
depends_on = [ module.vpc ]<\/code><\/pre>Without this, Terraform might try to create EC2 instances before VPC exists. The terraform execution happens in parallel for speed, but some resources need others first. The depends_on forces correct order.<\/p>
5. Elastic IP for Bastion Host<\/h3>resource \"aws_eip\" \"bastion_eip\" {\n depends_on = [ module.vpc, module.ec2_public ]\n instance = module.ec2_public.id\n domain = \"vpc\"\n tags = local.common_tags\n}<\/code><\/pre>Elastic IP gives bastion host a permanent public IP address. Even if I stop and start the instance, the IP stays the same. This is important for SSH access and security group rules.<\/p>
Why Elastic IP is necessary:<\/p>
Without Elastic IP:<\/p>
- Instance gets random public IP when launched<\/li>
- Public IP changes every stop\/start<\/li>
- I need to update SSH config every time<\/li>
- Security group rules break<\/li><\/ul>
With Elastic IP:<\/p>
- Same IP always: 54.123.45.67 (example)<\/li>
- Can whitelist this IP in company firewall<\/li>
- SSH config never changes<\/li>
- Can create DNS record pointing to this IP<\/li><\/ul>
Understanding the resource block:<\/p>
resource \"aws_eip\" \"bastion_eip\" {\n depends_on = [ module.vpc, module.ec2_public ]\n instance = module.ec2_public.id\n domain = \"vpc\"\n tags = local.common_tags\n}<\/code><\/pre>- depends_on – Wait for VPC and EC2 to exist first<\/li>
- instance – Attach EIP to this specific instance<\/li>
- domain = “vpc” – EIP for VPC (not EC2-Classic which is old)<\/li><\/ul>
EIP Lifecycle:<\/p>
- Terraform creates EIP (gets public IP from AWS pool)<\/li>
- Terraform attaches EIP to bastion instance<\/li>
- Instance can now use this IP<\/li>
- If instance stops \u2192 EIP stays allocated to my account<\/li>
- If instance starts \u2192 EIP automatically reattaches<\/li>
- If I run terraform destroy \u2192 EIP releases back to AWS<\/li><\/ol>
EIP is FREE when:<\/p>
- Attached to a running instance<\/li>
- Not allocated at all<\/li><\/ul>
So always run terraform destroy when done learning!<\/p>
6. Automated SSH Key Distribution<\/h3>
This was the tricky part. Private instances need the SSH key to connect to each other, but the key file is on my laptop. I used Terraform provisioners:<\/p>
resource \"null_resource\" \"name\" {\n depends_on = [ module.ec2_public ]\n\n connection {\n type = \"ssh\"\n host = aws_eip.bastion_eip.public_ip\n user = \"ec2-user\"\n password = \"\"\n private_key = file(\"private-key\/terraform-key.pem\")\n }\n\n provisioner \"file\" {\n source = \"private-key\/terraform-key.pem\"\n destination = \"\/tmp\/terraform-key.pem\"\n }\n\n provisioner \"remote-exec\" {\n inline = [ \n \"sudo chmod 400 \/tmp\/terraform-key.pem\",\n \"echo VPC created on `date` and VPC ID: ${module.vpc.vpc_id} >> creation-time-vpc-id.txt\"\n ]\n }\n}<\/code><\/pre>What this does:<\/p>
- Waits for bastion host to be ready (depends_on)<\/li>
- Connects via SSH to bastion host<\/li>
- Copies my private key to \/tmp\/ directory<\/li>
- Sets correct permissions (400 = read-only for owner)<\/li>
- Creates a log file with VPC ID and creation time<\/li><\/ol>
Now from bastion, I can SSH to private instances:<\/p>
ssh -i \/tmp\/terraform-key.pem ec2-user@10.0.1.X<\/code><\/pre>Why null_resource is needed:<\/p>
The problem:<\/p>
- Private instances are in private subnet (no public IP)<\/li>
- I cannot SSH directly from my laptop<\/li>
- Private instances need SSH key to communicate with each other<\/li>
- The key file is on my laptop, not on bastion<\/li><\/ul>
The solution:<\/p>
- Use null_resource to run commands AFTER bastion is ready<\/li>
- Copy private key from my laptop to bastion<\/li>
- Now bastion can SSH to private instances<\/li><\/ul>
Understanding each provisioner:<\/p>
Connection block:<\/p>
connection {\n type = \"ssh\"\n host = aws_eip.bastion_eip.public_ip\n user = \"ec2-user\"\n password = \"\"\n private_key = file(\"private-key\/terraform-key.pem\")\n}<\/code><\/pre>- type = “ssh” – Use SSH protocol<\/li>
- host – Connect to Elastic IP (not random public IP)<\/li>
- user = “ec2-user” – Default user for Amazon Linux 2<\/li>
- private_key – Read key file from my laptop<\/li><\/ul>
File provisioner:<\/p>
provisioner \"file\" {\n source = \"private-key\/terraform-key.pem\"\n destination = \"\/tmp\/terraform-key.pem\"\n}<\/code><\/pre>This copies file from my laptop to bastion host. Like scp command but automated.<\/p>
Remote-exec provisioner:<\/p>
provisioner \"remote-exec\" {\n inline = [ \n \"sudo chmod 400 \/tmp\/terraform-key.pem\",\n \"echo VPC created on `date` and VPC ID: ${module.vpc.vpc_id} >> creation-time-vpc-id.txt\"\n ]\n}<\/code><\/pre>- sudo chmod 400 – Sets permissions to read-only for owner (required for SSH keys)<\/li>
- echo … >> file.txt – Creates log file with timestamp and VPC ID<\/li><\/ul>
Why chmod 400 is critical: SSH refuses to use key files with wrong permissions:<\/p>
chmod 777 terraform-key.pem \u2192 SSH ERROR: \"permissions are too open\"\nchmod 400 terraform-key.pem \u2192 SSH works<\/code><\/pre>400 means:<\/p>
- Owner can read (4)<\/li>
- Group cannot do anything (0)<\/li>
- Others cannot do anything (0)<\/li><\/ul>
Alternative approaches I considered:<\/p>
- AWS Systems Manager Session Manager – No SSH key needed, but costs money<\/li>
- EC2 Instance Connect – Temporary SSH keys, but more complex<\/li>
- This null_resource approach – Simple and free<\/li><\/ol>
For learning, null_resource is best. For production, use Systems Manager.<\/p>
7. Web Server Installation Script<\/h3>
I used user data to install Apache automatically when instances launch:<\/p>
#!\/bin\/bash\nsudo yum update -y\nsudo yum install -y httpd\nsudo systemctl enable httpd\nsudo service httpd start \nsudo echo '<h1>Welcome to Root Access - APP-1<\/h1>' | sudo tee \/var\/www\/html\/index.html\nsudo mkdir \/var\/www\/html\/app1\nsudo echo '<!DOCTYPE html> <html> <body style=\"background-color:rgb(250, 210, 210);\"> <h1>Welcome to Root Access - APP-1<\/h1> <p>Terraform Demo by Reza Chegini<\/p> <p>Application Version: V1<\/p> <\/body><\/html>' | sudo tee \/var\/www\/html\/app1\/index.html\n\n# Get instance metadata\nTOKEN=`curl -X PUT \"http:\/\/169.254.169.254\/latest\/api\/token\" -H \"X-aws-ec2-metadata-token-ttl-seconds: 21600\"`\nsudo curl -H \"X-aws-ec2-metadata-token: $TOKEN\" http:\/\/169.254.169.254\/latest\/dynamic\/instance-identity\/document -o \/var\/www\/html\/app1\/metadata.html<\/code><\/pre>This script uses IMDSv2 (Instance Metadata Service version 2) for better security. The token-based approach prevents SSRF attacks.<\/p>
Let me explain the script line by line:<\/p>
#!\/bin\/bash<\/p>
Shebang – tells Linux to run this with bash shell<\/p>
sudo yum update -y<\/p>
- yum update – Updates all installed packages<\/li>
- -y – Automatically answers “yes” to all prompts<\/li>
- sudo – Run with root privileges<\/li><\/ul>
sudo yum install -y httpd\nsudo systemctl enable httpd\nsudo service httpd start<\/code><\/pre>- Install Apache web server<\/li>
- enable – Start Apache automatically on boot<\/li>
- start – Start Apache now<\/li><\/ul>
sudo echo '<h1>Welcome to Root Access - APP-1<\/h1>' | sudo tee \/var\/www\/html\/index.html<\/code><\/pre>- tee – Writes to file AND shows on screen<\/li>
- Creates homepage at root URL: http:\/\/INSTANCE_IP\/<\/li><\/ul>
sudo mkdir \/var\/www\/html\/app1\nsudo echo '<!DOCTYPE html>...' | sudo tee \/var\/www\/html\/app1\/index.html<\/code><\/pre>- Creates \/app1 directory<\/li>
- Creates page at: http:\/\/INSTANCE_IP\/app1\/<\/li><\/ul>
The IMDSv2 Security:<\/p>
Old way (IMDSv1 – insecure):<\/p>
curl http:\/\/169.254.169.254\/latest\/dynamic\/instance-identity\/document<\/code><\/pre>This is vulnerable to SSRF (Server-Side Request Forgery) attacks.<\/p>
New way (IMDSv2 – secure):<\/p>
# Step 1: Get session token\nTOKEN=`curl -X PUT \"http:\/\/169.254.169.254\/latest\/api\/token\" -H \"X-aws-ec2-metadata-token-ttl-seconds: 21600\"`\n\n# Step 2: Use token to get metadata\nsudo curl -H \"X-aws-ec2-metadata-token: $TOKEN\" http:\/\/169.254.169.254\/latest\/dynamic\/instance-identity\/document -o \/var\/www\/html\/app1\/metadata.html<\/code><\/pre>Why IMDSv2 is more secure:<\/p>
- Must use PUT request to get token (SSRF usually uses GET)<\/li>
- Token expires after 6 hours (21600 seconds)<\/li>
- Token must be in HTTP header (harder to exploit)<\/li><\/ol>
What metadata contains:<\/p>
{\n \"instanceId\": \"i-0abcd1234efgh5678\",\n \"region\": \"us-east-1\",\n \"availabilityZone\": \"us-east-1a\",\n \"privateIp\": \"10.0.1.45\",\n \"instanceType\": \"t2.micro\"\n}<\/code><\/pre>This metadata is useful for:<\/p>
- Application knows which AZ it’s running in<\/li>
- Dynamic configuration based on instance type<\/li>
- Monitoring and logging with instance ID<\/li><\/ul>
User Data Execution:<\/p>
- Runs as root user (already has sudo privileges)<\/li>
- Executes only on FIRST boot<\/li>
- Logs saved in \/var\/log\/cloud-init-output.log<\/li>
- If script fails, instance still launches (no rollback)<\/li><\/ul>
Testing if script worked:<\/p>
# SSH to instance\nssh -i key.pem ec2-user@INSTANCE_IP\n\n# Check Apache status\nsudo systemctl status httpd\n\n# Check if files were created\nls -la \/var\/www\/html\/\nls -la \/var\/www\/html\/app1\/\n\n# View script output\nsudo cat \/var\/log\/cloud-init-output.log<\/code><\/pre>8. Local Values for Resource Naming<\/h3>
I created consistent naming across all resources:<\/p>
locals {\n owners = var.business_division\n environment = var.environment\n name = \"${var.business_division}-${var.environment}\"\n common_tags = {\n owners = local.owners\n environment = local.environment\n }\n}<\/code><\/pre>So my resources get names like: sap-dev-BastionHost, sap-dev-myvpc<\/p>
This makes it easy to identify resources in AWS console and track costs by environment.<\/p>
Variables Organization<\/h3>
I organized variables in separate files:<\/p>
ec2instance.auto.tfvars:<\/p>
instance_type = \"t2.micro\"\ninstance_keypair = \"terraform-key\"\nprivate_instance_count = 2<\/code><\/pre>c2-generic-variables.tf:<\/p>
variable \"aws_region\" {\n default = \"us-east-1\"\n}\n\nvariable \"environment\" {\n default = \"dev\"\n}\n\nvariable \"business_division\" {\n default = \"sap\"\n}<\/code><\/pre>Terraform automatically loads *.auto.tfvars files. This keeps configuration clean and organized.<\/p>
How to Deploy This Infrastructure<\/h3>
Clone the repository and navigate to directory:<\/p>
cd AWS-EC2Instance-and-SecurityGroups\/terraform-manifests<\/code><\/pre>Create directory for SSH key:<\/p>
mkdir -p private-key\n# Copy your terraform-key.pem here\nchmod 400 private-key\/terraform-key.pem<\/code><\/pre>Initialize Terraform:<\/p>
terraform init<\/code><\/pre>Review the plan:<\/p>
terraform plan<\/code><\/pre>Apply configuration:<\/p>
terraform apply<\/code><\/pre>Access bastion host:<\/p>
ssh -i private-key\/terraform-key.pem ec2-user@<ELASTIC_IP><\/code><\/pre>From bastion, access private instances:<\/p>
ssh -i \/tmp\/terraform-key.pem ec2-user@<PRIVATE_IP>\ncurl http:\/\/<PRIVATE_IP>\/app1\/<\/code><\/pre>Lessons I Learned<\/h3>1. Security Group Direction Matters<\/h3>
I made mistake thinking “if I allow SSH in security group A, I can connect to security group B”. Wrong! Both source and destination security groups need rules. That’s why private security group allows traffic from VPC CIDR.<\/p>
My mistake: I thought bastion security group allowing SSH is enough. Then I couldn’t connect to private instances!<\/p>
What I learned: Traffic must be allowed in BOTH places:<\/p>
- Source: Bastion security group must allow outbound SSH (egress)<\/li>
- Destination: Private security group must allow inbound SSH from VPC (ingress)<\/li><\/ol>
My config works because:<\/p>
- Bastion SG: egress_rules = [“all-all”] \u2713<\/li>
- Private SG: ingress_cidr_blocks = [module.vpc.vpc_cidr_block] \u2713<\/li><\/ul>
Common mistake many people make:<\/p>
# WRONG - too restrictive\ningress_cidr_blocks = [module.public_bastion_sg.security_group_id]<\/code><\/pre>This doesn’t work! ingress_cidr_blocks needs IP addresses, not security group IDs.<\/p>
Correct way to reference security groups:<\/p>
# Method 1: Use CIDR blocks (what I use)\ningress_cidr_blocks = [\"10.0.0.0\/16\"]\n\n# Method 2: Use security group source\ningress_with_source_security_group_id = [\n {\n rule = \"ssh-tcp\"\n source_security_group_id = module.public_bastion_sg.security_group_id\n }\n]<\/code><\/pre>Method 1 is simpler for learning. Method 2 is more secure for production.<\/p>
2. Depends_on Is Important<\/h3>
Without depends_on in private EC2 module, Terraform might try to create instances before VPC exists. This causes errors. Always think about resource dependencies.<\/p>
The error I got:<\/p>
Error: Error launching source instance: InvalidSubnetID.NotFound<\/code><\/pre>Why it happened: Terraform executes resources in parallel by default. It tried to create EC2 instances while VPC module was still creating subnets.<\/p>
The fix:<\/p>
module \"ec2_private\" {\n depends_on = [ module.vpc ] # Wait for VPC first\n ...\n}<\/code><\/pre>Other dependencies in this project:<\/p>
# Elastic IP depends on VPC and EC2\nresource \"aws_eip\" \"bastion_eip\" {\n depends_on = [ module.vpc, module.ec2_public ]\n ...\n}\n\n# Null resource depends on EC2\nresource \"null_resource\" \"name\" {\n depends_on = [ module.ec2_public ]\n ...\n}<\/code><\/pre>When Terraform figures out dependencies automatically:<\/p>
- When you reference resource attribute: module.vpc.vpc_id<\/li>
- Terraform knows VPC must exist first<\/li><\/ul>
When you need explicit depends_on:<\/p>
- Connection timing (SSH to just-created instance)<\/li>
- Resource recreation order<\/li>
- External dependencies<\/li><\/ul>
3. User Data Runs Only Once<\/h3>
The app1-install.sh script runs only when instance launches first time. If you modify the script and run terraform apply, it won’t update existing instances. You need to recreate them with terraform taint or destroy\/apply.<\/p>
What happened to me:<\/p>
- Deployed instances with basic user data<\/li>
- Updated user data script to add more features<\/li>
- Ran terraform apply<\/li>
- Expected: Script runs again<\/li>
- Reality: Nothing changed!<\/li><\/ol>
Why: User data executes during instance initialization only. Terraform sees:<\/p>
- user_data changed<\/li>
- But AWS doesn’t support updating user data on running instance<\/li>
- Terraform shows “no changes needed”<\/li><\/ul>
Solutions:<\/p>
Option 1: Recreate instance (destroys data)<\/p>
terraform taint module.ec2_private[\"0\"]\nterraform apply<\/code><\/pre>Option 2: Use remote-exec provisioner<\/p>
provisioner \"remote-exec\" {\n inline = [\n \"bash \/path\/to\/script.sh\"\n ]\n}<\/code><\/pre>This runs every terraform apply but is less reliable.<\/p>
Option 3: Configuration management<\/p>
- Use Ansible, Chef, Puppet<\/li>
- Updates without instance recreation<\/li>
- But more complex to setup<\/li><\/ul>
For learning, I recreate instances, use proper config management.<\/p>
4. File Provisioner Path Issues<\/h3>
I spent 2 hours debugging why file provisioner failed!<\/p>
The error:<\/p>
Error: file: open private-key\/terraform-key.pem: no such file or directory<\/code><\/pre>What I learned:<\/p>
- Terraform runs from where you execute terraform apply<\/li>
- Path is relative to current directory<\/li>
- Not relative to .tf file location<\/li><\/ul>
My directory structure:<\/p>
project\/\n\u251c\u2500\u2500 terraform-manifests\/\n\u2502 \u251c\u2500\u2500 c9-nullresource-provisioners.tf\n\u2502 \u2514\u2500\u2500 private-key\/\n\u2502 \u2514\u2500\u2500 terraform-key.pem<\/code><\/pre>Wrong (what I tried first):<\/p>
private_key = file(\"terraform-key.pem\") # Not found!<\/code><\/pre>Correct:<\/p>
private_key = file(\"private-key\/terraform-key.pem\") # Works when running from terraform-manifests\/<\/code><\/pre>Better way using path variables:<\/p>
private_key = file(\"${path.module}\/private-key\/terraform-key.pem\")<\/code><\/pre>This works regardless of where you run terraform from!<\/p>
5. SSH Connection Timeout During Provisioning<\/h3>
Sometimes null_resource provisioner times out:<\/p>
Error: timeout - last error: ssh: handshake failed<\/code><\/pre>Reasons I discovered:<\/p>
- Security group not yet active (AWS eventual consistency)<\/li>
- Instance not fully booted<\/li>
- SSH daemon not started<\/li><\/ol>
The fix – add wait time:<\/p>
resource \"null_resource\" \"name\" {\n depends_on = [ module.ec2_public ]\n \n # Wait for instance to be ready\n provisioner \"local-exec\" {\n command = \"sleep 30\"\n }\n \n connection {\n type = \"ssh\"\n host = aws_eip.bastion_eip.public_ip\n ...\n }\n}<\/code><\/pre>6. Tagging Saved My Budget<\/h3>
Without proper tags, I couldn’t track which resources belong to which project.<\/p>
What happened:<\/p>
- Created resources in multiple projects<\/li>
- AWS bill showed $150\/month<\/li>
- Couldn’t figure out which project costs what!<\/li><\/ul>
My tagging strategy:<\/p>
locals {\n common_tags = {\n owners = local.owners # \"sap\"\n environment = local.environment # \"dev\"\n Project = \"terraform-learning\"\n ManagedBy = \"Terraform\"\n }\n}<\/code><\/pre>Pro tip: Add terraform = true tag to all Terraform-managed resources. Makes cleanup easier!<\/p>
Project Files Structure<\/h3>terraform-manifests\/\n\u251c\u2500\u2500 c1-versions.tf # Terraform & provider versions\n\u251c\u2500\u2500 c2-generic-variables.tf # Region, environment variables\n\u251c\u2500\u2500 c3-local-values.tf # Local values for naming\n\u251c\u2500\u2500 c4-01-vpc-variables.tf # VPC input variables\n\u251c\u2500\u2500 c4-02-vpc-module.tf # VPC module configuration\n\u251c\u2500\u2500 c4-03-vpc-outputs.tf # VPC outputs\n\u251c\u2500\u2500 c5-03-securitygroup-bastionsg.tf # Bastion security group\n\u251c\u2500\u2500 c5-04-securitygroup-privatesg.tf # Private security group\n\u251c\u2500\u2500 c6-01-datasource-ami.tf # Amazon Linux 2 AMI\n\u251c\u2500\u2500 c7-03-ec2instance-bastion.tf # Bastion host config\n\u251c\u2500\u2500 c7-04-ec2instance-private.tf # Private instances config\n\u251c\u2500\u2500 c8-elasticip.tf # Elastic IP resource\n\u251c\u2500\u2500 c9-nullresource-provisioners.tf # SSH key provisioner\n\u251c\u2500\u2500 app1-install.sh # Web server setup script\n\u2514\u2500\u2500 ec2instance.auto.tfvars # EC2 variable values<\/code><\/pre>Outputs After Deployment<\/h3>
Terraform shows important information:<\/p>
vpc_id = \"vpc-xxxxx\"\nvpc_cidr_block = \"10.0.0.0\/16\"\npublic_subnets = [\"subnet-xxxxx\", \"subnet-yyyyy\"]\nprivate_subnets = [\"subnet-aaaaa\", \"subnet-bbbbb\"]\nnat_public_ips = [\"x.x.x.x\"]\nec2_bastion_public_id = \"y.y.y.y\"\nec2_private_private_ips = [\"10.0.1.x\", \"10.0.2.y\"]<\/code><\/pre>Save these values! You’ll need them for connecting and troubleshooting.<\/p>
To save money during learning:<\/p>
vpc_enable_nat_gateway = false # Private instances lose internet<\/code><\/pre>Or destroy infrastructure when not using:<\/p>
terraform destroy<\/code><\/pre>Troubleshooting Tips<\/h3>
Problem: Can’t SSH to bastion host<\/p>
- Check security group allows your IP<\/li>
- Verify key permissions: chmod 400 terraform-key.pem<\/li>
- Check Elastic IP is attached<\/li><\/ul>
Problem: Can’t reach private instances from bastion<\/p>
- Verify you’re using correct private IP<\/li>
- Check private security group allows SSH from VPC CIDR<\/li>
- Make sure NAT Gateway is running (for yum updates)<\/li><\/ul>
Problem: Terraform apply fails with “subnet not found”<\/p>
- Run terraform refresh<\/li>
- Check VPC module created subnets successfully<\/li>
- Verify availability zones are correct for your region<\/li><\/ul>","protected":false},"excerpt":{"rendered":"
Why I Built This Project When I started learning AWS, I struggled to understand how networking really works. Reading documentation wasn’t enough…<\/p>\n","protected":false},"author":2,"featured_media":139,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_rezaops_part":"1","_rezaops_linkedin_url":"https:\/\/www.linkedin.com\/pulse\/building-secure-aws-infrastructure-vpc-bastion-hosts-private-chegini-ibmzc\/","footnotes":""},"categories":[85,10],"tags":[60,8,89,38,87,88],"series":[86],"class_list":["post-137","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aws","category-devops","tag-aws","tag-devops","tag-ec2","tag-security","tag-terraform","tag-vpc","series-aws-with-terraform"],"jetpack_featured_media_url":"https:\/\/rezachegini.com\/wp-content\/uploads\/2026\/10\/building-secure-aws-infrastructure-cover.png","_links":{"self":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/137","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=137"}],"version-history":[{"count":1,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/137\/revisions"}],"predecessor-version":[{"id":138,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/137\/revisions\/138"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/media\/139"}],"wp:attachment":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=137"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=137"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=137"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fseries&post=137"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}