The mechanism is one HTTP status code. When a bot that AWS classifies as an AI agent requests a page you have priced, the request never reaches your origin. AWS WAF answers with 402 Payment Required and a machine-readable price list, the agent presents a signed payment authorisation, AWS verifies it at the edge, issues a scoped access token and serves the content, all inside a single request cycle. Your application code does not change. Human readers see nothing different. What changes is that a crawl becomes a transaction, and a fetch you previously either absorbed silently or refused outright becomes something with a price attached to it.
What AWS actually launched
AI traffic monetization is a capability inside AWS WAF Bot Control, announced on 15 June 2026 and now generally available. Bot Control already gave AWS customers visibility into bot activity and the ability to block or rate-limit it. What it could not do, in AWS's own framing, was set a price and collect payment. That is the gap this closes.
AWS puts the case for it in the same terms publishers have been using for two years. In its launch post, AWS states that AI bot traffic now accounts for more than 50% of web traffic for many content providers, and that AI-specific crawlers are growing more than 300% year on year. It draws the distinction that matters commercially: traditional search crawlers index content and return measurable referral traffic, while AI bots consume the same content to generate summaries and answers inside AI interfaces, with little or no traffic sent back to the source. The publisher pays the serving cost and receives none of the page views, ad impressions or subscription conversions that normally offset it.
The configuration unit is called a protection pack. A pack defines which content paths are monetised, what each agent tier is charged, which payment methods you accept and what licence terms apply. You can run several packs against the same CloudFront distribution and price different content zones differently, so an archive, a live data feed and a general news section can each carry their own rate.
One hard constraint is worth knowing before you plan anything. The Monetize action is supported only on web ACLs associated with an Amazon CloudFront distribution. Adding it to a regional web ACL is not supported. If your CDN is not CloudFront, this product is not available to you.
How the payment actually works
When a Monetize rule matches, AWS WAF returns HTTP 402 with a JSON price manifest in the body, formatted using the x402 open protocol for machine-to-machine payments. The manifest carries the price in USDC, the accepted blockchain networks, the destination wallet address, the maximum payment timeout and the payment scheme. Any x402-compatible agent runtime can read that manifest and complete the flow autonomously, with no human in the loop and no prior commercial relationship between the publisher and the AI company.
Settlement and verification run through Coinbase's x402 Facilitator. Publishers nominate one or more supported networks, currently including Base and Solana, and receive payouts in stablecoins to a wallet address of their choosing, self-managed or held with a provider such as Coinbase. AWS states plainly that it does not process payments and takes no fee on content revenue, and that disbursement is self-managed or handled by your wallet provider. Integration with Stripe for direct account payments, and support for the Machine Payments Protocol, are both described as coming soon.
There is a test mode, and it is more useful than most. Toggling currency mode to Test runs the full payment flow identically to production but on a test chain such as Base Sepolia or Solana Devnet, using test funds from a faucet, with every event logged as CurrencyMode: TEST. That means you can validate pricing, wallet configuration and the x402 handshake against real bot traffic before a single real dollar moves.
What you can charge, and to whom
Pricing is set per agent verification tier rather than per crawler, which is the design decision with the most editorial consequence.
AWS WAF Bot Control classifies over 650 distinct AI bot and agent types, including GPTBot, Claude-Web and Perplexity-Bot, and sorts them into two tiers. Verified means the agent's identity is confirmed cryptographically through a Web Bot Auth Ed25519 signature, or sourced from a documented IP range with a known set of user agents and domain names. Unverified means the agent was recognised through user-agent matching, behavioural fingerprinting and IP reputation, but its identity was never cryptographically confirmed.
For each tier you assign one of six actions: Monetize, which returns the 402 and the price; Allow, which grants free access; Block, which denies it; Count, which logs the request without charging; CAPTCHA; or Challenge. That set is what makes differentiated policy possible rather than theoretical. AWS's own suggested pattern is to let a verified AI search crawler through at one price while charging a different price to unverified agents or training crawlers, which is the same Search-versus-Training distinction the rest of the industry converged on this year.
Two dashboards sit alongside the configuration. AI traffic analysis breaks traffic into all bot requests, AI bot requests, verified AI bot traffic and unverified AI bot traffic, and surfaces bandwidth consumed, estimated monthly cost and peak request rates, with a per-path heatmap showing which paths draw the most bot activity by hour. AI access monetization then reports total revenue, the split between verified and unverified bots, average revenue per request, top revenue sources by bot category, and a settlements tab for reconciling payments and reviewing failed attempts. The analysis dashboard is worth running on its own for a fortnight before you price anything, because it answers the question most publishers cannot currently answer: which of your URLs are actually expensive to serve to machines.
Why an AWS launch matters more than another vendor launch
Access charging stopped being a specialist product this year. Cloudflare moved from Pay Per Crawl to Pay Per Use on 1 July 2026 and will change its default handling of AI crawlers on ad-supported pages on 15 September 2026. Akamai applies policy per bot, per path and per price through partnerships with TollBit and Skyfire. TollBit runs a marketplace across several thousand sites. AWS is different in three specific ways.
It is native, so there is no additional vendor, contract or integration if you are already behind CloudFront. It is free, in that AI traffic monetization carries no charge beyond standard AWS WAF pricing and AWS takes no share of what you earn, which is a sharper commercial position than any intermediary that clips a percentage. And it is default-off rather than default-on, which is the opposite of Cloudflare's approach and means nothing happens to your traffic until you decide it should.
The scale point is the real one. A capability inside AWS WAF is available to a very large share of the commercial web by default, which does more to normalise per-request charging than any number of specialist launches. It also puts real institutional weight behind x402. Coinbase contributed that protocol to the Linux Foundation, which announced the operational launch of the x402 Foundation on 14 July 2026 with 40 member organisations signed up since the April intent to launch. Premier members include AWS, Cloudflare, Coinbase, Google, Stripe, Visa, Mastercard, American Express, Adyen, Circle, Fiserv, Ripple, Shopify and the Solana Foundation. Peyton Rice, general manager of AWS Payments and Fraud Prevention, framed it as proposing "an open protocol for AI agents to transact programmatically". x402 revives a status code that has sat reserved and largely unused since HTTP/1.1.
Read that membership list carefully, though, because it is a payments and infrastructure roster. Of the frontier model developers, only Google appears on it. The companies operating the crawlers you would be billing are, with that exception, not in the room.
The limitation nobody should skip
A price is not revenue. It is an offer, and it only becomes revenue if the agent on the other end has a wallet, a budget and instructions to spend. Most crawlers hitting publisher sites today have none of those things. Cloudflare has reported returning on the order of a billion HTTP 402 responses a day, and that figure should be read carefully: a 402 is a refusal with a price attached, not a payment. The overwhelming majority of those responses end the conversation rather than starting a transaction.
So the realistic near-term outcome of switching Monetize on is not a new revenue line. It is a more precisely instrumented block, with an open door for the small number of agent runtimes built to walk through it. That is still worth having, and it is strictly better than an undifferentiated 403, because it converts automatically the day an AI company decides paying is cheaper than negotiating. But a publisher who models this as replacement revenue for lost referral traffic in the next two quarters will be disappointed.
There is a second-order objection worth taking seriously as well. Open-source advocates and independent developers have argued that metering machine access at the edge entrenches the best-funded AI companies, who can simply pay, while pricing out smaller research projects, academic crawlers and new entrants who cannot. Publishers setting prices are making a decision about who gets to read them at scale, and it is not obvious that the answer they want is "whoever has the largest balance sheet".
Third, and most practically: charging for the fetch does nothing about the read that happens anyway. Content leaks through third-party scrapers, resellers and unverified agents that ignore the price entirely, and a model that has already ingested your archive does not need to fetch it again to answer a question about it.
What publishers should do about it
Turn on Bot Control at Common or Targeted level if it is not already on, since agent classification is the prerequisite for everything else.
Run the AI traffic analysis dashboard for two to four weeks before setting any price. Use the per-path heatmap to find the paths where machine demand and serving cost are concentrated, and price those rather than the whole site.
Decide your Search versus Training position explicitly, and express it in the verification tiers. Allowing verified search crawlers free or cheap access while charging training crawlers is a defensible public position and an easy one to explain to your newsroom.
Use test mode against live bot traffic before going real. The failure modes here are configuration failures, not commercial ones.
Check the wallet and treasury question early, because it is the one that stalls deployments. Payouts arrive in stablecoins to a wallet, and plenty of media finance teams have no process for receiving USDC, no policy on holding it and no view on who reconciles it. That conversation takes longer than the console configuration does.
And check what your CDN already does by default. If you sit behind both CloudFront and Cloudflare, or you are migrating between them, you may have two different default policies applying to the same content, one of which changes on 15 September 2026.
Where charging the crawl stops and monetising the answer begins
Every model described here meters the same moment: the fetch. It asks an AI company to pay for the act of collecting your page. That is a reasonable ask, and where a publisher's traffic is dominated by bulk training crawlers it is the right meter to attach.
It is the wrong meter for the traffic growing fastest. A Live Search Agent fetching a page in real time to answer a specific user question is not stockpiling your archive. It is doing something much closer to what a reader does, on behalf of a person waiting for an answer, and that read carries commercial intent that a per-request fee of a fraction of a cent does not capture. blankspace works at the same CDN edge as these products but attaches the meter further along: it detects and verifies Live Search Agent traffic in real time and places contextual, paid brand facts into the content the agent is parsing, so the publisher earns from the answer the agent produces rather than from the request that produced it. The two approaches are complementary, and the honest way to choose between them is to look at your own traffic mix by agent type first, using server-side measurement, because client-side analytics cannot see agents that never execute JavaScript.
The useful thing about AWS shipping this is not the revenue it will produce this year. It is that per-request pricing for machine access is now a checkbox on the largest cloud platform in the world, which settles the argument about whether publishers are entitled to charge. What is still unsettled is what they should be charging for.
Frequently asked questions
Does AWS WAF AI traffic monetization cost anything?
The capability itself carries no additional charge. Standard AWS WAF pricing applies, and Bot Control must be enabled at Common or Targeted level as a prerequisite. AWS also states that it does not process payments and takes no fee on content revenue, which distinguishes it from marketplaces and intermediaries that take a percentage of what publishers earn.
Do publishers have to accept cryptocurrency to use it?
At launch, yes. Payments settle in stablecoins, currently USDC, on supported networks including Base and Solana, and arrive in a wallet you nominate. AWS has said that integration with Stripe for direct account payments and support for the Machine Payments Protocol are coming soon, which would remove the wallet requirement, but neither is available yet. For many publishers the treasury and reconciliation question is the practical blocker rather than the technical configuration.
Will charging AI bots damage search visibility?
It depends entirely on how you configure the tiers, which is why the verification-tier design matters. Search crawlers and AI training crawlers overlap in ways that make blunt rules dangerous, and several major crawlers serve more than one purpose from the same user agent. The safe pattern is to allow verified search crawlers explicitly rather than relying on a broad rule to exempt them, and to check the change against your server logs afterwards rather than assuming it worked.
Can publishers use this if they are not on CloudFront?
No. The Monetize action is supported exclusively on web ACLs associated with an Amazon CloudFront distribution and is not supported on regional web ACLs. Publishers on other CDNs have equivalent options through Cloudflare, Akamai with TollBit and Skyfire, or TollBit directly, all of which charge for access at the same moment in the request.
Is it better to charge for the crawl or to monetise the AI answer?
They capture different things, and most publishers with a mixed traffic profile will end up doing both. Charging for the crawl bills the fetch and works best against bulk training crawlers from a small number of identifiable companies. Monetising the answer earns from the read itself and is the only model that captures value from Live Search Agents, which fetch in real time on behalf of a waiting user and are the fastest-growing category of machine traffic on most publisher sites. Measure your traffic by agent type before choosing, because the mix decides the answer.