Amazon CloudFront

Site hosting caps the background video component at 30 MB, and Assets panel uploads at 4 MB for images and 10 MB for documents. 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.

This suits agencies building media-heavy marketing sites and DevOps engineers who already manage AWS accounts. SaaS teams also use it to 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 dedicated Webflow origin subdomain.

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. Site hosting already delivers static assets from Cloudflare's network edge, so CloudFront is not what makes a Webflow site fast. It is what you add when you need AWS-side controls, or files site hosting will not accept. Every working setup uses embeds, Zapier, or the two platforms' APIs, because the Webflow App Marketplace has no CloudFront app.

Before adding a second CDN, check whether the problem is solvable inside Webflow. The Webflow MCP server lets an agent run asset compression jobs and write site-level and page-level custom code for you, working inside your existing Webflow permissions and recording what it changed in the site activity log. Reach for CloudFront when the files are genuinely too large for site hosting, or the controls you need live in AWS.

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 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.

Point the Webflow page at the CloudFront URL wherever visitors reach the object. That covers video streaming in MPEG DASH, Apple HLS, and CMAF formats through a Code Embed element, and large-file downloads such as software installers or game patches linked from a Webflow page. Serving those assets from CloudFront also keeps them off the bandwidth Webflow counts against your site.

For player scripts that must load site-wide, add them under Site settings > Custom code and follow the documentation on custom code in head and body tags. 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 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. There is no pre-built Webflow-to-CloudFront template, so you assemble the Zap yourself, and you write no code. The CloudFront app exposes an Invalidate Item action plus New Distribution and New Invalidation triggers. CloudFront is a Zapier premium app, so this path needs a paid Zapier plan.

You can fire Invalidate Item from a Webflow new form submission or an updated order, and from a Webflow CMS item update for the affected content paths. Zapier is the practical no-code route 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 covers sites, pages, CMS collections, and custom code at https://api.webflow.com/v2, and Webflow webhooks fire real-time events such as site_publish and collection_item_published. Build against v2.

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) 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. Webflow's self-managed reverse proxy guide lists CloudFront as Option C, for teams whose edge already runs on AWS. Cloudflare Orange to Orange is the recommended pattern otherwise, because Webflow does not configure or support third-party proxies and cannot troubleshoot them for you. You need a paid Site plan and a custom domain: proxying a *.webflow.io staging domain is unsupported and violates the Terms of Service. An Enterprise plan is not required.

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 Cloudflare cache in front of your site 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.

Two things break quietly in this setup. Making the origin subdomain the default domain also puts that subdomain in the auto-generated sitemap and robots.txt, so host both files yourself if you care how the site gets crawled. Query strings that never reach the origin break site search and filtered Collection Lists. Misconfigured cookie forwarding can break password-protected pages too, by caching protected and unprotected responses interchangeably.

Watch the distribution chain quota as well. CloudFront does not support stacking distributions: AWS advises against placing one distribution in front of another, and a request chain to a single origin endpoint that exceeds the documented quota returns HTTP 403. Site hosting routes through Cloudflare rather than CloudFront, so a single CloudFront distribution in front of your Webflow origin adds a second CDN layer without forming a CloudFront chain.

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. 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 you can 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 path is the one that supports per-page invalidation and multi-origin routing. For the same programmatic control over what loads on each page, see how to apply custom code through the Webflow Data API.