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.

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.

Option Initial Effort Ongoing Overhead Scalability Cost Suitability for "Least Operational Overhead" A High Minimal Excellent (serverless) Cost-effective for low-to-medium traffic Poor (high re-architecture effort) B Very High High Excellent (with effort) Expensive Poor (requires Kubernetes expertise) C Moderate High Good (DNS-based scaling) Cheaper than ALB Moderate (Route 53 overhead) D Low Minimal Excellent (real-time ALB) Predictable Best

D Explanation: Benefits of an Application Load Balancer (ALB): Load Balancing: An ALB automatically distributes incoming traffic across multiple EC2 instances, ensuring high availability and efficient use of resources. Scalability: The ALB works seamlessly with an Auto Scaling group to scale the number of instances based on traffic load. Improved Security: Moving EC2 instances to private subnets ensures they are not directly exposed to the internet, reducing security risks. Operational Overhead: Minimal setup compared to other options. No need to manage DNS changes dynamically as the ALB provides a single, stable endpoint. Integration with Route 53: Route 53 can easily point to the ALB's DNS name, providing seamless updates to the clients. Handling Sudden Traffic Spikes: The ALB efficiently distributes traffic among available instances and works with Auto Scaling to dynamically adjust capacity to meet varying load demands.

D: ALB --> EC2 Not A cos This would require re-architecting the application from a monolithic design to a microservices or serverless architecture, which introduces additional complexity. Managing AWS Lambda functions and API Gateway would involve more operational overhead and may not be the most straightforward solution for handling increased load.

I don't think this question is correct! all the answers are illogical given that the solution is very straight forward! Nothing in the question suggest that anything out of the ordinary is needed or justified! I am guessing that the answer should have been option D with auto scaling... They can't seriously expect an architect to simply suggest to refactor the whole app as a solution!

For those of you considering D... If the "new and varying load" goes 100x of current, how without Auto Scaling Group can the "five Amazon EC2 instances" handle it?

its monolithic - cant be lambda