What I was actually building

CloudFront sits as the only public entry point in front of a private S3 bucket. Origin Access Control makes sure only the CloudFront distribution is allowed to read from it. Route 53 then maps a real domain name onto that CloudFront distribution, so visitors type www.yourdomain.com instead of some random .cloudfront.net URL.

User types yourdomain.com
        │
        ▼
   Route 53 (DNS)
        │
        ▼
CloudFront Distribution
        │
        ▼
S3 Bucket (private — no public access)

The bucket, the access policy, the CDN, the DNS, and other resources were all defined in Terraform, and the whole stack came up with a couple of terraform apply runs.

The first wall I hit: A 403 on my custom domain

Once I had the S3 bucket and CloudFront distribution up, the auto-generated CloudFront URL worked fine. But the moment I tried hitting it through my actual domain, I got a 403.

It turns out CloudFront only answers requests for hostnames explicitly listed in its aliases config. Anything else gets rejected before it even reaches the origin. I was missing two things: the aliases block telling CloudFront "yes, accept requests for this domain," and an ACM certificate to handle HTTPS for it.

Code that caused the 403: missing aliases and viewer_certificate on CloudFront

resource "aws_cloudfront_distribution" "main_s3_distribution" {
  origin {
    domain_name              = aws_s3_bucket.main.bucket_regional_domain_name
    origin_id                = local.s3_origin_id
    origin_access_control_id = aws_cloudfront_origin_access_control.main.id
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    target_origin_id       = local.s3_origin_id
    viewer_protocol_policy = "redirect-to-https"

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true    # ← no custom certificate
  }
                                             # ← no aliases block
}

The fix was straightforward once I understood the why: request the certificate, attach it via viewer_certificate, add the domain to aliases. Simple change, but it took actually hitting the error to understand what CloudFront was protecting against.

Code that fixed the 403: added aliases and viewer_certificate with ACM

resource "aws_cloudfront_distribution" "main_s3_distribution" {
  origin {
    domain_name              = aws_s3_bucket.main.bucket_regional_domain_name
    origin_id                = local.s3_origin_id
    origin_access_control_id = aws_cloudfront_origin_access_control.main.id
  }

  enabled             = true
  default_root_object = "index.html"

  aliases = [var.domain_name]              # ← tells CloudFront to accept requests
                                           #   for your custom domain

  default_cache_behavior {
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    target_origin_id       = local.s3_origin_id
    viewer_protocol_policy = "redirect-to-https"

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate_validation.main.certificate_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }                                        # ← custom ACM certificate attached
}

The bigger problem: why my terraform apply just... hung

My domain is registered with a third-party registrar (not Route 53), and when ACM issues a certificate, it validates ownership by writing a CNAME record into the Route 53 hosted zone and then polling DNS for it publicly.

Here's the catch: that DNS query only reaches Route 53 if the domain's nameservers at the registrar are actually pointed at Route 53. If they're not, ACM's validation query hits the registrar's default nameservers instead, which have no idea what CNAME record it's looking for. The certificate just sits in PENDING_VALIDATION forever, and terraform apply hangs right along with it, blocked on this resource:

  certificate_arn         = aws_acm_certificate.main.arn
  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

The fix was splitting the deployment into two stages instead of one.

Stage one — provision just the Route 53 hosted zone:

terraform init
terraform validate
terraform apply -target=aws_route53_zone.main_route

Then grab the four nameservers Route 53 assigned:

terraform output route53_nameservers

...and go update them at the registrar. Then wait (anywhere from 5 minutes to 48 hours) and confirm propagation:

nslookup -type=NS yourdomain.com

Stage two — once the nameservers have actually propagated, run the full apply:

terraform plan
terraform apply

This time ACM's validation query lands on Route 53, finds the CNAME record Terraform already wrote there, and the certificate issues cleanly. Terraform waits for it to hit ISSUED before attaching it to CloudFront, then finishes provisioning the other resources.

Not glamorous, but it's the kind of thing you only really understand after watching it fail once.

A few other things that clicked

CNAME vs. alias A record. The obvious choice for pointing a domain at CloudFront's domain name looks like a CNAME. It is not allowed at the zone apex, which is the root domain, so that option is off the table from the start. Route 53's alias A record solves this properly: it maps directly to an AWS resource instead of a raw IP, works at the root domain, resolves inside AWS's own DNS, and does not cost extra in Route 53 query charges. Once that became clear, the choice was obvious.

OAC over OAI. CloudFront used to lock down S3 access with something called Origin Access Identity, basically a special CloudFront user added to the bucket's ACL. It is being phased out in favour of Origin Access Control, which uses proper IAM style signed requests (SigV4), works across all S3 regions, and supports KMS encryption. The bucket policy also ties access to one specific distribution's ARN, rather than any CloudFront distribution somewhere, a meaningfully tighter setup for barely any extra configuration.

What the finished setup actually does

• Remote state locking means I am not going to accidentally overwrite my own state file mid apply.

• The S3 bucket stays fully private. No public bucket policy, only the CloudFront distribution I created can read from it, enforced through a least privilege policy scoped to CloudFront's service principal plus a SourceArn condition.

• Website files upload automatically from a local www/ folder, with Terraform working out the correct content_type for each file extension.

• HTTPS is enforced on every request through redirect to https.

Final thoughts

None of these problems were exotic on paper. A 403 on a custom domain, a certificate stuck validating, a DNS record type that seemed obvious until it was not. But reading about them in a checklist and actually watching them happen on my own infrastructure are two different educations. One tells you what to do. The other teaches you why it matters, and that difference is what made the pieces of this project actually stick.

This project touched IAM, ACM, S3, CloudFront, and Route 53, and it made me understand how they depend on each other, not just how to spin them up. That understanding is the part that carries over when the infrastructure gets bigger and the stakes get higher.

Full code, with the actual Terraform files, is here: aws-s3-cloudfront-webhosting-terraform