Een CloudFront-distributie gebruikt een Origin Access Identity (OAI) om toegang te krijgen tot een private S3-bucket. De bucket weigert toegang aan alle anderen. De app vereist dat gebruikers een openbare inlogpagina bekijken en vervolgens signed cookies ontvangen om toegang te krijgen tot private directories. De distributie gebruikt het standaard cachegedrag met beperkte viewer-toegang gericht op de S3-origin. Toegang tot de inlogpagina resulteert in een 403 Forbidden. Hoe kan de ontwikkelaar niet-geauthenticeerde toegang tot de inlogpagina toestaan, terwijl private content veilig blijft?

De juiste oplossing is om een tweede cachegedrag toe te voegen met een padpatroon dat specifiek overeenkomt met de inlogpagina (bijv. /login.html) en de viewer-toegang voor dit specifieke gedrag in te stellen op 'onbeperkt'. CloudFront verwerkt cachegedragingen in de volgorde waarin ze zijn gedefinieerd, van meest specifiek naar minst specifiek. Door een specifiek gedrag voor de inlogpagina te creëren met onbeperkte toegang, zal CloudFront dit gedrag toepassen voordat het standaardgedrag wordt bereikt, waardoor niet-geauthenticeerde gebruikers de inlogpagina kunnen zien. Het standaard cachegedrag, dat beperkte toegang heeft, blijft van kracht voor alle andere (private) content, waardoor de beveiliging behouden blijft. De andere opties zijn incorrect omdat: Het wijzigen van het standaardgedrag of het toevoegen van een catch-all patroon met onbeperkte toegang zou de beveiliging van de private content compromitteren. Failover-origins zijn bedoeld voor beschikbaarheid, niet voor toegangscontrole op basis van padpatronen. Het toevoegen van een bucket policy voor openbare toegang en een CloudFront Function om door te verwijzen, is complexer en minder efficiënt dan het gebruik van CloudFront's ingebouwde cachegedragregels voor toegangscontrole.