Skip to content

Integration guide

Prerendering on AWS (CloudFront + Lambda@Edge)

Lambda@Edge runs at CloudFront edge locations, similar to Cloudflare Workers but inside the AWS ecosystem. The pattern is identical: detect crawlers in the viewer-request handler, rewrite to a prerender origin (S3-cached HTML, an ECS-hosted Chromium service, or an external prerender API).

Setup overview

Attach a Lambda@Edge function to the CloudFront distribution at the viewer-request stage. The function inspects user-agent, optionally verifies bot identity, and rewrites the request URI or origin to point to the prerender source.

Working snippet

// lambda-edge-prerender.js
const BOT_UA = /Googlebot|OAI-SearchBot|PerplexityBot|ClaudeBot|GPTBot|Bingbot/i

export const handler = async (event) => {
  const request = event.Records[0].cf.request
  const headers = request.headers
  const ua = (headers['user-agent']?.[0]?.value) ?? ''

  if (!BOT_UA.test(ua)) return request

  // Rewrite origin to prerender bucket / service
  request.origin = {
    s3: {
      domainName: 'prerender-cache.s3.amazonaws.com',
      region: 'us-east-1',
      authMethod: 'origin-access-identity',
      customHeaders: {},
      path: '/snapshots',
    },
  }
  request.headers['host'] = [{ key: 'host', value: 'prerender-cache.s3.amazonaws.com' }]
  return request
}

Decision criteria

Fits when

  • Existing infrastructure is on AWS and you want vendor-uniform deployment.
  • Prerender snapshots can be cached in S3 (low-volatility content).
  • You have AWS-side compliance or data-residency constraints.

Decision criteria

Avoid when

  • You need rapid iteration on the bot-routing logic (Lambda@Edge cold-deploy is slow).
  • A managed prerender service would be faster to ship and you can pay external for it.

Common pitfalls

Watch for these on first rollout

Lambda@Edge size and runtime limits

Viewer-request Lambda@Edge has a 1MB function-size limit and a 5-second timeout. Keep the function lean — bot detection only, no rendering. Heavy logic moves to the prerender origin.

CloudFront cache key not including user-agent

By default, CloudFront does not cache by user-agent. If the bot path serves different HTML, configure a cache policy that varies on a derived header (e.g., x-is-bot) set by the Lambda. Otherwise bots and humans get the same cached HTML.

Slow Lambda@Edge cold starts

Cold-start latency adds 200-500ms per request. Use Lambda Provisioned Concurrency for the viewer-request layer if traffic justifies it.

FAQ

Platform-specific questions

Why not use CloudFront Functions instead of Lambda@Edge?

CloudFront Functions have 1 ms CPU and limited request access — they cannot fetch external origins or call AWS services. Lambda@Edge supports full Node.js + outbound HTTP, which is required for prerender fetch routing.

How do I avoid cold-start latency?

Lambda@Edge does not support Provisioned Concurrency natively. Mitigations: keep the function < 200 KB, avoid heavy imports, use the viewer-request stage (warmer than origin-request), and live with 100-300 ms cold-start tail latency that affects only the first request per edge location.

Can I cache prerendered output in S3 + CloudFront?

Yes — and it is a common pattern. Lambda@Edge fetches the prerender HTML from your service, writes it to S3, and CloudFront serves subsequent requests for the same URL directly from the cached S3 object until invalidation.

Last updated:

Platform documentation

Authoritative references

Related deep-dives

Want this scoped to your stack?

Generic snippets are useful for orientation; the actual integration needs your routes, your bot traffic mix, your cache strategy. The scoping call is 30 minutes — bring the platform constraints.

Book scoping callBrowse all integrations

Other platforms