CloudFront offers a built-in geographic restriction setting and AWS WAF offers a geo match rule. What can each do that the other cannot, and what would you tell a stakeholder who calls either one a compliance guarantee?

## The built-in setting CloudFront's geographic restriction lives on the distribution. You choose allowlist or blocklist and supply a set of country codes; CloudFront resolves the viewer's IP address to a country and refuses blocked viewers with a 403 before serving anything, cached or not. It costs nothing extra and takes a minute to configure. Its constraint is granularity. The setting is one policy for the entire distribution, applied to every cache behavior and every path. There is no way to express "block these countries for the video paths but always allow the health check and the public marketing pages." If your requirement has an exception in it, this feature cannot express it. ## The WAF geo match rule Inside an AWS WAF web ACL, a geo match statement is one condition among many. That changes what you can express: - Scope it with a byte-match on the URI so it applies to `/catalog/*` and nothing else. - Combine it with a rate-based rule, so a country is not blocked outright but is rate-limited harder. - Combine it with an IP set exception so partner egress ranges are exempt. - Set the action to **Count** first, and read the logs to see how much real traffic the rule would have hit before you enforce it. - Return a custom status code and body instead of a bare 403, which matters when a client application needs to distinguish "blocked by policy" from "broken". - Get per-request logging of which rule matched, which the built-in setting does not give you. The cost is real: WAF bills per web ACL, per rule, and per million requests inspected, so on a high-volume distribution a geo rule is not free the way the built-in toggle is. ## They share the same weakness Both resolve the client IP address against a geolocation database. That database is good, and for aggregate traffic it is right the overwhelming majority of the time — but the failure modes are systematic rather than random: - A commercial VPN or proxy presents an exit address in whatever country the user selected. Bypassing geo restriction is a consumer feature, not a hacking skill. - Corporate networks backhaul traffic, so an employee in one country appears in the country of the egress point. - Mobile carriers and CGNAT pools can be registered in one country while serving another. - A genuine customer travelling abroad is blocked from content they are entitled to, and will open a support ticket. - IP-to-country mappings change as ranges are reassigned, so a rule that was accurate a year ago drifts. Because both are country-granularity only, "this state but not that one" is not expressible either — although CloudFront can pass the viewer's inferred location onward in headers such as `CloudFront-Viewer-Country` and `CloudFront-Viewer-Country-Region`, so an edge function or the origin can make a finer-grained decision from the same inference. ## What to tell the stakeholder Say plainly that geo restriction is a control, not evidence. It reduces casual out-of-territory access and satisfies a good-faith-effort requirement in many licensing contracts, and that is genuinely worth having. It does not establish where a person is, and it will both let some people through and shut some legitimate customers out. If the contract or regulation demands a stronger claim, that claim has to rest on identity — an account with a verified billing address and a payment instrument in the territory — with geo filtering layered on top as a cheap first pass. Deciding which layer is authoritative is the real design conversation; the toggle is just the easy part.