Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 143 discussion

I think the answer here is "D" because usually when you see terms like "monolithic" the answer will likely refer to microservices.

D is organic pattern, lift and shift, decompose to containers, first making most use of existing code, whilst new features can be added over time with lambda+api gw later. A is leapfrog pattern. requiring refactoring all code up front.

Monolith to Smaller Apps (Microservices-Ready) ECS (or EKS) is ideal when breaking a monolithic app into smaller services (aka microservices). Different teams can manage individual containers running different parts of the app.

D because the operational overhead is the smallest among the given options. The company may do all that breaking up of functionalities and let teams manage the parts, but operationally for the site, hosting in Containers is the lowest maintenance. No ASG tuning, no ALB limitations and so on.

The company wants to keep as much of the front-end code and the backend code as possible, so containization is less code changes than B which uses lambda.

Auto scaling group meets highly scalable requirement. D is not right 1. it is unknown if the app can be containerized , 2. and it maintains EC2 as C, so D has no operational advantage. Microservice is not equivalent to container.

Ans D - hint: "...break the application into smaller applications"

Ans D - hint: "The company wants to keep as much of the front-end code and the backend code as possible. However, the company wants to break the application into smaller applications." Containerisation will help the company achieve a scaleable, more manageable solution.

For the folks suggesting Amplify: Have any of you actually shipped anything on Amplify? There are tons of adaptations needed to port a monolith to Amplify, specially around the backend that will need severe refactor. Answer D allows for decomposing the application into different containers, enabling a distributed monolith.

Amazon API Gateway and Amplify both server less. Also you can import your code from GitHub in the amplify.

The company wants to keep much of its existing code. So the preferable solution is ECS. However the option D does not mention AWS Fargate which would cover the 'least operational overhead ' part.

Different teams working means " microservices based architecture" so basically decoupling the application ..u can achieve this only by containerizing the app so answer is D

B allows for a serverless architecture using AWS Lambda functions, which are highly scalable and require minimal operational overhead. AWS Amplify can help in managing the front-end code, while Amazon API Gateway integrated with AWS Lambda can handle the backend services. D imo is not the best option in this scenario. While ECS can be a good choice for containerized workloads, it might introduce more operational overhead compared to a serverless solution like AWS Lambda and AWS Amplify.

I have a problem with this question. "The company wants to keep as much of the front-end code and the backend code as possible" So containerization is the solution here (D)? ABC don't make much sense so I will go with D but using containers for FE/BE code and configuring ALB for ECS (hopefully for frontend containers) is a pain in practice. Maybe this is worded in a bad way.

Original state: monolithic with FE and BE code Wanted state: seperate to mutilple components for diff. teams as Microservices B is correct to decouple monolithic to microservices. D still keep monolithic application in ECS.

IT is B. AWS amplify. AWS Amplify will help seperate FE and BE. I agree with MM_Korvinus answer.

https://aws.amazon.com/tutorials/break-monolith-app-microservices-ecs-docker-ec2/module-three/ This page explained clearly why D is the correct answer