While preparing for the AWS SAP-C02, many candidates get confused by API Gateway integration patterns. In the real world, this is fundamentally a decision about Operational Complexity vs. Cost Efficiency vs. Flexibility. Let’s drill into a simulated scenario.
The Scenario #
GlobalRetail Analytics operates a product recommendation engine that stores user preference matrices across multiple Amazon DynamoDB tables. The data science team needs to expose this data to external partner applications through a public HTTPS API. The Chief Architect has mandated a fully serverless solution that automatically scales with demand without manual intervention. Security requires standard HTTPS authentication, and the finance team has flagged API infrastructure costs as a quarterly review metric.
Key Requirements #
Design a serverless solution that:
- Exposes DynamoDB table data via public HTTPS API
- Requires zero server management or capacity planning
- Scales automatically with request volume
- Minimizes operational overhead
The Options #
Select TWO:
- A) Deploy Amazon API Gateway REST API with AWS service integration type configured for direct DynamoDB access
- B) Deploy Amazon API Gateway HTTP API with AWS service integration type configured for direct DynamoDB access
- C) Deploy Amazon API Gateway HTTP API integrated with AWS Lambda functions that query DynamoDB tables
- D) Create AWS Global Accelerator endpoint integrated with Lambda@Edge functions that return DynamoDB data
- E) Deploy Network Load Balancer with listener rules forwarding requests to AWS Lambda functions
Correct Answer #
Options A and C.
Step-by-Step Winning Logic #
Option A (REST API + Direct Integration):
- REST API supports AWS service integration with VTL (Velocity Template Language) mapping templates
- Enables direct DynamoDB operations (GetItem, PutItem, Query, Scan) without Lambda compute costs
- Provides built-in request/response transformation for simple CRUD patterns
- Ideal for straightforward data access without complex business logic
Option C (HTTP API + Lambda):
- HTTP API offers 70% lower cost than REST API ($1.00 vs $3.50 per million requests)
- Lambda provides unlimited flexibility for complex queries, multi-table joins, and data transformation
- Easier to implement authorization logic and data filtering in familiar programming languages
- Better testability and local development experience compared to VTL templates
The Strategic Combination: These two options represent complementary patterns鈥攗se direct integration for simple operations and Lambda for complex logic, both leveraging serverless auto-scaling.
馃拵 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option B?
- HTTP API does NOT support AWS service integration type (as of 2025)
- HTTP API only supports Lambda and HTTP endpoint integrations
- This is a critical exam trap testing your knowledge of API Gateway feature parity differences
Why not Option D?
- Global Accelerator is a network layer service for improving global availability and performance
- Lambda@Edge runs at CloudFront edge locations, not as a standalone API endpoint
- Requires CloudFront distribution (not mentioned in requirements)
- Massive over-engineering for simple DynamoDB exposure
- 3-5x cost premium with no stated latency requirements
Why not Option E?
- Network Load Balancer operates at Layer 4 (TCP/UDP)
- Does not natively understand HTTPS application layer routing
- Requires EC2 targets or IP targets鈥擫ambda integration requires Application Load Balancer
- Violates serverless requirement (NLB charges hourly + LCU costs regardless of traffic)
The Architect Blueprint #
graph TB
subgraph "Pattern 1: Direct Integration"
Client1[External Partner Apps] -->|HTTPS| APIGW1[API Gateway REST API]
APIGW1 -->|AWS Service Integration| DDB1[(DynamoDB Tables)]
APIGW1 -.->|VTL Mapping| Transform1[Request/Response Transform]
end
subgraph "Pattern 2: Lambda Integration"
Client2[External Partner Apps] -->|HTTPS| APIGW2[API Gateway HTTP API]
APIGW2 -->|Proxy Integration| Lambda[Lambda Functions]
Lambda -->|AWS SDK| DDB2[(DynamoDB Tables)]
Lambda -.->|Business Logic| Enrich[Data Enrichment/Filtering]
end
style APIGW1 fill:#FF9900,stroke:#232F3E,color:#fff
style APIGW2 fill:#FF9900,stroke:#232F3E,color:#fff
style Lambda fill:#FF9900,stroke:#232F3E,color:#fff
style DDB1 fill:#4053D6,stroke:#232F3E,color:#fff
style DDB2 fill:#4053D6,stroke:#232F3E,color:#fff
Diagram Note: The architecture shows two serverless patterns鈥攄irect integration for simple CRUD operations via REST API, and HTTP API with Lambda for complex transformations, both auto-scaling based on demand.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost (10M requests, 1KB payload) | Pros | Cons |
|---|---|---|---|---|
| A: REST + Direct Integration | Medium (VTL learning curve) | $35 ($35 API Gateway) | Zero compute cost; lowest latency (no Lambda cold start); simple CRUD operations | Limited to DynamoDB operations; VTL template debugging difficulty; no custom business logic |
| B: HTTP + Direct Integration | N/A | Not Supported | Would be ideal cost-wise if supported | Feature does not exist in HTTP API |
| C: HTTP + Lambda | Low (familiar code) | $30 ($10 HTTP API + $20 Lambda @ 200ms avg) | Full programming flexibility; easy testing; complex query support | Lambda cold starts (50-200ms); compute costs scale with execution time |
| D: Global Accelerator + Lambda@Edge | Very High | $2,850+ ($200 GA + $650 data transfer + $2,000 Lambda@Edge) | Global latency optimization | Requires CloudFront; 10x cost premium; operational complexity; not designed for origin API |
| E: NLB + Lambda | High | $850+ ($18 NLB + $32 LCU + $800 ALB required for Lambda) | Layer 4 performance | Requires ALB intermediary; fixed hourly costs; violates serverless principle |
FinOps Insight: For typical API workloads, the cost difference between Options A and C is marginal (~$5/month at 10M requests), making the decision heavily dependent on operational requirements rather than pure cost optimization.
Real-World Practitioner Insight #
Exam Rule #
“For the SAP-C02 exam, remember:
- REST API supports AWS integration (DynamoDB, SQS, SNS, Step Functions)
- HTTP API only supports Lambda and HTTP endpoints
- Always choose direct integration when no data transformation is needed
- Prefer HTTP API over REST API when Lambda is involved (70% cost savings)”
Real World #
“In production environments, I typically implement a hybrid pattern:
- Use REST API direct integration for high-volume, simple GET operations (e.g.,
/products/{id}) - Use HTTP API + Lambda for complex operations requiring multi-table joins or business logic
- Add API Gateway caching for frequently accessed DynamoDB items (not mentioned in exam scenario but reduces DynamoDB RCU costs by 60-80%)
- Implement DynamoDB DAX if read latency becomes critical (sub-millisecond response times)
The exam scenario oversimplifies the authentication layer鈥攔eal implementations would use:
- Cognito User Pools for partner application authentication
- API Gateway usage plans with API keys for rate limiting per partner
- WAF integration for DDoS protection on public APIs
Also, the ‘multiple DynamoDB tables’ hint suggests the need for Lambda-based aggregation logic, making Option C the practical primary choice with Option A as an optimization for specific endpoints.”