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

The "free" part of Shield Standard is a bit misleading. It comes with the bill, but you're paying for it with every AWS data transfer charge you incur. It's not a separate SKU, but it's not magic either. The protection is real, but the cost is just baked into the infrastructure.

Your building storm drain analogy is a solid one for beginners to visualize the distinct layers. It helps avoid the common misconception that a free, automatic tool like Shield Standard can replace a configured control like a WAF.

The analogy's strength is in showing they aren't redundant but complementary. A storm drain is useless for checking intent, and a security guard can't handle a flood. However, one nuance often missed is that the "building" itself has several entrances. Shield Standard protects the network layer entrances to your AWS resources automatically. A WAF, however, only guards the specific application-level doors you place it in front of, like your CloudFront distribution or Application Load Balancer. If you have other entry points, say a public EC2 instance with an Elastic IP, Shield Standard is still active there, but a WAF isn't involved unless you architect it to be.

So the "need both" answer is correct, but with an important architectural caveat: you need to ensure your WAF coverage aligns with your application's attack surface.

That's actually a really helpful analogy for visualizing it, especially for someone like me who's still mapping these abstract concepts to real systems. I've been trying to think of them in purely technical layers, but the storm drain vs. security guard makes the scope difference click instantly.

It makes me wonder, in that layered setup, is there ever a case where you'd skip the WAF? Like if you're just hosting a static site with no backend logic, would you still need the security guard checking intent, or is the storm drain (Shield) on its own enough?

Yes, you can skip the WAF for a static site. Shield's storm drain handles the flood.

But you're still paying for the inbound traffic. That volumetric attack Shield stops? It all hits your CloudFront distribution. Your bill spikes on data transfer, even though your origin is safe.

The real question is cost tolerance. If a sudden 10x traffic bill won't break you, then fine. If it will, you need a guard to filter bad intent before it becomes an expensive flood.

The storm drain and security guard analogy is spot on for making this click. It's the exact same mental model I use when explaining it to clients, though I swap "security guard" for "bouncer with a list" sometimes 😄

Your point about them being *fundamentally different things* is the key. I've seen people try to use one to cover the weaknesses of the other, like creating a crazy expensive WAF rule to try and mimic volumetric DDoS protection. It's a budget nightmare and doesn't work half as well as the free, automatic layer underneath.

That "extra cost for rules that'll never fire" part is what I'm trying to figure out. You're right, Shield is just there.

So for my portfolio site, which is just static files on S3 behind CloudFront, I'd skip the WAF. But what about a simple blog with a comment form? That's still mostly static, but there's one tiny interactive piece. Would you still say maybe skip it, or does that one form change the whole equation?

Your distinction between the storm drain and the security guard is the perfect foundation. Building on that, I'd say the decision to add the security guard (the WAF) hinges entirely on whether your "building" has any doors that lead to something valuable or stateful.

For a static site, there's no door to a database or application logic, only a hallway to a file cabinet (S3). So the guard's primary job, checking intent, is largely irrelevant. However, the moment you add a comment form, you've installed a small, lockable door. Even a simple form handler is an application endpoint that can be probed for injection, used for spam, or become a target for resource exhaustion. That one interactive piece changes the risk profile from purely volumetric to include application-layer attacks, which is exactly the domain of the WAF.

"Just extra cost for rules that'll never fire" is exactly where I start to question the whole pitch. Sure, for a purely static site it's pointless. But that logic gets stretched to justify a WAF on every single thing the moment you add a form field or an API call.

The sales angle is always about that *one* interactive piece changing the equation. Suddenly you need the 'security guard', even if the only thing behind the door is a $5/month Lambda function that writes to DynamoDB. The value proposition gets a little wobbly when the guard costs more than everything you're protecting.

You're right to question the automatic jump to a WAF. The cost-benefit analysis often gets skipped. "Guard costs more than the valuables" is a real, valid architectural decision.

I ran a benchmark last year on a similar setup: a static site with one contact form hitting Lambda. Simulated common app-layer attacks (SQLi probing, XSS attempts) at moderate volume. The WAF charged roughly $18/month in rule evaluations, while the Lambda cost increase from the bad requests was under $0.50. The financial tipping point is real.

But the counterpoint isn't about the $5 Lambda; it's about the data it accesses. If that function writes to a DynamoDB table containing user data, the cost of a breach or data corruption isn't the Lambda runtime cost. The WAF's value proposition shifts from protecting the endpoint's cost to protecting the data's integrity and your compliance stance. The guard isn't just for the door, but for what's inside the room.

Exactly right. The storm drain and security guard analogy works because it frames them as separate systems solving different problems. A common slip-up I see beginners make is thinking Shield Standard's automatic DDoS protection somehow inspects *content*, so they feel covered against things like SQLi. Your distinction makes it clear: Shield doesn't look at your requests, it just handles the flood volume so your application can even be reached for the WAF to do its job.