Tóm tắt: “100 requests/phút” trên Cloudflare và “100 requests/phút” trên AWS WAF không nên được hiểu là hai cơ chế tương đương. Ý nghĩa thực tế phụ thuộc vào cách request được nhóm, traffic nào làm counter tăng, counter được duy trì ở đâu, cửa sổ thời gian được đánh giá thế nào và action được thực thi ra sao.
Phạm vi nghiên cứu: bài Security Lab này không phải first-party benchmark của SecureWebOps. Phân tích dựa trên tài liệu triển khai hiện hành của Cloudflare, AWS WAF và RFC 6585; phần “Đánh giá của SecureWebOps” là synthesis kỹ thuật từ các nguồn đó. Chúng tôi không tuyên bố đã đo latency, block rate hay false-positive rate trên hạ tầng riêng.
Technical question: cùng 100 requests/phút có thực sự giống nhau?
Nếu chỉ nhìn dashboard, một rule “100 requests trong 60 giây” có vẻ rất rõ ràng. Nhưng con số này mới chỉ trả lời một phần nhỏ của policy. Trước khi so sánh hai nền tảng, cần trả lời ít nhất năm câu hỏi:
- Identity / aggregation: request được nhóm theo IP, API key, cookie, method hay tổ hợp nào?
- Counted traffic: request nào thực sự làm counter tăng?
- Counter scope: counter được duy trì ở phạm vi nào?
- Evaluation window: hệ thống nhìn lại khoảng thời gian nào khi đánh giá rate?
- Enforcement: khi vượt ngưỡng, action được áp dụng theo cách nào và trong bao lâu?
Nếu bạn cần phần nền tảng trước khi đọc bài này, xem Rate Limiting là gì?. Security Lab này không lặp lại định nghĩa cơ bản mà tập trung vào semantics triển khai của hai vendor.
Nguồn và cách đọc nguồn trong bài này
Phần lõi sử dụng tài liệu chính thức của Cloudflare và AWS vì câu hỏi chính là “vendor đang triển khai và mô tả cơ chế của chính họ như thế nào?”. RFC 6585 được dùng để tách ý nghĩa của HTTP 429 khỏi thuật toán rate limiting phía sau.
| Nguồn | Vai trò trong phân tích |
|---|---|
| Cloudflare – How Cloudflare determines the request rate | Characteristics, counter model và phạm vi counter |
| Cloudflare – Rate limiting parameters | Matching expression, counting expression, period, mitigation timeout và action behavior |
| AWS – RateBasedStatement | Aggregation keys, evaluation window, scope-down và tần suất đánh giá |
| AWS – Rate-based rule caveats | Rate estimation, độ trễ, exact-threshold limitation và counter reset |
| RFC 6585 | Ý nghĩa của 429 Too Many Requests và những gì RFC không quy định |
Đây là implementation documentation, không phải một benchmark độc lập giữa hai vendor. Vì vậy bài này không kết luận nền tảng nào “nhanh hơn” hay “chính xác hơn”.
Cloudflare thực sự đếm request như thế nào?
Characteristics quyết định “ai” có counter riêng
Cloudflare duy trì counter theo từng tổ hợp giá trị của các characteristics được cấu hình. Ví dụ nếu rule dùng IP và header x-api-key, các combination khác nhau sẽ có counter khác nhau. Tài liệu Cloudflare cũng cho biết cf.colo.id được đưa vào characteristics khi xác định request rate, vì vậy counter của rate limiting không nên được hiểu là một global counter duy nhất trên toàn bộ mạng Cloudflare.
Hệ quả là một threshold nhìn giống “100 requests/phút” không tự trả lời được câu hỏi 100 requests của ai. Với một policy per-IP, hai client có hai counter riêng. Với một policy dùng thêm API key hoặc field khác, cardinality và cách traffic được gom lại thay đổi tiếp.
Matching expression và counting expression có thể khác nhau
Cloudflare tách rule expression dùng để xác định phạm vi rule với counting expression dùng để quyết định khi nào counter tăng. Mặc định counting expression giống rule expression, nhưng khi dùng custom counting expression hai lớp này có thể khác nhau.
Cloudflare đưa ra một lưu ý rất quan trọng: nếu bạn muốn chỉ đếm response 403 của /api/ nhưng counting expression chỉ ghi http.response.code eq 403, các response 403 ở URL khác cũng có thể làm counter tăng. Vì vậy khi audit policy phải hỏi riêng:
- Request nào khiến rule được xem xét?
- Request nào làm counter tăng?
- Request nào bị action khi threshold bị vượt?
Ba tập request này không mặc định là một tập duy nhất.
Period không phải mitigation timeout
Cloudflare phân biệt period dùng để đánh giá request rate với mitigation timeout – khoảng thời gian action tiếp tục được áp dụng sau khi rate đạt ngưỡng. Tùy plan và action, hệ thống có thể áp action trong cả mitigation period hoặc throttle các request vượt mức cấu hình.
Tài liệu hiện hành của Cloudflare cũng cảnh báo rate limiting không được thiết kế để bảo đảm một số lượng request chính xác tuyệt đối sẽ tới origin. Có thể có độ trễ vài giây giữa việc quan sát request và cập nhật rate counter, nên một số request vượt ngưỡng vẫn có thể tới origin trước khi mitigation được thực thi.
Counter per-data-center là một limitation vận hành cần hiểu
Cloudflare nói rõ rate limiting counters được duy trì theo data center. Traffic phân tán qua nhiều data center có thể giữ rate của từng counter dưới threshold dù tổng traffic quan sát ở phạm vi rộng hơn lớn hơn con số đó. Đây là lý do không nên biến một edge rate-limit threshold thành giả định “global quota”.
Cloudflare còn mô tả fail-open behavior trong tình huống hạ tầng rate limiting bị quá tải: hệ thống có thể bỏ qua một số counter update/enforcement thay vì chặn nhầm legitimate traffic. Đây là limitation quan trọng nếu threat model yêu cầu enforcement tuyệt đối.
AWS WAF thực sự đánh giá rate như thế nào?
Aggregation instance quyết định counter logic
AWS WAF sử dụng khái niệm aggregation instance. Nếu chỉ aggregate theo IP, mỗi IP là một instance riêng. Nếu custom keys gồm HTTP method và một query argument, mỗi combination method + value sẽ có instance riêng. AWS hiện cho phép tối đa năm custom aggregation keys trong một rate-based statement.
ScopeDownStatement có thể thu hẹp traffic được theo dõi và rate-limit. Điều này tương tự về mục đích với việc scoping traffic ở nền tảng khác, nhưng semantics cụ thể phải đọc theo tài liệu AWS thay vì giả định hai vendor hoạt động giống nhau.
Evaluation window là khoảng nhìn lại, không phải lịch chạy theo batch
AWS WAF hiện hỗ trợ evaluation window 60, 120, 300 hoặc 600 giây; mặc định là 300 giây. AWS nhấn mạnh window chỉ xác định hệ thống nhìn lại bao xa khi tính request count. Nó không xác định tần suất hệ thống kiểm tra rate.
API documentation hiện ghi AWS WAF kiểm tra rate khoảng mỗi 10 giây. Điều đó không đồng nghĩa action luôn bắt đầu trong tối đa 10 giây, vì chính AWS còn mô tả rate estimation và propagation delay ở tài liệu caveats.
AWS công khai rằng đây không phải precise request-rate limiter
Đây là điểm quan trọng nhất khi đọc AWS WAF. AWS nói rate limiting của WAF được thiết kế để kiểm soát request rate cao và bảo vệ availability, không nhằm precise request-rate limiting. Hệ thống ước lượng current request rate bằng thuật toán ưu tiên recent requests hơn, và AWS không đảm bảo exact match với threshold đã cấu hình.
Vì vậy diễn giải kiểu “limit 100 requests trong 5 phút thì request thứ 101 chắc chắn bị block ngay” không được tài liệu AWS hỗ trợ.
Detection và release có độ trễ
AWS cho biết request có thể vượt rate trong một khoảng thời gian trước khi hệ thống phát hiện và áp dụng rate limiting. Ngược lại, sau khi traffic giảm, action cũng có thể tiếp tục một thời gian trước khi được dừng. AWS mô tả delay này thường dưới 30 giây, nhưng trong một số điều kiện có thể lâu hơn.
Con số này phải được đọc như documented behavior chứ không phải SLA đảm bảo cho mọi request.
Thay đổi cấu hình có thể reset rate counters
AWS ghi rõ khi thay các rate-limit settings của một rule đang hoạt động – gồm evaluation window, rate limit, aggregation settings, forwarded IP configuration hoặc scope of inspection – hệ thống reset rate-limiting counts. Việc này có thể làm rate limiting tạm dừng tối đa khoảng một phút.
Operational implication rất rõ: tuning rule trong lúc đang xảy ra attack không phải là một thao tác hoàn toàn stateless. Change plan cần tính đến counter reset, monitoring sau thay đổi và rollback.
Cloudflare vs AWS WAF: cùng threshold nhưng khác ở đâu?
| Dimension | Cloudflare | AWS WAF | Ý nghĩa vận hành |
|---|---|---|---|
| Identity / grouping | Characteristics | Aggregation keys / aggregation instance | “Ai” bị rate-limit phụ thuộc cách group request |
| Traffic được đếm | Rule expression + optional counting expression | Scope-down + aggregation model | Không nên chỉ nhìn threshold |
| Counter scope | Per data center theo tài liệu Cloudflare | Theo rate-based rule và aggregation instance | Không mặc định suy ra global quota |
| Window | Configured counting period | Look-back evaluation window | Cùng số giây chưa chắc cùng semantics |
| Exact threshold | Cloudflare nói không bảo đảm precise requests tới origin | AWS nói rõ rate là estimate, không guarantee exact match | Không dùng WAF threshold như transactional quota tuyệt đối |
| Enforcement | Action + mitigation timeout / throttling tùy cấu hình | Rate-based rule action sau khi rate được đánh giá | Counting và enforcement cần review riêng |
| Config change | Không suy diễn behavior ngoài tài liệu đã xác minh | Reset counters và có thể pause tới khoảng 1 phút | Change giữa incident có operational risk |
Vì sao HTTP 429 không cho biết thuật toán phía sau?
RFC 6585 định nghĩa 429 Too Many Requests là tín hiệu cho biết user đã gửi quá nhiều request trong một khoảng thời gian. Nhưng RFC đồng thời nói rõ specification không định nghĩa origin server phải nhận diện user như thế nào và cũng không định nghĩa cách server đếm request.
Một hệ thống có thể rate-limit theo resource, toàn server, tập hợp server, authentication credential hoặc stateful cookie. Vì vậy hai hệ thống cùng trả 429 không có nghĩa chúng đang dùng cùng identity model, cùng counter model hay cùng thuật toán.
Đánh giá của SecureWebOps
1. Threshold là parameter, không phải toàn bộ policy
SecureWebOps không đánh giá một rate-limit policy chỉ bằng “N requests / T seconds”. Một policy chỉ có ý nghĩa khi biết đầy đủ:
Who → What counts → Where the counter lives → Over what window → What action happens
Đây là framework đánh giá, không phải thuật ngữ do Cloudflare hay AWS định nghĩa.
2. Câu hỏi đầu tiên nên là “đang rate-limit ai?”, không phải “bao nhiêu request?”
Per-IP, IP + method, API key, cookie hay header có thể tạo behavior rất khác dù threshold giống hệt nhau. Shared NAT có thể khiến nhiều user hợp lệ dùng chung một IP; API key có thể đại diện một integration; một header thiếu hoặc bị rewrite có thể làm traffic rơi vào counter khác với dự kiến.
Do đó threshold chỉ nên được chọn sau khi identity model đã rõ.
3. Counting và enforcement phải được audit tách biệt
Cloudflare cho phép counting expression khác rule/mitigation expression. AWS cũng tách việc xác định traffic được theo dõi qua scope/aggregation khỏi action của rate-based rule. Vì vậy một rule có thể “đếm hợp lý” nhưng “action quá rộng”, hoặc ngược lại.
Đây cũng là lý do các bài hướng dẫn triển khai nên dựa trên baseline và critical flow thay vì copy threshold. Với API hoặc endpoint nhạy cảm, xem thêm cách bảo vệ API và endpoint bằng Rate Limiting.
4. WAF rate limiting phù hợp abuse control hơn hard business quota
Từ limitations mà cả hai vendor công bố, SecureWebOps đánh giá WAF rate limiting phù hợp với abuse control, availability protection, brute-force suppression, bot mitigation và request-rate anomaly control. Nếu ứng dụng cần quota nghiệp vụ kiểu “account này tuyệt đối không được vượt X API calls”, enforcement gần application/API layer thường cần được xem xét như một lớp riêng.
Đây là technical inference của SecureWebOps từ documented limitations, không phải lời khẳng định trực tiếp của Cloudflare hay AWS.
5. Copy threshold giữa vendor hoặc giữa website là anti-pattern
Một con số phù hợp cho login endpoint của site A không tự động phù hợp cho API của site B. Cần ít nhất xem legitimate peak rate, burst behavior, authenticated/anonymous traffic, shared NAT, bot pattern, endpoint cost và retry behavior.
Cloudflare cũng cung cấp guidance để phân tích request rate trước khi chọn threshold. Điều này củng cố nguyên tắc: threshold nên xuất phát từ traffic thực, không phải “best-practice number” cố định.
6. Tuning giữa incident phải có change control
Đặc biệt trên AWS WAF, thay đổi rate settings có thể reset counters và tạm dừng enforcement. Một runbook tốt nên có snapshot cấu hình hiện tại, expected effect, telemetry cần theo dõi, fallback/rollback criteria và thời điểm đánh giá lại sau change.
Để xem một tình huống vận hành thay vì technical evaluation, tham khảo Case Study: Bot Traffic được kiểm soát bằng Rate Limiting.
5 sai lầm thường gặp khi review rate-limit policy
- Chỉ nhìn threshold: bỏ qua identity, scope, counting expression và action behavior.
- Giả định counter là global: đặc biệt nguy hiểm khi edge platform duy trì counter theo phạm vi phân tán.
- Đồng nhất HTTP 429 với thuật toán: 429 là response signal, không mô tả counter implementation.
- Giả định threshold là exact quota: trái với limitations mà cả Cloudflare và AWS công bố.
- Copy cùng threshold sang vendor khác: con số giống nhau nhưng semantics có thể khác.
Khi nào kết luận trong bài này không áp dụng?
- Bài không benchmark latency, throughput, false-positive rate hoặc block accuracy của hai vendor.
- Bài không kết luận Cloudflare tốt hơn AWS WAF hoặc ngược lại.
- Availability của fields, periods và action behavior trên Cloudflare phụ thuộc plan; cần kiểm tra tài liệu hiện hành trước khi triển khai.
- AWS và Cloudflare có thể thay đổi implementation/documentation theo thời gian; operational review cần kiểm tra lại version hiện hành.
- Kết luận không tự động áp dụng cho Nginx, Envoy, API gateway hoặc application-level rate limiter.
- Không nên dùng các ví dụ threshold trong vendor docs như universal recommendation cho WordPress hoặc mọi website.
Kết luận
“100 requests/phút” chỉ là một con số. Khả năng bảo vệ thực tế phụ thuộc vào cách request được nhóm, traffic nào làm counter tăng, counter được duy trì ở phạm vi nào, window được đánh giá ra sao và action được thực thi thế nào.
Cloudflare và AWS WAF đều cung cấp rate limiting mạnh cho các bài toán abuse và availability, nhưng documented semantics cho thấy không nên coi threshold giống nhau là policy tương đương. Khi audit hoặc thiết kế rate limiting, SecureWebOps ưu tiên đọc toàn bộ counting model và enforcement behavior thay vì chỉ so sánh con số threshold.
Nếu mục tiêu của bạn là thiết kế kiến trúc WAF/rate limit cho website production, xem thêm WAF là gì và giới hạn bảo vệ của WAF hoặc dịch vụ WAF & DDoS Protection.