Welcome to Knowledge Base!

KB at your finger tips

Book a Meeting to Avail the Services of AWS overtime

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

Categories
All

AWS

Troubleshoot API Gateway"429 Too Many Requests" or "Limit Exceeded" errors

How can I troubleshoot "429 Too Many Requests" or "Limit Exceeded" errors for my API Gateway API?

Last updated: 2022-09-26

I received "429 Too Many Requests" or "Limit Exceeded" errors when sending requests to my Amazon API Gateway API. How do I troubleshoot these errors?

Short description

API Gateway has account-level quotas, per Region. The throttle quota is 10,000 requests per second (RPS) with an additional burst capacity provided by the token bucket algorithm. The maximum bucket capacity is 5,000 requests per account and Region. API Gateway throttling-related settings are applied in the following order:

  • Per-client or per-method throttling limits that you set for an API stage in a usage plan.
  • Per-method throttling limits that you set for an API stage.
  • Account-level throttling per Region.
  • AWS Regional throttling.

Exceeding the throttling limit or quota returns a "429 Too Many Requests" or "Limit Exceeded" error response.

For more information, see How throttling limit settings are applied in API Gateway.

Resolution

Before you begin, make sure that you have followed the instructions to turn on Amazon CloudWatch Logs for troubleshooting API Gateway. Make sure that you choose ERROR to generate execution logs only for requests to your API that result in an error. Then, view logged API requests and responses using the CloudWatch console.

"429 Too Many Requests" error

Check the rate or burst limit for per-client or per-method throttling limits that you set for the API stage for your usage plan. When the rate or burst limits are exceeded, CloudWatch execution logs an exceeded throttle limit error similar to the following:

(f277a0b4-2bcd-41b3-8e43-4de770663ffb) API Key 
**********************************
F0yrv6 exceeded throttle limit for API
 Stage rohkz08x02/dev: Key throttle limit exceeded for Usage Plan ID 
nnpegc, RestApi rohkz08x02, Stage dev, Resource f646q2, HttpMethod GET. 
Limit: 5.00 Burst: 10

To resolve this error, use retries and an exponential backoff algorithm with jitter, and then resubmit your API request.

For more information, see exponential backoff and jitter.

"Limit Exceeded" error

This error might indicate that the quota limit is exceeded for your API Gateway usage plan. When the quota limit is exceeded, then CloudWatch execution logs an exceeded quota limit error similar to the following:

(7b819c41-e0a0-433a-883e-bc461fd70fd6) API Key 
**********************************
F0yrv6 exceeded quota limit for API 
Stage rohkz08x02/dev: Key quota exhausted for Usage Plan ID nnpegc. Q
Limit: 500 Period: DAY

To resolve this error, follow the instructions to extend the remaining quota.


How do I troubleshoot Lambda function throttling with "Rate exceeded" and 429 "TooManyRequestsException" errors?

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

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support

Stay Ahead in Today’s Competitive Market!
Unlock your company’s full potential with a Virtual Delivery Center (VDC). Gain specialized expertise, drive seamless operations, and scale effortlessly for long-term success.

Book a Meeting to Avail the Services of AWSovertime

Set up API Gateway access logging

How can I set up access logging for API Gateway?

Last updated: 2022-08-15

I'm trying to set up access logging for Amazon API Gateway. How can I do this?

Short description

To debug issues related to request execution or client access to your API, you can activate Amazon CloudWatch Logs to log API calls.

Resolution

Before you begin, make sure that you have:

  • Deployed your API to a stage.
  • Granted API Gateway permission to read and write logs to CloudWatch for your account.

Next, to activate access logging follow steps 1-5 and 7-8 (skip step 6) in the instructions for setting up CloudWatch API logging using the API Gateway console.

Note: It's a best practice not to log the full API requests and responses for production APIs. Full API requests and responses can result in logging sensitive data.

You now have CloudWatch logs activated for debugging. To find errors, see How do I find API Gateway REST API errors in my CloudWatch logs?

For more information, see Monitoring REST API execution with Amazon CloudWatch metrics.


How do I troubleshoot "Invalid permissions on Lambda function" errors from API Gateway REST APIs?

How do I find 5xx errors from API Gateway in my CloudWatch logs?

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

Resolve certificate expired or "invalid certificate" errors for API Gateway API custom domains

How can I resolve certificate expired or "invalid certificate" errors when invoking an API Gateway API using a custom domain name?

Last updated: 2022-09-23

I set up a custom domain name for my API Gateway API. I received an error that the AWS Certificate Manager (ACM) certificate is expired or "invalid certificate". How can I resolve this error?

Short description

The certificate has expired error occurs when the certificate used for creating the custom domain name is expired.

The "invalid certificate error" occurs because of a mismatched common name (CN) or subject name in the certificate.

Resolution

Expired ACM certificates

If your certificate is expired, you might receive an error similar to the following:

"SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]"
To check the certificate expiry, run the OpenSSL command s_client similar to the following:

openssl s_client -servername <custom domain name> -connect <custom domain name>:443 2>/dev/null | openssl x509 -noout -dates

To renew the certificate, see Managed renewal for ACM certificates.

To avoid expired certificates, see How to monitor expirations of imported certificates in ACM.

Mismatched ACM certificates

If your certificate has a mismached CN or subject name, you might receive an error similar to the following:

"ERR_CERT_COMMON_NAME_INVALID"

Confirm the following settings:

  • The certificate used to create the custom domain name exists in ACM.
  • The certificate subject name or CN includes the custom domain name. For example, if the custom domain name is custom.example.com, then the subject name or CN must include custom.example.com or *example.com.
  • Make sure that there is a DNS record pointing to the API Gateway custom domain name. The DNS record can be either a CNAME or A type.

Note: Custom domain names can't point directly to the execute-api endpoint because the certificate doesn't have the custom domain listed as the Subject Alternative Name (SAN).

Example configuration:

custom.example.com -> CNAME record -> d-yg54udirl4.execute-api.us-east-1.amazonaws.com

You can check your configuration by running the dig command on your custom domain similar to the following:

$ dig custom.example.com

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

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article

Troubleshoot SigV4 signature mismatch errors with IAM authentication for API Gateway

How can I troubleshoot signature mismatch errors when making SigV4 signed requests with IAM authentication to API Gateway?

Last updated: 2022-09-22

The Signature Version 4 (SigV4) signed request to Amazon API Gateway failed with a 403 response and an error similar to the following:

"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method."

How can I troubleshoot this?

Short description

API Gateway API endpoints using AWS Identity and Access Management (IAM) authentication might return 403 errors if:

  • The API request isn't signed and the API request uses IAM authentication.
  • The IAM credentials used to sign the request are incorrect or don't have permissions to invoke the API.
  • The signature of the signed API request doesn't match the signature for the API Gateway API endpoint.
  • The API request header is incorrect.

Resolution

IAM authentication

Make sure that the API request using IAM authentication is signed with SigV4. If the API request isn't signed, then you might receive the following error: “Missing Authentication Token”

IAM credentials

Verify that the authentication credentials for the access key and secret key are correct. If the access key is incorrect, then you might receive the following error: "The security token included in the request is invalid."

Make sure that the IAM entity used to sign the request has execute-api:Invoke permissions. If the IAM entity doesn't have execute-api:Invoke permissions, then you might receive the following error: "User: arn:aws:iam::xxxxxxxxxxxx:user/username is not authorized to perform: execute-api:Invoke on resource"

Signature mismatch

If the secret access key is incorrect, then you might receive the following error: "The request signature we calculated does not match the signature you provided."

The secret access key must match the access key ID in the Credential parameter. For instructions, follow the Send a request to test the authentication settings section in How do I activate IAM authentication for API Gateway REST APIs?

Make sure that you followed the instructions for the SigV4 signing process. If any values in the signature calculation are incorrect, then you might receive the following error: "The request signature we calculated does not match the signature you provided."

When API Gateway receives a signed request, it recalculates the signature. If there are differences in the values, then API Gateway gets a different signature. Compare the canonical request and string to your signed request with the value in the error message. Modify the signing process if there are any differences.

Example canonical request:

GET                                                      -------- HTTP method
/                                                        -------- Path. For API stage endpoint, it should be /{stage-name}/{resource-path}
                                                         -------- Query string key-value pair. Leave it blank if the request doesn't have any query string
content-type:application/json                            -------- header key-value pair. One header per line
host:0123456789.execute-api.us-east-1.amazonaws.com      -------- host and x-amz-data are required headers for all signed request                       
x-amz-date:20220806T024003Z                              

content-type;host;x-amz-date                             -------- A list of signed headers
d167e99c53f15b0c105101d468ae35a3dc9187839ca081095e340f3649a04501        -------- hash of the payload

Example canonical error response:

<ErrorResponse xmlns="https://iam.amazonaws.com/doc/2010-05-08/">
  <Error>
    <Type>Sender</Type>
    <Code>SignatureDoesNotMatch</Code>
    <Message>The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The canonical string for this request should have been 'GET / Action=ListGroupsForUser&MaxItems=100&UserName=Test&Version=2010-05-08&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential
=AKIAIOSFODNN7EXAMPLE%2F20120223%2Fus-east-1%2Fiam%2Faws4_request&X-Amz-Date=20120223T063000Z&X-Amz-SignedHeaders=host
host:iam.amazonaws.com

host
<hashed-value>'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20120223T063000Z
20120223/us-east-1/iam/aws4_request
<hashed-value>'
</Message>
  </Error>
  <RequestId>4ced6e96-5de8-11e1-aa78-a56908bdf8eb</RequestId>
</ErrorResponse>

Note: For API gateway headers, only the host and x-amz-date headers are required.

API request header

Make sure that the SigV4 authorization header includes the correct credential key similar to the following:

Authorization: AWS4-HMAC-SHA256 
Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, 
SignedHeaders=host;range;x-amz-date,
Signature=example-generated-signature

If the credential key is missing or incorrect, you might receive the following error: “Authorization header requires 'Credential' parameter. Authorization header requires 'Signature' parameter."

Make sure that the SigV4 authorization request also includes the request date using either HTTP Date or the x-amz-date header.

For more information, see Troubleshooting key signing errors and Troubleshooting AWS Signature Version 4 errors.


Examples of the complete Signature Version 4 signing process (Python)

How do I troubleshoot HTTP 403 errors from API Gateway?

Signing AWS requests with Signature Version 4

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article

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

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