Protect APIs with AWS Shield Advanced

Your API is the front door to your business — and distributed denial-of-service (DDoS) attacks can slam that door so hard your entire application falls over. Amazon's own AWS Shield Advanced service exists to stop precisely this scenario, absorbing massive network floods before they reach your API Gateway, Application Load Balancer, or CloudFront distribution. In this lesson, you'll learn how to protect APIs with AWS Shield Advanced: what it actually does, how to turn it on, and how to build a layered defense around your most critical endpoints.

The problem this lesson solves

Without DDoS protection, your API suddenly becoming popular for the wrong reasons can mean minutes of downtime, failed payments, angry customers, and inflated AWS bills. A typical volumetric attack saturates network links, but modern attacks also exploit application-level weaknesses — like a single expensive endpoint that, when hammered, exhausts CPU or database connections. AWS Shield Advanced directly addresses both layers:

• Network and transport layer (L3/L4): SYN floods, UDP reflection attacks, and other packet-based assaults.
• Application layer (L7): HTTP request floods targeting specific routes such as /login or /health.

If you rely only on infrastructure scaling or a basic firewall, you're reacting after the damage begins. Shield Advanced gives you always-on detection and mitigation at the edge, far before traffic reaches your origin.

Pro tip: Even if you have no web application firewall, Shield Advanced's network-layer protection can often keep your API alive during a basic SYN flood — a cheap insurance policy for mission-critical workloads.

Core concept / mental model

Think of AWS Shield Advanced as a smart bouncer standing at the entrance of an exclusive club. The bouncer:

• Scans every guest (packet/request) long before they reach the dance floor (your origin).
• Recognizes known troublemakers (attack patterns) and blacklists them instantly.
• Notifies the manager (you) when suspicious crowds form.
• Allows only legitimate guests through — using your custom rules (like a WAF) to decide who's VIP.

Operationally, Shield Advanced works at AWS edges (CloudFront, Route 53, Global Accelerator) and regional resources (ELB, API Gateway). It constantly watches traffic, uses heuristics and signatures to spot anomalies, and automatically redirects malicious traffic before it can overload your infrastructure.

The service also provides cost protection: if an attack increases your usage charges (for example, EC2 data transfer spikes), AWS grants credits — something rare among cloud providers.

How it works step by step

1. Enable Shield Advanced

You subscribe at the organization level (or per account), then associate the protected resource. You can also attach an AWS WAF web ACL to define application-layer rules.

2. Associate your API resource

Decide which Amazon resource fronts your API:

• Amazon API Gateway (REST/HTTP/WebSocket) — simplest for pure APIs.
• Application Load Balancer — if you run containers or EC2 behind a load balancer.
• CloudFront — for global distribution and caching.

3. Configure application-layer protection (optional)

Shield Advanced can automatically create and manage a WAF rule that rate-limits requests to your resource. You can adjust thresholds based on normal traffic patterns.

4. Monitor and respond

Set up CloudWatch alarms and event notifications. When Shield detects an attack, it emits metrics and events that trigger your incident response playbook.

5. Engage the DDoS Response Team (DRT)

Under active attack, you can contact the 24/7 DRT for hands-on assistance — they can mitigate on your behalf.

6. Review cost protection

If an attack inflates your bill, file for credits via the Shield console — AWS automatically applies many of them.

Hands-on walkthrough

Prerequisites

• AWS CLI configured (v2, with credentials with shield:CreateProtection and wafv2:* permissions).
• An existing API Gateway API (or any resource above).

Step 1: Subscribe to Shield Advanced

aws shield subscribe --subscription-limit 100000

Verify:

aws shield describe-subscription

Expected output: JSON confirming your subscription status, ProactiveEngagementStatus and SubscriptionLimits.

Step 2: Create a WAF web ACL for the API

First, retrieve your API Gateway ARN:

api_arn=$(aws apigateway get-rest-apis --query 'items[?name==`my-api`].id' --output text)
echo "arn:aws:apigateway:REGION::/restapis/$api_arn"

Create a web ACL (replace REGION and RESOURCE_ARN):

aws wafv2 create-web-acl \
  --name api-waf \
  --scope REGIONAL \
  --default-action Allow \
  --description "Protect API from L7 floods" \
  --rules '['
    {
      "Name": "AWSManagedRulesCommonRuleSet",
      "Priority": 1,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet"
        }
      },
      "OverrideAction": {"None": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "common-rules-metric"
      }
    },
    {
      "Name": "RateLimit",
      "Priority": 2,
      "Statement": {
        "RateBasedStatement": {
          "Limit": 2000,
          "AggregateKeyType": "IP"
        }
      },
      "Action": {"Block": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "rate-limit"
      }
    }
  ']' \
  --region REGION

This command creates an allow-all ACL with two managed rules. The rate-based rule blocks IPs that exceed 2000 requests in a 5-minute window.

Step 3: Associate the web ACL with your API

aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:REGION:ACCOUNT_ID:regional/webacl/api-waf/ID 
  --resource-arn arn:aws:apigateway:REGION::/restapis/YOUR_API_ID

Step 4: Enable Shield Advanced protection on the API

aws shield create-protection \
  --name api-protection \
  --resource-arn arn:aws:apigateway:REGION::/restapis/YOUR_API_ID

Step 5: Set up monitoring

Create a CloudWatch alarm for DDoS attack metrics:

aws cloudwatch put-metric-alarm \
  --alarm-name shield-attack-alarm \
  --metric-name DDoSDetected \
  --namespace AWS/DDoSProtection \
  --statistic Sum \
  --period 300 \
  --evaluation-periods 1 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching

Expected output: CloudWatch alarm ARN.

Compare options / when to choose what

When to choose what: - Shield Advanced — if your API generates revenue, handles sensitive data, or you need cost protection for attack-driven bill spikes. - WAF only — if you have a tight budget and only need to control HTTP request patterns, but you lose L3/L4 defense. - Both combined — for the highest resilience, use Shield Advanced + WAF (Shield automatically engages WAF for L7 attacks when attached).

Troubleshooting & edge cases

Error: ResourceNotFoundException during create-protection

Your resource ARN is wrong. Double-check the ARN format for API Gateway: arn:aws:apigateway:REGION::/restapis/API_ID. For an Application Load Balancer, it's arn:aws:elasticloadbalancing:REGION:ACCOUNT:loadbalancer/app/NAME/ID.

Problem: API returns 503 Service Unavailable during high traffic

Shield may be blocking legitimate users as part of the rate-based rule. Check the rate limits in the WAF web ACL and adjust to a higher value, but monitor for abuse.

Misconception: Shield Advanced automatically protects all resources

It does not. You must explicitly create a protection for each resource. If you forget, the resource remains unprotected — and a DDoS attack will hit your origin directly.

Edge case: Not all regions support Shield Advanced

Some regional resources (like API Gateway in a specific region) may not support Shield Advanced protections — refer to the regional support documentation. This is rare, but always verify when planning.

Cost protection doesn't apply automatically

You must apply for cost credits through the Shield console after an attack. AWS won't automatically refund your inflated charges.

Application-layer attacks bypass network-layer filters

If you see high CPU but no network saturation, your API is likely under an L7 attack. Use the WAF rate-based rule (as shown above) — Shield alone doesn't block HTTP floods.

What you learned & what's next

You now understand why Shield Advanced is the fundamental layer of DDoS defense for your APIs: it stops network floods at the edge, integrates with WAF for L7 rules, and protects you from attack-driven bill shock. You can enable it, associate resources, and monitor attacks. Remember: Shield Advanced is not a substitute for good application security — DDoS protection is just one part of a layered defense.

Ready to become a true cloud security engineer? Move to the next lesson in this track, where you'll learn how to orchestrate response runbooks — how to detect attacks automatically and recover in minutes, using CloudWatch, Lambda, and AWS Systems Manager. That skillet will turn your static protections into a dynamic defense.

Final tip: Enable cost alarms as soon as you subscribe. Attack-driven bill spikes can be nasty if you forget to claim credits.