☁️ From AWS to Azure: A Developer’s Journey Through Domains, HTTPS, and the Azure-verse

For years, I hosted my static website the usual way — a combo of AWS S3, CloudFront, and Cloudflare. It was familiar territory. The bucket was named after my domain, HTTPS was neatly managed via CloudFront or Cloudflare, and DNS validation was predictable.

But recently, I decided to experiment. I moved everything to Azure.

What followed was a journey filled with confusion, delight, occasional 400 errors, and a surprising amount of appreciation for the Azure ecosystem.

🔄 The Why Behind the Migration

I wasn’t frustrated with AWS. It’s reliable and deeply mature. But Azure had been catching my eye — particularly the simplicity of Azure Blob Storage for static sites, and the idea of combining Azure CDN, Front Door, and Entra ID for a more integrated setup.

Plus, I’d been working more with Azure professionally, and it made sense to align personal projects with what I was learning.

🌐 The Domain and DNS Curveball

Here’s where things got really different.

On AWS S3, you’re required to name your bucket exactly the same as your domain — for example, www.example.com — if you want to use a custom domain. Then you set up CloudFront, issue an ACM certificate, validate via DNS or email, and off you go.

With Azure, the process is more flexible… and slightly more opaque at first.

Azure doesn’t care if your storage account name matches your domain. You can name it something entirely different like myprojectstorage, and still serve www.example.com from it. All of the magic happens through a DNS CNAME record and portal-level domain configuration.

But there’s a catch.

To map a custom domain to a static website endpoint (like myprojectstorage.z20.web.core.windows.net), Azure makes you verify domain ownership using a special record — usually something like:

asverify.www.example.com CNAME asverify.myprojectstorage.z20.web.core.windows.net

This needs to be set up before Azure will accept requests to www.example.com.

Remove that verification record too soon (as I did), and Azure will promptly forget the domain — triggering mysterious 400 errors and “ErrorCode: InvalidUri” responses. The site fails, and you’re left wondering what just happened.

🛡️ HTTPS: Familiar Ends, Different Paths

Once domain validation is complete, you’d expect HTTPS to just work.

But here’s the thing — Azure doesn’t provide native HTTPS for custom domains on Blob Storage. Unlike AWS CloudFront or Cloudflare, where HTTPS is nearly frictionless, Azure requires you to plug in Azure CDN or Azure Front Door to get secure HTTPS for your domain.

So, I ended up using Azure CDN Standard (Verizon). It added HTTPS, caching, and edge acceleration — but it’s a mental shift coming from Cloudflare’s “orange cloud” toggle.

And if you’re layering Cloudflare on top (as I did), be very careful about SSL modes. Azure requires HTTPS on the origin, so Cloudflare must be set to “Full” or “Full (Strict)”. “Flexible” will break things. Ask me how I know.

🧭 The Azure Portal: A UI Adventure

Let’s talk about the Azure Portal.

Coming from AWS, which favors utility and minimalism, Azure felt like stepping into a control tower. Everything has a blade, a dropdown, a metrics panel, and at least three ways to do the same thing.

At first, it felt like UI overload.

But I’ll be honest — once I stopped trying to find a “simple” way and leaned into it, I found the experience pretty powerful.

Visual feedback is immediate.
Integrated docs help explain features inline.
You get to see what’s happening across storage, CDN, DNS, and security all in one place.

It takes time to adjust, but it’s not bad. Just… different. And very polished once you’re used to the Azure way of doing things.

🛂 Intune, Entra, and the Token Maze

Now, here’s the one area I still struggle with on Azure: authentication and tokens.

In AWS, setting up IAM users, roles, and policies always felt intuitive. I could wrap my head around the security model fairly quickly.

In Azure, you’re introduced to a cast of concepts: Service Principals, Microsoft Entra ID, role-based access control, and sometimes Intune if your setup gets complex.

Generating the right tokens, assigning the right scopes, and figuring out where to manage them takes effort. It’s powerful, but it’s not as discoverable as I hoped. Still, once configured properly (like for a GitHub Actions deployment or az storage blob sync), it just works.

🤔 Final Thoughts: AWS vs Azure — Not Better, Just Different

After living with the Azure setup for a while, I’ve realized that the differences between AWS and Azure are more philosophical than purely technical.

AWS favors composability and minimal abstraction. You build the tower yourself, brick by brick.
Azure leans toward opinionated integrations, a cohesive UI, and deeper enterprise alignment.

Both ecosystems are powerful.

And while AWS might be easier to comprehend at a glance, Azure feels more thoughtfully integrated — if you take the time to learn its way of thinking.

📝 TL;DR

DNS setup on Azure is clean, but be patient with domain validation.
HTTPS requires Azure CDN or Front Door, and Cloudflare must use Full SSL.
The portal is overwhelming at first, but becomes a feature-rich dashboard.
Security and token handling is a mental shift from AWS, but robust once understood.
Both clouds are equally powerful. Azure’s not second-place anymore.

If you’re migrating your site — static or not — to Azure and want a guide, a script, or a second pair of eyes, feel free to reach out.

Sometimes, it’s just nice to know you’re not the only one staring at a 400 error wondering why your custom domain suddenly stopped working.

Let me know if you’d like to convert this into a Next.js blog page, Notion article, or deploy it directly to your Azure static site.

BLOG PUBLISHING CHECKLIST

CHECK for dark mode or add callout
check for exisitng coding links and hrefs
check for style and width for all components
check hrefs and links

☁️ From AWS to Azure: A Developer's Journey Through Domains, HTTPS, and the Azure-verse