WAF rate based rule with threshold for the identical requests?

With WAF you can define the limit of the rate limit of when it kicks in and what the action is. https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-high-level-settings.html

You can block the request or trigger a CAPTCHA or Challange response ensuring that its a human making the request. https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-request-limiting.html

You can rate limit on specific URLs, so if the inital page thats being DDOS is the logon page https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-example-limit-login-page.html

If the application passes a header, you can limit on the missing header https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-example-limit-missing-header.html

You can setup WAF to run in Count mode while you tune the rules before applying another action.

If the attacks are originating in a reasonably small number of IP addresses, WAF's rate-limiting rules aggregated by source IP address are an effective countermeasure. In your design, you should consider that some URLs on your site are likely to be resource-intensive for your application to handle, while others may be enormously lightweight. For example on re:Post, processing a user logon or executing a full-text search could be relatively resource-intensive to handle, while the front page and the main questions page might be mostly constructed from cached data or simple DynamoDB queries, making them very lightweight by comparison.

When setting your rate limits, you should consider applying a very low limit, even near the recently introduced minimum of 10 requests per second, for requests like logons, full-text searches, and similar features that legitimate users wouldn't call at a high frequency but which would make for lucrative targets for attackers. For pages heavy in cached content and lightweight to construct, you could apply a higher limit.

Another aspect is that if (and only if) the application is mostly used by limited geographies, such as mainly from the US, India, South America, or Europe, or even more locally, a very powerful but cost-efficient defence mechanism is to aggregate requests from outside your primary target geographies and applying a rate limit to all requests originating outside them.

For example, a site mainly used by a European audience could rate-limit all requests from outside Europe to a manageable amount. A DDoS attack launched from bots outside Europe could render the site largely inaccessible from outside Europe, because legitimate clients in the US, for example, would hit the same rate limit as the attackers. However, the site could continue as per normal for the primary audience in Europe, because the container or server workloads wouldn't receive the bulk of the attack traffic coming from outside Europe.

You could further improve the effeciveness of the geo-rate-limiting by applying a different rate limit for the computationally intensive logon page or search result pages, as contemplated above, and the heavily cached, lightweight pages that can easily handle more load.

Finally, even for sites that are used by a broad, global audience, you can limit the hit from many DDoS attacks by applying similarly aggregated rate-limiting as above, but instead of basing it on geolocation, applying the aggregate limit to the providers of hosting/data centre services, anonymiser/VPN services, and the like, which typically originate very low volumes of end user traffic but can provide massive capacity for DDoS attacks launched by bad actors. There are AWS-managed WAF rule groups for identifying hosting providers (except AWS itself), VPN providers, and various networks known for originating bad traffic: https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html. One of the managed rule groups is AWSManagedIPDDoSList, which contains a constantly updated list of known origins of DDoS attacks. Note that its default action is set to "count", and you might want simply to block all traffic from AWSManagedIPDDoSList, rather than letting some of the likely attacks through a rate limit. You should place unconditional block rules before the rate limit rules, so that the limited aggregation capacity of a single WAF web ACL isn't wasted on blocked traffic.

The way aggregation is controlled is explained in this documentation article: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-aggregation-options.html.

For combining multiple countries or other origins, you have two options. One is to use the aggregation option of "count all" and to specify a scope-down statement that identifies the traffic to be rate-limited.

Another option that can be useful for more complex variations it first to apply rules with a "count" action to apply labels to them (or to allow managed rule groups to apply their built-in labels), and possibly further to derive custom labels if you want to match multiple source labels or to exclude certain traffic. After the labels are added, in a subsequent rule, apply a rate rate limit aggregated based on a "custom key" of the type "label namespace" for which you specify the custom label that has been applied to the traffic to be limited.