AWS WAF not able to filter strange requests

The IP address in that log entry doesn't belong to AWS, so it isn't a CloudFront edge server that's sending the request. The connections are reaching your Nginx server directly, without going through CloudFront and therefore also not getting processed by WAF.

First, open the VPC console in the region where your Nginx server is hosted. Select "Managed prefix lists" from the left, and find the prefix list with the name com.amazonaws.global.cloudfront.origin-facing. This list contains all the IP ranges that CloudFront edge servers use to connect to origin resources, such as your web server. From the data of the prefix list, copy its "prefix list ID". For example, for the us-east-1 region, it would be pl-3b927c52.

From the security group of your web server, remove rules that allow connections inbound from 0.0.0.0/0 and/or ::/0, which denote the entire internet over IPv4 or additionally over IPv6. In its place, add a new rule that permits inbound tcp/443 (or tcp/80 if you're using unencrypted connections between CloudFront and Nginx) from the prefix list with the ID that you looked up. This way, only CloudFront servers protected by WAF will be able to reach Nginx, and all direct connections from the internet to the server will be dropped by the security group.

The issue you're experiencing is related to how AWS WAF processes HTTP requests. AWS WAF is designed to filter and block malicious web requests, but it primarily works with properly formed HTTP requests that follow standard protocols.

The logs you've shared show requests with binary/hexadecimal content that don't follow standard HTTP request formats (no proper method, URI, or protocol). These malformed requests are bypassing WAF inspection because they don't meet the basic criteria for AWS WAF to process them properly.

To address this type of attack, consider these approaches:

1. Configure your NGINX server to quickly reject these malformed requests with minimal resource consumption. This can be done through NGINX configuration optimizations.

2. Implement rate-based rules in AWS WAF to limit the number of requests from specific IP addresses. While this won't block the malformed requests directly, it can help mitigate the impact of the DDoS attack by limiting traffic from the attacking IPs.

3. Use AWS Shield Advanced for enhanced DDoS protection capabilities beyond what standard WAF offers.

4. Consider implementing geo-restrictions in AWS WAF or CloudFront if the attacks are coming from specific geographic regions where you don't expect legitimate traffic.

5. Enable AWS WAF logging to gather more information about the traffic patterns, which might help identify additional characteristics you could use for filtering.

6. Add custom rules in AWS WAF that block based on IP addresses identified in your NGINX logs as sources of these malformed requests.

Remember that AWS WAF works best as part of a layered security approach, especially for handling unusual attack patterns like the one you're experiencing.
Sources
AWS WAF Rules not working | AWS re:Post
Detect and filter malicious web requests (BP1, BP2) - AWS Best Practices for DDoS Resiliency
AWS WAF - AWS Best Practices for DDoS Resiliency

@mofaized-AWS The requests aren't going through WAF when Nginx's log shows them arriving directly from a random IP address in Korea. WAF settings will have no effect on requests not going anywhere near it.

Furthermore, even if WAF weren't used or regardless of how it was configured, CloudFront wouldn't send requests to an origin at all without one of the HTTP methods that CloudFront supports, which are GET, HEAD, OPTIONS, PUT, POST, PATCH, and DELETE (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesCacheBehavior.html#DownloadDistValuesAllowedHTTPMethods).

If these requests are actually passing through your WAF, why not simply create a rule within your WebACL that blocks traffic without an expect HTTP method? Something like: