Command Palette

Search for a command to run...

Hectal
PHASE 6Advanced ~15 min· topic 6 of 8

Topic 6.6

Cloud Networking: VPCs, Subnets, Gateways & Peering

In one line

A VPC is your own private network inside a cloud region, with a CIDR range you choose. You split it into subnets per availability zone. A subnet is 'public' when its route table sends 0.0.0.0/0 to an internet gateway, and 'private' when it doesn't, usually reaching out through a NAT gateway instead. VPCs connect to each other with peering or a transit gateway, and to cloud services privately with VPC endpoints. Plan non-overlapping CIDRs from day one.

0/8 · 0%

Think of it like this

A gated housing society. The society (VPC) has its own address plan. Some blocks face the main road with a gate (public subnets with an internet gateway), others are inside with no direct road access (private subnets). Residents inside can still go out through a staffed exit (NAT gateway), but strangers can't walk in.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

VPC
Virtual Private Cloud: an isolated private network in a cloud region.
Subnet
A range of addresses within a VPC, located in one availability zone.
Route table
Rules deciding where traffic from a subnet goes, by destination prefix.
Internet gateway (IGW)
The VPC's two-way door to the internet for resources with public IPs.
NAT gateway
A managed service letting private resources start outbound internet connections.
VPC endpoint
A private connection from the VPC to a cloud service, avoiding the internet.
VPC peering / transit gateway
Ways to connect VPCs: one-to-one links, or a central hub.

Step by step

01Tiffin's Mumbai VPC

The VPC uses 10.0.0.0/16 in ap-south-1, across two availability zones. Load balancers sit in public subnets, app servers and databases in private ones. App servers reach Razorpay through NAT gateways, and S3 through a gateway endpoint.

Tiffin's Mumbai VPCdiagram
Rendering diagram…

02What makes a subnet public

The two route tables differ by one line. That line is the whole difference between 'reachable from the internet' (with a public IP and an open security group) and 'not'.

terminal
$ aws ec2 describe-route-tables --filters Name=tag:Name,Values=public-a,private-app-a --query 'RouteTables[].{name:Tags[?Key==`Name`]|[0].Value,routes:Routes[].[DestinationCidrBlock,GatewayId||NatGatewayId]}' --output yaml
── expected output ──
- name: public-a
routes:
- - 10.0.0.0/16
- local
- - 0.0.0.0/0
- igw-0a1b2c3d
- name: private-app-a
routes:
- - 10.0.0.0/16
- local
- - 0.0.0.0/0
- nat-0f9e8d7c

03Connecting a second VPC

The analytics team builds a VPC with 10.1.0.0/16, so the ranges don't overlap. Peering connects them, but traffic only flows once both sides have routes to each other and the security groups allow it. Peering isn't transitive: analytics can't reach the office VPN through the main VPC.

terminal
$ aws ec2 create-vpc-peering-connection --vpc-id vpc-main --peer-vpc-id vpc-analytics --query 'VpcPeeringConnection.VpcPeeringConnectionId'
aws ec2 create-route --route-table-id rtb-private-app-a --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id pcx-0c1d2e3f
── expected output ──
"pcx-0c1d2e3f"
{
"Return": true
}
The peering must also be accepted, and the analytics VPC needs the reverse route to 10.0.0.0/16.

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

Overlapping CIDRs

A partner kitchen's network also uses 10.0.0.0/16. Tiffin tries to connect it with a site-to-site VPN.

terminal
$ ip route get 10.0.1.20 # from a partner server
── what you'll see ──
10.0.1.20 dev eth0 src 10.0.1.33 uid 1000
cache
The partner's server thinks 10.0.1.20 is on its own local network, so traffic never enters the VPN.

Myth vs fact

Myth

Private subnets can't reach the internet.

Fact

They can't be reached *from* the internet. Through a NAT gateway they can still make outbound connections.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

  • ▸

    NAT gateway data charges add up quietly. Large S3 or ECR traffic from private subnets should go through VPC endpoints (gateway endpoints for S3 and DynamoDB are free), which can cut a big part of the NAT bill (see the AWS course).

Remember this

  1. 1

    VPC: a private network with a CIDR block (for example 10.0.0.0/16) in one region. It spans all the region's availability zones.

  2. 2

    Subnet: a slice of the VPC's range (for example 10.0.1.0/24) inside one availability zone. Use at least two AZs for anything that must survive an AZ outage.

  3. 3

    Public vs private isn't a setting. It's the route table: 0.0.0.0/0 → igw-… makes a subnet public, 0.0.0.0/0 → nat-… (or no default route) makes it private.

  4. 4

    Internet gateway: two-way internet access for resources with public IPs. NAT gateway: outbound-only access for private resources (Topic 4.3), billed per hour and per GB.

  5. 5

    VPC endpoints reach services like S3 or DynamoDB (gateway endpoints) or other AWS APIs (interface endpoints) without going via the internet or NAT, which is cheaper and more private.

  6. 6

    Connecting networks: VPC peering (one-to-one, non-transitive), transit gateway (a hub for many VPCs and VPNs), and site-to-site VPN or Direct Connect to offices and data centres. All need non-overlapping CIDRs.

Explain it without notes

01

What makes a subnet public?

02

Why does VPC peering need non-overlapping CIDRs?

Practice

01

Design subnets for a VPC 10.0.0.0/16 with public, app, and database tiers in two AZs.

02

Explain the path a request takes from a private app server to api.razorpay.com.

Trade-offs

  • ↔

    One NAT gateway per AZ costs more but avoids cross-AZ traffic and a single point of failure. Peering is simple for a few VPCs, and a transit gateway scales to many but adds cost per attachment and per GB.

Done when you can

  • I can explain public vs private subnets by route tables.

  • I know when to use NAT gateways and VPC endpoints.

  • I plan non-overlapping CIDRs.