🚦 API Gateway Monitoring
API Gateway is the front door to your backend services. Monitoring it properly helps you understand API performance, cache effectiveness, error rates, and diagnose exactly where latency originates — in the API Gateway layer or the backend.
🔑 Covers: Latency vs IntegrationLatency · Cache Metrics · Error Rates · Access Logs · CloudWatch IntegrationThe Most Important Metrics — Latency Deep Dive
Understanding the difference between Latency and IntegrationLatency is one of the most frequently tested API Gateway concepts.
←————— IntegrationLatency (backend time) —————→
⏱️ Latency
Definition: Total time from when API Gateway receives the request to when it sends the response to the client.
Includes: All API Gateway processing + time waiting for backend + response processing.
Measures: The end-to-end response time as experienced by the client.
High Latency Signal: Investigate both API Gateway overhead AND backend performance.
🔗 IntegrationLatency
Definition: Time from when API Gateway sends the request to the backend until it receives the response from the backend.
Includes: Only the backend processing time (Lambda execution, HTTP endpoint response time).
Does NOT include: API Gateway's own processing overhead.
High IntegrationLatency: Backend (Lambda, HTTP) is slow. Focus optimization there.
🧮 The Math — What It Tells You
API Gateway Overhead = Latency − IntegrationLatency
If Latency = 500ms and IntegrationLatency = 480ms → API GW overhead = 20ms (normal). Backend is the problem.
If Latency = 500ms and IntegrationLatency = 50ms → API GW overhead = 450ms (abnormal!). Problem is inside API Gateway — check: authorizer, WAF, request transformation, VPC Link latency.
"Latency is high AND IntegrationLatency is high" → Backend (Lambda/HTTP) is slow. Optimize your Lambda function or backend API.
API Gateway Cache Metrics
API Gateway can cache backend responses for a configurable TTL. Cache metrics tell you how effectively your cache is working.
✅ CacheHitCount
Number of requests served from the API Gateway cache (no backend call made). High hit count = cache is working = lower cost + lower latency + less load on backend.
Goal: High as possible for cacheable endpoints.
❌ CacheMissCount
Number of requests that couldn't be served from cache (backend was called). Could be because: cache is disabled, TTL expired, request has unique parameters, cache was invalidated.
High Miss Count means: Review TTL settings, check what's making requests uncacheable (query parameters, headers).
📊 Cache Hit Rate Calculation
Cache Hit Rate = CacheHitCount / (CacheHitCount + CacheMissCount) × 100%
A good cache hit rate is 70-90%+. If it's low, consider: increasing TTL, removing dynamic parameters from cache key, enabling caching for more methods.
Access Logs — Detailed Request Logging
By default, API Gateway only sends metrics to CloudWatch. To get detailed logs of each API request/response, you enable Access Logging.
What Access Logs Contain
You define the log format using context variables. Example fields you can log:
Access logs go to a CloudWatch Logs Group. You can then use Logs Insights to query them and build dashboards.