I Spent Three Hours Fighting CloudFront. Here's What I Actually Learned.

Jas — Mon, 29 Jun 2026 04:57:46 +0000

Today was supposed to be simple.

I'm working through the Cloud Resume Challenge, a project that has you build a resume site on AWS using S3, CloudFront, Lambda, DynamoDB, and a handful of other services, wired together by hand. The point isn't the resume. The point is proving you can actually use the infrastructure, not just talk about it.

Stage one: static site on S3. Done. Stage two: CloudFront with HTTPS.

Three hours later, I was staring at the same error message for the sixth time.

What Went Wrong

The error was this:

404 Not Found
Code: NoSuchBucket
BucketName: d2aoai2y8wmb9h.cloudfront.net

S3 was receiving requests and trying to find a bucket named after my CloudFront domain. Which doesn't exist. Which will never exist. That's not how any of this works.

Here's what was actually happening: CloudFront was forwarding the wrong Host header to S3. Instead of telling S3 "hey, I'm looking for content from resume.jasmineallen.dev.s3-website.us-east-2.amazonaws.com," it was sending its own domain name as the host. S3 saw that, tried to find a matching bucket, couldn't, and threw a 404.

The root cause was the AWS console's new simplified CloudFront UI. When I selected "Amazon S3" as my origin type during setup, it locked in S3-specific origin behavior under the hood. Behavior I couldn't fully override by just editing the origin domain afterward. The UI was abstracting away the exact setting I needed to change.

What I needed was a custom origin configured with CustomOriginConfig, which tells CloudFront to treat S3 as a plain HTTP server rather than an S3 bucket. That distinction matters because S3 static website hosting works differently from the S3 REST API, and CloudFront handles them differently.

The console wouldn't let me set it. Every path I tried hit a wall: blocked Host header overrides, stale cached errors, a distribution I couldn't delete because of a billing plan lock. I tried:

Editing the origin domain
Creating a second origin and swapping the behavior
Invalidating the cache
Disabling and re-enabling the distribution

None of it worked.

What finally worked was bypassing the UI entirely and using the AWS CLI to create a new distribution with the exact config I needed:

bashaws cloudfront create-distribution --distribution-config '{
  "Origins": {
    "Items": [{
      "DomainName": "resume.jasmineallen.dev.s3-website.us-east-2.amazonaws.com",
      "CustomOriginConfig": {
        "HTTPPort": 80,
        "OriginProtocolPolicy": "http-only"
      }
    }]
  }
  ...
}'

First try. Site loaded. HTTPS working.

What I Actually Learned

The console UI hides things that matter.

Simplified UIs are useful until they're not. The new CloudFront setup wizard made the wrong choice for my use case, S3 REST origin instead of custom HTTP origin, and then made it very hard to correct that choice after the fact. If I hadn't known to look for CustomOriginConfig as a concept, I would have been completely stuck.

This is true of a lot of AWS tooling. The console is great for exploration. For production configuration, the CLI or IaC gives you precision the UI sometimes can't.

Error messages are clues, not just complaints.

The BucketName: d2aoai2y8wmb9h.cloudfront.net in the error response was telling me exactly what was wrong. CloudFront was sending the wrong host. I just had to slow down and read it instead of treating it as noise.

Cache invalidation is not a magic fix.

I created two invalidations today trying to clear errors that weren't caused by caching. Invalidation tells CloudFront to stop serving stale content. It doesn't fix a misconfigured origin. Reaching for invalidation before diagnosing the actual problem just adds waiting time.

Sometimes you have to go lower in the stack.

The UI abstracted away the problem. The CLI solved it in one command. Knowing that the CLI exists and how to use it isn't optional knowledge. It's the fallback when the pretty interface runs out of options.

Why This Matters Beyond the Challenge

This exact class of problem shows up in real projects all the time.

A team sets up a CDN for a client-facing application using the console's default settings. Everything looks fine in the UI. Then traffic starts behaving strangely. Some requests are slow, some are returning stale content, some are failing entirely. Nobody can figure out why because nobody looked at the actual origin configuration. The UI said it was set up correctly.

Or a startup moves their static marketing site to CloudFront to improve global performance. The engineer who set it up used the wizard. Six months later a different engineer needs to debug a caching issue and finds the origin type is wrong, with the distribution locked into a billing plan that makes it hard to recreate cleanly.

Understanding what's actually happening underneath the UI isn't just useful for passing certifications. It's the difference between being able to debug your own infrastructure and being stuck with whatever the wizard decided for you.

A few concrete takeaways for anyone building on AWS:

For S3 static website hosting + CloudFront: always use the S3 website endpoint (bucket-name.s3-website.region.amazonaws.com) as a custom HTTP origin, not the S3 REST endpoint. The website endpoint handles index documents and error routing correctly. The REST endpoint doesn't.

Before reaching for cache invalidation: confirm the origin is actually returning what you expect by hitting the origin URL directly. If the origin is broken, no amount of invalidation will fix it.

Learn the CLI early. Not everything, just the services you're actively using. aws cloudfront create-distribution, aws s3 sync, aws lambda update-function-code. These give you a level of control and repeatability the console can't match.

Where I Am Now

S3 static site: done
CloudFront with HTTPS: done (via CLI, not the wizard)
DNS: pointing resume.jasmineallen.dev at CloudFront
Visitor counter: JavaScript to API Gateway to Lambda to DynamoDB
IaC
CI/CD
This post

The debugging was frustrating in the moment. Looking back, it was the most useful part of the day, more useful than if everything had worked on the first try.

That's the thing about infrastructure work. The happy path teaches you the steps. The broken path teaches you how it actually works.

Next up: DNS and the visitor counter.

Provisioning Jas is a series about building real things on AWS, written in real time, mistakes included.

I Audited My AWS Account and Here's What I Found

Jas — Sat, 27 Jun 2026 17:01:02 +0000

I finally sat down and did a proper audit of my AWS account. I knew I had projects running and services connected to my domains, but I had never actually gone line by line through the bill. When I did, I found $13.16 in charges across four separate services, some of which I did not even know were running.

Here is what I found and what I did about it.
AWS is not one bill. It is a lot of meters running at the same time.
Every service you spin up has its own pricing. I had four separate things billing me and I only really understood one of them.

EC2 — $8.25

A virtual Linux server running in US East Ohio. I spun this up for a study group project and forgot about it. EC2 charges by the hour whether anyone is using it or not. It does not care about traffic. It is a server and it is on until you turn it off.

VPC Public IP — $3.67

This one surprised me the most. AWS started charging for public IPv4 addresses in 2024. My EC2 instance had one attached and I had no idea it was a separate charge. It was just sitting there costing money.

Route 53 — $1.01

This is AWS's DNS service. I have two domains and each one has its own hosted zone. Fifty cents per hosted zone per month plus a small amount for DNS queries.

Amplify — $0.23

This was actually a good surprise. I did not realize I was using Amplify at all. Turns out one of my sites runs through it. Because it is a static site with low traffic, the cost was almost nothing.

What I did

The EC2 instance was for a study group project that is on hold right now. It was not serving any live site. I confirmed my actual portfolio still loaded fine without it, so I stopped it.

Stopping and terminating are not the same thing.

Stop powers it off and saves your work. A small storage charge still runs.

Terminate deletes everything permanently and stops all charges.
I stopped it.

My bill goes from $13.16 to about $1.64 next month.

What I took away from this

The money was not even the main thing. It was realizing I had services running that I did not fully understand. Now I know that EC2 is a full virtual server and it is overkill for a static site. Amplify is the better tool for that because it is built on S3 and CloudFront and handles the deployment for you. Public IP addresses cost money now even when nothing is running. And reading your bill line by line is actually a skill worth building early.

I am working through the Cloud Resume Challenge and building toward my AWS certifications. This was not a planned lesson but it ended up being one of the more useful things I have done.