Practical AWS WAF Rate Controls for DDoS Resilience

AWS WAF rate-based rules provide a practical way to limit abusive request bursts before they consume application capacity. They are useful for HTTP floods, credential-stuffing attempts, scraping, and poorly behaved clients, although they are only one layer of a broader DDoS protection design.

The rule counts requests from an aggregation key over a rolling five-minute period. When a source exceeds the configured limit, AWS WAF can block, challenge, or count subsequent requests. The service is commonly attached to Amazon CloudFront, an Application Load Balancer, Amazon API Gateway, or an AppSync API.

For Australian workloads, deployment details matter. A Sydney or Melbourne application may serve customers nationwide, while CloudFront distributes traffic through edge locations closer to users in Brisbane, Perth, Adelaide, and other cities. IP addresses in WAF logs may also be personal information under the Privacy Act 1988, so access, retention, and cross-border log handling should be reviewed.

Select The Right AWS WAF Attachment Point

Attach AWS WAF as close as practical to the public entry point. CloudFront is usually the strongest option for internet-facing websites because filtering occurs at the edge before requests reach an origin in ap-southeast-2 or another AWS Region. It also provides a consistent policy for users across Australia and overseas.

For regional services, associate a Web ACL with an Application Load Balancer, API Gateway REST API, or AppSync API. A CloudFront Web ACL must be managed in us-east-1, even when the origin is in Sydney. Regional Web ACLs must be created in the Region hosting the protected resource.

AWS Shield Standard automatically protects supported AWS services against common network and transport-layer attacks. AWS WAF handles application-layer request filtering, while Shield Advanced can add enhanced detection, response support, and cost protection for eligible architectures.

Design A Rate-Based Rule

Start by identifying the resource that is expensive or easy to abuse. Login, password reset, search, checkout, token issuance, and report-generation paths generally need tighter controls than static assets. A single global limit can protect the site broadly, but path-specific rules usually produce fewer false positives.

The default aggregation key is the source IP address. This works well for many public websites, but it can penalise users behind carrier-grade NAT, corporate proxies, university networks, or shared mobile connections. Australia’s mobile and regional broadband markets make this relevant, particularly when many users appear behind a small number of public addresses.

If a trusted proxy or CDN supplies the original client address, configure forwarded-IP handling carefully. Only trust a header that your architecture controls or validates. An attacker can spoof an arbitrary header when traffic reaches the load balancer directly, making the rule ineffective or causing innocent addresses to be blocked.

Create The Web ACL And Rule

In the AWS WAF console, create a Web ACL for the correct scope, select the protected resource, and add a rate-based rule. Set the evaluation window and request limit, then define the rule action. Count mode is useful during an observation period; block is appropriate after traffic patterns and legitimate peak rates are understood.

Use a scope-down statement to target a route, HTTP method, host, query pattern, or other condition. For example, a rule can rate-limit POST requests to /login without restricting normal GET requests for product pages. Combine the rate rule with managed rule groups, IP reputation rules, and explicit allow rules where required.

The same configuration can be managed with AWS CloudFormation, Terraform, or AWS CDK. Infrastructure as code makes policy changes reviewable and repeatable across Sydney, Melbourne, and disaster-recovery environments. Keep Web ACL names, rule priorities, thresholds, and tags consistent so operators can identify the correct policy quickly.

Set Thresholds Based On Traffic

A rate threshold is not a universal DDoS number. Establish a baseline from CloudFront, ALB, API Gateway, and application metrics. Look at requests per source, endpoint, response codes, login failures, and normal campaign peaks. Australian retailers may see sharp increases during local sales events, end-of-financial-year promotions, or evening shopping periods.

Traffic pattern	Starting approach	Action after testing
Public content pages	Higher per-IP limit	Block only sustained excess
Login and token endpoints	Low, path-specific limit	Challenge or block repeated bursts
API clients with authentication	Key by trusted identity where possible	Exempt approved integrations
Shared office or mobile networks	Avoid an aggressive IP limit	Use scope-down rules and challenge
Internal or partner traffic	Explicit allow or separate policy	Monitor independently

AWS WAF rate-based rules are approximate controls rather than precise counters. Enforcement can take time, and distributed attacks may stay below an individual-IP threshold. Use CloudWatch metrics and sampled requests to confirm whether the rule is matching the intended traffic.

For a high-volume attack, combine WAF with CloudFront caching, origin protection, autoscaling, restrictive security groups, Shield features, and application-level throttling. WAF should reduce harmful HTTP traffic, not serve as a replacement for capacity planning or resilient architecture.

Control Legitimate And Malicious Requests

Blocking every request over the threshold can disrupt customers sharing an address. A challenge action gives browsers an opportunity to prove they are genuine, while CAPTCHA introduces a more visible human verification step. These actions are generally better suited to interactive web traffic than machine-to-machine APIs.

Create narrowly scoped exceptions for payment providers, monitoring systems, trusted partners, and corporate egress addresses. Avoid broad allow rules based only on user-agent strings, as those are easy to forge. For APIs, use authentication, quotas, API keys, and per-client throttling alongside WAF.

Consider Australian privacy and compliance requirements when storing logs. WAF logs can contain IP addresses, paths, query strings, and headers. Limit access through IAM, encrypt log destinations, define retention periods, and assess whether data is sent to an overseas service or account.

Monitor, Test, And Troubleshoot

Send AWS WAF logs to Amazon CloudWatch Logs, Amazon Kinesis Data Firehose, or Amazon Simple Storage Service according to operational and retention needs. Useful fields include terminatingRuleId, action, source address, URI, country, and rate-based rule labels. Correlate these records with ALB access logs, CloudFront logs, and application events.

Begin with Count mode and test from normal broadband, mobile networks, office egress points, and automated clients. Confirm that the intended rule matches the intended path and that direct access to an origin cannot bypass CloudFront controls. In a Melbourne or Perth office, shared egress behaviour may look very different from a home connection in Sydney.

Watch for elevated 403 responses, increased challenge failures, origin latency, and sudden changes in unique source addresses. If legitimate users are blocked, reduce the rule scope, raise the threshold, change the aggregation strategy, or create a narrowly defined exception. If an attack distributes requests across many addresses, add behavioural rules and upstream protections.

Operational Recommendations For Australian Teams

Use the following practices when putting rate-based DDoS controls into production:

• Attach WAF to CloudFront where edge filtering and centralised protection are appropriate.
• Keep CloudFront Web ACL changes in us-east-1 and regional policies beside their AWS resources.
• Start in Count mode, measure real traffic, and document the reason for every threshold.
• Protect login, password reset, search, and expensive API routes with separate scoped rules.
• Test shared mobile, corporate, and regional broadband networks before enabling aggressive blocking.
• Store WAF logs securely with controlled access and a documented retention period.
• Combine WAF with Shield, caching, origin restrictions, authentication, and application throttling.

Treat the configuration as an operational control rather than a one-time setting. Review thresholds after product launches, advertising campaigns, seasonal demand, and changes to CloudFront or load-balancer architecture. A measured policy gives Australian users reliable access while making automated abuse more expensive and easier to investigate.