Last week, Strands Agents, AWS open source for agentic AI SDK just hit 1 million downloads and earned 3,000+ GitHub Stars less than 4 months since launching as a preview in May 2025. With Strands Agents, you can build production-ready, multi-agent AI systems in a few lines of code. We’ve continuously improved features including support […]

A widespread malicious campaign has been uncovered deploying dozens of spoofed websites designed to impersonate popular Windows utilities, developer toolkits,

Last week, Strands Agents, AWS open source for agentic AI SDK just hit 1 million downloads and earned 3,000+ GitHub Stars less than 4 months since launching as a preview in May 2025. With Strands Agents, you can build production-ready, multi-agent AI systems in a few lines of code. We’ve continuously improved features including support […]

Today, Amazon CloudFront announces support for HTTPS resource records in Amazon Route 53.HTTPS resource records allow domain name systems (DNS) such as Amazon Route 53 to provide additional information such as supported HTTP protocol versions and port numbers before the HTTP connection is attempted. This helps clients establish the initial connection using their preferred HTTP protocol to improve application performance and security. By using the HTTPS DNS records during DNS lookup, clients can discover the CloudFront capabilities that boost application performance and security. For example, clients can identify if HTTP/3 is enabled on the CloudFront distribution, without the need for additional round-trips (RTT) to negotiate HTTP protocols after the DNS lookup. This can reduce application load times, especially in regions with limited network infrastructure. By providing secure connection information upfront, HTTPS DNS records streamline the process of establishing secure connections to CloudFront distributions. Additionally, customers using Route 53 can benefit from free HTTPS record queries when using CloudFront alias records, reducing DNS costs. HTTPS DNS records are supported from all edge locations. This excludes Amazon Web Services China (Beijing) region, operated by Sinnet, and the Amazon Web Services China (Ningxia) region, operated by NWCD. To learn more about implementing this feature and its benefits, read our detailed blog post.

Amazon CloudFront now supports bringing your own IPv6 addresses (BYOIP) for Anycast Static IPs via VPC IP Address Manager (IPAM). This capability enables network administrators to use their own public IPv4 and IPv6 address pools with CloudFront distributions, simplifying IP address management across AWS's global infrastructure. CloudFront typically uses rotating IP addresses to serve traffic. CloudFront Anycast Static IPs enables customers to provide a dedicated list of IP addresses to partners and customers, enhancing security and simplifying network management. Previously, customers implementing BYOIP with Anycast Static IPs could only bring their own IPv4 addresses (/24 blocks). With IPAM's unified interface, customers can now create dedicated IP address pools using BYOIP for IPv4 (/24) and IPv6 (/48), and assign them to CloudFront Anycast Static IP lists in a dual-stack configuration. Customers do not need to change the existing IP address space for their applications when they migrate to CloudFront, thus maintaining existing allow-lists and branding for both IPv4 and IPv6 clients.   The feature is available within Amazon VPC IPAM in all commercial AWS Regions except the Middle East (Bahrain), Middle East (UAE), AWS GovCloud (US) Regions, and China (Beijing, operated by Sinnet) and China (Ningxia, operated by NWCD). To learn more about CloudFront BYOIP feature, view the BYOIP CloudFront documentation. For details on pricing, refer to the IPAM tab on the Amazon VPC Pricing Page.

Amazon Web Services (AWS) is launching flat-rate pricing plans with no overages for website delivery and security. The flat-rate plans, available with Amazon CloudFront, combine global content delivery with AWS WAF, DDoS protection, Amazon Route 53 DNS, Amazon CloudWatch Logs ingestion, and serverless edge compute into a simple monthly price with no overage charges. Each plan also includes monthly Amazon S3 storage credits to help offset your storage costs. CloudFront flat-rate plans allow you to deliver your websites and applications without calculating costs across multiple AWS services. You won’t face the risk of overage charges, even if your website or application goes viral or faces a DDoS attack. Security features like WAF and DDoS protection are enabled by default, and additional configurations are simple to set up. When you serve your AWS applications through CloudFront instead of directly to the internet, your flat-rate plan covers the data transfer costs between your applications and your viewers for a simple monthly price without the worry of overages. This simplified pricing model is available alongside pay-as-you-go pricing for each CloudFront distribution, giving you the flexibility to choose the right pricing model and feature set for each application. Plans are available in Free ($0/month), Pro ($15/month), Business ($200/month), and Premium ($1,000/month) tiers for new and existing CloudFront distributions. Select the plan tier with the features and usage allowances matching your application’s needs. To learn more, refer to the Launch Blog, Plans and Pricing, or CloudFront Developer Guide. To get started, visit the CloudFront console.

Amazon CloudFront expands its IPv6 capabilities by introducing support for IPv6 connectivity to origin servers, allowing customers to implement end-to-end IPv6 content delivery for their web applications. Support for IPv6 origins enables customers to send IPv6 traffic all the way to their origins, allowing them to meet their architectural and regulatory requirements for IPv6 adoption. End-to-end IPv6 support improves network performance for end users connecting over IPv6 networks, and also removes concerns for IPv4 address exhaustion for origin infrastructure. Previously, CloudFront only supported IPv4 connectivity to origins, despite accepting IPv6 connections from end users. Customers using CloudFront can configure their custom origins to use IPv4-only (default), IPv6-only, or dual-stack connectivity. When using dual-stack, CloudFront will automatically choose between IPv4 and IPv6 addresses to ensure even distribution of traffic towards origin over both. Customers can configure IPv6 origins in all supported AWS Commercial Regions. Customers can configure IPv6-only or dual-stack origins with CloudFront, excluding Amazon S3 and VPC origins. To learn more IPv6 support with CloudFront, visit the CloudFront documentation.

Securely deliver high-performance web apps with CloudFront VPC origins; serve content directly from private subnets, eliminating undifferentiated work.

Amazon CloudFront now supports Elliptic Curve Digital Signature Algorithm (ECDSA) for signed URLs and signed cookies, providing customers with enhanced performance and security for content access control. This addition gives customers the flexibility to choose between RSA and ECDSA cryptographic algorithms based on their specific security and performance requirements. Previously, CloudFront only supported RSA based encryption algorithms to create signed tokens. ECDSA offers several advantages over traditional RSA signatures, including faster signature generation and verification, smaller signature sizes that result in shorter URLs, and equivalent security with smaller key sizes. This makes ECDSA signed URLs and signed cookies particularly beneficial for high-volume applications, mobile environments, and IoT devices where processing efficiency and bandwidth optimization are critical. ECDSA support with signed URLs and signed cookies is available in all edge locations. This excludes Amazon Web Services China (Beijing) region, operated by Sinnet, and the Amazon Web Services China (Ningxia) region, operated by NWCD. There is no additional charge to utilize this feature. To learn more about restricting content delivered with Amazon CloudFront, visit the CloudFront documentation.

Amazon CloudFront now supports three new capabilities for CloudFront Functions: edge location and Regional Edge Cache (REC) metadata, raw query string retrieval, and advanced origin overrides. Developers can now build more sophisticated edge computing logic with greater visibility into CloudFront's infrastructure and precise, granular control over origin connections. CloudFront Functions allows you to run lightweight JavaScript code at CloudFront edge locations to customize content delivery and implement security policies with sub-millisecond execution times. Edge location metadata, includes the three-letter airport code of the serving edge location and the expected REC. This enables geo-specific content routing or compliance requirements, such as directing European users to GDPR-compliant origins based on client location. The raw query string capability provides access to the complete, unprocessed query string as received from the viewer, preserving special characters and encoding that may be altered during standard parsing. Advanced origin overrides solve critical challenges for complex application infrastructures by allowing you to customize SSL/TLS handshake parameters, including Server Name Indication (SNI). For example, multi-tenant setups may override SNI where CloudFront connects through CNAME chains that resolve to servers with different certificate domains. These new CloudFront Functions capabilities are available at no additional charge in all CloudFront edge location. To learn more about CloudFront Functions, see the https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html.

Amazon CloudFront announces support for mutual TLS Authentication (mTLS), a security protocol that requires both the server and client to authenticate each other using X.509 certificates, enabling customers to validate client identities at CloudFront's edge locations. Customers can now ensure only clients presenting trusted certificates can access their distributions, helping protect against unauthorized access and security threats. Previously, customers had to spend ongoing effort implementing and maintaining their own client access management solutions, leading to undifferentiated heavy lifting. Now with the support for mutual TLS, customers can easily validate client identities at the AWS edge before connections are established with their application servers or APIs. Example use cases include B2B secure API integrations for enterprises and client authentication for IoT. For B2B API security, enterprises can authenticate API requests from trusted third parties and partners using mutual TLS. For IoT use cases, enterprises can validate that devices are authorized to receive proprietary content such as firmware updates. Customers can leverage their existing third-party Certificate Authorities or AWS Private Certificate Authority to sign the X.509 certificates. With Mutual TLS, customers get the performance and scale benefits of CloudFront for workloads that require client authentication. Mutual TLS authentication is available to all CloudFront customers at no additional cost. Customers can configure mutual TLS with CloudFront using the AWS Management Console, CLI, SDK, CDK, and CloudFormation. For detailed implementation guidance and best practices, visit CloudFront Mutual TLS (viewer) documentation.

Amazon CloudFront now supports origin modification within CloudFront Functions, enabling you to conditionally change or update origin servers on each request. You can now write custom logic in CloudFront Functions to overwrite origin properties, use another origin in your CloudFront distribution, or forward requests to any public HTTP endpoint. Origin modification allows you to create custom routing policies for how traffic should be forwarded to your application servers on cache misses. For example, you can use origin modification to determine the geographic location of a viewer and then forward the request, on cache misses, to the closest AWS Region running your application. This ensures the lowest possible latency for your application. Previously, you had to use AWS Lambda@Edge to modify origins, but now this same capability is available in CloudFront Functions with better performance and lower costs. Origin modification supports updating all existing origin capabilities such as setting custom headers, adjusting timeouts, setting Origin Shield, or changing the primary origin in origin groups. Origin modification is now available within CloudFront Functions at no additional charge. For more information, see the CloudFront Developer Guide. For examples of how to use origin modification, see our GitHub examples repository.

Amazon CloudFront now supports Elliptic Curve Digital Signature Algorithm (ECDSA) for signed URLs and signed cookies, providing customers with enhanced performance and security for content access control. This addition gives customers the flexibility to choose between RSA and ECDSA cryptographic algorithms based on their specific security and performance requirements. Previously, CloudFront only supported RSA based encryption algorithms to create signed tokens. ECDSA offers several advantages over traditional RSA signatures, including faster signature generation and verification, smaller signature sizes that result in shorter URLs, and equivalent security with smaller key sizes. This makes ECDSA signed URLs and signed cookies particularly beneficial for high-volume applications, mobile environments, and IoT devices where processing efficiency and bandwidth optimization are critical. ECDSA support with signed URLs and signed cookies is available in all edge locations. This excludes Amazon Web Services China (Beijing) region, operated by Sinnet, and the Amazon Web Services China (Ningxia) region, operated by NWCD. There is no additional charge to utilize this feature. To learn more about restricting content delivered with Amazon CloudFront, visit the https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html#private-content-how-signed-urls-work 

Amazon CloudFront announces support for hybrid post-quantum key establishment across all existing Transport Layer Security (TLS) security policies, providing enhanced protection against future quantum computing threats for client-to-edge connections. Additionally, CloudFront launched a new TLS 1.3 only security policy that enhances TLS options between viewers and edge locations. These updates allow customers to leverage quantum-resistant encryption while having more flexibility in configuring their CloudFront distributions to meet specific security and compliance requirements. The post-quantum cryptography (PQC) capabilities are automatically enabled for client-to-edge connections, providing future-proof encryption that ensures long-term data security and regulatory compliance readiness. PQC support is available on all existing security policies by default, requiring no customer configuration. The new TLS1.3_2025 policy, which supports TLS 1.3 only, enables customers to leverage the latest TLS protocol, which provides improved security and performance compared to earlier TLS versions. This is particularly useful for organizations that enforce using the most up-to-date security standards. These PQC capabilities and new security policy are available in all CloudFront edge locations. There are no additional charges for using PQC or the TLS1.3_2025 policy. To learn more about Post Quantum Cryptography and this new TLS policy and how to implement them in your CloudFront distributions, visit the CloudFront documentation. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html.

Today, Amazon CloudFront announces support for HTTPS resource records in Amazon Route 53.HTTPS resource records allow domain name systems (DNS) such as Amazon Route 53 to provide additional information such as supported HTTP protocol versions and port numbers before the HTTP connection is attempted. This helps clients establish the initial connection using their preferred HTTP protocol to improve application performance and security. By using the HTTPS DNS records during DNS lookup, clients can discover the CloudFront capabilities that boost application performance and security. For example, clients can identify if HTTP/3 is enabled on the CloudFront distribution, without the need for additional round-trips (RTT) to negotiate HTTP protocols after the DNS lookup. This can reduce application load times, especially in regions with limited network infrastructure. By providing secure connection information upfront, HTTPS DNS records streamline the process of establishing secure connections to CloudFront distributions. Additionally, customers using Route 53 can benefit from free HTTPS record queries when using CloudFront alias records, reducing DNS costs. HTTPS DNS records are supported from all edge locations. This excludes Amazon Web Services China (Beijing) region, operated by Sinnet, and the Amazon Web Services China (Ningxia) region, operated by NWCD. To learn more about implementing this feature and its benefits, read our detailed https://aws.amazon.com/blogs/networking-and-content-delivery/boost-application-performance-amazon-cloudfront-enables-https-record/.  

Amazon CloudFront announces support for hybrid post-quantum key establishment across all existing Transport Layer Security (TLS) security policies, providing enhanced protection against future quantum computing threats for client-to-edge connections. Additionally, CloudFront launched a new TLS 1.3 only security policy that enhances TLS options between viewers and edge locations. These updates allow customers to leverage quantum-resistant encryption while having more flexibility in configuring their CloudFront distributions to meet specific security and compliance requirements. The post-quantum cryptography (PQC) capabilities are automatically enabled for client-to-edge connections, providing future-proof encryption that ensures long-term data security and regulatory compliance readiness. PQC support is available on all existing security policies by default, requiring no customer configuration. The new TLS1.3_2025 policy, which supports TLS 1.3 only, enables customers to leverage the latest TLS protocol, which provides improved security and performance compared to earlier TLS versions. This is particularly useful for organizations that enforce using the most up-to-date security standards. These PQC capabilities and new security policy are available in all CloudFront edge locations. There are no additional charges for using PQC or the TLS1.3_2025 policy. To learn more about Post Quantum Cryptography and this new TLS policy and how to implement them in your CloudFront distributions, visit the CloudFront documentation. CloudFront documentation.

Amazon CloudFront now supports https://datatracker.ietf.org/doc/html/rfc8392 and Common Access Tokens (CAT), enabling secure token-based authentication and authorization with CloudFront Functions at CloudFront edge locations. CWT provides a compact, binary alternative to JSON Web Tokens (JWT) using https://datatracker.ietf.org/doc/html/rfc8949 encoding, while CAT extends CWT with additional fine grained access control including URL patterns, IP restrictions, and HTTP method limitations. Both token types use https://datatracker.ietf.org/doc/html/rfc8152 for enhanced security and allow developers to implement lightweight, high-performance authentication mechanisms directly at the edge with sub-millisecond execution times. CWT and CAT are ideal for performance critical applications such as live video streaming platforms that need to validate viewer access tokens millions of times per second, or IoT applications where bandwidth efficiency is crucial. These tokens also provide a single, standardized method for content authentication across multi-CDN deployments, simplifying security management and preventing the need for unique configurations for each CDN provider. For example, a media company can use CAT to create tokens that restrict access to specific video content based on subscription tiers, geographic location, and device types, all validated consistently across CloudFront and other CDN providers without requiring application network calls. With CWT and CAT support, you can validate incoming tokens, generate new tokens, and implement token refresh logic within CloudFront Functions. The feature integrates seamlessly with CloudFront Functions KeyValueStore for secure key management. CWT and CAT support for CloudFront Functions is available at no additional charge in all CloudFront edge locations. To learn more about CloudFront Functions CBOR Web Token support, see the https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cwt-support-cloudfront-functions.html.

Amazon CloudFront now supports CBOR Web Tokens (CWT) and Common Access Tokens (CAT), enabling secure token-based authentication and authorization with CloudFront Functions at CloudFront edge locations. CWT provides a compact, binary alternative to JSON Web Tokens (JWT) using Concise Binary Object Representation (CBOR) encoding, while CAT extends CWT with additional fine grained access control including URL patterns, IP restrictions, and HTTP method limitations. Both token types use CBOR Object Signing and Encryption (COSE) for enhanced security and allow developers to implement lightweight, high-performance authentication mechanisms directly at the edge with sub-millisecond execution times. CWT and CAT are ideal for performance critical applications such as live video streaming platforms that need to validate viewer access tokens millions of times per second, or IoT applications where bandwidth efficiency is crucial. These tokens also provide a single, standardized method for content authentication across multi-CDN deployments, simplifying security management and preventing the need for unique configurations for each CDN provider. For example, a media company can use CAT to create tokens that restrict access to specific video content based on subscription tiers, geographic location, and device types, all validated consistently across CloudFront and other CDN providers without requiring application network calls. With CWT and CAT support, you can validate incoming tokens, generate new tokens, and implement token refresh logic within CloudFront Functions. The feature integrates seamlessly with CloudFront Functions KeyValueStore for secure key management. CWT and CAT support for CloudFront Functions is available at no additional charge in all CloudFront edge locations. To learn more about CloudFront Functions CBOR Web Token support, see the Amazon CloudFront Developer Guide.

Previously, the Amazon CloudFront Premium flat-rate plan supported a single usage allowance, and customers who outgrew it needed to contact us to discuss custom pricing options. Now, the Premium plan offers a range of self-service monthly usage levels ranging from 500 million to 6 billion requests and 50 TB to 600 TB, so customers can scale within the plan as their applications grow. Enterprises and mid-sized businesses whose baseline traffic previously made them ineligible for flat-rate plans can now adopt the Premium plan at a usage level that fits their application. You select your Premium plan usage level in the CloudFront console, see your new monthly flat-rate price instantly, and can change your usage level at any time with no commitment required. All Premium plan features are included at every usage level. Flat-rate plans provide a single monthly price covering content delivery, AWS WAF and DDoS protection, bot management, Amazon Route 53 DNS, Amazon CloudWatch Logs ingestion, serverless edge compute, and Amazon S3 storage credits — with no overage charges. To get started, visit the CloudFront console. To learn more, refer to the Launch Blog or Amazon CloudFront Developer Guide.

Amazon CloudFront now supports both IPv4 and IPv6 addresses for Anycast Static IP configurations. Previously, this feature was limited to IPv4 addresses only. This update now provides customers with ability to have both IPv4 and IPv6 addresses when using CloudFront Anycast Static IP addresses. Previously, customers could only use IPv4 addresses when using CloudFront Anycast static IP addresses. With this launch, customers using CloudFront Anycast Static IP addresses receive both IPv4 and IPv6 addresses for their workloads. This dual-stack support allows customers to meet IPv6 compliance requirements, future-proof their infrastructure, and serve end users on IPv6-only networks. CloudFront supports IPv6 for Anycast Static IPs from all edge locations. This excludes Amazon Web Services China (Beijing) region, operated by Sinnet, and the Amazon Web Services China (Ningxia) region, operated by NWCD. Learn more about Anycast Static IPs here and for more information, please refer to the Amazon CloudFront Developer Guide. For pricing, please see CloudFront Pricing.

Amazon CloudFront announces support for mutual TLS Authentication (mTLS), a security protocol that requires both the server and client to authenticate each other using X.509 certificates, enabling customers to validate client identities at CloudFront's edge locations. Customers can now ensure only clients presenting trusted certificates can access their distributions, helping protect against unauthorized access and security threats. Previously, customers had to spend ongoing effort implementing and maintaining their own client access management solutions, leading to undifferentiated heavy lifting. Now with the support for mutual TLS, customers can easily validate client identities at the AWS edge before connections are established with their application servers or APIs. Example use cases include B2B secure API integrations for enterprises and client authentication for IoT. For B2B API security, enterprises can authenticate API requests from trusted third parties and partners using mutual TLS. For IoT use cases, enterprises can validate that devices are authorized to receive proprietary content such as firmware updates. Customers can leverage their existing third-party Certificate Authorities or https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html to sign the X.509 certificates. With Mutual TLS, customers get the performance and scale benefits of CloudFront for workloads that require client authentication. Mutual TLS authentication is available to all CloudFront customers at no additional cost. Customers can configure mutual TLS with CloudFront using the AWS Management Console, CLI, SDK, CDK, and CloudFormation. For detailed implementation guidance and best practices, visit https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/mtls-authentication.html.

Amazon CloudFront announces cross-account support for Virtual Private Cloud (VPC) origins, enabling customers to access VPC origins that reside in different AWS accounts from their CloudFront distributions. With VPC origins, customers can have their Application Load Balancers (ALB), Network Load Balancers (NLB), and EC2 Instances in a private subnet that is accessible only through their CloudFront distributions. With the support for cross-account VPC origins in CloudFront, customers can now leverage the security benefits of VPC origins while maintaining their existing multi-account architecture. Customers set up multiple AWS accounts for better security isolation, cost management, and compliance. Previously, customers could access origins in private VPCs from CloudFront only if CloudFront and the origin were in the same AWS account. This meant customers who had their origins in multiple AWS accounts, had to keep their accounts in public subnets to get the scale and performance benefits of CloudFront. Customers then had to maintain additional security controls, such as access control lists (ACL), at both the edge and within regions, rather than benefiting from the inherent security of VPC origins. Now, customers can use AWS Resource Access Manager (RAM) to allow CloudFront access to origins in private VPCs in different AWS accounts, both within and outside their AWS Organizations and organizational units (OUs). This streamlines security management and reduces operational complexity, making it easy to use CloudFront as the single front door for applications. VPC origins is available in AWS Commercial Regions only, and the full list of supported AWS Regions is available here. There is no additional cost for using cross-account VPC origins with CloudFront. To learn more about implementing cross-account VPC origins and best practices for multi-account architectures, visit CloudFront VPC origins.

Today, AWS WAF announced AI traffic monetization, a new Bot Control capability that lets you price, meter, and collect payment from AI bots and agents accessing your content and APIs. As AI agents increasingly support autonomous payments for the content and APIs they consume, AWS WAF now lets content owners and publishers set a price for that access, accept payment through third-party providers, and grant scoped access directly at the edge. When an AI bot or agent requests a protected resource like an article, a data feed, or a licensed archive, AWS WAF returns a machine-readable HTTP 402 Payment Required response using the x402 open protocol for machine-to-machine payments. The response contains your prices to access the content, accepted payment methods, and license terms. The agent presents proof of payment, AWS WAF verifies it at the edge, issues a scoped access token, and serves the response within a single request cycle. With AWS WAF AI traffic monetization, you can configure pricing through the AWS WAF console, define AI bot or agent policies based on verification status (including Web Bot Auth signatures), and receive payouts in stablecoins to your preferred wallet. AWS WAF’s integration with payment settlement and verification flows are provided by Coinbase’s x402 Facilitator. Integration with Stripe for direct account payments and Machine Payments Protocol (MPP) support is coming soon. Publishers can apply differentiated pricing based on agent identity and intent, allow verified AI search crawlers at one price while charging a different price to unverified agents or training crawlers, and validate end-to-end configuration in test mode before going live. Revenue analytics are available directly in the AWS WAF console alongside the AI traffic analysis dashboard, giving publishers a unified view of agent traffic and the revenue it generates. Publishers receive payments directly from agents and manage disbursement through their chosen payment provider. AI traffic monetization is available to AWS WAF customers at no additional charge. Standard AWS WAF charges apply. Refer to https://aws.amazon.com/waf/pricing/ for details.  This capability is available in all edge locations where AWS WAF Web ACLs are associated with Amazon CloudFront distributions. To get started, visit the http://console.aws.amazon.com/wafv2-pro or explore the AWS WAF Developer Guide.

Effective October 25, 2024, all CloudFront requests blocked by AWS WAF are free of charge. With this change, CloudFront customers will never incur request fees or data transfer charges for requests blocked by AWS WAF. This update requires no changes to your applications and applies to all CloudFront distributions using AWS WAF. AWS WAF will continue billing for evaluating and blocking these requests. To learn more about using AWS WAF with CloudFront, visit Use AWS WAF protections in the CloudFront Developer Guide.