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

Source: Dev.to

Introduction

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

It’s also very common for teams to eventually move some public‑facing pages (e.g., the homepage or blog) to a CMS like Webflow. This shift is usually driven by practical reasons:

• Marketers can publish content without engineering involvement.
• SEO workflows become easier.
• Design iterations move faster.

The challenge starts when you want to do both:

• company.com and /blogs → managed in Webflow
• All other pages (especially dynamic ones like /dashboard/*) → remain on S3

Everything must live under the same domain, without redirects or subdomains.

The Problem: Traffic Routing

In this article I’ll walk through how I solved this problem during our deployment. The approach lets you:

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

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

High‑Level Solution

Instead of trying to move routing logic into Webflow (which might require an enterprise plan) or introducing a new proxy layer, we:

1. Keep CloudFront as the single edge.
2. Treat Webflow and S3 as origins.
3. Use path‑based behaviours to decide where each request goes.

Request Flow (runtime)

Route53 → CloudFront
   ├── /dashboard/* → S3
   └── /*          → Webflow

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.

Why a 502 Bad Gateway Appears

Treating Webflow as an origin in CloudFront is straightforward: create a custom origin that points to your Webflow‑hosted site, just like you would for an ALB or any external service.

If you do only that, you’ll likely hit a 502 Bad Gateway on the paths meant for Webflow. The reason is that Webflow requires domain‑ownership verification before it allows publishing.

Webflow’s verification flow

1. TXT record – proves ownership.
2. A record or CNAME – points traffic directly to Webflow.

This works when Webflow is the final destination for traffic. In our architecture DNS must point to CloudFront, not Webflow, creating a mismatch:

The Webflow UI mixes two concerns:

• Control‑plane – verification (TXT record).
• Data‑plane – actual traffic routing (A/CNAME).

Webflow suggests that both the TXT and the A/CNAME must continuously point to Webflow, but only the TXT record is required for ongoing verification.

Practical Work‑around

1. Initial step – point TXT, A, and CNAME records to Webflow so verification can succeed.
2. After verification – keep the TXT record and point the A/CNAME records back to CloudFront.
3. CloudFront can now safely forward traffic to Webflow as an origin.

Step‑by‑Step Implementation

Note: Do not remove or bypass CloudFront at any point. The apex domain (company.com) and www (if used) must always resolve to CloudFront.

1. Create a custom origin in CloudFront

2. Configure behaviours

Ordering matters – more specific paths (/dashboard/*) must appear above the default (*) behaviour.

3. Set up Webflow

1. Add your custom domain (company.com) in the Webflow UI.

4. Add DNS records in Route 53 (initially)

Wait for Webflow to show the domain as Verified and Published.

5. Switch DNS back to CloudFront (post‑verification)

Now:

• DNS routes traffic to CloudFront.
• Webflow remains verified and publishable.

6. Publish the site in Webflow

1. Set the custom domain as the default.
2. Click Publish.

No further DNS changes are required.

Result

All content is served under the same domain (company.com) with no redirects and no subdomains.

Key Insight

• CloudFront stays the single edge.
• Webflow only needs to verify the domain once; after that it can be an origin behind CloudFront.

This simple mental model eliminates the need for extra proxy layers and leverages an architecture many teams already have in production.

Handling Routing and Forwarding Requests to Webflow

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 front‑ends, and managed platforms like Webflow, while still retaining CloudFront.

That’s the architecture that actually works.

Thank you for reading.

Connect with me

• LinkedIn: [Your LinkedIn Profile]
• YouTube: [Your YouTube Channel] – Subscribe for more valuable content.

Feel free to share your thoughts in the comments section!