5.3 AWS Shield Advanced & DDoS Defense Architectures

5.3 AWS Shield Advanced & DDoS Defense Architectures

Distributed Denial of Service (DDoS) attacks seek to exhaust system availability, saturate network bandwidth, consume connection tables, and deplete backend compute resources. In modern multi-tier cloud environments, attacks occur across different layers of the Open Systems Interconnection (OSI) model, ranging from massive multi-terabit volumetric Layer 3 and Layer 4 floods to subtle, application-specific Layer 7 query floods.

AWS delivers a layered defense model anchored by AWS Shield Standard and AWS Shield Advanced. For the AWS Certified Security – Specialty exam, security engineers must understand attack vector classifications, protected resource scopes, the mechanics of Automatic Layer 7 DDoS Mitigation, Health-Based Detection via Route 53, operational integration with the AWS Shield Response Team (SRT), and financial cost protection against scaling spikes.

---

DDoS Attack Taxonomy: Layer 3/4 vs Layer 7 Attacks

Effective DDoS mitigation requires diagnosing the specific OSI layer targeted by an adversary.

Loading diagram...

Infrastructure Layer Attacks (Layers 3 & 4)

• UDP Reflection / Amplification: Attackers send spoofed requests with the victim's source IP address to publicly accessible third-party reflection servers (e.g., open NTP, DNS, CLDAP, or Memcached servers). The reflection servers return responses amplified by factors of 10x to 50,000x, saturating the victim's inbound internet connectivity.
• SYN Floods: Attackers initiate vast numbers of TCP handshakes with spoofed IPs by sending SYN packets but never completing the three-way handshake with an ACK. This consumes the TCP state table and half-open connection buffers of edge firewalls and load balancers.
• IP Packet Fragmentation: Attackers transmit overlapping, out-of-order, or malformed UDP/ICMP fragments to exhaust operating system defragmentation memory buffers.

Application Layer Attacks (Layer 7)

• HTTP GET/POST Floods: Attackers submit high volumes of validly formed HTTP requests targeting CPU-intensive or database-heavy endpoints (e.g., dynamic reporting queries, PDF generation, or checkout processing). Because requests conform to standard TLS handshakes and HTTP protocols, Layer 3/4 firewalls cannot distinguish them from legitimate user traffic.
• Slowloris / Slow POST: Attackers open thousands of HTTP connections and transmit request headers or payload bytes extremely slowly (e.g., 1 byte every 15 seconds). This keeps web server threads and connection sockets open indefinitely, preventing real users from connecting.

---

AWS Shield Standard vs AWS Shield Advanced

AWS provides two distinct tiers of DDoS defense:

---

Automatic Layer 7 DDoS Mitigation

A signature capability of AWS Shield Advanced is Automatic Layer 7 DDoS Mitigation. When an enterprise associates a WebACL with a protected resource (such as an Application Load Balancer or CloudFront distribution), Shield Advanced continuously profiles the application's normal traffic patterns.

Loading diagram...

How Automatic Mitigation Functions

1. Continuous Baselining: Shield Advanced analyzes historical traffic telemetry to establish diurnal baseline models for request rates, client IP distributions, user agents, and URL endpoints.
2. Anomaly Isolation & Signature Extraction: During an active attack, the mitigation engine uses machine learning algorithms to isolate the unique fingerprint of the malicious traffic (e.g., identical uncommon header values, specific URI combinations, or abnormal geographic concentrations).
3. Automated Rule Synthesis: Shield Advanced authors a custom AWS WAF rule targeting the isolated attack signature and deploys it into a rule group that Shield owns (named ShieldMitigationRuleGroup_<account-id>_<web-acl-id>_<unique-id>), referenced from your web ACL by a rule at priority 10,000,000 so it runs after your own rules.
4. Mitigation Action Configuration: Security engineers can configure automatic mitigation to operate in Count mode (logs the rule evaluation without dropping traffic) or Block mode (actively terminates attack connections at the edge).
5. Automated Rule Teardown: When the attack terminates and traffic returns to baseline, Shield Advanced automatically removes the generated rule to conserve WebACL capacity and prevent stale rules from impacting future operations.

---

Health-Based Detection via Amazon Route 53

A critical challenge in automated DDoS defense is distinguishing between an active malicious flood and a legitimate traffic surge (such as a viral marketing campaign, flash sale, or breaking news broadcast).

If a mitigation system relies solely on traffic volume, it risks generating severe false positives—blocking legitimate customers during high-revenue business events.

The Health-Based Detection Mechanism

Shield Advanced resolves this through Health-Based Detection by integrating with Amazon Route 53 Health Checks:

• The security engineer creates a Route 53 health check monitoring the operational health of the application (probing endpoint latency, HTTP status codes, or internal backend health).
• The health check is associated with the Shield Advanced protected resource.
• Operational Logic:
  • Traffic Surge + Healthy Application: If traffic volume spikes by 500% but the Route 53 health check remains completely healthy (low latency, 200 OK responses), Shield Advanced determines the application is handling the load successfully. It does not engage aggressive mitigations, protecting legitimate user transactions.
  • Traffic Surge + Degraded Application: If a traffic surge coincides with failing health checks (elevated backend latency or 5xx error responses), Shield Advanced immediately lowers its anomaly threshold, engages automated Layer 7 WAF mitigations, and alerts the AWS Shield Response Team.

Exam Tip: Always configure Health-Based Detection for Shield Advanced protected resources! On the exam, when asked how to minimize false positives during legitimate traffic spikes or enable proactive SRT engagement, the correct architectural answer involves associating Route 53 health checks with the Shield Advanced protected resources.

---

24/7 AWS Shield Response Team (SRT) Integration

Subscribers to AWS Shield Advanced gain direct, 24/7 access to the AWS Shield Response Team (SRT)—formerly known as the DDoS Response Team (DRT). The SRT consists of specialized security engineers who assist customers in triaging, analyzing, and mitigating complex, multi-vector DDoS attacks.

Loading diagram...

Configuration Prerequisites for SRT Support

To allow the SRT to manage mitigations on the customer's behalf during an active emergency, three prerequisites must be completed before an attack occurs:

1. Support Plan: The AWS account must be subscribed to either Business Support or Enterprise Support.
2. SRT access role:
   • In the Shield console, choose to create a new role or select an existing one; either way the role must trust the service principal drt.shield.amazonaws.com (via sts:AssumeRole).
   • The role carries the AWS managed policy AWSShieldDRTAccessPolicy, which lets the SRT call Shield Advanced and AWS WAF APIs on your behalf and read your AWS WAF web ACL logs.
3. Optional extra log buckets:
   • WAF web ACL logs need no extra step. For other evidence (ALB or CloudFront access logs, packet captures), add up to 10 buckets; Shield grants the SRT s3:GetBucketLocation, s3:GetObject, and s3:ListBucket on them.
   • Those buckets must be unencrypted or SSE-S3 encrypted. The SRT cannot read logs in buckets encrypted with AWS KMS keys.

Proactive Engagement

When Proactive Engagement is enabled in the Shield console, the SRT does not wait for the customer to open a support ticket. If a protected resource with an associated Route 53 health check becomes unhealthy during a detected DDoS event, the SRT will proactively contact the customer's designated emergency contacts (via phone and high-priority ticket) to begin mitigation immediately.

---

Financial Protection: DDoS Cost Protection for Scaling

A devastating secondary effect of a Layer 7 DDoS attack is financial exhaustion. In a well-architected cloud environment, Auto Scaling groups, Application Load Balancers, and CloudFront distributions automatically scale up to handle incoming request volume. During an attack, hundreds of EC2 instances may be provisioned, resulting in catastrophic compute and data transfer out (DTO) bills.

AWS Shield Advanced Cost Protection shields organizations against these economic damages:

• If an attack causes a surge in resource usage across protected resources (such as Amazon EC2, CloudFront, ALB, or Route 53), the customer can submit a claim for billing credits.
• The credit covers the difference between normal baseline operational usage and the spike charges directly attributable to the DDoS attack.
• Claims are submitted via AWS Support after the incident, referencing the attack identifier, affected resource ARNs, and billing cycle.

---

End-to-End Edge DDoS Defense Architecture

A resilient, enterprise-grade edge defense architecture integrates Route 53, CloudFront, AWS WAF, AWS Shield Advanced, and AWS Global Accelerator:

Loading diagram...

Defense-in-Depth Components

1. Route 53 Shuffle Sharding: Route 53 provides authoritative DNS resolution utilizing anycast routing across dozens of edge locations. Each hosted zone is assigned four virtual name servers hosted on isolated failure domains (shuffle sharding), ensuring that a DDoS flood against one name server does not impact resolution on the remaining three.
2. AWS Global Accelerator: For non-HTTP TCP/UDP workloads (such as gaming, VoIP, or proprietary financial trading protocols), Global Accelerator provisions static anycast IP addresses routed across the AWS global backbone. It terminates TCP connections at edge PoPs, absorbing SYN floods and UDP reflection before traffic enters the VPC.
3. CloudFront Edge Termination: Terminating TLS connections at edge PoPs ensures that Layer 3 and 4 attacks are absorbed by AWS border routers and transit centers without reaching regional VPC gateways.
4. Origin Cloaking: Enforcing custom header verification (X-Origin-Verify) and restricting security groups to the CloudFront managed prefix list guarantees that malicious traffic cannot bypass edge mitigations.

---

Specialty Exam Pitfalls & Architectural Traps

1. Assuming Shield Standard Covers Layer 7 Floods: Shield Standard is entirely automated and provides world-class Layer 3 and Layer 4 defense. However, it provides zero protection against Layer 7 application attacks (such as HTTP GET floods). Defending against Layer 7 attacks requires AWS WAF or AWS Shield Advanced with automatic Layer 7 mitigation.
2. Overlooking the SRT IAM Role and S3 Log Permissions: In an active DDoS emergency, customers cannot simply open a ticket and expect the SRT to modify their WebACLs. If SRT access has not been granted (no role trusting drt.shield.amazonaws.com with AWSShieldDRTAccessPolicy), the SRT is legally and technically constrained from accessing the customer's account or deploying mitigations on their behalf.
3. Misunderstanding Cost Protection Mechanics: Shield Advanced Cost Protection does not cap or prevent auto-scaling charges in real time. Backend resources will still scale up to attempt to handle the load, incurring charges. The protection functions as a post-incident billing credit applied after AWS verifies the incident.
4. Failing to Associate Route 53 Health Checks: Operating Shield Advanced without Route 53 Health-Based Detection severely impairs its defensive capabilities. The system cannot distinguish legitimate marketing surges from distributed attacks, increasing the risk of false positives, and proactive SRT engagement will remain disabled.