☁️ Secure by Design: Hosting a Static Website on AWS

Select a component in the diagram, or jump directly to one below.

• Verified evidence exists and is referenced
• Needs verification described or reported, no evidence attached
• Planned not done yet
• Not applicable not part of this design

Before publishing screenshots of the AWS console, redact the 12-digit account ID, distribution ID, bucket ARN and any access keys.

Diagnostic flow

1. Check distribution deployment status

   Confirm the distribution shows Deployed, not In progress.

   Why: a distribution still deploying can behave inconsistently.

   Observed: not recorded

2. Inspect the origin domain

   Read the origin domain name exactly as configured.

   Why: it identifies which kind of S3 endpoint CloudFront is calling.

   Observed: not recorded

3. Is it an S3 REST endpoint or an S3 website endpoint?

   REST: <bucket>.s3.<region>.amazonaws.com. Website: contains s3-website.

   Why: OAC supports an S3 REST origin, not the website endpoint. This design needs REST.

   Observed: not recorded

4. Confirm index.html exists at the expected key

   List the bucket and check the key matches exactly, including case and any folder prefix.

   Why: an object in a sub-folder or with a different name is not found at /index.html.

   Observed: not recorded

5. Check the default root object

   It should be index.html, with no leading slash.

   Why: without it, a request for / asks S3 for the bucket itself rather than a page, which can be denied.

   Observed: not recorded

6. Inspect OAC attachment and signing

   On an S3 REST origin, check that an OAC is attached and signing behavior is set to sign requests.

   Why: unsigned requests cannot satisfy a policy that only trusts CloudFront.

   Observed: not recorded

7. Inspect the S3 bucket policy

   Read the statement text, bucket name and distribution reference in full.

   Why: a typo or a stale distribution reference denies access even if everything else is right.

   Observed: not recorded

8. Does the policy authorize the right distribution to s3:GetObject?

   Compare against this template. Replace placeholders with your own values; never publish real IDs.

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Sid": "AllowCloudFrontServicePrincipalReadOnly",
       "Effect": "Allow",
       "Principal": { "Service": "cloudfront.amazonaws.com" },
       "Action": "s3:GetObject",
       "Resource": "arn:aws:s3:::<BUCKET_NAME>/*",
       "Condition": { "StringEquals": {
         "AWS:SourceArn": "arn:aws:cloudfront::<ACCOUNT_ID>:distribution/<DISTRIBUTION_ID>"
       } }
     }]
   }

   Why: the condition scopes read access to one distribution, which is the least-privilege model.

   Observed: not recorded

9. If it fails on the custom domain: check alternate domain and certificate

   Confirm the domain is listed as an alternate domain name and that a valid ACM certificate in us-east-1 covers it. Compare with the default CloudFront URL.

   Why: if the CloudFront URL works but the custom domain does not, the fault is in domain, certificate or DNS, not the origin.

   Observed: not recorded (applies only if a custom domain is used)

10. Apply only a justified change

    Change one thing, tied to one hypothesis that the evidence supports. Write down what and why.

    Why: several simultaneous changes make the real cause impossible to identify.

    Change made: not recorded

11. Retest the affected URL

    Request the same URL again, allowing for cached error responses and deployment time.

    Why: a fix is only confirmed by a repeatable test.

    Result: not recorded

12. Record the result and the confirmed root cause

    Write down the exact response, the evidence, and the cause only if the retest supports it. If it does not, return to step 02 with the new evidence.

    Why: the record is what makes the investigation repeatable and explainable.

    Confirmed root cause: not recorded

Hypotheses to test (none confirmed)

1. Origin access is its own design problem

   CloudFront reaching S3 is not automatic. Decision: use an S3 REST origin with OAC rather than a public website endpoint.

2. Least privilege is specific

   “Allow CloudFront” is too broad. Decision: grant only s3:GetObject, scoped to one distribution with AWS:SourceArn.

3. HTTPS and DNS are separate layers

   The certificate, the alternate domain name and the DNS record can each fail independently. Decision: test the default CloudFront URL first, then the custom domain.

4. CloudFront changes take time

   Deployment and caching mean a change may not show immediately. Decision: check Deployed status and cache behavior before concluding a fix failed.

5. Troubleshoot with evidence

   Changing settings at random hides the real cause. Decision: collect the response, form one hypothesis, change one thing, retest.

6. Intended is not verified

   A diagram describes intent; only a test shows behavior. Decision: label each control Verified only when evidence is attached.

• PlannedComplete the 403 incident recordReproduce or review the symptom, collect evidence, confirm the root cause.
• PlannedComplete the verification matrixRun T01 to T10 and attach redacted evidence.
• PlannedCustom domain verificationRoute 53 record, ACM certificate in us-east-1, alternate domain name, HTTPS test.
• PlannedLogging and monitoringChoose suitable CloudFront and S3 logging; document what each answers.
• PlannedCache behavior and invalidationDocument cache settings and when an invalidation is needed after updates.
• PlannedCost reviewEstimate and document the cost drivers. No savings are claimed.
• PlannedEvaluate AWS WAF only if justifiedAdd it only if a threat model shows a need; it is not part of the current design.
• PlannedOperational documentationA short runbook for deploying and rolling back site updates.