4 posts tagged with "managed-instances"

At the end of the last post, I left you with the question ECS keeps asking that Lambda never did.

Whose server is this?

That question has exactly three answers. AWS calls them EC2, Fargate, and — the new kid — Managed Instances. Picking between them feels like the first real fork in your ECS journey, the one where you're sure you'll choose wrong and regret it for eighteen months.

Here's the reassuring part: it's less of a fork than it looks. All three run the exact same container. Same task definition, same image, same application code. The only thing that changes is who owns and babysits the box your container lands on. Get that one idea and the rest is just trade-offs.

If you've been following this series, you know what AWS Lambda Managed Instances (LMI) are and what they cost. In Part 1 we covered the overview and in Part 2 we dug into the cost model. Now it's time to answer the question that actually matters for day-to-day development: will my existing Lambda code work on LMI, and what will I need to change?

The short answer is: maybe - and possibly quite a bit.

The execution model is fundamentally different from on-demand Lambda. Don't assume your code will behave the same way - some of these differences will silently corrupt your data, and others will just make your life harder. Read through all of them before migrating anything to production.

You've likely seen the AWS launch post and are intrigued by what AWS Lambda Managed Instances (AWS LMI) can offer. You may have even read my overview of AWS LMI in an earlier blog post.

In this post, we'll look at AWS Lambda On-Demand costs, how costs change with AWS LMI, when it makes sense to use AWS LMI and when it makes sense to stick with On-Demand AWS Lambda.

You've optimized your Lambda functions six ways from Sunday, but costs are still eating your budget. AWS LMI might help.