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

Serverless requires least operational effort.

Suppose there are a 100 REST APIs (Since this application is monolithic, it's quite common). Are you still going to copy and paste all those API codes into lambda? What if business logic changes? This is not MINIMAL. I would go with C.

I believe the issues the company is experiencing are directly related to the use of the Route 53 Multi-Value Answer routing policy without a proper load balancer. This approach relies on DNS to distribute traffic, which can result in uneven load distribution across EC2 instances. Since clients may randomly select the first IP returned by DNS, some instances might get overwhelmed while others remain underutilized. In contrast, using an Application Load Balancer (ALB) alone but recomended with an Auto Scaling Group provides real-time traffic distribution, automatic health checks, and the ability to scale out based on demand. All with minimal operational overhead. For this use case, where the application is monolithic and the main concern is handling unpredictable traffic surges, Option D (ALB) is the most reliable and scalable solution.

Lambda's refactorings, especially Labmdas that update DNS or EKS Ingress "Envoy" provisioning add to operational complexities, D it is quite simple and easy

My preference would be to go for option D as an ALB is a more elegant solution, but without an ASG behind it, there would still be problems. C is less elegant, but has the advantage of an ASG, even if the R53 update mechanism is messy.

ALB + Private EC2 + Route 53 → ALB Perfect for immediate scaling needs, security, and minimal disruption. A is incorrect Requires completely re-architecting the monolithic API into functions — high development effort Not the least operational overhead initially (only pays off long term)

Right answer would be ALB+Autoscaling. Go with A because the question is asking least operation overheard not least effort.

Option A is not the answer because if the application is migrated to lambda then code refactoring is required which will require operational overhead, while option D the architecture remains the same but we evenly distribute the traffic by adding ALB then assigning the EC2s to a target group therefore the load will be evenly balanced. Route 53 gets updated pointing to the ALB

D. doesn’t have auto scaling. B. EKS will add operational overhead A. Adds lots of lambda functions whose maintenance and management will add to operational overhead compared to current monolithic setup. C. Is the best fit of the available options, it will enable autoscaling and will allow upto 8 nodes from current 5, one lambda function to update route53 will add minimal operational overhead. Though D with Autoscaling would have allowed minimal operational overhead and more flexibility to scale.

Less operational overhead. Much less development effort.

well... i have to say... none of the options here comply to least operational overhead... each and every option involves changing the application logic.. but foe the sake of it... A is the best answer.. It cannot be B as containerizing would not be suitable to use with IP addresses of the instances... ASG and ELB would not fit here as Route 53 records point to the static IP addresses of the instances.. so the best answer is A... But again... a lot of overhead invovled if someone goes on for implementation...

It can’t be A since we don’t know how much time the API needs to complete

While all 4 options work well and general inclination is to go for "serverless", the least operational effort is certainly add an ALB to distribute the incoming traffic on the EC2 instances. In a "real-world" scenario, I would ideally place Route53 -> ALB -> EC2 instances in an ASG. However, in the given option choices, D with ALB meets the requirement well from operational complexity point of view.

Serverless is the least operational effort

D provides a balanced solution to handle increased and varying traffic loads while minimizing the complexity and maintenance overhead.

Operational overhead to fix the scalabiltiy issue is minimal if we keep the EC2 instances as they are and use ASG. We know nothing about the code complexity or response time, it might be hours, so Lambda is nto an option IMHO. D is not an option because it doesn't include autoscaling, so it won't solve the issue.

This approach leverages AWS managed services like the Application Load Balancer (ALB) and Auto Scaling groups, minimizing the operational overhead required to handle varying traffic loads. The ALB automatically distributes incoming traffic across the EC2 instances, while the instances can be placed in private subnets for better security. Additionally, the Auto Scaling group can be configured to automatically scale the EC2 instances based on metrics like CPU utilization, eliminating the need for manual scaling. By using these managed services, you can offload tasks like load balancing, health checks, and auto-scaling to AWS, reducing the operational burden on your team. Updating the Route 53 record to point to the ALB's DNS name ensures that traffic is seamlessly routed to the backend instances without the need for manual DNS updates or additional components like Lambda functions.