AWS VPC packet flow simulator

The VPC has three subnets: a public one with a web server and a NAT gateway, a private one with an application server, and a data subnet with a database. Choose a connection by its source, destination, protocol and port, or click one of the examples; the diagram draws its path and the list shows each check in order, including the checks on the reply. Open the editor to change routes, network ACL rules and security group rules, or start from one of the broken configurations.

A packet leaving an instance in an AWS VPC is checked first by the instance's security group outbound rules, then, if it leaves the subnet, by the subnet's network ACL outbound rules. The subnet's route table decides where it goes: another subnet through the local route, an internet gateway, a NAT gateway, an endpoint or a peering connection. Entering the destination subnet it meets that subnet's network ACL inbound rules, and then the destination's security group inbound rules. The reply travels back through the network ACLs again, while the security groups let it through on their own.

Every subnet is associated with one route table. Every route table has a local route for the VPC's own range, so subnets can always reach each other as far as routing is concerned. For any other destination the table uses the most specific matching route: in the private subnet, 0.0.0.0/0 points to the NAT gateway, but the S3 prefix list added by a gateway endpoint and the peered VPC's 10.1.0.0/16 are more specific and win for those addresses. Add a more specific blackhole route and it beats the default route too: in the blackhole configuration the app's connection to the internet host fails with "best match 203.0.113.0/24 blackhole is a blackhole route".

Security groups attach to network interfaces and contain only allow rules; anything not allowed is dropped. They are stateful: once a connection is allowed in one direction, its return traffic is allowed regardless of rules. Rules can name another security group instead of an address range, so the database's group here allows port 5432 from "anything in the app group" rather than from an address range that might change.

Network ACLs attach to subnets, have numbered allow and deny rules evaluated from the lowest number, stop at the first match, and deny anything that matches nothing. They are stateless and only see traffic crossing the subnet boundary. Both layers must allow a connection. In the example, the web server's connection to the database gets past the data subnet's ACL, because its rule for ephemeral ports happens to cover 5432 too, and is stopped by the database's security group: security group db (database).

The client side of a TCP connection uses a temporary ephemeral port, a high number chosen by its operating system, and the server's reply is addressed to it. Because network ACLs are stateless, every subnet a reply enters needs an inbound rule allowing those ports; the AWS documentation suggests 1024-65535 to cover the ranges different systems and NAT gateways use. This is the most common reason a network ACL change breaks something. The NACL without ephemeral ports configuration removes that rule from the private subnet, and app to the internet, app to s3, app to peered vpc all stop working, although the outgoing packets are still allowed.

A subnet is public if its route table sends internet-bound traffic to an internet gateway. The gateway translates between an instance's private address and its public IPv4 address, so an instance without one cannot use it, in either direction: app server has no public address, so nothing on the internet can address it; the internet gateway only translates public addresses of instances that have one.

Private instances reach the internet through a NAT gateway placed in a public subnet. The private subnet routes 0.0.0.0/0 to it; it sends the traffic on through the internet gateway from its own Elastic IP and passes replies back. Connections can only start from inside. A NAT gateway has no security group, but the public subnet's network ACL applies to traffic going into and out of it, in both directions, which is why the public subnet here allows traffic from the VPC and replies to ports 1024-65535.

A gateway endpoint for S3 or DynamoDB adds a route for the service's prefix list to the route tables you choose, so private instances reach the service without a NAT gateway or a public address; an endpoint policy can restrict what they may do. A peering connection joins two VPCs: each side needs a route to the other's range through the peering connection, and each side's security groups and ACLs must allow the traffic. Peering is not transitive, so a VPC peered with two others does not connect them to each other.

The VPC, subnets and addresses are fixed; the rules are yours to change. Addresses outside the VPC come from documentation ranges, and the S3 prefix list is represented by one illustrative range. The peered VPC is assumed to route back and to allow the traffic. Replies use client port 50000 and, through the NAT gateway, port 1024, as examples from the ranges in use. IPv6, transit gateways, interface endpoints and load balancers are left out.