When I started studying for the AWS Certified Solutions Architect Associate exam (SAA-C03), I thought it would be straightforward. I already worked in IT. I had touched cloud concepts before. I figured it would mostly be connecting dots and memorizing a few services.

I was wrong.

The exam is broad in a way that sneaks up on you. AWS isn’t just “learn EC2 and S3.” It’s learning how dozens of services interact under different constraints: cost, scalability, fault tolerance, security, operational overhead, and performance. The hard part isn’t memorizing definitions. It’s thinking like an architect under pressure.

Deploying a Hugo static site on AWS gives you a fast, scalable, and cost-effective setup. In this guide, we’ll walk through hosting your site on Amazon S3, distributing it globally via CloudFront, and pointing a custom domain using Route 53.

Prerequisites

Before starting, make sure you have:

• A built Hugo site (hugo command generates the public/ folder)
• An AWS account with appropriate IAM permissions
• A domain name registered in Route 53 (or transferred there)
• The AWS CLI installed and configured

Step 1: Build Your Hugo Site

Run the Hugo build command to generate your static files:

If your GitHub Actions workflow talks to AWS using AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, you are relying on long-lived credentials stored in GitHub secrets. That works, but it creates more secret management overhead than you need. A better approach is to use OpenID Connect (OIDC) so GitHub can request short-lived AWS credentials at runtime.

In this guide, I’ll walk through how to migrate a typical GitHub-to-AWS deployment from hard-coded tokens to OIDC. The pattern is especially useful for static site deployments, where GitHub Actions builds the site, uploads it to Amazon S3, and then invalidates CloudFront.