When does serverless stop being the answer?

AWS FOR THE REAL WORLD

⏱️

Reading time: 11 minutes

🎯

Main Learning: Most teams should stay serverless. EKS only pays off at real scale.

📝

Blog Post

Hey Reader 👋🏽
For years we told everyone the same thing: don't run Kubernetes!

And we meant it. Running k8s yourself is a second full-time job. Cluster upgrades, etcd backups, some networking plugin that falls over on a Tuesday and nobody can say why.
We're serverless people through and through. Lambda first, a queue behind it, scale to zero, go home! 💪
And when something won't fit in a function, we still don't jump to clusters. ECS on Fargate is our happy place: steady long-running jobs, containers just humming along, no servers to patch! A battle-tested service! 🥰
So consider this our plot twist: There's a point where EKS is genuinely the right move, and we want to show you exactly where that line sits.
That's this issue: what to do when serverless runs out of road!

AI agents and workflows, in plain TypeScript.

Running AI agents or long jobs in prod means retries, queues, stuff timing out. Trigger.dev handles all of it: you write normal TypeScript, it runs durably with no timeouts.

Best part: no separate service to run. It's an npm install into the repo you already have, streams output to your frontend, shows task status live, and it's properly open source.

Take a look at Trigger.dev →

This issue is sponsored by Trigger.dev.

Getting started with EKS — when serverless stops being the answer

📚 This Week's Deep Dive

EKS used to be an instant no from us. Running Kubernetes yourself means babysitting a control plane at 3am, and we'll take Lambda and a queue over that any day. But at a certain scale the math flips, and we finally get why teams reach for it.

The compute ladder

We pick compute in a fixed order. Lambda first. If the work doesn't fit a function, drop down to containers on Fargate. Small team, a handful of services? That's the whole story. Stop there, you're done.

Where it breaks

Then you scale, and the ladder snaps. A JVM service that needs 90 seconds to warm up. A model server that wants a GPU. A vendor tool that only ships as a Helm chart. None of that fits a function. Now hand 30 teams their own setup and watch one security fix turn into a pull request in 30 repos. Run hundreds of services flat out and the Fargate premium stops feeling convenient and starts feeling like money you're lighting on fire.

EKS is not self-managed Kubernetes

Here's what changed our minds. Every nightmare up top, the control plane, the etcd backups, the 3am upgrades, comes from running Kubernetes yourself. EKS hands all of it to AWS. They run the control plane across AZs and charge you ten cents an hour for it. That's 73 bucks a month. For an org with hundreds of services that's a rounding error, and the thing that used to need a whole team is now a line on the bill.

That's the part that flipped us. The rest of the post is the actual blueprint: Flux syncing everything from Git, Karpenter picking your nodes and parking most of them on Spot to gut the bill, and the trick that lets a brand-new cluster boot itself. Plus the spots where it bites.

🚀 Read the full blueprint →

📰 This Week in AWS

🔐AWS Workload Credentials Provider

You know how it goes: certs expire, and some cron job is quietly on the hook for renewing them right up until the day it isn't. AWS shipped an open-source agent that takes over. It pushes ACM certs and caches Secrets Manager secrets onto your boxes, on AWS or off, Linux or Windows, Apache or NGINX. Cert lifetimes keep getting shorter, so that's one less thing breaking at the worst possible moment.

💰AWS FinOps Agent (preview)

The bill jumps and there you are, spelunking through Cost Explorer trying to work out what happened. AWS wants an AI agent to take that off you. Ask it cost questions, let it dig for savings, and it'll chase down spend spikes on its own. It hooks into Slack and Jira, so ideally the "who blew the budget" thread sorts itself out. Preview for now, but worth a look.

That's a wrap for this one.
One thing to take with you: don't argue about whether Kubernetes is good or bad. Ask whether you've got the scale and the people to make the overhead pay off. If you have to ask, you probably don't, and that's completely fine.
Serverless first! EKS when you run out of the ladder. 😉

Catch you in the next one!

Sandro & Tobi

AWS for the Real World