The only problem with lambda authorizer is that when rate limit rule is applied and request is throttled in response we get unauthorized/forbidden response which does not tell us that we were throttled. Maybe it's okay in some cases but it would be better if we could return proper 429 HTTP status code to indicate that we are making to many requests and also provide proper rate limiting headers. We can allow reqeust from authorizer and include some kind of meta info in authorizer context and then handle it in lambda and throttle request from there. but stilll it sounds not so good (((((
Again a great video on mastering kubernetes. It makes a lot of sense to continue, we are going at a very good pace for someone wanting to learn kubernetes.
1. how what is actually returned by the lambda? Is there an expectation from the gateway to have the lambda return the api key 2. How does this solution prevent the noisy neighbor, because even though the client has golden badge his excessive request will affect others?
For 1. I don't think so lambda has to return api key. Same token can be used to access api's for further requests. The token can be jwt token. So lambda will return the status. If the status is 401, means unauthorized.
You can limit the number of concurrently running instances of lambdas for your AWS account, so that it doesn't go that high. But I agree, that if that number is reached due to e.g. DDoS attack, then regular users won't be able to access this flow either.
This is in the context of multi-tenant architecture, the point is to limit the number of requests for each tenant (group of users), depending on their tier (paid tenants get to perform more requests per second). API Gateway distinguishes these tenants by their clientID. You don't need different clientIDs, if you want to limit requests per second uniformly for all users, regardless of their status in your system.
Excellent work. Hats off to you.
Thank you for this tutorial! I'm a newbie to AWS and your videos really help me better understand the flow of the design process! Cheers!!
It would be great to have a deep dive video into the new AuthZ AWS solution: Verified Permissions!
The only problem with lambda authorizer is that when rate limit rule is applied and request is throttled in response we get unauthorized/forbidden response which does not tell us that we were throttled. Maybe it's okay in some cases but it would be better if we could return proper 429 HTTP status code to indicate that we are making to many requests and also provide proper rate limiting headers.
We can allow reqeust from authorizer and include some kind of meta info in authorizer context and then handle it in lambda and throttle request from there. but stilll it sounds not so good (((((
Great video… thank you for sharing 👌🏻
Again a great video on mastering kubernetes.
It makes a lot of sense to continue, we are going at a very good pace for someone wanting to learn kubernetes.
Hey can you please tell me what program you used to create your diagrams?
1. how what is actually returned by the lambda? Is there an expectation from the gateway to have the lambda return the api key
2. How does this solution prevent the noisy neighbor, because even though the client has golden badge his excessive request will affect others?
For 1. I don't think so lambda has to return api key. Same token can be used to access api's for further requests. The token can be jwt token.
So lambda will return the status. If the status is 401, means unauthorized.
If there are thousands of requests, won't we run out of lambda authorizers? There are only 1k of lambda concurrent invocations.
You can limit the number of concurrently running instances of lambdas for your AWS account, so that it doesn't go that high. But I agree, that if that number is reached due to e.g. DDoS attack, then regular users won't be able to access this flow either.
Can someone please explain me why can't we just use one id( the tenantId or the cID) ?
I think we can but it depends on the API gateway implementation. Some expect the key in a custom header.
I guess multiple tenant id can map to one CId
This is in the context of multi-tenant architecture, the point is to limit the number of requests for each tenant (group of users), depending on their tier (paid tenants get to perform more requests per second). API Gateway distinguishes these tenants by their clientID.
You don't need different clientIDs, if you want to limit requests per second uniformly for all users, regardless of their status in your system.
@@ildar5184 the question was why the need for clientid AND tenantid.
bro is using ai for his face video
this ai face video gives weird vibez
its not ai