DEV Community: Jon Goodall

AWS Database Savings Plans – Save Up to 35% – FINALLY!

Jon Goodall — Thu, 04 Dec 2025 11:07:12 +0000

It’s AWS Re:Invent right now, and one announcement has me and the rest of the AWS community very excited – AWS Database Savings Plans.

I’ve been asking for this for as long as I can remember, probably because I’m a bit dull, and also a little stingy…

You’re likely wondering why I’m so excited about this, and in no small part, it’s because it makes my life easier. It also gives you, AWS customers, another AWS cost optimisation option to save money on your AWS bill, which is always a good thing.

Before we get into the details about AWS Database Savings Plans, let’s do a bit of a history lesson.

A History of AWS Savings Plans

All the way back in 2019 AWS released “Compute Savings Plans“, and I’ve been a fan since day 1. They make saving money on “compute” (namely, EC2, Fargate and later Lambda) much easier.

Before the Compute Savings Plan was released, if you knew that you were going to keep the same server for 1-3 years, you could lock in a commitment using a Reserved Instance (RI). Savings of 20% were common, and savings of 30% or more were possible. But, if you had plans on moving to “modern compute”, you were a bit stuck. Sure, you could do it, but you’d be paying for the RI you’d committed to for the duration of the term, even if you weren’t using it. This was a real barrier to modernisation, because nobody likes paying twice.

This is an oversimplification, as convertible Reserved Instances exist, which let you trade them for other types. Reserved Instances also “roll up” smaller-sized Reserved Instances to cover larger servers. This has a caveat, though – it only applies if there’s no licence fee built into the hourly spend (sorry, Windows users). But in essence, you were stuck managing servers.

You could move to containers, but you had to keep using EC2 to run the containers on, which was a headache and added engineering time.

Compute Savings Plans are different, though – you commit to an hourly spend and save money. Literally, that’s it.

OK, it’s a spend within the three supported services (EC2, Lambda and Fargate), but so long as you’re spending money on one of those things, you’d be getting the discounted pricing. Purchase terms are the same – commit to longer and pay more up front to save more money. However, the 0% upfront 1-year plan is incredibly compelling, so I default to recommending it.

Compute Savings Plans aren’t perfect, though. My biggest gripe was that they didn’t support database spend. You might argue it’s a storage service, not a compute service, but tell a developer that. The line between “storage” and “compute” is so thin you can see through it at this point. My second biggest issue was the hourly commitment rather than the daily one. With a daily commitment you can account much better for flexible workload trends, but you can’t have everything.

Cool, history done, what’s new?

As of the 2nd of December 2025, announced to great cheers from the audience in Matt Garman’s re:Invent 2025 keynote, AWS Database Savings Plans are a thing! This is “A Very Good Thing“. He really did save the best til last, with only 2 seconds left on the ‘shot clock’!

AWS Database Savings Plans work in a very similar way to Compute Savings Plans – commit to an hourly spend in “supported usage” and save money.

Purchase terms are similar, but currently you can only commit to a 1-year term (come on AWS, give us 3 years!), and we’re also only offered a no up-front payment option at lauch. I’d love to see increasing discounts available for committing for longer, and paying up front as you can with Compute Savings Plans. Despite this, there are still some serious discounts available here, and the best bit is it covers serverless too – with a discount of up to 35%! That’s massive and really cements the idea for me that you should start on serverless options until your per-hour cost outweighs the “scale to zero” benefit. AWS are also pushing ‘Advance Pay‘ as a way to pay up front for your database services, but there’s no discount for doing this, so I’m not sure why you’d bother.

They also have day 1 support in Savings Plan Purchase Analyzer – I waxed lyrical about this on an episode of the Logicast AWS News Podcast, so this is a really nice thing to have on day 1. You’d better believe if it didn’t have it, I’d be complaining about it!

Sounds Great, What’s the Catch?

The AWS Database Savings Plan isn’t a perfect offering, as it still suffers from my second gripe of Compute Savings Plans – the hourly vs. daily commitment.

It does also muddy the water a bit, as we now have four different types of Savings Plan:

Compute Savings Plan
EC2 Savings Plan
Database Savings Plan
SageMaker Savings Plan

This is very easy to solve though, AWS just needs to release an overall “Savings Plan” that covers Compute & Database, whilst dropping the EC2 Savings Plan offer. I’ve never found them useful between Reserved Instances and Compute Savings Plans, but maybe some people do. I also don’t use SageMaker to have a considered opinion on SageMaker Savings Plans, so they get to stay for now.

I’m sure it’s not very easy for AWS to do this, for a myriad of internal and technical reasons, but we can but dream.

Now, onto the “supported services” list. This is confusing. It covers:

RDS
Aurora
DynamoDB
ElastiCache
DocumentDB
Neptune
Keyspaces
Timestream
Database Migration Service (who’s running that for a whole year?).

This is a massive list of services for day 1 – remember Compute Savings plans only covered EC2 & Fargate at launch.

However, it’s not all spend within those services that counts. Got a Redis cluster? Sorry, only Valkey is supported. Using a t4g RDS instance? No discount for you. In fact, anything that uses ‘servers’ is only eligible to be included in a Database Savings Plan if it’s using the latest instance types (r7g, m7g, m7i, m8g, etc). This is very frustrating, as many people I’ve worked with need a 24/7 non-prod environment, but only need t4g instances, for example.

The serverless offering somewhat redeems this, as it’s just per-CU (Capacity Unit) hour. This is a much better offering than the current option of “nothing” and goes a long way to solving for “I can’t do serverless, it’s more expensive under consistent load”. This has been a real issue for me personally, as I’m a big advocate of serverless-first, but I couldn’t honestly recommend it for production workloads. Either the warmup time was too long for transactional workloads, or the constant throughput was too expensive without being able to make a committed purchase.

Final Thoughts on AWS Database Savings Plans

I’m willing to forgive the complicated in-scope vs. out-of-scope spend on this one, considering the vast array of services that are covered. Also this is a V1 offering so I’m sure it will evolve to include more services, and more payment options, as per the other savings mechanisms.

This also doesn’t solve for “do I buy a Reserved Instance or an AWS Database Savings Plan”, but the gap is closing, and I’m looking forward to seeing more things come into scope in the future. AWS have committed to including newly released instance types as they become available, so I’ll just have to upgrade my boxes, I guess.

Building a Serverless Podcast Workflow: Adventures with AI

Jon Goodall — Mon, 30 Dec 2024 14:09:50 +0000

As you may know, I’m a co-host & standing guest on the Logicast AWS News Podcast, where we discuss all things in the news about AWS.

What you probably don’t know, is that the preparation & production of a podcast is rather a lot a work, and that anything to speed up & simplify the process is absolutely necessary – especially for a weekly podcast.

On the preparation side, being about recent AWS news helps because we don’t have to do as much work on research side – we just turn up & record. This doesn’t help us on the production side though, which is still a lot of work.

To give you a flavour, the things we have to do every week are:

Pick the articles (and ideally read them)
Share with the guest and answer any questions they might have
Record the episode
Download the files
Convert the files into the correct formats
Create a trailer
Create a summary (the “show notes”, in podcasting parlance)
Upload to the publishing platform
Social promotion

On top of this, because “content is king”, we want to be able to re-use the episode as much as possible. Our current wishlist is:

Create short “clips” for social posting to “drip feed” the content and drive subscribers
Create a long-form blog post from the recording, that isn’t just a transcript
Add full subtitles to each video.

As with any problem, there were a few options to solve both the required tasks, and start on the wishlist.

Option 1: Outsource it.
This looks like a combination of things, from hiring a production & marketing person (much love to Alicja for the work she does), to using 3rd party tools to help with some of the creation (I’m not linking the tool, because they’re not paying us, but we use an AI service for clip/trailer creation)

Option 2: Automate All The Things
Obviously I want to do this, because I’m an engineer, and in my head my time is free. I’m sure Logicata disagrees with me here though…..
However, throw in the fact that we “needed” a reason to talk about AI, we thought we’d better have a go at doing “something”.

Enter the Workflow

Now, I’m a Serverless AWS Community Builder, so obviously I went straight for Lambda & Step Functions here. I started playing around with options, and for once, doing some research. I know! Didn’t see that coming either.

Up in this rarified research-fueled air, I found this AWS blog: https://aws.amazon.com/blogs/machine-learning/create-summaries-of-recordings-using-generative-ai-with-amazon-bedrock-and-amazon-transcribe/

This was a really good foundation for what we needed/wanted to build, it even had a sample project at the time which let me short-circuit hours of dev time

After a bit of tweaking, I came up with this:

Yes, that’s a big scary image, so let’s break it down.

The process is:

Step 1: Kick-off with File Upload

We start by uploading an m4a file to an S3 bucket, and use the bucket notification to trigger the workflow.
I have to download the files from the recording platform, which isn’t a problem, but is a bit annoying.

Step 2: Media Conversion

AWS Elemental MediaConvert transforms the m4a file into an mp3 format, ready for Spotify and other platforms.
We have to do this because the recording platform delivers an m4a, but most audio platforms prefer an mp3.

This is a fire-and-forget approach, so I’m manually checking for the job completion and downloading the file afterwards. Again, not a problem but somewhat annoying.

Step 3: Transcription

Amazon Transcribe converts audio into a text-based JSON document. This is actually the most expensive part of the process, which I didn’t expect at the outset.

Step 4: Run the prompts

Amazon Bedrock reads the transcription and generates summaries and titles using prompts stored in DynamoDB.
Since building this, prompt manager became a thing, because as everyone knows the best way to get AWS to create a new feature is to build it yourself first.

This is all in one Lambda, using a loop in Python. I regret this enormously but it was the quickest option.

Step 5: Outputs

The final outputs are sent to an SNS topic for easy access.
We have a Slack channel email subscribed to the topic, so the messages aren’t lost in inboxes.
We went with SNS & email both because the baseline I used was already doing it, and I couldn’t be bothered to work out the schema for AWS Chatbot. I should probably do this though.

Obviously this isn’t our full wishlist, or even the complete set of required tasks. However, with careful prompting, it does make the required tasks a lot faster to do. The summary is a good prompt to create the show notes & the LLM creates the title – sometimes we use it, sometimes not.

There must be some problems though?

You would be correct there. The issue comes back to my time – it’s only free in my head. Turns out, building this sort of thing takes rather a lot of time & effort, so it has a number of “rough edges”.

Chiefly:

1. It’s really fragile.
Seriously, one dodgy prompt, or an episode that runs a touch long, bang. All falls over, nothing comes out the end. Lately we’ve been hitting rate limits too, presumably because we’re on an ancient version of Claude.
This is mostly because I’m hacking it together, and not spending a proper amount of time on it

2. Transcription is expensive, and the workflow must restart on error.
Again, because it’s fragile, the re-runs have to start at the beginning. What’s worse, because most of the failures are prompt-based and errors in the model invocation are only checked after-the-fact in a downstream task, I can’t take the offending prompt out and re-drive from the failure, thus forcing a full re-run.

3. It’s kinda slow
Nothing doing here, it’s just slow. No parallelisation of the prompts (due to the aforementioned bad Python loop), and a single lambda taking every output response and dumping it onto SNS at the same time.

Improvements.

OK, we’ve run this for a few months (eek), and I’ve even delivered a whole talk on it (see that here), I should probably do something about fixing these rough edges. This was the list:

Improvement 1:

Update the model:
Annoyingly the interface between Claude versions has changed, so some faffing around is needed here.

Improvement 2:

Use Prompt Manager:
What it says on the tin. No more dodgy DynamoDB table for the prompts, use the service properly.

Improvement 3:

Fix the bad loop:
Take the loop through the prompts out of a single lambda, and run them all as single Lambda’s, called using a Map state.
This also solves for speed, as the prompts are the second slowest part of the workflow

Improvement 4:

Less fragility:
Through the judicious use of “ignoring errors”, we want to be able to run all the prompts and get outputs, even if one (or most) of them fail.

Improvement 5:

File conversion result in Slack
Still using SNS -> email, but now we’re checking for the conversion job, creating an S3 pre-signed URL and sending that to the SNS topic as soon as it’s available. The pre-signed URL lasts for a couple of hours.

Yes yes, Show us a picture:

Fine, something like this:

Did it work?

Well, no. Not quite.
With the improvement list as a starting place, I ended up here:

Bigger and scarier than before I know, but it can’t be helped – we’re just doing more stuff now.
Let me walk you through it.

Steps 1-3: Kick Off:

All still the same – kick off with the upload of the m4a file, trigger the transcoding & transcription.
Only slight tweak is the transcoding trigger actually returns the job id, so I can use that later.

Step 4: Parallel State:

Now we actually use the parallel container I built earlier and split into two branches – one for the transcription & LLM invocations, and the other for the transcoding.

Step 5 (Transcoding Branch):

Nothing massively clever here, just a loop in the step function based on an if/else/continue premise to check for the status of the transcoding job.
If it’s not done, loop around again and wait some more, if it failed, if it’s completed generate a pre-signed url and send to SNS, if it failed send an error to SNS but don’t halt the step function.
This last bit is important – as far as possible we’re not halting the step function for errors in the process, especially on the lower-value task.

Step 5 (LLM Branch):

Now we grab the prompts in their own Lambda, but they’re still from DynamoDB, because I couldn’t fathom prompt manager in the few evenings I had to spend on this.
Same goes for the direct SDK integration between DDB & Step Functions really.

I’m sure some of the Serverless DevAdvocates, AWS Heroes & Community Builders I know would dislike me for this, but I didn’t see the benefit of it here.
Using Lambda Powertools in Python, grabbing the list is 4 lines of code. Plus I’d already written said code in v1, so I kept it.

Step 6 (LLM Branch):

Much the same as before, but with another loop – not a map state.

It turns out the rate limiting wasn’t because Claude v2 is ancient. It’s because all of Bedrock has really low rate limits.
This means that we’re not solving for speed, but we are solving for rate limits, with an unlimited number of prompts, so that’s something.

On each execution of the “Invoke Bedrock Model” lambda we’re dropping the prompt we ran from the list of them, as a quick-and-dirty for loop. With some time this could be cleaned up a bit, but for now it works.

Also, we’re using Claude 3.5 Sonnet V1, and have designs on both V2 (or V3.5 Opus when that eventually comes out), and Amazon Nova Pro, as the outputs in the console looked encouraging.

Step 7 (LLM Branch):

You’ll notice that a couple of states have been removed, namely the direct SDK integration with SNS for sending the results, and the “end error” state.
This reduces the re-run cost by allowing me to re-drive the state machine from the point of error in the case of hitting a rate limit – which was 90% of our errors in v1.

Step 8 (LLM Branch):

Back around to the iterator we go, but this time with an arbitrary 2 minute sleep.

This gets us around the 1 invocation-per-minute rate we’re working with, but I could do something a bit smarter here with error code checking & exponential backoff.

The iterator is well-trodden at this point – just check if the prompts list still has prompts in it, and go around again. If it’s now empty, finish the branch.

Step 9 (Both Branches):

End.
Both branches are now done, so we close out.

So, how is this better?

Well for one I don’t have to sit and wait for the transcoding to finish. The pre-signed URL is dropped straight into Slack for me to grab, so that’s nice.

Also, we can run an unlimited number of prompts, and shouldn’t get rate-limited anywhere near as often – if we do, re-drive from failure covers the restart without having to re-do the expensive transcoding & transcribing.

The updated model performs loads better, and because the interface for all Claude v3/3.5 models is the same, I have a route to make each prompt run under a different model – which I thought was the idea behind Bedrock to start with, but seems to be harder than I thought it would be.

Also we have monitoring, sort of.
I put a small Cloudwatch Alarm on the failures of the step function (well, I had Q Developer write it actually, can’t avoid using AI in this project), which also sends to the same SNS topic. That way I can just upload the file to S3, and get on with other things, without having to babysit the workflow.

And of course I have an update on the project I can write a talk for, so I best start shopping that around local meetup groups I guess.

What’s Next?

Expand the Iterator

I still want to be able to run a different model for each prompt, because models aren’t one-size-fits-all, and I’d like an easy way to test lots of different models on the same prompt.

Use Prompt Manager

Still not using this, and I really should be.

Resiliency

We’re in a better place than we were, but it’s still not as good as I’d like it to be. Ideally we’ll handle rate limit exceptions via a retry and exponential backoff, plus have proper alerting rather than a single alert for the whole Step Function.

Finally, What did we learn?

Rather a lot, as it happens.

Time & Effort Needed

Phase 1 showed the sheer amount of effort needed to get these things going, even with a big jumping-off point from AWS. This is compounded by the fact that this is a marketing/hobby project, so doesn’t get a lot of time spent on it. Phase 2 just compounded that lesson – it took the best part of a day to make the change, split across several evenings, and it’s not that different from phase 1.

Pace of Change

The pace of change within LLMs is really high – between v1 & v2 there were 6 different models released just for Claude, so keeping up with the current models is a challenge all by itself. Once you start thinking about other model providers (looking at you Amazon Nova), it’s a whole different challenge.

LLMs are Non-Deterministic

So we knew that already from the documentation, but in practice it can be really frustrating to not have a consistent output between executions, and you need to be aware of it when developing against them.

Skillset

By day I’m an SRE/Platform Engineer/Generalist Cloud Engineer, not a developer and certainly not an AI/LLM expert, so this was a challenge both dusting off my Serverless developer skills whilst learning how to interface with Bedrock. Fortunately AWS have done a really good job of making it an easy service to consume, and I highly recommend you start with the chat interface in the console to test your prompts.

The other recommendation I’d have for you is to dive in – after v1 I gravitated much more towards AI/LLM talks and workshops at the various AWS conferences I’ve attended this year (London Summit, London Partner Summit, Re:Invent), which I got much more out of for having a baseline level of knowledge, thanks to this project.

LLMs Have Rate Limits

Well, yes, you might say. However I didn’t appreciate just how low they are in Bedrock.
When you think about it, it makes sense, and our usage puts a very high number of tokens through the model in a short space of time. But you do need to be aware of them, and handle them appropriately in your own implementations.

So, What are My Tips?

Hopefully you can learn from my mistakes here, but if you want to short-circuit this whole “learning by doing” thing, I’d recommend:

1. Go to a couple of workshops before getting going.
They don’t have to be in-person, and could be watching something on YouTube after-the-fact, but for a good portion of phase 1 I struggled with just understanding the new terminology I needed
2. Test your prompts
I said this above but it bears repeating – use the console to test your prompts and see what sort of output you’re likely to get. It’s much cheaper to do this than run a whole transcription & transcoding workflow for the sake of changing a single prompt.
3. Try to do model evaluation
I didn’t do this, because the project I based on had already done it, and settled on Claude2. I regret not going through the process to get a better understanding of why Claude2 was the correct choice at the time though. You’ll also learn a lot about the various models in the process, which might be useful for another project.
4. Request model access up front
The “non-AWS” models aren’t instantly approved when you request them, so save yourself some time and request them early.
5. Check the rate limits
These are different between models & regions, so you can’t assume that the same thing will work if you port it to another region
6. Be aware of time
If you’re new to LLM development, this is a learning curve that you’ll need to climb, so be patient with yourself. Doubly so if you’re not a developer by day.
7. Learn by doing
Hopefully by reading this you can go further and faster than I did, but there’s no substitute for building things when trying to learn.

To wrap this up I think I’ll quote Amazon CTO Dr. Werner Vogels:

Now, Go Build

AWS Lambda Use Cases: When You Should Use It?

Jon Goodall — Wed, 31 May 2023 14:13:41 +0000

Lambda, and Serverless in general, is rather “in” right now in the world of cloud computing. If you listened to all the marketing coming out from the big names about it (and yes, I’m guilty of this too); you’d expect that you can run your whole service on it. For next-to-nothing, with no downtime, and your deployments would be as smooth as silk.

So, how much of the marketing spiel should you listen to – how do you know when to use Lambda? Well, I’m going to try and come up with a reasonable list of use cases for AWS Lambda, so that’s a good place to start.

What Is Lambda?

Before we get into “what’s it for”, it’s worth defining “what it is”, so let’s do that.

AWS Lambda is AWS’s take on “Function as a Service” (FaaS). It allows developers to run code without provisioning or managing servers. With AWS Lambda, developers can upload their code, and the service will take care of the rest – including scaling, patching, and availability.

The idea behind AWS Lambda is to make it easier for developers to build scalable, event-driven applications that run on the cloud. The service is highly-available and fault-tolerant. Which means that it can handle large amounts of traffic without crashing or experiencing downtime. One of the key benefits of using AWS Lambda is that it is fully managed. This means that developers don’t have to worry about managing hardware or operating systems. They can focus on building applications, while AWS Lambda takes care of the underlying infrastructure.

AWS Lambda supports a variety of programming languages, including Java, Python, Node.js, C#, and Go. This makes it easy for developers to write code in the language they are most comfortable with, without having to learn a new language or platform.

Another advantage of AWS Lambda is that it provides automatic scaling. This means that the service adjusts the number of functions serving requests. If there is a sudden increase in traffic, AWS Lambda will scale out the number of functions to handle the load. Conversely, if there is a decrease in traffic, the service will scale in the functions to reduce costs.

AWS Lambda is also cost-effective. Developers only pay for the compute time that their code actually uses. This means that if an application isn’t in use, there are no costs associated with running it. Additionally, since AWS Lambda scales based on demand, developers can avoid over-provisioning and paying for unused resources.

That’s all fine and good, but what exactly do you use it for?

AWS Lambda Use Cases

Use Cases for AWS Lambda #1: Glue

Now I’m not talking about AWS Glue but rather using Lambda to “glue” (or “stitch” if you prefer) other AWS services together.

Why would you use Lambda for this?

A few reasons.
Lambda can bridge two services that don’t talk to each other. For instance, when an API Gateway call is made to retrieve a file from an S3 bucket, Lambda can facilitate the interaction between the two.

In some cases, the services do talk to each other, but filtering the results can be challenging. For instance, API Gateway and DynamoDB. Yes, API Gateway can talk to tables, but it’s not easy to work out how or to combine queries from several tables into a single result.

Event-driven architectures. Say you wanted to process an image after uploading to S3, you could send a notification to a queue and have an EC2 instance handle the message processing. Or do this with Lambda, because it’s only charging you when it’s running. In the same vein, you can use Lambda can act as a replacement for cron-triggered scripts, again saving money.

“Gluing” things together is a lot of the work I’ve seen/done used with lambdas as they’re quick to build & deploy and cheap to run. In most of the deployments I’ve seen, the CloudWatch bill for monitoring the lambdas was higher than the bill for the lambdas themselves.

Use Cases for AWS Lambda #2: APIs

So, you can’t use Lambda’s as APIs by themselves but put them behind either API Gateway or an ALB, and you can.
Most APIs are “call-and-response” in that a client calls an endpoint for “something,”. This could be data, to kick off background processing or anything else.

Why would you use Lambda for this?

Once again, it’s about cost and resource utilization.
Lambdas can be permanently provisioned and react in very short spaces of time. So they complete the processing and respond to the user for a much lower cost than a server or container can.

Use Cases for AWS Lambda #3: Websites:

This one is a bit out there but go with me on it.

Most “modern” websites consist of dynamically constructed pages. The pages are rendered and served in real-time, per request to the user.
Most webpages don’t do complex processing on the same thread that is serving the page to the user, as this improves the user experience.

Why would you use Lambda for this?

For exactly the same reasons as using it for the backend or an API.
You don’t have to have a server, which might only get occasional use, and instead, only pay when people are using the service. You also have a lot less to worry about when it comes to scaling to meet demand, as the lambda service does this for you.

Use Cases for AWS Lambda #4: Data Processing & ETL

This is similar to the “glue” use case but different enough that I thought it deserved its own section.
ETL (Extract, Transform, Load) is the process of taking data from one data source, changing its format or adding content, and loading it into another data storage platform.

Why would you use Lambda for this?

A couple of reasons, depending on your requirements:

Lambda can be triggered directly from other AWS services. Meaning when data is added to one of the sources, the processing starts quickly in response.
For instance, you could subscribe your Lambda to the event stream from a DynamoDB table, which allows the Lambda to start working within 1 second of the data being added.
Lambda also scales in response to demand, so if you have a period of a large volume of data being added to sources, it will be able to keep up and keep feeding your data warehouse in near-real-time.
Lambda can be called by AWS Step Functions, which allows for complex processing from multiple data sources, whilst being able to break the logic down into very small component parts. This can make the development easier to break up between team members and improve the testability of the system.

Use Cases for AWS Lambda #5: Containerized Workloads

Again, out of left field on this but bear with me.
Since Docker was added as a Lambda runtime environment, you can use Lambda to run anything you’d run in Docker.
The caveat is that it must complete within 15 minutes and use less than 10GB of RAM. I know I touched on this at the start of the article, but it’s definitely worth going into more detail on this.

Why would you use Lambda for this?

We’re back on the same benefits again – cost and complexity. I’ve done the cost thing a few times now, so I’ll skip that and go to the complexity piece instead.
Running Docker-based workloads in a highly-available manner is difficult and requires some level of orchestration (e.g. Docker Swarm, ECS or Kubernetes.
Managing the orchestration tools is a job in and of itself. Yes, AWS can take some of that away in their managed services; but your engineers still need to understand how to manage the tools.
With Lambda, that goes away as it scales to meet demand. Additionally, deployment is as trivial as uploading a Docker image (though you really should be using a CI/CD setup).

Use Cases for AWS Lambda #6: ChatBots & Voice Assistants

ChatBots are on almost every website these days, so I don’t think I need to explain them. If you have a customer service setup of some sort, you either already have a ChatBot on your website, or are thinking/have thought about it.

Why would you use Lambda for this?

Because it can interface using the API/SDK with things like Lex and Polly, you can use Lambda to get data from APIs or other areas of your infrastructure and send them back to the user via the bot.
I can’t promise that your users will actually like the bot, but that’s more to do with the information it’s sending back than the technology.

Closing Thoughts

The hype is more or less correct, and you can use Lambda to run almost anything for a low cost. The biggest drawback is that you have to reframe your thought process. It’s a bit of a mental jump to think about serving web pages out of the same service that you’re using to shuffle data around in your backend, but it can be done.