Brainsteam

Search

SearchSearch

AWS API Gateway

Apr 25, 20253 min read

softengdevopsaws

AWS Documentation

AWS API Gateway provides a bundle of functionality for proxying inbound HTTP requests to different containers and services running inside AWS.

API Gateways can easily be deployed by using AWS SAM to manage serverless stacks of gateways and lambda functions.

Custom Lambda Authorizer for Custom Auth Header

By default AWS API Gateway has a built in mechanism for passing a pre-shared API key via the x-api-key header in a HTTP request. However, this header name cannot be customised. If we need to build in compatibility with some existing REST convention (e.g. passing api keys via Authorization: Bearer <token> instead of x-api-key: <token>) this presents a challenge.

To get around this we can create a custom custom lambda function that checks whether the current user should be allowed to call the API or not.

import logger
 
def auth_handler(event, context):
    """Lambda function to authorize API Gateway requests using an API key."""
    logger.info("Received event: %s", event)
    if "authorizationToken" not in event:
        logger.warning("No authorization token provided")
 
    authorization_header = event.get("authorizationToken")
    api_key = authorization_header[len("Bearer "):] if authorization_header.startswith("Bearer ") else None
 
    action = "Allow"
 
    # ARN looks like arn:aws:execute-api:<region-name>:<account-number>:<gateway-id>/<stage-name>/<method-name>/<resource-path>
    # we want to allow access to all methods for the given resource path by replacing /<method-name>/<resource-path> with /*
    # Modify the Resource to allow access to all methods for the current ARN
    resource_arn = event["methodArn"].split("/", 1)[0] + "/*"
    
    policy = {
        "principalId": "x-api-key",
        "policyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Action": "execute-api:Invoke",
                    "Effect": action,
                    "Resource": resource_arn,
                },
            ],
        },
    }
 
    if api_key is not None:
        policy["usageIdentifierKey"] = api_key
 
    logger.info("Generated policy: %s", policy)
 
    return policy

Troubleshooting Inconsistent Authorizers

If you find that authorizers sometimes let you in - perhaps you can successfully GET but following this with a POST fails, it might be because AWS is caching the authorizer result and your methodARN is too granular. In the example above we discard the Method (e.g. GET or POST) and just grant an Allow to ‘*‘ for the given lambda function.

Resources:

Setting up Logging for API Gateway

Using AWS SAM:

Resources:
 
  AccessLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/aws/apigateway/${ApiGateway}/${EnvironmentName}"
      RetentionInDays: 7
 
  ApiGateway:
    Type: AWS::Serverless::Api
    Properties:
      Name: my-api-gateway
      StageName: prod
      AccessLogSetting:
          DestinationArn: !GetAtt AccessLogGroup.Arn
          Format: '{"requestTime":"$context.requestTime","requestId":"$context.requestId","httpMethod":"$context.httpMethod","path":"$context.path","resourcePath":"$context.resourcePath","status":$context.status,"responseLatency":$context.responseLatency}'
 
      # other stuff ...
      TracingEnabled: true # turns on x-ray tracing
      MethodSettings:
        - ResourcePath: "/*"
          HttpMethod: "*"
          ThrottlingBurstLimit: 2
          ThrottlingRateLimit: 2
          # for logging 
          LoggingLevel: INFO
          DataTraceEnabled: true
          MetricsEnabled: true

The access logs will be in CloudWatch under “/aws/apigateway/gateway-name/stage-name” but these won’t help you to debug issues with authorizers. They simply provide a log of who accessed the api.

The more interesting logs are the execution logs. They can be found in Cloudflare with the pattern API-Gateway-Execution-Logs_<GATEWAY_ID>/<STAGE_NAME>

Resources

Graph View

Backlinks