Cloud Resume Challenge

cristianxcueva — Mon, 29 Jun 2026 15:53:22 +0000

Building a Serverless Resume on AWS

I rebuilt my resume as a live AWS application instead of a PDF. It's a static site backed by a real serverless pipeline: a visitor counter that reads and writes to a database, behind an API, deployed through infrastructure as code, with its own CI/CD pipeline pushing updates automatically. I did this through the Cloud Resume Challenge, and this post walks through how it's built and what I actually learned doing it.

The Architecture

The site itself is static: HTML and CSS, no server rendering anything on the fly. It's hosted in an S3 bucket, sitting behind CloudFront, with Route 53 pointing my custom domain at the CloudFront distribution. Nobody hits S3 directly. Every request goes through CloudFront first, which means consistent load times no matter where in the world someone's loading the page from, and it keeps the actual storage layer shielded from direct traffic.

That's the whole story for the page itself. The visitor counter is a separate thing entirely, and it only starts once the page has already finished loading.

Once the page renders, JavaScript running in the browser fires off a fetch to API Gateway. API Gateway invokes a Lambda function through a resource policy attached directly to it, that's a different kind of permission than the role Lambda itself uses, one controls who can call Lambda, the other controls what Lambda is allowed to do once it's running. The Lambda function uses its own execution role to read and write a single item in a DynamoDB table: the current visitor count. It increments that number, writes it back, and the result travels back through Lambda, through API Gateway, and into the page, where the count updates on screen.

Every piece of this, the S3 bucket, CloudFront, Route 53, the IAM roles, the Lambda function, the DynamoDB table, API Gateway, was provisioned through Terraform. None of it was clicked together in the AWS console. And once it was built, GitHub Actions took over deployment entirely: push code, the pipeline runs tests, and if they pass, it deploys automatically.

What I Learned

Terraform changed how I think about building anything in AWS. Every resource in this project, down to the IAM policies, lives in code I can read, version, and redeploy from scratch. I learned the actual shape of writing Terraform for a wide range of services, and I ran into real ordering problems along the way, depends_on exists because Terraform doesn't always know that one resource needs to fully finish before another can safely apply, and I hit that failure firsthand before I understood why it mattered.

I also learned to actually reason about service choices instead of defaulting to the familiar option. DynamoDB made sense here over something like Aurora Serverless because this is a single counter, not relational data, and DynamoDB's schemaless model and on-demand pricing fit that far better than spinning up anything resembling a traditional database.

Identity and permissions turned out to be deeper than I expected. Lambda doesn't need an instance profile the way EC2 does, it just takes an execution role directly. And that role only covers what Lambda can do, it has nothing to do with who's allowed to invoke Lambda in the first place, that's a separate, resource based permission entirely. I also learned, the hard way, that my own AWS credentials had no business being inside a GitHub Actions pipeline, even though they technically would have worked. An automated system running unsupervised deserves its own scoped identity, not my personal admin access, so I built dedicated IAM users for each pipeline instead.

Most of the real learning happened in the failures. One implicit AWS region setting worked fine on my machine, because my local AWS CLI was quietly filling in a value I never actually specified in the code, and failed instantly the moment that same code ran on a fresh GitHub Actions runner with no such fallback available. Another time, an automation user's IAM policy didn't grant it permission to read information about itself, so the pipeline failed trying to manage a resource it owned. That exact pattern, permissions falling behind as the infrastructure grew, showed up three separate times across this project, and recognizing it as one repeating shape instead of three unrelated bugs was its own kind of lesson.

This project also started as a single repository, built milestone by milestone, before getting split into separate frontend and backend repos once CI/CD needed two independent pipelines. Restructuring an already working project, rather than getting it right from the start, turned out to be its own real skill.

DEV Community: cristianxcueva

Cloud Resume Challenge

Building a Serverless Resume on AWS

The Architecture

What I Learned