deploy a static web app with a fully private S3 bucket by putting CloudFront in front of it

AWS S3 Cloudfront.md

You can deploy a static web app with a fully private S3 bucket by putting CloudFront in front of it and granting CloudFront exclusive access. The “legacy” style CloudFront distribution uses an Origin Access Identity (OAI) instead of the newer Origin Access Control (OAC).

Prerequisites

• An AWS account with permissions for S3, CloudFront, and IAM.
• A built static website folder on your machine (for example containing index.html, CSS, JS, and assets).
• Optional but recommended: a registered domain (for example via Route 53) and an ACM certificate in us-east-1 if you want HTTPS on a custom domain.

Step 1 – Create a private S3 bucket

1. In the AWS console, go to S3 and choose “Create bucket”.
2. Give it a DNS-compliant name (for example my-static-site-bucket) and choose your region.
3. Under “Block Public Access”, leave Block all public access enabled (this keeps the bucket private).
4. Complete creation with all other settings default (versioning/encryption optional).
5. After creation, go to the bucket “Permissions” tab and confirm:
   • “Block public access” is ON.
   • No bucket policy is present yet.
   • “Access control list (ACL)” does not grant public access.

Step 2 – Upload your static web app

1. Open the bucket and click “Upload”.
2. Add all your site files (HTML, CSS, JS, images, etc.) and start the upload.
3. Ensure that at least an index.html file exists at the root of the bucket (or wherever you plan to point CloudFront’s default root object).

Note: You do not need to enable “Static website hosting” on the bucket when using CloudFront; CloudFront can simply read objects directly from S3.

Step 3 – Create an Origin Access Identity (legacy access)

1. Go to the CloudFront console and open the “Origin access” or “Security” related section (exact UI label may vary slightly, look for “Origin access identity”).
2. Create a new Origin Access Identity (OAI) and give it a recognizable name (for example my-static-site-oai).
3. Copy or note the OAI identifier; it will be used when configuring the origin and bucket policy.

This OAI is a special “user” that CloudFront uses to fetch objects from your S3 bucket, while the bucket remains private to everyone else.

Step 4 – Attach OAI to a new CloudFront distribution (legacy distribution)

1. In CloudFront, choose “Create distribution” and select Web (if asked).
2. For Origin domain, choose your S3 bucket (the regular bucket endpoint, not the static website endpoint).
3. Set Origin access to use the legacy OAI:
   • Choose “Origin access identity (legacy)”.
   • Select the OAI created earlier.
   • Choose the option to automatically update the bucket policy if offered; otherwise you will add the policy manually in the next step.
4. Ensure Viewer protocol policy is set to “Redirect HTTP to HTTPS” (or “HTTPS only”) to enforce HTTPS.
5. Under Default cache behavior:
   • Allowed HTTP methods: usually “GET, HEAD” is enough for a static site.
   • Cache policy: you can start with the managed “CachingOptimized” policy.
6. In Settings:
   • Set Default root object to index.html (or your main file).
   • If using a custom domain, enter it as an Alternate domain name (CNAME) and select your ACM certificate from us-east-1.
7. Create the distribution and wait for it to deploy (this can take several minutes).

Once deployed, CloudFront will provide a domain name like d123456abcdef.cloudfront.net that you can use immediately to access the site.

Step 5 – Lock S3 so only CloudFront can read it

If CloudFront did not auto‑update the bucket policy, add it yourself so that only the OAI can access objects:

1. Go to S3 → your bucket → “Permissions” → “Bucket policy”.
2. Add a policy of the following form (replace placeholders):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontOAIReadOnly",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity YOUR_OAI_ID"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
    }
  ]
}

3. Save the policy.
4. Confirm:
   • The bucket still has Block public access enabled.
   • There is no “Everyone (public access)” permission in the ACL.

Now the bucket is private; only CloudFront (via the OAI) can read your files.

Step 6 – Test CloudFront access

1. In your browser, open the CloudFront distribution domain, for example https://d123456abcdef.cloudfront.net.
2. You should see your static site load.
3. Test a direct S3 object URL (copy an object URL from the S3 console):
   • It should now return an Access Denied error, confirming the bucket is private.
   • The same file should load fine via the CloudFront URL.

If the CloudFront root URL returns an error:

• Check that the Default root object in the distribution is set correctly (index.html).
• Confirm that the file exists in the bucket path CloudFront expects.
• Verify the bucket policy uses the exact OAI ID of the distribution.

Step 7 – Optional: use your own domain

If you have a domain and want to access the app via something like https://www.example.com:

1. Make sure you have an ACM certificate in us-east-1 for your domain (for example www.example.com).
2. In the CloudFront distribution:
   • Add your domain under “Alternate domain names (CNAMEs)”.
   • Attach the ACM certificate that matches the domain.
3. In your DNS service (for example Route 53), create an A record for www.example.com:
   • Type: A (or A – IPv4).
   • Alias: Yes (if using Route 53).
   • Target: your CloudFront distribution.
4. After DNS propagates, visit https://www.example.com and confirm the site loads via CloudFront.

By the end of these steps you have a private S3 bucket that only CloudFront (via a legacy OAI) can read and a CloudFront “legacy” Web distribution that serves your static web app over HTTPS. You can access it using the CloudFront URL or, optionally, your own custom domain.

1 2 3 4 5 6 7 8 9 10