Amazon Cloudfront

Site hosting caps background videos at 30 MB, Assets panel images at 4 MB, and documents at 10 MB. Media-heavy sites hit those ceilings quickly. Teams that already run infrastructure on AWS also want edge controls such as WAF rules and multi-origin routing in front of their marketing site. Amazon CloudFront covers both needs.

With CloudFront in front of an S3 bucket, you can serve files up to 50 GB and embed them on Webflow pages. Webflow webhooks can trigger CloudFront cache invalidations as soon as you publish. CloudFront path routing can also serve a Webflow marketing site and a separate application from a single domain.

Agencies building media-heavy marketing sites can use this integration. DevOps engineers who already manage AWS accounts can use it too, while SaaS teams can run marketing on Webflow beside an app on another stack. monday.com runs exactly this pattern and routes one domain across Webflow and a Next.js app through CloudFront.

How to integrate Amazon CloudFront with Webflow

What is Amazon CloudFront? Amazon CloudFront is an AWS content delivery network service that delivers content with low latency and high transfer speeds. It runs more than 750 points of presence in over 100 cities and routes each viewer to the nearest edge location. Distributions can use S3 buckets or any HTTP(S) server as an origin, including a Webflow custom domain.

Connecting the two keeps your site on Webflow while large media, cache invalidation, and edge security move to CloudFront.

Teams pair CloudFront with Webflow when file limits, bandwidth allowances, or AWS-side security requirements outgrow site hosting alone. Every working setup uses embeds, Zapier, or the two platforms' APIs because the Webflow App Marketplace has no official CloudFront app. Site hosting already runs on Cloudflare's CDN, which shapes how each method below must be configured.

Available integration approaches:

• CloudFront asset URLs deliver S3-hosted media on Webflow pages without writing code.
• Zapier connects Webflow triggers to CloudFront's Invalidate Item action.
• The Webflow and CloudFront APIs give you full control over cache invalidation and origin routing, but require server-side development.

Most implementations combine two or more of these methods depending on the complexity of the setup.

Serve S3 assets through CloudFront on Webflow pages

Uploading media to S3 and fronting it with CloudFront gets around site hosting file limits. CloudFront caches objects up to 50 GB per HTTP GET response, against the 30 MB background video cap and the 4 MB Assets panel image cap. You need an AWS account and a bucket with your files, but no code beyond optional embed markup. This method suits designers and marketers who want heavy media on Webflow pages without touching the site's DNS or hosting.

To set up the integration:

1. Open the CloudFront console, then choose Distributions > Create distribution.
2. For origin type, select Amazon S3, then Browse S3 and pick your bucket.
3. Choose Use recommended origin settings, which configures Origin Access Control automatically.
4. Choose Create distribution. CloudFront updates the S3 bucket policy for you.
5. Record the assigned domain, such as d111111abcdef8.cloudfront.net, and paste asset URLs into Webflow image or video fields, or into a Code Embed element for custom players.

Add the CloudFront asset URL to the Webflow page where visitors will access the object:

• Video streaming in MPEG DASH, Apple HLS, and CMAF formats, embedded through a Code Embed element
• Large-file downloads such as software installers or game patches linked from Webflow pages
• Bandwidth offload, since serving large assets from CloudFront reduces site-hosting-counted bandwidth

For player scripts that must load site-wide, add them under Site settings > Custom code and follow the custom code in head and body tags documentation. Each section holds up to 50,000 characters. If you need CloudFront in front of the whole site rather than individual assets, that requires the API-driven reverse proxy setup covered below.

Connect Webflow and CloudFront with Zapier

Zapier is the only automation platform with native apps for both Webflow and Amazon CloudFront. Zapier requires you to assemble the Zap manually because a pre-built Webflow-to-CloudFront template is unavailable. You write no code. The CloudFront app exposes an Invalidate Item action plus New Distribution and New Invalidation triggers. This path suits teams that want cache purges tied to site activity without running a server.

Example Webflow event mappings:

• Webflow New Form Submission → CloudFront Invalidate Item
• Webflow Updated Order → CloudFront Invalidate Item for inventory or order pages
• Webflow CMS item update → CloudFront Invalidate Item for the affected content paths

Zapier is the practical no-code path for tying publish or CMS activity to a CloudFront invalidation.

Build with the Webflow and CloudFront APIs

The APIs support publish-triggered invalidation and reverse proxying. They also handle multi-origin routing, which the no-code paths cannot. Both sides need server-side development. CloudFront calls require AWS Signature Version 4 authentication, and Webflow calls use a Bearer token with scoped permissions.

• The CloudFront API (version 2020-05-31) handles invalidations, distributions, cache policies, and edge functions
• Webflow's Data API handles sites, pages, CMS collections, and custom code at https://api.webflow.com/v2
• Webflow webhooks trigger real-time events such as site_publish and collection_item_published

The v1 Data API was deprecated on March 31, 2025. Build against v2 only.

Invalidate the CloudFront cache when Webflow publishes

This is the core automation pattern for any CloudFront layer in front of Webflow content. A publish event fires a webhook, and your receiver calls CloudFront to purge stale objects.

To implement this:

1. Register the webhook with POST https://api.webflow.com/v2/sites/{site_id}/webhooks and send {"triggerType": "site_publish", "url": "https://your-receiver.example.com/webhook"}. This requires the sites:write scope.
2. Verify each incoming request. The x-webflow-signature header carries an HMAC-SHA256 of {timestamp}:{request_body}; reject requests older than five minutes, per the webhook verification docs.
3. Call POST /2020-05-31/distribution/{DistributionId}/invalidation with an XML body containing a unique CallerReference and a Paths object. The IAM action is cloudfront:CreateInvalidation, documented in the CreateInvalidation reference.
4. Optionally poll GET /2020-05-31/distribution/{DistributionId}/invalidation/{Id} to confirm completion.

A full-site purge body looks like this:

<InvalidationBatch xmlns="http://cloudfront.amazonaws.com/doc/2020-05-31/">
  <CallerReference>unique-string-per-request</CallerReference>
  <Paths>
    <Items>
      <Path>/*</Path>
    </Items>
    <Quantity>1</Quantity>
  </Paths>
</InvalidationBatch>

The site_publish payload includes a publishScope field (site or page, added April 8, 2026) and a pageId, per the site_publish event reference. When publishScope is page, use pageId to look up the page through the Webflow Pages API, or consult a maintained page-ID-to-URL mapping, then submit the resulting URL path to CloudFront instead of /*. The pageId cannot be sent directly as an invalidation path. One wildcard entry covers every object that matches it. CMS-level triggers such as collection_item_published support the same pattern for per-slug invalidation like /blog/post-slug.

Run Webflow behind CloudFront as a reverse proxy

In this setup your public domain points to CloudFront, which forwards requests to a dedicated Webflow origin subdomain. The self-managed reverse proxy guide lists CloudFront as Option C. Cloudflare O2O is the recommended pattern for a CDN in front of site hosting. Third-party proxies aren't supported. Proxying *.webflow.io staging domains violates the Terms of Service, so you need a custom domain.

To configure the proxy:

1. Create a dedicated origin subdomain such as wf.example.com, connect it as a custom domain, and set it as the site's default domain to avoid unwanted redirects.
2. Point CloudFront's origin at that subdomain with origin protocol policy https-only, since all HTTP traffic redirects to HTTPS. Attach the AllViewerExceptHostHeader managed origin request policy and forward query strings so site search and collection filters keep working.
3. Disable CloudFront caching by setting TTL to 0. Publishing purges the site cache but not the CloudFront cache, so any upstream caching serves stale content to visitors.
4. Request an ACM certificate in us-east-1 for the public domain, attach it to the distribution, and point public DNS at CloudFront. Use a Route 53 alias A record for apex domains, since CNAMEs cannot sit at the zone apex.

Watch the distribution chain quota. CloudFront does not support stacking distributions: two or more CloudFront distributions in a request chain to a single origin endpoint return HTTP 403, and AWS advises against placing one distribution in front of another. Site hosting routes through Cloudflare rather than CloudFront, so a single CloudFront distribution in front of your Webflow origin adds a second CDN layer but does not form a CloudFront chain. Misconfigured cookie forwarding can also break password-protected pages on paid plans by caching protected and unprotected responses interchangeably.

Route paths across Webflow and other origins

Path-based routing serves /blog from Webflow and /app from another origin under one domain. Cache behaviors match URL path patterns in order, with the first match winning, up to 75 behaviors per distribution. For request-based origin selection, a CloudFront Function can call cf.updateRequestOrigin(), though origin switching there is limited. Lambda@Edge at the origin-request event handles routing that needs network access or request-body inspection.

To build this routing layer:

1. Define a cache behavior per path pattern, with the default * behavior pointing at your Webflow origin subdomain.
2. Write a Lambda@Edge origin-request function that sets request.origin.custom.domainName and the host header per route according to AWS's origin modification guide.
3. Deploy the function in us-east-1, the required region for Lambda@Edge, and allow several minutes for propagation.

monday.com documented this architecture in a September 2025 engineering post. A viewer-request Lambda evaluates the URI and routes it to a Next.js app or Webflow. An origin-request Lambda routes to the appropriate backend. An automated S3 mapping tracks every Webflow page including localized versions.

What can you build with the Amazon CloudFront Webflow integration?

Integrating Amazon CloudFront with Webflow lets you deliver large media, fresh caches, and edge-filtered traffic without exporting your site or leaving Webflow hosting.

• Media-heavy marketing sites: Host a video library or product demo reel in S3, stream it through CloudFront in HLS or MPEG DASH, and embed the player on Webflow pages with Code Embed elements. File sizes far beyond the 30 MB background video cap become usable.
• Publish-fresh proxied sites: Pair a CloudFront layer with a site_publish webhook pipeline so every publish triggers a targeted invalidation. A content team ships CMS updates and the invalidation clears matching objects instead of waiting for a TTL to expire.
• Single-domain hybrid stacks: Serve marketing pages from Webflow and an application from Next.js under one domain, the way monday.com routes cross-platform A/B tests with Lambda@Edge.
• Edge-protected sites: Put AWS WAF's one-click protection, Shield Standard DDoS mitigation, and geographic restrictions in front of a proxied Webflow site to filter bots and blocked countries before requests reach the origin.

The API integration path supports per-page invalidation and multi-origin routing.