3

I understand the AWS Lambda is a serverless concept wherein a piece of code can be triggered on some event.
I want to understand how does the Lambda handle scaling?
For eg. if my Lambda function sits inside a VPC subnet as it wants to access VPC resources, and that the subnet has a CIDR of 192.168.1.0/24, which would result in 251 available IPs after subtracting the AWS reserved 5 IPs

Would that mean if my AWS Lambda function gets 252 invocations at the exact same time,
Only 251 of the requests would be served and 1 would either timeout or will get executed once one of the 252 functions completes execution?
Does the Subnet size matter for the AWS Lambda scaling?

I am following this reference doc which mentions concurrent execution limits per region,
Can I assume that irrespective of whether an AWS Lambda function is No VPC or if it's inside a VPC subnet, it will scale as per mentioned limits in the doc? enter image description here

Dev1ce
  • 5,390
  • 17
  • 90
  • 150
  • .. the lambda functions may even have a single IP with your subnet.. the subnet size should net matter in fact – gusto2 Mar 10 '19 at 21:15

2 Answers2

2

Vladyslav's answer is still technically correct (Subnet size does matter), but things have changed significantly since it was written and subnet size is much less of a consideration. See aws' announcement:

  • Because the network interfaces are shared across execution environments, typically only a handful of network interfaces are required per function. Every unique security group:subnet combination across functions in your account requires a distinct network interface. If a combination is shared across multiple functions in your account, we reuse the same network interface across functions.
  • Your function scaling is no longer directly tied to the number of network interfaces and Hyperplane ENIs can scale to support large numbers of concurrent function executions
Federico
  • 1,636
  • 2
  • 22
  • 24
0

Yes, you are right. Subnet size definitely does matter, you have to be careful with your CIDR blocks. With that one last invocation (252nd), it depends on the way your lambda is invoked: synchronously (e.g. API Gateway) or asynchronously (e.g. SQS). If it is called synchronously, it'll be just throttled and your API will respond with 429 HTTP status, which stands for "too many requests". If it is asynchronous, it'll be throttled and will be retried within a six hour period window. More detailed description you can find on this page.

Also I recently published a post in my blog, which is related to your question. You may find it useful.

Vladyslav Usenko
  • 2,296
  • 8
  • 18
  • So if I select 2 subnets for the Lambda function, each subnet of 251 size, and if the function gets invoked via API Gateway, would that mean my new scaling size is 251+251= 502? – Dev1ce Mar 10 '19 at 21:17
  • Unless your subnets are not dedicated to lambda and there's something more (EC2 instances?) inside them, it should be 502. It's a good practice to put lambda in different subnets, because it becomes multi AZ, which is fault tolerant. – Vladyslav Usenko Mar 10 '19 at 21:21
  • 1
    Also, I have to mention that at ReInvent 2018 Mark Booger (lead engineer of AWS Lambda team) announced a solution for 2019 both for VPC cold starts and this ugly approach to calculate IP addresses: https://twitter.com/jeremy_daly/status/1068272580556087296 – Vladyslav Usenko Mar 10 '19 at 21:23
  • Ok so it putting the function under multiple subnets would make it HA and also help in scaling to the sum size of available private IPs of the subnets the function sits in combined? – Dev1ce Mar 10 '19 at 21:24
  • yeah, since VPC is not an actual data center in the cloud (like people call it), but rather a software defined network, we can leverage things like this – Vladyslav Usenko Mar 10 '19 at 21:28
  • @VladyslavUsenko your blog post calculation appears to be off by a factor of 10... 10500 * (0.125 / 3) = 4375 is not accurate... it's 437.5. Approaching from the opposite direction, a container host with 3 GiB of RAM can support 24 containers of 128 MiB each, so again 10500 ÷ 24 = 437.5. Additionally, you say "yes, you are right," but OP's assertion that 251 concurrency == 251 ENI is not correct, unless the container size for these invocations is 3 GiB. – Michael - sqlbot Mar 11 '19 at 02:35
  • @Michael-sqlbot always happy to stumble up on your comments, Michael! Thanks for the note, I'll check the post. Anyway, about lambda concurrency. So you're saying that it's not lambda, who's getting ENI attached, but a worker ec2 instance, on which lambda runs, therefore one ENI per one lambda only happens when lambda occupies all available RAM (which is 3 Gigs) of the instance? – Vladyslav Usenko Mar 11 '19 at 09:30
  • @Michael-sqlbot not sure if it's the right place to have this convo, since it's related to my post, but... the point of the post was not to calculate the formula, provided by AWS. the point was to estimate the amount of concurrent executions, given that each lambda runs for at least 10.5 seconds, consumes 128 mbs of RAM and there is load of 1K req/s. Lambdas, triggered by the first thousand of requests are not expected to finish before the second thousand roll in, since their execution time is more than 10 secs :) That's why I used Little's law. Kind of a long term calculation – Vladyslav Usenko Mar 11 '19 at 09:58
  • @VladyslavUsenko yes, the only seemingly plausible explanation for the appearance of the value of 3 GB as a constant in the formula used to estimate the number of ENIs based on concurrency is that it's [related to the packing of containers onto instances](https://stackoverflow.com/a/54768505/1695906), where all the containers on a given instance use the same ENI to interact with the VPC. 251 available addresses can support a concurrency of approximately 6024, at 128MB, based on the published formula. – Michael - sqlbot Mar 11 '19 at 16:24