Un'azienda esegue un'applicazione web a tre livelli on-premises: frontend Apache, middle-tier Java monolitico e storage PostgreSQL. Una recente promozione ha sovraccaricato tutti i livelli, l'applicazione è andata in crash e il database ha raggiunto i limiti di capacità di lettura. Sono previste diverse promozioni. È necessario progettare una migrazione ad AWS che massimizzi la scalabilità e minimizzi lo sforzo operativo. Quali tre passaggi realizzano questo obiettivo? (Scegliere tre.)

Rifattorizzare il frontend con S3 e CloudFront massimizza la scalabilità e riduce il carico sui server applicativi, servendo gli asset statici in modo efficiente e globale. Il rehosting dell'applicazione Java su Elastic Beanstalk con auto scaling abilitato minimizza lo sforzo operativo fornendo un ambiente gestito e scalabile automaticamente, affrontando i picchi di traffico. Migrare PostgreSQL ad Amazon Aurora PostgreSQL con AWS DMS e utilizzare Aurora Auto Scaling per le repliche di lettura risolve i limiti di capacità di lettura e garantisce scalabilità e alta disponibilità del database con uno sforzo operativo ridotto. Le opzioni errate sono: Il rehosting del frontend Apache su istanze EC2 con EFS per gli asset statici non massimizza la scalabilità e non riduce lo sforzo operativo come S3/CloudFront. EFS non è l'opzione più efficiente per la distribuzione di asset statici globali. Rifattorizzare l'applicazione Java in un container Docker ed eseguirla su AWS Fargate è una buona opzione per la scalabilità, ma richiede uno sforzo di refactoring maggiore rispetto al rehosting con Elastic Beanstalk, che è più allineato con la minimizzazione dello sforzo operativo per un'applicazione monolitica esistente. Il rehosting del database PostgreSQL su un'istanza EC2 non risolve i problemi di scalabilità di lettura e aumenta lo sforzo operativo per la gestione del database rispetto ad Aurora.