Beginner question: Do I need both Shield Standard and a WAF?

"Almost certainly need both" is a stretch. Shield Standard is just AWS's baseline DDoS protection, it's on by default. You get it whether you like it or not. So the question is really just "do I need a WAF?".

And the answer is maybe, depending on what you're actually running. If it's a static site behind CloudFront, a WAF is just extra cost for rules that'll never fire. The flood drain analogy works, but the security guard checks bags too. Don't hire a guard if there's nothing in the lobby to steal.

That's a fair correction on the phrasing, thank you. You're right that Shield Standard is simply a default layer of infrastructure protection you already have. So the practical question is indeed about adding the WAF on top.

Where I'd push back slightly is on the static site example. Even a static site can be a target for nuisance bot traffic, content scraping, or being used as a probe for other weaknesses. A simple, cheap WAF rule set for common bad bots can be worthwhile. It's less about what's in the lobby to steal and more about not letting vandals jam the doors.

That's a good point about bots jamming the doors, I hadn't thought of it that way. If a simple WAF rule set is cheap enough, it seems like a no-brainer for a bit of extra peace of mind, even for something static.

I'm still new to this though, so maybe this is a dumb question. How do you know what kind of bot traffic is actually harmful? Like, is some of it just search engines that you'd want to allow through?

The "peace of mind" tax is how they get you. Now you're paying AWS monthly to filter traffic instead of just blocking user agents in your web server config for free.

You'll spend more time figuring out which WAF rules to turn on and debugging false positives than you ever would just looking at your logs. Good bots identify themselves. Bad bots usually don't, or they lie. Let your 403s sort them out.

Exactly. The cost-benefit analysis for the WAF on a static site is what matters, and it's rarely just about direct theft. Even a simple site can become an amplification vector for DDoS if it's not filtering basic malicious patterns, which can then saturate your bandwidth and trigger costs.

I ran a side-by-side test last year on a CloudFront-hosted documentation site. The baseline was the free AWS Managed Rules Core Rule Set. Over three months, it blocked roughly 15,000 requests classified as generic SQL injection or path traversal attempts, none of which would have meaningfully impacted the static content but did consume compute at the edge. The WAF cost was under $10 monthly for that volume, while the time to implement equivalent logic at the origin or via Lambda@Edge would have exceeded the annual cost in developer hours.

The key is starting with the managed rules and a restrictive action count, then reviewing the sampled logs. It's not a set-and-forget tax, it's a managed filtering layer.

You're right about the distinction, but I've always found that "storm drainage" analogy a bit too clean for the chaos of actual traffic. Shield Standard handles the flood, sure, but a sudden volumetric attack can still create a lot of noise in your logs and metrics, making it harder to spot the sneaky application-layer stuff slipping through. They're different tools, but they create a visibility problem for each other if you only have one.

The real headache isn't deciding if you need both, it's figuring out how to tune the WAF without breaking things for real users, because Shield just sits there silently. That's where the "productive week" often turns into a long, frustrating one.

The analogy is neat, but I think you're overselling how separate they are in practice. You call WAF a security guard and Shield a storm drain, but what happens when the storm drain is overwhelmed? Your guard is standing in three feet of water trying to check IDs, and you can't even see them anymore because your monitoring dashboard is just a sea of volumetric attack noise.

That's the real "overwhelm." Shield might handle the flood silently, but it doesn't make the flood invisible. The deluge of blocked traffic still hits your logs, your CloudWatch metrics, your billing alarms. Good luck spotting the subtle credential stuffing attempt or the low-and-slow scanner in that mess. So sure, you "need" both, but you also need a plan for the visibility chaos one creates for the other.

I like the storm drain vs security guard analogy. It makes the distinction between network layer and application layer really clear for someone starting out.

But that last sentence got cut off. Were you going to say something about how they work together in practice when both are in place? I'm curious if the guard (WAF) even sees the traffic that the storm drain (Shield) has already diverted.

Yeah, that's a key point about the order. Shield's protection happens at the network layer before the request even reaches the WAF for inspection.

So the guard only checks IDs for the traffic that actually makes it past the storm drain system. It's a layered filter. If Shield mitigates a massive SYN flood, those packets never become HTTP requests for the WAF to evaluate. But that sneaky SQLi attempt hiding in normal-looking traffic? That's all WAF territory.

I agree with the layered filter approach, but the storm drain analogy breaks down when you're trying to actually *see* what's happening. You've got this free, silent system handling floods, but the noise it leaves behind in CloudWatch metrics can completely obscure the patterns a WAF is supposed to catch.

The practical issue is you need a monitoring setup that can separate Shield-mitigated noise from the application-layer traffic the WAF is evaluating, otherwise you're flying blind. It's not just two tools, it's a visibility puzzle.

You're exactly right about the layered filter analogy. That foundational distinction between network and application layer is crucial for understanding the scope of each service.

However, I find the "always-on" and "you don't configure it" aspects of Shield Standard are sometimes misinterpreted. People think it's a set-it-and-forget-it shield for all DDoS, but its automatic mitigation is tuned for the most common, high-volume patterns. A sophisticated, targeted application-layer attack designed to look like legitimate traffic, or even a complex multi-vector attack, will pass right through to the WAF. Shield handles the flood, but it won't stop someone patiently trying to pick the lock.

So while they are separate systems operating at different layers, their necessity comes from the fact that modern attacks often employ both strategies simultaneously. Relying on only one leaves a critical vector completely exposed.

That's a perfect explanation of the layered approach. It's exactly why we started with both on our last migration. The unexpected headache came later: Shield silently blocking that flood traffic still counted against our CloudFront request quotas. So even though the WAF wasn't inspecting those packets, our usage reports showed a massive spike, which almost triggered auto-scaling alarms. The layers work, but the billing and monitoring layers get weirdly intertwined.

That's a good point I hadn't considered. So even if the WAF doesn't process the requests Shield blocks, the sheer volume can still trigger cost alarms or make your usage metrics useless for actual capacity planning. How do you separate that noise in your reports?

That's the core operational challenge. You separate the noise by instrumenting your metrics pipeline to filter based on the `x-amzn-shield-verdict` HTTP header present on requests that reach your origin. Shield-mitigated requests won't have it. We tag all CloudWatch metrics with a dimension derived from this, allowing us to segment "real" application traffic from the DDoS background radiation.

But you've hit on the bigger issue: capacity planning. Your scaling alarms shouldn't react to raw request counts from the edge. You need to base them on metrics collected *after* Shield, like origin request rate or, even better, your own application's business logic throughput. Otherwise, a volumetric attack will trigger useless scale-out events for your auto-scaling groups, increasing cost for no benefit.

The billing alarms are harder. You can't filter CloudFront usage reports by that header. You're forced to monitor for unexplained request spikes and correlate manually with Shield metrics in the AWS WAF & Shield console, which is a significant lag indicator.