Choosing Container Orchestration Across Many Client Accounts

• Does at least one other engineer besides the original setup person understand each client's container configuration well enough to debug a 2 a.m. page
• Is there a standard template for new client onboarding, or does every engagement start from a blank slate
• Can you answer, in under a minute, which clients are on which platform without checking a spreadsheet

MSPs that fail the first check are one resignation away from a client outage nobody can diagnose. Kubernetes makes this worse if only one person understands the cluster's networking and RBAC setup; ECS's simpler mental model tends to be more forgiving when knowledge is unevenly distributed across a team.

• Are you billing clients per managed endpoint, per hour, or a flat retainer, and does that model reward or punish the extra hours a Kubernetes cluster demands
• Have you priced in cluster upgrades, node patching, and version deprecations as ongoing work, not a one-time setup fee

A flat retainer that assumes ECS-level operational overhead will quietly lose money on every client you move to Kubernetes unless you renegotiate the scope. Price the platform choice into the contract, not just the initial build.

• If you run multiple clients' workloads on shared infrastructure, are namespaces, IAM roles, and network policies actually preventing cross-client access, or is isolation just a folder structure
• Has anyone tried to break the isolation on purpose, the way a penetration tester would

This is the pitfall that turns into a real incident: an MSP assumes Kubernetes namespaces are enough isolation between two clients' workloads on a shared cluster, and a misconfigured network policy lets one client's pod reach another's service. Separate clusters or separate ECS accounts per client sidestep this entirely at the cost of some efficiency.

• Can you view the health of every managed client's infrastructure from one dashboard, or does checking status mean logging into twenty separate AWS accounts
• Does your incident response process name a clear owner per client, or does everyone assume someone else has it covered

ECS's simplicity is genuinely an advantage here if your tooling investment is limited: fewer moving parts per client means less custom tooling to build. Kubernetes rewards MSPs who invest in a proper multi-cluster management layer, but that investment only pays off once you're managing enough clients to amortize it.

For any client running a subscription product, hosting typically costs about 5% of ARR and DevOps effort roughly 4% more¹². If a client's bill is running well outside that band and they're asking you to explain why, check for orphaned load balancers, oversized node pools, and idle ECS tasks before assuming the platform itself is the problem.

This is also a useful number to quote back to a client who's pushing for a cheaper setup than their workload actually needs: a hosting bill meaningfully below that range on a live production subscription product is often a sign of undersized capacity, not efficiency.

Resist the urge to pick one platform for the entire practice. Default new, unremarkable client engagements to ECS, since it's faster to staff and easier to hand off if the relationship ends. Reserve Kubernetes for clients whose workload genuinely needs its features, such as heavy autoscaling, multi-region failover, or a client-mandated platform.

Kubernetes vs. AWS ECS vs. Nomad is worth reading before you commit a client to either one, since Nomad occasionally fits a client's existing on-premises footprint better than either.

Whatever you decide client by client, keep a single internal register of which platform each account runs, who the backup engineer is, and when the setup was last reviewed. The firms that get burned aren't the ones running two platforms; they're the ones that lost track of which client is on which one.