Un'azienda esegue un'applicazione on-premises su un cluster Kubernetes. L'azienda ha recentemente aggiunto milioni di nuovi clienti. L'infrastruttura on-premises esistente dell'azienda non è in grado di gestire il gran numero di nuovi clienti. L'azienda deve migrare l'applicazione on-premises su AWS Cloud. L'azienda migrerà a un cluster Amazon Elastic Kubernetes Service (Amazon EKS). L'azienda non vuole gestire l'infrastruttura di calcolo sottostante per la nuova architettura su AWS. Quale soluzione soddisferà questi requisiti con il MINOR overhead operativo?

L'opzione corretta è utilizzare AWS Fargate perché soddisfa il requisito di non voler gestire l'infrastruttura di calcolo sottostante con il minimo overhead operativo. Fargate è un motore di calcolo serverless per i container che elimina la necessità di effettuare il provisioning, configurare e scalare i server. Un Fargate profile in EKS specifica quali pod devono essere eseguiti su Fargate. Le altre opzioni sono meno ideali: I nodi autogestiti richiedono la gestione completa dell'infrastruttura sottostante (EC2 instances), il che è contrario al requisito. I gruppi di nodi gestiti riducono parte dell'overhead operativo rispetto ai nodi autogestiti, ma richiedono comunque la gestione di alcune configurazioni delle istanze EC2 e la loro scalabilità. L'utilizzo di gruppi di nodi gestiti con Karpenter automatizza ulteriormente la gestione dei nodi, ma introduce la complessità della gestione di Karpenter stesso e non elimina completamente la necessità di considerare l'infrastruttura sottostante come fa Fargate.