I've been using CloudWatch to track metrics against API Gateway and Lambda, and it shows throttled calls for Lambda, but is there any way to see the number of calls that are throttled earlier by API Gateway?
Not yet, but we are planning on addressing this in the near future. Can't provide an ETA. But it would be similar to Lambda in that there will be a metric counter for throttled requests.
You could setup CloudWatch alerts with SNS notifications to receive info about throttled request. Another way could be tracking the throttled HTTP 429 status on the client.
Related
The api gateway url is triggered/called by a form submit. Now, as this is a synchronous invocation, how do I handle a lambda retries and handle throttles?
Note: I am deploying api gateway along with lambda and use the url generated as webhook for form submit. So basically, it would be a one-way communication.
Flow:
form(payload)-> (api gateway)-> lambda-> lambda-> sqs-> lambda-> dynamoDb
There won't be an automatic Lambda retry when it's invoked from API Gateway afaik. If you are throttled or the request fails (perhaps because of a Lambda function error), your client is responsible for deciding how to recover and whether or not to retry, likely based on the HTTP response code.
Also worth reading:
A Detailed Overview of AWS API Gateway
How AWS Lambda Retry really works
For those requests excess the limit and get the response: 429 too many requests, will those requests still charge me?
In this question,t he throttling limit is the limit from the API gateway itself, no other limit.
It depends.
If you reached the limit for your usage plan and the API Gateway throttles you, there would be no additional costs. Although, this kind of throttling may not be as accurate as you would expect, see this question: AWS API Gateway Throttling not working as expected.
If your backend integration throws a 429 (for example, you reached some kind of Lambda limit), than your request will be charged on the API Gateway.
I have an API Gateway invoking an AWS Lambda which sends Text messages.
In case of an accident or an attack, I would like to limit the max invocations per hour to mitigate the cost of an infinite loop for example.
What is the easiest way to do that ? I can't see such options in AWS Lambda, SQS or event Cloudwatch Alarm
API Gateway supports rate limiting. You can set limits for individual API stages or methods and you can enable usage plans to restrict client request submissions to within specified request rates and quotas.
In addition, per the API Gateway FAQ:
API Gateway automatically protects your backend systems from distributed denial-of-service (DDoS) attacks, whether attacked with counterfeit requests (Layer 7) or SYN floods (Layer 3).
And, finally, be aware of Protecting API Endpoints guidance.
As it currently stands AWS SNS provides functionality for retrial(Linear, Geometric and Exponential backoff) with HTTP/HTTPS endpoints in case of a 5XX response returned from the endpoint.
Because of this my application architecture changes and I forcefully need to insert a API gateway between my SNS and Lambda so that in case of a failure I can return a 5XX status from the API gateway and utilise the retrial functionality of SNS.
But there is nothing mentioned for retrial mechanism with AWS lambda. Is there any way I can use the SNS retrial facilities for non-HTTP based subscriptions?
Thanks
After a couple of hours of debugging and going through AWS documentation it seems that there is currently no way of getting exponential back of from AWS SNS for anything else apart from HTTP/HTTPS sources.
You can checkout the this.
As quoted in the documentation:
When a user calls the SNS Publish API on a topic that your Lambda
function is subscribed to, Amazon SNS will call Lambda to invoke your
function asynchronously. Lambda will then return a delivery status. If
there was an error calling Lambda, Amazon SNS will retry invoking the
Lambda function up to three times. After three tries, if Amazon SNS
still could not successfully invoke the Lambda function, then Amazon
SNS will send a delivery status failure message to CloudWatch.
Since there is a async invocation of the Lambda SNS will not care what the exit status of the lambda is. Hence, from the point of view of SNS, a successful invocation of the lambda is success enough and will not provide a failure event, hence no customised back off.
For now it seems, adding an HTTP endpoint is the only option.
I have been experimenting with AWS API Gateway and AWS Lambda to try out a serverless architecture. Have been going through blogs and AWS documentation. Have tried out sample GET/POST. But, I have the following requirement w.r.t tracking user events from my custom application
Events are posted from my application to API end point
I wanted the API to respond back with a custom response (Say {'fine'})
(acknowledging that the request has been received)
After the response is sent, hand over the event payload to a AWS Lambda function
As per the documentation, I understand,
a) I can post events to API end point
b) On GET/POST trigger an AWS Lambda Function
- Respond back from AWS Lambda function to API request
I wanted to change the above and modify it to
a) Post events to API end point
a.0) Respond back acknowledging that request is received [Say {'fine'} ]
b) Trigger AWS Lambda function to process the event payload
Please share across suggestions on how to achieve the same.
Another asynchronous model many customers have used:
Set up an API configured to send requests to Amazon Kinesis. This API could acknowledge the request.
Set up AWS Lambda to consume your Kinesis stream.
This setup has some advantages for high workload APIs as fetches from the Kinesis stream can be batched and don't require a 1-to-1 scaling of both your API Gateway limits and Lambda limits.
Update
To answer your questions about scalability:
Kinesis
Kinesis scales by adding what it calls "shards" to the stream. Each shard handles a portion of your traffic, based on a partition key. Each shard scales up to 1000 rps or 1MBps (see limits). Even with the lower default 25 shards, this would support up to 25,000 rps or 25MBps with an evenly distributed partition key.
API Gateway
API Gateway has a default account level limit of 500 rps, but this can easily be extended by requesting a limit increase. We have customers in production that are using the service at limits above your current suggested scale.
If you want a fast response from the API and not have to wait for the processing of data, you could:
post an event to an API Gateway endpoint
trigger an AWS Lambda Function A
call asynchronously a Lambda Function B using the AWS SDK in the Lambda Function A
Call context.succeed() or context.done() or the callback function in the Lambda Function A so it respond back to API Gateway
the Lambda Function B can process the data while API Gateway already received a response
You should first run some tests to see what type of real world response times you are getting from having your lambda function complete all the logic. If the times are above what you feel are acceptable for your use case, here is another asynchronous solution utilizing an SNS Topic to trigger a secondary Lambda function.
Client Request to API Gateway -> Calls Lambda function A
Lambda A verifies payload and then publishes to SNS Topic X
Lambda A returns {fine} success message -> API Gateway -> client
SNS Topic X triggers Lambda function B
Lambda function B implements given logic