{"id":156,"date":"2026-05-29T02:09:33","date_gmt":"2026-05-29T06:09:33","guid":{"rendered":"https:\/\/securebydefault.io\/blog\/?p=156"},"modified":"2026-07-13T12:48:33","modified_gmt":"2026-07-13T16:48:33","slug":"cloud-resume-challenge-aws-portfolio-visitor-counter","status":"publish","type":"post","link":"https:\/\/securebydefault.io\/blog\/cloud-resume-challenge-aws-portfolio-visitor-counter\/","title":{"rendered":"How I Built a Cloud Portfolio Website With a Visitor Counter Using AWS – From Start to Finish"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

There’s a point in most cloud learning journeys where tutorials stop being enough. You can follow along, click the buttons, watch things appear, and still not feel like you actually built something. The Cloud Resume Challenge exists specifically for that moment.<\/p>\n\n\n\n

The idea is simple: build a real portfolio website, host it on AWS, add a live visitor counter backed by a serverless API, wire the whole thing to automated CI\/CD, and document it. No step-by-step tutorial to follow. No hand-holding. Just you, AWS, and a blank text editor.<\/p>\n\n\n\n

I built mine. It’s live at ron-mercier101.com<\/a>. This is the complete walkthrough on what I built, why I made the decisions I made, what broke, and what I’d do differently.<\/p>\n\n\n\n

What I Was Building<\/strong><\/p>\n\n\n\n

The project splits into two distinct pieces, which is actually a good representation of how real cloud architecture works: a frontend that serves your content, and a backend that handles dynamic functionality.<\/p>\n\n\n\n

The frontend is a static portfolio website with HTML, CSS, and JavaScript, served globally via AWS. The backend is a serverless API that tracks how many people have visited, backed by a database that persists the count. When you load the site, the browser calls the API, the API increments the counter in DynamoDB, and the updated number shows up in the footer.<\/p>\n\n\n\n

Two separate GitHub repositories. Two separate deployment pipelines. One project that demonstrates you understand how modern cloud infrastructure actually fits together.<\/p>\n\n\n\n

Here’s what I used on each side:<\/p>\n\n\n\n

Frontend: S3 (file storage and static hosting) \u00b7 CloudFront (CDN + HTTPS) \u00b7 Route 53 (custom domain DNS) \u00b7 ACM (SSL\/TLS certificate) \u00b7 GitHub Actions (automated deployment)<\/p>\n\n\n\n

Backend: AWS Lambda (Python 3.12, serverless function) \u00b7 API Gateway HTTP API (the public endpoint) \u00b7 DynamoDB (PAY_PER_REQUEST, the database) \u00b7 AWS SAM (Infrastructure as Code) \u00b7 GitHub Actions with OIDC (automated deployment without stored credentials)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Part 1: The Frontend – Hosting a Static Site on S3<\/strong><\/p>\n\n\n\n

The first decision is one that trips people up: S3 is not a web server. It’s object storage that happens to have a static website hosting feature. That distinction matters because it affects how you configure access, how you connect it to CloudFront, and what security model you use.<\/p>\n\n\n\n

I started by creating an S3 bucket. The name doesn’t matter much, but I named it to match my domain (ron-mercier101.com<\/a>) for clarity. The region matters slightly more, so I chose us-east-1 because it’s where ACM certificates must live when used with CloudFront (more on that shortly) and because the latency difference for a personal portfolio is negligible.<\/p>\n\n\n\n

Under Object Ownership, I enabled ACLs during initial setup. ACLs (Access Control Lists) let you control permissions at the individual object level rather than the bucket level. For a simple static site where everything is meant to be public, this is the most direct approach. Without making the objects public (either via ACLs or a bucket policy), you’ll get a 403 Forbidden error when you try to load the site, which is a confusing first experience if you’re not expecting it.<\/p>\n\n\n\n

Static website hosting is a checkbox in the bucket Properties tab. Enable it, set index.html as the index document, and you’ll get an HTTP URL that looks like your-bucket.s3-website-us-east-1.amazonaws.com. That URL works, but it has two problems: it’s HTTP only (no HTTPS), and it’s not your domain. Both get solved in the next step.<\/p>\n\n\n\n

Part 2: CloudFront – HTTPS, CDN, and the Custom Domain Bridge<\/strong><\/p>\n\n\n\n

CloudFront is AWS’s content delivery network. It sits in front of your S3 bucket and does several valuable things at once: it distributes your content across AWS edge locations globally (so someone in Tokyo gets files from a nearby edge location rather than routing all the way back to us-east-1), it enforces HTTPS, and it’s where your custom domain connects.<\/p>\n\n\n\n


Creating a CloudFront distribution requires specifying your S3 bucket as the origin. There’s a subtlety here: if you point it at the S3 static website hosting endpoint (the .s3-website- URL), it handles things differently than if you point it at the S3 REST API endpoint (the .s3.amazonaws.com URL). I pointed at the REST API endpoint and enabled Origin Access Control (OAC) so that only CloudFront can read from the bucket; the bucket itself remains private to the public internet. This is the more secure approach, and AWS now recommends it over the older public bucket + CloudFront combination.<\/p>\n\n\n\n


The HTTPS piece requires an ACM certificate. There’s a gotcha: ACM certificates for CloudFront must be issued in us-east-1 regardless of where your bucket or distribution lives. Request a public certificate, add the CNAME validation records ACM provides to Route 53, wait for them to show as Issued (usually a few minutes), and attach the certificate to your CloudFront distribution. Set the viewer protocol policy to Redirect HTTP to HTTPS so nobody accidentally lands on an unencrypted version.<\/p>\n\n\n\n

Part 3: Route 53 – Making It Your Domain<\/strong><\/p>\n\n\n\n

Route 53 is AWS’s DNS service. The goal here is simple: when someone types ron-mercier101.com, Route 53 directs them to your CloudFront distribution instead of sending them directly to S3.<\/p>\n\n\n\n


You create a hosted zone for your domain, add an A record (alias) pointing to your CloudFront distribution, and optionally add an AAAA record for IPv6. If your domain is registered elsewhere (mine was), you update the domain registrar’s nameservers to point to Route 53’s four nameservers. DNS propagation can take anywhere from a few minutes to a few hours, and the site will start working once it finishes.<\/p>\n\n\n\n


After this step, the domain loads your portfolio over HTTPS with your own domain. The S3 URL still works, but nobody needs to know it exists.<\/p>\n\n\n\n

Part 4: GitHub Actions – Never Upload Files Manually Again<\/strong><\/p>\n\n\n\n

This is where the project starts feeling like a real workflow rather than a tutorial. The goal: when I push a change to the main branch, my website updates automatically without me touching the AWS console.<\/p>\n\n\n\n

The GitHub Actions workflow lives in .github\/workflows\/ in the repository. It runs on push to main, assumes an IAM role with permission to write to the S3 bucket, syncs the files (aws s3 sync), and optionally invalidates the CloudFront cache so the change is visible immediately rather than waiting for the cached version to expire.<\/p>\n\n\n\n

The authentication piece is worth understanding. The naive approach is to create an IAM user, generate an access key and secret, and store them as GitHub Secrets. This works but it’s not great, because those keys are long-lived credentials that don’t expire, and if they get exposed, someone has persistent AWS access until you manually rotate them.<\/p>\n\n\n\n

The better approach (and the one I used) is OIDC (OpenID Connect). Instead of storing credentials, you create an IAM OIDC identity provider in AWS that trusts GitHub’s token service, create an IAM role with a trust policy scoped to your specific repository, and the GitHub Actions workflow assumes that role temporarily using a short-lived token. No credentials stored anywhere. The token expires when the workflow ends.<\/p>\n\n\n\n

Part 5: The Backend – Where It Gets Interesting<\/strong><\/p>\n\n\n\n

The visitor counter is where the project stops being a ‘host a static file’ tutorial and starts being actual cloud engineering. The requirement: every time someone loads the portfolio, a counter increments, and the current count displays in the footer. This requires persistent storage, server-side logic, and a public API, none of which you can do with a static S3 site alone.<\/p>\n\n\n\n


I chose to build this serverlessly. No EC2 instance, no always-on server paying for compute time that isn’t being used. Instead, API Gateway receives the request, triggers a Lambda function, which reads and increments a value in DynamoDB, and returns the updated count as JSON.<\/p>\n\n\n\n


The entire backend: API Gateway, Lambda, DynamoDB, IAM roles, and CORS configuration, is defined in a single file called template.yaml using AWS SAM (Serverless Application Model). SAM is a CloudFormation transform that makes serverless IaC significantly less verbose. What would take 60+ lines of raw CloudFormation takes 15 lines in SAM. It compiles down to CloudFormation under the hood, so there’s no lock-in.<\/p>\n\n\n\n

Part 6: DynamoDB – Storing the Count<\/strong><\/p>\n\n\n\n

DynamoDB is AWS’s fully managed NoSQL database. For a visitor counter, the data model is about as simple as it gets: a single table with a single item containing a single attribute, which is the count. The key is an ID field (String type, value ‘visitors’), and the count is a Number attribute that gets atomically incremented on each request.<\/p>\n\n\n\n


The billing choice matters more than it might seem. DynamoDB offers two modes: provisioned (you pre-allocate read\/write capacity units) and on-demand (PAY_PER_REQUEST). For a portfolio site, provisioned capacity would mean paying for reserved throughput that sits mostly idle. PAY_PER_REQUEST charges per request and scales automatically, which costs nothing when nobody is visiting. For a project with unpredictable, low-volume traffic, it’s clearly the right choice.<\/p>\n\n\n\n


The table is named visitorCount, and the SAM template defines it with a DeletionPolicy of Retain, which means CloudFormation won’t delete the table when you tear down the stack. This is deliberate, so you don’t accidentally wipe your visitor count data when you run sam delete.<\/p>\n\n\n\n

Part 7: Lambda – The Logic Layer<\/strong><\/p>\n\n\n\n

The Lambda function is a Python 3.12 handler that does one thing: increment the visitor count in DynamoDB and return it. The handler reads the DynamoDB table name from an environment variable (TABLE_NAME, injected by SAM via !Ref VisitorTable), calls update_item with an atomic ADD operation, and returns the updated count as a JSON response with appropriate CORS headers.<\/p>\n\n\n\n

Using an atomic ADD rather than a read-modify-write is important. If two people visit the page at the same millisecond and both read a count of 41, then both write 42, you’ve lost a count. DynamoDB’s atomic counter operations handle concurrent updates correctly by design.<\/p>\n\n\n\n

The Lambda function has an IAM role attached via SAM’s DynamoDBCrudPolicy, scoped specifically to the visitorCount table. The role is set for Least privilege, so the function can only read and write that one table, nothing else in the account.<\/p>\n\n\n\n

Part 8: API Gateway – The Public Endpoint<\/strong><\/p>\n\n\n\n

API Gateway is what gives the Lambda function a public URL the browser can call. I used HTTP API (not REST API) for two reasons: it’s cheaper (roughly 70% less per request) and it’s lower latency. REST API’s premium features (caching, request validation, usage plans, API keys) are overkill for a simple counter endpoint.<\/p>\n\n\n\n

The route is GET \/count, deployed to a stage called Prod. CORS is configured to only accept requests from your domain. The visitor counter won’t work from any other origin, which is the intended behavior. The preflight response is cached for 3600 seconds (MaxAge: 3600) so browsers don’t send a CORS preflight on every single request.<\/p>\n\n\n\n

After deployment, SAM prints the API endpoint in the stack outputs. That URL goes into the JavaScript in index.html, which calls it on page load and animates the count up from zero.<\/p>\n\n\n\n

Part 9: Testing – Before It Hits Production<\/strong><\/p>\n\n\n\n

The backend repository has a tests\/ directory with pytest unit tests for the Lambda handler. The tests mock the DynamoDB client so no real AWS resources are needed to run them. This matters for the CI\/CD pipeline: tests run before the build and deploy steps, so a broken handler never makes it to production.<\/p>\n\n\n\n

The test-build-deploy sequence in GitHub Actions looks like this: pytest passes, sam build compiles the Lambda package, sam deploy pushes the CloudFormation stack update to AWS. If tests fail, the pipeline stops and nothing deploys. If the build fails, same result. Only a successful test and build proceeds to deployment.<\/p>\n\n\n\n

After any deploy, I run a smoke test: call the actual API endpoint and verify it returns valid JSON with a count field. This confirms the full stack is working, Lambda executed, DynamoDB updated, and API Gateway routed correctly. Unit tests verify the handler logic in isolation; the smoke test verifies the infrastructure actually deployed correctly. Both matter.<\/p>\n\n\n\n

What I’d Do Differently<\/strong><\/p>\n\n\n\n

A few things I’d change if I were starting fresh:<\/p>\n\n\n\n

Use OAC from the beginning. I initially set up the S3 bucket with public ACLs, which is the simpler approach and what the original Cloud Resume Challenge README described. The more secure model (private bucket with CloudFront OAC) is worth setting up correctly from day one, even if it takes slightly longer. Public buckets have a way of generating anxiety.<\/p>\n\n\n\n

Rename master to main immediately. The backend repository’s default branch is still called master. It’s a minor thing but it’s inconsistent with the frontend repo and with modern convention. Worth fixing early before the discrepancy becomes a habit.<\/p>\n\n\n\n

Remove .aws-sam from version control. The .aws-sam\/ directory contains build artifacts that don’t belong in git, so it’s the equivalent of committing node_modules. It inflates the repository size and adds noise to the commit history. Should have been in .gitignore from the start.<\/p>\n\n\n\n

Set up a CloudFront cache invalidation step in the GitHub Actions workflow. Right now, pushing a change deploys to S3 but the old version stays cached in CloudFront until the cache expires. Adding a cache invalidation step (aws cloudfront create-invalidation –distribution-id $ID –paths ‘\/*’) to the workflow means changes are visible immediately after deploy.<\/p>\n\n\n\n

The Full Stack, Summarized<\/strong><\/p>\n\n\n\n

The browser request arrives at Route 53, which points to CloudFront. CloudFront checks its cache and, if it has the file, serves it from the nearest edge location. If not, fetches from S3 (via OAC, the bucket stays private). The page loads. JavaScript calls the API Gateway endpoint. API Gateway invokes the Lambda function. Lambda does an atomic increment on the DynamoDB table and returns the updated count. JavaScript animates the number in the footer. The whole round-trip from page load to the counter display takes under 200 milliseconds on a warm Lambda.<\/p>\n\n\n\n


On the deployment side: I push to main on either repo. GitHub Actions authenticates to AWS via OIDC, so no stored credentials. Frontend workflow syncs files to S3. Backend workflow runs tests, builds the Lambda package with SAM, and deploys the CloudFormation stack. If everything passes, the update is live.<\/p>\n\n\n\n

What This Project Actually Teaches<\/strong><\/p>\n\n\n\n

The Cloud Resume Challenge is sometimes described as a beginner project, which undersells it. Getting S3 + CloudFront + Route 53 + ACM all wired together correctly, with the certificate in the right region, OAC configured properly, CORS locked to your domain, and OIDC set up instead of stored credentials, requires actually understanding what each service does and how they interact. The number of ways to get it subtly wrong is substantial.<\/p>\n\n\n\n

The backend: SAM, Lambda, DynamoDB, API Gateway, OIDC auth, automated testing, CI\/CD, covers most of the core serverless development loop. If you can build and deploy this, you can build and deploy most simple serverless APIs.<\/p>\n\n\n\n

The site is live at ron-mercier101.com. The backend repository is at github.com\/RonMercier\/cloud-resume-backend<\/a> and the frontend at github.com\/RonMercier\/AWS-S3-Static-Website<\/a>. Both have full READMEs with setup steps if you want to build something similar.<\/p>\n\n\n\n

Key Takeaways<\/strong><\/p>\n\n\n\n