Provision an AWS VPC and Security Group with Terraform

The pieces

• VPC - your private network (a CIDR block like 10.0.0.0/16).
• Subnet - a slice of the VPC where the instance lives (10.0.1.0/24).
• Security group - a stateful firewall on the instance; here, allow inbound 80.
• Instance - wired to the subnet + security group.

The Terraform

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "web-vpc" }
}

resource "aws_subnet" "main" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_security_group" "web" {
  name   = "web"
  vpc_id = aws_vpc.main.id

  ingress {                       # only port 80, from anywhere
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {                        # allow all outbound
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "web" {
  ami                    = data.aws_ami.default.id
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.main.id          # in the subnet
  vpc_security_group_ids = [aws_security_group.web.id] # using the SG
}

The details that matter

• Security groups are stateful - allow inbound 80 and the response goes back out automatically; you don't need a matching egress rule for replies.
• Wire the instance to both - subnet_id and vpc_security_group_ids. Miss the SG and it falls back to the default group (often wrong).
• Least privilege ingress - only the ports you actually serve. Don't open 22 to 0.0.0.0/0; scope SSH to your IP or use SSM.
• Resources reference each other by id (aws_vpc.main.id), which is how Terraform orders creation - VPC before subnet before instance.

Security group rules and common mistakes

A security group is stateful: if you allow an inbound request, the response is automatically allowed back out - no matching egress rule needed. Each rule lists ports plus a source, and the source can be a CIDR (cidr_blocks = ["10.0.0.0/16"]) or another security group id, which is the cleaner way to let one tier talk to another.

The mistakes that bite:

• Opening SSH to the world - 0.0.0.0/0 on port 22 invites brute force. Scope it to your IP or a bastion.
• Forgetting egress - the aws_security_group resource has no egress unless you add one, so the instance cannot reach the internet. Add an egress rule if it needs outbound.
• Confusing it with a NACL - security groups are per-instance and stateful; network ACLs are per-subnet and stateless. Use security groups for app-level access control.