Aggiornamento: la risposta di seguito è stata accurata quando è stata scritta nel 2015 ed è corretta in base al comportamento integrato di CloudFront stesso.
Tuttavia, l'introduzione di [email protected] nel 2017 modifica la dinamica.
Lambda @ Edge consente di dichiarare i ganci trigger nel flusso CloudFront e di scrivere piccole funzioni Javascript che ispezionano e possono modificare la richiesta in arrivo, prima che la cache CloudFront sia selezionata (richiesta visualizzatore) o dopo che la cache è stata selezionata (richiesta di origine). Ciò ti consente di riscrivere il percorso nell'URI della richiesta. Ad esempio, è possibile trasformare un percorso di richiesta dal browser di /download/images/cat.png per rimuovere /download, in modo che una richiesta venga inviata a S3 (o un orgin personalizzato) per /images/cat.png.
Questa opzione non modifica quale comportamento della cache effettivamente servirà la richiesta, poiché si basa sempre sul percorso richiesto dal browser, ma è possibile modificare il percorso in-flight in modo che l'oggetto richiesto sia effettivamente su un percorso diverso da quello richiesto dal browser.
Per aggiungere semplicemente un prefisso alla richiesta dal browser, è comunque possibile utilizzare l'impostazione Percorso di origine, come indicato di seguito, ma per rimuovere o modificare i componenti del percorso è necessario Lambda @ Edge.
Sì, i motivi devono esistere all'origine.
CloudFront, nativamente. può anteporre al percorso per una data origine, ma attualmente non ha la capacità di rimuovere elementi del percorso (senza Lambda @ Edge, come indicato sopra).
Se i file si trovavano nello stato /secret/files/ all'origine, è possibile trasformare il percorso del percorso /files/* prima di inviare la richiesta all'origine impostando il "percorso di origine".
L'opposto non è vero. Se i file erano nell'origine /files, non esiste un modo incorporato per servire quei file dal modello di percorso /download/files/*.
È possibile aggiungere (prefisso) ma non portare via.
Una soluzione relativamente semplice sarebbe un server proxy inverso su un'istanza EC2 nella stessa area del bucket S3, che punta CloudFront al proxy e il proxy a S3.Il proxy dovrebbe riscrivere la richiesta HTTP sulla sua strada verso S3 e trasmettere la risposta risultante a CloudFront. Uso un setup come questo e non mi ha mai deluso con le sue prestazioni. (Il software proxy inverso che ho sviluppato può effettivamente controllare più bucket in parallelo o in serie e restituire la prima risposta di non errore ricevuta a CloudFront e al richiedente).
Oppure, se si utilizzano gli endpoint del sito Web S3 come origini personalizzate, è possibile utilizzare le regole di reindirizzamento S3 per restituire un reindirizzamento a CloudFront, rimandando il browser con il prefisso non gestito rimosso. Ciò significherebbe una richiesta aggiuntiva per ciascun oggetto, aumentando la latenza e alquanto il costo, ma le regole di reindirizzamento S3 possono essere impostate per attivarsi solo quando la richiesta non corrisponde effettivamente a un file nel bucket. Questo è utile per la transizione da una struttura gerarchica a un'altra.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html
http://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html