Skip to content
Ask AI about this
Help improve this page

API Gateway stages should have logging enabled

API Gateway logs are the primary source of truth for understanding who called your APIs, what they requested, and how the backend responded. Without execution or access logging, you lose visibility into authentication failures, authorization errors, latency spikes, and integration faults. These gaps make incident investigation slow and unreliable.

Access logs feed SIEM tools and anomaly detection pipelines. Execution logs capture request/response payloads and transformation errors that are invisible at the network layer. Disabling either leaves a blind spot that attackers can exploit undetected.

Retrofit consideration

Enabling execution logging at INFO level on high-traffic stages can generate significant CloudWatch Logs volume and cost. Estimate log volume before enabling on production stages.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_api_gateway_stage.

resource "aws_api_gateway_rest_api" "this" {
  name = "pofix-abc123"
}

resource "aws_api_gateway_stage" "this" {
  access_log_settings {
    destination_arn = "arn:aws:logs:us-east-1:123456789012:log-group:example-log-group"
    format          = "$context.requestId"
  }
  client_certificate_id = "abc123"
  deployment_id         = "abc123"
  rest_api_id           = "abc123"
  stage_name            = "example"
}

What this control checks

This control validates that each aws_api_gateway_stage has logging configured. Two aspects matter. First, execution logging must be enabled via an aws_api_gateway_method_settings resource associated with the stage. The settings block must set logging_level to "INFO" or "ERROR". A value of "OFF" or omitting the setting entirely causes a failure. The method_path of "*/*" applies the setting to all methods. Second, access logging requires an access_log_settings block on aws_api_gateway_stage with a destination_arn pointing to a CloudWatch Logs log group or Firehose stream ARN. The stage must also reference a valid deployment_id. It fails when both execution logging and access log configuration are absent.

Common pitfalls

  • Method settings not applied to all methods

    Logging gaps are easy to miss when method_path targets a specific route like "resource/GET" instead of "*/*". Every method not covered by the settings resource stays at OFF, and the control flags the stage as non-compliant. Use "*/*" unless you have a specific reason to scope it differently, and be aware that narrower paths won't satisfy this control.

  • Access log settings changes may require a deployment update

    Updating access_log_settings on aws_api_gateway_stage without also triggering a redeployment can leave the API Gateway console showing stale configuration. If deployment_id isn't updated or a redeployment trigger is missing, the change may not take effect. Add a triggers map to aws_api_gateway_deployment that references the stage configuration, so any relevant change forces a new deployment.

  • Missing CloudWatch Logs role ARN on the account

    API Gateway requires a CloudWatch Logs IAM role configured at the account level via aws_api_gateway_account with cloudwatch_role_arn. Without it, execution logging silently fails even when logging_level is set to "INFO". The control may pass at plan time, but logging produces no output. This is a one-time account-level setup that's easy to skip in module-only deployments.

  • Access log destination ARN must exist before apply

    Create the aws_cloudwatch_log_group before the stage, either with an explicit depends_on or by referencing the log group's ARN attribute directly in destination_arn. If the log group doesn't exist at apply time, the API Gateway API call fails and Terraform surfaces a somewhat opaque error.

  • HTTP APIs vs REST APIs use different resources

    This control targets REST API stages (aws_api_gateway_stage). HTTP APIs use aws_apigatewayv2_stage, which has a different access_log_settings structure and a default_route_settings block with its own logging_level. Using the wrong resource type means the control never evaluates the stage you think it's evaluating.

Audit evidence

Auditors expect AWS Config rule evaluation results for api-gw-execution-logging-enabled showing compliant status across all API Gateway stages. Console screenshots of the stage editor's "Logs/Tracing" tab with CloudWatch Logs enabled at INFO or ERROR level and an access log destination ARN configured support the finding. CloudWatch Logs log group listings that correspond to API Gateway access log destination ARNs show that logs are actually being written, not just configured.

For continuous assurance, export AWS Config compliance history or provide a scan report from Prowler, Steampipe, or equivalent covering the evaluation period. CloudTrail events for UpdateStage and UpdateMethodSettings confirm when logging was enabled and who made the change.

Framework-specific interpretation

SOC 2: CC7.2 expects monitoring of system components to detect anomalies. API Gateway stage logs give auditors the evidence trail they look for: confirmation that API access is being captured and is available for review when a security event occurs.

PCI DSS v4.0: Requirement 10.2 mandates an audit trail for all access to system components in the cardholder data environment. Any API Gateway stage processing or transmitting cardholder data needs both execution and access logging enabled to cover that requirement.

HIPAA Omnibus Rule 2013: 45 CFR 164.312(b) requires audit controls that record and examine activity in systems containing ePHI. For API Gateway stages fronting healthcare APIs, logging access patterns is how you detect unauthorized data retrieval or modification attempts, and it's what auditors check first.

NIST SP 800-53 Rev 5: The AU family (AU-2, AU-3, AU-12) calls for event logging with enough detail to support incident analysis and continuous monitoring. API Gateway logs satisfy this for API-layer activity: caller IP, request parameters, response status, and integration errors.

NIST Cybersecurity Framework v2.0: API Gateway logs feed directly into DE.CM monitoring for anything passing through the API layer. Without them, anomalous access patterns go undetected at the source.

FedRAMP Moderate Baseline Rev 4: AU-2 and AU-3 under FedRAMP Moderate require that all system components produce audit records capturing caller identity, timestamps, and response codes. Execution and access logging on API Gateway stages meets that requirement for web service endpoints in federal information systems.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: apigateway_stage_logging_enabled

  • AWS Config Managed Rules: APIGATEWAY_STAGE_ACCESS_LOGS_ENABLED, API_GW_EXECUTION_LOGGING_ENABLED

  • Checkov Check: CKV2_AWS_4

  • Powerpipe Controls: aws_compliance.control.apigateway_stage_logging_enabled, aws_compliance.control.gatewayv2_stage_access_logging_enabled

  • Prowler Checks: apigateway_restapi_logging_enabled, apigatewayv2_api_access_logging_enabled

  • AWS Security Hub Control: APIGateway.1

  • KICS Queries: 1b6799eb-4a7a-4b04-9001-8cceb9999326, 982aa526-6970-4c59-8b9b-2ce7e019fe36

  • Trivy Check: AWS-0001

Last reviewed: 2026-03-08