19 ms·

AWS Lambda pricing now per ms

• catchmeifyoucan 6y ago
  For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement for cost savings.
  • jeffbee 6y ago
    Just out of curiosity, what are you getting out of your 160 million CPU cycles? Are you mostly on the CPU, or mostly waiting for something (database call or whatever)?
    • londons_explore 6y ago
      I want to do something that a low level hacker could do in 100 clock cycles with hardcoded bit twiddling and some avx-512, but I want to use nodejs, so I'm gonna need at least 100 million clock cycles to parse all the npm modules...
      • fwip 6y ago
        Not sure why you need a whole bunch of npm modules to do bit twiddling in a performance-sensitive lambda function. Sounds like you just don't like Javascript. Edit: You're spending like 80ms on cold-start of your lambda function, plus network overhead. If you can spare that, you can likely spare the half a millisecond for the 999,900 cycles you're complaining about.
  • Supermancho 6y ago
    > So this is a pretty good advancement for cost savings. For some people. Those cost savings are made up somewhere else. Ultimately, Amazon is not a loss leader.
    • camhart 6y ago
      Why only for some people? It always rounded up to 100ms. If your function took 101ms, it was billed as 200ms.
      • jlouis 6y ago
        If it takes 60 seconds, that's 600 steps. 601 steps isn't that much of a saving. It matters close to 0.
        • NeutronStar 6y ago
          If your lambda function took 60s you have other issues.
        • alpha_squared 6y ago
          If a process takes that long, lambda would be a poor architectural choice.
          • Pfhreak 6y ago
            Not necessarily. For low frequency workloads with reasonably long step times, Lambda can still make sense. (E.g. When videos appear in this S3 bucket, process them.) You might only drop videos in once a week, but when you do you want to run some code against them. There are plenty of distributed workflow reasons to run long running Lambdas infrequently rather than spinning up and down an EC2 instance.
            • lstamour 6y ago
              Right but the first thought I had was, couldn’t you fan out and run a lambda for each frame or a group of related frames? (E.g. Batch HLS processing would be really easy!) If so, you’re back to short lambdas again. It’s really the sweet spot for using Lambda after all: lots of big jobs can be broken down into lots of little jobs, etc.
  • tgv 6y ago
    Warm or cold?
  • munns 6y ago
    Awesome! That was the idea here. Lots of sub 100ms workloads and we really want you to be able to pay for what you use. - Chris, Serverless@AWS
    • ignoramous 6y ago
      > ...we really want you to be able to pay for what you use. Cloudflare Workers has the right pricing model. They only charge for CPU time and not wall time. They also do not charge for bandwidth. > Lots of sub 100ms workloads... AWS Lambda (or Lambda at Edge), as it stands, is 10x more expensive for sub 50ms workloads (Workers does allow upto 100ms for the 99.9th percentile) that can fit 128MB RAM. https://medium.com/@zackbloom/serverless-pricing-and-costs-aws-lambda-and-lambda-edge-169bfb58db75 https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
      • munns 6y ago
        Except that none of the rest of your infrastructure is there, and that APIs represent just a non-majority part of Lambda workloads.
        • mrits 6y ago
          To be clear, you're acknowledging Cloudflare has a much better pricing model but just not as many other services yet?
          • munns 6y ago
            No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think. They aren't brought up in any of the convos I have with customers.
            • ignoramous 6y ago
              But you're telling us that Lambda's prices are justifiably higher because of the strong vendor lock-in? AWS is starting to sound more like Oracle. Ironic. :) Besides the fact that Cloudflare's part of the Bandwidth Alliance with GCP and other infrastructure providers from which AWS is conspicuously absent, Cloudflare's also slowly but surely building a portfolio of cloud services.
  • eb0la 6y ago
    So this confirms there is a lot of competition in the serverless space: aws lambda, Azure cloud functions, Google cloud functions, serverless containers. Like knative, Google cloud run...
  • jimmaswell 6y ago
    How many people actually use lambda? Always came off as a gimmick to me.
    • munns 6y ago
      Enough that in 2019 it was the most popular topic at re:Invent (our big user conference) and that today per our re:Invent announcement almost half of all new compute workloads in Amazon are based on it. Pretty heavily used across different industries and verticals.
    • diegocg 6y ago
      They can seem not that useful by themselves. Their power comes from the integration with the rest of AWS services.
    • tealpod 6y ago
      I rarely use lambda but I use alot of Google firebase-functions for majority of my server code. From my experience lambda/firebase-functions/Azure-functions are very popular.One simple usecase I can tell is payment-successful return-hook from payment servers like Stripe.Its a tiny task which just logs payment-success info and triggers a email..etc.
  • franga2000 6y ago
    Just out of curiosity, could you share what kind of things you use it for? I've never used Lambda, but any time I have a function that I need to run in response to some event or perodically (that's what Lambda is, right?), it's set up in a background worker specifically because it's long and slow, as anything fast can be done synchronously without the overhead.
    • Cthulhu_ 6y ago
      Lambda is not specifically made for long and slow tasks; AWS Lambda specifically has a maximum execution time of 15 minutes (and you have to explicitly configure it to do so, see https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambda-supports-functions-that-can-run-up-to-15-minutes/#:~:text=You%20can%20now%20configure%20your,Lambda%20function%20was%205%20minutes https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambd....). For longer tasks, spinning up an EC2 or Beanstalk instance is probably the way to go. As for what to use it for, we used it in our application (deployed to Netlify which uses Lambda under the hood) where lambdas operated like a 'proxy' to various 3rd party API suppliers (Commercetools, Adyen, some age verification service), and those too would use a lambda function to ping back at us (e.g. when payment was confirmed). Worked pretty well, although in retrospect I would've preferred a 'normal', monolithic server to do the same thing.
• yeldarb 6y ago
  Anyone know why there's a hard limit of 15 minutes for Lambda (and 9 minutes for Google Cloud Functions)? Still seems really weird to me.
  • jlouis 6y ago
    Safety. No function runs forever. Also if you want to reboot/repurpose the server, 15 minutes is max wait time. And finally, you don't want people running long jobs here when you have a solution there.
  • yowlingcat 6y ago
    Lambda isn't designed for long running processes. Keeping the runtime limit lower makes it a lot easier to operate the underlying metal because you can move thing around every N minutes where N is the runtime limit. For long-running processes, something like Fargate might be a better fit in the AWS side of things.
    • donor20 6y ago
      Fargate works well especially after they fixed some of the pricing issues there. Then next step you can spin up a fleet of EC2 or EKS or something
      • yowlingcat 6y ago
        Yup! In general, I prefer Fargate over Lambda because of cold starts. It's a little bit more management overhead over Lambda and it is a bit lower level. But I think it's worth it.
      • Cpoll 6y ago
        > Fargate works well especially after they fixed some of the pricing issues there. Was this recent, should I take a look at this again? My issue with Fargate as recent as a year ago was that running the same workload on ECS (if you can use your cluster nodes efficiently) was twice as cheap (even without reserved instances).
  • 6y ago
• deleted 6y ago
  [deleted]
• camhart 6y ago
  I've learned that AWS pricing tends to improve over time, and I appreciate it. I just recently switched from a startup offering authorization to AWS Cognito because the startup kept raising their price(s). It's nice to see this drop, though I'm sure Amazon does it due to competition as well.
  • Supermancho 6y ago
    This is an analysis from 2018ish - https://www.stayclassyinternet.com/articles/investigating-AWS-pricing-over-time/ https://www.stayclassyinternet.com/articles/investigating-AW...
  • astuyvenberg 6y ago
    It's nice to see that AWS is using their economy of scale to reduce their own costs, and passing that on to the consumer.
    • irrational 6y ago
      I don't think they are doing it to be nice to consumers. I think they are doing it to cost less than competitors.
      • astuyvenberg 6y ago
        I didn't mean to imply that they did it to be kind, I think it's clear they made this change to be more competitive in the market place. It's still great to see.
      • trisiak 6y ago
        Isn't that the same in practice? You get customers by being nice to them. Being nice to customers means competitive pricing, high quality support, good documentation, easy integration, etc. It's all driving towards the same goal.
        • bosie 6y ago
          Naming good documentation and high quality support in conjunction with AWS is a bit weird to me. Though parent was talking about using their scale to improve prices. They might just reduce their margins at the moment.
• jlouis 6y ago
  Necessary change. Now writing stuff in fast languages suddenly matter in cost, changing the landscape of when these solutions might become viable for a chase.
  • SoSoRoCoCo 6y ago
    True: Last week HN had this to say about AWS + Rust: https://news.ycombinator.com/item?id=25200324 https://news.ycombinator.com/item?id=25200324
  • koolba 6y ago
    And you can pick any language you'd like as it supports arbitrary containers now too: https://news.ycombinator.com/item?id=25267182 https://news.ycombinator.com/item?id=25267182
    • bdcravens 6y ago
      For per ms billing to matter, you probably want to limit your language choices.
    • throwaway894345 6y ago
      Wow, I haven’t read yet, but I’m very curious if this affects the size limits on the lambdas. I’ve tried to build lambdas for a small Python use case, but by the time I imported pandas and a few other libraries I exceeded the 250 mb limit and migrated to ECS/Fargate, but the startup times were much longer.
      • fitzoh 6y ago
        https://twitter.com/chrismunns/status/1333825503464214530 https://twitter.com/chrismunns/status/1333825503464214530 Docker containers can be up to 10gb, traditional lambdas are still limited to 250mb.
        • munns 6y ago
          Thats me. We've got some fun things we do behind the scenes to keep Lambda container image support snappy. SO yes, up to 10gb artifacts with container image support.
• 4lejandrito 6y ago
  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?
  • munns 6y ago
    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
    • pistoriusp 6y ago
      Are 15 minute max execution times still the norm?
      • rajinikantham 6y ago
        Yes. I didn't see anything about relaxing those limits today in the keynote. Once can hope and dream..
        • digianarchist 6y ago
          I saw the news around running container images as artifacts which is welcome. Still the 15 min limit restricts a lot of use cases. https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-containe...
          • snypox 6y ago
            As far as I know, if you run for more than a few seconds Lambda’s cost will _really_ not worth it. One should prefer ECS or Batch.
            • digianarchist 6y ago
              On Fargate? I agree.
• forrestbrazeal 6y ago
  More detailed breakdown from AWS's James Beswick: https://acloudguru.com/blog/engineering/building-more-cost-effective-lambda-functions-with-1-ms-billing https://acloudguru.com/blog/engineering/building-more-cost-e...
  • ite07 6y ago
    this is a good reference, thanks
• brunoluiz 6y ago
  I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS
  • tgv 6y ago
    I've got bad experiences with go startup (i.e., cold runs). They're much more expensive than I would have expected. If node can indeed run in 40ms (as https://news.ycombinator.com/item?id=25267211 https://news.ycombinator.com/item?id=25267211 says), then I'm surely going back to JS.
    • philosopher1234 6y ago
      What is your experience? Go is an AOT compiled language so the only thing I could imagine you running into on startup is loading the binary into memory? Theres not a cold-start issue with Go, as its not an optimizing JIT. Edit: Bizarre. Seems like Go on lambda does actually have slower cold start than JS or Python. I wonder if its just that the binary is likely larger than the equivalent JS source code? https://levelup.gitconnected.com/aws-lambda-cold-start-language-comparisons-2019-edition-%EF%B8%8F-1946d32a0244 https://levelup.gitconnected.com/aws-lambda-cold-start-langu...
      • nicoburns 6y ago
        I'm not sure about lambda, but cloudflare workers use v8 isolates to avoid starting a new process at all.
      • tgv 6y ago
        My experience is that Go cold start takes around 900ms. Processing (parsing a JSON message, verifying it with one DynamoDB look-up, and storing it in DynamoDB) then takes between 11ms and 105ms. Go does use less memory than node, though, and that also counts in Lambda. I hadn't expected it either, but it loads node faster. Perhaps via some VM trick?
      • gen220 6y ago
        > The function did nothing except emit ‘hello world’. A more realistic benchmark would be parsing a 1kb protobuf blob and printing some random key from it. (this would require importing a non-stdlib parser) Without knowing how it's implemented, my guess is that they're conserving python/v8 processes, so that they're not cold-starting the interpreter on each lambda execution. You can't [1] do the same thing for a Go binary, so they have to invoke a binary, which might involve running some scans against it first. This leads to some pretty counterintuitive conclusions! If you want minimal latency (in Lambda!!), you really should be using JS/Python, I guess. [1]: OK. Maybe you could. Go has a runtime after all, although it's compiled into the binary! I have never heard of anybody doing this, but I'd love to read something about it. :)
• AndersSandvik 6y ago
  66$ for running a AWS Lambda with 128 for a year seems very expensive.
  • jedberg 6y ago
    If you're running it continuously for a year, then you should probably be using a reserved instance and not lambda. Lambda is for short bursts, not 1 year of continuous use.
    • dumbfounder 6y ago
      Not necessarily, especially in a large company setting. Lambda allows you to scale and take care of spikey traffic. It also doesn't require server management. Servers are a pain in the butt.
      • brianwawok 6y ago
        True, but ECS and K8s both abstract aware the hardware and offer cheaper 24/7 workloads and get past the cold start problem (at the expense of slower spike responses).
    • deleted 6y ago
      [deleted]
  • donor20 6y ago
    The service bills in ms's, and you are complainting about price for the year? For $66/year and a 3 year commit maybe get a T4g small with 2GB of ram vs .1GB?
  • astuyvenberg 6y ago
    Generally speaking, functions don't run continuously. If your use case is 100% compute 100% of the time, it's not a great fit for lambda.
  • kempbellt 6y ago
    And it costs even more if you need that Lambda function to have access to the internet. A possibly useful comparison: A Raspberry Pi 3 (~6.5 watts) costs $6.83 per year to run full-time (at 12 cents per kWh). You get a full computer with much more I/O. However, there are a lot of other factors to consider: - Initial cost of the hardware - Time and energy spent maintaining/configuring the device - Physical maintenance of the device - power/network/physical management/etc - Lack of immediate access to I/O ramp-up and global replication - Lack of direct integration into other AWS services/etc AWS Lambda isn't a magic bullet, but it offers a lot of convenience to offset time and money spent on a DIY approach. I run a small static site/service that never breaks Lambda's free tier, but most of the cost goes to hosting a NAT gateway for it to have access to the internet. The benefit of hassle free, global access to the service I built and the underling services it runs on (Lambda/AWS in general) makes it worth the cost. I could setup the same service at home on a Raspi for pennies by comparison, but if my home internet goes down while I'm away, or a dog chews on an ethernet cable, it's a headache that I have to deal with personally - or I have to do remote tech-support to whoever is home: "Okay, you should see a Raspbery Pi. No...it's not a food. It's a computer. Whatever... I know it's a strange name. Anyway, is the cable plugged in? Do you see a blinking light?" I find it similar to being able to use a rental car while visiting a foreign city vs just driving yours across the country to save some money. You might save some money, but it comes with extra time, maintenance, potential roadblocks (literally and figuratively), breakdowns that you will have to deal with personally, etc. It's really up to personal preference.
• notpygame 6y ago
  Anyone know what the co2_price is? It's missing from the page.
• pwinnski 6y ago
  This is my favorite news so far. Hard to imagine beating this one, in terms of actual impact for me. Very tired of this: `Duration: 58.62 ms Billed Duration: 100 ms` Very happy about this: `Duration: 48.74 ms Billed Duration: 49 ms`
• dezmou 6y ago
  There will be more surprise in bills, imagine if your Lambda is making a call to an API and this API suddenly slow down for any reason
  • SamBam 6y ago
    How does this change increase the likelihood of that happening?
    • colechristensen 6y ago
      Before the 100x courser granularity would hide a lot more variation if your lambdas were quick.
      • cestith 6y ago
        It would be a surprise of less savings, but it would still be a savings on the tail with the smaller granularity. Perhaps Keep your old budgets for a while and be glad at the surprise discount.
• simlevesque 6y ago
  This means that using bigger CPUs (by allocating more RAM) just became even more important.
  • bmm6o 6y ago
    That was my first thought. Over a lot of the curve it's almost free to run on a bigger slice. When you get down to just a few billing quanta the math didn't work out in your favor.
• kadukeitor 6y ago
  I think now is a good time to use this kind of services. https://callbackfy.com https://callbackfy.com It's essentially a way to save some money by avoiding long http requests by buffering requests and sending a callback when the result is complete.
  • hbbio 6y ago
    Using a service with a TLS certificate error... probably not.
    • kadukeitor 6y ago
      The url is just a redirection to this: https://rapidapi.com/kadukeitor/api/callbackfy2/ https://rapidapi.com/kadukeitor/api/callbackfy2/
• imahaccker 6y ago
  hack this guuy
• imahaccker 6y ago
  hack thisguy
• ehejsbbejsk 6y ago
  Does Lambda still lag from awake?
  • SV_BubbleTime 6y ago
    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.
    • ralmeida 6y ago
      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.
      • SV_BubbleTime 6y ago
        This is news to me and exactly what I would have expected to exist. Good to know!
    • ehejsbbejsk 6y ago
      I suppose I can ping it upon page visit (for web apps). That never occurred to me until now.
• loxias 6y ago
  Exciting! As a primarily C & C++ programmer this makes me happy. Also, I see that there's now examples for C++ that don't involve "step 1, download nodejs". Progress!
• ashtonkem 6y ago
  Oh, that absolutely changes the price calculation for Lambda. Historically the 100ms minimum billing interval made Lambda significantly more expensive than EC2 for large numbers of work loads.
  • SV_BubbleTime 6y ago
    My needs were different and the EC2 vs Lambda different was state vs stateless. This won’t save me a ton of money; but at least I won’t have to guess on if bumping up to the next CPU+MEM tier will get me from 101ms to 99ms
• code4tee 6y ago
  This is great. For many high velocity low runtime workloads this is going to be a result in a significant cost savings.
• lawwantsin17 6y ago
  This is still scam. no matter what it costs.
• fareesh 6y ago
  Is there a way to use lambda where I can use ffmpeg to watermark and downscale a 4K video? Possibly some system where I can throw a lot of computing at the job and get it done quickly. Right now on my vps it takes multiple minutes to get done and scaling up the vps for one feature or dedicating another server for it is overkill.
  • pcnix 6y ago
    Another subission today seems to point to exactly what you're looking for - https://aws.amazon.com/blogs/aws/new-for-aws-lambda-functions-with-up-to-10-gb-of-memory-and-6-vcpus/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-function...
  • npollock 6y ago
    This works well: https://github.com/serverlesspub/ffmpeg-aws-lambda-layer https://github.com/serverlesspub/ffmpeg-aws-lambda-layer
  • winslow 6y ago
    I don't see why not, assuming it's less than the lambda max run time (15 minutes I believe). Use a python script and an included binary of ffmpeg might work. Note: You'll need to write to the tmp space of the lambda as that's the only place that allows writing to the filesystem and then you'll need to upload it to S3 or elsewhere. Lambda's are good at batch jobs where you might need to kick off a few of them but not have a dedicated system for it. I've used it to automate manual customer support tasks that are sporadic in requests.
  • itisit 6y ago
    I'd check out Amazon Elastic Transcoder (https://aws.amazon.com/elastictranscoder/ https://aws.amazon.com/elastictranscoder/).
• diveanon 6y ago
  I wonder if any of the downstream service providers like vercel and netlify will pass this along.
• haolez 6y ago
  I hope Azure follows this move soon :)
  • akh 6y ago
    They might change their 128MB rounding-up structure but they already had per 1ms pricing with the minimum execution time and memory for a single function execution being 100ms and 128MB respectively. (Google do per 100ms and have 6 pre-defined memory sizes to pick from).
• koluna 6y ago
  All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows and sleep much better (and at lower maintenance cost). [0]: https://news.ycombinator.com/item?id=25268049 https://news.ycombinator.com/item?id=25268049
  • landerwust 6y ago
    Your lambda function can be a container
    • koluna 6y ago
      Why would you want to put it in Lambda then when there are better options?
      • deleted 6y ago
        [deleted]
      • landerwust 6y ago
        There is no better option for temporally sparse compute. If your job can run all the time there is no benefit to these systems, but if it wastes money by being provisioned all the time when not in use, there is no alternative. Lambda is neither "worse" nor "better" in any general sense. It's just another option that might apply given a particular scenario, and one that got significantly cheaper today.
  • gpmcadam 6y ago
    After using lambda quite a lot recently I think the vendor lock-in argument is overstated, especially with things like Serverless framework. The lock-in comes more with the other AWS products you end up using such as CloudFormation and DynamoDb, but not Lambda which in most cases can be wrapped around an Express server or similar and could be hosted anywhere
• gitweb 6y ago
  2020 is the year when companies will gladly pay 20x as much as a dedicated server in a DC because cloud.
  • ratdragon 6y ago
    But... But....It's cloud. And savi gs.
• akh 6y ago
  In case it helps Terraform users estimate their cloud costs, I updated https://www.infracost.io https://www.infracost.io to support the new ms-based Lambda pricing (https://github.com/infracost/infracost/pull/248/files 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 https://www.infracost.io/docs/usage_based_resources - longer term we could extend that to fetch average_request_duration from cloudwatch or datadog.
  • maxpanas 6y ago
    Very cool project, well done.
  • Hortinstein 6y ago
    Wow amazing project! Another reason to start looking at terraform for my next project
• maverwa 6y ago
  Interesting: the german version (and other non-english versions, if I parse that correct) of the page still mentions rounding up to 100ms while the english version to 1ms. Cache? Not yet translated? Different pricing model?
• polskibus 6y ago
  I wonder if this change will push more people to consider rewriting code to more memory and CPU-efficient programming platforms, for example from java/c# to C or Rust?
  • zingplex 6y ago
    I thought you are limited in the languages they permit, the fastest of which being Go.
    • floatboth 6y ago
      No. You could always shell out to any language from node/python, but for quite a while even that is not required, lambda can directly run any binary. https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/ https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws... https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom...
• raphaelj 6y ago
  I find it annoying to have all these pricing per second, and now per millisecond. It's really hard for my mind to visualize what `$0.0000000021 per millisec` actually is. Being billed by the millisecond does not mean that you should give a pricing per millisecond. I prefer Digital Ocean or Heroku's approach of billing by the second, but giving the price per month. How on hell is `$0.0000000021 per millisec` better than `$5/month, billed by the millisecond`? If I know that my workload will be about 20% of a dedicated CPU, I know that I'll end up paying about $1 per month.
  • Tehnix 6y ago
    There is simply an enourmous amount of assumptions that would go into estimating anything else, because ms is the only correct metric. Lambda billing for a month? What on earth does that say? 10 invocations running 15 minutes? 90,000 invocations running 100ms? (Those two are equivalent btw). If I know my function takes around ~35ms ballpark, and I will probably invoke it 5,000 times per day, then I can calculate my monthly: 0.0000000021 $/ms * 35ms * 5,000 * 30 = 0.011 $/month. AWS usually shows a neat example of usecase and what the billing would be on their pricing pages.
    • stkdump 6y ago
      Gotta be sure to have that number of 0s exactly right.
• deleted 6y ago
  [deleted]
• cordite 6y ago
  This is great, AWS. 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.
  • snypox 6y ago
    I’m confused. This is available already for more than a year (maybe 2). https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
    • cordite 6y ago
      Yes, it's in ECS, which is why I said "like ECS" I'm asking for Lambda to have externally supplied secrets
• kords 6y ago
  I was considering migrating my NodeJs lambdas to .NET Core, but I guess cold start times will have a higher impact over billing.
• nnx 6y ago
  Were lots of memory tiers (eg. 256MB) removed? They aren't present on pricing page anymore.
  • jmu1234567890 6y ago
    It is up to 10GB now
• collyw 6y ago
  What sort of workload is that going to make a significant difference to?