41–50 of 74 posts
AWS 2014: "Run your work loads on serverless so you don't have to deal with those pesky EC2 instances 24/7 anymore."
AWS 2019: "Click a checkbox and you can have your serverless workloads get dedicated EC2 instances 24/7!"
Am I misunderstanding something here? Based on the AWS calculations on the Lambda pricing page, a single 256Mb Lambda would incur a cost of $2.7902232 per month, using "provisionedConcurrency: 1". Pushing it to 3008Mb, to get access to more processing power, makes that go up to $32.78 per month (EU London region). Compared to the standard way of warming it up by hitting the endpoint once every 5 minutes, which comes…
Pinging the lambda to keep it warm doesn’t do the same thing. When you do that, it only keeps one instance warm. If you have 10 concurrent requests, even if one is warm, the other 9 requests will still experience a cold start. The only way around this is to send a request that holds the connection open long enough to make sure concurrent requests start a new lambda instance. While you are keeping the request open, th…
Earlier quoted context omitted.
How do you ensure that the 500 concurrent keep-alives land on different Lambda functions? I.e. requests 220 and onwards might hit lambda functions which were warmed up by requests 0-219. I just made the above numbers up of course.
That's why I mentioned 'with maybe some overhead'. You can also have the keep-alive handling take a second or 2 extra to complete, to have the lambda blocked for this time, so the burst calls get more spread. It's not going to be a precise solution, but still, paying 2-3 seconds every minute instead of paying the whole minute is still a lot cheaper.
Provisioned: 500 * 86400 (sec/day) * 0.000004167 ~= $180
Keep-alive: 500 * 1440 (min/day) * 2 (sec. runtime) * 0.000016667 (100ms price) * 10 ~= $240
Invocation costs on the provisioned ones would be a lot cheaper too cheaper too. Roughly $45 provisioned vs $80 for 50M calls.
So depending on the demands, provisioning can be more performant, and cheaper at the same time.
At least if you build APIs, you can use VTL and avoid Lambda and its cold starts completely
Am I misunderstanding something here? Based on the AWS calculations on the Lambda pricing page, a single 256Mb Lambda would incur a cost of $2.7902232 per month, using "provisionedConcurrency: 1". Pushing it to 3008Mb, to get access to more processing power, makes that go up to $32.78 per month (EU London region). Compared to the standard way of warming it up by hitting the endpoint once every 5 minutes, which comes…
Pinging the lambda to keep it warm doesn’t do the same thing. When you do that, it only keeps one instance warm. If you have 10 concurrent requests, even if one is warm, the other 9 requests will still experience a cold start. The only way around this is to send a request that holds the connection open long enough to make sure concurrent requests start a new lambda instance. While you are keeping the request open, th…
AWS 2006: "Run your workloads on our EC2 instances in the cloud 24/7." AWS 2014: "Run your work loads on serverless so you don't have to deal with those pesky EC2 instances 24/7 anymore." AWS 2019: "Click a checkbox and you can have your serverless workloads get dedicated EC2 instances 24/7!"
"Click a checkbox and we'll run your code for you, take care of OS security updates, compliance requirements, autoscaling, load balancing, AZ resiliency, getting logs of your box, restarting unhealthy processes, ..."
Provisioned Concurrency (PC) is an interesting feature for us as we've gotten so much feedback over the years about the pain point of the service over head leading to your code execution (the cold start). With PC we basically end up removing most of that service overhead by pre-spinning up execution environments.
This feature is really for folks with interactive, super latency sensitive workloads. This will bring any overhead from our side down to sub 100ms. Realistically not every workload needs this, so don't feel like you need this to have well performing functions. There are still a lot of thing you need to do in your code as well as knobs like memory which impact function perf.
- Chris Munns - https://twitter.com/chrismunns
With Fargate Savings Plans and Spot Instances, the cost of running workloads on Fargate is getting substantially cheaper, and with the exception of extremely bursty workloads, much more consistently performant vs Lambda. The cost of provisioning Lambda capacity as well as paying for the compute time on that capacity means Fargate is even more appealing for high volume workloads. The new pricing page for lambda ("Exam…
Hey all, I lead developer advocacy for serverless at AWS and was part of this product launch since we started thinking about it(quite some time ago I should say). I'm running around re:Invent this week, but will try and pop in and answer any questions I can. Provisioned Concurrency (PC) is an interesting feature for us as we've gotten so much feedback over the years about the pain point of the service over head leadi…
1. the time to initialize the VM
2. the time to create an ENI if you are connecting to a VPC[1](until the NAT alternative rolls out globally)
3. the time to initialize your language runtime (Java seems to be the worse, scripting languages the best)
4. any program initialization done outside of your handler that runs once per cold start of your lambda runtime.
A fully “warm” instance avoids all four when run.
Is my understanding correct that a “provisioned” runtime that isn’t “warm” will only avoid the first two?
What state is a “provisioned” instance in?
[1] I refuse to use the colloquial but incorrect statement that the lambda is “running inside your VPC”.