Implementing ingress geo-restriction with AWS to reduce attack surface

Geo-restriction has evolved from a nice-to-have feature to a critical security control. As cyber threats become increasingly sophisticated and geographically concentrated, organizations need precise tools to control where their traffic originates—whether for security, compliance, or cost optimization. These controls integrate seamlessly into zero-trust security models, making sure that access requests originate from expected locations and adding a crucial verification layer to authentication processes.

The security imperative has become even more pressing as certain geographic regions consistently generate disproportionately high levels of malicious traffic, such as sophisticated automated attacks and fraud attempts. When legitimate business rarely originates from these high-risk regions, geographic restrictions offer a powerful way to reduce attack surfaces and focus security resources on protecting genuine user traffic.

In this post, we dive deep into how each Amazon Web Services (AWS) services like Amazon CloudFront, AWS WAF, AWS Network Firewall and Amazon Route 53 effectively handle geo-restriction, analyze their key differences, and provide guidance for choosing the optimal solution for your specific needs. We demonstrate when to use each service, and how to combine them for a defense-in-depth approach, so that you can implement the most effective solution for your architecture.

All AWS services covered in this post use MaxMind GeoIP databases to provide accurate IP-to-location mapping at country and regional levels.

Option 1: CloudFront

CloudFront is a content delivery network (CDN) that securely delivers content through a global network of edge locations. CloudFront provides several approaches for implementing geo-restriction: a feature for country-level blocking at no added cost, integration capabilities with third-party geolocation services, and edge functions for programmatic control. In this section we examine each approach in detail.

1) Built-in geolocation feature

The CloudFront built-in geographic restriction feature provides clear country-level access control with zero added costs beyond standard CloudFront pricing. CloudFront geographic restrictions apply uniformly across the entire distribution, meaning all cache behaviors share the same geographic rules. These restrictions cannot be configured differently for individual paths or behaviors within the same distribution.

The feature operates on an exclusive basis: allowlists automatically block all non-specified countries, while blocklists allow all countries except those specified.

Geographic restrictions set directly in CloudFront take precedence over any AWS WAF rules and edge functions (CloudFront Functions and Lambda@Edge). This precedence order makes sure that geographic restrictions act as the first line of defense in your security stack. Any traffic that passes the CloudFront geo-restriction filter is evaluated by AWS WAF rules and edge functions. Log attributes such as"x-edge-detailed-result-type": "ClientGeoBlocked"and"sc-status": "403"forbidden clearly indicate blocked requests. More log attributes such as"c-ip",“x-forwarded-for”and"c-country"offer deeper insights into the origin of requests.

The following is a sample CloudFront access log showing a geo-blocked request from the United States:

{
"date": "2025-08-22",
"time": "02:50:36",
"x-edge-location": "DFW57-P6",
"c-ip": "1234:1234:1f23:b123:1234:A2b3:9a1z:g123",
"cs-method": "GET",
"cs(Host)": "d1eXXXXXXXmm.cloudfront.net",
"cs-uri-stem": "/",
"sc-status": "403",
"cs(User-Agent)": "curl/8.7.1",
"x-edge-result-type": "Error",
"x-edge-request-id": "xZTYxiZQeaE4W2qZQggfLsku2smTCxR7JG3Y1BJhzPp_PAxcpXX==",
"x-host-header": "d1eXXXXXXXmm.cloudfront.net",
"cs-protocol": "http",
"x-edge-response-result-type": "Error",
"x-edge-detailed-result-type": "ClientGeoBlocked",
"sc-content-type": "text/html",
"c-country": "US"
}

2) Third-party geolocation service

Third-party geolocation services provide an alternative approach to implementing geographic controls beyond the CloudFront country-level restrictions. This approach can be particularly relevant for organizations that need to implement complex geographic rules that follow non-standard boundaries, or when they need different rules for specific content paths within the same distribution. Organizations might choose this path when they already use external geolocation services as part of their broader technology stack or have specific requirements that align well with third-party solutions.

The implementation works by integrating your application with a third-party geolocation service’s API. When a user requests content, your application captures the client’s IP address and sends it to the geolocation service. The service returns detailed geographic data, including city, postal code, coordinates, and sometimes more context such as ISP information or connection type. Your application can use this enriched location data to make access control decisions.

3) Edge functions

Edge functions provide programmatic geo-restriction capabilities through two options: CloudFront Functions for lightweight, high-performance scenarios, and Lambda@Edge for complex logic needing more computational power. These functions enable you to implement sophisticated geographic access controls directly at CloudFront edge locations, allowing for granular blocking based on various location attributes and URL pattern matching. To use geolocation data in edge functions, you must configure either an Origin Request Policy or Cache Policy that includes the desired viewer location headers.

CloudFront Functions run with sub-millisecond latency directly at CloudFront edge locations, making them ideal for high-volume, low-latency geolocation decisions. These functions can be triggered during viewer request or viewer response events. They have access to geolocation and device data during viewer events, so they can handle millions of requests per second, making them highly scalable for high-traffic applications. Blocked requests show"sc-status": "403"and"x-edge-detailed-result-type": "FunctionGeneratedResponse"in CloudFront logs.

Lambda@Edge provides another option for implementing geo-restriction logic, though with some important considerations. Although it can be triggered at both viewer and origin events, geolocation data is only available during origin requests and responses. This consideration, in combination with the fact that origin calls only occur during cache misses, makes it less ideal for primary geo-restriction implementation. However, if you already use Lambda@Edge functions in your architecture, then adding geographic filtering logic might be convenient. Blocked requests show"sc-status": "403"and"x-edge-detailed-result-type": "MissGeneratedResponse"in logs. Lambda@Edge functions are more computationally powerful but also more expensive than CloudFront Functions.

Option 2: AWS WAF

AWS WAF is a web application firewall that helps secure your web applications and APIs by blocking requests before they reach your servers.

AWS WAF determines the client location by examining the source IP address from either the direct client connection or X-Forwarded-For (XFF) headers when behind proxies or CDNs. When examining X-Forwarded-For (XFF) headers, AWS WAF examines the first IP address in the header.

The geo match statement within AWS WAF automatically enriches all incoming web requests with geographical context by applying labels that indicate both the country and region of origin. These labels follow a consistent format:"clientip:geo:country:<ISO country code>"and"clientip:geo:region:<ISO region code>"for countries and regions respectively. Importantly, these labels are injected whenever a geo match rule evaluates a request, regardless of whether the rule finds a match or not. This consistent labeling serves two valuable purposes: it enables the use of these geographic identifiers in downstream rules for more complex access control logic, and it provides rich data for log analysis to understand traffic patterns and their geographic origins.

AWS WAF geo match rules support Allow, Block, Count, Challenge, and CAPTCHA actions, and it can combine multiple criteria, such as ASN, IP addresses, CIDR ranges, countries, and regions (through Labels). For example, you can block traffic from specific countries while creating IP-based exceptions for legitimate business partners within those regions, or combine geographic restrictions with rate limiting for different request volumes per region.

The following is a sample AWS WAF log showing a geo-blocked request from the United States, including the automatic geographic labeling. If the action is set to COUNT in this rule, then these Labels can be used in downstream Rules as needed.

{
    "timestamp": 1755054486205,
    "formatVersion": 1,
    "webaclId": "arn:aws:wafv2:us-east-1:95376154XXX:global/webacl/Test/57d26a7b-66b8-471b-ad07-b32aXXXX",
    "terminatingRuleId": "USBlock",
    "terminatingRuleType": "REGULAR",
    "action": "BLOCK",
    "terminatingRuleMatchDetails": [],
    "httpSourceName": "CF",
    "httpSourceId": "ECB75ZPWSXXX",
    "ruleGroupList": [],
    "rateBasedRuleList": [],
    "nonTerminatingMatchingRules": [],
    "requestHeadersInserted": null,
    "responseCodeSent": null,
    "httpRequest": {
        "clientIp": "3.239.X.X",
        "country": "US",
        "headers": [
            {
                "name": "Host",
                "value": "did07inwxxxx.cloudfront.net"
            },
            {
                "name": "User-Agent",
                "value": "curl/8.11.1"
            },
            {
                "name": "Accept",
                "value": "*/*"
            }
        ],
        "uri": "/",
        "args": "",
        "httpVersion": "HTTP/1.1",
        "httpMethod": "GET",
        "requestId": "VjYFD2a9B2FqXGZ-ljiuLqmDYYBOzNlkglXJ252wJtlyXGXXXlzxxxxx",
        "fragment": "",
        "scheme": "http",
        "host": " did07inwxxxx.cloudfront.net"
    },
    "labels": [
        {
            "name": "awswaf:clientip:geo:country:US"
        },
        {
            "name": "awswaf:clientip:geo:region:US-VA"
        }
    ]
}

Option 3: AWS Network Firewall

AWS Network Firewall operates at the network infrastructure level (layers 3-7), providing geographic IP filtering capabilities that complement application-layer solutions such as CloudFront and AWS WAF. Unlike the previous options that focus on HTTP/HTTPS traffic, Network Firewall can filter all IP, Port, and Protocol, making it ideal for protecting entire VPC workloads regardless of the application protocol.

When traffic reaches Network Firewall, the service evaluates configured geographic rules and identifies the geographic location of source or destination IP addresses (based on your rule configuration) to apply the appropriate action. These actions include pass, drop, reject, or alert, for traffic to or from specific countries using standard ISO country codes.

Network Firewall supports geographic filtering through two primary methods:

1. Standard stateful rules: Through the AWS Management Console, you can configure geographic IP filtering with intuitive options to either “Match only selected countries” or “Match all but selected countries“.
2. Suricata-compatible rules: For advanced users, Network Firewall supports Suricata rule syntax using the “geoip” keyword. This approach enables more sophisticated filtering logic, allowing you to combine geographic restrictions with other packet inspection criteria such as specific protocols, ports, or payload content.

The following is an example suricata rule set demonstrating how to allow and monitor traffic from a specific country (India). The rule evaluation order was set to Strict.

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Ingress traffic from IN allowed"; flow:to_server; geoip:src,IN; metadata:geo IN; sid:202409301;) 
pass ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Ingress traffic from IN allowed"; flow:to_server; geoip:src,IN; metadata:geo IN; sid:202409302;)

This flexibility enables complex scenarios such as blocking SSH traffic from specific countries while allowing other protocols, or combining geographic restrictions with deep packet inspection rules for enhanced security policies.

Network Firewall includes the msg keywords in your rules and metadata to provide detailed geographic information in the alert logs. The following is an example alert log generated for the preceding rules:

{
    "firewall_name": "Test-NFW",
    "availability_zone": "eu-west-2a",
    "event_timestamp": "1756003042",
    "event": {
        "tx_guessed": true,
        "tx_id": 0,
        "app_proto": "http",
        "src_ip": "43.204.148.X",
        "src_port": 49418,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 202409301,
            "rev": 0,
            "metadata": {
                "geo": [
                    "IN"
                ]
            },
            "signature": "Ingress traffic from IN allowed",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 799891964035732,
        "dest_ip": "10.0.10.198",
        "proto": "TCP",
        "verdict": {
            "action": "pass"
        },
        "http": {
            "hostname": "18.134.198.X",
            "url": "/",
            "http_user_agent": "curl/8.11.1",
            "http_method": "GET",
            "protocol": "HTTP/1.1",
            "length": 0
        },
        "dest_port": 80,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2025-08-24T02:37:22.969703+0000",
        "direction": "to_server"
    }
}

Note: This example and blog focuses on ingress traffic filtering. However, AWS Network Firewall also supports egress geo-blocking, allowing you to control outbound traffic to specific countries. For detailed implementation examples covering both ingress and egress scenarios, along with logging configurations, refer to the AWS Network Firewall Geographic IP Filtering launch blog and the Network Firewall documentation. 

Option 4: Route 53

Route 53 geolocation routing provides DNS-level geographic access control by returning different DNS responses based on the location of DNS queries. This approach enables blocking or redirecting traffic from specific countries before it even reaches your infrastructure, offering a unique upstream filtering capability that operates at the DNS resolution layer.

Route 53 geolocation routing functions by mapping IP addresses to geographic locations using geolocation databases. When a DNS query arrives, Route 53 determines the geographic origin based on either the DNS resolver’s IP address or, when available, the client subnet information provided through the EDNS0-Client-Subnet (ECS) extension. The service responds with the appropriate DNS record based on your configured geographic routing rules.

You can implement Route 53 geolocation blocking through two main strategies:

1. Invalid IP redirection: The most direct blocking approach involves configuring geolocation records for restricted countries to return invalid IP addresses such as 127.0.0.1 (loopback). This causes blocked traffic to fail at the client level without consuming your infrastructure resources, because the requests never leave the user’s system.
2. Error page redirection: A more user-friendly approach directs blocked users to a dedicated error page hosted on CloudFront and Amazon Simple Storage Service (Amazon S3). This static website can explain the access restriction, provide appeal processes, or offer alternative contact methods. This approach maintains better user experience while clearly communicating access policies.

Route 53 supports multiple levels of geographic specificity, from continental routing to country-level and US state-level controls. When implementing overlapping geographic regions, the service applies precedence rules where the most specific geographic match takes priority. For example, if you configure both a North America record and a Canada-specific record, then Canadian queries match the Canada record while other North American queries use the continental rule.

The effectiveness of Route 53 significantly improves when DNS resolvers support EDNS0-Client-Subnet (ECS). This extension allows recursive DNS resolvers to include the client’s network subnet information in queries, so that Route 53 can make routing decisions based on the actual client location rather than the DNS resolver location.

Although many public DNS services such as Google DNS and OpenDNS support EDNS, some do not due to varying privacy and implementation considerations. When EDNS is unavailable, Route 53 falls back to using the DNS resolver’s IP address for geographic determination, which can lead to suboptimal routing decisions when clients use geographically distant DNS servers.

Conclusion

Each AWS service offers distinct advantages for geo-restriction, with varying levels of complexity, cost, and functionality. The following comparison matrix highlights the key differentiators to help guide your selection process.

For straightforward country-level blocking, start with CloudFront’s built-in geo-restriction or Route 53 geolocation routing—both offer low-cost implementation with minimal configuration. When you need application-aware filtering with URL-specific controls, AWS WAF geo-match rules or CloudFront edge functions provide greater flexibility. For network-level protection that extends beyond web traffic, AWS Network Firewall is the only solution supporting bidirectional inspection across all protocols and ports.

Most production environments benefit from layering multiple services together. For example, you might use Route 53 to block traffic at the DNS layer, CloudFront’s built-in geo-restriction as a second filter, and AWS WAF for granular, path-specific rules—creating a defense-in-depth architecture that addresses threats at multiple levels.

By implementing geo-restriction with AWS services, you can:

• Reduce your attack surface by blocking traffic from high-risk regions before it reaches your applications
• Lower infrastructure costs by filtering unwanted traffic early, reducing compute, bandwidth, and logging expenses
• Strengthen your compliance posture by enforcing geographic access policies required by regulatory frameworks such as GDPR or data residency requirements
• Improve security team efficiency by reducing alert noise and allowing teams to focus on legitimate threats
• Enhance application performance by reducing the load from unwanted traffic on your origin servers

Start with the simplest solution that meets your requirements, and add complexity as your geo-restriction needs evolve.

Get started today by exploring the CloudFront geo-restriction documentation, WAF geo-match conditions, Network Firewall rules reference and Route 53 geolocation routing guide.

About the authors