Blog
Token
About Us
AiDOOS Wiki
Project Cost Estimation

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
CRM
Salesforce
ERP
SAP
Storage and Backups
Purestorage Netapp Nutanix
Cloud
AWS
Computing
IBM
Database
MongoDB MySQL PostgreSQL
DevOps
Docker Kubernetes Jenkins GitLab
Mobile
React Native Android
Web
React Angular PHP
Programming
Python
Products
CNC Software (Mastercam) 3D perception 7shifts

Cloud-AWS

Resolve "HTTP 403 Forbidden" errors when invoking API Gateway with an IAM cross-account

How can I resolve "HTTP 403 Forbidden" errors when invoking my API with cross-account IAM authentication for API Gateway?

Last updated: 2022-09-16

I called my Amazon API Gateway API with a cross-account AWS Identity and Access Management (IAM) entity (user or role). I get an "HTTP 403 Forbidden" error. How do I troubleshoot this?

Resolution

REST APIs

For accessing API Gateway REST APIs, turn on IAM authentication for an API method in the API Gateway console. Then, use IAM policies and resource policies to designate permissions for your API's users.

Make sure that the cross-account IAM entity has permissions to invoke the API and is allowed access in the resource policy.

In this example, the REST API for account A 111111111 has IAM authentication enabled. User1 tries to invoke from account B 999999999. User1 in account B has the following IAM policy attached: 

}
  ]
    }
      "Resource": "arn:aws:execute-api:us-east-1:111111111:AB12CDEF34/*/*/*"
      ],
        "execute-api:ManageConnections"
        "execute-api:Invoke",
      "Action": [
      "Effect": "Allow",
    {
  "Statement": [
  "Version": "2012-10-17",
{

To allow the IAM user for account B in account A to invoke cross-account access, use a resource policy similar to the following: 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999:user/User1"
      },
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:us-east-1:111111111:AB12CDEF34/stage/*/*"
    }
  ]
}

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

HTTP APIs

For accessing 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.

Make sure that the temporary security credentials used to invoke the HTTP API are correct and not expired.

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

API Gateway resource policy examples

Activate IAM authentication for API Gateway Rest APIs

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support

Resolve DNS or certificate mismatch errors for API Gateway custom domains

How can I resolve DNS resolution or SSL certificate mismatch errors for my API Gateway custom domain name?

Last updated: 2022-10-21

I configured a custom domain name for my Amazon API Gateway API. I am unable to connect to the domain name and receive DNS resolution or SSL certificate mismatch errors. How can I resolve this?

Short description

There are two types of custom domain names that you can create for API Gateway APIs: Regional or (for REST APIs only) edge-optimized.

Resolution

Before creating a custom domain name for your API, you must do one of the following:

Request an SSL/TLS certificate from AWS Certificate Manager (ACM).
-or-
Import an SSL/TLS certificate into ACM.

For more information, see Getting certificates ready in AWS Certificate Manager.

After you have your SSL/TLS certificate, you can follow the instructions to set up a custom domain name for my API Gateway API.

To connect to a custom domain name for API Gateway APIs, you must configure Amazon Route 53 to route traffic to an API Gateway endpoint.

If the DNS records for the custom domain name aren't mapped to the correct API Gateway domain name, then the SSL connection fails. This is because the default *.execute-api.<region>.amazonaws.com certificate is returned instead of the SSL/TLS certificate.

To confirm that the DNS mapping is correct, run the following command from the client: 

$ nslookup <customdomainname>

The output should be the API Gateway domain name. Make sure that the domain name matches the API Gateway domain name. If a Route 53 alias record is used for DNS mapping, then the output is the IP address. Make sure that the IP address matches the API Gateway domain name IP address.

Note:

  • When configuring Route 53, you must create either a public hosted zone or a private hosted zone. For internet-facing applications with resources that you want to make available to users, choose a public hosted zone. For more information, see Working with hosted zones.
  • Route 53 uses records to determine where traffic is routed for your domain. Alias records provide easier DNS queries to AWS resources, while CNAME (non-alias) records can redirect DNS queries outside of AWS resources. For more information, see Choosing between alias and non-alias records.

Migrating a custom domain name to a different API endpoint

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article

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
Read article

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