Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All
Cloud-AWS
Troubleshoot API Gateway 5xx errors

How can I troubleshoot 5xx errors for API Gateway?

Last updated: 2022-09-22

When I call my Amazon API Gateway API, I get an 5xx error. How do I troubleshoot API Gateway 5xx errors?

Short description

HTTP 5xx response codes indicate server errors. API Gateway 5xx errors include:

  • 500 internal server
  • 502 bad gateway
  • 503 service unavailable
  • 504 endpoint request timed out

Resolution

Before you begin, follow the steps to turn on Amazon CloudWatch Logs for troubleshooting API Gateway errors.

You can use the Amazon CloudWatch Logs to find 5xx errors from API Gateway. The API Gateway metric 5XXError counts the number of server-side errors captured in a given period.

Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.

500 error: internal server error

This error might be due to:

  • Errors in the AWS Lambda function code.
  • Missing permissions for using a stage variable.
  • Incorrect or missing HTTP status code mapping.
  • Throttling issues.
  • The HTTP method of POST isn't defined.
  • Lambda permissions.
  • Lambda function JSON format issue.
  • The backend payload size exceeded 10 MB.
  • Private endpoint integration.

Errors in the Lambda function code

API endpoints 500 errors that integrate with Lambda might indicate that the Lambda function has an error in the code. For more information and troubleshooting, see Error handling patterns in Amazon API Gateway and AWS Lambda.

Missing permissions for using a stage variable

If you set up an API Gateway to invoke an AWS Lambda function using a stage variable, you might receive an "internal server error". To resolve this error, see Why do I get an "Internal server error" and a 500 status code when I invoke the API method?

Incorrect or missing HTTP status code mapping

Incorrect or missing HTTP status code mapping can also result in 500 errors. To resolve this error, you can Set up mock integrations in API Gateway.

Throttling issues

If the backend service is throttled due to a high number of requests, the API Gateway API might return an "Internal server error". You can activate an exponential backoff and retry mechanism and try the request again. If the issue persists, check your API Gateway quota limit. If you exceeded the service quota limit, you can request a quota increase.

The HTTP method of POST isn't defined

For Lambda integration, you must use the HTTP method of POST for the integration request.

Update the method integration request using the AWS CLI command put-integration similar to the following:

aws apigateway put-integration \
    --rest-api-id id \
    --resource-id id \
    --http-method ANY \
    --type AWS_PROXY \
    --integration-http-method POST \
    --uri arn:aws:apigateway:us-east-2:lambda:path//2015-03-31/functions/arn:aws:lambda:us-east-2:account_id:function:helloworld/invocations

Then, deploy the REST API using the AWS CLI command create-deployment similar to the following:

aws apigateway create-deployment \
    --rest-api-id id \
    --stage-name <value>

Lambda permissions

Make sure that the integrated Lambda function or Lambda authorizers resource-based policy includes permissions for your API to invoke the function. Follow the instructions to update your Lambda function's resource-based policy.

Lambda function JSON format issue

The integrated Lambda function isn't returning output according to the predefined JSON format for REST APIs and HTTP APIs. Update your Lambda function or Lambda authorizer function JASON format similar to the following:

REST API

{
    "isBase64Encoded": true|false,
    "statusCode": httpStatusCode,
    "headers": { "headerName": "headerValue", ... },
    "multiValueHeaders": { "headerName": ["headerValue", "headerValue2", ...], ... },
    "body": "..."
}

HTTP API

{
    "isBase64Encoded": true|false,
    "statusCode": httpStatusCode,
    "headers": { "headername": "headervalue", ... },
    "multiValueHeaders": { "headername": ["headervalue", "headervalue2", ...], ... },
    "body": "..."
}

The backend payload size exceeded 10 MB

The maximum backend payload size is 10 MB and can't be increased. Make sure that the backend payload size doesn't exceed the 10 MB default quota.

Private endpoint integration

If you are using a private API endpoint, you must also configure API Gateway private integration. Follow the instructions to Set up API Gateway private integrations.

502 error: bad gateway

A 502 error code is related to the AWS service that your API Gateway integrates with such as an AWS Lambda function. API Gateway couldn’t process the response as a gateway or proxy.

To troubleshoot 502 error when integrated with a Lambda proxy function, see How do I resolve HTTP 502 errors from API Gateway REST APIs with Lambda proxy integration?

Note: API Gateway interprets the response from the backend service in a format that can be mapped in the integration response section using mapping templates. For more information, see Set up an integration response in API Gateway.

503 error: service unavailable

A 503 error code is related to the backend integration and the API Gateway API is unable to receive a response.

This error might occur if the backend server is:

  • Overloaded beyond capacity and is unable to process new client requests.
  • The backend server is under temporary maintenance.

To resolve this error, consider provisioning more resources to the backend server and activating an exponential backoff and retry mechanism on the client. Then, try the request again.

504 error: endpoint request timed out

If an integration request takes longer than your API Gateway REST API maximum integration timeout parameter, API Gateway returns an HTTP 504 status code.

To resolve this error, see How can I troubleshoot API HTTP 504 timeout errors with API Gateway?


Security best practices in Amazon API Gateway

Monitoring REST API execution with Amazon CloudWatch metrics

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Connect API Gateway to your on-premises network

How can I connect to API Gateway from my on-premises network?

Last updated: 2022-08-31

I want to connect to Amazon API Gateway from my on-premises network. How can I do this?

Short description

API Gateway API types include REST APIs (edge-optimized and Regional API endpoints), HTTP APIs, WebSocket APIs, and private REST APIs. REST APIs, HTTP APIs, and WebSocket APIs can be connected from on-premises networks directly. Private REST APIs can only be accessed from within an Amazon Virtual Private Cloud (Amazon VPC) using an interface VPC endpoint.

Resolution

Before you begin, verify that your on-premises network:

  • has connectivity to the internet.
  • firewall allows bidirectional traffic to and from the API Gateway endpoint.

Connect an on-premises network to a REST API, HTTP API, or WebSocket API

Use invoke to connect your on-premises network to API Gateway depending on the API type.

For REST APIs, see Invoking a REST API in Amazon API Gateway.

For HTTP APIs, see Publishing HTTP APIs for customers to invoke.

For WebSocket APIs, see Use wscat to connect to a WebSocket API and send messages to it.

Connect an on-premises network to a private REST API

Private REST APIs can be accessed from within an Amazon VPC using an interface VPC endpoint. Use the following access methods depending on your configuration.

Note:

  • The security group for the interface endpoint must allow inbound traffic from your on-premises source CIDR range on TCP port 443.
  • The private API resource policy must be updated to allow private API traffic from the source VPC or VPC endpoint.

AWS Direct Connect

You can use Direct Connect to connect your on-premises network to Amazon VPC and access your private API using pubic DNS names. For more information, see Accessing your private API using Direct Connect.

Amazon Route 53 alias

Follow the steps to associate an Amazon VPC endpoint with a private REST API.

API Gateway then generates a new Route 53 ALIAS DNS record. You can use this record to invoke your private API in the following URL format:

https://{rest-api-id}-{vpce-id}.execute-api.{region}.amazonaws.com/{stage}

For more information, see Accessing your private API using a Route 53 alias.

Private DNS names

If you are using private DNS, you can access your private API from your on-premises network using the private DNS names. You must set up a Route 53 Resolver inbound endpoint, and then forward to it all DNS queries of the private DNS from your on-premises network. For more information, see Invoking your private API using private DNS names.

Public DNS names

You can access your private API from your on-premises network using endpoint-specific DNS hostnames. The public DNS hostnames contain the VPC endpoint ID or API ID for your private API in the following URL format:

https://{public-dns-hostname}.execute-api.{region}.vpce.amazonaws.com/{stage}

For more information, see Invoking your private API using endpoint-specific public DNS hostnames.


How do I access a private API Gateway API when the VPC endpoint uses an on-premises DNS?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Provide cross-account IAM authorization for API Gateway HTTP APIs

How can I provide cross-account IAM authorization for API Gateway HTTP APIs?

Last updated: 2022-08-31

I want to activate AWS Identity and Access Management (IAM) authentication for cross-account access to my Amazon API Gateway HTTP API. How do I set that up?

Short description

For API Gateway REST APIs, you can use resource policies to provide IAM authentication for cross-accounts. However, this option isn't available for API Gateway HTTP APIs.

You can use the sts:AssumeRole API action to assume a role for the HTTP API account. The assumed role provides temporary security credentials that can be used to invoke the HTTP API in another account.

Resolution

Create the IAM temporary credentials

Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.

1.    Create an IAM policy for Account A that hosts the HTTP API. This policy provides invoke permission for the HTTP API execute-api ARN.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke",
            ],
            "Resource": [
                "arn:aws:execute-api:us-east-1:<AccountA-id>:<Api-id>/$default/*/*"
            ]
        }
    ]
}

2.    Create an IAM role in Account A , add "Trusted Entity Type" as "AWS Account", and enter the ID for Account B .

3.    Attach the IAM policy created in step 1 to the IAM role created in step 2 .

4.    Create an IAM policy for Account B to allow the sts:AssumeRole API action:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::<AccountA-id>:role/<AssumedRoleName>"
    }
  ]
}

5.    Attach the IAM policy to the user in Account B .

6.    Run the AWS CLI command assume-role similar to the following:

$ aws sts assume-role --role-arn arn:aws:iam::<account-id>:role/<AssumedRoleName> --role-session-name role_session

Example output:

{
    "Credentials": {
        "AccessKeyId": "A1B2C3D4E5E6G7H8J9K0",
        "SecretAccessKey": "abcdefghijk123456789",
       
 "SessionToken": 
"11111111111122222222223333333333344444444455555566666667777777777778888888999999999aaaaaaaaaabbbbbbbbbcccccccc==",
        "Expiration": "2022-07-11T15:55:25+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AAAAAAABBBBBBBBBBB:role_session",
        "Arn": "arn:aws:sts::<account-id>:assumed-role/<AssumedRoleName>/role_session"
    }
}

Check the credentials object for the AccessKeyId , SecretAccessKey , and SessionToken . These temporary credentials provided by the assumed role can be used to invoke the HTTP API.

Test the IAM authentication

Use the Postman app to send a request to your API resource using the method that you activated IAM authentication for.

Note: To manually authenticate requests that are sent to API Gateway using another tool or environment, use the Signature Version 4 (SigV4) signing process. For more information, see Signing AWS API requests.

1.    In Postman, choose the Authorization tab and do the following:
For Type , choose AWS Signature .
For AccessKey , SecretKey , and SessionToken , enter the values from the assume-role API call.

2.    For Enter request URL , enter your API's invoke URL similar to the following:

https://<Api-id>.execute-api.<region>.amazonaws.com/<stagename>/<resourcepath>

An authenticated request returns a 200 OK response code. An unauthorized request returns the message Missing Authentication Token and a 403 Forbidden response code.


How do I activate IAM authentication for API Gateway REST APIs?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Troubleshoot missing CloudWatch logs for API Gateway REST APIs

How can I troubleshoot missing CloudWatch logs for API Gateway REST APIs?

Last updated: 2022-08-30

I have activated Amazon CloudWatch logging for Amazon API Gateway, but I couldn't find any logs. How do I get the CloudWatch logs for troubleshooting API Gateway REST APIs?

Short description

You can use CloudWatch logging can be used to help debug issues related to request execution or client access to your API. CloudWatch logging includes execution logging and access logging.

For execution logging, API Gateway manages the CloudWatch logs including creating log groups and log streams. For access logging, you can create your own log groups or choose existing log groups.

Not all client-side errors rejected by API Gateway are logged into execution logs. For example, a client making an API request to an incorrect resource path of your REST API returns a 403 "Missing Authentication Token" response. This type of response isn't logged into execution logs. Use CloudWatch access logging to troubleshoot client-side errors.

For more information, see CloudWatch log formats for API Gateway.

API Gateway might not generate logs for:

  • 413 Request Entity Too Large errors.
  • Excessive 429 Too Many Requests errors.
  • 400 series errors from requests sent to a custom domain that has no API mapping.
  • 500 series errors caused by internal failures.

For more information, see Monitoring REST APIs.

Resolution

Verify API Gateway permissions for CloudWatch logging

To activate CloudWatch Logs, you must grant API Gateway permission to read and write logs to CloudWatch for your account. The AmazonAPIGatewayPushToCloudWatchLogs managed policy has the required permissions.

Create an AWS Identity and Access Management (IAM) role with apigateway.amazonaws.com as its trusted entity. Then, attach the following policy to the IAM role, and set the IAM role ARN on the cloudWatchRoleArn property for your AWS Account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams",
        "logs:PutLogEvents",
        "logs:GetLogEvents",
        "logs:FilterLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

Make sure that:

  • AWS Security Token Service (AWS STS) is activated for your AWS Region. For more information, see Managing AWS STS in an AWS Region.
  • The IAM role is activated for all AWS Regions where you want to activate CloudWatch logs.

For more information, see Permissions for CloudWatch logging.

Verify API Gateway logging settings

Verify that the CloudWatch execution or access logging settings are activated for API Gateway.

Note: You can activate execution logging and access logging independent of each other.

1.    Open the API Gateway console.

2.    In the navigation pane, choose APIs .

3.    Choose your API, and then choose Stages .

4.    In Stages , choose your stage, and then choose the Logs/Tracing tab.

5.    In CloudWatch Settings , verify the following:
Enable CloudWatch Logs is selected.
Log level is set to INFO .
Note:
If Log level is set to ERROR , only requests for errors in API Gateway are logged. Successful API requests aren't logged.
Log full requests/responses data and Enable Detailed CloudWatch Metrics are selected for additional log data.
Note:
It's a best practice not to enable Log full requests/responses data for production APIs which can result in logging sensitive data.

6.    In Custom Access Logging , verify that Enable Access Logging is selected.

Verify logging method and override if necessary

By default, all API resources use the same configurations as their stage. This setting can be overridden to have different configurations for each method if you don't want to inherit from the stage.

1.    Open the API Gateway console.

2.    In the navigation pane, choose APIs .

3.    Choose your API, and then choose Stages .

4.    In Stages , expand your stage name, and then choose your HTTP method. For example, GET .

5.    In Settings , choose Override for this method .

6.    In CloudWatch settings , make any additional log changes for your use case if needed, and then choose Save Changes .

For more information, see Setting up CloudWatch logging for a REST API in API Gateway.


How do I find API Gateway REST API errors in my CloudWatch logs?

How can I set up access logging for API Gateway?

How do I turn on CloudWatch Logs for troubleshooting my API Gateway REST API or WebSocket API?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Disable API Gateway default endpoint API

How can I disable the API Gateway default endpoint for REST or HTTP APIs?

Last updated: 2022-08-26

I want to allow clients to invoke my APIs only using the custom domain name. How can I deactivate the default API execute-api endpoint URL for Amazon API Gateway REST or HTTP APIs?

Short description

API Gateway REST APIs and HTTP APIs use a default API endpoint in the following format: " https://{api_id}.execute-api.{region}.amazonaws.com ". If you use a custom domain name for your API Gateway REST or HTTP APIs, you can deactivate the default endpoint. This allows all traffic to route to your APIs through the custom domain name.

Resolution

Follow these steps to disable the default endpoint using the API Gateway console, AWS Command Line Interface (AWS CLI), or AWS CloudFormation.

Note:

  • If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.
  • After you activate or deactivate the default endpoint, a deployment is required for the update to take effect.

API Gateway console

REST API

  1. Open the API Gateway console.
  2. In the navigation pane, choose APIs , and then choose your REST API.
  3. In the navigation pane, choose Settings .
  4. For the Default Endpoint , choose Disabled , and then choose Save Changes .
  5. In the navigation pane, choose Resources , Actions , and then choose Deploy API .

HTTP API

  1. Open the API Gateway console.
  2. In the navigation pane, choose APIs , and then choose your HTTP API.
  3. In the navigation pane, choose Settings .
  4. For the Default Endpoint , choose Disabled , and then choose Save Changes .
  5. In the navigation pane, choose Resources , Actions , and then choose Deploy API .

AWS CLI

REST API

Run the AWS CLI command update-rest-api similar to the following:

aws apigateway update-rest-api --rest-api-id abcdef123 --patch-operations op=replace,path=/disableExecuteApiEndpoint,value='True'

To deploy the updated API, run the AWS CLI command create-deployment similar to the following

aws apigateway create-deployment --rest-api-id abcdef123 --stage-name dev

Note: Replace api_id abcdef123 and stage_name dev with your REST API ID and respective stage.

HTTP API

Run the AWS CLI command update-api similar to the following:
aws apigatewayv2 update-api --api-id abcdef123 --disable-execute-api-endpoint

To deploy the updated API, run the AWS CLI command create-deployment similar to the following:

aws apigatewayv2 create-deployment --api-id abcdef123 --stage-name dev

Note: Replace api_id abcdef123 and stage_name dev with your HTTP API ID and respective stage.

CloudFormation template

To disable the default endpoint from a CloudFormation template, you can set the DisableExecuteApiEndpoint parameter to True . Update the CloudFormation template for REST API or HTTP API.

Important: Disabling the default endpoint results in HTTP 403 Forbidden errors if the API is invoked using the default endpoint URL.


How do I troubleshoot HTTP 403 errors from API Gateway?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Pass API Gateway REST API data to Lambda or an HTTP endpoint

How do I pass data through an API Gateway REST API to a backend Lambda function or HTTP endpoint?

Last updated: 2022-08-26

I want my Amazon API Gateway REST API to pass data to a backend AWS Lambda function and an HTTP endpoint. How can I do that?

Short description

To configure a REST API to pass data to a backend Lambda function, use a Lambda custom integration.

To pass query string parameters to an HTTP endpoint, use an HTTP custom integration.

Important: Make sure that the input data is supplied as the integration request payload. It’s a best practice to use a mapping template to supply the payload. For more information, see Map request and response payloads between method and integration.

Resolution

Create a Lambda function to handle custom headers from your API Gateway API

1.    Open the Lambda console.

2.    Choose Create function . The Create function page opens with the Author from scratch option selected.

3.    In the Basic information pane, do the following: For Function name , enter a name that describes your function's purpose. For example: MapTemplate . For Runtime , choose Python 3.9 .

4.    For Permissions , expand Change default execution role .

5.    Choose Use an existing role . A dropdown list of existing roles appears.

6.    For Existing role , choose the Lambda execution role that you created earlier.

7.    Choose Create function .

8.    From the Code tab, in Code source , replace the code in lambda_function.py with the following:

import json

def lambda_handler(event, context):
    print(event)
    return {
        'statusCode': 200,
        'body': json.dumps(event) # returning the data sent to backend lambda function as API response.
    }

9.    Choose Deploy .

For more information, see Building Lambda functions with Python.

Pass data to the backend Lambda function or HTTP endpoint

1.    Open the API Gateway console.

2.    Choose Create API .

-or-

(If this is your first time using API Gateway) A page that introduces you to the features of the service appears. In REST API , choose Build . When the Create Example API popup appears, choose OK .

3.    For Choose an API type , in the REST API pane, choose Build .

4.    In Create new API , choose New API .

5.    In Settings , do the following: For API name , enter a name that describes your API's purpose. For example: MappingTemplateTutorial . (Optional) For Description , enter a short description your API's purpose. For example, Send Data to Backend Lambda function/HTTP endpoint . For Endpoint Type , choose Regional .

6.    Choose Create API .

Configure your API's resources, integration point, and body mapping template

1.    In the API Gateway console, choose the name of the API that you created in the previous step. Your API's Resources page opens.

2.    On the Resources page, choose Actions . Then, choose Create Resource .

3.    In the New Child Resource pane, for Configure as proxy resource , select the check mark icon , and then choose Create Resource .

4.    On the /{proxy+} - ANY - Setup page, do the following:

  • For Integration type , choose Lambda Function Proxy .
  • For Lambda Region , choose the AWS Region that hosts your function.
  • For Lambda Function , enter the function's name MappingTemplateTutorial .

Choose Save . An Add Permission to Lambda Function popup appears, choose OK .

7.    On the / {proxy+} - ANY - Method Execution page, choose Integration Request .

8.    On the / {proxy+} - ANY - Integration Request page, do the following:

  • Uncheck the Use Lambda Proxy integration icon box. A Switch to Lambda integration popup appears.
  • In the popup, choose OK. An Add Permission to Lambda Function popup appears. In the popup, choose OK
  • Expand Mapping Templates .
  • For Request body passthrough , choose When there are no templates defined (recommended) .

Choose Add mapping template . For Content-Type , enter application/json . Then, choose the check mark icon.

9.    Choose the Generate template dropdown list, and then choose Method Request passthrough .

10.    In the mapping template editor, enter the following:

##  See http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html
#set($allParams = $input.params())
{
"method" : "$context.httpMethod", ## API method
"authcontext" : "$context.authorizer.stringkey", ## Optional output from Lambda Authorizers
## passthrough body
"body-json" : $input.json('$'),
## passthrough headers, querystrings and path parameters
"params" : {
#foreach($type in $allParams.keySet())
    #set($params = $allParams.get($type))
"$type" : {
    #foreach($paramName in $params.keySet())
    "$paramName" : "$util.escapeJavaScript($params.get($paramName))"
        #if($foreach.hasNext),#end
    #end
}
    #if($foreach.hasNext),#end
#end
}
}

11.    Choose Save .

12.    Choose Method Execution to come back to / {proxy+} - ANY - Method Execution page.

13.    Choose Method Response to setup valid method response.

14.    On /{proxy+} - ANY - Method Response page, Choose Add Response .

15.    For HTTP status code, enter 200 . Then, choose the check mark icon.

16.    Choose Actions to Deploy API to a stage.

Deploy your API to a new stage

1.    Follow the instructions in Deploy a REST API to a stage. For more information, see Setting up a stage using the API Gateway console.

2.    In the Stage Editor pane, copy the Invoke URL to your clipboard.

REST API Invoke URL example

https://1a2bc3d456.execute-api.us-east-1.amazonaws.com/stage

Test your setup

To confirm that all data is being passed to backend Lambda function or HTTP endpoint by your API, run the following curl command:

Important: Replace https://restApiId.execute-api.region.amazonaws.com/stageName with your API's invoke URL.

curl -i --location --request POST 'https://1a2bc3d456.execute-api.us-east-1.amazonaws.com/stage/path1/path2?query1=querystring1&query2=querystring2' --header 'header1: value1' --header 'header2: value2' --header 'Content-Type: application/json' --data-raw '{"keybody":"valuebody"}'

The command output includes all data received by the backend Lambda function to the client. You can update the output message for your environment.

Note: To install curl on Windows, see Downloads on the Git website. For more information about curl, see the curl project website.


Tutorial: Build an API Gateway REST API with Lambda non-proxy integration

Setting up data transformations for REST APIs

How do I pass custom headers through API Gateway to a Lambda function using custom Lambda integration?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article