From Azure Front Door Back to Zero Cost – Migrating to Azure Static Web Apps
TL;DR
Azure CDN (Classic) was retired, Azure Front Door took its place, and a previously cheap static blog
started generating 30€+ per month.
This article describes how a Hexo-based static blog was migrated from Azure Storage + Front Door to Azure Static Web Apps (Free Tier) — including GitHub Actions, custom domain, redirects, and a custom 404 page — ending up with zero ongoing hosting cost again.
Background
This article builds on two earlier posts:
The original setup was:
- Hexo as static site generator
- GitHub Actions for build & deployment
- Azure Storage Static Website as hosting
- Azure CDN in front
That setup worked reliably for a long time and is not repeated here in detail.
The Problem: Azure CDN Retirement → Front Door → Cost Explosion
When Azure CDN (Classic) was deprecated, Azure offered an automatic migration to Azure Front Door.
Functionally, the migration was transparent:
- same domain
- same content
- same availability
Financially, it was not.
Azure Front Door is a powerful enterprise product (global routing, WAF, rules engine), but for a personal site it is massive overkill. After noticing invoices of 30€+ per month, it became clear that this setup was no longer acceptable, at least not for my humble purposes.
So, the goal was
Host a static Hexo blog on Azure with custom domain and HTTPS for zero ongoing cost.
Target Architecture
graph LR
User[Browser] --> SWA["Azure Static Web Apps - Free Tier"]
SWA --> CDN["Global CDN - included"]
What should disappear entirely:
- Azure Front Door
- Azure CDN
- Azure Storage Static Website (as hosting target)
Why Azure Static Web Apps
Azure Static Web Apps (SWA) fits this use case particularly well:
- Free tier
- Custom domains included
- HTTPS certificates fully managed
- Global CDN included
- Native GitHub Actions integration
No separate CDN.
No Front Door.
No certificate management.
No billing surprises.
Migration Strategy
The most important design decision was simple:
Change as little as possible in the existing workflow.
The Hexo build already worked perfectly.
Only the deployment target needed to change.
Step 1: Create an Azure Static Web App (Free)
In the Azure Portal, create a new Static Web App:
- Plan: Free
- Deployment source: GitHub
- Repository: existing Hexo repository
- Build preset: Custom / Other
Step 2: Adjust the GitHub Action (Hexo + SWA)
Hexo already produces static output in the public/ directory.
There is no reason to let Azure rebuild anything.
Key changes:
- build Hexo manually
- upload the already-built
public/directory - skip Oryx entirely
1 | - name: Deploy to Azure Static Web Apps |
Step 3: Custom Domain (blog.example.dev)
The blog is served from a subdomain:
blog.example.dev
Azure provides a CNAME target:
1 | CNAME blog <random>.azurestaticapps.net |
Step 4: Custom 404 Page
Azure Static Web Apps supports custom error handling via staticwebapp.config.json. The file needs to live in the projects root.
1 | { |
Cleanup: Removing Front Door
Done by a simple delete of all obsolete elements in the Azure Resource Group. The only remaining element is the Static Web App.
Lessons Learned
- Azure Front Door is not a CDN replacement.
- Static Web Apps should be the default for static sites.
- Registrar-level redirects are often the cleanest solution.
- Automatic migrations can have financial side effects.
Conclusion
Replacing Azure Front Door with Azure Static Web Apps reduced complexity, removed operational overhead, and brought hosting costs back to zero.
And don’t get me wrong, this is not a rant, but I would have preferred to get warned about upcoming costs of an automatic migration.
The complete workflow can be found at its dedicated GitHub repo.