Amazon VPC

AWS 027

A web application can be perfectly healthy and still be unreachable because the network around it is wrong. The EC2 instance may be running, the application may be listening on the correct port, and the database may be healthy—but a missing route, incorrect subnet, or unexpected security rule can make the whole system look broken. Amazon VPC is where those decisions become concrete.

What You Will Learn

• What Is Amazon VPC?
• The Mental Model You Need
• VPC CIDR and IP Planning
• Subnets Inside a VPC
• Route Tables Decide the Path
• Internet Connectivity
• Private Subnets and Outbound Access
• Security Groups and Network ACLs
• Troubleshooting
• Production architecture
• Practical exercise
• Learning progression

1. What Is Amazon VPC?

Amazon VPC is the networking boundary in which AWS resources can communicate. A VPC defines an IP address range and provides the foundation for subnets, routing, security controls, gateways, and connectivity to other networks. A VPC spans the Availability Zones of its Region, while subnets are placed inside specific Availability Zones.

2. The Mental Model You Need

Do not think of a VPC as a single box around EC2. Think of it as a set of connected decisions: CIDR range, subnets, route tables, gateways, security groups, network ACLs, and service endpoints. When something cannot connect, work through those layers instead of randomly changing permissions.

At a Glance

3. VPC CIDR and IP Planning

Choose the address range before the environment grows. A common private IPv4 range might be 10.0.0.0/16, with smaller subnet ranges such as 10.0.1.0/24 and 10.0.2.0/24. Leave room for future Availability Zones, services, peering, VPNs, or other networks. Overlapping CIDRs become painful when networks later need to communicate.

4. Subnets Inside a VPC

A subnet is a range of IP addresses inside one Availability Zone. Public and private are routing concepts: a subnet is public when its route table has a route to an internet gateway; without that route, it is not publicly routed through an internet gateway. Keep application tiers deliberately separated rather than putting every resource into one subnet.

Example Architecture

Example traffic path

Internet
   ↓
Internet Gateway
   ↓
Public Subnet
   ↓
Application Load Balancer
   ↓
Private Subnet
   ↓
Application Servers
   ↓
Database Subnet

Private application servers → NAT Gateway → Internet Gateway → Internet

5. Route Tables Decide the Path

Route tables determine where packets go. The local route enables VPC-internal communication, while other routes can target an internet gateway, NAT gateway, peering connection, VPN, transit gateway, or other supported targets. When debugging, read the route table before assuming the application is at fault.

6. Internet Connectivity

An internet gateway connects a VPC to the internet. For an IPv4 resource to communicate directly through it, the resource needs an appropriate public IPv4 address or Elastic IP and the subnet route table must point internet-bound traffic to the gateway. A private subnet should not receive a direct internet-gateway route.

7. Private Subnets and Outbound Access

Private workloads often need to download packages, call external APIs, or reach public AWS endpoints without accepting unsolicited inbound connections. A public NAT gateway can provide outbound IPv4 connectivity for private subnets when routing is configured correctly.

8. Security Groups and Network ACLs

Security groups are stateful controls attached to resources or network interfaces. Network ACLs operate at the subnet boundary and are stateless. They solve different problems and should not be treated as interchangeable firewall layers.

9. VPC Endpoints

If workloads in private subnets need AWS services, VPC endpoints can reduce dependence on internet paths. Gateway endpoints support services such as S3 and DynamoDB; interface endpoints use AWS PrivateLink for supported services. This can simplify routing and reduce exposure.

10. A Real Production VPC Pattern

A common application layout uses two or more Availability Zones, public subnets for load balancers, private application subnets for compute, and private database subnets. Private application servers can use NAT for required outbound internet access while databases remain without direct internet routes.

11. The Debugging Experience

When a private EC2 instance cannot reach an API, check the subnet association, route table, NAT gateway path, security group egress, network ACLs, DNS behavior, and the destination itself. Change one layer at a time and test again. This is much faster than opening every port.

12. Common VPC Mistakes

Typical mistakes include overlapping CIDRs, putting databases in public subnets, assuming a public subnet automatically gives an instance a public IP, sharing one route table without understanding its blast radius, and forgetting that network controls and application permissions are separate.

13. Practical Exercise

Build a VPC with two Availability Zones, one public subnet and one private subnet per AZ, a load balancer in public subnets, application instances in private subnets, and a database tier without public routing. Then intentionally remove a route and diagnose the failure.

14. Learning Progression

After VPC basics, learn subnet design, routing, gateways, security groups, load balancing, DNS, private connectivity, and multi-VPC architectures. The goal is not memorizing resource names; it is being able to trace traffic from source to destination.

Advantages

• Centralized network boundary
• Flexible segmentation
• Works across Availability Zones
• Supports layered connectivity and security

Limitations and Considerations

VPC networking is flexible but can become difficult to operate if CIDRs, routing, and security rules are designed without a clear architecture.

Common Production Mistakes

• Changing several networking settings at once and then losing track of which change fixed or caused the problem.
• Using broad access rules because they are faster during troubleshooting, then forgetting to narrow them.
• Designing for the happy path without considering AZ failure, dependency failure, retries, or partial outages.
• Treating AWS service names as architecture instead of tracing the actual request or traffic flow.
• Skipping documentation of why a route, rule, queue, or subscription exists.

Interview and Architecture Perspective

A strong AWS engineer should be able to explain not only what the service does, but why it was selected, what failure it prevents, what dependency it introduces, and how the system behaves when something goes wrong. For this topic, practice drawing the traffic or message path from source to destination and naming every control point.

Practical Review Checklist

☐ Can you explain the request or traffic path without opening the AWS console?

☐ Can you identify the component that controls routing?

☐ Can you distinguish availability, security, and application-level failures?

☐ Can you explain what happens when a dependency fails?

☐ Can you troubleshoot the issue layer by layer instead of opening everything?

FAQs

Does every VPC have to be public?

No. A VPC can contain private and isolated workloads and may have no direct internet-facing resources.

Does a public subnet make every instance public?

No. Routing, public addressing, and security controls all matter.

A Production Failure Walkthrough

Imagine an application is deployed across two Availability Zones. The load balancer is healthy, the EC2 instances are running, and the database reports normal status. Users still receive timeouts. The first instinct is often to restart instances or open more security-group ports. An experienced engineer starts with the path instead: client to load balancer, load balancer to application subnet, application to database, and application to any external dependency. Each hop has a routing and security decision. If the application subnet is associated with the wrong route table, the server may be healthy but unable to reach a dependency. If the database subnet has an unintended route, the problem may be security rather than availability. VPC design makes these boundaries visible, which is why understanding the network is a prerequisite for reliable troubleshooting.

How to Design Before Creating Resources

Start with traffic requirements rather than clicking through the VPC console. List the users and systems that must communicate. Decide which components need inbound internet traffic, which only need outbound access, and which should never use the internet path. Then choose a CIDR range large enough for the expected growth. Map each tier across Availability Zones and assign subnet ranges. Only after that should you decide route tables, gateways, security groups, and endpoints. This order prevents a common mistake: creating resources first and discovering later that the address space or routing model cannot support the intended architecture. A simple network diagram with source, destination, port, and route target is often more valuable than a long list of console screenshots.

What an Experienced Engineer Checks First

When a VPC problem appears, check facts before changing configuration. Identify the exact source resource, destination hostname or IP, protocol, and port. Confirm the source subnet and its route table. Confirm the destination subnet and route path. Check security groups on both ends and the relevant network ACLs. If the destination is an AWS service, check whether a VPC endpoint is available and whether the workload is intended to use it. Finally inspect DNS and application logs. This sequence narrows the failure domain. It also protects production systems from the dangerous debugging habit of temporarily allowing all traffic and forgetting to restore the original policy.

Design Decisions That Matter

A mature VPC design answers several questions before deployment: Which workloads need inbound connectivity? Which workloads only need outbound access? Which tiers must be isolated? Which AWS services should be reached privately? Which networks may need to connect later? Which Availability Zone failure should the application tolerate? The answers determine CIDR allocation, subnet roles, route tables, gateways, endpoints, and security controls. A good VPC is therefore not the result of choosing the most AWS resources. It is the smallest network model that clearly expresses the application's communication requirements. When a requirement changes, engineers can identify which layer must change instead of modifying unrelated resources.

Failure Modes and Recovery

A VPC can fail in partial ways. One subnet can lose a route while another remains healthy. One Availability Zone can have an issue while another continues serving traffic. A NAT path can fail while internal database traffic remains available. This is why recovery plans should describe traffic paths rather than simply saying “restart the server.” For important workloads, document which resources can be recreated, which routes are expected, which subnets are paired across AZs, and how traffic should move during a failure. The best recovery documentation lets another engineer reconstruct the intended network without depending on the person who originally created it.

Hands-on Practical Lab

Hands-on lab: create a VPC with public and private subnets across two Availability Zones. Place an internet-facing load balancer in the public tier and application resources in the private tier. Trace a request from the internet to the load balancer, from the load balancer to the application, and from the application to a private dependency. Write down the route table, security group, and addressing decision at every hop. Then remove one route and diagnose the failure without opening additional ports. Restore the intended configuration and document the troubleshooting sequence. The purpose is to make VPC networking something you can reason about during a real incident.

Conclusion

Amazon VPC: Complete Guide to Virtual Private Cloud is most useful when treated as an engineering concept rather than a service definition. The goal is to understand the problem, the traffic or request flow, the configuration decisions, the failure modes, and the operational tradeoffs. That mindset is what turns AWS documentation knowledge into production-ready cloud skills.

Canonical URL: https://kodestree.com/amazon-vpc/