-
Epic
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
AWS throttling
-
0% To Do, 0% In Progress, 100% Done
-
False
Goal:
- Make sure we handle AWS throttling well and not allow few consecutive request of one customer to slow down experience for all.
- Protect customers from hitting their quota too fast by throttling requests on our side.
Acceptance Criteria:
- Many requests from single customer does not exceed all the quota for STS api calls AWS throtteling for all the customers
- Single customer is protected for not exceeding their EC2 quota too fast
Open questions:
- Do we need to care also about EC2 throttling?
Description
AWS EC2 API limits are strict, we want to disallow customers to hit our endpoint too often. Let’s limit this to 2 reservations per second per account per hyperscaler.
Use something like https://github.com/throttled/throttled or similar project that can be applied per Chi route (only for ReservationCreate path) and per path (/reservation/TYPE/) and which uses Redis as the backend for storing data. Account can be taken from HTTP header even if it is not ideal (its base64 encoded JSON so it can vary).
This feature must be runtime-switchable via unleash flag in case we want to conduct performance testing at any time.
- relates to
-
HMS-1782 AWS client does not keep up with job queue concurrency
-
- Closed
-