Uno sviluppatore ospita un sito web statico in un bucket S3 servito tramite CloudFront utilizzando il controllo di accesso all'origine (OAC) in modo che il bucket non sia pubblico. Gli utenti possono accedere a URL di file espliciti (ad esempio, /products/index.html) ma ricevono un errore quando richiedono URL di directory (ad esempio, /products/). Senza rendere pubblico il bucket S3, come si possono servire le richieste di directory in modo che restituiscano il file indice predefinito?

La creazione di una funzione CloudFront viewer-request (CloudFront Functions o Lambda@Edge) è la soluzione più efficace e sicura. Questa funzione può intercettare le richieste in arrivo (es. /products/) e riscrivere l'URL aggiungendo automaticamente il nome del file indice (es. /products/index.html) prima che la richiesta raggiunga l'origine S3. Questo permette di servire il contenuto corretto senza esporre il bucket S3. Modificare l'oggetto root predefinito della distribuzione CloudFront in index.html non risolverebbe il problema, in quanto si applica solo alla root della distribuzione (/), non alle sottodirectory. Abilitare l'hosting di siti web statici S3 e modificare l'origine CloudFront all'endpoint del sito web S3 è una soluzione valida per servire i file indice, ma richiede di rendere il bucket accessibile pubblicamente tramite l'endpoint del sito web S3, compromettendo l'uso di OAC per la sicurezza. Configurare una risposta di errore personalizzata CloudFront per 404 Not Found che restituisca /index.html non è l'ideale, poiché si basa su un errore 404 per attivare la logica, il che è inefficiente e non semanticamente corretto per richieste valide.