Busca en todas las páginas de la documentación
"Someone is attacking my application" can mean two very different things. It can mean a flood of packets aimed at saturating a network link, or it can mean a stream of well-formed HTTP requests trying to find a SQL injection hole. AWS WAF and AWS Shield answer these two problems separately, at different layers of the stack, and understanding which is which is the first step before touching either SDK.
This page lays out the model: what each service inspects, where each one sits relative to your resources, and how they combine into one layered defense.
Start with what each service actually looks at.
AWS WAF (via the wafv2 API - boto3 module wafv2, SDK v3 package @aws-sdk/client-wafv2) sits in front of an Application Load Balancer, API Gateway REST API, AppSync GraphQL API, App Runner service, Cognito user pool, or CloudFront distribution. It parses each HTTP(S) request and evaluates it against a Web ACL - an ordered list of rules. A rule can match on IP address, geographic origin, request rate, header content, or a body pattern (SQL injection, cross-site scripting), and the action is ALLOW, BLOCK, or COUNT.
WAFV2 is the current API. The original "classic" WAF API is deprecated - AWS has stopped adding features to it, and new work should always target wafv2/WAFV2. If you inherit code that imports the classic waf or waf-regional clients, treat that as a signal to migrate.
AWS Shield operates below WAF, at the network and transport layers. Shield Standard is automatic and free for every AWS account - it defends every Elastic Load Balancer, CloudFront distribution, Route 53 hosted zone, and Global Accelerator against common, most-frequently-occurring network and transport layer DDoS attacks, with no setup required.
Shield Advanced (via the shield API - boto3 module shield, SDK v3 package @aws-sdk/client-shield) is a paid subscription that adds near-real-time visibility into attacks, more sophisticated mitigations for larger/more complex attacks, DDoS cost protection (credits against scaling charges incurred during an attack), and access to AWS's DDoS Response Team (DRT) during an active incident.
Both services are opt-in per resource, not blanket account settings - but they opt in differently.
A Web ACL is created independently (CreateWebACL) and then explicitly attached to a resource with AssociateWebACL. Nothing is protected until that association exists. The Scope you create the Web ACL with matters: REGIONAL for an ALB, API Gateway, AppSync API, or Cognito pool - created in the region where the resource lives; CLOUDFRONT for a CloudFront distribution, which is global but the API call itself must be made against us-east-1 regardless of where your viewers are.
Shield Advanced works similarly but with its own object: after CreateSubscription enrolls the account, you call CreateProtection naming a specific resource ARN (an ELB, CloudFront distribution, Global Accelerator, Elastic IP, or Route 53 hosted zone). Only resources with an explicit Protection get the enhanced mitigations and DRT support; everything else on the account still has Shield Standard automatically, but not the Advanced tier.
The layering shows up clearly under an actual attack on a CloudFront-fronted API. Shield (Standard or Advanced) absorbs a volumetric flood at the edge before it ever reaches your origin. Requests that get through - because they are individually well-formed, just numerous or malicious in content - are then evaluated by the Web ACL attached to that same distribution. A rate-based WAF rule can independently throttle an IP sending too many requests per five minutes, which is a layer-7 control that complements, but does not replace, Shield's layer-3/4 mitigation.
DRT access requires its own grant. Even with Shield Advanced active, the DDoS Response Team cannot see your logs or WAF configuration unless you explicitly grant access via AssociateDRTLogBucket (S3 access logs) and AssociateDRTRole (an IAM role they can assume). Subscribing to Shield Advanced alone does not open that door.
Cost protection is retroactive, not preventive. Shield Advanced's DDoS cost protection reimburses scaling charges (extra ALB, CloudFront, or Route 53 usage) incurred during a declared event. It does not stop the attack traffic itself from arriving - that is still Shield's mitigation job, WAF's filtering job, or both.
Managed Rule Groups blur the "you write every rule" assumption. Most production Web ACLs lean heavily on AWS Managed Rule Groups (AWSManagedRulesCommonRuleSet, AWSManagedRulesBotControlRuleSet, and similar) referenced via a ManagedRuleGroupStatement, rather than hand-authored ByteMatchStatement/SqliMatchStatement rules for everything. Custom rules typically supplement managed groups for app-specific logic, not replace them.
Scope mismatches are a common first mistake. Creating a Web ACL with Scope=REGIONAL in us-east-1 and trying to associate it with a CloudFront distribution fails - CloudFront needs a CLOUDFRONT-scope Web ACL, and that Web ACL must have been created via a client pointed at us-east-1, even if your other regional resources live elsewhere.
wafv2.CreateProtection per resource ARN; unprotected resources keep only Shield Standard.WAF inspects HTTP(S) request content at the application layer and can allow, block, or rate-limit based on rules. Shield protects against network and transport-layer DDoS attacks and has no visibility into request content.
For most internet-facing production applications, yes. Shield Standard is automatic and free, so at minimum you already have it. Adding a Web ACL is the usual next step; Shield Advanced is worth it once cost protection and DRT support matter.
Yes, it is automatic and free for every AWS account, covering ELB, CloudFront, Route 53, and Global Accelerator against common DDoS attacks.
Near-real-time attack visibility, mitigation for larger and more sophisticated attacks, DDoS cost protection credits, and access to the AWS DDoS Response Team during an incident.
Always WAFV2 (wafv2 in boto3, @aws-sdk/client-wafv2 in SDK v3). Classic WAF is deprecated and should not be used for new work.
REGIONAL is for an ALB, API Gateway, AppSync API, or Cognito pool, created in the resource's own region. CLOUDFRONT is for a CloudFront distribution and must be created via a client pointed at us-east-1, regardless of where the distribution serves traffic.
No. You must separately call AssociateDRTLogBucket and AssociateDRTRole to give the DDoS Response Team access during an incident.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 25 jul 2026