Amazon VPC explained

The short answer

An Amazon VPC (Virtual Private Cloud) is your own private network inside AWS. AWS describes it as a virtual network dedicated to your AWS account and logically isolated from other virtual networks. You choose its range of IP addresses, split it into subnets, and decide with route tables, gateways and security rules what can talk to what, and whether anything can reach the internet.

Almost everything you launch, such as an EC2 instance, a load balancer or an RDS database, lives in a subnet of a VPC. That is why networking is the first thing that goes wrong when an app on AWS “cannot connect”.

An analogy, and where it breaks

Think of the VPC as a private floor you rent in a large office building. You decide how the floor is divided into rooms (subnets). Signs in each room say which corridor leads where (route tables). There is one main entrance to the street (the internet gateway), and a mail room that sends letters out for people in back offices and passes the replies back, but never lets visitors in (the NAT gateway). Each room’s door has a guard with a list of who may enter (security groups), and each corridor has a checkpoint too (network ACLs).

Where the analogy breaks, and why it matters:

• A room is not “public” because of where it is. In AWS a subnet is public only because its route table sends internet traffic to the internet gateway. Change the route and the same subnet becomes private.
• Being in a public room is not enough to be reachable. A resource also needs a public IPv4 address (or an IPv6 address), and its security rules must allow the traffic.
• The guards remember differently. A security group remembers who it let out and lets their replies back in (it is stateful). A network ACL does not: it checks every packet against its list, in both directions (it is stateless).
• A room cannot span floors. Each subnet lives in exactly one Availability Zone, a separate data-centre location. To survive a zone failing, you build matching subnets in at least two zones.

The architecture, part by part

This is the most common shape for a web application on AWS. Choose any part to see what it is for, or choose a request to follow it through the network one step at a time.

The VPC and its address range

When you create a VPC you give it an IPv4 range in CIDR notation, such as 10.0.0.0/16. CIDR (Classless Inter-Domain Routing) writes a range as a starting address and how many leading bits are fixed: /16 fixes 16 bits and leaves 65,536 addresses. AWS allows a VPC between /16 (65,536 addresses) and /28 (16), and recommends the private ranges from RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

Pick a range that will not overlap networks you may need to connect later, such as other VPCs or your office. Peering, for example, refuses overlapping ranges. The CIDR calculator shows what a range contains and how it splits into subnets.

Subnets, public and private

A subnet is a smaller range inside the VPC, such as 10.0.10.0/24, and it lives entirely in one Availability Zone. Subnets can be between /28 and /16, and AWS keeps five addresses in each: in 10.0.0.0/24 those are .0 (network), .1 (VPC router), .2 (DNS), .3 (reserved) and .255 (broadcast, not supported in a VPC). A /24 therefore gives you 251 usable addresses, not 256.

AWS defines the subnet types by routing:

• Public subnet: has a direct route to an internet gateway.
• Private subnet: has no direct route to an internet gateway; it needs a NAT device to reach the internet.
• Isolated subnet: has no route out of the VPC at all. The database subnet in the diagram is one.

“Public” describes routing, not exposure. Whether a resource can actually be reached also depends on it having a public address, and on its security group and network ACL allowing the traffic. Put only what must face the internet, such as load balancers and NAT gateways, in public subnets.

Route tables, and the local route

A route table is a list of rules: each one has a destination (an address range) and a target (where to send matching traffic). Every subnet is associated with exactly one route table; a subnet you do not associate explicitly uses the VPC’s main route table.

Every route table contains a local route for the VPC’s own range, for example 10.0.0.0/16 → local. That is why every subnet in a VPC can reach every other subnet without you adding anything. When several routes match, AWS uses the most specific one (longest prefix match).

Public subnet           Private app subnet        Private DB subnet
10.0.0.0/16  local      10.0.0.0/16  local        10.0.0.0/16  local
0.0.0.0/0    igw-...    0.0.0.0/0    nat-...
                        pl-... (S3)  vpce-...

AWS suggests leaving the main route table in its original state, with only the local route, and associating each subnet with a custom table explicitly. Then a new subnet you forget to associate cannot accidentally become public.

Internet gateway and NAT gateway

The internet gateway connects the VPC to the internet. AWS describes it as horizontally scaled, redundant and highly available, so it is not a bottleneck. It does no filtering: it lets resources with a public IPv4 address (or IPv6) reach the internet and be reached from it, and security groups and network ACLs decide what is allowed.

A NAT gateway (network address translation) lets instances in private subnets start connections to the internet, for package updates or external APIs, while unsolicited connections from the internet cannot reach them. It swaps the private source address for its own public one and passes the replies back. It is not a firewall for outbound traffic: your security groups and network ACLs still decide what may leave.

AWS now offers two availability modes:

• Zonal (the classic design): you create the NAT gateway in a public subnet with an Elastic IP. Each one lives in one Availability Zone, so AWS recommends one per zone: if a shared NAT gateway’s zone fails, resources in the other zones lose internet access.
• Regional: one NAT gateway that expands into the zones where you have workloads, with no public subnet needed. AWS notes it can take up to 60 minutes to expand into a new zone, and that it does not do private NAT; for that, use zonal mode.

Security groups and network ACLs

Both filter traffic, at different levels. AWS’s advice is to use security groups as the main control and network ACLs as coarse, subnet-wide guard rails.

A new security group has no inbound rules, so nothing gets in until you add some, and one outbound rule allowing everything. Referencing security groups instead of IP ranges is what keeps the diagram’s chain tight: the app servers accept only the load balancer, and the database accepts only the app servers.

The load balancer and the private database

An internet-facing Application Load Balancer receives HTTPS from users and forwards it to healthy app servers. AWS requires it to be in subnets in at least two Availability Zones, one subnet per zone. The app servers stay in private subnets: only the load balancer needs to be public.

An RDS database belongs in its own private subnets. RDS needs a DB subnet group with subnets in at least two Availability Zones in the Region, even for a single-instance database, so it can be moved or made Multi-AZ later. Leave “publicly accessible” off, and allow the database port only from the app servers’ security group.

VPC endpoints, peering, Transit Gateway and Flow Logs

• Gateway endpoints give private subnets a route to Amazon S3 or DynamoDB in the same Region without an internet gateway or NAT device, at no additional charge. Other AWS services use interface endpoints (AWS PrivateLink), which are billed per hour and per GB processed.
• VPC peering connects two VPCs privately, one to one. Their address ranges may not overlap, and peering is not transitive: if A peers with B and B with C, A still cannot reach C through B.
• Transit Gateway is a hub that many VPCs and on-premises networks attach to, instead of a mesh of peering connections.
• VPC Flow Logs record the IP traffic going to and from network interfaces: who, where, which port, and whether it was accepted or rejected. AWS collects them outside the path of your traffic, so turning them on does not affect throughput or latency.

Four requests, step by step

The same walkthroughs as the diagram above, for reading straight through.

What breaks when one setting changes

The diagram’s “What if…” switches show this interactively. Each change below breaks one request, or makes it cost more, and leaves the others alone, which is how you can tell from the symptom which setting moved.

• Remove the public subnet's route to the internet gateway. A user opens the app: stops at the application load balancer. An internet-facing load balancer must sit in public subnets. Without the route, requests from the internet never get an answer. A private server downloads updates: stops at the nat gateway. The NAT gateway's own subnet can no longer reach the internet gateway, so nothing behind it can reach the internet.
• Remove the app subnet's 0.0.0.0/0 route to the NAT gateway. A private server downloads updates: stops at the application servers. No route matches internet addresses any more, so the download times out. Traffic inside the VPC still uses the local route.
• Delete the S3 gateway endpoint. The app reads from S3: still works, but costs more. S3 traffic now follows 0.0.0.0/0 through the NAT gateway. It still works, but every gigabyte is billed as NAT data processing.
• App servers' security group stops allowing the load balancer. A user opens the app: stops at the application servers. The load balancer cannot reach any target and health checks fail, so users get errors from the load balancer instead of the app.
• Database security group allows its port only from 10.0.20.0/24 (its own subnet). The app queries the database: stops at the database (amazon rds). The app servers are in 10.0.10.0/24, which no rule allows. Security groups have no deny rules: anything not allowed is dropped.

Build it with the AWS CLI

You need the AWS CLI v2 configured for a test account, and permission to create VPC resources. Every create command prints an ID; use yours where these examples show vpc-0abc, subnet-0pub and so on.

To check it worked, launch a small instance with no public IP in the app subnet and connect through AWS Systems Manager Session Manager, so you need neither a public address nor SSH.curl -I https://aws.amazon.com should then succeed through the NAT gateway, and a request from the internet to the instance cannot reach it. Session Manager needs the instance to have the right permissions (the AWS managed policy AmazonSSMManagedInstanceCore provides them) and a way to reach the Systems Manager endpoints: the NAT gateway gives it one, or you can add interface endpoints for ssm, ssmmessages and ec2messages.

The same in Terraform

The same single-zone layout as Terraform, for reading alongside the CLI steps. It was formatted and syntax-checked with Terraform 1.14 (terraform fmt) but not validated against the AWS provider or applied; run terraform plan and read it before applying anything.

Troubleshooting

Most connectivity problems in a VPC come down to the same questions: does the name resolve, is there a route, is there a public address where one is needed, does the security group allow it, does the network ACL allow it both ways, and is the service on the far end actually listening? The commands below answer them without guessing.

Production considerations

• Availability: repeat every subnet in at least two Availability Zones, put the load balancer and the database subnet group across them, and give each zone its own route to a NAT gateway in the same zone (or use a regional NAT gateway).
• Security: only the load balancer is internet-facing. Chain security groups by reference: load balancer → app → database. Use network ACLs sparingly, as subnet-wide guard rails.
• Cost: NAT gateways and public IPv4 addresses are billed by the hour, and NAT data by the gigabyte. Keep S3 and DynamoDB traffic on gateway endpoints, keep instances in the same zone as their NAT gateway, and delete what you do not use.
• Visibility: turn on VPC Flow Logs, at least for rejected traffic, before you need them. They cannot tell you about yesterday if they were off yesterday.
• Address planning: leave room. Choose a VPC range that cannot overlap other VPCs or your office network, and size subnets for growth, remembering the five reserved addresses in each.

Common mistakes

• Calling a subnet private because of its name. Only its route table decides.
• Putting app servers in public subnets “so they can download updates”. That is what the NAT gateway is for.
• Thinking a NAT gateway makes a workload secure. It stops unsolicited inbound connections; it does nothing about what your instances send out, or about traffic arriving through the load balancer.
• Opening a database’s security group to 0.0.0.0/0 while debugging, then forgetting it.
• Allowing a request through a network ACL but not its reply, which comes back on a high-numbered port the client chose.
• Leaving a NAT gateway and its Elastic IP running after a lab.

Interview questions

What makes a subnet public?

Its route table has a route to an internet gateway. A resource in it still needs a public IPv4 or IPv6 address, and security rules that allow the traffic, to be reachable.

Why put the NAT gateway in a public subnet?

A zonal NAT gateway sends traffic to the internet through the internet gateway, so its own subnet must route 0.0.0.0/0 to the internet gateway. A regional NAT gateway is the exception: it needs no public subnet.

Security group or network ACL: which would you use to block one IP address?

A network ACL, because security groups have no deny rules. For allowing traffic, security groups are the main tool: they are stateful and can reference other security groups.

Two VPCs are peered, but traffic does not flow. What do you check?

Routes in both VPCs pointing at the peering connection, security groups on both sides, and that the ranges do not overlap. Also that traffic is not expected to pass through a third VPC: peering is not transitive.

How would you cut a large NAT gateway bill?

Find what the traffic is. Move S3 and DynamoDB traffic to gateway endpoints, keep instances and their NAT gateway in the same Availability Zone to avoid cross-zone charges, and remove NAT gateways nothing uses.

Questions people ask

Do I need a NAT gateway at all?

Only if private instances must start connections to the internet. A database subnet usually needs none, and S3 or DynamoDB access can use a gateway endpoint instead.

What is the default VPC?

An AWS account created after 4 December 2013 has one in each Region, with a public subnet in every Availability Zone, an internet gateway and a route to it. That is why an instance launched there gets internet access straight away. It is handy for experiments; for real workloads, build your own VPC with private subnets.

Can I change a VPC’s address range later?

You can add more IPv4 CIDR blocks to an existing VPC, and later remove those again, but you cannot remove the primary block it was created with. Plan that one before you build.

Where to go next

• Who may use what runs in this network, and why a request is denied: AWS IAM explained.
• The instances themselves, and what survives a stop and start: Amazon EC2 explained.
• Launch an instance into a network like this one, with the choices that matter (keys or Session Manager, IMDSv2, user data): AWS EC2 and VPC: Building Your First Cloud Infrastructure.
• Split your own range into subnets with the CIDR calculator.
• See what the same ideas look like inside a cluster: Kubernetes DNS resolution failures and a Service with no endpoints.
• When the trouble is a certificate rather than the network: x509: certificate signed by unknown authority.