Amazon CloudFront can put a managed edge network in front of a website or API, while AWS Shield and AWS WAF add different kinds of attack protection. A resilient design uses CloudFront as the intended public entry point, protects the origin from direct requests, and applies request rules that match the application. These controls reduce risk; they do not guarantee that every attack is blocked or that an application remains available under every traffic pattern.

Key takeaways

  • Shield Standard is automatically available to AWS customers at no extra charge. It provides baseline protection against common network and transport layer DDoS attacks, including for CloudFront.
  • Shield Advanced is a paid subscription. You must subscribe and add protection for the CloudFront distribution to receive its expanded protections and event visibility.
  • AWS WAF evaluates HTTP and HTTPS requests against rules you configure. Rate limits and managed rules can help with application-layer abuse, but they need testing and tuning.
  • Origin restrictions matter. If an attacker can reach a public origin directly, CloudFront, Shield, and its web ACL may not inspect that path.
  • HTTPS encrypts connections; it does not filter DDoS traffic. Require HTTPS from viewers to CloudFront and from CloudFront to a custom origin, then configure the origin's access controls separately.

How CloudFront, Shield, and WAF fit together

CloudFront is a content delivery network and reverse proxy. It handles viewer requests at AWS edge locations and forwards requests to the configured origin when needed. Caching can reduce origin work for cacheable responses; dynamic requests and cache misses still depend on the origin and application capacity.

AWS Shield is the managed DDoS protection service. Shield Standard is on by default and protects against common network and transport layer attacks. AWS describes particular availability protection for CloudFront distributions, Route 53 hosted zones, and Global Accelerator. The protection you get also depends on how traffic reaches your application and how the application is designed. See the Shield Standard overview.

AWS WAF is a configurable web application firewall. A web ACL can count, allow, or block HTTP(S) requests based on conditions such as IP addresses, request fields, managed rule groups, or request rates. It is useful for application-layer threats, but it does not replace Shield's infrastructure-layer protections. AWS explains the request controls available in a web ACL.

AWS Shield Standard vs. Shield Advanced

Shield Standard requires no setup or separate subscription. It is included at no additional charge and automatically protects AWS customers against common network and transport layer DDoS events. For a CloudFront distribution, this baseline is already in place.

Shield Advanced is for applications that need expanded DDoS protections and event visibility. You must subscribe to Shield Advanced and add the distribution as a protected resource. AWS currently lists a $3,000 monthly subscription fee per payer account for eligible customers, a one-year subscription commitment, and additional data-transfer-out usage charges. Check the current AWS Shield pricing page for the applicable rates and terms before budgeting. For a broader comparison of WAF charges, Shield Advanced inclusions, and CloudFront plans, see our AWS WAF and Shield pricing guide.

The subscription covers standard AWS WAF web ACL, rule, and request charges for Shield-protected resources up to 1,500 web ACL capacity units, the default body-inspection size, and 50 billion WAF requests per month across the payer ID. It does not make every WAF feature free: AWS lists additional charges for some capabilities, including Bot Control, Fraud Control, higher web ACL capacity, and request-body inspection beyond the default size. Review the current Shield Advanced and WAF cost details.

Shield Advanced also provides access to the AWS Shield Response Team (SRT). Current AWS DDoS guidance lists Business Support+, Enterprise Support, or Unified Operations as eligible plans for escalating an event. Some Shield-specific pages still use the predecessor “Business Support” name; AWS's support-plan notice says that plan is scheduled to end January 1, 2027, with separate GovCloud treatment. Check your account's plan before assuming SRT access. Proactive engagement is a separate opt-in and uses a Route 53 health check associated with the protected resource. See the current AWS DDoS support guidance, support plan notice, and health-based detection guidance.

Shield Advanced cost protection is also conditional. Eligible customers can request credits for certain attack-driven charges on resources that were protected before the attack; this is not a general cap on the AWS bill. AWS lists additional prerequisites for CloudFront and Application Load Balancer resources, including an associated web ACL with a rate-based rule in Block mode. Review the current service-credit eligibility requirements.

Shield Advanced is not a substitute for an AWS WAF policy. Associate a web ACL with CloudFront when you need custom request filtering or WAF-based application-layer controls. When creating CloudFront-scoped WAF resources, use the Global (CloudFront) scope, which is managed in US East (N. Virginia), us-east-1.

Setting up protection for a CloudFront distribution

Shield Standard and Advanced setup

There is nothing to enable for Shield Standard. For Shield Advanced, subscribe in the AWS WAF and Shield console, then add the CloudFront distribution to the protected resources. Follow the Shield Advanced workflow to associate a web ACL and configure the protections you need. If you manage multiple accounts, AWS Firewall Manager can apply Shield policies centrally; use its Global scope for CloudFront distributions.

Layer 7 guidance is changing in 2026. AWS is moving Shield Advanced application-layer automatic mitigation to the AWS WAF Anti-DDoS managed rule group. AWS's current migration announcement says automatic migration is scheduled through October 24, 2026, and the legacy Shield Advanced application-layer automatic mitigation is scheduled to end January 29, 2027. Check the current Shield Advanced migration guidance and inspect each web ACL's status; older setup instructions may describe the legacy feature.

Configure HTTPS and origin access separately

HTTPS protects data in transit between a viewer and CloudFront, and between CloudFront and a custom origin. Set the viewer protocol policy to redirect HTTP to HTTPS or accept HTTPS only. For a custom origin, set CloudFront's origin protocol policy to HTTPS only when the origin supports a valid certificate. These settings encrypt the connections, but they do not prevent a direct request to a public origin. AWS documents the protocol behavior for custom origins.

DDoS protection best practices

Use AWS WAF for application-layer rules

Associate an AWS WAF web ACL with the CloudFront distribution when you need rules for web requests. Use managed rules to address the threats they are designed for, and add rate-based rules for endpoints that need request-rate controls. A rate limit can reduce abusive traffic, but attackers can distribute requests across many sources and legitimate users can share addresses, so a single IP threshold is not a complete DDoS strategy.

Start new or changed rules in Count or monitor mode where available. Review sampled requests and logs, then enable blocking only after confirming the rules do not interfere with expected users. If you configure the AWS WAF Anti-DDoS managed rule group, test its sensitivity and any Challenge action with your clients. AWS warns that browser-based single-page applications and native mobile API clients may need integration work to handle challenges. See AWS's current guidance for the Anti-DDoS managed rule group, client compatibility, and monitoring WAF protections before blocking.

Do not use geographic blocks or broad IP blocks just because traffic looks unusual. First check whether the traffic matches your application's real access patterns and business requirements.

Prevent requests from bypassing CloudFront

CloudFront, Shield, and a CloudFront-associated web ACL protect the path that passes through the distribution. Restrict the origin as well, or an attacker may use its public hostname or IP address to bypass those controls and target the application directly.

For an Amazon S3 bucket origin, use Origin Access Control (OAC) with the regular S3 bucket endpoint, then update the bucket policy so the intended CloudFront distribution can read objects. Review public access settings and remove any other permission that would allow direct anonymous reads; OAC does not revoke them by itself. OAC does not apply to an S3 static website endpoint; that endpoint also cannot use HTTPS between CloudFront and S3. See AWS's guide to restricting access to an S3 origin.

CloudFront also supports a separate OAC type for Lambda function URL origins, which requires the function URL's authentication type to be AWS_IAM; follow its Lambda origin setup. For an Application Load Balancer, EC2 instance, or other custom origin, OAC is not the general-purpose option. One approach is to configure CloudFront to send a secret custom header and make the origin reject requests without the expected value. Keep the value secret, use HTTPS, and rotate it periodically. Where supported, CloudFront VPC origins let you place an ALB, NLB, or EC2 origin in private subnets and use CloudFront as the public entry point. Check the current custom-origin access guidance and VPC origin requirements. If your custom origin is an ALB, our Application Load Balancer setup guide covers listener, certificate, and security-group configuration.

Do not assume a secret header alone makes an origin private. The origin must validate it, and its network path should admit only the traffic sources your design intends to allow. Test that a direct-origin request fails after you change access controls.

Monitor traffic and attack signals

The CloudFront security dashboard combines CloudFront and AWS WAF security information. You must enable AWS WAF to see its request security metrics; without WAF, the dashboard cannot show allowed and blocked request trends. WAF logging can help identify request paths and sources, but log ingestion and queries may add CloudWatch charges. See the CloudFront security dashboard requirements.

Shield Advanced publishes DDoS detection and mitigation metrics in CloudWatch for protected resources. For global services such as CloudFront, view these metrics in us-east-1. The DDoSDetected metric is a useful signal, not proof by itself that an attack is in progress; AWS recommends investigating resource health and combining request-flood signals with application health and request volume. See the Shield Advanced metrics reference.

Set alarms from your normal traffic and availability patterns instead of copying a generic request threshold. Correlate CloudFront request and error metrics, WAF allowed and blocked requests, origin health, and the user-facing symptoms. A traffic increase can be a legitimate launch or event; a DDoS indicator can also be mitigated before it causes an outage. Keep a runbook that tells the on-call team what to inspect, who can change WAF rules, and how to confirm that legitimate traffic still works.

Respond and review after an event

During an incident, confirm which entry points and origins are affected, compare viewer traffic with origin load, and review WAF and Shield event details that are available for your configuration. If you have Shield Advanced and the required support plan, contact the SRT through AWS Support for help analyzing and responding to the event. Avoid making broad emergency blocks without checking their effect on legitimate requests.

Afterward, record the event window, affected resources, user impact, rules or mitigations applied, and any service or data-transfer costs. Use that evidence to tune rules, caching, origin restrictions, application capacity, and the response runbook. CloudFront and Shield reduce exposure, but application resilience still depends on origin capacity, cache behavior, dependencies, and a tested recovery plan.

Conclusion

CloudFront gives an application a managed edge entry point, Shield Standard provides automatic baseline DDoS protection, and Shield Advanced adds paid protections and event support for resources you explicitly protect. AWS WAF controls HTTP(S) requests through a web ACL associated with CloudFront. These services have different roles: combine them where they fit the workload, secure the origin against direct access, and monitor both attack signals and application health.