In most of the official documents to express throttling limits, AWS uses metrics like Requests per second or Requests per client. e.g. here. But for AWS IOT API throttling limit, there are using a metric called Transactions per seconds. Is there an actual difference between "Transactions per Second" and "Requests per second" metrics or they are just the same?
They mean the same thing — the rate in which you're allowed to call the API. It seems there's no standard for this term; it's chosen at the discretion of the writers. Some services only state a plain number, i.e. 1000, others use requests, and a few use transactions.
Related
According to the docs,
the X-Ray SDK applies a sampling algorithm to determine which requests get traced. By default, the X-Ray SDK records the first request each second, and five percent of any additional requests.
Is it possible to trace all requests?
It is possible to set the sampling rate to 100%.
However, as noted in the FAQs:
X-Ray should not be used as an audit or compliance tool because it does not guarantee data completeness.
I am uploading photos to Google Photos and placing them in Albums via the Photos Library API.
Every now and then, I get an error "Quota exceeded for quota metric 'Write requests' and limit 'Write requests per minute per user' of service 'photoslibrary.googleapis.com' for consumer 'project_number:XXXXXXX'.
The documentation states 10,000 requests per project per day. But then it says In addition to these limits there are other quotas that exist to protect the reliability and integrity of our systems. I am assuming it's referring to the "per minute per user" that I am receiving.
So what is the actual limit? How many times can I call the API per minute?
P.S. There is a API quote page for Google Sheets API, which states that the limit is 60 requests per minute. Does that limit also apply to other Google APIs?
P.P.S. There is a similar question from 2018, but the issue was too much bandwidth - doesn't apply to my situation.
We need to have an endpoint to receive http POST requests and send them to SQS with both headers and payload. API Gateway with REGIONAL type and SQS integration works great and satisfies our needs. However, we are slightly worried about the limits of 600 requests per second as it might not be enough for our case. Do we correctly understand that API Gateway HTTP API (that is not REST API with REGIONAL or EDGE types) can receive 10.000 requests per second, but in this case we would need to "build" our own integration to SQS (e.g. using lambdas)?
A bit late, but I believe there is a quota of 600 regional APIs (not request rate) per region. That mean, you can create 600 APIs, each of them with up to 10k requests per second. The quota 10k requests per second is, however, shared across these APIs, so if you have 100 APIs, each of them can receive can, in average, receive 1k requests per second. However, if 99 of them sit idle, the one API can get 10k requests per second.
from the docs
Lambda automatically scales up the number of instances of your function to handle high numbers of events.
What I understood is, if there are 10 incoming requests for a particular lambda function, then 10 instances of that runtime(lets say nodejs) will be launched.
Now, my questions:
What is the maximum number of instances that lambda allows ? (looked into docs but didn't found this)
Since there would be some maximum cap what is the fallback if that number is reached ?
The default account number is 1000, but this is a soft limit and can be increased.
Concurrency in Lambda actually works similarly to the magical pizza
model. Each AWS Account has an overall AccountLimit value that is
fixed at any point in time, but can be easily increased as needed,
just like the count of slices in the pizza. As of May 2017, the
default limit is 1000 “slices” of concurrency per AWS Region.
You can check this limit under Concurrency inside your Lambda function, just like the image below:
You can use services with some retry logic already built-in to in order to decouple your applications (think of SQS, SNS, Kinesis, etc). If the Lambda requests are all HTTP(S) though, then you will get 429 (Too Many Requests) HTTP responses and the requests will be lost.
You can see Lambda's default retry behaviour here
I'm running a business API on AWS, through API Gateway and Lambda.
Currently, I handle rate limiting with the built in usage plans and api keys.
Each account tier (think basic, medium, premium) is associated to a usage plan, to which each customer's api key is linked.
I just found out that there is a hard (but increasable) limit of 500 api keys that a single AWS account can have per region (https://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/limits.html).
Is it sustainable to rely on api keys to rate limit each customer ? We will get to the 500 limit eventually. Are there other solutions we could use ?
Thanks a lot
If you read the table carefully you will notice that the last column has a header "Can Be Increased" and value "Yes" for "Maximum number of API keys per account per region".
Just contact support once you will be getting close to your limit and ask for an increase. It may take up to 2-3 work days, but otherwise it should be only a matter of asking.