Een applicatie die is geïmplementeerd op AWS Elastic Beanstalk gebruikt Amazon Aurora en wordt benaderd via een CloudFront-distributie die het Elastic Beanstalk-domein als oorsprong gebruikt. CloudFront is geconfigureerd met een alternatieve domeinnaam die gebruikers benaderen. Elke week wordt de applicatie offline gehaald voor onderhoud; gedurende die tijd wil het bedrijf dat bezoekers een informatiepagina zien (geen CloudFront-fout). De eerste stap – het aanmaken van een S3-bucket – is al voltooid. Welke drie acties moet de solutions architect vervolgens ondernemen om dit gedrag te implementeren?

De eerste stap is het uploaden van de statische onderhoudspagina naar de S3-bucket, zodat deze beschikbaar is. Vervolgens moet de bestaande CloudFront-distributie worden geconfigureerd met de S3-bucket als een tweede oorsprong. Dit maakt het mogelijk om te schakelen tussen de Elastic Beanstalk-applicatie en de onderhoudspagina. Het gebruik van een Origin Access Identity (OAI) zorgt ervoor dat CloudFront toegang heeft tot de S3-bucket, terwijl directe openbare toegang wordt voorkomen. Ten slotte moet tijdens het onderhoud het standaard cachegedrag van de CloudFront-distributie tijdelijk worden gewijzigd om naar de S3-oorsprong te verwijzen, en na het onderhoud weer teruggezet worden naar de Elastic Beanstalk-oorsprong. De optie om een gloednieuwe CloudFront-distributie aan te maken is onnodig en complex, aangezien de bestaande distributie al de alternatieve domeinnaam gebruikt. Het toevoegen van een cachegedrag voor de S3-oorsprong op een nieuwe distributie is irrelevant, en de prioriteit van 0 zou niet het gewenste effect hebben op de bestaande distributie. Elastic Beanstalk kan geen verkeer rechtstreeks vanuit een S3-bucket leveren; dit is de taak van CloudFront.