Edge Security on AWS with WAF, Shield, CloudFront, and DDoS Defense

A comprehensive guide to AWS edge security layers — WAF Managed Rules, Rate-based Rules, Shield Advanced DRT and Cost Protection, Firewall Manager org-wide deployment, and CloudFront OAC, Signed URL, and Field-Level Encryption.

Edge Security on AWS with WAF, Shield, CloudFront, and DDoS Defense

_Category: Network Security_

By the time internet traffic reaches your application servers, it has already passed through dozens of Edge Locations and load balancers. The core principle of security is simple: block attacks as far from your perimeter as possible. Stopping an intruder at the front gate is far more efficient than chasing them through your corridors after they've already made it inside. AWS WAF, Shield, CloudFront, and AWS Firewall Manager are the edge security services that put this principle into practice.

---

 

The Edge Defense Principle: Stop Threats as Far Out as Possible

Once an attack reaches inside your VPC, EC2 instances start burning CPU cycles processing DDoS packets, and SQL injection queries have a chance to reach your RDS databases. The ideal line of defense sits at the Global Edge layer where CloudFront and WAF operate.

Think of AWS edge security as a series of concentric rings. The outermost ring is Shield, absorbing Layer 3/4 DDoS floods. Inside that, CloudFront receives traffic at hundreds of Edge Locations around the world. The next ring is AWS WAF, inspecting HTTP/HTTPS requests and blocking malicious patterns. Only traffic that passes all these outer defenses ever reaches your Application Load Balancer or EC2 instances.

Attaching WAF to CloudFront means your rules execute at the global edge — before traffic even enters a region. Attaching WAF to an Application Load Balancer means rules run at the regional level. From a DDoS-mitigation perspective, the CloudFront + WAF combination filters traffic far earlier in the journey.

---

 

AWS WAF Architecture: Web ACL, Rule, Rule Group, and Managed Rules

AWS WAF works like a security checkpoint at the entrance of a building. Every HTTP request must pass through, and a set of rules determines whether it walks through or gets turned away.

A Web ACL is the top-level container in WAF. You associate it with a CloudFront distribution, Application Load Balancer, API Gateway, or AWS AppSync. Inside a Web ACL, you define Rules, each with a priority number — the lower the number, the earlier it is evaluated.

A Rule Group bundles multiple Rules into a reusable container. Managed Rules are pre-built, continuously updated Rule Groups maintained by AWS and AWS Marketplace security partners.

| Category | Description | Representative Rule Group | |---------|------|----------------| | Core Rule Set (CRS) | Blocks common web attacks based on OWASP Top 10 | AWSManagedRulesCommonRuleSet | | Known Bad Inputs | Blocks patterns associated with known vulnerability exploitation | AWSManagedRulesKnownBadInputsRuleSet | | SQL Database | Blocks SQL injection attacks | AWSManagedRulesSQLiRuleSet | | Amazon IP Reputation | Blocks malicious IPs observed by AWS threat intelligence | AWSManagedRulesAmazonIpReputationList | | Bot Control | Detects and blocks bot traffic | AWSManagedRulesBotControlRuleSet |

An IP Set stores up to 10,000 IP addresses or CIDR ranges and can be referenced inside a Rule. WAF logs flow through Kinesis Data Firehose to S3 or CloudWatch Logs, recording the source IP, URI, headers, matched rule name, and allow/block outcome for every request. CloudWatch metrics give you aggregated counts per rule — but per-request, one-to-one tracing is only available in the WAF logs themselves.

---

 

Stopping Automated Attacks with Rate-based Rules, Bot Control, and Captcha

A Rate-based Rule automatically blocks any IP that exceeds a configured threshold (minimum 100 requests) within a 5-minute window. Pair it with a URI pattern condition and you can throttle only the specific path under attack while leaving normal traffic untouched. If a Layer 7 DDoS is in progress and a particular URI is being hammered repeatedly, adding a Rate-based Rule with a URI condition is your fastest immediate countermeasure. Shield Advanced DRT engagement takes hours — WAF is your first responder.

A Geo Match Rule allows or blocks traffic based on the country of origin. This is distinct from CloudFront's built-in Geo Restriction feature. CloudFront Geo Restriction is configured directly on the distribution without WAF, incurs no additional charge, and returns HTTP 403 to blocked requests. A WAF Geo Match Rule is the right choice when you need to combine country filtering with URL pattern conditions for finer-grained control — but it does add WAF cost.

Bot Control distinguishes legitimate bots from malicious ones and handles them differently. The Captcha action challenges suspicious requests with a CAPTCHA puzzle before allowing them through. Custom Response lets you define the HTTP status code and response body returned when a request is blocked.

---

 

Shield Standard vs Shield Advanced: Comparison, DRT, and Cost Protection

Shield Advanced is like having a dedicated security team on call 24/7 rather than just a lock on the door. It is not simply a bigger shield — it brings expert responders who rush to your side the moment an attack begins.

| Feature | Shield Standard | Shield Advanced | |------|----------------|----------------| | Cost | Free (automatic) | $3,000/month + data transfer fees | | Protection Layer | Layer 3/4 | Layer 3/4 + Layer 7 | | DRT 24/7 Support | None | Yes — real-time attack response | | Cost Protection | None | Yes — reimbursement for scaling costs | | CloudWatch Metrics | Basic metrics only | Detailed metrics including DDoSDetected | | Health-based Detection | None | Based on Route 53 Health Checks | | WAF Fee Waiver | Not applicable | WAF charges waived for subscribed resources |

The DDoSDetected CloudWatch metric provided by Shield Advanced switches to 1 when an attack is detected and returns to 0 when it ends. Set a CloudWatch Alarm on this metric and connect it to an SNS topic, and you will receive email, SMS, or Lambda notifications the moment an attack is identified.

!Shield Standard versus Shield Advanced

This is the standard architecture for real-time DDoS detection alerting with Shield Advanced.

Cost Protection covers situations where a DDoS attack causes abnormal spikes in EC2 Auto Scaling usage, CloudFront data transfer, or Route 53 query volume — AWS reimburses those unexpected costs as credits. This is a decisive differentiator that Shield Standard simply does not offer.

---

 

Deploying Org-wide Policies with AWS Firewall Manager

Managing WAF Web ACLs individually across dozens or hundreds of AWS accounts makes consistent security posture nearly impossible to maintain. AWS Firewall Manager is like headquarters issuing a security handbook to every branch office simultaneously — and enforcing compliance automatically.

Firewall Manager integrates with AWS Organizations, allowing a central administrator account to deploy WAF policies, Shield Advanced protections, and Security Group policies across an entire organizational unit or individual accounts in a single operation. When a new resource is created, Firewall Manager automatically associates the appropriate Web ACL if the resource matches the configured scope.

The most common reason some ALBs end up without a Web ACL after a Firewall Manager deployment is a missing scope tag. Firewall Manager policies filter included and excluded resources by tag, and any resource missing the expected tag is considered out of scope.

One important behavioral nuance: if you remove an account from a Firewall Manager policy scope, any Web ACLs already associated with its resources are not automatically detached or deleted — they remain in place. After the account leaves scope, Web ACL changes are no longer automatically propagated, so the account owner must manage them directly. Prerequisites for using Firewall Manager are AWS Organizations being active and a designated administrator account.

---

 

CloudFront Security Integration: OAC, Signed URL/Cookie, and Field-Level Encryption

OAI and OAC both enforce access to S3 exclusively through CloudFront, blocking direct public access. OAC is the modern replacement for OAI and is the recommended approach for new configurations.

| Feature | OAI (Legacy) | OAC (Current, Recommended) | |------|-----------|----------------| | Mechanism | CloudFront-specific virtual identity | IAM service principal (cloudfront.amazonaws.com) | | SSE-KMS Support | Limited | Full | | SigV4 Dynamic Signing | No | Yes | | Recommendation | Avoid for new setups | Recommended |

The OAC + WAF IP Set combination is the standard pattern for simultaneously blocking direct S3 access and enforcing IP-based access restrictions. Using aws:SourceIp in an S3 bucket policy does not work for client IP filtering because CloudFront forwards requests from its own IP addresses, not the client's.

Signed URL controls access to a single file. Signed Cookie controls access to multiple files or an entire path with a single credential. For a streaming service that should only be accessible to subscribers, Signed Cookie is the better fit.

Field-Level Encryption encrypts specific POST fields at the CloudFront edge using a public key before forwarding the request to the backend. Sensitive data like payment card numbers never travels as plaintext beyond the edge. The distinction worth remembering: KMS is server-side encryption at rest, while Field-Level Encryption selectively encrypts individual fields in transit, at the edge, before the data even reaches your origin. CloudFront Origin Failover automatically switches to a secondary origin within an Origin Group when the primary origin returns 4xx or 5xx errors, providing high availability without manual intervention.

---

 

Tricky Edge Security Scenarios on the Exam

Here are the most commonly confused scenarios drawn from real exam questions.

"Block traffic from specific countries without WAF" — CloudFront Geo Restriction, not WAF Geo Match. Geo Restriction is configured directly on the CloudFront distribution at no additional

Back to blog list