4 posts tagged with "fargate"

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.

You containerized a Lambda function. Then you moved it to AWS Fargate, and it just...worked.

But here's the part I glossed over: Fargate isn't a service you deployed to. It's a launch type. When you ran that task, you had your first encounter with Amazon ECS — and you quietly accepted a bunch of defaults you didn't even know you were choosing.

So what is ECS, really?

You might be considering whether to deploy your application to a serverless service. Maybe you're an AWS customer weighing AWS Lambda (serverless functions) against AWS Fargate for Amazon ECS (serverless containers).

Your application fits within Lambda's hard constraints — 15-minute max duration, package size, payload limits, memory, and cold start latency all check out.

Is Lambda a good fit? Is it better to run on AWS Fargate?

It's an important question, especially in organizations that deploy a lot of resources to AWS. In this post, we'll work through that question with a focus on cost — and we'll cover a technique you can use to minimize the risk of getting the answer wrong.

You've bought in to using containers to package AWS Lambda functions but now you're curious...

If you had to, could you migrate that same function to AWS Fargate?