Which solution will meet these requirements with the LEAST ongoing operational overhead?
Run the application on Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. Use Amazon Elastic File System (Amazon EFS) for data that is frequently accessed between the web and application tiers. Store the frontend web server session data in Amazon Simple Queue Service (Amazon SQS).
Run the application on Amazon Elastic Container Service (Amazon ECS) on Amazon EC2. Use Amazon ElastiCache for Redis to cache frontend web server session data. Use Amazon Elastic Block Store (Amazon EBS) with Multi-Attach on EC2 instances that are distributed across multiple Availability Zones.
Run the application on Amazon Elastic Kubernetes Service (Amazon EKS). Configure Amazon EKS to use managed node groups. Use ReplicaSets to run the web servers and applications. Create an Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system across all EKS pods to store frontend web server session data.
Deploy the application on Amazon Elastic Kubernetes Service (Amazon EKS). Configure Amazon EKS to use managed node groups. Run the web servers and application as Kubernetes deployments in the EKS cluster. Store the frontend web server session data in an Amazon DynamoDB table. Create an Amazon Elastic File System (Amazon EFS) volume that all applications will mount at the time of deployment.
Explanations:
While ECS on Fargate simplifies management, using SQS for session data is not suitable, as SQS is a messaging service, not a storage solution for session persistence. EFS is a good choice for shared data but does not address session persistence needs adequately.
Running ECS on EC2 with EBS Multi-Attach allows for some fault tolerance, but using ElastiCache for session management is better suited for session data than EBS. However, managing EC2 instances increases operational overhead compared to a serverless option like Fargate.
Although EKS with managed node groups provides scalability and fault tolerance, using EFS for session data does not effectively manage session persistence since EFS is not optimized for session management, which typically requires a caching layer.
EKS with managed node groups allows for automatic scaling and fault tolerance. Using DynamoDB for session data ensures high availability and low latency. EFS can be used for shared data across applications, optimizing both storage and operational overhead.
I judge that the answer is:
Deploy the application on Amazon Elastic Kubernetes Service (Amazon EKS). Configure Amazon EKS to use managed node groups. Run the web servers and application as Kubernetes deployments in the EKS cluster. Store the frontend web server session data in an Amazon DynamoDB table. Create an Amazon Elastic File System (Amazon EFS) volume that all applications will mount at the time of deployment.