Multi-cloud means understanding that every provider works differently. You only really learn that by actually building on them.

The Cloud Resume Challenge is a project by Forrest Brazeal that asks you to build and deploy a resume site using cloud services. I did it on AWS, then extended it to GCP, and ended up with something that actually touches most of the services you'd use in a real production environment.

What I built

The AWS side uses S3 for static hosting, CloudFront for the CDN, Route 53 for DNS, API Gateway and Lambda for the backend API, and DynamoDB for storage. Infrastructure is managed with CloudFormation and SAM. Deployments are automated with Ansible and GitHub Actions.

The GCP side mirrors the architecture: Cloud Storage for static hosting, a Cloud CDN in front of it, Cloud Functions for the backend, and Firestore for storage. That's managed with Terraform.

Frontend

S3 hosts the static files. CloudFront sits in front of it and handles HTTPS, caching, and routing. The S3 bucket is private -- CloudFront accesses it using an Origin Access Control (OAC), so nothing is exposed directly.

Route 53 handles DNS. The site runs on danphillips.cloud.

Backend

The visitor counter is a Lambda function behind API Gateway. It reads and increments a count in DynamoDB, then returns the value to the frontend via a fetch call.

CloudFormation and SAM manage the AWS infrastructure as code. GitHub Actions handles CI/CD -- on push to main, it syncs files to S3 and invalidates the CloudFront cache.

GCP

The GCP implementation uses the same architecture pattern. Cloud Storage hosts the static files, a load balancer with Cloud CDN handles distribution, Cloud Functions replaces Lambda, and Firestore replaces DynamoDB. Terraform manages all of it.

The interesting part is seeing where the two providers diverge. The concepts are the same but the implementation details are different enough that you can't just copy your AWS config and expect it to work.

What bit me

CORS in two places

The API Gateway needs CORS configured, and so does the Lambda function response. Getting one right and missing the other wastes a lot of time.

Regional vs Edge endpoint attributes

CloudFormation attribute names differ depending on whether you're using a Regional or Edge-optimized API Gateway endpoint. Use DistributionDomainName instead of RegionalDomainName, or CertificateArn instead of RegionalCertificateArn, and your deployment breaks in non-obvious ways.

Never manually delete CloudFormation resources

I did this once. The stack drifted and subsequent deployments failed. The only fix was deleting the whole stack and redeploying. CloudFormation manages its own state, don't touch resources outside of it.

Check .gitignore before your first commit

I committed vault files with credentials. Had to scrub them from git history. Won't happen again.

What I'd do differently

Automate CloudFront cache invalidation from the first deploy, not as an afterthought. Use OAC over OAI from day one since OAI is the legacy option. And set WWW as the primary domain upfront -- it keeps your bucket structure clean and leaves the apex free for subdomains.

Worth doing?

Yes. One project that touches storage, CDN, serverless compute, a NoSQL database, DNS, IaC, and deployment automation is genuinely useful for understanding how AWS services connect in a real architecture. For a job search it's something concrete you built and can walk through, not just another cert.

---

Full project on GitHub with AWS and GCP implementations, CloudFormation templates, Terraform config, and Ansible playbooks: danphillips-cloud/danphillips-aws