VPC & EC2

🔥 Vibe Prompt

"Design a 3-tier VPC with public, private, and DB subnets across 2 AZs. Deploy an EC2 bastion."

# Terraform: VPC with 3 tiers
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  count = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index}.0/24"
  availability_zone = data.aws_availability_zones.azs.names[count.index]
  map_public_ip_on_launch = true
}

resource "aws_subnet" "private" {
  count = 2
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.${count.index + 10}.0/24"
}

resource "aws_subnet" "db" {
  count = 2
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.${count.index + 20}.0/24"
}

VPC Architecture

Internet Gateway
     ↓
Public Subnets (load balancers, bastion)
     ↓
NAT Gateway
     ↓
Private Subnets (application servers)
     ↓
DB Subnets (RDS, ElastiCache - no internet)

EC2 Bastion

resource "aws_instance" "bastion" {
  ami                    = "ami-0c55b159cbfafe1f0"
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.public[0].id
  vpc_security_group_ids = [aws_security_group.bastion.id]
  associate_public_ip    = true
  key_name               = aws_key_pair.dev.key_name

  tags = { Name = "bastion" }
}

Security Groups

| SG | Rules | |----|-------| | Bastion | SSH (22) from your IP | | App | HTTP (80) from ALB only | | DB | PostgreSQL (5432) from App SG |

Best Practices

• Use NAT Gateway for private subnet internet
• Never assign public IPs to DB or App
• Use VPC Flow Logs for monitoring
• Enable VPC Endpoints for S3/SSM

Chapter Summary

• Understand core concepts and principles
• Master implementation methods and techniques
• Familiar with common issues and solutions
• Able to apply in real projects

Further Reading

• Official documentation and API references
• Open source examples on GitHub
• Technical books and online courses
• Community discussions and tech blogs

Implementation Example

Basic Example

# This section provides a complete implementation example

Steps

1. Setup: Configure development environment
2. Data: Prepare required data
3. Implementation: Build core functionality
4. Testing: Verify correctness
5. Optimization: Improve performance

Common Errors

| Error Type | Cause | Solution | |------------|-------|----------| | Compilation | Syntax | Check code syntax | | Runtime | Environment | Verify dependencies installed | | Logic | Algorithm | Step-by-step debugging | | Performance | Efficiency | Use profilers |

Code Example

import sys

def main():
    print("Hello, World!")

if __name__ == "__main__":
    main()

References

• Official documentation
• API reference
• Open source examples
• Community discussions

VPC Components

| Component | Purpose | |-----------|---------| | VPC | Isolated virtual network | | Subnet | Public or private network segment | | Route Table | Controls traffic routing | | Internet Gateway | Internet access for public subnets | | NAT Gateway | Outbound internet for private subnets | | Security Group | Instance firewall (allow only) | | NACL | Subnet firewall (allow + deny) | | VPC Peering | Connect two VPCs |

EC2 Instance Types

| Type | Use Case | Free Tier | |------|----------|----------| | t3.micro | General purpose, low CPU | ✅ Yes | | t3.small | General purpose | ❌ | | m5.large | Balanced compute/memory | ❌ | | c5.xlarge | CPU-intensive | ❌ | | r5.large | Memory-intensive | ❌ |

Summary

VPC and EC2 are the foundation of AWS. VPC provides isolated networking. EC2 provides virtual servers. Security Groups control traffic.

Key takeaways:

• VPC = isolated network in AWS |
• Public subnet = has internet gateway |
• Private subnet = no direct internet access |
• Security Group = allow rules only, stateful |
• NACL = allow + deny rules, stateless |
• EC2 free tier: t3.micro, 750 hours/month |
• User Data = script runs on first boot |
• Key Pair = SSH access to EC2 |

What's Next: RDS & S3

The next chapter covers RDS and S3.

Security Groups In-Depth

Security Groups act as a virtual firewall for EC2 instances. They control inbound and outbound traffic at the instance level.

Default Rules

| Direction | Default Behavior | |-----------|-----------------| | Inbound | All inbound traffic is denied by default | | Outbound | All outbound traffic is allowed by default |

Rule Characteristics

| Characteristic | Description | |---------------|-------------| | Stateful | If you allow inbound, the response is automatically allowed out | | Allow only | You can't create deny rules — only allow rules | | Evaluate all | All rules are evaluated together (not numbered) | | Reference by ID | You can reference other security groups by their ID |

Common Security Group Rules

| Type | Protocol | Port | Source | |------|----------|------|--------| | SSH | TCP | 22 | Your IP (e.g., 203.0.113.0/32) | | HTTP | TCP | 80 | 0.0.0.0/0 (anywhere) | | HTTPS | TCP | 443 | 0.0.0.0/0 (anywhere) | | App Traffic | TCP | 3000 | sg-other-app (another security group) | | Database | TCP | 5432 | sg-app-server (only app servers) |

Summary

Security Groups are instance-level firewalls with allow-only, stateful rules. They are the primary mechanism for controlling traffic to EC2 instances in AWS.

Key takeaways:

• Security Group = instance firewall (allow rules only) |
• Stateful: response traffic is automatically allowed |
• Default: deny all inbound, allow all outbound |
• Reference other SGs by ID for internal traffic |
• NACL = subnet firewall (allow + deny, stateless) |
• NACL rules are evaluated in order (numbered) |

What's Next: ECS & EKS

The next chapter covers ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service).