Where did my request die?

An interactive lab for AWS networking and access. Pick a scenario and send the request: the packet travels through every gateway, route table, firewall and policy on its path, and stops exactly where AWS would stop it. You’ll see the error you’d really get, why it happened, and the fix. Each scenario starts broken. Change any layer to experiment.

Simulated in your browser

NetworkOrganization policyIdentity policyResource policyEncryptionHost

Live mode: real AWS servers

Checking whether the live backend is awake…

Layers on the path

Result

Trace

Send the request to see each hop.

Read the symptom first

  • Timed out means something on the path silently dropped a packet: a security group, a network ACL, a route table, or a missing gateway or public IP. Policies are never even consulted.
  • Connection refused means the network worked and reached the host, but nothing is listening on that port.
  • 403 Access denied means the network worked and a policy said no. The error message names the policy type that blocked it.

How AWS authorizes a request

  1. An explicit deny in any policy wins, every time.
  2. SCPs (caller’s organization) and RCPs (resource’s organization) must allow. They cap permissions but never grant them.
  3. Same account: the identity policy or the resource policy can allow. Cross-account: both must allow.
  4. Permissions boundaries and VPC endpoint policies cap what the other policies allow.
  5. KMS-encrypted data adds a separate check: the key policy must allow you too.

AWS evaluates all policies together. This debugger reports the first blocking layer, so fixing one can reveal the next, just like in real life.