AWS’s October 30, 2026 release lets CloudFront insert the AWS WAF JavaScript SDK tag into application HTML. That can remove recurring work from application releases. But a rollout review should include the distribution’s downloads and media, as well as its web pages.
Start with the eligible web ACL
The announcement limits availability to CloudFront web ACLs containing targeted Bot Control, account takeover prevention or account creation fraud prevention. AWS says the integration has no additional charge; that statement concerns this integration, rather than the complete service bill.
Creation method also matters. The setting defaults on for qualifying new web ACLs created in the console, and off when created programmatically. Existing web ACLs are unchanged. Record the actual setting rather than assuming that a qualifying rule group proves it is enabled.
AWS announcement: October 30 availability and defaults
HTML insertion and request handling have different scopes
The developer guide says tag insertion applies to eligible HTTP 200, uncompressed text/html responses. Separately, enabling the setting removes Range and If-Range headers from requests that WAF allows, across every content type. CloudFront returns the whole object with HTTP 200. AWS identifies effects on media players and download managers, including increased transfer for those requests.
CloudFront also requests allowed objects from the origin without compression, including non-HTML objects. Viewer compression is a separate cache-behavior setting. Treat the origin request and the viewer response as different observations in a trial.
For page verification, AWS recommends checking source in a private browsing window and checking for the aws-waf-token cookie. Its guide also documents unsupported configurations and insertion gaps. Review those limits before relying on automatic insertion for a particular application.
AWS developer guide: requirements, request changes and limitations
Rehearse a fictional mixed-content site
Imagine a training website that delivers lesson pages, recorded audio and downloadable course packs through one distribution. The team opens a lesson and observes the SDK tag. That observation answers a question about that returned page. It leaves the audio player and interrupted-download workflow untested.
A useful review sheet gives each workflow its own row. For the lesson, record the returned page and browser result. For audio, record whether the chosen playback actions complete. For a course pack, record the requested portion, returned status and returned size. These are suggested observations for an authorized trial, not results from a real website.
- Inventory the content and clients using the affected distribution before estimating the trial.
- Compare the same representative workflows before and after a proposed change in a suitable test environment.
- Keep requested behavior, returned response and user-visible outcome in separate columns.
- Leave unresolved workflows visible when deciding whether the proposed rollout is ready.
A successful page check is useful evidence, but it does not complete that worksheet. No AWS account, web ACL, browser SDK, player, download or transfer-cost measurement was tested for this article.