CloudFront geographic restrictions can allow or deny access to an entire distribution according to the country or territory associated with a visitor's IP address. The feature is useful when content is licensed only in selected markets or when a service is not currently offered in certain countries.
However, built-in CloudFront geo restriction is not user authentication and should not be treated as an unbreakable compliance barrier. It makes a decision using IP geolocation, not a person's nationality, residence, or contractual eligibility. VPNs, proxies, corporate egress networks, and errors in geolocation data can all affect the result. Paid or private content should combine location rules with signed URLs, signed cookies, origin protection, and application-level authorization.
How CloudFront Geographic Restrictions Work
CloudFront's built-in Geographic Restrictions setting offers two modes:
Allow list: only viewers in listed countries can access the distribution; all other countries are denied.
Block list: viewers in listed countries are denied; other countries remain allowed.
The setting applies to the whole CloudFront distribution and works at country level. When a viewer request reaches an edge location, CloudFront estimates the country from the source IP address. If the policy denies that country, CloudFront returns HTTP 403 Forbidden instead of retrieving the restricted content.
Choose the list type according to the licensing model. An allow list is clearer when only a small number of countries are authorized. A block list is generally easier to maintain when only a few markets must be excluded.
AWS states that CloudFront uses a third-party IP geolocation database. Country mapping is highly accurate overall, but not perfect. AWS documentation also says that when CloudFront cannot determine a viewer's location, the built-in feature serves the requested content. Therefore, an unknown location should not be assumed to fail closed.
How to Configure Country Restrictions in CloudFront
Sign in to the AWS Management Console and open CloudFront.
Select the distribution that needs the restriction.
Open Security, then choose Geographic restrictions.
Edit the setting and select either Allow list or Block list.
Add the relevant countries or territories and save the change.
Wait for the distribution configuration to finish deploying, then test from both an allowed and a denied location.
Before deployment, account for the locations used by administrators, remote teams, partners, monitoring probes, and automated services. A production policy should not be considered verified simply because it works from the office network.
Built-In Restriction, AWS WAF, or Edge Logic?
| Option | Best Fit | Main Limitation |
|---|---|---|
| CloudFront built-in geo restriction | One country policy for the entire distribution | Country level only; cannot target selected paths or combine complex request conditions |
| AWS WAF Geo Match | Country or regional rules combined with paths, IPs, headers, rate controls, or exceptions | Requires deliberate rule priority, labels, logging, and the applicable WAF charges |
| CloudFront Functions or Lambda@Edge | Custom responses, redirects, and specialized edge workflows | More code, testing, monitoring, and failure handling; viewer country still is not identity proof |
| Third-party geolocation service | City, postal-code, or specialized commercial database requirements | Accuracy, latency, cost, privacy, and data licensing require separate review |
An AWS WAF Geo Match statement can match requests using ISO 3166 two-letter country codes and adds country and region labels to matching requests. A common pattern for state or province controls is to add geographic labels in one rule and evaluate those labels in later rules. Requests denied by CloudFront's built-in geographic restriction are not forwarded to AWS WAF. When geography must be combined with other WAF conditions, implement the decision in WAF rather than expecting the two layers to evaluate the same denied request.
When Should You Separate CloudFront Distributions?
If only one directory under a domain has territorial licensing restrictions while other files must remain globally available, evaluate WAF, signed access, and separate cache behaviors. If the domains, certificates, logging, policies, and operational lifecycles are also different, separate distributions may be easier to audit. Avoid multiplying distributions without a clear operational reason, but also avoid hiding unrelated authorization models inside an opaque rule set.
Geographic Restriction and Signed Access Solve Different Problems
A geographic rule answers, “Where does this request appear to come from?” Signed access answers, “Does this request possess a valid access credential?” They can be used together, but one does not replace the other.
| Control | Main Decision Input | Typical Use |
|---|---|---|
| Geographic restriction | Country or region associated with the source IP | Distribution territories, market availability, and geographic risk controls |
| Signed URL | URL signature, expiration, and optional IP condition | One paid download, a specific object, or a client that does not support cookies |
| Signed cookie | Cookie signature, policy, and expiration | Member areas, HLS video segments, or access to a group of restricted files |
| Application authentication | Account, subscription, permissions, and business state | Determine whether a particular user is entitled to the content |
CloudFront documentation recommends using trusted key groups for modern signer management. Signed URLs are generally appropriate for individual files or clients without cookie support. Signed cookies are useful when one authorization decision should cover multiple files without changing their URLs. Use a reasonably short validity period, protect private keys, and establish a rotation process.
The origin must also be protected against direct access that bypasses CloudFront. For an Amazon S3 origin, use an origin access design appropriate to the current architecture. For a custom HTTP origin, restrict the direct endpoint as well. If the origin URL remains publicly accessible, users may be able to bypass geographic and signature controls at the edge.
Why Country Blocking Is Not a Compliance Guarantee
VPNs and Proxies Change the Visible Source
CloudFront sees the source IP of the connection. When a visitor uses a VPN, proxy, or corporate gateway, the system evaluates the exit location rather than the person's physical location. Geo restriction can reduce ordinary access from excluded areas, but it cannot prove where a person is physically present.
IP Geolocation Produces False Positives
Mobile carriers, satellite networks, cross-border corporate networks, and newly allocated IP ranges can be mapped incorrectly. Provide an appropriate support or appeal route and monitor unexpected increases in 403 responses so that legitimate users are not silently excluded for long periods.
Legal Rules Are Not Always Simple Country Lists
Copyright, sanctions, export controls, privacy, tax, and industry licensing can define covered parties, products, and territories differently. A technical team should not treat a country list as the final legal interpretation. Record the source of each rule, approver, effective date, and review cycle, and obtain appropriate legal or compliance review.
Important: This article discusses technical configuration and is not legal advice. Sanctions, export controls, content licensing, and regulatory obligations should be reviewed by appropriately qualified professionals.
What About 403 Pages, Caching, and Search Engines?
Custom error pages: provide a concise explanation and support route, but do not disclose internal rules, credentials, or user data.
Error caching: CloudFront can cache error responses. If an old 403 remains after a policy change, inspect the error-caching configuration before repeatedly changing the country list.
Search crawling: crawlers operating from a denied location may be unable to fetch the page. Assess the effect on the search markets that matter before launch.
Redirects: avoid permanently redirecting every visitor solely from IP location. Preserve user choice, language preferences, and a route back to other regional pages.
Cache keys: if edge code generates different content by region, verify that one region's response cannot be incorrectly reused in another.
Pre-Launch and Post-Launch Checklist
Confirm whether the policy applies to the full distribution, selected paths, or particular users.
Record the business basis, owner, and review date for the country allowlist or blocklist.
Define how unknown locations, VPNs, proxies, and corporate egress networks should be handled.
Verify that the origin cannot be accessed directly and that private content also uses identity or signature authorization.
Perform real requests from at least one allowed and one denied country.
Check the expected status code, error page, response headers, caching behavior, and logs.
Monitor 403 volume, country distribution, reports of false blocking, and unusual traffic patterns.
Prepare a quick rollback procedure and retain a history of configuration changes.
Frequently Asked Questions
Can Built-In CloudFront Geo Restriction Target a State or Province?
No. The built-in Geographic Restrictions feature controls access by country. For regional requirements, evaluate AWS WAF geographic labels with subsequent label-matching rules or another geolocation solution.
Which Status Code Is Returned to a Denied Viewer?
CloudFront's built-in geographic restriction normally returns HTTP 403 Forbidden. You can configure a custom error response, but test its caching duration and the behavior after policy changes.
What Happens If CloudFront Cannot Determine the Country?
According to current AWS documentation, the built-in feature serves the requested content when CloudFront cannot determine the viewer's location. If the business requires unknown locations to fail closed, implement explicit additional controls and test them thoroughly.
Can I Restrict Only a Video Directory?
The built-in setting applies to the entire distribution. For selected content, evaluate AWS WAF, a separate distribution, edge logic, or signed access associated with the relevant cache behavior.
Can a Signed URL Stop a User from Using a VPN?
No. A signed URL verifies an access credential; it does not establish physical location. A custom signed policy can include an IP range, but network changes, shared links, and proxy scenarios still require business tradeoffs.
Should CloudFront Geo Restriction and AWS WAF Be Used Together?
Combine them only when their responsibilities are clear. Use the built-in feature for a simple country policy covering the full distribution. When geography must be combined with paths, IP exceptions, rate controls, or other conditions, keeping the decision in AWS WAF is often easier to understand and audit.
Conclusion
CloudFront geographic restrictions are a practical way to implement a country-level allowlist or blocklist, but they control IP geolocation rather than identity and do not provide absolute proof of compliance. Use the built-in feature for a simple distribution-wide country rule. Evaluate AWS WAF or edge logic for regional granularity, path-specific treatment, or compound conditions. Add signed URLs, signed cookies, or application authorization for paid and private content.
A reliable design also includes origin protection, logging, monitoring, a process for false positives, periodic review, and documented compliance approval. Treat geographic restriction as one layer in a broader access-control system—not as the only barrier between restricted content and the public internet.
References
AWS: Restrict the geographic distribution of your content, reviewed August 12, 2026
AWS WAF: Geographic match rule statement, reviewed August 12, 2026
AWS: Serve private content with signed URLs and signed cookies, reviewed August 12, 2026
AWS: Decide to use signed URLs or signed cookies, reviewed August 12, 2026
AWS: Specify signers for signed URLs and signed cookies, reviewed August 12, 2026
