Building a Multi-Cloud Portfolio Site

March 13, 2026 • 5 min read

When I decided to build a portfolio site, I had a clear goal: show, don't tell. Rather than just writing about infrastructure patterns, I wanted this site to be the example of clean, transparent infrastructure design.

So I built it twice! Once on AWS, once on Azure. Here's why that matters and how you can do the same.

Why Multi-Cloud?

Multi-cloud deployments aren't about hedging bets (although that's nice and I am a big fan of Monzo Stand-in).They're about demonstrating that you understand the differences between cloud platforms and can make intentional choices about where workloads go, architecture and developer experience.

For a static site, the pattern is identical on both platforms:

The infrastructure is nearly identical. The tools are different, but the thinking is the same. That's what a hiring manager wants to see: that you can translate patterns between platforms.

The AWS Side

AWS is the straightforward path. Create an S3 bucket, enable static website hosting, upload your HTML, then sit CloudFront in front of it for caching and HTTPS. 


# AWS setup (simplified)
aws s3 mb s3://my-portfolio-bucket
aws s3 sync ./site s3://my-portfolio-bucket
# CloudFront distribution points to S3 origin
# GitHub Actions: aws s3 sync on push

The real value here is understanding Origin Access Control (OAC) - you don't want the S3 bucket publicly accessible. You want CloudFront to be the only thing that can read from it. That's a security pattern worth knowing.

The Azure Side

Azure's approach is slightly different. You use Blob Storage (the Azure equivalent of S3), but for the best experience, you front it with Azure CDN or, even better, Azure Static Web Apps.

Static Web Apps is worth mentioning because it does something nice: it handles the Blob-to-CDN connection for you, integrates with GitHub automatically, and gives you a consistent URL. You can also use it for simple serverless functions if you ever need dynamic content later. 


# Azure setup (simplified)
az storage account create --name myportfolio
az storage blob upload-batch -s ./site -d '$web'
# Azure CDN or Static Web Apps in front
# GitHub Actions: az storage blob sync on push

The CI/CD Layer

This is where the "transparency" part really shines. With GitHub Actions, you can define exactly what happens when you push code:

Your git history shows every deployment. Your workflow file shows exactly what's happening. No magic.

Cost Considerations

Keeping an eye on the bottom line? Of course, tough times.

A static site is cheap. It often comes up as a pattern in exams for this reason.

You're paying for:

Running it on both clouds doesn't double the cost in any meaningful way - you're storing identical data on two platforms at minimal cost and paying for CDN traffic (which you'd pay either way).

Next Steps

If you want to add dynamic content later, the pattern doesn't break. You can add API Gateway on AWS or Functions on Azure, pointing to the same static site. The infrastructure is ready for evolution without redesign. 


Contact Form

AWS Path:
Lambda function — Receives form data, sends email
API Gateway — Exposes Lambda as an HTTP endpoint
HTML form — Points to API Gateway URL

Azure Path:
Azure Functions — Receives form data, sends email
Function App HTTP trigger — Exposes function as endpoint
HTML form — Points to Function URL


Payments

AWS Path:
Stripe/PayPal API — Handle payment processing
Lambda — Validates payment, updates your records
API Gateway — Exposes endpoint
HTML — Stripe.js form on your site

Azure Path:
Stripe/PayPal API — Same
Azure Functions — Validates payment
Function URL — Exposes endpoint
HTML — Stripe.js form

That's the real benefit of getting the foundations right.

← Back to blog