Introduction

This error usually appears when CloudFront requests exactly the path the viewer asked for, but your S3 origin only has index.html under that path. The confusion comes from assuming CloudFront will always perform the same implicit index-document behavior as S3 static website hosting. Sometimes it will not, depending on which origin type you are using and which path is being requested.

Root Index and Nested Index Are Different Problems

CloudFront has a Default Root Object, but that applies to the distribution root, such as /. It does not automatically solve every nested path such as /docs/ or /blog/post/.

That is why a root request may work while a deeper request returns "The specified key does not exist". CloudFront may be asking S3 for /docs/ when the actual object is /docs/index.html.

Know Which S3 Origin Type You Are Using

If CloudFront points at the S3 website endpoint, S3 website hosting can handle directory index behavior for paths with a trailing slash. If CloudFront points at the S3 REST endpoint, that website-style index resolution does not happen the same way.

This distinction matters a lot. Two distributions can both "use S3" and still behave differently because one is using the website endpoint and the other is using the bucket as a REST origin.

Use a Rewrite for Nested Index Pages

A common fix is to rewrite requests that end in / so they request index.html explicitly.

1function handler(event) {
2    var request = event.request;
3    var uri = request.uri;
4
5    if (uri.endsWith('/')) {
6        request.uri += 'index.html';
7    }
8
9    return request;
10}

This kind of function can run at the CloudFront edge and turns /docs/ into /docs/index.html before the origin request happens.

Default Root Object Still Matters, but Only at Root

You should still configure the distribution's default root object when the homepage is supposed to resolve to index.html.

That fixes the root request path, but it is not a general substitute for nested-path rewrites. Developers often set it once, see the homepage working, and then assume subdirectories will behave identically.

Verify the Object Really Exists

Before debugging CloudFront logic too deeply, confirm that the expected object actually exists in S3 at the rewritten path.

If the desired behavior is /docs/ serving /docs/index.html, then /docs/index.html needs to exist as an object. CloudFront and S3 cannot invent a file that is not there.

That sounds basic, but it eliminates a lot of false debugging paths quickly.

Caching Can Hide Configuration Changes

CloudFront caches errors too. After changing origin settings, rewrite behavior, or uploaded files, invalidate the relevant paths or wait for the cache to expire.

Otherwise you can fix the origin problem and still keep seeing the old error from cache, which is a very common source of confusion in CDN debugging.

Common Pitfalls

• Assuming Default Root Object handles nested subdirectories automatically.
• Forgetting the difference between an S3 website endpoint and an S3 REST origin.
• Expecting /path/ to work when only /path/index.html exists and no rewrite is configured.
• Debugging CloudFront before confirming the actual object exists in S3.
• Forgetting that CloudFront may still be serving a cached error response.

Summary

• The error usually means CloudFront asked S3 for the wrong key, often a directory path instead of index.html under that path.
• 'Default Root Object helps at the distribution root, not automatically for every nested path.'
• Origin type matters because S3 website endpoints and REST origins resolve paths differently.
• Edge rewrites are a common fix for nested implicit index-document behavior.
• Always verify object existence and consider cached errors during debugging.