Skip to main content
This guide configures AXP Edge on an existing CloudFront distribution using a CloudFront Function (viewer request) plus a Lambda@Edge function (origin request / origin response). Requests from recognized AI agents (GPTBot, ClaudeBot, Google-Extended, and similar) are routed to the Publive CDS backend instead of your origin. Every other request (human visitors and SEO bots) passes through to your existing origin, unchanged. Use this approach when your site is served from CloudFront and you want agent routing configured at the CDN layer, without an application deploy.
Make sure PubliveBot/1.0 (+https://axp.thepublive.com/bot) is unblocked on your CDN.
Make sure LLM user agents (GPTBot, ClaudeBot, Google-Extended, and similar) are unblocked on your CDN, in robots.txt, and in any firewall/WAF rules. If one of these layers blocks a bot’s request before it reaches CloudFront’s function associations, that traffic never gets a chance to route to AXP Edge.

Prerequisites

  • An existing CloudFront distribution serving your website.
  • AWS IAM permissions to create CloudFront functions, Lambda functions, IAM roles, cache policies, and to edit distribution behaviors.
  • Your Publive Edge CDS API key and backend URL (issued per client, contact support@thepublive.com if you don’t have these).

How routing works

CloudFront splits this integration across two function types, run at two different points in the request lifecycle:
  • A CloudFront Function (pl-edge-routing), running on viewer request — a lightweight JS function that decides, per request, whether this looks like agent traffic. It doesn’t call out to Publive; it only tags the request so the right origin gets picked.
  • A Lambda@Edge function (pl-edge-origin), running on origin request and origin response — this is what actually fetches from the Publive CDS backend, applies failover if CDS errors, and shapes the response.
A request only qualifies for AXP Edge when all of the following are true:
  • The request hostname matches your configured client host.
  • The request hasn’t already been routed once (a loop guard header prevents re-routing looped or failed-over requests).
  • The method is GET or HEAD, and the path isn’t a static asset (.js, .css, images, fonts, and similar are always skipped).
  • The user-agent matches a known AI agent, or the request carries a preview flag.
If the request qualifies, the Lambda@Edge origin-request function fetches the page from CDS and returns it. If CDS errors or is unreachable, the function automatically fails over to your real origin and tags the response with a failover header. Visitors never see an error. Unlike the Cloudflare integration, where the whole routing decision and the backend fetch live in one Worker, CloudFront splits this across the CloudFront Function (cheap, runs on every request, viewer-request only) and Lambda@Edge (heavier, only invoked for requests the CloudFront Function has already flagged as candidates). This two-tier design is a CloudFront constraint, not a Publive choice — CloudFront Functions cannot make network calls, so the actual CDS fetch has to happen in Lambda@Edge.

Set up the integration

1

Create the Publive CDS origin

Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Origins tab
  1. Click Create origin.
  2. Configure the origin:
    • Origin domain: your Publive Edge CDS backend URL (for example, cds.thepublive.com)
    • Name: Publive_CDS_Origin
  3. Leave all other fields at their default values.
  4. Add custom headers:
  5. Click Create origin.
[SCREENSHOT: CloudFront → Distributions → Origins → Create origin, showing the Publive_CDS_Origin domain and custom headers]
2

Create the viewer request function

Navigation: AWS Console > CloudFront > Functions
  1. Click Create function.
  2. Configure:
    • Name: pl-edge-routing
    • Runtime: cloudfront-js-2.0
  3. Replace the default code with the routing code below. Before publishing, customize:
    • YOUR_DEFAULT_ORIGIN — the name of your existing default origin (found in CloudFront > Distributions > [Your Distribution] > Origins tab).
    • TARGETED_PATHS — set to null to target all HTML pages, or an array of specific paths, for example ['/', '/products', '/about'].
viewer-request.js
  1. Click Save changes > Publish function.
[SCREENSHOT: CloudFront → Functions → pl-edge-routing, showing the published function code]
3

Configure the cache policy

Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > BehaviorsCheck the cache policy currently attached to your behavior. Click Edit on your behavior and look at the Cache key and origin requests section to identify your scenario:
  • Scenario A (Legacy): Legacy cache settings is selected — no policy-name dropdown, just inline TTL and header settings.
  • Scenario B (Custom policy): Cache policy is selected, with a policy name your team created (not an AWS-provided policy).
  • Scenario C (Managed policy): Cache policy is selected with an AWS-provided name like CachingOptimized, CachingDisabled, or CachingOptimizedForUncompressedObjects — these cannot be edited directly.
Scenario A: Legacy cache settings
  1. Under Cache key and origin requests, confirm Legacy cache settings is selected.
  2. Add x-pl-url and x-pl-origin-choice to the Headers allow list:
    • Select Include the following headers from the dropdown.
    • Add x-pl-url and x-pl-origin-choice.
    [SCREENSHOT: Legacy cache settings — Headers allow list with x-pl-url and x-pl-origin-choice added]
    If you already have All selected in the Headers dropdown, skip this step — all headers are automatically forwarded to the origin.
  3. Check Object caching:
    • If set to Customize, set Minimum TTL to 0 — recommended. If your current Minimum TTL is already very short, you may not need to change it.
    • If set to Use origin cache headers, no change needed.
  4. Click Save changes.
Scenario B: Non-legacy with a custom cache policyNavigation: AWS Console > CloudFront > Policies > Cache
  1. Click your existing policy, then Edit.
  2. Set Minimum TTL to 0 — recommended. If your current Minimum TTL is already very short, you may not need to change it. [SCREENSHOT: Cache policy TTL settings — generic AWS view, reusable as a layout reference]
  3. Under Cache key settings > Headers, along with your existing inclusions, add x-pl-url and x-pl-origin-choice. [SCREENSHOT: Cache policy headers — generic AWS view, reusable as a layout reference]
  4. Click Save changes.
Scenario C: Non-legacy with a managed (AWS) cache policyIf your behavior uses an AWS managed cache policy (for example, CachingOptimized), you can’t edit it directly — you need a new custom policy that replicates it and adds Publive’s headers.Part 1 — note your current managed cache policy settingsNavigation: AWS Console > CloudFront > Policies > Cache
  1. Find and open the managed cache policy attached to your behavior.
  2. Note: Minimum TTL, Maximum TTL, Default TTL; headers, cookies, and query strings included in the cache key; compression support (Gzip, Brotli).
Part 2 — create a new custom cache policy with the same settings + Publive headersNavigation: AWS Console > CloudFront > Policies > Cache
  1. Click Create cache policy.
  2. Name: pl-edge-cache [SCREENSHOT: Cache policy name field — generic AWS view, reusable as a layout reference]
  3. Replicate all settings noted in Part 1, with these modifications:
    • Set Minimum TTL to 0 — recommended, unless your current Minimum TTL is already very short.
    • Under Cache key settings > Headers, include everything the managed policy had, plus x-pl-url and x-pl-origin-choice.
  4. Click Create.
  5. Go back to your behavior and associate the new policy: Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Behaviors
    1. Edit your behavior.
    2. Under Cache key and origin requests, select Cache policy.
    3. Choose pl-edge-cache from the dropdown.
    4. Click Save changes.
4

Create the Lambda@Edge function (origin request and response)

Lambda@Edge functions must be created in the us-east-1 (N. Virginia) region. This is an AWS requirement. Even though the function is created in us-east-1, AWS automatically replicates it to all CloudFront edge locations worldwide, so it executes at the edge location nearest the viewer. Confirm you’re in us-east-1 in the AWS Console before proceeding.
Create the functionNavigation: AWS Console > Lambda
  1. Click Create function.
  2. Select Author from scratch.
  3. Configure:
    • Function name: pl-edge-origin
    • Leave all other fields at their default values.
  4. Click Create function.
  5. In the code editor, replace the default code with the origin-request/origin-response code below.
  6. Click Deploy to save the code.
  7. Note the execution role name shown under Configuration > Permissions (for example, pl-edge-origin-role-xxxxx) — you need this in the next two steps.
origin-request-response.js
The sample above shows the routing and header-injection contract explicitly, but production failover on CloudFront typically uses a CloudFront origin group (primary: Publive CDS, secondary: your origin) configured on the distribution, rather than a second fetch performed inline in Lambda@Edge — Lambda@Edge cannot make outbound network calls of its own in the origin-response phase in all runtimes. Confirm the failover mechanism with your Publive representative before going live; the origin-group approach is what the Verify steps below assume.
Update the execution role’s trust policyThe auto-created role only trusts lambda.amazonaws.com. For Lambda@Edge, you must also add edgelambda.amazonaws.com.Navigation: AWS Console > IAM > Roles > [your role from the previous step] > Trust relationships tab
  1. Click Edit trust policy.
  2. Replace the policy with:
trust-policy.json
  1. Click Update policy.
The edgelambda.amazonaws.com service principal is required for Lambda@Edge. Without it, CloudFront cannot invoke your function at edge locations.
Fix the CloudWatch Logs permission policyThe auto-created role ships with an AWSLambdaBasicExecutionRole policy configured for regular Lambda, which has the wrong region and log-group name for Lambda@Edge.Navigation: AWS Console > IAM > Roles > [your role] > Permissions tab > click the attached policy name (for example, AWSLambdaBasicExecutionRole-xxxx)
  1. Click Edit.
  2. Replace the policy with:
cloudwatch-policy.json
Replace ACCOUNT_ID with your AWS account ID (top-right corner of the AWS Console) and FUNCTION_NAME with your Lambda function’s name (for example, pl-edge-origin).
  1. Click Save changes.
The region in the ARN must be * — Lambda@Edge executes at the edge location nearest the viewer, so logs are written to CloudWatch in the region of that edge location (for example, ap-south-1, eu-west-1), not necessarily us-east-1. The log group uses a region-prefixed name: /aws/lambda/us-east-1.FUNCTION_NAME, where us-east-1 is always the function’s home region.
Publish a version
  1. On the function page, click Actions (top right) > Publish new version.
  2. Add a description.
  3. Click Publish.
  4. Copy the Function ARN — you need it in the next step.
[SCREENSHOT: Lambda — publish new version dialog] [SCREENSHOT: Lambda — versioned Function ARN shown on the function page]
5

Associate the functions and cache policy with the behavior

Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Behaviors
  1. Edit your behavior.
  2. If you created a new cache policy in the previous step (Scenario C), set Cache policy to pl-edge-cache.
  3. Under Function associations, configure:
  4. Click Save changes.
[SCREENSHOT: Cache policy dropdown on the behavior, set to pl-edge-cache] [SCREENSHOT: Function associations — Viewer request / Origin request / Origin response set to Publive's functions]

Allow AXP Edge through firewall rules (optional)

If your CDN uses a WAF or Bot Manager:
  • Allowlist the PubliveBot/1.0 (+https://axp.thepublive.com/bot) user agent so the AXP Edge service can fetch your origin content during failover and cache-warming.
  • If your firewall requires additional verification beyond user agent, generate a secret (for example, openssl rand -hex 32) and:
    • Add x-pl-fetcher-key with the secret to the Publive CDS origin’s custom headers (Step 1).
    • Add a WAF or Bot Manager rule allowing requests where x-pl-fetcher-key matches the same secret.
  • AXP Edge forwards this header as-is — you own the full key lifecycle.

Verify

1. Test bot traffic (should be optimized) Simulate an AI bot request using an agentic user-agent:
A successful response includes the x-pl-request-id header, confirming the request was routed through AXP Edge:
2. Test human traffic (should NOT be affected)
The response should not contain the x-pl-request-id header. Page content and response time should be identical to before enabling AXP Edge. 3. How to differentiate between the two scenarios You can also check routing status in the AXP dashboard: Brand Configuration > Integrations > CDN. [SCREENSHOT: AXP dashboard — CDN integration status showing "verified" for the CloudFront connection] 4. Verify logs are flowing correctly CloudFront Function logs (pl-edge-routing) Navigation: AWS Console > CloudWatch > Log groups (in us-east-1, or the region where your CloudFront distribution is configured)
  1. Look for a log group named /aws/cloudfront/function/pl-edge-routing.
  2. Open the latest log stream.
  3. For agentic requests, expect entries such as:
    • Routing to Publive CDS origin for userAgent: ChatGPT-User
  4. For non-agentic requests, expect:
    • Routing to Default origin for userAgent: ...
You can also check the Metrics tab under AWS Console > CloudFront > Functions > pl-edge-routing for invocation counts and error rates. Lambda@Edge logs (pl-edge-origin)
Lambda@Edge logs are written to CloudWatch in the region of the edge location that served the request, not us-east-1. Check CloudWatch in the AWS region closest to where you ran the curl command.
Navigation: AWS Console > CloudWatch > Log groups (confirm you’re in the correct region)
  1. Look for a log group named /aws/lambda/us-east-1.pl-edge-origin.
  2. Open the latest log stream.
  3. For agentic requests, expect entries such as:
    • Calling Publive CDS Origin for agentic requests — primary path
    • Failover Triggered for agentic requests — origin-response failover detection
If the log group isn’t present, verify the IAM permissions were updated correctly. Also check other nearby AWS regions — the edge location that served your request may differ from what you expect.

Troubleshooting

Rollback

The Lambda@Edge function (pl-edge-origin) is associated with the origin request and origin response events of your CloudFront behavior. Because it runs inline on every request passing through that behavior — both human and agentic — a Lambda@Edge outage will impact all live traffic, not just agentic requests. If you detect a Lambda@Edge outage, remove the function associations immediately to restore normal traffic flow to your default origin. How to detect a Lambda@Edge outage
  • AWS Service Health Dashboard — check for active incidents affecting Amazon CloudFront or AWS Lambda.
  • Lambda@Edge errorsAWS Console > CloudFront > Monitoring > [Your Distribution] > Lambda@Edge errors tab; check the Execution errors graph.
Detaching the Lambda@Edge function Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Behaviors
  1. Click Edit on your behavior.
  2. Under Function associations, set the following to No association:
  3. Click Save changes.
  4. Wait for the distribution to finish deploying (status changes from Deploying to the last-modified date, typically within a few minutes).
Once deployed, all traffic routes directly to your default origin. No configuration is deleted; the Lambda function and its associations can be restored at any time. Re-attaching the Lambda@Edge function Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Behaviors
  1. Click Edit on your behavior.
  2. Under Function associations, restore:
  3. Click Save changes.
  4. Wait for the distribution to finish deploying, then verify agentic requests return the x-pl-request-id header as described in Verify.

Next steps

AXP Edge dashboard

Monitor agent traffic and manage optimization rules.

Deploy on Cloudflare

Site behind Cloudflare instead of CloudFront? Use the Worker-based guide.
Last modified on August 10, 2026