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
Pass a connectionId or custom token to VPC Link integration as a header for API Gateway WebSocket APIs

How can I pass a connectionId or custom token to VPC Link integration as a header for Amazon API Gateway WebSocket APIs?

Last updated: 2022-10-26

I want to pass a connectionId or custom token to VPC Link integration as a header for my Amazon API Gateway WebSocket API. How can I do this?

Short description

For WebSocket APIs, the connectionId is required to send a callback response from the backend. By default, WebSocket APIs don't pass the ConnectionId to VPC link integration.

Resolution

Using the Amazon API Gateway console and AWS CLI

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.    Follow the instructions to create a REST API VPC link and associate it with your Network Load Balancer.

2.    Follow the instructions to set up a WebSocket API integration and create a VPC link private integration endpoint.

3.    To retrieve the integration ID, run the AWS CLI command get-integrations similar to the following:

aws apigatewayv2 get-integrations --api-id <api-id>

4.    Create and save a JSON file named integration.json in the following format:

{
    "ApiId": "<api-id>",
    "IntegrationId": "<integration id retrieved from previous step>",
    "RequestParameters": {
        "integration.request.header.ConnectionId": "context.connectionId", //passing context variable connectionId as ConnectionId header to backend
        "integration.request.header.<header-key>": "route.request.body.<parameter>", // passing a request body parameter as header to backend
        "integration.request.querystring.<querysting-key>": "'static value'" //passing static value as querystring to backend
    }
}

Note: Before proceeding to step 5 , remove the comments noted with the forward slashes " // ".

5.    To update the integration, run the AWS CLI command update-integration similar to the following:

aws apigatewayv2 update-integration --cli-input-json file://integration.json
6.    To apply these changes, follow the instructions to deploy the REST API.

Using AWS CloudFormation

If you manage Amazon API Gateway using CloudFormation, you can use the AWS::ApiGatewayV2::Integration resource to configure request parameters similar to the following:

Integration:
    Type: AWS::ApiGatewayV2::Integration
    Properties:
      ApiId: !Ref websocket
      ConnectionId: !Ref <VPC-Link-connection-id>
      ConnectionType: VPC_LINK
      IntegrationMethod: <HTTP method to backend >
      IntegrationType: <HTTP_PROXY/HTTP>
      IntegrationUri: "<endpoint-url>"
      RequestParameters:
        "integration.request.header.connectionId": "context.connectionId" #passing context variable 'connectionId' as ConnectionId header to backend
        "integration.request.header.<header-key>": "route.request.body.<parameter>"  #passing a request body parameter as header to backend
        "integration.request.querystring.<querystring-key>": "'static value'" #passing static value as querystring to backend

You can use data mapping to map data from a route request to the VPC link backend integration. For more information, see Map route request data to integration request parameters.


Setting up WebSocket API integrations

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Troubleshoot "internal server" error status code 500 for API Gateway enpoints with Lambda integration

How can I troubleshoot the "internal server" error with status code 500 for API Gateway endpoints that integrate with Lambda?

Last updated: 2022-10-19

I sent an HTTP request to my Amazon API Gateway API endpoint that integrates with AWS Lambda (for example, /lambda-resource GET). I received a status code 500 response with the following error: {"message": "Internal server error"}

How can I troubleshoot this error?

Short description

This error might be due to:

  • Lambda function permissions
  • Throttling issues
  • Incorrect or missing HTTP status code mapping
  • Unhandled errors

Resolution

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

Note: For Log level , choose INFO to generate execution logs for all requests.

Lambda function permissions

The error “Invalid permissions on Lambda function” occurs if API Gateway doesn't have permissions to invoke the Lambda function. To resolve this, see How do I resolve "Invalid permissions on Lambda function" errors from API Gateway REST APIs?

Note: If you used another service, such as AWS CloudFormation, to deploy your API Gateway resources, make sure that you have permissions to the AWS::Lambda::Permission resource.

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.

You might also receive "Rate exceeded" and 429 "TooManyRequestsException" errors due to Lambda function throttling issues. For more information, see How do I troubleshoot Lambda function throttling with "Rate exceeded" and 429 "TooManyRequestsException" errors?

You can also request an increase for the Lambda function's concurrency limit so that the function doesn't get throttled. For instructions, see How do I request a concurrency limit increase for my Lambda function?

Incorrect or missing HTTP status code mapping

Incorrect or missing HTTP status code mapping can also result in 500 errors similar to the following:

"Execution failed due to configuration error: Output mapping refers to an invalid method response: 2xx/4xx/5xx".

To resolve this error, make sure that an API method response exists for the status code returned from the backend and is mapped correctly.

Unhandled errors

Unhandled errors in Lambda indicate that the function timeouts due to errors in the function code. To prevent this error, make sure that the Lambda function code is idempotent.

You can also use the debugging tool AWS X-Ray to get more details on how long different sections of your function’s code takes to complete.

For more information, see Error handling patterns in Amazon API Gateway and AWS Lambda.


How can I troubleshoot 5xx errors for API Gateway?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Delete an Amazon VPC link for an Amazon Gateway REST API

How can I delete an Amazon VPC link for my Amazon Gateway REST API?

Last updated: 2022-10-04

I'm trying to delete my Amazon Virtual Private Cloud (Amazon VPC) link for my Amazon Gateway REST API and received the following error:

"Cannot delete VPC link referenced in format of [Method:Resource]."

How can I resolve this?

Short description

If a resource using the Amazon VPC link integration is deleted, then you can't delete the link.

Resolution

To delete the Amazon VPC link, follow these steps depending on whether the REST API was or was not deployed.

Deployed REST APIs

Switch the integration type from the Amazon VPC link to another type. For example, a mock integration, HTTP integration, or AWS integration type. After switching the integration type, redeploy the REST API to the same stage name that you previously deployed. Then, try deleting the Amazon VPC link again.

Undeployed REST APIs

Switch the integration type from the Amazon VPC link to another type. For example, a mock integration, HTTP integration, or AWS integration type. Then, try deleting the Amazon VPC link again.


Tutorial: Build a REST API with API Gateway private integration

How can I access an API Gateway private REST API in another AWS account using an interface VPC endpoint?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Access an Amazon API Gateway API from another AWS account

How can I access an Amazon API Gateway API from another AWS account?

Last updated: 2022-10-03

I want to access an Amazon API Gateway API from another AWS account. How can I do this?

Short description

Public API endpoints (Regional or edge-optimized) can be accessed directly from the public endpoint stage URL or a custom domain name.

Private REST APIs endpoints can be accessed from a virtual private cloud in Amazon Virtual Private Cloud (Amazon VPC) using an interface VPC endpoint.

Amazon API Gateway endpoints can be accessed using AWS Identity and Access Management (IAM) authentication with cross-account access.

Resolution

Public API endpoints

You can access API Gateway public endpoints directly from the API stage URL. For example, https://0123456789.execute-api.{region}.amazonaws.com/{stage-name}.

You can also access API Gateway public endpoints using a custom domain name in a public hosted zone.

Note: Custom domain names aren't supported for private APIs.

For more information, see How can I set up a custom domain name for my API Gateway API?

Private REST API endpoints

You can access API Gateway private REST APIs in another AWS account with an Amazon Virtual Private Cloud (Amazon VPC) using an interface endpoint.

If your private REST API is located in an AWS account and you want to access it from another account, you can edit the resource policy.

For more information, see How can I access an API Gateway private REST API in another AWS account using an interface VPC endpoint?

APIs using IAM authentication

Additional configuration is required to access an API Gateway API with cross-account access that uses IAM authentication. The IAM role of the source account must be allowed explicit access in the resource policy similar to the following:

REST APIs

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::account-id-2:user/Alice",
          "account-id-2"
        ]
      },
      "Action": "execute-api:Invoke",
      "Resource": [
        "arn:aws:execute-api:us-east-1:{account-id}:{api-id}/*/*/*"
      ]
    }
  ]
}

For more information, see How do I activate IAM authentication for API Gateway REST APIs?

HTTP APIs

The option to use resource policies to provide IAM authentication for cross-accounts 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.

For more information, see How can I provide cross-account IAM authorization for API Gateway HTTP APIs?


Creating a private API in Amazon API Gateway

Example: Allow users in another AWS account to use an API

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Map status codes in API Gateway for HTTP APIs

How do I map the response status codes for API Gateway integrations in HTTP APIs?

Last updated: 2022-09-30

What are the differences between payload versions 1.0 and 2.0?

How do I map the status codes returned by HTTP APIs in Amazon API Gateway?

-or-

How do I map the status codes in HTTP APIs?

Resolution

When you want to override your backend response status codes, use API Gateway mapping templates or regular expressions to map the status codes. You can do this in proxy and non-proxy integrations with HTTP API.

Working with HTTP APIs

HTTP APIs are different in design when compared to REST APIs. HTTP APIs are integrated by default proxy and return the same response. Unlike REST APIs, HTTP APIs provide two payload format versions to use with Lambda integration. For the 1.0 and 2.0 payload format versions, there are associated Lambda function response formats.

When the payload format version 2.0 is used, if the Lambda function doesn’t explicitly pass the status code in a valid JSON response, API Gateway assumes the following:

  • IsBase64Encoded is false
  • statusCode is 200
  • content-type is application/json
  • body is the response from a Lambda function

In the previous example, the HTTP API doesn’t return any errors, but forwards the assumed status code 200.

When the payload format version 1.0 is used, the Lambda integration must return a response in the following format. API Gateway doesn’t make assumptions of the response and returns a 500 error.

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

Mapping status codes

To map the status code to a static value basing on the returned back-end response key:

  1. Navigate to the integrations configured in HTTP API.
  2. Choose the Integration route to modify. Choose Manage Integration . Scroll to the parameter mapping, and then choose Create parameter mapping .
  3. Set Mapping type to Response (based on a status code) . Also set Response status code because the integration responses that match this status code must have parameter mapping applied.
  4. Choose Add new mapping .
  5. Under Parameter to modify , choose statusCode . Set the Modification type to Overwrite .
  6. Set Value to Static value .
    Note : This value needs to be sent to the client.
  7. Choose Create .

Working with models and mapping templates

Transforming API requests and responses

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article
Map status codes in API Gateway for REST APIs

How do I map the response status codes for API Gateway integrations in REST APIs?

Last updated: 2022-09-30

Why is AWS Lambda returning 200 OK status code responses in REST APIs?

How do I map the status codes returned by REST APIs in Amazon API Gateway?

-or-

How do I map status codes in REST APIs?

Resolution

When you want to override your backend response status codes, use API Gateway mapping templates or regular expressions to map the status codes. You can do this in proxy and non-proxy integrations with REST API.

Proxy and non-proxy integrations are used to map response status codes in REST API. When there’s a proxy response, API Gateway receives the status codes as they’re sent by the backend. In a Lambda proxy integration, API Gateway requires the backend Lambda function to return the following output in JSON format:

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

In a proxy integration with a Lambda function, a status code is passed directly to API Gateway from a backend Lambda function. A status code can’t be passed directly from the Lambda function in a non-proxy integration.

When API Gateway successfully invokes a Lambda function, the default response status code is 200. Status codes are also returned when Lambda experiences errors. You can customize API Gateway response codes. Use a non-proxy integration and a mapping template when you need to create a custom response code.

Configuring a response method with custom code

Follow these steps to configure a method to respond with custom response code from API Gateway:

1.    In the API Gateway console, create a public REST API.

2.    Create a resource and a method for the resource.

3.    Set up a method response that includes the status code that you want API Gateway to return.

4.    Configure a Lambda integration response.

  • For Lambda Error Regex , provide the regular expression pattern for the error message that's returned by the Lambda function.
    Note : You can also find the HTTP error regex for HTTP responses.
  • For the method response status, provide the status code that must be returned by API Gateway.
  • Choose an option for Content Handling to set how the response body is handled before the response is sent to the client.
  • Make sure that the default pattern of the status code is set to 200.

5.    After you finish configuring your integration response, save, test, and deploy your changes.

Mapping status codes to static values

For API Gateway to capture a group of status codes returned from your backend, map the status codes to static values:

1.    Go to the resource that has the status code you want to change.

2.    Set up a method response to return 400 as the API Gateway response code.

3.    Go back to the resource configurations and set up an integration response.

4.    The values in HTTP status regex capture the status returned by your backend. The status is then mapped to the response code defined in Step 2.

When HTTP status regex has a default value of "-" and is mapped to 200 as the method response status, all status codes are captured and returned by your backend map to 200. You can change the HTTP status regex values to 2\d{2} to capture all 2xx responses and map them to 200.

5.    Choose Add integration response to capture the other status codes.

For 4xx, in HTTP status regex , add 4\d{2} . For Method response status , choose 400 . This was defined in Step 2.

6.    Deploy your API. When the API returns any 2xx status codes, they're mapped to the 200 status code. If your API returns any 4xx status codes, they’re mapped to the 400 status code.

Regular expressions can be formatted in multiple ways. For example:

  • .*([01][0-9][0-9]|2[0-4][0-9]|25[0-5]).* matches for status codes between 100-199, 200-249, or 250-255.
  • .*5\d\d.* matches a status code , such as 5xx.

The following example code is for testing a Lambda function:

def lambda_handler(event, context):
    if "error" not in event or event['error'] == "":
        return("Pass")
    elif event['error'] == 'sample 400':
        raise Exception({"errorMessage": "Error: Raising 400 from within the Lambda function","errorType": "Exception"})
    elif event['error'] == 'sample 500':
        raise Exception({"errorMessage": "Error: Raising 500 from within the Lambda function","errorType": "Exception"})
    else:
        return("Error Value in the json request should either be 400 or 500 to demonstrate")

In the example, the code checks if the error value sent from API Gateway is a 400 or 500 error. When it’s a 400 or 500 error, the Lambda code raises an exception with an error message. When API Gateway receives the response, the service checks if the error message matches any pattern configured in the integration response. API Gateway responds accordingly if the Lambda regex pattern is matched.

7.    After a successful configuration, the status codes can be tested using the API Gateway console.

Mapping status codes with mapping templates

The previous example uses regular expressions, but it can also use mapping templates. The following example overrides the 200 status code from the backend to apply the 400 status code:

1.    Create a Lambda function with following example code:

----------------------
def lambda_handler(event, context):
    # TODO implement print(event)
    return { 'statusCode': 200, 'body': "customerror" }
-----------------------

2.    Create an API with Lambda non-proxy integration by using the previous Lambda function for the backend.

3.    Follow steps 6-10 described in the Override an API's response status code with the API Gateway console tutorial.

In this example, use the following mapping template:

----------------------
#set($inputRoot = $input.path('$'))
$input.json("$")
#if($inputRoot.toString().contains("customerror"))
#set($context.responseOverride.status = 400)
#end 
----------------------

4.    Save, test, and deploy the API.


Working with models and mapping templates

Transforming API requests and responses

Amazon API Gateway Developer Guide

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article