AWS VPC: Subnets, Routing, Security Groups, and NAT

Plan Address Space and Subnets

An Amazon VPC is a regional network boundary containing IP ranges, subnets, routes, gateways, endpoints, and traffic controls.

A subnet belongs to one Availability Zone. Its route table determines where packets can go; the words public and private describe routing behavior rather than a special subnet type.

Security groups filter traffic at network interfaces and keep connection state. Network ACLs filter at the subnet boundary and require explicit rules for both directions.

Choose a CIDR range that leaves room for growth and does not overlap networks that may later connect through VPN, Direct Connect, Transit Gateway, or VPC peering.

Create subnets across multiple Availability Zones.
Separate ingress, application, and data tiers when routing needs differ.
Document reserved ranges before teams allocate them independently.

Route Internet and AWS Service Traffic

A public IPv4 workload needs a route to an internet gateway and a public address. Private IPv4 workloads can use a NAT gateway for outbound internet access, while VPC endpoints keep supported AWS service traffic off that path.

Place a NAT gateway in each active Availability Zone when cross-zone failure matters.
Use gateway endpoints for S3 and DynamoDB where appropriate.
Inspect route-table association before changing firewall rules.

Apply Network Controls

Reference security groups to express service-to-service access, such as allowing an application group to reach a database group. Use NACLs for coarse subnet controls rather than duplicating every security-group rule.

Avoid broad inbound rules and unnecessary outbound access.
Account for ephemeral ports when editing stateless NACLs.
Keep load balancer, application, and database security groups distinct.

Troubleshoot the Packet Path

Work from DNS resolution through source route, security group, NACL, destination route, and application listener. Reachability Analyzer and VPC Flow Logs help distinguish network rejection from application failure.

Confirm both forward and return routes.
Check that the service listens on the expected address and port.
Review NAT gateway processing and cross-AZ transfer costs.

IPv4 and IPv6 Address Plan

Choose VPC and subnet address ranges before connectivity is urgent. An IPv4 CIDR must leave room for application tiers, Availability Zones, managed endpoints, growth, and temporary migration capacity without overlapping networks that may be connected later. AWS reserves addresses in each subnet, so a subnet provides fewer usable addresses than the raw CIDR size suggests.

IPv6 uses globally unique addresses and changes the egress design: an egress-only internet gateway can permit outbound IPv6 connections without allowing unsolicited inbound connections. Security groups and network ACLs still control traffic. Dual-stack applications must test DNS, listener, policy, logging, and dependency behavior for both protocols rather than assuming IPv6 follows the IPv4 NAT path.

Record allocation ownership in an address management process. VPC IP Address Manager can help plan and monitor address use across accounts and Regions, but the essential contract is organizational: no team allocates a connected range without checking the shared plan, and every subnet has an owner and intended tier.

Reserve address space for growth and migration.
Account for AWS-reserved subnet addresses.
Test dual-stack paths independently.
Detect overlapping or abandoned allocations early.

Subnet and Route Semantics

A subnet exists in one Availability Zone and is associated with one route table at a time. Every route table includes a local route for VPC communication; more-specific routes determine traffic toward gateways, appliances, peering, or transit connections. Longest-prefix matching decides the route before security controls decide whether the traffic is allowed.

Public and private are architectural descriptions. A public IPv4 path requires a route to an internet gateway, a public address on the resource or entry point, and permissive security controls. A private subnet omits a direct inbound internet path even when its workloads can reach the internet through NAT. Do not infer exposure from a subnet name.

Spread each required tier across the Availability Zones used by the workload and associate route tables deliberately. A database subnet group, load balancer, or container service may require subnets in several zones. Verify the actual associations after infrastructure deployment because an unattached custom route table changes nothing.

Read the most specific matching route first.
Verify route-table associations, not only route definitions.
Separate direct inbound reachability from outbound access.
Map every subnet to one tier and Availability Zone.

Internet, NAT, and Service Endpoints

An internet gateway connects a VPC route to the public internet but does not translate private IPv4 addresses. A NAT gateway gives private IPv4 workloads outbound connectivity while preventing unsolicited inbound initiation through that path. For zone-resilient designs, place NAT capacity in each active Availability Zone and route private subnets to the same-zone gateway to avoid one-zone dependency and unnecessary cross-zone transfer.

NAT gateways have hourly, processing, and transfer implications and can become an expensive default for service traffic. Gateway endpoints provide private route-table access to S3 and DynamoDB, while interface endpoints create private network interfaces for supported services through AWS PrivateLink. Endpoint policies and private DNS must be reviewed alongside IAM and resource policies.

Outbound access is a security boundary. Decide which destinations workloads require, how DNS is resolved, whether proxies or network firewalls enforce policy, and how exfiltration is detected. A route that works is not automatically a route the workload should have.

Avoid a single-zone NAT dependency in multi-zone workloads.
Use endpoints where they improve privacy, resilience, or cost.
Review endpoint policies as authorization controls.
Measure NAT processing and cross-zone traffic.

Security Groups and Network ACLs

Security groups are stateful controls attached to network interfaces. An allowed connection automatically permits response traffic through the stateful flow. Express application relationships by referencing security groups where supported, such as allowing a database port from the application group instead of maintaining changing instance addresses.

Network ACLs are stateless ordered rules at a subnet boundary. Both directions and ephemeral response ports must be allowed, and the lowest numbered matching rule wins. Use them for coarse subnet guardrails or explicit deny requirements, not as a duplicate copy of every security-group rule. Default and custom NACL behavior differ, so inspect the actual association.

Neither control proves that an application listens, a route exists, DNS resolves, or a host firewall permits traffic. Keep narrow inbound and outbound rules, remove stale references, and review IPv4 and IPv6 sources separately. Never solve an unexplained timeout by opening all ports to all addresses.

Model security-group rules as service relationships.
Include return paths when changing stateless ACLs.
Review both IPv4 and IPv6 exposure.
Remove temporary diagnostic rules promptly.

VPC and Hybrid Connectivity

VPC peering provides private routing between two VPCs but is not transitive. Transit Gateway provides a hub for larger networks and route segmentation. PrivateLink exposes a service through private endpoints without merging the participants full network routes. Choose the relationship required rather than connecting whole address spaces by default.

Site-to-Site VPN creates encrypted connectivity over the internet, while Direct Connect provides dedicated connectivity and normally needs resilient locations, devices, and routing. Hybrid DNS must resolve private names in the correct direction through Route 53 Resolver endpoints and rules. Network connectivity does not grant application or IAM authorization.

Define route ownership, BGP behavior, failure paths, bandwidth, inspection, and cost before connecting production networks. Prevent accidental transitive access with segmented route tables and test one-site or one-tunnel failure. An architecture diagram should show return paths and overlapping CIDR constraints, not only a line between clouds.

Use peering for deliberate non-transitive relationships.
Use PrivateLink when service access is narrower than network access.
Design hybrid DNS with the routing plan.
Test redundant tunnels and route withdrawal.

Packet Path Diagnosis

Start with the exact source address, destination name and address, protocol, port, timestamp, and expected direction. Confirm DNS, source route, gateway or appliance, source security group, network ACLs in both directions, destination security group, destination route, host firewall, and listening process. This ordered path prevents random rule changes.

Reachability Analyzer can reason about configuration for supported paths; VPC Flow Logs record accepted or rejected flow metadata at selected interfaces, subnets, or VPCs. Neither replaces an application log or packet-level test. A flow accepted by network controls can still time out because the service is unhealthy, TLS fails, or the return application response is delayed.

Check route propagation, asymmetric routing through appliances, NAT port pressure, DNS resolver rules, endpoint private DNS, and cross-zone behavior for harder cases. Preserve the failing five-tuple and request ID, make one change, and revert diagnostic access after confirmation. Add the proven failure mode to a connectivity test.

Capture source, destination, protocol, port, and time.
Inspect forward and return paths in order.
Separate network acceptance from application health.
Turn resolved incidents into path tests.

VPC Routing Examples

AWS public and private subnet routing example

A useful VPC lesson should show that subnet design is really route-table design. Public and private behavior comes from routes, not subnet names.

AWS public and private subnet routing example

aws ec2 create-subnet --vpc-id vpc-123456 --cidr-block 10.20.1.0/24 --availability-zone us-east-1a
aws ec2 create-subnet --vpc-id vpc-123456 --cidr-block 10.20.11.0/24 --availability-zone us-east-1a
aws ec2 create-route-table --vpc-id vpc-123456
aws ec2 create-route --route-table-id rtb-123456 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-123456

Public access is created by an internet route plus public IP behavior.
Private subnets usually reach the internet through a NAT path, not directly.

Diagnose a Private Subnet Timeout

A private application instance can resolve an API hostname but every HTTPS connection times out.

Diagnose a Private Subnet Timeout

Constraints: The subnet has no public IPs; traffic may use a NAT gateway or an interface endpoint; security groups are stateful.
Decision: Trace DNS, subnet route, endpoint or NAT route, security-group egress, return path, and network ACLs in that order.
Verification: Reachability Analyzer identifies a complete path and a timed curl returns the expected TLS response.
Failure test: Remove the endpoint security-group ingress rule and confirm the same test fails at the predicted hop.

Output

Expected evidence: Reachability Analyzer identifies a complete path and a timed curl returns the expected TLS response.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on