Kubernetes vs. ECS When You Deploy Into a Client's Account

For the two fixed-price handoffs, ECS is usually the safer default: task definitions and services map closely to what a client's own small team, or their next contractor, can read and maintain without having run Kubernetes before. A client engineer who understands ECS after a week of onboarding is worth more to you than a technically superior setup nobody on their side can operate.

For the retainer client, where your team keeps running the infrastructure indefinitely, Kubernetes starts to make more sense once you're supporting several such retainers side by side, because one cluster and one set of operational runbooks can host workloads for multiple clients more efficiently than a separate ECS setup, stack, and on-call habit for each one.

AWS ECS is, by definition, AWS-only. If there's any chance a client migrates to Google Cloud or Azure later, or if you work across clients on different clouds, Kubernetes's portability is a real advantage: the same manifests run, with modest changes, wherever there's a conformant cluster.

But portability has a cost most agencies underestimate: someone has to actually maintain that abstraction layer, and a small team building four different products rarely has the spare capacity to keep a general-purpose Kubernetes setup current across multiple client environments. Don't buy portability you won't use.

Whichever platform you pick, write the handoff document as if the reader has never met you: how deployments are triggered, where secrets live, what happens when a pod or task crashes, and who to call if nothing in the runbook covers the failure. This matters more than the platform choice itself, because a well-documented ECS setup outlives a brilliant but undocumented Kubernetes cluster.

Include the reasoning, not just the steps. A client team that understands why you chose ECS over Kubernetes, or the reverse, is far less likely to rip it out six months later because a new hire only knows the other one.

Write the handoff document so it answers:

• How deployments are triggered, described as if the reader has never met you or seen the system before.
• Where secrets live and who is allowed to change them.
• What happens when a pod or task crashes, and what the reader should check first.
• Who to call if nothing in the runbook covers the failure.

Client-facing engineering shops rarely track hosting spend the way a product company does, but the same underlying ratios apply once a client's product reaches steady state: hosting typically lands around 5% of ARR and DevOps effort around 4% more for a subscription product¹². Use that as a sanity check when a client asks whether their infrastructure bill looks reasonable relative to what they're charging customers.

If a client's hosting spend is running well above that band on a workload you built, it's worth a short audit before you hand off: overprovisioned Kubernetes node pools and idle ECS tasks are both common, unglamorous sources of that gap.

Default to ECS for any engagement that ends with a handoff to a team that hasn't run Kubernetes, and default to Kubernetes only for retainer work where your own team operates several similar clusters and the portability or scaling features genuinely get used. Kubernetes vs. AWS ECS vs. Nomad covers a middle option worth knowing if a client's infrastructure spans both cloud and on-premises hardware.

Write the rule down for your own team, too. Agencies that let each engineer pick their favorite platform per project end up maintaining a zoo of one-off setups that nobody, including the original author a year later, remembers how to operate.

Revisit the rule once a quarter against your actual project mix. A shop that used to be all fixed-price handoffs and is drifting toward retained infrastructure work should expect its default to drift with it, and should say so out loud in a team meeting rather than letting individual engineers quietly diverge.

A five-person shop supporting four clients on two different orchestrators is really running two skill sets in parallel, and that has a staffing cost most project plans never line-item. Someone needs to be conversant enough in both ECS task definitions and Kubernetes manifests to review either kind of pull request, or you end up with silos where only one engineer can safely touch the retainer client's cluster.

Budget onboarding time accordingly when a new engineer joins mid-contract. A hire who has only worked with Kubernetes will need real ramp-up time on an ECS-based client project, and the reverse is just as true; treat the platform switch as a genuine context switch, not a five-minute README read.