Introduction
I challenged myself with a real-world Azure scenario something beyond just spinning up a VM and calling it a day. So I set myself to host a fully functional marketing website for a fictional Lagos real estate startup on Azure, with no servers, no maintenance overhead, and as little cost as possible.
Here's exactly what I built, every decision I made, and why plus the mistakes I ran into along the way.
The Architecture Design Before Deployment
Before touching a single Azure resource, I mapped out the layout. This is a habit I'm building early because deploying without a clear design in mind is how you end up with resources in the wrong place and configurations you have to undo.
User types www.lagosproperties.com
│
▼
Azure DNS Zone (CNAME record)
│
▼
Storage Account — $web container
│
▼
index.html / about.html / contact.html
The key design decision here was deliberately avoiding compute. No VM means no OS to patch, no web server to configure, and no idle compute costs running 24/7. For a static marketing site, Blob Storage is the right tool — cheap, reliable, and maintenance-free.
Task 1 — Setting Up the Storage Account + Static Website
First, I created a StorageV2 storage account in the South Africa North region. because South Africa North is geographically closest to Lagos, which means lower latency for Nigerian visitors loading the site. a small detail, but the kind of thing that matters in production.
I also used Standard LRS (Locally Redundant Storage) for redundancy, Azure keeps three copies of the data within the same datacenter. For a marketing site, that's sufficient. A banking system would warrant something stronger like GRS, but over-engineering redundancy here would just drive-up cost unnecessarily.
With static website hosting enabled, Azure provisions a special $web container and assigns a public endpoint automatically. I built three HTML pages; Home, About, and Contact plus a custom 404 error page and uploaded all four to the container.
The site went live immediately at:
https://lagosproertiesstg.z1.web.core.windows.net/
Homepage
About page
Contact page
$web container showing all 4 files
Task 2 — Azure DNS Zone + CNAME Record
A storage endpoint URL works but lagosproertiesstg.z1.web.core.windows.net isn't something you'd put on a business card. I needed a proper custom domain.
So i created a public Azure DNS Zone for lagosproperties.com and configured a CNAME record pointing www.lagosproperties.com to the storage endpoint
One thing worth noting and something I learned during this project is that a CNAME record cannot sit at the root/apex of a domain (lagosproperties.com with no www). DNS standards don't allow it because the root domain must have SOA and NS records, which can't coexist with a CNAME. The www subdomain is where the CNAME lives. For the bare root domain to also work in production, an Alias record would be needed instead.
Azure automatically assigned four nameservers to the zone:
ns1-09.azure-dns.com
ns2-09.azure-dns.net
ns3-09.azure-dns.org
ns4-09.azure-dns.info
In a real deployment, I'd update these at the domain registrar to complete the delegation. But for this project, I verified the CNAME resolves correctly by querying Azure's nameservers directly using this command:
nslookup www.lagosproperties.com ns1-09.azure-dns.com
I chose to verify it this way at my own discretion, because anyone trying to load www.lagosproperties.com in a browser right now wouldn't see it yet without the registrar delegation. Querying the nameserver directly proves the Azure side of the configuration works perfectly!
Task 3 — Blob Versioning + Rollback
This is the part I found most valuable from a real-world perspective. Enabling blob versioning on the storage account means every time a file is overwritten, Azure silently keeps the previous version in the background automatically, with no extra configuration.
Why does this matter? Because mistakes happen. A content update with a typo, a broken layout, an accidental overwrite these are inevitable. "Being careful" doesn't scale as a strategy. Versioning is what gives you a fast recovery path when something goes wrong, regardless of why it went wrong.
To demonstrate this, I:
- Uploaded the original homepage — Version 1
- Edited the heading and re-uploaded the same file — Version 2 (now live)
- Confirmed both versions existed in Azure with different timestamps.
- Rolled back by restoring Version 1 as the current live blob.
- Refreshed the live site original content restored instantly.
Data Protection page showing versioning enabled
live site — Version 1 (original heading)
live site — Version 2 (updated heading)
Versions of the two timestamps in the azure portal
live site after rollback — Version 1 restored
Task 4 — What Does This Actually Cost?
One thing I always want to understand when building on Azure is what I'm actually paying for and why. So I ran the numbers through the Azure Pricing Calculator based on realistic assumptions for a small real estate site:
Assumption Value
─────────────────────────────────────────────────
Expected visitors/month ~5,000
Average pages viewed per visit 3
Total read operations/month ~10,000
Write operations/month ~1,000
Data retrieval/month ~100 MB
DNS zone 1
DNS queries/month ~10,000
Estimated monthly total: $1.14
That's the entire hosting cost for a production-ready marketing website DNS included. No compute, no idle server running overnight, no maintenance window. This is the core value proposition of serverless static hosting, and running these numbers myself made it genuinely concrete rather than just a talking point.
Below are images showing the Storage + DNS line items breakdown
Conclusion
What started as a simple "host a static site" challenge turned into a genuinely useful exercise in thinking through architecture, cost, DNS, and data resilience together not as separate topics, but as one connected system. The result is a serverless, sub-$2/month website that a real Lagos startup could deploy from day one with confidence.
Top comments (0)