Single IP generating massive CloudFront/WAF costs - Please block upstream!

This is a well-known pain point — you're correct that there is currently no AWS-native mechanism to drop traffic at the CloudFront edge before it incurs request charges. Every HTTP/HTTPS request that reaches a CloudFront edge location is a billable event, regardless of whether it's blocked by WAF, a CloudFront Function, or any other rule. The same applies to WAF — each request evaluated counts toward your WAF bill.

That said, here are the practical options to mitigate the cost impact:

1. AWS Shield Advanced — DDoS Cost Protection (strongest option)

If this traffic pattern qualifies as a DDoS attack (sustained millions of requests/hour from a single source for days certainly looks like one), AWS Shield Advanced (https://aws.amazon.com/shield/pricing/) provides DDoS cost protection — you can request credits for CloudFront request charges and data transfer caused by the attack.

Prerequisites to be eligible for credits:

• Shield Advanced protection must be enabled on the CloudFront distribution before the attack
• A WAF web ACL with a rate-based rule in Block mode must be associated with the distribution
• You must follow AWS Best Practices for DDoS Resiliency (https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)

To request a credit: open a billing case via AWS Support Center with "DDoS Concession" in the subject line within 15 days of the billing month. The Shield Response Team (SRT) validates the attack and issues credits for qualifying traffic. (Full process - https://docs.aws.amazon.com/waf/latest/developerguide/ddos-request-service-credit.html)

Shield Advanced costs $3,000/month with a 1-year commitment, so evaluate whether the ongoing attack cost justifies it. It also includes the SRT for hands-on incident response and up to 50 billion requests/month to WAF-protected resources at no additional WAF charge.

2. WAF rate-based rules (you likely already have this, but verify)

Ensure you have a rate-based rule (https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-waf-rate-based-rules.html) in Block mode — not just an IP-match block rule. Rate-based rules are required for Shield Advanced cost protection eligibility, and they automatically manage the block list. This won't reduce your bill on its own (blocked requests are still counted), but it's a prerequisite for the credit path above.

3. Contact AWS Support / your account team

Open a support case describing the situation. While AWS does not offer a general-purpose "block this IP globally across CloudFront" mechanism, the AWS abuse team and service teams have internal tooling for extreme cases. Provide:

• The source IP (120.85.92.136)
• Your CloudFront distribution ID
• WAF/CloudFront logs showing the sustained volume
• The duration and cost impact

This won't guarantee an upstream block, but it puts the issue on record and may result in action for clearly abusive single-IP patterns.

4. Rotate or change your CloudFront endpoint (workaround)

If the attacker is hitting a specific distribution domain name (e.g., d111111abcdef8.cloudfront.net) or a custom domain, and you can tolerate a brief change:

• Create a new CloudFront distribution with the same origin configuration
• Update your DNS to point to the new distribution
• Delete or disable the old distribution

A misconfigured/abandoned client (as you suspect) won't follow the DNS change. This is a workaround, not a solution — a determined attacker would simply follow the new endpoint.

5. Move the endpoint behind an ALB with Shield Advanced (architecture change)

For long-term resilience, placing an Application Load Balancer in front of your origin and protecting both the ALB and CloudFront distribution with Shield Advanced gives you layered DDoS cost protection and access to the SRT.

---

To directly answer your questions:

│ Is there any way within AWS to block an IP at the edge before it incurs CloudFront/WAF request charges?

No. As of today, there is no way to drop traffic before CloudFront counts it as a request. WAF rules, CloudFront Functions, and geo-restrictions all execute after the request is received and counted.

│ Is there any mechanism to have AWS block clearly abusive IPs globally across CloudFront?

There is no self-service mechanism for this. Contact AWS Support (or your TAM if you have Enterprise Support) to report the abusive IP with evidence. AWS has internal processes for extreme abuse cases, but there is no public SLA or guarantee for upstream blocking.

│ From our perspective, this is not an application-level issue anymore.

You're right — and this is exactly the scenario Shield Advanced's DDoS cost protection was designed for. If the cost impact is significant, Shield Advanced is the formal AWS answer to "someone else is generating my bill."

• Change your distribution to use a CloudFront fixed-rate pricing plan (FRP). Requests blocked by AWS WAF never count against your usage allowance. Follow the instructions under Subscribe an existing distribution to a pricing plan.

Note: that even without a FRP, CloudFront never charges for requests that are blocked by AWS WAF (however it will charge for requests blocked by a CloudFront function).

• Report abusive activity to abuse@chinaunicom.cn and also to AWS abuse - it's not quite clear whether the IP you mention is part of AWS or not. You will need to provide evidence in the form of logs.

• Raise a billing case and ask for billing forgiveness, once you've switched onto a FRP. There is no guarantee this will be given, but you can ask.