VPC & Networking Deep Dive

Follow the packet, then explain the bill

A private application cannot download an update. Its security group allows outbound traffic, so why does the connection fail? A route, address, return-path rule, DNS answer or permission can still be missing. Troubleshooting becomes easier when you trace one actual request rather than opening every firewall rule.

This lesson develops the VPC concepts from the foundation lessons into an IPv4 network plan, a packet trace, endpoint choices and a cost calculation. You will also recognize configuration commands and interpret flow logs. AWS details were checked 14 September 2026. Examples are architecture and configuration exercises, not a complete production deployment or a certification syllabus.

1. Plan address space at the right level

A VPC is a logically isolated virtual network in one Region. Its resources can occupy subnets in several Availability Zones; each subnet belongs to exactly one AZ. The AZs themselves are shared AWS infrastructure, not facilities owned by your VPC.

Choose non-overlapping address ranges for networks that must connect. RFC 1918 private ranges are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16; select appropriate smaller blocks from them. A /16 VPC and /24 subnets are useful teaching sizes, not universal requirements. Default VPCs can be absent or deleted; inspect the actual account. VPC dedicated tenancy concerns eligible EC2 instance placement, not dedicated physical network equipment for the whole VPC. VPC concepts, VPC address ranges

For an IPv4 CIDR with prefix length p, the number of addresses is 2^(32-p). In an ordinary AWS IPv4 subnet, the first four addresses and the last address are reserved. The following assumes ordinary private addressing, not BYOIP:

Do not subtract five once from a whole VPC and call the result its usable capacity: reservations apply per subnet, and services also consume addresses. A fully partitioned /16 containing 256 ordinary /24 subnets would have 256 × 251 = 64,256 assignable addresses before service usage. Actual subnet quotas and a sensible growth plan still matter. Subnet sizing and BYOIP exception

For 10.0.1.0/24, .0, .1, .2, .3 and .255 are reserved. .255 is reserved even though VPC does not support broadcast. The VPC resolver's IPv4 address is the primary VPC CIDR base plus two—10.0.0.2 for this VPC. Reserving 10.0.1.2 in the subnet does not mean the resolver lives there. The resolver is also available at 169.254.169.253. Amazon DNS server

This AWS CLI fragment creates only the VPC. It requires an authenticated caller, an explicit Region and permission to create it; it does not create subnets or internet access:

aws ec2 create-vpc --region us-east-1 \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=network-lab}]'

2. A route is not a permission or an IP address

Each subnet uses one route table, explicitly associated or implicitly through the VPC's main table. One route table can serve multiple subnets. Routes select a next hop for a destination; they do not assign a public address or grant access through security groups, NACLs or IAM.

A private subnet is not necessarily an isolated subnet: it can have controlled outbound connectivity. A public subnet does not make every instance publicly reachable. An ordinary instance needs a public IPv4 address or Elastic IP for direct IPv4 internet access, plus suitable routing and network rules. Traffic through a public load balancer is a different path. IPv6 uses separate addresses and routes; 0.0.0.0/0 does not cover it. Route tables, Internet Gateways

An Internet Gateway attaches to the VPC, not to a subnet; at most one can be attached to a VPC at a time. It provides a managed, redundant internet gateway function. That does not remove instance/network throughput limits or guarantee application availability.

For an existing VPC, available IGW and intended public route table in us-east-1, read these commands using real values in $LAB_VPC_ID, $LAB_IGW_ID and $LAB_PUBLIC_RT_ID. Assume that default route does not already exist:

aws ec2 attach-internet-gateway --region us-east-1 \
  --internet-gateway-id "$LAB_IGW_ID" --vpc-id "$LAB_VPC_ID"
aws ec2 create-route --region us-east-1 \
  --route-table-id "$LAB_PUBLIC_RT_ID" \
  --destination-cidr-block 0.0.0.0/0 --gateway-id "$LAB_IGW_ID"

Choose the matching route

Routes use longest-prefix matching, with additional rules for equal destinations and different route types. For a simple example, assume these active, supported routes and their connections already exist:

Destination     Target
10.0.0.0/16     local
10.20.0.0/16    tgw-example
10.20.4.0/24    pcx-example
0.0.0.0/0      nat-example

10.20.4.25 matches /24, /16 and /0; /24 wins. 10.20.8.25 uses the /16. Target names here are diagram labels, not real IDs. A selected route can still fail if the peer, target or return route is wrong. AWS imposes special rules on more-specific routes within the VPC's own local range; do not assume any destination/target combination is accepted. Local routes have supported target-replacement behavior for middlebox routing; they are not ordinary removable internet routes. Route priority, route-table options

3. Trace private IPv4 internet egress

For a zonal public NAT gateway, the outbound path is:

Private app → private subnet's route → NAT in a public subnet
            → public subnet's IGW route → Internet Gateway → internet service

Return packets for the app's connection follow the translation state back. A public NAT gateway does not provide inbound port forwarding for unsolicited internet connections. The zonal public NAT uses an Elastic IP and a public subnet with an IGW route; creating it does not automatically add the private subnet's default route.

Distinguish the variants. A private NAT gateway serves private routing use cases, not internet egress through an IGW. A regional NAT gateway spans AZs and does not require a hosting public subnet. The following example deliberately selects the zonal public design. NAT gateway types, regional NAT

With an existing public subnet, allocated Elastic IP and private route table, use their real IDs in the variables. The public subnet already has its IGW path, and the private subnet is associated with the intended private table:

LAB_NAT_ID=$(aws ec2 create-nat-gateway --region us-east-1 \
  --availability-mode zonal --connectivity-type public \
  --subnet-id "$LAB_PUBLIC_SUBNET_ID" --allocation-id "$LAB_EIP_ALLOCATION_ID" \
  --query 'NatGateway.NatGatewayId' --output text)
aws ec2 wait nat-gateway-available --region us-east-1 \
  --nat-gateway-ids "$LAB_NAT_ID"
aws ec2 create-route --region us-east-1 \
  --route-table-id "$LAB_PRIVATE_RT_ID" \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id "$LAB_NAT_ID"

The commands require permission and a current CLI supporting the shown parameters. They create billable resources and are not idempotent: do not repeatedly run creation commands after a later step fails. Check existing resources first. CreateNatGateway

A zonal NAT supports 5 Gbps and scales up to 100 Gbps under the current documented limits; packet rate and connections per destination also matter. It cannot have a security group attached. A NAT instance is an EC2 instance you configure and maintain, including forwarding, source/destination-check configuration, patching, scaling and recovery. It is not categorically restricted to development use; assess the operational and cost tradeoffs. Zonal NAT characteristics

If private subnets in AZ A and AZ B both depend on a zonal NAT in A, losing A can break B's internet egress. A design with a zonal NAT in each AZ normally sends each private subnet to its local NAT. A regional NAT is another design option. Neither choice makes all application dependencies fault tolerant.

4. Check the two network-rule layers in both directions

Security groups apply to associated network interfaces/resources. Their rules allow traffic; there are no Deny rules or ordered first-match priorities. Allowed connections are tracked so response traffic is allowed. Rules across attached groups combine; one restrictive group does not cancel an Allow in another group.

A newly created custom security group starts without inbound rules and normally with an allow-all outbound rule. The VPC's default security group differs: its initial inbound rule allows traffic from resources associated with that same group. Existing groups can have changed rules. Security group rules, default group

For a same-VPC application-to-database path using private addresses, this ingress fragment permits TCP destination port 3306 from resources associated with the source group. The variables identify existing database and application groups:

aws ec2 authorize-security-group-ingress --region us-east-1 \
  --group-id "$LAB_DATABASE_SG_ID" \
  --protocol tcp --port 3306 --source-group "$LAB_APP_SG_ID"

3306 is the conventional MySQL port; the rule permits a port, not a database login. It does not copy rules from the source group, attach either group to resources, or override another group's access. The app's egress and other path controls still need to permit the request. Group references have topology-specific restrictions; the simple same-VPC private-address example avoids those additional cases.

Network ACLs (NACLs) operate at subnet boundaries. Each subnet uses one NACL, and a NACL can serve multiple subnets. Rules can Allow or Deny; the lowest-numbered matching rule wins, separately for inbound and outbound. NACLs are stateless, so the return path needs suitable rules. A default NACL initially allows traffic; a new custom NACL initially denies it. Network ACLs

Trace destination ports, not just “open HTTPS”

Suppose an app at 10.0.2.10 opens TCP port 51000 to a server on port 443. Before considering any NAT translation, its app-subnet boundary sees:

Request: 10.0.2.10:51000 → server:443
Reply:   server:443 → 10.0.2.10:51000

The app subnet's outbound NACL needs to allow destination port 443 toward the server. Its inbound NACL needs to allow destination port 51000 from that server for this connection. For a web server receiving client requests, the directions are reversed: inbound service port, outbound client ephemeral port. NAT-subnet boundaries must also permit their corresponding paths.

Ephemeral-port ranges depend on the client operating system and intermediaries. 1024–65535 is a broad range sometimes needed, not a requirement to open every high port in both directions on every subnet. Determine the actual paths and scope the rules. Ephemeral ports

5. Use endpoints for the service and path you need

Two common endpoint types have different mechanisms:

This is not an exhaustive catalog of all endpoint types. An endpoint policy restricts requests through the endpoint; it does not replace the caller's identity permissions or the service's resource policies. Private connectivity does not automatically grant access. Gateway endpoints, interface endpoints

For S3 in us-east-1, select the gateway type explicitly. The VPC and route table variables contain existing IDs in that Region:

aws ec2 create-vpc-endpoint --region us-east-1 \
  --vpc-id "$LAB_VPC_ID" --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids "$LAB_PRIVATE_RT_ID"

The endpoint adds its service-prefix-list route to the chosen table. For traffic matching those same-Region S3 ranges, that route is more specific than the NAT default route. Different Regions, DNS configurations and address families can change the path; do not conclude “all S3 traffic always uses this endpoint.” Gateway endpoints are not a general endpoint path for on-premises clients or a peered VPC. S3 gateway behavior

For an interface endpoint, choose supported subnets and security groups and plan DNS. Private DNS for supported AWS service names requires the relevant VPC DNS support/hostname settings and endpoint configuration. Routing works on IP addresses; the chosen DNS answer determines which address is routed. Private DNS

Diagnose it: a policy permits only s3:GetObject on incoming/*. Running aws s3 ls against the bucket tests listing, which requires s3:ListBucket. A denial does not by itself disprove the endpoint route. Test the intended action/key and check both network and policy evidence.

Count only costs that actually change

Use these illustrative rates, not a quote: one NAT at $0.045/hour, 730 hours/month, and $0.045 per GB processed. Assume 1,000 GB of counted NAT processing, all attributable to same-Region EC2↔S3 traffic. Do not add a generic internet data-transfer rate to this same-Region service path. AWS's pricing example distinguishes those charges. VPC pricing

from decimal import Decimal
hourly = Decimal('0.045') * 730
processing = Decimal('0.045') * 1000
nat_total = hourly + processing
print(hourly, processing, nat_total)

The outputs are $32.85, $45.00, and $77.85 for these NAT line items. Moving the matching traffic to an S3 gateway endpoint avoids the $45.00 processing charge, or $540.00 over 12 identical months. If the NAT remains for other traffic, its hourly charge remains. If it can safely be removed altogether, the modeled NAT saving becomes $77.85/month, or $934.20/year. Public IPv4 charges and other bill items require separate accounting.

S3 storage, requests, retrievals, replication and other services may still cost money. “No endpoint charge” does not mean “a free application,” and an endpoint does not prove better latency without measurement.

6. Connect networks without assuming transit

VPC peering connects a pair of VPCs, including supported cross-account and cross-Region cases. Use non-overlapping CIDRs and configure both sides' routes and network controls. A connection being active does not install every required route.

A ↔ B     B ↔ C
These peering links alone do not provide an A ↔ C path through B.

For three VPCs requiring full pairwise communication, direct peering needs three connections: A↔B, A↔C and B↔C. In general, full mesh requires n × (n − 1) / 2 pairs: ten VPCs require 45. A Transit Gateway can provide hub routing with appropriate attachments and route tables; it has its own quotas, support and charges. It does not make overlapping address plans harmless. Peering limits, Transit Gateway

For Site-to-Site VPN, distinguish the customer gateway resource representing the customer device from the device itself. A virtual private gateway can terminate VPN connectivity for a VPC; a Transit Gateway is another supported AWS-side design. A VPN connection supplies two IPsec tunnels. Configure and test both, plus routing/BGP or static routes, return routes and the customer-side configuration. Two AWS tunnels do not make one customer router redundant. Direct Connect supplies dedicated connectivity, not automatic end-to-end encryption. VPN concepts, Direct Connect encryption

7. Use logs as evidence, not as a packet capture

VPC Flow Logs record supported IP traffic metadata for selected interfaces, subnets or VPCs. They do not capture application payloads or every possible flow, and delivery/aggregation takes time. REJECT is useful evidence, but a default record does not name the precise SG or NACL rule that caused it. ACCEPT is not proof of a successful TLS handshake, IAM authorization or database query. Flow Log limitations

To publish to CloudWatch Logs, assume $LAB_FLOWLOG_ROLE_ARN is an existing same-account role with a trust policy for vpc-flow-logs.amazonaws.com, appropriate source-account/source-ARN protections, and sufficient scoped log-delivery permissions. The caller needs iam:PassRole for that role and the applicable EC2 permission. The log group already exists in us-east-1:

aws ec2 create-flow-logs --region us-east-1 \
  --resource-type VPC --resource-ids "$LAB_VPC_ID" \
  --traffic-type ALL --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --deliver-logs-permission-arn "$LAB_FLOWLOG_ROLE_ARN"

The delivery role is not made correct merely by attaching CloudWatchLogsFullAccess. Use the documented trust relationship and required operations, scoping resources where supported. Check the API response for failed resource entries and inspect log-delivery status after creation. Flow Log role, creation prerequisites

A default-format example has 14 fields:

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-0123456789abcdef0 10.0.2.10 10.0.3.20 51000 3306 6 20 4000 1700000000 1700000060 REJECT OK

This record concerns TCP (6) to destination port 3306, with 20 packets and 4,000 bytes over the displayed 60-second interval. OK is the logging status; it does not cancel REJECT. Address fields contain IP addresses, not amazonaws.com hostnames. Some additional fields can help identify paths/services if you select them; the default record is not a DNS trace. Flow Log fields

In CloudWatch Logs Insights, when the default VPC Flow Log fields are discovered, count rejected records by destination port:

fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| stats count(*) as rejectedRecords by dstPort
| sort rejectedRecords desc

The result counts log records, not necessarily connections or packets. Verify your log format/field discovery before using the query. Logs Insights examples

8. Review a two-AZ plan before deploying it

For the 10.0.0.0/16 example, reserve these six non-overlapping subnets:

Allow viewer HTTPS to the entry tier, only the intended entry-to-app port, and only the app-to-database port. A database subnet group spanning AZs is not itself a running resilient database: configure the actual database's availability and recovery features. Verify capacity, health checks, sessions, backup/recovery and remaining dependencies. The earlier command fragments do not create this entire six-subnet plan.

For a failed request, work in order: resolved destination → source address → route and next-hop health → SG rules → NACL directions and ports → return route → listener/TLS → service authorization. Use Flow Logs and supported Reachability Analyzer paths as evidence; configuration analysis does not send an application transaction. Reachability Analyzer

If you run a disposable lab later, record created IDs and charges, and remove unused NAT gateways, Elastic IPs, interfaces/endpoints and log resources after testing. Preserve resources other workloads depend on. A useful network review explains both what works and what would fail when one component disappears.