Tác giả: Rahi Patel và Anvesh Koganti
Ngày đăng: 05/01/2026
Danh mục: Amazon CloudFront, Amazon Route 53, AWS Network Firewall, AWS WAF, Best Practices, Intermediate (200), Networking & Content Delivery, Security, Identity, & Compliance, Technical How-to

Giới hạn địa lý (geo-restriction) đã phát triển từ một tính năng “có thì tốt” trở thành một biện pháp kiểm soát bảo mật quan trọng. Khi các mối đe dọa mạng ngày càng tinh vi và tập trung theo khu vực địa lý, các tổ chức cần những công cụ chính xác để kiểm soát nguồn gốc lưu lượng truy cập — dù là vì mục tiêu bảo mật, tuân thủ hay tối ưu chi phí. Các biện pháp kiểm soát này tích hợp liền mạch vào các mô hình bảo mật zero-trust, đảm bảo rằng các yêu cầu truy cập xuất phát từ những vị trí được kỳ vọng và bổ sung một lớp xác minh quan trọng cho quy trình xác thực.

Yêu cầu bảo mật ngày càng trở nên cấp thiết hơn khi một số khu vực địa lý nhất định liên tục tạo ra lượng lưu lượng độc hại cao bất tương xứng, chẳng hạn như các cuộc tấn công tự động tinh vi và các nỗ lực gian lận. Khi hoạt động kinh doanh hợp pháp hiếm khi xuất phát từ những khu vực rủi ro cao này, việc áp dụng các giới hạn địa lý mang lại một cách hiệu quả để giảm bề mặt tấn công và tập trung nguồn lực bảo mật vào việc bảo vệ lưu lượng người dùng hợp lệ.

Trong bài viết này, chúng tôi đi sâu vào cách từng dịch vụ của Amazon Web Services (AWS) như Amazon CloudFront, AWS WAF, AWS Network Firewall và Amazon Route 53 xử lý hiệu quả bài toán giới hạn địa lý, phân tích các khác biệt chính giữa chúng, đồng thời đưa ra hướng dẫn giúp bạn lựa chọn giải pháp tối ưu cho nhu cầu cụ thể của mình. Chúng tôi minh họa khi nào nên sử dụng từng dịch vụ, cũng như cách kết hợp chúng theo hướng phòng thủ nhiều lớp (defense-in-depth), để bạn có thể triển khai giải pháp hiệu quả nhất cho kiến trúc của mình.

Tất cả các dịch vụ AWS được đề cập trong bài viết này đều sử dụng cơ sở dữ liệu MaxMind GeoIP để cung cấp khả năng ánh xạ IP sang vị trí địa lý chính xác ở cấp quốc gia và khu vực.

Tùy chọn 1: CloudFront

CloudFront là một mạng phân phối nội dung (CDN) cung cấp nội dung một cách an toàn thông qua mạng lưới toàn cầu các edge location. CloudFront cung cấp nhiều cách tiếp cận khác nhau để triển khai giới hạn địa lý: tính năng chặn theo quốc gia được tích hợp sẵn mà không phát sinh thêm chi phí, khả năng tích hợp với các dịch vụ định vị địa lý của bên thứ ba, và các edge function cho phép kiểm soát bằng lập trình. Trong phần này, chúng tôi sẽ phân tích chi tiết từng cách tiếp cận.

1) Tính năng định vị địa lý tích hợp sẵn

Tính năng giới hạn địa lý tích hợp sẵn của CloudFront cung cấp khả năng kiểm soát truy cập rõ ràng ở cấp quốc gia mà không phát sinh thêm chi phí ngoài mức giá CloudFront tiêu chuẩn. Các giới hạn địa lý của CloudFront được áp dụng đồng nhất trên toàn bộ distribution, nghĩa là tất cả các cache behavior đều chia sẻ cùng một tập quy tắc địa lý. Các giới hạn này không thể được cấu hình khác nhau cho từng path hoặc behavior riêng lẻ trong cùng một distribution.

Tính năng này hoạt động theo nguyên tắc loại trừ: danh sách cho phép (allowlist) sẽ tự động chặn tất cả các quốc gia không được chỉ định, trong khi danh sách chặn (blocklist) sẽ cho phép tất cả các quốc gia ngoại trừ những quốc gia được chỉ định.

Các giới hạn địa lý được thiết lập trực tiếp trong CloudFront có độ ưu tiên cao hơn bất kỳ rule nào của AWS WAF và các edge function (CloudFront Functions và Lambda@Edge). Thứ tự ưu tiên này đảm bảo rằng các giới hạn địa lý đóng vai trò là tuyến phòng thủ đầu tiên trong ngăn xếp bảo mật của bạn. Bất kỳ lưu lượng nào vượt qua bộ lọc geo-restriction của CloudFront sẽ tiếp tục được đánh giá bởi các rule của AWS WAF và các edge function. Các thuộc tính log như "x-edge-detailed-result-type": "ClientGeoBlocked" và "sc-status": "403" (forbidden) cho thấy rõ các yêu cầu đã bị chặn. Các thuộc tính log khác như "c-ip", "x-forwarded-for" và "c-country" cung cấp thêm thông tin chi tiết về nguồn gốc của các yêu cầu. Xem thêm log.

Dưới đây là một ví dụ về access log của CloudFront cho thấy một yêu cầu bị chặn theo địa lý từ Hoa Kỳ:

{
"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) Dịch vụ định vị địa lý của bên thứ ba

Các dịch vụ định vị địa lý của bên thứ ba cung cấp một cách tiếp cận thay thế để triển khai các kiểm soát địa lý vượt ra ngoài giới hạn cấp quốc gia của CloudFront. Cách tiếp cận này đặc biệt phù hợp với các tổ chức cần triển khai các quy tắc địa lý phức tạp theo các ranh giới không tiêu chuẩn, hoặc khi cần áp dụng các quy tắc khác nhau cho các path nội dung cụ thể trong cùng một distribution. Các tổ chức có thể chọn hướng đi này khi họ đã sử dụng sẵn các dịch vụ định vị địa lý bên ngoài trong hệ sinh thái công nghệ của mình, hoặc có những yêu cầu đặc thù phù hợp với các giải pháp của bên thứ ba.

Việc triển khai hoạt động bằng cách tích hợp ứng dụng của bạn với API của một dịch vụ định vị địa lý bên thứ ba. Khi người dùng yêu cầu nội dung, ứng dụng của bạn sẽ thu thập địa chỉ IP của client và gửi đến dịch vụ định vị địa lý. Dịch vụ này sẽ trả về dữ liệu vị trí chi tiết, bao gồm thành phố, mã bưu chính, tọa độ, và đôi khi là các ngữ cảnh bổ sung như thông tin ISP hoặc loại kết nối. Ứng dụng của bạn có thể sử dụng dữ liệu vị trí được làm giàu này để đưa ra các quyết định kiểm soát truy cập.

3) Edge functions

Edge functions cung cấp khả năng giới hạn địa lý theo hướng lập trình thông qua hai lựa chọn: CloudFront Functions cho các kịch bản nhẹ, hiệu năng cao, và Lambda@Edge cho logic phức tạp hơn, cần nhiều năng lực tính toán hơn. Các function này cho phép bạn triển khai các kiểm soát truy cập địa lý tinh vi trực tiếp tại các edge location của CloudFront, hỗ trợ chặn chi tiết dựa trên nhiều thuộc tính vị trí khác nhau và khớp theo URL pattern. Để sử dụng dữ liệu định vị địa lý trong edge functions, bạn cần cấu hình một Origin Request Policy hoặc Cache Policy bao gồm các header vị trí viewer mong muốn.

CloudFront Functions chạy với độ trễ dưới một mili-giây ngay tại các edge location của CloudFront, khiến chúng trở thành lựa chọn lý tưởng cho các quyết định định vị địa lý có lưu lượng lớn và yêu cầu độ trễ thấp. Các function này có thể được kích hoạt trong các sự kiện viewer request hoặc viewer response. Chúng có quyền truy cập vào dữ liệu định vị địa lý và thiết bị trong các sự kiện viewer, cho phép xử lý hàng triệu request mỗi giây, rất phù hợp cho các ứng dụng có lưu lượng cao. Các request bị chặn sẽ hiển thị "sc-status": "403" và "x-edge-detailed-result-type": "FunctionGeneratedResponse" trong log của CloudFront.

Lambda@Edge cung cấp một lựa chọn khác để triển khai logic giới hạn địa lý, nhưng đi kèm một số cân nhắc quan trọng. Mặc dù có thể được kích hoạt ở cả các sự kiện viewer và origin, dữ liệu định vị địa lý chỉ khả dụng trong các request và response tại origin. Yếu tố này, kết hợp với việc các request tới origin chỉ xảy ra khi cache miss, khiến Lambda@Edge kém phù hợp hơn cho việc triển khai geo-restriction làm tuyến phòng thủ chính. Tuy nhiên, nếu bạn đã sử dụng Lambda@Edge trong kiến trúc của mình, việc bổ sung thêm logic lọc theo địa lý có thể khá thuận tiện. Các request bị chặn sẽ hiển thị "sc-status": "403" và "x-edge-detailed-result-type": "MissGeneratedResponse" trong log. Lambda@Edge có năng lực tính toán mạnh hơn nhưng cũng tốn kém hơn so với CloudFront Functions.

Tùy chọn 2: AWS WAF

AWS WAF là một web application firewall giúp bảo vệ các ứng dụng web và API của bạn bằng cách chặn các request trước khi chúng tới được server.

AWS WAF xác định vị trí của client bằng cách kiểm tra địa chỉ IP nguồn từ kết nối trực tiếp của client hoặc từ header X-Forwarded-For (XFF) khi ứng dụng nằm sau proxy hoặc CDN. Khi kiểm tra header X-Forwarded-For (XFF), AWS WAF sẽ sử dụng địa chỉ IP đầu tiên trong header này.

Câu lệnh geo match trong AWS WAF sẽ tự động làm giàu tất cả các web request đến bằng ngữ cảnh địa lý, thông qua việc gắn các label cho biết quốc gia và khu vực xuất phát. Các label này tuân theo định dạng nhất quán: "clientip:geo:country:<ISO country code>" và "clientip:geo:region:<ISO region code>" tương ứng cho quốc gia và khu vực. Quan trọng là các label này được chèn vào mỗi khi một rule geo match được đánh giá, bất kể rule đó có khớp hay không. Cách gắn nhãn nhất quán này mang lại hai lợi ích quan trọng: cho phép sử dụng các định danh địa lý này trong các rule downstream để xây dựng logic kiểm soát truy cập phức tạp hơn, và cung cấp dữ liệu phong phú cho việc phân tích log nhằm hiểu rõ mô hình lưu lượng và nguồn gốc địa lý của chúng.

Các rule geo match của AWS WAF hỗ trợ các hành động Allow, Block, Count, Challenge và CAPTCHA, đồng thời có thể kết hợp nhiều tiêu chí khác nhau như ASN, địa chỉ IP, dải CIDR, quốc gia và khu vực (thông qua Labels). Ví dụ, bạn có thể chặn lưu lượng từ một số quốc gia nhất định trong khi vẫn tạo các ngoại lệ dựa trên IP cho các đối tác kinh doanh hợp pháp trong những khu vực đó, hoặc kết hợp các giới hạn địa lý với rate limiting cho các ngưỡng lưu lượng khác nhau theo từng khu vực.

Dưới đây là một ví dụ về log của AWS WAF cho thấy một request bị chặn theo địa lý từ Hoa Kỳ, bao gồm cả các label địa lý được gắn tự động. Nếu hành động của rule được đặt là COUNT, thì các label này có thể được sử dụng trong các rule downstream khi cần.

{
    "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"
        }
    ]
}

Tùy chọn 3: AWS Network Firewall

AWS Network Firewall hoạt động ở tầng hạ tầng mạng (layers 3–7), cung cấp khả năng lọc IP theo địa lý để bổ trợ cho các giải pháp ở tầng ứng dụng như CloudFront và AWS WAF. Khác với các tùy chọn trước vốn tập trung vào lưu lượng HTTP/HTTPS, Network Firewall có thể lọc toàn bộ IP, Port và Protocol, khiến nó trở thành lựa chọn lý tưởng để bảo vệ toàn bộ workload trong VPC, bất kể giao thức ứng dụng.

Khi lưu lượng đi tới Network Firewall, dịch vụ sẽ đánh giá các rule địa lý đã cấu hình và xác định vị trí địa lý của địa chỉ IP nguồn hoặc đích (tùy theo cấu hình rule của bạn) để áp dụng hành động phù hợp. Các hành động này bao gồm pass, drop, reject hoặc alert cho lưu lượng đến hoặc đi từ các quốc gia cụ thể, sử dụng mã quốc gia ISO tiêu chuẩn.

Network Firewall hỗ trợ lọc địa lý thông qua hai phương pháp chính:

1. Stateful rule tiêu chuẩn: Thông qua AWS Management Console, bạn có thể cấu hình lọc IP theo địa lý với các tùy chọn trực quan như “Match only selected countries” hoặc “Match all but selected countries”.
2. Rule tương thích Suricata: Đối với người dùng nâng cao, Network Firewall hỗ trợ cú pháp rule của Suricata thông qua từ khóa geoip. Cách tiếp cận này cho phép xây dựng logic lọc phức tạp hơn, kết hợp giới hạn địa lý với các tiêu chí kiểm tra gói tin khác như giao thức cụ thể, port hoặc nội dung payload.

Dưới đây là một ví dụ về bộ rule Suricata minh họa cách cho phép và giám sát lưu lượng từ một quốc gia cụ thể (Ấn Độ). Thứ tự đánh giá rule được đặt là 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;)

Sự linh hoạt này cho phép triển khai các kịch bản phức tạp như chặn lưu lượng SSH từ một số quốc gia nhất định trong khi vẫn cho phép các giao thức khác, hoặc kết hợp các giới hạn địa lý với các rule deep packet inspection để tăng cường chính sách bảo mật.

Network Firewall bao gồm các từ khóa msg trong rule và metadata để cung cấp thông tin địa lý chi tiết trong alert log. Dưới đây là một ví dụ về alert log được tạo ra từ các rule trên:

{
    "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"
    }
}

Lưu ý: Ví dụ và bài blog này tập trung vào việc lọc lưu lượng ingress. Tuy nhiên, AWS Network Firewall cũng hỗ trợ geo-blocking cho egress, cho phép bạn kiểm soát lưu lượng outbound tới các quốc gia cụ thể. Để xem các ví dụ triển khai chi tiết cho cả kịch bản ingress và egress, cùng với cấu hình logging, hãy tham khảo blog ra mắt tính năng Geographic IP Filtering của AWS Network Firewall và tài liệu Network Firewall.

Tùy chọn 4: Route 53

Tính năng định tuyến theo vị trí địa lý (geolocation routing) của Route 53 cung cấp khả năng kiểm soát truy cập dựa trên DNS bằng cách trả về các phản hồi DNS khác nhau tùy theo vị trí của truy vấn DNS. Cách tiếp cận này cho phép chặn hoặc chuyển hướng lưu lượng từ các quốc gia cụ thể trước cả khi nó chạm tới hạ tầng của bạn, mang lại khả năng lọc upstream độc đáo ở tầng phân giải DNS.

Geolocation routing của Route 53 hoạt động bằng cách ánh xạ địa chỉ IP sang vị trí địa lý thông qua các cơ sở dữ liệu định vị địa lý. Khi một truy vấn DNS được gửi tới, Route 53 xác định nguồn gốc địa lý dựa trên địa chỉ IP của DNS resolver hoặc, khi khả dụng, dựa trên thông tin subnet của client được cung cấp thông qua phần mở rộng EDNS0-Client-Subnet (ECS). Sau đó, dịch vụ sẽ trả về bản ghi DNS phù hợp dựa trên các quy tắc định tuyến địa lý mà bạn đã cấu hình.

Bạn có thể triển khai việc chặn theo địa lý trong Route 53 thông qua hai chiến lược chính:

1. Chuyển hướng tới IP không hợp lệ: Cách chặn trực tiếp nhất là cấu hình các bản ghi geolocation cho các quốc gia bị hạn chế để trả về các địa chỉ IP không hợp lệ như 127.0.0.1 (loopback). Điều này khiến lưu lượng bị chặn thất bại ngay ở phía client mà không tiêu tốn tài nguyên hạ tầng của bạn, vì các request không bao giờ rời khỏi hệ thống của người dùng.
2. Chuyển hướng tới trang lỗi: Một cách tiếp cận thân thiện hơn với người dùng là chuyển hướng các user bị chặn tới một trang lỗi chuyên dụng được host trên CloudFront và Amazon Simple Storage Service (Amazon S3). Website tĩnh này có thể giải thích lý do hạn chế truy cập, cung cấp quy trình kháng nghị, hoặc đưa ra các phương thức liên hệ thay thế. Cách tiếp cận này giúp duy trì trải nghiệm người dùng tốt hơn trong khi vẫn truyền đạt rõ ràng các chính sách truy cập.

Route 53 hỗ trợ nhiều mức độ chi tiết về địa lý, từ định tuyến theo châu lục, cấp quốc gia cho tới cấp bang của Hoa Kỳ. Khi triển khai các khu vực địa lý chồng lấn, dịch vụ sẽ áp dụng các quy tắc ưu tiên, trong đó khớp địa lý cụ thể hơn sẽ được ưu tiên cao hơn. Ví dụ, nếu bạn cấu hình cả một bản ghi cho Bắc Mỹ và một bản ghi riêng cho Canada, thì các truy vấn từ Canada sẽ khớp với bản ghi Canada, trong khi các truy vấn khác từ Bắc Mỹ sẽ sử dụng quy tắc theo châu lục.

Hiệu quả của Route 53 được cải thiện đáng kể khi các DNS resolver hỗ trợ EDNS0-Client-Subnet (ECS). Phần mở rộng này cho phép các recursive DNS resolver đưa thông tin subnet của client vào truy vấn, để Route 53 có thể đưa ra quyết định định tuyến dựa trên vị trí thực tế của client thay vì vị trí của DNS resolver.

Mặc dù nhiều dịch vụ DNS công cộng như Google DNS và OpenDNS có hỗ trợ EDNS, một số dịch vụ khác thì không do các cân nhắc khác nhau về quyền riêng tư và triển khai. Khi EDNS không khả dụng, Route 53 sẽ fallback sang việc sử dụng địa chỉ IP của DNS resolver để xác định vị trí địa lý, điều này có thể dẫn tới các quyết định định tuyến kém tối ưu khi client sử dụng các DNS server ở xa về mặt địa lý.

Kết luận

Mỗi dịch vụ AWS đều mang lại những lợi thế riêng cho bài toán giới hạn địa lý, với các mức độ phức tạp, chi phí và chức năng khác nhau. Bảng so sánh dưới đây làm nổi bật các điểm khác biệt chính nhằm hỗ trợ bạn trong quá trình lựa chọn.

Đối với nhu cầu chặn đơn giản ở cấp quốc gia, hãy bắt đầu với tính năng geo-restriction tích hợp sẵn của CloudFront hoặc geolocation routing của Route 53 — cả hai đều có chi phí thấp và cấu hình tối thiểu. Khi bạn cần khả năng lọc nhận biết ứng dụng với kiểm soát theo URL cụ thể, các rule geo-match của AWS WAF hoặc CloudFront edge functions sẽ mang lại sự linh hoạt cao hơn. Đối với bảo vệ ở tầng mạng, vượt ra ngoài lưu lượng web, AWS Network Firewall là giải pháp duy nhất hỗ trợ kiểm tra hai chiều trên tất cả các protocol và port.

Phần lớn các môi trường production sẽ hưởng lợi từ việc kết hợp nhiều dịch vụ với nhau. Ví dụ, bạn có thể sử dụng Route 53 để chặn lưu lượng ngay ở tầng DNS, CloudFront geo-restriction tích hợp sẵn làm lớp lọc thứ hai, và AWS WAF cho các rule chi tiết theo path — từ đó tạo nên một kiến trúc phòng thủ nhiều lớp, xử lý các mối đe dọa ở nhiều cấp độ khác nhau.

Bằng cách triển khai giới hạn địa lý với các dịch vụ AWS, bạn có thể:

• Giảm bề mặt tấn công bằng cách chặn lưu lượng từ các khu vực rủi ro cao trước khi chúng tới được ứng dụng
• Giảm chi phí hạ tầng bằng cách lọc sớm lưu lượng không mong muốn, từ đó giảm chi phí compute, băng thông và logging
• Tăng cường trạng thái tuân thủ bằng cách áp dụng các chính sách truy cập theo địa lý theo yêu cầu của các khung pháp lý như GDPR hoặc yêu cầu lưu trú dữ liệu
• Nâng cao hiệu quả của đội ngũ bảo mật bằng cách giảm nhiễu cảnh báo và cho phép tập trung vào các mối đe dọa hợp pháp
• Cải thiện hiệu năng ứng dụng bằng cách giảm tải không cần thiết lên các origin server

Hãy bắt đầu với giải pháp đơn giản nhất đáp ứng yêu cầu của bạn, và dần bổ sung thêm độ phức tạp khi nhu cầu giới hạn địa lý phát triển.

Bắt đầu ngay hôm nay bằng cách khám phá tài liệu geo-restriction của CloudFront, điều kiện geo-match của WAF, tài liệu tham chiếu rule của Network Firewall và hướng dẫn geolocation routing của Route 53.

Tác giả

Rahi Patel

Rahi Patel là Startups Technical Account Manager tại AWS, chuyên sâu về Networking. Anh thiết kế các giải pháp mạng cloud nhằm tối ưu hiệu năng trên các triển khai AWS toàn cầu. Trước đây, anh từng là Network Engineer tại Cisco Meraki và sở hữu bằng Thạc sĩ Kỹ thuật từ San Jose State University. Ngoài công việc, anh yêu thích tennis và pickleball.

Anvesh Koganti

Anvesh Koganti là Solutions Architect tại AWS, chuyên sâu về Networking. Anh tập trung hỗ trợ khách hàng xây dựng các kiến trúc mạng có khả năng mở rộng cao và độ bền vững tốt trên AWS. Ngoài công việc, Anvesh đam mê công nghệ tiêu dùng và thường nghe podcast về công nghệ và kinh doanh. Khi rời xa thế giới số, anh dành thời gian cho các hoạt động ngoài trời như đi bộ đường dài và đạp xe.