CloudFront + S3: Should You Ignore That Warning Message? 🤔 — Endpoint Choice Determines Service Quality

May 11, 2026

—

cslab

in IT Security

“This S3 bucket is configured as a website. We recommend using the website endpoint instead of the bucket endpoint.”

Ignore this one-line warning, and you’ll surely regret it later.

🎯 What this article covers

The exact meaning of the warning message that appears when configuring CloudFront origins
Key differences between S3 bucket endpoints vs. website endpoints
Criteria for choosing each endpoint based on the situation
Essential limitations to know when using OAC (Origin Access Control)
CloudFront + S3 configuration patterns you can use immediately in practice

📌 Introduction / Background

When creating a CloudFront distribution in the AWS console and specifying an S3 bucket as the origin, a yellow warning sometimes appears:

This S3 bucket is configured as an S3 website.

If you intend to use this distribution as a website, we recommend using the S3 website endpoint instead of the bucket endpoint.

Those seeing it for the first time might be flustered, thinking, “Is there a problem?” while those familiar with it habitually ignore it. However, whether this warning can be ignored or not depends entirely on the situation.

This article clarifies the meaning of the warning, the differences between each endpoint, and when to choose which one.

🔍 S3 Origin Endpoints: There are two types

When configuring an S3 bucket as a CloudFront origin, there are two types of endpoints you can choose from.

1️⃣ S3 Bucket Endpoint (REST API Endpoint)

bucket-name.s3.ap-northeast-2.amazonaws.com

S3’s default API endpoint
The exact address that auto-completes with the bucket name in the CloudFront console
OAC (Origin Access Control) or OAI (Origin Access Identity) can be applied → allows the bucket to remain completely private
❗ Subdirectory index documents not supported → a request to /blog/ will not automatically return blog/index.html

2️⃣ S3 Website Endpoint

bucket-name.s3-website.ap-northeast-2.amazonaws.com

The endpoint used when S3’s static website hosting feature is enabled
Automatic handling of index documents (index.html) and error documents (404.html)
Subdirectory index support → a request to /about/ automatically responds with about/index.html
❗ OAC/OAI not supported → requires disabling public access blocking for the bucket to function
❗ HTTPS not supported (the endpoint itself only supports HTTP; CloudFront handles HTTPS)

🤔 Should I ignore the warning message?

To put it simply: “It depends on the situation.”


Situation	Recommended Choice	Ignore Warning?
Static Website (React, Vue, Next.js static builds, etc.)	Website Endpoint	❌ Do Not Ignore
Keep Bucket Private + OAC Security Configuration	Bucket Endpoint	✅ Can Ignore
Simple File Distribution (Images, CSS, JS CDN)	Bucket Endpoint	✅ Can Ignore
SPA (Single Page Application) + Subpath Routing	Bucket Endpoint + CF Functions	✅ Can Ignore (but requires additional work)

—

💡 Key Difference: Subdirectory Index Handling

This is the most common problem that arises when ignoring the warning.

For example, assume S3 has files with the following structure:

/index.html
/about/index.html
/blog/index.html

When using the Bucket Endpoint:

→ index.html ✅ Normal response
→ ❌ 403 or 404 error occurs

When using the Website Endpoint:

→ index.html ✅
→ about/index.html ✅

Because of this difference, if you simply use the bucket endpoint when deploying sites built with static site generators like Next.js, Gatsby, or Hugo, errors will occur when accessing subpages.

🔐 For Security Priority: OAC + Bucket Endpoint

In security-conscious environments (most production setups), keeping a bucket publicly open is a concern. In such cases, OAC can be used to keep the bucket completely private while allowing only CloudFront to access it.

OAC Setup Flow:

사용자 → CloudFront → (OAC 서명 요청) → S3 버킷 (비공개)

In this scenario, you must use the bucket endpoint, as OAC does not work with the website endpoint.

S3 Bucket Policy Example (Allowing OAC):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/DISTRIBUTION_ID"
        }
      }
    }
  ]
}

💻 Solving Subdirectory Issues: Utilizing CloudFront Functions

Want to handle subdirectory indexes while using OAC? CloudFront Functions can solve this.

// CloudFront Functions — Connect to Viewer Request trigger
function handler(event) {
  var request = event.request;
  var uri = request.uri;

  // If the path ends with /, add index.html
  if (uri.endsWith('/')) {
    request.uri += 'index.html';
  }
  // If the path has no extension, add /index.html
  else if (!uri.includes('.')) {
    request.uri += '/index.html';
  }

  return request;
}

By attaching this function to the Viewer Request event of your CloudFront distribution, you can use the bucket endpoint and still handle /about/ → about/index.html.

⚠️ Cautions / Common Mistakes

1. Website Endpoint = Public Bucket Access Required If you configure CloudFront with a website endpoint, you must disable public access blocking for the bucket. Since OAC does not work, the bucket can be directly exposed externally. To enforce access only through CloudFront, you would need to configure a separate Referer header-based bucket policy, which is not a complete security solution.

2. SPA Routing Errors SPAs using client-side routing like React Router or Vue Router will request paths directly from the server upon refresh. If the S3 bucket does not have a file for that path, a 403/404 error will occur. You must configure CloudFront’s error page settings to redirect 403/404 errors to index.html.

3. HTTPS Configuration Confusion The website endpoint itself does not support HTTPS. However, you can set the communication between CloudFront and the origin to HTTP, and only handle HTTPS between the user and CloudFront. Specifying the Origin Protocol Policy as HTTP Only will work correctly.

✅ Summary / Conclusion

Whether a warning message can be ignored is not simply a “yes/no” answer but must be determined based on your use case and security requirements.


Purpose	Choice
Static site (requires subdirectory routing)	Website Endpoint
Enhanced security (OAC applied, bucket kept private)	Bucket Endpoint + CF Functions
Simple file CDN distribution	Bucket Endpoint (warning can be ignored)

In practice, the combination of OAC + Bucket Endpoint + CloudFront Functions is the most recommended pattern for achieving both security and functionality. The warning message should be taken as a signal to “understand, not ignore.”