Ein Entwickler hostet eine statische Website in einem S3-Bucket, die über CloudFront bereitgestellt wird, wobei Origin Access Control (OAC) verwendet wird, damit der Bucket nicht öffentlich ist. Benutzer können auf explizite Datei-URLs zugreifen (z. B. /products/index.html), erhalten jedoch einen Fehler, wenn sie Verzeichnis-URLs anfordern (z. B. /products/). Ohne den S3-Bucket öffentlich zu machen, wie können Verzeichnisanfragen so bedient werden, dass sie die Standard-Indexdatei zurückgeben?

Die korrekte Antwort ist, eine CloudFront-Viewer-Request-Funktion zu erstellen. Wenn Benutzer eine Verzeichnis-URL wie /products/ anfordern, sendet CloudFront diese Anfrage an den S3-Origin. Da S3-Buckets, die nicht als statische Websites konfiguriert sind, keine Indexdokumente für Verzeichnisse unterstützen, schlägt die Anfrage fehl. Eine Viewer-Request-Funktion kann die eingehende Anfrage abfangen und die URL umschreiben, indem sie index.html anhängt (z. B. /products/index.html), bevor die Anfrage an den Origin weitergeleitet wird. Dies löst das Problem, ohne den S3-Bucket öffentlich zu machen oder die Sicherheit zu beeinträchtigen. Das Ändern des Standard-Root-Objekts der CloudFront-Distribution in index.html funktioniert nur für die Root-URL (/), nicht für Unterverzeichnisse. Das Aktivieren von S3 Static Website Hosting erfordert, dass der Bucket öffentlich zugänglich ist, was der Anforderung widerspricht, den Bucket nicht öffentlich zu machen, und OAC umgeht. Eine benutzerdefinierte Fehlerantwort für 404 würde nur bei einem bereits aufgetretenen Fehler reagieren und nicht proaktiv die korrekte Datei bereitstellen.