Skip to content
VenerableNetworks
ProfessionalProGlobal AcceleratorNACL / Security GroupsAWS VPC

Lab 18: The Deny Rule That May Not Be Read

Two identical servers in one subnet under one network ACL that denies your address. One sits behind a Global Accelerator with client IP preservation on. AWS documents two opposite answers about whether the deny applies to it, so this lab settles it in your account rather than telling you.

Debugging time
~25 min
Reading time
10 min
Reported by
Security Engineering
Tier
Professional
CHG-2041SEV-4OpenOpened 2026-08-19 09:15 UTC

Confirm whether subnet network ACLs still apply once client IP preservation is enabled

Reported by Security Engineering

We are putting Global Accelerator in front of the public API and enabling client IP address preservation so the rate limiter sees real client addresses instead of accelerator addresses.

Review flagged a dependency. Two of our subnet network ACLs carry deny rules for specific source ranges, and those denies are the only place those ranges are blocked. If preservation changes whether network ACLs are evaluated, those rules stop doing anything and nobody finds out.

The documentation does not settle it. One page says network ACLs are not evaluated for this traffic. Another page in the same guide says preserved traffic still respects them. We need an answer for our own account before the change goes ahead, not a reading of the documentation.

What you are working with

One subnet, one Availability Zone, two identical HTTP servers. Every variable that could explain a difference between them is held constant except one: which of them is registered behind the accelerator.

Starting state — one subnet, one deny rule, two ways in
VPC 10.60.0.0/16 Attached: Internet gateway, Global Accelerator interface. AZ a contains subnet 10.60.1.0/24, holding endpoint host, control host.Your laptop, directthe control requestYour laptop, acceleratedthe same source addressVPC 10.60.0.0/16AZ asubnetpublic10.60.1.0/24Risk — network ACL denies your address on port 80endpoint hostbehind the acceleratorcontrol hostreached directlyInternet gatewayordinary ingressGlobal Acceleratorinterfacepreserves the clientaddress

One source address and two ways into one subnet. The edges are drawn from each entry point out to the client, which is the convention on these diagrams for anything outside the VPC — the requests you send travel the other way. Both servers share a subnet, a route table, a network ACL and a security group, and the security group permits port 80 from anywhere on purpose so that it cannot be what blocks anything and the network ACL is the only control in play. The control host is a second instance rather than the endpoint's own public address because AWS recommends against sending traffic directly to a resource that is also behind an accelerator — the paths can collide and add TCP delay, which would turn a clean timeout into something you cannot attribute.

The accelerator's endpoint is an EC2 instance, which is one of the two endpoint types where client IP address preservation is permanently on and cannot be disabled. That removes the main way this experiment could go wrong: there is no preservation setting to get accidentally left off, so you cannot end up measuring the unpreserved path and concluding the wrong thing.

Scope and constraints

  • The deny rule is scoped to your address and port 80 only, so Session Manager, the accelerator's health checks, and the instances' own outbound traffic are unaffected. Health checks do not come from your laptop.
  • Network ACLs are stateless, so one inbound deny is the whole test. A dropped request never reaches the server and there is nothing to return.
  • Global Accelerator is a global service whose control plane lives in us-west-2. The Terraform uses a second provider alias for that reason; without it the apply fails on the accelerator rather than on anything you configured.
  • Cost is about 7 cents an hour. Read the clean-up section before you start — this lab has a billing trap that the others do not.