When Shield Advanced Earns Its Subscription Over Shield Standard

The situation

We run a handful of internet-facing things:

• A marketing site on CloudFront + S3. Static assets, handful of RUM endpoints. Revenue impact of an outage: small and diffuse (people don’t read a press release today, they read it tomorrow).
• A customer portal on CloudFront + ALB + ECS. Revenue impact: moderate. People log in to check their account; an outage generates support volume.
• A payments endpoint on CloudFront + ALB + ECS. Revenue impact: direct and immediate. Every minute of downtime costs measurable money; every second of added latency converts at a known rate.
• An internal admin app on an ALB with no CloudFront in front, accessed via Verified Access. Revenue impact from a DDoS: zero (it’s not on the internet in any meaningful sense).
• A handful of Route 53 hosted zones for the above domains.

Shield Standard is on for all of them by default. CFO has asked whether we should add Shield Advanced; security has asked whether the SRT (Shield Response Team) access and cost-protection clauses are actually worth the subscription. Same question, two framings. The answer depends on what Standard and Advanced actually do, and what they don’t.

What actually matters

DDoS protection at AWS is not a single product; it’s a stack with a free floor and a paid ceiling, and the distance between them is the question.

The free floor is always-on network-layer mitigation. SYN floods, UDP reflection amplification, and other L3/L4 attacks, applied by the same AWS edge infrastructure that carries normal traffic. This happens without the customer enabling anything. It costs nothing because AWS has to do it anyway to protect the shared infrastructure. The customer benefits regardless of whether they know Shield Standard exists.

What Standard doesn’t include is application-layer mitigation with customer-specific tuning, visibility into ongoing attacks, and the ability to talk to a human when something weird is happening. A volumetric L7 attack, a million HTTP GETs per second aimed at /search, doesn’t look like a SYN flood to the edge infrastructure. The requests are TCP-complete, TLS-valid, and formally well-formed. Distinguishing them from a traffic spike requires customer context: “this endpoint normally does 2k RPS, 900k is not a traffic spike, it’s an attack.” Shield Advanced subscribes the customer to that context.

The second axis is cost protection. When a DDoS causes an Auto Scaling group to scale up, a CloudFront distribution to absorb a hundred gigabytes of bogus requests, or a Route 53 zone to bill more queries than it normally would, the bill goes up. Standard doesn’t refund that. The paid tier, for a flat org-wide subscription plus data-transfer, will refund the usage spike caused by an attack as a service credit on a successful claim. For a service whose normal monthly spend on edge data transfer is in the hundreds of thousands of dollars, the cost-protection clause alone can pay for the subscription.

The third axis is human support. Advanced includes access to the Shield Response Team, a group that can help mitigate an ongoing attack in real time, writing custom WAF rules on our behalf, analysing traffic patterns, advising on Anycast routing. Standard does not. For most organisations the SRT is hypothetical; for the ones that genuinely run something tier-one, having a 24/7 number to call when the graph goes straight up is part of what they’re buying.

The fourth axis is scope. The paid tier is enabled per protected resource, but the subscription fee is per organisation (one flat charge). Once the subscription is paid, protecting more resources is incremental data-transfer cost, not another subscription. That shape rewards consolidation: if we’re paying the subscription anyway, protecting all revenue-bearing resources is cheap; protecting one and leaving the rest on the free floor is leaving value on the table.

What we’ll filter on

1. Layer of defence, network only (L3/L4), or network plus application (L7)?
2. Visibility, do we see what’s being blocked and why?
3. Response team access, can a human help during the attack?
4. Cost protection, do we get refunded for attack-driven usage?
5. Subscription shape, free, or flat org-wide fee plus data transfer?

The DDoS protection landscape

1. Shield Standard. Always on, free, every AWS customer, every account. Network-layer mitigation at the AWS edge against common L3/L4 attacks (SYN/ACK floods, UDP reflection, DNS-query floods on Route 53). No configuration, no console, no visibility into what got dropped. The defence runs continuously and the customer sees nothing unless it fails, which is most of the time the correct experience.

2. Shield Advanced. Paid tier: $3,000/month subscription per AWS organisation (one-year commit), plus data-transfer charges for traffic through protected resources. Protectable resources include CloudFront distributions, Route 53 hosted zones, Global Accelerator accelerators, Elastic IPs on EC2 and NLBs, and ALBs. Buys: application-layer protection via AWS WAF integration (WAF is included for Advanced-protected resources at no additional cost for the WAF ACL usage on those resources), CloudWatch metrics for DDoS events (DDoSDetected, DDoSAttackBitsPerSecond, etc.), a real-time console of ongoing attacks, access to the Shield Response Team, and cost-protection credits against scale-driven usage spikes during an attack. Enabled per resource from the Shield console or CLI.

3. AWS WAF by itself. Without Shield Advanced, WAF still attaches to CloudFront, ALB, API Gateway, AppSync, and Cognito user pools; pay the WAF charges normally. This is the option for L7 protection when the resource isn’t protectable by Shield Advanced (say, a standalone ALB without CloudFront in front) or when the Advanced subscription isn’t justified.

4. CloudFront + Route 53 architectural hardening. Fronting origins with CloudFront turns every request into an edge-terminated one, which is always-on-Shield-Standard territory and is free. Pointing authoritative DNS at Route 53 means the DNS layer is also Shield-Standard-protected. This isn’t a Shield product; it’s the architecture that makes Shield’s free tier maximally useful.

5. Third-party DDoS providers (Cloudflare Magic Transit, Akamai Prolexic, Lumen). Out of scope for AWS-native thinking but worth naming: organisations with cross-cloud presence sometimes front the AWS edge with a third-party scrubbing provider. Usually overkill for AWS-only estates.

Side by side

Reading the table by resource:

• Marketing site. Standard is plenty. Static assets, CloudFront already in front. An L7 attack on a marketing site is embarrassing but not revenue-bearing.
• Customer portal. Standard plus a WAF ACL is the right floor. If the business is paying for Advanced for the payments endpoint anyway, add the portal to Advanced too; the marginal cost is zero.
• Payments endpoint. Advanced is the answer. Revenue-bearing, latency-sensitive, attack-target shaped. Cost-protection clause covers the scaling spike, SRT access covers the “we don’t know what’s happening” moment.
• Internal admin app. Neither. It’s not internet-facing; Verified Access is the access control and DDoS exposure is effectively zero.
• Route 53 zones. Shield Standard protects DNS; Advanced protects the hosted zone if it’s added to the Advanced protection set.

The decision: does Advanced earn its keep?

The picks in depth

Shield Standard, everywhere (automatic). The defaults already do this. Worth naming explicitly because the question “are we protected against SYN floods?” has a positive answer without anyone having enabled anything. The protection applies to every AWS-edge-terminated resource: CloudFront, Global Accelerator, Route 53, public-facing ALB/NLB, EC2 with an Elastic IP. Nothing to configure, no console to visit, no finding to triage. Absorbs the garden-variety L3/L4 attacks that would otherwise dominate the inbound noise.

Shield Advanced for the payments endpoint, plus the portal once we’re paying anyway. The subscription is $3,000/month org-wide, one-year commit. That number reads as “per resource” in the marketing copy but is actually “flat, then add resources.” Protect the CloudFront distribution in front of payments; WAF usage on that distribution is included for free (the WAF base and per-rule-group charges are covered; data-processing is separately priced). Enable the DDoSDetectedNotification CloudWatch metric to route alarms to PagerDuty. Sign up for SRT access and pre-authorise them to make changes on our behalf during an incident, during an attack, the SRT can add WAF rules, adjust rate limits, and coordinate anycast response, and the authorisation has to be pre-granted because the moment you want them isn’t the moment to handle paperwork. Then, at no additional subscription cost, protect the customer portal’s CloudFront distribution too.

Cost protection, read carefully. The headline is “Shield Advanced refunds attack-driven usage.” The reality is more specific: credits are issued against data-transfer-out from CloudFront, Route 53 queries, ALB LCU usage, and a handful of other lines, when the usage was attributable to a DDoS that Shield Advanced detected. It does not cover every bill surprise during an attack. EC2 compute driven by an application-layer flood that slipped through WAF, for example, is not covered. Keep the expectation set: cost protection is a strong safety net for the transport layers, not a blanket insurance on every service. The claims process requires providing the incident window and the Shield DDoSDetected event; the service-credit decision is AWS’s.

A worked attack trace

Friday evening, 21:47 UTC. Shield Advanced’s DDoSDetected metric goes high on the CloudFront distribution in front of payments. EventBridge rule routes to PagerDuty; on-call acks in ninety seconds. Shield console shows the attack profile: ~75 Gbps of HTTPS traffic, GET requests to /api/v1/checkout/validate, spread across ~400k source IPs, user-agent pool of ~50 variations, entirely IPv4.

The existing WAF ACL on the distribution has a rate-based rule (aggregate IP, 200/5min, scope URI = /api/v1/*). The rule is blocking a huge fraction of the attack but 400k IPs means even at 200 hits each, 80M requests are getting through before the limit kicks in. The on-call calls the SRT via the Shield console contact-us workflow. SRT engineer on the line in four minutes.

22:02. SRT adds a custom rule in front of the rate-based: AWSManagedRulesAnonymousIpList block rule, deployed from an AWS-managed rule group that matches anonymisation providers (VPNs, hosting providers, TOR). Attack traffic drops by 60% within two minutes. Remaining traffic is mostly residential-looking IPs, harder to categorise.

22:14. SRT proposes a temporary CAPTCHA action on the /api/v1/checkout/validate path, legitimate browser clients will pass transparently via the Challenge mechanism, automated clients will not. Deployed. Attack traffic effectively eliminated; legitimate customer traffic sees ~200ms added latency on the first request after resume, zero on subsequent requests.

23:30. Attack ends (attackers gave up). SRT removes the CAPTCHA rule, leaves the AnonymousIpList rule in place because it was a good idea anyway. Shield Advanced’s cost-protection claim is filed automatically; a ticket is open with the incident window and the WAF traffic baseline. Six weeks later a service credit of $8,400 (CloudFront data-transfer and WAF processing) lands on the account.

Without Advanced, the same incident involves no SRT (the on-call writes the rules themselves, learning the syntax under pressure), no automatic claim (the cost increase becomes a business expense), and no advance coordination with AWS network operations. Same technical outcome is possible; the difference is how many senior engineers are on the bridge and how fresh they are at 02:00.

A worked month of the bill

Baseline month (no attacks):

Shield Advanced subscription              $3,000
Shield Advanced data-transfer (protected   $180
  resources, ~6 TB on CloudFront)
WAF on payments + portal (covered by      $0
  Advanced)
Total Shield-attributable cost            $3,180

Attack month (the 75 Gbps incident):

Shield Advanced subscription              $3,000
Shield Advanced data-transfer (~9 TB,      $270
  inflated by attack before mitigation)
Attack-driven CloudFront data-transfer    $1,200  (refunded via credit)
Attack-driven WAF request processing      $600    (refunded via credit)
Total Shield-attributable cost            $3,270
Minus cost-protection credit              -$1,800
Net                                        $1,470

The cost-protection credit came close to paying back a month’s subscription in one incident. Over a year with one-to-two serious attacks, the subscription recovers itself through credits; over a quieter year, the subscription is straight insurance. Either way the number is small relative to the revenue the payments endpoint is carrying.

What’s worth remembering

1. Shield Standard is always on, free, and covers L3/L4. SYN floods, UDP reflection, DNS-query floods on Route 53. No enable, no console, no configuration.
2. Shield Advanced is $3,000/month per org, flat. Adding more protected resources after the first is incremental data-transfer, not another subscription. This shape rewards consolidating Advanced across every revenue-bearing resource.
3. Advanced buys visibility, SRT access, WAF included on protected resources, and cost protection. Each axis matters differently to different organisations; the SRT access and cost protection tend to be the deciders.
4. Cost protection applies to transport-layer lines. CloudFront data-transfer, Route 53 queries, ALB LCUs during an attack Shield detected. Not blanket insurance against all bill surprises.
5. Protectable resources are: CloudFront distributions, Route 53 hosted zones, Global Accelerator accelerators, Elastic IPs, and Application and Network Load Balancers. Pre-authorise the SRT for production resources so they can act during an incident.
6. WAF without Shield Advanced is the L7 answer for resources not protectable by Advanced. Standalone ALBs without CloudFront in front, API Gateway, AppSync.
7. CloudFront in front of origins is the architecture that gets Standard’s full value. Every edge request benefits from Standard’s L3/L4 absorption; direct-to-ALB skips the best part of the free tier.
8. The $3k/month is the gate, not the slope. The question isn’t “which resources deserve Advanced”; it’s “does the org clear the $3k gate at all.” If yes, protect everything revenue-bearing under the same subscription.

Standard is the floor, Advanced is the tier-one package, WAF is the L7 piece that comes with Advanced or stands alone. The decision is almost always about whether the organisation clears the $3k/month gate, and if it does, the work is making sure every resource that earns revenue is on the other side of it.