What a packet needs
When a connection times out, finding one correct route or one open security-group rule does not settle the question. The request needs a route to its destination, every relevant filter must permit it, and the reply needs its own path back. Address translation may also change the source or destination seen at each checkpoint.
The packet enters the VPC through an elastic network interface (ENI), the network interface attached to an EC2 instance or another resource. Its subnet supplies the address range, and the associated route table tells the VPC router which target should receive each destination. The route with the longest matching prefix normally wins. Selecting a gateway as that target does not itself rewrite the destination; translation happens only where the path provides it. AWS routing ↗
- 01Choose a pathDestination address → matching route → target
- 02Permit the flowSecurity groups, subnet ACLs and the host
- 03Return the replyReverse routes, connection state and return ACLs
Follow a packet
Choose a path, then use Next step or Play to follow the packet. Completed steps remain visible with the source and destination seen at that checkpoint. Try a failure changes one condition and shows where the same journey stops; changing the path or failure resets the trace.
Each trace shows logical checkpoints rather than physical routers or AWS’s internal processing order. It groups some routing and filtering checks and assumes that omitted checks allow the traffic. The TCP examples focus on one request and reply, so they leave out retransmissions and the rest of the handshake. Playback timing gives you time to read each step; it does not represent network latency. Reduced-motion mode uses manual stepping, and every complete trace remains readable without JavaScript.
Internet → public EC2
TCP connection to port 443. Public address 203.0.113.10 maps to EC2 10.0.1.5. The subnet has an IGW route. Example addresses are documentation-only.
- Client
- Internet gateway
- Subnet NACL
- EC2 security group
- EC2
Solid connectors show the logical path. Highlighted node = current step. Request and reply remain in the trace below.
- Request
Client
Stopped hereSource198.51.100.4:52140→Destination203.0.113.10:443The client chooses temporary source port 52140 and sends a TCP SYN to the public address.
- Request
Internet gateway
Stopped hereSource198.51.100.4:52140→Destination10.0.1.5:443The IGW translates the destination public IPv4 address to the private address. EC2 sees its private address.
- Request
Subnet NACL
Stopped hereSource198.51.100.4:52140→Destination10.0.1.5:443The inbound ACL must allow TCP destination port 443 from the client.
Inbound NACL denies TCP 443. Check the first matching rule, including lower-numbered denies.
- Request
EC2 security group
Stopped hereSource198.51.100.4:52140→Destination10.0.1.5:443The inbound SG allows this client to reach TCP 443.
No inbound SG allow rule matches this client and port. The connection cannot reach EC2.
- Request
EC2
Stopped hereSource198.51.100.4:52140→Destination10.0.1.5:443A listening application and host firewall accept the connection. The server prepares a SYN-ACK.
- Reply
EC2 security group
Stopped hereSource10.0.1.5:443→Destination198.51.100.4:52140This tracked reply is allowed by SG connection state, even without an outbound rule for 52140.
- Reply
Subnet NACL
Stopped hereSource10.0.1.5:443→Destination198.51.100.4:52140The stateless outbound ACL must separately allow destination port 52140.
The reply is dropped: outbound NACL rules do not allow client port 52140. Allow the appropriate client ephemeral range and destination.
- Reply
Internet gateway
Stopped hereSource203.0.113.10:443→Destination198.51.100.4:52140The subnet route sends the reply to the IGW, which maps the source private address back to the public address.
- Reply
Client
Stopped hereSource203.0.113.10:443→Destination198.51.100.4:52140The SYN-ACK reaches the client. The final TCP ACK and TLS exchange are omitted.
Private EC2 → internet
A zonal public NAT gateway lives in a public subnet. Its private address is 10.0.1.10 and its Elastic IP is represented by 203.0.113.20. Other SG and ACL rules allow this example.
- Private EC2
- Private route table
- NAT gateway
- Internet gateway
- API
Solid connectors show the logical path. Highlighted node = current step. Request and reply remain in the trace below.
- Request
Private EC2
Stopped hereSource10.0.2.15:48920→Destination198.51.100.80:443The instance has no public IPv4 address. Its SG allows outbound HTTPS and the private-subnet ACL allows the request.
- Request
Private route table
Stopped hereSource10.0.2.15:48920→Destination198.51.100.80:443The destination matches 0.0.0.0/0 → nat-gateway.
The private subnet has no matching route to the NAT gateway. Check its actual route-table association.
- Request
NAT gateway
Stopped hereSource10.0.1.10:62000→Destination198.51.100.80:443Source NAT maps the instance address and port to the NAT private address and an illustrative translated port, 62000.
- Request
Internet gateway
Stopped hereSource203.0.113.20:62000→Destination198.51.100.80:443The public subnet routes to the IGW. The IGW maps the NAT private address to its Elastic IP.
The NAT subnet lacks an IGW route. Reaching the NAT gateway alone does not provide internet access.
- Request
API
Stopped hereSource203.0.113.20:62000→Destination198.51.100.80:443The API sees the NAT Elastic IP as the client address.
- Reply
Internet gateway
Stopped hereSource198.51.100.80:443→Destination10.0.1.10:62000The reply to the Elastic IP is translated back to the NAT private address.
- Reply
NAT gateway
Stopped hereSource198.51.100.80:443→Destination10.0.2.15:48920The existing translation restores the original client destination and port. Public-subnet ACLs must permit both sides of the translation.
- Reply
Private EC2
Stopped hereSource198.51.100.80:443→Destination10.0.2.15:48920The private-subnet inbound ACL allows 48920; the SG admits the tracked reply.
The private-subnet inbound NACL blocks 48920. Outbound HTTPS permission alone does not admit the reply.
Private EC2 → S3 endpoint
An IPv4 S3 gateway endpoint in the same Region is associated with the instance subnet route table. S3-IP represents an address in the AWS-managed S3 prefix list.
- EC2
- Route table
- Gateway endpoint
- S3
Solid connectors show the logical path. Highlighted node = current step. Request and reply remain in the trace below.
- Request
EC2
Stopped hereSource10.0.2.15:39120→DestinationS3-IP:443DNS resolves an S3 service address. The SG and outbound ACL allow HTTPS to that address.
- Request
Route table
Stopped hereSource10.0.2.15:39120→DestinationS3-IP:443The matching S3 prefix-list route selects the gateway endpoint ahead of a default route.
This subnet route table has no S3 endpoint route. With no other egress route in this example, the request stops here.
- Request
Gateway endpoint
Stopped hereSource10.0.2.15:39120→DestinationS3-IP:443The request uses the gateway endpoint without NAT or an IGW. There is no interface endpoint ENI or endpoint SG.
- Request
S3
Stopped hereSource10.0.2.15:39120→DestinationS3-IP:443Endpoint, identity and bucket policies must authorize the operation. Network reachability alone grants no object access.
An applicable policy denies GetObject. This is an authorization failure, typically an HTTP error, rather than an SG/NACL packet drop.
- Reply
Gateway endpoint
Stopped hereSourceS3-IP:443→Destination10.0.2.15:39120The response travels back through the endpoint path.
- Reply
EC2
Stopped hereSourceS3-IP:443→Destination10.0.2.15:39120The ACL allows the client ephemeral destination port; SG state admits the response.
App VPC → database VPC
VPC A is 10.0.0.0/16; VPC B is 10.1.0.0/16. An accepted peering connection joins them. Source SG and both subnet ACLs allow the illustrated TCP flow.
- App
- Route A
- Peering
- Database
- Route B
Solid connectors show the logical path. Highlighted node = current step. Request and reply remain in the trace below.
- Request
App
Stopped hereSource10.0.1.5:51000→Destination10.1.2.10:5432The application connects directly to the database private address.
- Request
Route A
Stopped hereSource10.0.1.5:51000→Destination10.1.2.10:543210.1.0.0/16 → pcx selects the peer. The destination remains the database address.
VPC A has no route for the peer CIDR. An accepted peering connection does not install your subnet routes.
- Request
Peering
Stopped hereSource10.0.1.5:51000→Destination10.1.2.10:5432Peering forwards between the two VPCs without NAT. It does not make a third VPC reachable through this peer.
- Request
Database
Stopped hereSource10.0.1.5:51000→Destination10.1.2.10:5432The database SG allows 5432 from the app, and PostgreSQL is listening.
The database SG has no matching inbound allow rule for the application source.
- Reply
Route B
Stopped hereSource10.1.2.10:5432→Destination10.0.1.5:5100010.0.0.0/16 → pcx provides the reverse route; SG state does not create it.
VPC B is missing its route back to VPC A. Request delivery cannot compensate for a missing reverse route.
- Reply
Peering
Stopped hereSource10.1.2.10:5432→Destination10.0.1.5:51000The return packet crosses the same peering connection with private addresses unchanged.
- Reply
App
Stopped hereSource10.1.2.10:5432→Destination10.0.1.5:51000The app subnet ACL allows the reply and the app SG recognizes the connection.
Cross-Region transit gateways
VPC A in us-east-1 reaches VPC B in eu-west-1 through two peered transit gateways. All VPC attachment routes and network filters are configured. Packet size is within path MTU.
- VPC A
- TGW A
- TGW peering
- TGW B
- VPC B
Solid connectors show the logical path. Highlighted node = current step. Request and reply remain in the trace below.
- Request
VPC A
Stopped hereSource10.0.1.10:52000→Destination10.2.1.20:443The source subnet route for 10.2.0.0/16 targets TGW A.
- Request
TGW A
Stopped hereSource10.0.1.10:52000→Destination10.2.1.20:443The route table associated with the incoming VPC attachment selects a static route to the peering attachment.
The associated TGW route table has no static route to the peer for 10.2.0.0/16. Peering does not propagate these routes automatically.
- Request
TGW peering
Stopped hereSource10.0.1.10:52000→Destination10.2.1.20:443The packet crosses the Region boundary without changing the private source or destination.
- Request
TGW B
Stopped hereSource10.0.1.10:52000→Destination10.2.1.20:443The table associated with the incoming peering attachment sends the packet to VPC B.
- Request
VPC B
Stopped hereSource10.0.1.10:52000→Destination10.2.1.20:443Destination subnet routing, ACLs and the service SG admit the request.
- Reply
TGW B
Stopped hereSource10.2.1.20:443→Destination10.0.1.10:52000The VPC B subnet routes to its TGW. The table associated with its VPC attachment needs a return static route to the peer.
The TGW B return route to 10.0.0.0/16 is absent. Forward and reverse lookups use different incoming attachment contexts.
- Reply
TGW peering
Stopped hereSource10.2.1.20:443→Destination10.0.1.10:52000The response traverses the peering connection back to TGW A.
- Reply
TGW A
Stopped hereSource10.2.1.20:443→Destination10.0.1.10:52000The peering-associated table selects the VPC A attachment.
- Reply
VPC A
Stopped hereSource10.2.1.20:443→Destination10.0.1.10:52000The reply reaches the original client after return filtering.
Consumer → PrivateLink service
A same-Region consumer uses a provider-approved interface endpoint at 10.0.1.50. The provider exposes a TCP service through an NLB. Provider-side packet addresses are intentionally abstracted.
- Consumer
- Endpoint ENI
- Provider NLB
- Service
Solid connectors show the logical path. Highlighted node = current step. Request and reply remain in the trace below.
- Request
Consumer
Stopped hereSource10.0.1.5:53000→Destination10.0.1.50:443The endpoint DNS name resolves to an endpoint ENI private address; the consumer SG permits the request.
- Request
Endpoint ENI
Stopped hereSource10.0.1.5:53000→Destination10.0.1.50:443The endpoint SG allows TCP 443 from the consumer. Required subnet ACL rules also allow the flow.
The endpoint SG does not allow TCP 443 from this consumer. Service approval does not replace network rules.
- Request
Provider NLB
Stopped hereSourceProvider-side connection→DestinationConfigured target:443PrivateLink delivers the connection to the provider NLB. This exposes a service, not general routing into the provider VPC.
- Request
Service
Stopped hereSourceProvider-side connection→DestinationConfigured target:443A configured listener forwards to a healthy target; provider network rules and the application allow the request.
No service is available on the configured target path. Check target health, listener configuration, provider filtering and the application.
- Reply
Provider NLB
Stopped hereSourceConfigured target:443→DestinationProvider-side connectionThe service response follows the load-balanced connection back through PrivateLink.
- Reply
Endpoint ENI
Stopped hereSource10.0.1.50:443→Destination10.0.1.5:53000On the consumer side, the peer remains the endpoint address.
- Reply
Consumer
Stopped hereSource10.0.1.50:443→Destination10.0.1.5:53000The response reaches the consumer. No peering route to the provider CIDR was needed.
Routes choose where, rules choose whether
Consider a packet addressed to 10.1.2.10. The table below contains both 10.1.0.0/16 and 0.0.0.0/0, so the more specific /16 route sends the packet toward the peering connection. If equally specific routes compete, AWS applies priority rules based on route type. After choosing the target, the VPC still evaluates the network controls on that path. AWS route priority ↗
| Destination | Target | What it means |
|---|---|---|
| 10.0.0.0/16 | local | Reach addresses inside this VPC. |
| 10.1.0.0/16 | pcx-example | Send matching traffic to the accepted peer. |
| S3 managed prefix list | vpce-example | Use the associated gateway endpoint for matching S3 addresses. |
| 0.0.0.0/0 | nat-example | Send other IPv4 destinations to a NAT gateway. |
A subnet is public when its route table has a direct route to an internet gateway. For ordinary direct IPv4 internet access, an EC2 instance also needs a public address or Elastic IP and suitable filtering. Adding an IGW route to an instance with only a private IPv4 address is insufficient. IGW requirements ↗
Addresses and translation
In the public EC2 trace, the client sends traffic to 203.0.113.10:443, but the instance receives it at 10.0.1.5:443. The internet gateway applies the public-to-private IPv4 mapping; the public address is not configured inside the guest. On the reply, the gateway maps the private source back to the public address. IGW translation ↗
The NAT trace shows two mappings. First, the NAT gateway replaces the private client’s source with its own private address and a translated port. The internet gateway then maps that private address to the NAT gateway’s Elastic IP. The reply reverses both mappings. Port 62000 is illustrative; it does not predict the port AWS will allocate. This path supports connections initiated by the private client, not unsolicited connections initiated from the internet. NAT behavior ↗
| Gateway | Purpose | Boundary |
|---|---|---|
| Internet gateway | Direct IPv4 or IPv6 internet connectivity | IPv4 needs a public mapping; IPv6 does not use this IPv4 NAT mapping. |
| Zonal public NAT gateway | Private IPv4 clients initiate internet connections | Requires an Elastic IP and a public subnet with an IGW route. |
| Private NAT gateway | Address translation toward private networks | It is not an internet egress gateway through an IGW. |
| Egress-only internet gateway | IPv6 connections initiated from the VPC | Allows their replies; blocks internet-initiated connections. |
The explorer deliberately uses a zonal NAT gateway. Regional NAT gateways have a different placement and routing model, with an AWS-managed route table rather than requiring a user-selected public subnet. Do not apply the zonal placement rule to every NAT gateway type. Regional NAT ↗
IPv6 routes are separate from IPv4 routes: 0.0.0.0/0 does not cover ::/0. An egress-only internet gateway supplies outbound-only IPv6 connectivity without translating IPv6 into IPv4; DNS64/NAT64 is a different mechanism for IPv6 clients accessing IPv4 destinations. IPv6 egress ↗ NAT64 ↗
Why the reply can fail
In the Internet → public EC2 scenario, choose the reply-side NACL failure. The request reaches the server on destination port 443, but the reply is addressed to the client’s temporary port, 52140. A stateless ACL must permit those two directions separately.
| Property | Security group | Network ACL |
|---|---|---|
| Scope | Associated resource/network interface | Traffic entering or leaving a subnet |
| Rules | Allow rules; matching permissions combine | Allow or deny; first matching numbered rule wins |
| Reply to an allowed tracked flow | Allowed by connection state | Needs an explicit rule in the reverse direction |
| Example inbound HTTPS server | Inbound TCP 443 from intended clients | Inbound 443 plus outbound client ephemeral ports |
| Same-subnet traffic | SG rules still matter | Not filtered as a subnet boundary crossing |
A security group tracks an admitted connection and permits its reply without requiring a reverse rule that would admit a new connection. That state does not supply a missing route and cannot override a network ACL. The example assumes the flow is tracked normally. Security groups ↗
ACL rules evaluate destination ports in each direction. For a private client initiating HTTPS, the inbound reply rule must allow the client ephemeral port. For a public server accepting HTTPS, the outbound reply rule must allow the remote client ephemeral port. Real ephemeral ranges depend on the client or translating device; 1024–65535 is a broad compatibility range, not every operating system’s allocation range. ACL rules ↗ Ephemeral ports ↗
Endpoints change the service path
A gateway endpoint adds routes for a service prefix list to associated route tables. An interface endpoint instead provides ENIs and commonly uses private DNS to direct the service name toward them. Check the route-table association or the DNS answer to confirm which private path the client will use. Gateway endpoints ↗ Interface endpoint DNS ↗
The PrivateLink scenario exposes a provider service through a Network Load Balancer (NLB). It does not connect entire VPC address spaces like peering. Provider permissions and acceptance, endpoint security groups, listeners, target health and application authorization solve different parts of delivery. The trace avoids inventing provider-side source addresses, which depend on the service configuration. PrivateLink services ↗
Peering and transit gateway route domains
Peering joins two non-overlapping VPC address spaces. Both participating subnet route tables need routes for the other side, and network rules must allow the flow. A ↔ B and B ↔ C do not imply A ↔ C. Peering is not transitive, and it does not let a peer borrow another VPC’s internet gateway or gateway endpoint. Cross-Region peering SG rules use CIDRs rather than references to the remote SG. Peering boundaries ↗
A transit gateway (TGW) adds another routing decision. The VPC subnet route sends the packet to its TGW attachment. The TGW then looks up the destination in the route table associated with the attachment where the packet arrived and chooses the next attachment. Association selects the table used for that lookup; propagation adds learned prefixes to selected tables. Configuring one does not configure the other. TGW routing ↗
For TGW peering, configure static routes to the peering attachment in both directions. The explorer shows four TGW lookups across the round trip, so a missing return lookup is visible. Stateful inspection adds a symmetry requirement; appliance mode on the inspection VPC attachment helps preserve the flow’s path, but the surrounding routes still need to be correct. TGW peering ↗ Appliance mode ↗
Cross-Region and hybrid boundaries
Crossing a Region does not imply a universal 1,500-byte MTU. AWS currently documents 8,500 bytes for inter-Region VPC peering, and TGW supports 8,500 bytes across its peering attachments. The usable end-to-end MTU is constrained by the smallest link along the actual path; VPN encapsulation and other devices introduce their own limits. Small successful probes do not prove that larger packets will pass. VPC peering MTU ↗ TGW MTU ↗
| Path | Logical sequence | Check before relying on it |
|---|---|---|
| Site-to-Site VPN | Customer gateway → IPsec tunnels → VGW or TGW → VPC | Tunnel state, route advertisement, return routing and effective MTU |
| Direct Connect to a VPC | Customer router → private virtual interface → VGW (optionally through DXGW) | BGP session, advertised prefixes, gateway associations and subnet routes |
| Direct Connect to TGW | Customer router → transit virtual interface → DXGW → TGW → VPC | Allowed prefixes plus the TGW route table selected by the incoming attachment |
The hybrid sequences above are configuration paths: virtual interfaces, gateway associations and routing all need to agree. Direct Connect gateways ↗ Site-to-Site VPN ↗
Direct Connect provides a dedicated connection, but does not encrypt traffic by default. Use appropriate TLS, supported MACsec, or an IPsec VPN design when encryption is required. MACsec protects its link; it is not a substitute for application-to-application encryption. Direct Connect encryption ↗
Cloud WAN extends the routing-policy discussion to a managed global core and segments. It does not remove the need to reason about which segment can reach which destination and how the reply returns. Cloud WAN overview ↗
Subnet details worth remembering
For a normal AWS-assigned IPv4 subnet 10.0.1.0/24, AWS reserves the first four and last addresses: .0, .1, .2, .3, and .255, leaving 251 assignable addresses. The .1 address is reserved for the VPC router; VPCs do not support broadcast. BYOIP has different address-allocation exceptions. Subnet addressing ↗
The subnet’s reserved .2 address does not mean a separate resolver lives at the base-plus-two address of every subnet. For a VPC with primary CIDR 10.0.0.0/16, the Amazon DNS server address is 10.0.0.2; AWS also provides the link-local resolver address 169.254.169.253. VPC DNS ↗
Availability Zone names may map differently between accounts. Use AZ IDs when you need to compare the same physical Availability Zone across accounts. An AZ can contain multiple data centers. AZ IDs ↗
Diagnose the first missing condition
| Observation | Check next | Why |
|---|---|---|
| Request reaches the server, client times out | Return route and reverse-direction NACL ephemeral ports | SG state only solves the security-group part of the reply. |
| NAT is reachable, internet is not | NAT type, IGW connectivity and both subnet ACLs | The gateway must have an onward path and permit translated ports. |
| Peering is active, connection fails | Both subnet route tables and destination filtering | Connection status does not install routes or open ports. |
| TGW attachment exists, traffic stops | Incoming attachment association and selected table | A route in another table is not used for this lookup. |
| Endpoint exists, request uses public egress | DNS result or gateway endpoint route association | Interface and gateway endpoints select paths differently. |
| Network path works, S3 returns AccessDenied | Identity, endpoint and bucket policies | Application authorization is separate from packet delivery. |
| Small probes work, large transfers stall | Effective path MTU and ICMP required for discovery | A successful small packet does not test large-packet delivery. |
VPC Flow Logs can show that an observed IP flow was accepted or rejected at a supported interface. They do not capture packet contents or cover every traffic type. Match the interface, source and destination addresses, ports, protocol, direction, and time window before using a record as evidence for this connection. Flow Logs ↗
Reachability Analyzer evaluates supported network configuration paths without sending packets. Use it to find configuration blockers, then test DNS, host firewalls, listeners, TLS and application permissions separately. A reachable model does not prove an application is healthy. Reachability Analyzer ↗
Sources and documentation
- Subnet route tables and the implicit router
- Route priority and longest prefix match
- Subnet CIDR blocks and reserved addresses
- Internet gateways and IPv4 translation
- NAT gateways
- Regional NAT gateway architecture
- Egress-only internet gateways
- Stateful security groups
- Network ACL rules and subnet boundaries
- Custom ACLs and ephemeral ports
- Gateway endpoints
- Interface endpoints and private DNS
- Share services through PrivateLink
- VPC peering limitations and MTU
- Transit gateway routing and appliance mode
- Transit gateway peering
- Transit gateway MTU
- Direct Connect encryption
- Direct Connect gateway architectures
- Site-to-Site VPN
- Cloud WAN and network segments
- Amazon DNS addresses
- Availability Zone IDs
- VPC Flow Logs
- Reachability Analyzer