So after three years of faithfully writing checks to AWS for Shield Advanced, I've finally pulled the plug. The catalyst was, predictably, another opaque line item on the bill labeled "Data Transfer Out For DDoS Mitigation" that required a support ticket and three days of back-and-forth just to understand which layer-7 event from three weeks prior it was even referencing. The final straw wasn't the cost itself, but the sheer operational overhead of *attributing* the cost.
I moved to one of the larger "bundled edge" vendors (you can probably guess the usual suspects, I'm not naming names because this isn't a vendor showcase) that bakes DDoS, WAF, bot management, and CDN into a single platform and per-request pricing model. The promise was simplification. The reality, as always, is more nuanced.
The immediate, undeniable win is observability. Instead of CloudWatch metrics that tell me "something happened, good luck," I now get a unified log stream where a single HTTP request ID can be traced through the WAF rule, rate-limiting stage, bot score, and DDoS mitigation action. This alone has cut our false-positive investigation time from hours to minutes. For example, I can actually see *why* a request was challenged:
```json
{
"request_id": "xyz123",
"action": "challenge",
"threat_categories": ["http_anomaly"],
"bot_score": 25,
"waf_rule_id": "100004",
"rate_limit_name": "api_search",
"mitigation_bandwidth_gbps": 0,
"request_headers": {
"user-agent": "SomeScraper/1.0"
}
}
```
Contrast this with Shield Advanced's "DDoS event started, DDoS event ended" alerts and a bill full of mysterious data transfer spikes. The integrated view is superior for any team that cares about root cause, not just attack volume.
However, the trade-off is in the granularity of control. AWS's WAFv2, for all its clunkiness, allows for incredibly specific, programmatic rules tied directly to my application's logic (like rate-limiting based on a custom header from my auth service). The bundled vendor's rules engine feels more like a menu of powerful, but somewhat generic, options. I've had to adapt my protection strategy to fit their primitives, which has meant accepting a slightly broader stroke on some mitigations.
Financially, it's a shift from "surprise capacity fees" to "predictable per-request costs." My bill now scales linearly with legitimate traffic, even during an attack, which is a concept that seems alien after AWS's model of charging you extra for the "privilege" of being attacked. For a sustained, high-volume layer-7 attack, I suspect the bundled vendor could become more expensive, but for the typical barrage of script kiddies and botnets, the cost predictability is a relief.
The biggest lesson? Shield Advanced feels like an infrastructure-level product bolted onto an application world. It's great if your threat model is primarily volumetric L3/L4 and you never want to leave the AWS console. But if you need to understand *what* is being attacked, *why* it was blocked, and have a hope of tuning protections without a PhD in AWS billing, an integrated edge platform is a starkly more operational model. Just be prepared to cede some fine-grained control for that clarity.
-- Cam
Trust but verify.
That point about unified logging is huge. I've been wrestling with CloudWatch for incident forensics, and the disconnect between WAF logs, ALB logs, and Shield metrics is a real time sink.
How steep was the learning curve for their query language or dashboard? I'm always wary that a slick new interface just hides different complexity.
And do you find the per-request pricing predictable, or does it feel like you're trading one kind of billing opacity for another?
Learning by breaking