Amazon VPC: A Complete Guide to AWS Networking

Amazon Virtual Private Cloud (VPC) is a logically isolated virtual network in AWS dedicated to your account. You define its IP address range (CIDR block), create subnets, and attach gateways or VPNs as needed. A VPC spans an AWS Region and consists of one or more Availability Zones (AZs). Within a VPC, you launch AWS resources (EC2, RDS, etc.) into subnets — IP ranges tied to a specific AZ.

By default, AWS creates a default VPC in each Region with one public subnet per AZ, an Internet Gateway (IGW) attached, and default routes to enable internet access. You can also create custom VPCs with private subnets for tighter network control.

CIDR & Subnetting

VPCs use CIDR notation (e.g. 10.0.0.0/16) to define IP ranges. The number of addresses = 2^(32–prefix). For example, 10.0.0.0/24 yields 256 addresses.

You can split a VPC CIDR into multiple non-overlapping subnets. For example, 10.0.0.0/24 can be split into:

• 10.0.0.0/25 — 128 IPs
• 10.0.0.128/25 — 128 IPs

Important: AWS reserves the first four and last IP in each subnet. In 10.0.0.0/24, addresses 10.0.0.0–10.0.0.3 and 10.0.0.255 are unusable (network, gateway, DNS, future use, broadcast). Valid IPv4 subnet sizes in AWS range from /28 to /16.

Availability Zones & Subnets

Each subnet resides entirely in one AZ — it cannot span AZs. For high availability, AWS recommends subnets in at least two AZs.

Common practice is to have matching public/private subnet pairs in each AZ:

• AZ-A: public subnet + private subnet
• AZ-B: public subnet + private subnet

This ensures resources survive an AZ failure. Subnets are carved out of the VPC’s CIDR and must not overlap.

Public vs. Private Subnets

A public subnet is one whose route table has a default route (0.0.0.0/0) pointing to an Internet Gateway (IGW). Instances in public subnets must have a public IPv4 address or Elastic IP (EIP) to communicate with the internet.

A private subnet has no IGW route. Traffic from a private subnet cannot reach the internet unless routed through a NAT device. Even if an instance in a private subnet has a public IP, it won’t reach the internet without a matching route.

Route Tables

Each subnet is associated with a route table. If the table has an IGW route, it’s public; if not, it’s private. By default, all subnets use the “main” route table unless you associate them with a custom one.

Internet Gateway (IGW)

The IGW provides a target for internet-bound traffic in public subnets. It also performs one-to-one NAT for IPv4 (maps private instance IPs to public IPs). IGWs are free to attach — you only pay data transfer charges.

Elastic IP (EIP)

An EIP is a static public IPv4 address allocated to your AWS account. Unlike automatically assigned public IPs, an EIP remains allocated until you release it. Each account is limited to 5 EIPs per region by default.

NAT Gateways vs. NAT Instances

Instances in private subnets often need internet access (e.g. to download patches) but should not be directly reachable from the internet. A NAT device enables outbound-only internet access. AWS offers two options:

NAT Gateway (AWS-managed) NAT Instance (self-managed) Availability Highly available, AWS-provisioned per AZ. Deploy one per AZ for full AZ-independence. Single EC2 instance. Manual failover setup required. Bandwidth Scales to ~100 Gbps Limited by EC2 instance type Maintenance Fully managed by AWS You manage OS/patches Cost ~$0.045/hr + ~$0.045/GB Normal EC2 instance pricing Security Groups Not supported; use NACLs Supported directly

Recommendation: NAT Gateways are preferred for production — simpler, highly available, and auto-scaling. NAT Instances may be used for very low-volume needs but require manual HA setup.

Traffic flow: Private subnets route 0.0.0.0/0 to the NAT Gateway → NAT Gateway forwards to the IGW using its EIP → return traffic maps back to the original private IP.

Security Groups vs. Network ACLs

AWS provides two layers of networking security:

Security Groups (SGs)

• Stateful firewalls at the instance/ENI level
• Allow rules only (implicit deny for everything else)
• Return traffic is automatically allowed (stateful)
• Default SG: allows all traffic within itself, no outside inbound

Network ACLs (NACLs)

• Stateless firewalls at the subnet level
• Support both allow and deny rules
• Return traffic must be explicitly allowed (stateless)
• Default NACL: allows all inbound and outbound traffic
• Rules evaluated by number order; first match wins

Feature Security Groups Network ACLs Applied to Instance (ENI) level Subnet level Stateful? Yes — return traffic auto-allowed No — return traffic must be explicit Rule types Allow only Allow and deny Rule evaluation All rules evaluated Ordered; first match applied

In practice: Most teams rely on SGs for instance-level protection and use NACLs as an optional extra layer.

VPC Peering and Transit Connectivity

VPC Peering

A point-to-point, secure connection between two VPCs. Can be within the same account or across accounts, and even inter-region. Data transfer within a single AZ is free.

Limitations:

• Non-transitive: If VPC A peers with B and C, B cannot reach C through A
• Doesn’t scale well: full-mesh requires n(n–1)/2 connections (max 125 peerings per VPC)
• Peered VPCs don’t share on-prem connectivity

AWS Transit Gateway (TGW)

A fully managed, regional “cloud router” that acts as a hub connecting thousands of VPCs and on-prem networks. Supports transitive routing — attach each VPC only once (hub-and-spoke).

TGW simplifies management: instead of N² peering links, you manage routes in TGW route tables. Note: overlapping CIDRs are not allowed on TGW attachments.

VPC Endpoints

A VPC Endpoint lets your VPC privately access AWS services without using an IGW, NAT, or VPN.

Gateway Endpoints

• Only for Amazon S3 and DynamoDB
• Adds target entries in route tables; traffic stays on the AWS network
• No data processing cost
• Only works within the same region and VPC (no on-prem or cross-VPC access)

Interface Endpoints (AWS PrivateLink)

• For most other AWS services (SSM, ECR, CloudWatch, Kinesis, SNS, etc.)
• An ENI in your subnet with a private IP
• Works across accounts, regions, and from on-prem via Direct Connect/VPN
• Incurs hourly charge + data processing fees

Rule of thumb: Use gateway endpoints for S3/DynamoDB whenever possible (free). Use interface endpoints for other services and for cross-VPC/on-prem use cases.

Bastion Host, VPN & Direct Connect

Bastion Host

A jump box in a public subnet that administrators use to SSH/RDP into private subnet servers. Best practices:

• Lock down the SG to known IPs only
• Use key-based authentication
• Consider AWS Systems Manager Session Manager as a bastion-less alternative (no inbound ports needed)

Site-to-Site VPN

IPSec VPN tunnels between a VPC and on-premises networks. Uses a Virtual Private Gateway with two parallel tunnels for HA. Supports BGP route propagation.

AWS Direct Connect

A dedicated network link between your data center and AWS (1–100 Gbps). Offers lower latency and higher bandwidth than VPN. Data over Direct Connect is not encrypted by default (enable MACsec or run VPN over DX for encryption). Use multiple DX connections in different locations for redundancy.

Multi-AZ Web App Architecture

Here’s a typical layered web-app architecture:

1. Route 53 (DNS) directs the user’s request to a public Application Load Balancer (ALB)
2. The ALB sits in the public subnet and routes traffic to EC2 instances in private subnets
3. EC2 instances in private subnets handle application logic and read/write from RDS
4. Outbound internet access for private instances (e.g. updates) flows via a NAT Gateway in the public subnet
5. RDS has no public route and is only accessible within the VPC via SGs

For production, add: Route53 health checks, NAT Gateways per AZ, multi-AZ RDS, and Auto Scaling groups.

EKS (Kubernetes) Networking

AWS EKS clusters are deployed in a VPC. Best practices:

• Use at least two subnets in different AZs when creating a cluster
• Worker nodes run in private subnets; public load balancers run in public subnets
• Ingress traffic enters through public ELBs/NLBs and reaches pods in private subnets
• Egress traffic (e.g. pulling images from ECR/S3) goes via NAT Gateways or VPC endpoints
• Ensure you allocate enough IPs per subnet (e.g. /24 per AZ) to accommodate Pods and ENIs

Best Practices & Common Pitfalls

Do this:

• Plan sufficient IP space upfront — AWS reserves 5 IPs per subnet
• Deploy resources (servers, NAT Gateways, RDS replicas) across multiple AZs
• Use gateway endpoints for S3/DynamoDB to avoid NAT/IGW costs
• Use VPC Flow Logs and Reachability Analyzer for monitoring and debugging
• Restrict SG rules to minimum needed (no 0.0.0.0/0 on SSH)

Avoid this:

• Forgetting to attach an IGW or add a route in a new VPC
• Omitting NAT, leaving private subnets with no outbound access
• Overlapping CIDRs across VPCs (breaks peering and Transit Gateway)
• Ignoring the 5-IP reservation per subnet when planning address space

Quick Reference: Interview Q&A

What is a VPC? A customizable, private virtual network in AWS — isolated from other VPCs, with subnets, route tables, and gateways.

Public vs. Private Subnet? Public if route table has 0.0.0.0/0 → IGW and instances have public IPs. Private if no IGW route — private instances need NAT for internet access.

NAT Gateway vs. NAT Instance? NAT Gateway: AWS-managed, HA per-AZ, 100 Gbps, no maintenance. NAT Instance: self-managed EC2, manual HA. Use NAT Gateway for production.

Security Groups vs. NACLs? SGs: instance-level, stateful, allow-only. NACLs: subnet-level, stateless, allow+deny. Use both for defense in depth.

VPC Peering vs. Transit Gateway? Peering: point-to-point, non-transitive, good for few VPCs. Transit Gateway: hub-and-spoke, transitive routing, scales to thousands of VPCs.

VPC Endpoints? Gateway endpoints for S3/DynamoDB (free, route-table targets, in-region only). Interface endpoints for other services (ENI-based, paid, cross-VPC and on-prem via PrivateLink).

VPN vs. Direct Connect? VPN: encrypted IPSec over internet, quick setup, up to ~5 Gbps. Direct Connect: dedicated private link (1–100 Gbps), lower latency, consistent performance.

Troubleshooting tips? Check route tables, SG rules, and NACLs. Verify IGW/NAT routes. Use VPC Flow Logs and Reachability Analyzer. Confirm no overlapping CIDRs.

Advanced Interview Questions (Experienced Level)

You have 3 VPCs (A, B, C) all peered with each other. VPC A also has a VPN to on-prem. Can VPC B reach on-prem through VPC A? No. VPC peering is non-transitive. Even though B is peered with A, it cannot use A’s VPN connection to reach on-prem. You’d need to either establish a direct VPN from B to on-prem, or attach all VPCs to a Transit Gateway and connect the VPN there — TGW supports transitive routing and can propagate on-prem routes to all attached VPCs.

What happens when two VPCs with overlapping CIDRs need to communicate? VPC peering and Transit Gateway both require non-overlapping CIDRs — you simply cannot peer them directly. Your options are: (1) re-IP one VPC (costly but clean), (2) use a NAT-based proxy layer where an intermediary VPC with non-overlapping CIDRs translates addresses, or (3) use AWS PrivateLink to expose specific services without needing full network-level routing between the VPCs.

How would you design VPC networking for a multi-account AWS Organization (100+ accounts)? Use AWS Transit Gateway shared via AWS Resource Access Manager (RAM) across accounts. Each account’s VPC attaches to the shared TGW. Centralize egress through a dedicated “egress VPC” with NAT Gateways and optionally a firewall (AWS Network Firewall or third-party). Use a “shared services VPC” for common tools (DNS, monitoring, AD). Manage routing with TGW route tables — segment environments (prod/dev/staging) into separate route domains so they can’t talk to each other by default.

What is the difference between a Security Group referencing another Security Group vs. referencing a CIDR? When you reference another SG in a rule (instead of an IP CIDR), AWS dynamically resolves all instances associated with that SG as allowed sources/destinations. This is more flexible and operationally cleaner — you don’t need to track or update IPs. For example, allowing the ALB’s SG in the app-tier SG means any new ALB instance is automatically permitted. CIDR-based rules are static and require manual updates when IPs change. SG references also work cross-account (with account ID prefix).

How does AWS PrivateLink work, and when would you use it over VPC peering? PrivateLink exposes a specific service (backed by an NLB) from a provider VPC via an interface endpoint in the consumer VPC. Traffic never leaves the AWS network, and the consumer only gains access to that one service — not the entire VPC. Use PrivateLink when: (1) you need to expose a service to hundreds of VPCs or external customers without full network access, (2) VPCs have overlapping CIDRs (PrivateLink doesn’t require routing between the two), or (3) you want service-level isolation rather than network-level connectivity.

A private EC2 instance can’t reach the internet via NAT Gateway. How do you troubleshoot? Work through each layer systematically:

• Route table: Does the private subnet’s route table have a 0.0.0.0/0 route pointing to the NAT Gateway?
• NAT Gateway state: Is it in “Available” state? Is it in a public subnet (NAT GW must itself be in a public subnet)?
• NAT Gateway’s subnet: Does the public subnet’s route table have 0.0.0.0/0 → IGW?
• Elastic IP: Does the NAT Gateway have an EIP attached?
• Security Group: Does the instance’s SG allow outbound traffic on the required port?
• NACL: Do the NACLs on both the private and public subnets allow the outbound traffic and the return ephemeral ports (1024–65535)?
• VPC Flow Logs: Check whether traffic is being accepted or rejected at the ENI level.

What are VPC Flow Logs and what are their limitations? VPC Flow Logs capture metadata about IP traffic flowing through ENIs, subnets, or an entire VPC — including source/dest IP, port, protocol, packet count, and whether traffic was accepted or rejected. They’re invaluable for security audits and troubleshooting. Key limitations: they don’t capture actual packet payload (only metadata), they don’t log traffic to/from the instance metadata service (169.254.169.254), DNS queries to Route 53 Resolver, or DHCP traffic. There's also a delay — logs are delivered to CloudWatch or S3 with a few minutes of latency, so they're not suitable for real-time alerting.

How does DNS resolution work inside a VPC, and how would you handle DNS for a hybrid (on-prem + AWS) environment? AWS provides a VPC DNS resolver at the base of the VPC CIDR + 2 (e.g. 10.0.0.2 for a 10.0.0.0/16 VPC). It resolves AWS-internal hostnames and forwards public DNS. For hybrid environments, use Route 53 Resolver: create an inbound endpoint (to allow on-prem to query AWS DNS) and an outbound endpoint with forwarding rules (to forward on-prem domain queries from AWS to your on-prem DNS servers). This gives you bidirectional DNS resolution without maintaining custom DNS servers.

What is the difference between an ENI, ENA, and EFA? An ENI (Elastic Network Interface) is a virtual network card you attach to an EC2 instance — it holds IPs, SGs, and MAC addresses, and can be moved between instances. ENA (Elastic Network Adapter) is a high-performance network driver that enables enhanced networking on supported instance types, offering higher throughput and lower latency than the default driver. EFA (Elastic Fabric Adapter) is a specialized network interface for HPC (High Performance Computing) workloads — it bypasses the OS kernel using OS-bypass technology to deliver ultra-low latency and high throughput needed for tightly coupled parallel applications like MPI workloads.

Can you attach multiple Internet Gateways to a single VPC? No. Each VPC can have at most one Internet Gateway attached at a time. If you need to separate internet traffic for different workloads, the correct approach is to use separate VPCs (each with its own IGW) and connect them via Transit Gateway or peering, or to use an Egress-Only Internet Gateway (for IPv6 outbound-only) alongside the main IGW. Trying to route around this with NAT or proxies is an anti-pattern.