While preparing for the AWS SAP-C02, many candidates get confused by serverless migration patterns, especially when multiple AWS services appear to solve the same problem. In the real world, this is fundamentally a decision about operational simplicity vs. architectural flexibility vs. total cost of ownership. Let’s drill into a simulated scenario.
The Scenario #
TechForge Solutions operates a Git repository infrastructure in their on-premises datacenter. Currently, repository events trigger webhooks that invoke AWS-hosted processing functions. The webhook receiver layer runs on Amazon EC2 instances managed by an Auto Scaling Group, fronted by an Application Load Balancer (ALB). The on-premises Git servers send POST requests to the ALB endpoint when code events occur (commits, merges, pull requests).
The engineering leadership wants to modernize this integration by eliminating EC2 management overhead and embracing a fully serverless architecture that reduces operational burden while maintaining reliability.
Key Requirements #
Migrate the webhook reception and processing layer to a serverless architecture that:
- Eliminates EC2 instance management
- Maintains webhook endpoint availability and scalability
- Minimizes operational complexity
- Optimizes for total cost of ownership
The Options #
- A) Create individual AWS Lambda Function URLs for each webhook type; update the Git server configuration to invoke each Lambda function’s unique HTTPS endpoint directly.
- B) Deploy an Amazon API Gateway HTTP API; implement each webhook’s business logic in separate AWS Lambda functions; configure the Git servers to POST events to the API Gateway endpoint with routing based on path or headers.
- C) Containerize the webhook logic and deploy to AWS App Runner; provision an Application Load Balancer with App Runner as the target; update Git server webhook URLs to point to the ALB DNS name.
- D) Containerize the webhook processing logic; create an Amazon ECS cluster running tasks on AWS Fargate; deploy an Amazon API Gateway REST API with VPC Link integration to the Fargate tasks; reconfigure Git webhooks to call the API Gateway endpoint.
Correct Answer #
Option B - Amazon API Gateway HTTP API with Lambda functions.
Step-by-Step Winning Logic #
This solution represents the optimal trade-off for professional-level serverless architecture migration:
-
Centralized Management: A single API Gateway endpoint provides one configuration point in the Git server, versus managing multiple Lambda URLs (Option A) or maintaining load balancers (Options C & D).
-
Serverless Execution: Lambda functions eliminate all compute management overhead, auto-scale to zero when idle, and scale massively during high-commit periods.
-
Cost Efficiency: HTTP API (not REST API) offers 71% lower pricing than REST APIs and charges only per-request ($1/million requests in us-east-1), with Lambda charging only for actual execution time.
-
Built-in Observability: API Gateway automatically integrates with CloudWatch for metrics, access logs, and execution logs without additional configuration.
-
Future Extensibility: The architecture easily supports adding authentication (Lambda authorizers), rate limiting, request transformation, or CORS without Git server changes.
-
True Serverless: Unlike Options C and D which introduce container orchestration overhead, this is a purely managed solution with zero infrastructure to maintain.
💎 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option A (Lambda Function URLs)?
- Configuration Sprawl: Each webhook type requires a separate URL configured in the Git server. With 10 webhook types, this means 10 separate endpoints to manage, update, and secure.
- No Centralized Control: Implementing authentication, rate limiting, or request validation requires duplicating logic across every Lambda function.
- Management Overhead: URL rotation, security updates, or architectural changes require touching every webhook configuration in Git.
- Cost Consideration: While Lambda Function URLs have no additional charge beyond Lambda execution, the operational cost of managing distributed endpoints exceeds the minimal API Gateway HTTP API fees.
Why not Option C (App Runner with ALB)?
- Not Fully Serverless: App Runner runs continuously (minimum 1 vCPU, 2GB memory even when idle), incurring baseline costs (~$30-50/month minimum).
- ALB Overhead: Reintroduces the very component the requirement seeks to eliminate (the ALB costs $16-22/month plus LCU charges).
- Architecture Regression: This maintains the old pattern (load balancer + compute) rather than modernizing to event-driven serverless.
- Complexity Without Benefit: Adds container management without solving the core requirement of eliminating operational overhead.
Why not Option D (ECS Fargate with API Gateway REST API)?
- Over-Engineering: This is the most complex and expensive option, introducing container orchestration, VPC networking, and REST API overhead.
- Cost Escalation: REST API costs
$3.50/million requests (vs. $1/million for HTTP API), plus Fargate task costs ($30-40/month minimum for continuous availability), plus potential NAT Gateway charges for VPC integration. - Operational Burden: Requires managing ECS task definitions, cluster configuration, container image updates, VPC Link setup, and security group rules.
- Wrong Tool: ECS Fargate is optimal for long-running containerized workloads, not event-driven webhook processing that completes in milliseconds.
The Architect Blueprint #
graph TD
A[On-Premises Git Server] -->|HTTPS POST| B[API Gateway HTTP API]
B -->|Route: /commit| C[Lambda: Commit Handler]
B -->|Route: /merge| D[Lambda: Merge Handler]
B -->|Route: /pr| E[Lambda: PR Handler]
C --> F[CloudWatch Logs]
D --> F
E --> F
C --> G[Downstream Processing]
D --> G
E --> G
style B fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style C fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style D fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style E fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
classDef gitStyle fill:#F05032,stroke:#fff,stroke-width:2px,color:#fff
class A gitStyle
Diagram Note: The architecture centralizes all webhook traffic through a single API Gateway HTTP API endpoint, which routes requests to dedicated Lambda functions based on path, eliminating the need for load balancers and EC2 instances while providing built-in observability and scalability.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost* | Pros | Cons |
|---|---|---|---|---|
| A) Lambda Function URLs | Low | $15-25 (Lambda execution only: ~1M invocations @ $0.20/M + compute) | Simple initial setup; no API Gateway costs; direct Lambda invocation | Configuration sprawl (N endpoints in Git); no centralized auth/logging; difficult to add cross-cutting features; management overhead scales with webhook count |
| B) API Gateway HTTP API + Lambda ✅ | Low-Medium | $20-35 (API Gateway HTTP: $1/M requests + Lambda execution: ~$15-25) | Single endpoint configuration; centralized routing/auth; built-in observability; true serverless; easy extensibility; optimal cost/benefit | Slightly higher cost than Function URLs ($1/M API calls); requires understanding API Gateway routing |
| C) App Runner + ALB | Medium | $65-90 (App Runner baseline: $30-50 + ALB: $16/mo + $0.008/LCU-hour) | Familiar container patterns; built-in CI/CD; simple container deployment | Not fully serverless (always-on costs); reintroduces ALB (the component being eliminated); higher baseline cost; defeats migration goal |
| D) ECS Fargate + API Gateway REST + VPC Link | High | $120-180 (Fargate tasks: $40-60 + REST API: $3.50/M + VPC Link: $0.01/hour ~$7/mo + NAT Gateway: $32-45) | Maximum flexibility; supports complex container workloads; enterprise networking | Massive over-engineering; 6-8x higher cost; container orchestration overhead; VPC complexity; REST API premium pricing; requires container expertise |
Cost Assumptions (us-east-1, moderate traffic scenario):
- 1 million webhook invocations/month
- Average Lambda execution: 200ms at 512MB memory
- App Runner: 1 vCPU, 2GB memory, continuous availability
- Fargate: 0.5 vCPU, 1GB memory tasks with 2 tasks for availability
- ALB: Low traffic (~0.5 LCU-hours/hour average)
Real-World Practitioner Insight #
Exam Rule #
For the SAP-C02, when you see “migrate to serverless architecture” combined with event-driven workloads (webhooks, API calls, scheduled tasks), the winning pattern is almost always:
- API Gateway (HTTP API for cost, REST API for features) for HTTP request handling
- Lambda for compute
- Avoid containers (ECS/Fargate) unless the scenario explicitly requires long-running processes, GPU workloads, or existing Docker investments
The exam tests whether you understand that “serverless” means managed services with zero infrastructure, not just “small containers.”
Real World #
In enterprise implementations, I would typically:
-
Start with Option B for 80% of webhook migration projects—it provides the right balance and grows with the organization.
-
Consider Lambda Function URLs (Option A) only for:
- POCs or single-webhook scenarios
- Internal tools where configuration sprawl isn’t a concern
- Extremely cost-sensitive projects with <100K monthly invocations where saving $1-2/month matters
-
Evaluate Option D (ECS Fargate) when:
- Webhook processing requires >15 minutes execution time (Lambda’s max)
- Complex dependency chains exist (multiple language runtimes, OS-level libraries)
- The team has zero Lambda experience but strong container expertise
- Regulatory requirements mandate specific container scanning tools
-
Add Authentication: In production, I’d implement:
- Git server: Configure webhook secret tokens
- API Gateway: Lambda authorizer to validate HMAC signatures
- Lambda functions: Verify signature before processing
-
Enhance Observability:
- Enable API Gateway access logging to S3
- Configure CloudWatch alarms for 5XX errors and high latency
- Implement AWS X-Ray tracing for end-to-end request visibility
- Create CloudWatch dashboards showing webhook volume by type
-
Cost Optimization:
- Right-size Lambda memory allocation based on CloudWatch Insights analysis
- Implement request throttling at API Gateway to prevent cost spikes from misconfigured Git webhooks
- Use Lambda reserved concurrency to cap maximum spend
The Hidden Complexity: The exam scenario doesn’t mention webhook authentication, but in reality, webhook signature validation is critical. With API Gateway + Lambda, you implement this once in a Lambda authorizer that all routes use. With Lambda Function URLs, you duplicate validation logic across every function.