251–260 of 291 posts
A feature I'd really like next is secrets as environment variables like ECS.
Retrieving SecretsManager secrets and SSM Secure Parameters in application code is messy and provides significant friction for developers on my team.
Earlier quoted context omitted.
There are warm and cold runs. If it’s really important you can pre-heat by calling the lambda every so often. It would be nice if they had some option for this.
There's Provisioned Concurrency for Lambda which keeps an amount of Lambdas warm at a price, so you don't have to keep pinging your function yourself to pre-heat.
In case it helps Terraform users estimate their cloud costs, I updated https://www.infracost.io to support the new ms-based Lambda pricing ( https://github.com/infracost/infracost/pull/248/files , it'll be in the next infracost release). I'm interested to hear what people think about https://www.infracost.io/docs/usage_based_resources - longer term we could extend that to fetch average_request_duration from cloudwatc…
I am impressed that computation is billed by the ms nowadays. I'm an ignorant in AWS Lambda but how do you know if their ms measurement is accurate? Is there any way to verify this?
You are billed by the execution time of the function. So from the millisecond we hand the event over to you until you return a response or timeout. - Chris - Serverless@AWS
Earlier quoted context omitted.
If you want sequential processing of the data in the SQS queue, something which works really well today is to create a state machine in AWS Step Functions which triggers a AWS Lambda function which then pulls data from SQS and processes it. Using a condition in the state machine, this can be done in a loop, so when the AWS Lambda function reaches its timeout, another one gets triggered as long as there is still data…
Yep, but I prefer to care about manually fetching data from SQS. It's a weird system, but due to our data model there are many benefits to processing as many messages in a given lambda as possible.
https://aws.amazon.com/about-aws/whats-new/2020/11/aws-lambd...
Earlier quoted context omitted.
You are billed by the execution time of the function. So from the millisecond we hand the event over to you until you return a response or timeout. - Chris - Serverless@AWS
Are 15 minute max execution times still the norm?
Earlier quoted context omitted.
To be clear, you're acknowledging Cloudflare has a much better pricing model but just not as many other services yet?
They're not easily comparable (I tried using Cloudflare Workers before going back to AWS). Lambda@Edge runs Node or Python. Cloudflare Workers runs V8 with "worker isolates" which has a few more caveats, an imperfect but improving dev experience, and doesn't work with a lot of npm packages.
Earlier quoted context omitted.
How long would you like it to be? Chris Munns - Lead of Dev Advocacy for Serverless@AWS
As long as possible. Our jobs usually finish well within the limit but the top 1% hit the limit. One example we've been wrestling with is a merge operation. Usually it's merging about 1000 records which completes in a few seconds. But every once in a while someone kicks off a job that tries to merge 1,000,000 records and it times out. We want the benefits of serverless (scale down to zero, up to infinity at the drop…