Lambda function URLs vs API Gateway for Git webhooks

SAP-C02 By islever Editorial Last updated

Determine a new architecture for existing workloads. Determine opportunities for modernization and enhancements.

Short answer

A Use a Lambda function URL for each webhook so the on-premises Git server calls Lambda directly, eliminating the ALB, Auto Scaling group, and EC2 instances with the fewest managed components.

Question

A company hosts a Git repository in an on-premises data center. The company uses webhooks to invoke functionality that runs in the AWS Cloud. The company hosts the webhook logic on a set of Amazon EC2 instances in an Auto Scaling group that the company set as a target for an Application Load Balancer (ALB). The Git server calls the ALB for the configured webhooks. The company wants to move the solution to a serverless architecture.
Which solution will meet these requirements with the LEAST operational overhead?
  1. For each webhook, create and configure an AWS Lambda function URL. Update the Git servers to call the individual Lambda function URLs. Correct Answer
  2. 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.
  3. Deploy the webhook logic to AWS App Runner. Create an ALB, and set App Runner as the target. Update the Git servers to call the ALB endpoint.
  4. Containerize the webhook logic. Create an Amazon Elastic Container Service (Amazon ECS) cluster, and run the webhook logic in AWS Fargate. Create an Amazon API Gateway REST API, and set Fargate as the target. Update the Git servers to call the API Gateway endpoint.

Key Takeaways

The exam tests whether you can recognize that Lambda function URLs are the lowest-overhead HTTPS endpoint for simple webhooks and that API Gateway is justified only by additional API-management requirements.

This SAP-C02 scenario asks for the least-operational-overhead serverless replacement for EC2/ALB-hosted Git webhooks. The answer is A: one Lambda function URL per webhook, because it removes the load balancer and avoids adding API Gateway when no routing, auth, or traffic-management features are required.

Common mistake: A common mistake is choosing B because API Gateway sounds like the canonical serverless front door; it adds an unnecessary API layer and routing configuration when the Git server can call each Lambda function URL directly.

Expert Analysis

Least-overhead endpoint choice. The question is not asking for the most feature-rich API tier; it asks for the smallest managed surface that still replaces the EC2 Auto Scaling group and ALB. Option A uses Lambda function URLs: each webhook gets a dedicated HTTPS endpoint backed by Lambda, so the on-premises Git server calls Lambda directly. There is no ALB, no Auto Scaling group, and no API Gateway route, stage, or integration layer to configure. The only moving parts are the Lambda functions and their URLs.

Why API Gateway is tempting but not required. Option B is the canonical serverless API pattern, and comments argue that it centralizes routing and avoids mapping individual Lambda URLs in Git. That is a real benefit when you need a single API front door, custom domains, throttling, API keys, or centralized authorization. This scenario contains none of those requirements. The Git server already calls a specific ALB for configured webhooks; replacing that with per-webhook Lambda function URLs is a direct substitution. AWS documentation specifically calls function URLs a good fit for simple webhooks that do not need advanced authorization or traffic management. Adding API Gateway would be extra configuration, not less.

What would flip the answer. If the company wanted one stable custom domain for all webhooks, request throttling, WAF, API-level auth, or centralized routing and observability across many webhook paths, option B would become stronger. Similarly, if the Git server could not be updated to call multiple function URLs, an API Gateway endpoint with path-based routes would reduce client-side changes. The operational consequence of choosing B without those needs is an extra API layer to deploy, monitor, and secure; choosing A without a plan for URL management can sprawl if webhook count grows, so use naming, tagging, and infrastructure as code.

Other options. Option C is not least overhead: App Runner plus an ALB reintroduces a load balancer and a persistent service. Option D adds ECS/Fargate task management and a REST API, which is more operational surface than Lambda and function URLs. The correct answer is A.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

For 'least operational overhead' questions, count the managed services and configuration surfaces the solution adds. If the requirement is a simple HTTPS callback with no need for custom domains, throttling, authentication, or centralized API routing, prefer the direct serverless endpoint such as a Lambda function URL over API Gateway. If the stem adds those API-management needs, API Gateway becomes the better answer.

Frequently Asked Questions

Why is API Gateway HTTP API not the least-overhead choice here?

API Gateway is serverless and valid, but it adds an API layer, routes, stages, and integrations to configure. The scenario has no custom-domain, throttling, authorization, or centralized-routing requirement, so Lambda function URLs meet the need with fewer managed components.

When would option B become the better answer?

Option B wins if the company needs a single API front door, request throttling, WAF, custom domain names, or API-level authorization. Those requirements justify API Gateway's extra configuration.

Are Lambda function URLs a fully serverless endpoint?

Yes. They are managed HTTPS endpoints for Lambda functions, so no EC2, Auto Scaling group, or ALB is required, and Lambda scales the backing function automatically.

More SAP-C02 FAQ →

Community Votes

B
62%
C
21%
A
17%

62% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 42 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 42

  1. masetromain 👍 26 Answered B
    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.
  2. masetromain 👍 8
    Option A would require updating the Git servers to call individual Lambda function URLs for each webhook, which would be more complex and time-consuming than calling a single API Gateway endpoint. Option C would require deploying the webhook logic to AWS App Runner, which would also be more complex and time-consuming than using an API Gateway. Option D would also require containerizing the webhook logic and creating an ECS cluster and Fargate, which would also add complexity and operational overhead compared to using an API Gateway.
  3. ninomfr64 👍 6 Answered A
    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?
  4. gofavad926 👍 5 Answered A
    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...
  5. SmileyCloud 👍 5 Answered B
    API GW and Lambda. Here is your architecture: https://aws.amazon.com/solutions/implementations/git-to-s3-using-webhooks/
Show 25 more comments
  1. RaghavendraPrakash 👍 4
    I go with C. With the options, we have Lambda and AppRunner. We dont know if that functionality can be repurposed with Lambda. However, the functionality can be deployed with AppRunner with least Operational Overhead.
  2. Malcnorth59 👍 4 Answered B
    A: large operational overhead B: Choice C: App runner doesn't use ALB D: Unnecessary complexity with containers
  3. emiliocb4 👍 3 Answered C
    to accomplish the least operational requiment i will go with C. B seems to be too much disruptive to implement "each logic" in a separate lambda
  4. AjayD123 👍 3 Answered B
    Api Gateway with Lambda https://medium.com/mindorks/building-webhook-is-easy-using-aws-lambda-and-api-gateway-56f5e5c3a596
  5. Untamables 👍 3 Answered B
    https://aws.amazon.com/solutions/implementations/git-to-s3-using-webhooks/
  6. dev112233xx 👍 3 Answered B
    B makes sense ✅
  7. moota 👍 2 Answered B
    Here's what ChatGPT has to say. In general, if you're looking for the option with the least operational overhead and you're comfortable with a fully managed, serverless environment, then AWS Lambda with API Gateway may be the better choice. However, if you require more control over your environment or need to use containers, then AWS App Runner with ALB may be the better option.
  8. hobokabobo 👍 2
    I do agree with B. However on Git server side it does make no difference if one calls aws or do a rest call via gateway. Eg. if you use Python it makes no difference if you use boto(call Lambda) or request(rest api) module. If one implemets via shell it makes no difference if one uses aws-cli(invoke Lambda directly) or curl(do a rest call). Similar for other implementations.
  9. hobokabobo 👍 2
    As addition why B is still better: it hides the implementation details and decouples by introducing a interface. With that a team for Aws may change what ever it needs to change to implement the interface. On the other hand on git side can use whatever deems necessary without caring about implementation details.
  10. Malcnorth59 👍 2
    Option A requires that you update the webhooks for each lambda function. This will create a considerable operational overhead not just for the initial change but going forward as well. API Gateway (B) decouple the functions from the Webhooks.
  11. jpa8300 👍 2
    ninomfr64 says that App runner cannot be a target for ALB, so that's the reason you cannot select C.
  12. Fu7ed 👍 2
    https://aws.amazon.com/ko/solutions/implementations/git-to-s3-using-webhooks/
  13. uas99 👍 2
    A. is the right answer as no need to introduce gateway here
  14. stantx 👍 1 Answered A
    Answer: A — Create a Lambda function URL for each webhook. Each function URL provides an HTTPS endpoint that the on-premises Git server can call directly. This removes the EC2 instances, Auto Scaling group, and ALB without introducing another API service to configure. AWS explicitly states: “Function URLs are a good choice for simple webhooks that don't require features like advanced authorization or request validation.” Source: AWS tutorial on webhook endpoints using Lambda function URLs (https://docs.aws.amazon.com/lambda/latest/dg/urls-webhook-tutorial.html) Why the other choices lose: - B: API Gateway plus Lambda would work, but adds API routes and integrations to configure. The question specifies no requirement that needs API Gateway’s additional features. - C: Introduces container hosting and an additional ALB, adding configuration and management. - D: Requires containerization, ECS/Fargate configuration, and API Gateway integration—more operational overhead. The deciding phrase is “LEAST operational overhead.” For the simple webhook requirements given, direct Lambda function URLs meet that criterion.
  15. bjexamprep 👍 1 Answered B
    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.
  16. master9 👍 1 Answered C
    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
  17. Sarutobi 👍 1
    Interesting that there is no more debate here about option A. I still think B is the way to go because AWS recommends integrating with GitLab with https://aws-quickstart.github.io/quickstart-git2s3/ and that is what we use. But if option A works, it would be the "LEAST operational overhead." I think masetromain talked about it, but I see it differently, basically, it can be a single Lambda function that reads the payload of the webhook to continue the pipeline, basically the same idea but without API-GW in front.
  18. bgc1 👍 1 Answered B
    AWS App Runner is designed for containerized web applications and APIs that need a persistent, stable runtime environment with consistent performance and minimal operational overhead. APGateway + Lambdas are better for event driven use cases like these. Hence option B is better than C. Also AppRunner cannot work with ALB. Options A and D have ongoing operational overhead.
  19. sam_cao 👍 1 Answered C
    The comments below supported Option B are only focusing on how Lambda + API Gateway can help reduce operational overhead. Thinking of the scenario in the question that we have already had the source code, wouldn't it be easier if we only specify the code repo on App Runner and let it process and finish the task? Implement all logic again would consume a lot more time.
  20. kz407 👍 1 Answered B
    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.
  21. glf 👍 1 Answered A
    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.
  22. Chris_W_1234 👍 1
    I don't buy answer B. Changing the webhooks once is not operational overhead. It is development effort. Once the webhooks have been updated to point to the respective function URLs, they never need to be touched again.
  23. subbupro 👍 1
    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
  24. subbupro 👍 1
    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
  25. GabrielShiao 👍 1 Answered C
    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.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Cost-Effective Image Processing with SQS and S3 Lifecycle Policies

S-grade

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide