VPC: Subnets, Route Tables, Security Groups

Concept

A VPC (Virtual Private Cloud) is your own private network inside AWS. It is a part of AWS's huge data centres that belongs only to you. It has its own range of IP addresses, its own doors to the internet and its own firewalls. (An IP address is the number that identifies a computer on a network. A firewall is a filter that allows or blocks network traffic.) Nothing gets in or out unless you built a door for it.

In Lesson 2 you learned how a request travels across the internet to a server. A VPC is the network on the server's side of that journey. On Vercel this layer is hidden. On AWS you design it yourself.

Why this matters

Many serious AWS mistakes are networking mistakes:

• A database is launched with a public IP and a Security Group that allows 0.0.0.0/0 (every address on the internet) on port 5432 (the PostgreSQL port). Within hours, bots try passwords against it. This is how many “company X leaked millions of records” stories begin.
• A server “cannot be reached” for two days, because nobody knew that the route table was the problem and not the Security Group.
• A NAT Gateway is left running for a month. It quietly costs more than the servers.

A well-designed VPC makes the safe choice the default. The database physically cannot be reached from the internet, because there is no path to it. This is much stronger than a firewall rule that you hope nobody edits.

The analogy — an office building

Picture a company that rents a whole building.

The reception desk and the shop front are on the public floor. The finance department and the safe are on a staff-only floor with no door to the street at all. This one design choice does most of the security work.

IP ranges and CIDR, once and for all

CIDR (Classless Inter-Domain Routing) is a short way to write a whole range of IP addresses, such as 10.0.0.0/16. You met it in Lesson 2. Now it is practical, because AWS asks you to choose a range when you create a VPC. The rule is short:

Why 251 and not 256? AWS keeps five addresses in every subnet for its own use: the network address, the VPC router, the DNS server, one saved for future use, and the broadcast address. (The router passes traffic between networks. DNS turns names into IP addresses. A broadcast address sends a message to every device at once.) This is a favourite interview question.

Choosing the range — three practical rules

• Use a private range: 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. These ranges are reserved for private networks and are never used on the public internet.
• Do not overlap with any network you may connect later, such as your office, a second VPC or a partner. Two networks with the same range cannot be joined. This is hard to fix afterwards, so real teams plan the ranges on paper first.
• Leave room to grow. A /16 VPC with /24 subnets costs nothing. It gives you room for 256 subnets of 251 usable addresses each.

The seven pieces of a VPC

Here is the layout this whole course builds. Read it top to bottom, like a request would.

Availability Zones — why we make four subnets, not two

A region is a geographic area where AWS runs data centres, such as ap-south-1 (Mumbai). Each region has several separate groups of data centres called Availability Zones (AZs), for example ap-south-1a, 1b and 1c. They are far enough apart that a fire or a power cut in one does not affect the others.

A subnet lives in one AZ. To survive the failure of an AZ, you need each kind of subnet in at least two AZs. Two services require this later:

• The load balancer (Lesson 12) needs subnets in at least two AZs. A load balancer is a service that shares incoming requests between several servers.
• An RDS subnet group (Lesson 8) needs subnets in at least two AZs, even if you run only one database. RDS is the AWS managed database service.

So we create four subnets: one public and one private in AZ a, and one public and one private in AZ b. This is cheap (subnets are free) and saves you a rebuild later.

What makes a subnet public or private

Many people misunderstand this idea in AWS networking, but it is simple.

A route table works like the signs in a lift. When traffic leaves, AWS looks for the row with the most specific matching range first. Here are two examples:

Destination       Target
10.0.0.0/16       local          # anything inside the VPC stays inside
0.0.0.0/0         igw-0abc123    # everything else goes out the front door

Destination       Target
10.0.0.0/16       local          # can talk to other subnets in this VPC
                                 # no 0.0.0.0/0 row = no path to the internet at all

The local row is added automatically and cannot be deleted. It is the reason an app server in a public subnet can reach a database in a private subnet with no extra setup. Inside the VPC, every subnet has a route to every other subnet. Security Groups, not routes, decide who is actually allowed in.

A public subnet is not enough — the public IP

For a server to be reachable from the internet, it needs both a public subnet and a public IP address. The public IP can be assigned automatically, or it can be an Elastic IP (a fixed public address, from Lesson 7). A server in a public subnet without a public IP can talk to other servers inside the VPC. It cannot reach the internet, and the internet cannot reach it. The reason is that the IGW only translates addresses for instances that have a public one. This is a common mistake. Remember: you need the route and the public IP.

Security Groups vs Network ACLs

You have used Security Groups since Lesson 2. AWS also gives you a second, older firewall called a Network ACL (NACL, where ACL means access control list). Here is how they differ. The question “explain SG vs NACL” is asked in almost every AWS interview.

Two words in the table need a plain explanation. Stateful means the firewall remembers a connection. If a request is allowed in, the reply is allowed out automatically. Stateless means the firewall remembers nothing, so you must write a rule for the reply traffic too.

Our rule: leave the NACL at its default (allow all) and do your real work with Security Groups. Use a NACL only for one job that Security Groups cannot do: block a bad IP range for a whole subnet.

The best Security Group trick — reference another group

Instead of an IP address, a rule can name another Security Group as the source. This keeps the database private, even when you add more servers:

alb-sg   inbound: 80, 443   from 0.0.0.0/0        # the public front door
web-sg   inbound: 80, 443   from alb-sg           # only the load balancer may talk to servers
         inbound: 22        from YOUR-IP/32       # only you may SSH
db-sg    inbound: 5432      from web-sg           # only app servers may reach Postgres
cache-sg inbound: 6379      from web-sg           # only app servers may reach Redis

Auto Scaling is the AWS feature that adds or removes servers when traffic changes. When it launches a tenth server, that server joins web-sg and may reach the database at once. There is no rule to edit and no IP to allow. A stranger who has the database password still cannot connect, because their machine is not in web-sg. Layer one (the private subnet) and layer two (the Security Group) both say no.

NAT Gateway — and why it can raise your bill

Here is a real problem. A server in the private subnet needs to download operating-system security updates. But it has no route to the internet. That was the whole point. How does it reach the update servers?

A NAT Gateway (NAT means Network Address Translation) is an AWS service that lets private servers start connections to the internet without being reachable from it. It sits in a public subnet. Private servers send their outbound traffic to it. It forwards the traffic using its own public IP and passes the replies back. Outsiders cannot start a connection to the private server. The door opens one way only, like a phone that can call out but has no number for people to call in.

Ways to avoid paying for it

• Our approach in this course: skip the NAT. The database never needs to call the internet, because AWS patches RDS for you. Only the app servers need outbound access. They live in the public subnet, where the Internet Gateway gives it to them for free.
• VPC endpoints are private doors from your VPC to an AWS service. The Gateway type, for S3 and DynamoDB, is free. It lets private servers reach S3 without a NAT and without using the internet. Add one whenever a private server talks to S3.
• Interface endpoints (for SSM, ECR, Secrets Manager and others) cost about $0.011 per hour per AZ. This can be cheaper than a NAT if you need only a few services.
• Real production usually does use a NAT (one per AZ, so that one AZ failure does not cut off the others). If your traffic is high, it is worth it. At the size of this course, it is not.

The default VPC — and why we do not use it

Every region in a new AWS account already has a default VPC. It has a public subnet in every AZ and an Internet Gateway attached. This is why the “launch instance” wizard works for a beginner: it puts your server in the default VPC without telling you.

The default VPC is fine for learning EC2 in ten minutes. It is wrong for real work:

• Every subnet is public, so there is nowhere safe to put a database.
• Instances get public IPs by default.
• You did not design it, so you do not know exactly what is in it.

You should know that it exists and that you can leave it alone. Do not delete it, because some services expect it. We build our own VPC.

Build it: the full VPC, step by step

The console builds most of this on one screen. Take your time and read each field. Every box matches one piece from the diagram above. In Lesson 15 you will write the same network as code with Terraform (a tool that creates cloud resources from text files).

1. Create the VPC and its subnets

   VPC → Create VPC → choose VPC and more. Name it myapp, CIDR 10.0.0.0/16, 2 Availability Zones, 2 public and 2 private subnets, NAT gateways None (they cost money — see above), VPC endpoints None, and keep DNS hostnames enabled (RDS endpoint names need it).

   The preview on the right is the resource map. It shows four subnets, one Internet Gateway and route tables that are already connected. Create it.

2. Read what the wizard made

   Open the public route table: it has the local row plus 0.0.0.0/0 → igw-…. That one row is the whole difference between public and private. The private route tables have only local. An Internet Gateway that no route points to does nothing. The route is the sign that sends traffic to the door.

   On each public subnet, turn on auto-assign public IPv4 (Edit subnet settings), so servers launched there get a public address.

3. Create the three Security Groups

   EC2 → Security Groups → Create, in the myapp VPC:

   Group	Inbound rule	Source
   alb-sg	HTTP 80, HTTPS 443	0.0.0.0/0 — the whole internet
   web-sg	HTTP 80, HTTPS 443	the group alb-sg
   web-sg	SSH 22	“My IP” (a /32)
   db-sg	PostgreSQL 5432	the group web-sg

   For the group-to-group rules, type sg- in the source box and pick the group by name. This is the trick from above: the rule follows the servers, not their IP addresses.

   Your IP changes

   Home and mobile connections often get a new IP address after some days. If SSH suddenly times out next week, update the “My IP” rule. SSH is the secure remote login tool, and it uses port 22. In Lesson 18 you will remove port 22 and use SSM Session Manager instead (an AWS tool that opens a shell without any open port).

4. Write down the IDs

   Later lessons ask for “the private subnets” or “web-sg”. Keep a note of the VPC ID, the four subnet IDs and the three Security Group IDs. The console shows them all on the VPC's resource map.

When something cannot connect — the checklist

Sooner or later you will watch an ssh command hang or a browser spinner turn forever. Do not guess. Check the request's path in order. A packet is a small piece of data sent over the network, so follow the packet:

Read the symptom, not just the failure

What this costs

Everything you built above is free. We are deliberately not creating a NAT Gateway in this course.

Interview corner

Read the question and try to answer out loud in two sentences. Then open the answer. These questions come up in real AWS interviews.

Practice task before Lesson 7

Build the network from the previous section. Then check that it works as designed. Everything is free.

1. Confirm four subnets, one Internet Gateway, one custom route table and three Security Groups exist in the console (VPC → Your VPCs → the resource map shows the picture).
2. Open the resource map and find the line from the public route table to the IGW. Now delete that one route in the console. What do you predict happens to the public subnets? Add it back.
3. Draw the VPC on paper without looking. Label each subnet with its CIDR, its AZ and whether it is public. Compare your drawing with the figure above.
4. Write down, for each Security Group, who may connect on which port. Which of the three has a rule that names another group instead of an IP, and why is that better?
5. Stretch: create a free S3 Gateway endpoint (VPC → Endpoints → Create → S3, type Gateway, pick your route tables). It adds a route to the table. Find it.

Conclusion

A VPC is a private building you rent inside AWS. Subnets are its floors. Route tables are the signs that decide where traffic goes. The Internet Gateway is the front door. Security Groups are the guards at each office.

• Public vs private is one route-table row: 0.0.0.0/0 → igw. Delete it and the subnet is private.
• Two layers of safety: the database is in a private subnet and its Security Group accepts only the app's Security Group.
• Two AZs from day one, because the load balancer and RDS both demand it.
• NAT Gateways cost money and are easy to forget. Skip them until your traffic needs them. Use free S3 endpoints instead.
• Debug in path order: instance → public IP → Security Group → route → NACL → listening port. “Timed out” means something blocked the traffic. “Refused” means no program was listening.

The network exists, but it is empty. Next we put the first real server in it: EC2.

End of Lesson 6. Next: Lesson 7 — EC2: Launch Your First Server and Deploy Next.js Manually.