DEV Community

Cover image for Webflow CMS Behind CloudFront: Serving Dynamic and Static Pages on the Same Domain
AWS Community Builders profile image Mubarak Alhazan
Mubarak Alhazan for AWS Community Builders

Posted on • Originally published at poly4.hashnode.dev

Webflow CMS Behind CloudFront: Serving Dynamic and Static Pages on the Same Domain

#webflow #cloudfront #dns

Introduction

A prevalent way to deploy a frontend on AWS is to use S3, CloudFront, and Route 53. It’s simple and cost-effective. Many teams begin here and successfully run this setup for years.

It’s also very common for teams to eventually move some public-facing pages (such as the homepage or blog) to a CMS like Webflow. This shift is usually driven by practical reasons: marketers want to publish content without engineering involvement, SEO workflows become easier, and design iterations move faster.

The challenge starts when you want to do both. You might want:

  • company.com and /blogs to be managed in Webflow

  • Other pages (especially dynamic ones like /dashboard/*, to remain on S3).

  • Everything is to live under the same domain, without redirects or subdomains.

At this point, the problem is traffic routing. In this article, I’ll walk through how I solved this problem in a recent deployment.

The approach allows you to:

  • Keep CloudFront as the single entry point

  • Serve Webflow pages and S3-backed pages from the same apex domain

  • Handle Webflow domain verification without permanently routing traffic away from CloudFront

This setup works reliably in production and avoids several pitfalls that aren’t clearly documented elsewhere.

The Architecture That Works

At a high level, the solution is surprisingly simple once you adopt the right mental model.

Instead of trying to move routing logic into Webflow (which might require an enterprise plan) or introducing a new proxy layer, we keep CloudFront as the single entry point for the domain and let it do what it’s already designed to do: route requests to different origins based on path patterns. This avoids extra proxy layer infrastructure and builds directly on an architecture many teams already have in production.

The Core Idea is:

  • CloudFront remains the single edge

  • Webflow and S3 are treated as origins

  • Path-based behaviours decide where each request goes

Requests flow like this:

Route53 → CloudFront
        ├── /dashboard/* → S3
        └── /*             → Webflow
Enter fullscreen mode Exit fullscreen mode

From the browser’s perspective, everything is still coming from company.com. There are no redirects, no subdomains, and no visible boundary between Webflow-managed pages and S3-backed pages.

Webflow as an Origin (and the Verification Gotcha)

Treating Webflow as an origin in CloudFront is straightforward from an infrastructure perspective. You create a custom origin pointing to your Webflow-hosted site, just like you would for an ALB or any external service. However, if that’s all you do, you’ll likely run into a 502 Bad Gateway error on the paths meant to route to Webflow.

This happens because Webflow requires domain ownership verification before it allows publishing.

The way Webflow handles this verification can be confusing. Before a domain can be published, Webflow asks you to add DNS records, typically:

  • A TXT record for ownership verification

  • An A record or CNAME that points traffic directly to Webflow

This works well when Webflow is intended to be the final destination for traffic. In this architecture, however, DNS must point to CloudFront, not Webflow.

This creates a fundamental mismatch:

  • Webflow expects DNS to point directly to them

  • CloudFront must stay in front to enable path-based routing

The key to resolving this is understanding that the Webflow UI is mixing two very different concerns:

  • Verification is a control-plane requirement: it exists to prove domain ownership and enable publishing

  • Traffic routing is a data-plane concern: it determines where live requests are actually served from

Webflow’s UI strongly suggests that both the TXT record and the A/CNAME record must continuously point to Webflow. In reality, only the TXT record is required for ongoing verification.

The practical workaround is:

  • Initially, point the TXT, A, and CNAME records to Webflow so verification can succeed

  • Once the domain is verified and publishing is enabled:

    • Keep the TXT record in place for continuous ownership proof
    • Point the A and CNAME records back to CloudFront

At that point, CloudFront can safely forward traffic to Webflow as an origin, since the domain is already verified.

In the next section, we’ll walk through how this is implemented step by step, without breaking production traffic.

Step-by-Step Implementation

1. Keep DNS Pointing to CloudFront

  • Ensure your apex domain (company.com) and www (if used) point to CloudFront

  • Do not remove or bypass CloudFront as part of the final setup

This remains true before and after verification.

2. Add Webflow as a Custom Origin in CloudFront

  • Create a new custom origin in your CloudFront distribution

  • Origin domain:

    your-site.webflow.io

  • Protocol policy: HTTPS only

  • Origin headers: none required

At this point, requests routed to Webflow will still fail until verification is completed.

3. Configure Path-Based Behaviours

  • Default behaviour (*):

    • Origin: Webflow
    • Cache policy: CachingDisabled (recommended for CMS content)
    • Origin request policy: AllViewer (or equivalent)

  • Specific behaviour (/dashboard/*):

    • Origin: S3
    • Cache policy: As per your existing setup

Ordering matters:

  • More specific paths (/dashboard/*) must appear above the default (*) behavior.

4. Temporarily Point DNS to Webflow for Verification

  • In Webflow:

  • In Route53:

    • Add the TXT record provided by Webflow (_webflow)

    • Temporarily update:

  • Wait for verification to complete in Webflow

This step is temporary and only required once.

5. Revert DNS to CloudFront

  • Restore DNS records:

    • Apex A record → CloudFront
    • www CNAME → CloudFront

  • Keep the TXT record in place

At this point:

  • DNS routes traffic to CloudFront

  • Webflow remains verified and publishable

6. Publish the Site in Webflow

  • Set the custom domain as the default

  • Publish the site

  • No further DNS changes are required

CloudFront now routes:

  • /* → Webflow

  • /restaurants/* → S3

All under the same domain.

Conclusion

The key insight in this setup is simple: CloudFront remains the single edge, and everything else becomes an origin behind it.

Webflow does not need to own DNS long-term to serve content. It only needs to verify the domain once. After that, CloudFront can safely sit in front, handle routing, and forward requests to Webflow exactly like it would to any other backend.

You may still see Webflow UI warnings like “update required” after DNS is reverted to CloudFront. These warnings are harmless, as long as the domain is already verified and published.

With this model, you get the flexibility of mixing static assets, dynamic frontends, and managed platforms like Webflow, while still retaining CloudFront.

That’s the architecture that actually works.

Thank you for reading

You can follow me on LinkedIn and subscribe to my YouTube Channel, where I share more valuable content. Also, let me know your thoughts in the comments section.

Top comments (0)