Een bedrijf heeft zijn webapplicatie gemigreerd naar AWS. De applicatie draait momenteel meerdere processen op één EC2-instance: een Apache-webserver die statische content serveert, een PHP-applicatie en een lokale Redis-server die wordt gebruikt voor sessies. Het bedrijf wil een zeer beschikbare redesign die gebruikmaakt van AWS managed services. Welke oplossing voldoet aan deze vereisten?

De correcte optie voldoet aan de vereisten voor hoge beschikbaarheid en het gebruik van beheerde AWS-services. Amazon S3 met CloudFront is ideaal voor statische content, wat schaalbaar en wereldwijd beschikbaar is. ECS met Fargate en een Application Load Balancer biedt een schaalbare en beheerde omgeving voor de PHP-applicatie, zonder serverbeheer. ElastiCache for Redis met Multi-AZ zorgt voor een zeer beschikbare en beheerde sessieopslag. De eerste optie is onjuist omdat Elastic Beanstalk weliswaar beheerd is, maar het plaatsen van de EC2-instance in een publiek subnet met een publiek IP-adres en het ontbreken van een aparte, schaalbare sessieoplossing de hoge beschikbaarheid en beveiliging beperkt. De tweede optie is onjuist omdat Lambda niet geschikt is voor het hosten van statische content en een PHP-applicatie die waarschijnlijk een langere runtime en meer geheugen vereist dan Lambda efficiënt kan bieden. Hoewel ElastiCache for Redis wordt gebruikt, is de architectuur voor de applicatie zelf niet optimaal. De derde optie is onjuist omdat het de backend-code op een enkele EC2-instance laat, wat een single point of failure creëert en niet voldoet aan de eis van een zeer beschikbare redesign met beheerde services voor de applicatielaag.