API Gateway Logs: What to Log and What to Query

Last verified on Nov 8, 2026.

API Gateway is the front door for many AWS backends. Its logs are often the quickest way to tell whether a problem is the caller, the gateway or the service behind it. They only exist if you turn them on, and the format is yours to define.

Two kinds of log

AWS describes two types of API logging in CloudWatch:

• Access logging records who accessed your API and how. You create the log group, choose the format and pick which $context variables to include.
• Execution logging records the actions API Gateway took to process each request, including errors and execution traces. The Sazabi docs call out REST APIs for this one.

They can be enabled independently. Execution logging needs a CloudWatch Logs role with the AmazonAPIGatewayPushToCloudWatchLogs policy, set once per Region.

Fields worth logging

The AWS variable reference defines these, and they are the ones that answer most questions:

• $context.status is the method response status.
• $context.integration.status is the status code the integration returned.
• $context.responseLatency is the response latency in milliseconds.
• $context.identity.sourceIp is the address of the immediate TCP connection.
• $context.identity.userAgent is the caller's User-Agent header.
• $context.authorizer.principalId and $context.authorizer.error identify the caller and any authorizer error.
• $context.wafResponseCode is WAF_ALLOW or WAF_BLOCK when a web ACL is attached.
• $context.resourcePath names the route for REST APIs. HTTP and WebSocket APIs use $context.routeKey.

The Sazabi docs recommend a JSON format that includes all of these, which keeps each field searchable.

What to look for

• 5xx by route. Group status by resourcePath and look for one route that dominates.
• A gap between status and integrationStatus. If the integration returned 200 and the gateway returned something else, the problem is between them.
• 401 and 403 by ip or principalId. One caller failing authorization repeatedly is a misconfigured client or a probe.
• 429 by caller. Throttled clients show up here.
• Slow routes. Sort by responseLatency within each route, not across the whole API.
• wafResponseCode equal to WAF_BLOCK. Pair it with your AWS WAF logs for the rule behind the block.

Example: a failed authorization

This is an example access log line in the JSON format from the Sazabi docs, abbreviated. The values are made up.

{
  "requestId": "c6af9ac6-7b61-11e6-9a41-93e8deadbeef",
  "requestTime": "1731070000000",
  "ip": "198.51.100.23",
  "httpMethod": "GET",
  "resourcePath": "/orders/{id}",
  "status": "403",
  "responseLatency": "14",
  "authorizerError": "User is not authorized to access this resource",
  "wafResponseCode": "WAF_ALLOW",
  "integrationStatus": "-"
}

The status is 403 and the integration status is unset because the authorizer refused the call before it reached your service. The latency is short for the same reason. Group that pattern by ip and you can tell a single misbehaving client from a bad deploy that broke authorization for everyone.

How Sazabi reads API Gateway logs

API Gateway writes both log types to CloudWatch Logs, and Sazabi reads them through the same path as the CloudWatch source. The Sazabi docs say to use log group names that start with API-Gateway-Access-Logs_ for access logs. Execution logs go to groups starting with API-Gateway-Execution-Logs_.

There are two ways in:

• If your account is already connected through the native CloudWatch source, turn on API Gateway logging and pick its log groups. No collector is needed.
• Otherwise run an OpenTelemetry Collector Contrib deployment with the awscloudwatch receiver. The collector needs logs:DescribeLogGroups and logs:FilterLogEvents, the credential stays with your collector and it exports to your Sazabi intake URL. See OpenTelemetry for the collector side.

To confirm records are arriving, the Sazabi docs suggest asking how many API Gateway access log lines arrived in the last 15 minutes, by status. Then search for status 401 or 403 for failed authorizations and 429 for throttled clients.

Related AWS sources

Gateway logs describe requests. VPC Flow Logs describes the network under the services behind it. See the AWS integration page for the full set, and the pricing page for plans.