Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 7 discussion

B. Upload the container images to Amazon Elastic Container Registry (Amazon ECR). Configure two auto scaled Amazon Elastic Container Service (Amazon ECS) clusters with the Fargate launch type to handle the expected load. Deploy tasks from the ECR images. Configure two separate Application Load Balancers to direct traffic to the ECS clusters. This option meets the requirement of using a serverless architecture by utilizing the Fargate launch type for the ECS clusters, which allows for automatic scaling of the containers based on the expected load. It also allows for separate deployments for production and testing by configuring separate ECS clusters and Application Load Balancers for each environment. This option also minimizes operational complexity by utilizing ECS and Fargate for the container orchestration and scaling.

Answer is A. ABC all works but A is most COST EFFECTIVE

I think it's A, you can upload docker images to lambda, and it's serverless. I don't think ECS can count as serverless in this case.

looks like now since 2020 lambda support container images https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/?utm_source=chatgpt.com

https://docs.aws.amazon.com/lambda/latest/dg/images-create.html

most cost-effective and lest operational overhead

I was initially torn between A and B, but answer A says to upload the container image to Lambda, which isn't possible - to use a container with Lambda, you still upload the image to ECR. Answer D (Beanstalk) isn't the most cost-effective for running containers. So between B and C (ECS vs EKS), ECS has less operational overhead, and also doesn't require the master node to be running, which means ECS will likely be very slightly cheaper, and have less operational work.

At the time I consider B & C without doubt. But finally consider to migration efforts, I choose B. I don't really consider the cost between B & C.

AWS Fargate launch type for Amazon ECS is indeed a pay-per-use model. With Fargate, you pay for the amount of vCPU and memory resources that your containerized application requests. The billing is based on the resources used from the time your container images are pulled until the Amazon ECS task terminates, rounded up to the nearest second, with a minimum charge of one minute12. This model allows you to focus on building and managing your applications without worrying about managing the underlying infrastructure, making it a convenient and scalable option for many use cases. See: https://aws.amazon.com/ecs/pricing/

"microservices that run on containers, with a serverless architecture that minimizes operational complexity and costs" = Amazon Elastic Container Service (Amazon ECS)

Serverless and Most Cost-Effective Solutions - B

Choosing A, Fargate had a minimum charge per minute. Lambda is per invocation. So lambda Is probably cheaper in THIS case

Option B is the most cost-effective solution for the following reasons: The use of Fargate, a serverless compute engine for containers, eliminates the need for managing and scaling the underlying infrastructure. This minimizes operational complexity and reduces costs as the resources are used only when required. Auto scaling ensures that the application scales up and down based on the load, providing the required performance and availability without incurring additional costs. Amazon ECS is a simpler and more cost-effective solution than Amazon EKS, which requires more management and additional resources to operate the Kubernetes control plane. Using Application Load Balancers to direct traffic to the ECS clusters ensures high availability and fault tolerance.

Explanation: Amazon ECS with Fargate: By uploading the container images to Amazon ECR and using Amazon ECS with the Fargate launch type, you can run the microservices in containers without having to manage the underlying infrastructure. Fargate automatically scales the containers based on the load. Separate Production and Testing Environments: With two separate auto-scaled Amazon ECS clusters, you can have dedicated environments for production and testing, ensuring isolation and allowing for separate deployments and configurations. Application Load Balancers (ALB): Configuring two separate ALBs allows you to direct traffic to the appropriate ECS clusters. This ensures proper routing of requests between the production and testing environments. Option B provides a cost-effective solution by utilizing the serverless nature of Fargate, which eliminates the need to provision and manage EC2 instances explicitly. It also allows for separate environments, easy scalability, and traffic routing using ALBs, providing flexibility and minimizing operational complexity.

Option A - This option might not work. AWS Lambda provides a cheap option to run containers however nothing is said about execution times could be a concern, i.e. AWS Lambda only provides 15 minutes of execution time Option B - This option will work. ALB, ECR, ECS and Fargate in combination will deliver a running solution. Option C - This option will work. ALB, ECR, EKS and Fargate will deliver a running solution. Option D - This option will work: Beanstalk will rely on ECS to run the containers. See https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker_ecs.html Cheapest option is B.

B. Upload the container images to Amazon Elastic Container Registry (Amazon ECR). Configure two auto scaled Amazon Elastic Container Service (Amazon ECS) clusters with the Fargate launch type to handle the expected load. Deploy tasks from the ECR images. Configure two separate Application Load Balancers to direct traffic to the ECS clusters.

A because ALB & Beanstalk are not serverless & Lambda added support to use docker images directly. you can upload container images to AWS Lambda and use them as functions. AWS Lambda introduced support for deploying functions as container images, allowing you to package and deploy Lambda functions with custom runtimes, libraries, and dependencies that might exceed the limitations of traditional Lambda deployment packages (zip files).