Deploy a static site to S3 + CloudFront

Private bucket, default settings, one CLI command

Pick a bucket name. It has to be globally unique across all of AWS, so something like mybrand-site-prod-2026. The name doesn't matter much — users never see it; CloudFront sits in front.

aws s3api create-bucket \
  --bucket mybrand-site-prod-2026 \
  --region us-east-1
# (For regions other than us-east-1, add --create-bucket-configuration LocationConstraint=<region>)

Leave the default "Block all public access" settings on. With CloudFront + OAC in front (Step 4), the bucket stays private; CloudFront has its own credential to read from it. Public-bucket setups still work but are the deprecated pattern — newer AWS docs all use OAC.

aws s3 sync is the deploy command

If your site is built into ./dist (or ./build, ./public, whatever):

aws s3 sync ./dist s3://mybrand-site-prod-2026 --delete
# --delete removes files in S3 that no longer exist locally —
# without it, removed pages stay live as orphans.

The first sync uploads everything. Subsequent syncs only upload changed files. This is the deploy command you'll script later. At this point S3 has the files but they're inaccessible — the bucket is private and there's no CloudFront yet.

Region matters; CloudFront only reads certs from us-east-1

This is the most common first-time error. AWS Certificate Manager certificates are region-specific. CloudFront is a global service but is fronted by us-east-1 for cert lookup. Switch the console region to "US East (N. Virginia) — us-east-1" before requesting the cert, or do it via CLI:

aws acm request-certificate \
  --domain-name mybrand.com \
  --subject-alternative-names www.mybrand.com \
  --validation-method DNS \
  --region us-east-1

ACM returns a CertificateArn and a set of CNAME validation records — one per domain in the cert. If your DNS is at Route 53 in the same account, the console offers a one-click "Create records in Route 53" button. Otherwise, you copy each CNAME to your DNS provider manually. Validation takes minutes once the records are live.

The complicated step; do it in the console

Open CloudFront → Create distribution. Fill out:

• Origin domain: select your S3 bucket from the dropdown (not the website endpoint — pick the bucket itself).
• Origin access: Origin access control settings (recommended). Click Create new OAC, accept defaults, save. CloudFront will give you a bucket policy snippet at the end of distribution creation — you'll paste it into S3 in Step 5.
• Viewer protocol policy: Redirect HTTP to HTTPS.
• Allowed HTTP methods: GET, HEAD (static sites don't need POST).
• Alternate domain names (CNAMEs): mybrand.com and www.mybrand.com.
• Custom SSL certificate: select the ACM cert from Step 3.
• Default root object: index.html.

Create. CloudFront provisions the distribution; this takes 5–15 minutes the first time. You'll get a distribution domain name like d1234abcde.cloudfront.net — you can hit that URL directly to test before DNS is wired up.

Let CloudFront read from the bucket; nothing else

The OAC creation flow shows a bucket policy snippet on the success screen. Copy it. In S3 → bucket → Permissions → Bucket policy, paste it in. It looks like:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipalReadOnly",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::mybrand-site-prod-2026/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::123456789:distribution/E1ABCDEFGHIJK"
      }
    }
  }]
}

The SourceArn condition is what makes OAC secure: only your specific distribution can read the bucket. Without it, any CloudFront distribution in any account could.

One Alias record per domain, in Route 53

In Route 53 → your hosted zone → Create record:

• Record name: empty (for apex) or www (for the www subdomain).
• Record type: A.
• Alias: on.
• Route traffic to: Alias to CloudFront distribution → select yours.

Create. Repeat for the other name (apex / www). DNS propagates in minutes — for an Alias record on the same AWS account, often seconds.

If your DNS isn't at Route 53, add a regular CNAME record at your DNS provider with value d1234abcde.cloudfront.net for www, and use your DNS provider's CNAME-flattening / ALIAS feature for the apex (DNS tutorial covers this).

Three checks; then it's three commands forever

# 1. Cert is on the distribution.
curl -sI https://mybrand.com | grep -E '^(HTTP|Server)'
# Expected: HTTP/2 200 ... Server: CloudFront

# 2. Files are reachable.
curl -s https://mybrand.com | head
# Expected: your index.html.

# 3. DNS points at CloudFront.
dig mybrand.com +short
# Expected: a CloudFront edge IP (changes per region; just confirm it's not blank).

From now on, deploys look like this — save these three lines as deploy.sh in your project:

#!/usr/bin/env bash
set -e
npm run build
aws s3 sync ./dist s3://mybrand-site-prod-2026 --delete
aws cloudfront create-invalidation \
  --distribution-id E1ABCDEFGHIJK \
  --paths "/*"

The invalidation is the part that makes new files visible immediately. Without it, CloudFront keeps serving cached old files until the TTL expires (default 24 hours for cached responses). You get 1,000 invalidation paths free per month — for one-path invalidations on every deploy, that's 33/day, which covers most projects.