The Incident That Started This Post

A recent Reddit thread described a simple yet painful story:

A small project suddenly received 130 million requests on its CloudFront distribution — resulting in a $195 bill in just a few days.

The intent wasn’t to take the service offline; it was to drain the wallet. This is what’s now known as a Denial-of-Wallet attack — and for hobby projects or early-stage startups, it can burn through your AWS credits overnight.

Let’s explore how to defend against such high-volume threats without paying for Shield Advanced or enterprise firewalls.

Understanding the Real Risk

The cloud’s biggest strength pay-per-use is also its greatest vulnerability.

• In a traditional DDoS, attackers try to crash your server.
• In a cost-based attack, they aim to make you pay for every request.

For CloudFront and similar services, that means:

• Requests → Charged per 10,000 or million
• Data transfer out → Charged per GB
• WAF checks → Charged per million evaluations

Even with AWS Shield Standard (which you get free), this kind of cost-escalation remains your responsibility.

The Smart Strategy: Layered, Cost-Aware Defense

To stay resilient, small teams and indie developers need to adopt a layered security posture — focusing as much on budget control as traffic defense.

Here’s how to structure it:

1. Strengthen the Edge

CloudFront Caching Policies

• Set long TTLs for static assets (Cache-Control: max-age=86400 or higher).
• Minimize cache bypasses: only vary by headers or query params when truly needed.
• Block direct access to your origin using Origin Access Control (OAC) or custom headers.

Geo-Restrictions

If you only serve India or US, block or challenge traffic from other regions. Reducing the audience reduces the attack surface.

2. Add a WAF (and Configure It Right)

Attach AWS WAF to your CloudFront distribution and apply:

• Rate-based rule: e.g., limit to 1000 requests per 5 minutes per IP.
• Geo-block rule: exclude countries irrelevant to your user base.
• Bot Control / Managed Rules: block known malicious agents.

⚠️ Be mindful: WAF itself costs $0.60 per million requests inspected — so during an attack, you still pay for what’s filtered.

If you want extra savings, deploy WAF only on high-risk endpoints like /api/, /login, or /checkout.

3. Monitor and Alert Early

Use CloudWatch and AWS Budgets to get notified before things spiral:

• CloudFront metrics: Requests, BytesDownloaded, 4xxErrorRate.
• Cost alarms: trigger at $1, $5, $10, $25 thresholds.
• Anomaly detection for request volume: “>5× normal average in an hour.”

You can even automate a response:

• Budget alert → EventBridge Rule → Lambda Function → disable CloudFront or reroute DNS via Route 53.
• Another possible solution, “Repoint Route 53 away from CloudFront when the budget crosses a limit — it’s a cheap kill switch.”

4. Consider a Backup Layer

If your AWS setup is overwhelmed:

• Temporarily move DNS to Cloudflare Free Plan, this requires planning in advance.
• Enable “Under Attack Mode”. - this requires automation but simple to do.
• Route back to AWS once the surge stabilizes.

Cloudflare and AWS pair well for hybrid setups — AWS for origin and durability, Cloudflare for aggressive front-end filtering.

5. Automate Cost-Protection

Budget protection is your final safety net.

Set up an AWS Budget Action:

• Trigger when forecasted spend > $20.
• Action:
  • Disable CloudFront distribution
  • Send SNS alert
  • Repoint Route 53 to a static S3 “maintenance” page

Add a secondary failsafe:

• Lambda script to monitor CloudFront metrics hourly.
• If requests > X or data transfer > Y, trigger “maintenance mode” switch.

This combination prevents one night of malicious requests from wiping your wallet.

Example: Budget-Based Cutoff Flow

CloudWatch Metric → Alarm (High Requests)
           ↓
AWS Budgets → Forecast Exceeds $20
           ↓
EventBridge Rule → Trigger Lambda
           ↓
Lambda Action:
   - Disable CloudFront Distribution
   - Notify via SNS
   - Switch DNS to S3 Static Page

End result: traffic stops, the site stays “up,” and your bill freezes.

Common Pitfalls to Avoid

• Ignoring cost visibility: Many learn about attacks only after billing closes.
• Overly broad caching policies: Caching dynamic pages can break UX.
• Not testing kill switches: They must work within minutes, not hours.
• Relying solely on WAF: It’s effective but can still incur significant cost under volume.

Key Takeaways

• Prevent at the edge: Block and cache before it hits your origin.
• Rate-limit early: Cap IPs and regions that over-request.
• Automate cost brakes: Budget alerts + Lambda shutdowns.
• Have a fallback path: Cloudflare, static S3, or alternate CDN.
• Monitor continuously: Metrics, budgets, and logs are your radar.

Summary

Even with small workloads, you’re never “too small to attack”. Modern web traffic includes bots, scanners, and random crawlers — any of which can trigger millions of requests overnight.

The good news? With just a few AWS-native tools, you can stop those costs from ever going beyond your comfort zone.

Build with confidence — but build with cost limits baked in.

Related Reading

• AWS Blog: Protect Dynamic Web Apps with CloudFront & Route 53
• AWS WAF Rate-Based Rules Explained
• Reddit: 130 M Requests → $195 CloudFront Bill