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

B. Create an Amazon API Gateway HTTP API. Implement each webhook logic in a separate AWS Lambda function. Update the Git servers to call the API Gateway endpoint. This solution will provide low operational overhead as it utilizes the serverless capabilities of AWS Lambda and API Gateway, which automatically scales and manages the underlying infrastructure and resources. It also allows for the webhook logic to be easily managed and updated through the API Gateway interface. The answer should be B because it is the best solution in terms of operational overhead.

I need help here: what's wrong with Lambda Function URL? With A I just need to handle my Lambda functions, updates go trough updating my aliases pointing to a new version. Here I am just missing all the capabilities provided by API Gateway that seems not to be requested (transformations, throttling, quotas, cache, api keys, auth, OpenAPI, ...). With B I still need to implement each webhook logic in a separate AWS Lambda function and update git server + I need to operates API Gateway. Any other option requires 2 or more services thus generating more operations, also: Not C as app runner is not a target for ALB (private IP, ECS, EC2 instance, Lambda) Not D as you cannot set Fargate as API Gateway target (while you can use ECS as target) Can you help me understand why B requires less operations overhead?

B is plain wrong. With an HTTP API Gateway you're publishing your API on the Internet, which could be forbidden by security policy. Even if it is not, you at least need to setup authentication, with OAuth2 or custom Lambda authorizer. And in this case, you lose the advantage in terms of operational overhead.

Deploy the web hook logic to the Apprunner which takes a minor effort to build and deploy the container image automatically without underlying infrastructure management.

B. Create an Amazon API Gateway HTTP API. Implement each webhook logic in a separate AWS Lambda function. Update the Git servers to call the API Gateway endpoint.

C is the best one . Operational over head - exisiting web logic needs to be change into the lambda. But in C - just we can use the same logic just deployment activities. Please go with C

A: large operational overhead B: Choice C: App runner doesn't use ALB D: Unnecessary complexity with containers

https://aws.amazon.com/ko/solutions/implementations/git-to-s3-using-webhooks/

Given the current answers, I think B is the only possible option with least overhead. C would have been a better candidate over B, if it mentioned to include the App Runner in a Target Group TG and assign TG as the target for the API Gateway. As it stands now, C is not correct because App Runner app can't be directly assigned as a target for API Gateway.

A, because is the solution with less operational overhead. Also option B also will create new lambda functions per webhook, and you have to define the specific path in the apigateway and integrate it with your specific lambda...

Lambda function is the easiest way to implement the webhook logic. App Runner and ECS all requires more ops overhead. So the answer is between A and B. Someone argue that using A introduces ops overhead of mapping every Lambda function to the webhooks, but actually with B, users don’t need to map Lambda function in git webhooks, but move the Lambda function mapping ops to API gateway. The mapping need to be done, that’s an ops overhead that cannot be ignored. I’m guessing the question designer prefers to use API GW, because the description “Update the Git servers to call the individual Lambda function URLs.” doesn’t look good. While, in reality, the repo developers create the Lambda function, and they know the URL, it’s very easy to launch the Lambda function from the web hook. No additional API GW is required.

You can set App Runner as a target for ALB. AWS App Runner can use your code. You can use AWS App Runner to create and manage services based on two fundamentally different service sources: source code and source image. App Runner starts, runs, scales, and balances your service regardless of the source type. You can use the CI/CD capability of App Runner to track changes to your source image or code. When App Runner discovers a change, it automatically builds (for source code) and deploys the new version to your App Runner service

A. is the right answer as no need to introduce gateway here

Least operations is the key. App runner is a aws managed one and can deploy it easily, A and B we need to create lamda for each web hook it is very complex . So C would be correct

Don't see the exact reasons to not choose A for now, but B will work for sure.

reducing operational overhead!

B vs C. Looking at App Runner C makes more sense.