Cloud Networking: VPC Design & Connectivity

Design enterprise cloud networking. Covers VPC architecture, subnet strategies, transit gateways, hybrid connectivity, DNS, security groups, network segmentation, and multi-account networking.

This reference explains how to design and connect virtual private clouds (VPCs) in cloud environments. It covers network topology, routing, inter-VPC communication, and connectivity patterns. This matters when building scalable, secure, multi-region applications that require predictable network behavior and controlled traffic flow.

Understanding VPC Fundamentals

A VPC is a logically isolated network within a cloud environment. All compute resources must reside within a VPC to communicate over the network. Each VPC has a CIDR block range, typically /16 or /24. The smallest supported subnet is /28, which provides 16 IP addresses.

VPCs have no default route to the internet unless explicitly configured. By default, all subnets within a VPC are private and cannot directly access external services without an internet gateway or NAT device.

Creating a Basic VPC Structure

To create a VPC with public and private subnets:

# Create VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16

# Create public subnet
aws ec2 create-subnet --vpc-id vpc-12345678 --cidr-block 10.0.1.0/24 --availability-zone us-east-1a

# Create private subnet
aws ec2 create-subnet --vpc-id vpc-12345678 --cidr-block 10.0.2.0/24 --availability-zone us-east-1a

# Create internet gateway
aws ec2 create-internet-gateway

# Attach IGW to VPC
aws ec2 attach-internet-gateway --internet-gateway-id igw-12345678 --vpc-id vpc-12345678

The VPC's main route table must have a route to the internet gateway for public subnets to reach external services. The private subnet's route table should not contain a default route, ensuring traffic stays within the VPC.

Routing Between VPCs

VPC peering allows direct communication between VPCs in the same or different accounts. To establish peering:

# Create peering connection
aws ec2 create-vpc-peering-connection --vpc-id vpc-12345678 --peer-vpc-id vpc-87654321

# Accept peering connection (in peer account)
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-12345678

Peering requires overlapping CIDR blocks or non-overlapping subnets. Routes must be manually added to both VPC route tables:

# Add route in source VPC
aws ec2 create-route --route-table-id rtb-12345678 --destination-cidr-block 10.10.0.0/16 --vpc-peering-connection-id pcx-12345678

# Add route in peer VPC
aws ec2 create-route --route-table-id rtb-87654321 --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id pcx-12345678

The peering connection is not automatically bidirectional. Routes must be added in both directions for full connectivity.

Connecting VPCs to On-Premises Networks

Site-to-site VPN connections use IPsec tunnels between VPCs and on-premises routers. The setup requires:

  1. Creating a customer gateway with public IP address
  2. Creating a virtual private gateway in the VPC
  3. Establishing a VPN connection between these gateways
# Create customer gateway
aws ec2 create-customer-gateway --type ipsec.1 --public-ip 203.0.113.10 --bgp-asn 65000

# Create virtual private gateway
aws ec2 create-vpn-gateway

# Attach VPN gateway to VPC
aws ec2 attach-vpn-gateway --vpn-gateway-id vpngw-12345678 --vpc-id vpc-12345678

# Create VPN connection
aws ec2 create-vpn-connection --type ipsec.1 --vpn-gateway-id vpngw-12345678 --customer-gateway-id cgw-12345678

The VPN connection must be manually configured on the on-premises side with matching encryption parameters, including pre-shared key, encryption algorithm, and authentication method.

Using Transit Gateways for Complex Topologies

Transit gateways centralize routing for multiple VPCs. They can connect up to 500 VPCs and support overlapping CIDR blocks through route propagation.

To create a transit gateway:

# Create transit gateway
aws ec2 create-transit-gateway --description "Main Transit Gateway"

# Attach VPC to transit gateway
aws ec2 attach-transit-gateway-vpc --transit-gateway-id tgw-12345678 --vpc-id vpc-12345678

# Create route table for transit gateway
aws ec2 create-transit-gateway-route-table --transit-gateway-id tgw-12345678

# Associate VPC with route table
aws ec2 associate-transit-gateway-route-table --transit-gateway-route-table-id tgw-rtb-12345678 --transit-gateway-attachment-id tgw-attach-12345678

Transit gateways do not automatically propagate routes. Routes must be manually added to the transit gateway route table for inter-VPC communication.

Managing Security Groups and Network ACLs

Security groups act as virtual firewalls for EC2 instances. They are stateful, meaning inbound rules automatically allow return traffic.

# Create security group
aws ec2 create-security-group --group-name web-sg --description "Web server security group" --vpc-id vpc-12345678

# Add inbound rule for HTTP
aws ec2 authorize-security-group-ingress --group-id sg-12345678 --protocol tcp --port 80 --cidr 0.0.0.0/0

# Add outbound rule for DNS
aws ec2 authorize-security-group-egress --group-id sg-12345678 --protocol udp --port 53 --cidr 0.0.0.0/0

Network ACLs are stateless and apply at the subnet level. They must be explicitly configured for both inbound and outbound traffic.

Setting Up Private Subnets with NAT Gateways

Private subnets cannot access the internet without a NAT gateway:

# Create NAT gateway
aws ec2 create-nat-gateway --subnet-id subnet-12345678 --allocation-id eipalloc-12345678

# Add route to NAT gateway in private subnet's route table
aws ec2 create-route --route-table-id rtb-12345678 --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-12345678

NAT gateways are not automatically created with subnets. Without a NAT gateway, private instances cannot reach public endpoints.

Troubleshooting Common VPC Issues

Route Table Confusion

Route tables can be associated with multiple subnets. Misconfigured routes cause traffic to drop silently. When a packet is sent to an IP address, check:

  1. Subnet route table contains correct route
  2. Route table has no conflicting default routes
  3. VPC peering or transit gateway routes are properly configured

CIDR Block Overlaps

Overlapping CIDR blocks in VPCs cause routing confusion. Traffic may reach the wrong destination due to ambiguous route selection.

Internet Gateway Not Attached

Instances in public subnets cannot reach the internet without an internet gateway attached to the VPC and a default route in the public subnet's route table.

Inter-VPC Communication Patterns

Direct Peering

VPCs can communicate directly through peering connections. This requires manual route configuration in both VPCs.

Transit Gateway Routing

For complex topologies with many VPCs, transit gateways centralize routing. Routes are propagated and managed in the transit gateway's route table.

Shared Services VPC

A dedicated VPC hosts shared services (DNS, logging, monitoring). Other VPCs connect through peering or transit gateway to access these services.

Traffic Flow Considerations

All traffic within a VPC travels through virtual routers. Subnets are isolated by default unless explicitly connected through route tables.

Private subnets must have NAT gateways for outbound internet access. Public subnets can directly reach the internet via internet gateways.

VPC peering connections do not support automatic route propagation. All routes must be manually configured in both VPCs' route tables.

Multi-AZ Considerations

Multi-AZ deployments require subnet placement across availability zones. Each AZ needs a subnet to ensure fault tolerance.

Subnets in different AZs cannot communicate directly through the same route table unless they are explicitly routed through transit gateways or peering connections.

Performance and Cost Implications

VPC routing is free, but internet traffic incurs costs. NAT gateways have hourly charges based on usage. Transit gateways charge per hour for each attachment and data transfer.

Private subnets with NAT gateways require careful planning to avoid over-provisioning. Each NAT gateway supports up to 10,000 concurrent connections.

Common Configuration Mistakes

Incorrect Route Table Association

Subnets may be associated with the wrong route table, causing connectivity issues.

Missing Default Routes

Public subnets without internet gateway routes cannot access external services.

Overlapping CIDR Blocks

VPCs with overlapping CIDR blocks cause routing conflicts and unpredictable traffic behavior.

Unconfigured Security Groups

Instances may have no security group rules, making them vulnerable to unauthorized access.

Misplaced Network ACLs

Network ACLs applied to subnets may not match expected traffic flow patterns.

Testing Connectivity

To verify VPC connectivity:

  1. Test basic ICMP between instances in same subnet
  2. Verify public IP addresses can reach internet
  3. Confirm private instances can access internet via NAT gateway
  4. Check that VPC peering routes are active
  5. Validate transit gateway route propagation works correctly

Monitoring and Alerting

Monitor VPC routing tables for unexpected changes. Monitor NAT gateway usage to prevent connection limits. Track internet gateway utilization for cost optimization.

VPC flow logs provide detailed traffic information for troubleshooting connectivity issues.

Backup and Recovery Planning

VPC configurations should be version-controlled. Route tables, security groups, and subnet placements must be documented. In case of failure, recreate VPCs with the same CIDR blocks to maintain IP address consistency.

The key to successful VPC design is understanding that all network traffic must follow defined routes. Without explicit routing configuration, packets will be dropped silently.

This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.