Kubernetes or ECS for a One- or Two-Person DevOps Shop

List the client's real requirements: expected traffic pattern, whether they need multi-region failover, whether they have an existing AWS account with legacy resources you have to work around, and whether anyone on their side will maintain this after you're gone.

Most solo consultancy engagements don't need Kubernetes's feature set. Naming the actual requirement, rather than reaching for the platform you enjoy working in, is the step that keeps scope honest and keeps the eventual invoice defensible if the client ever questions why the build took as long as it did.

Estimate hours for initial setup and for a typical month of ongoing operation under both ECS and Kubernetes. Include patching, version upgrades, and the hours you'd spend if something broke at an inconvenient time.

For a one- or two-person shop, Kubernetes almost always costs more of your own time relative to ECS, because there's no large internal team to absorb the operational load between billable hours. That extra time has to be priced into the engagement or it comes out of your margin, quietly, month after month, until you notice you're effectively working for less than you quoted.

If you're hit by a bus, or just on vacation, can the client's own team, or another consultant you'd hand off to, keep the lights on with the runbook you leave behind? ECS's smaller conceptual surface area is genuinely easier for a client's in-house generalist to pick up in an emergency.

If the answer is no for either platform, that's a gap to close before launch, not an acceptable risk to carry indefinitely on a client's production system.

Default to ECS unless the client specifically needs something Kubernetes does better: heavy autoscaling across many services, portability across clouds, or an existing Kubernetes footprint you're extending rather than building from scratch.

Put the reasoning in the client proposal, not just your own notes. A client who understands why you picked ECS over Kubernetes is far less likely to ask you to rip it out later because a friend's engineer told them Kubernetes is the modern choice, or because a vendor's sales pitch made the opposite case.

Choose Kubernetes for a client only when they specifically need one of these:

• Heavy autoscaling across many services, where ECS's simpler model would leave real capacity or cost problems unsolved.
• Portability across clouds, so the same manifests can run wherever the client eventually lands.
• An existing Kubernetes footprint that you are extending rather than building from scratch.
• Otherwise stay on ECS, and put your reasoning in the client proposal so the choice is documented.

Set up monitoring, logging, and deploy automation that would make sense to a stranger, because eventually a stranger, whether a new hire or another consultant, will have to operate this. Write the README as if you're already gone.

This step matters more for a solo consultancy than for a bigger firm, because there's no internal team to catch a documentation gap before the client does. Treat this documentation as part of the deliverable you're being paid for, not an optional extra you'll get to if time allows.

For a client running a subscription product at meaningful scale, hosting spend runs close to 5% of ARR at the median and DevOps effort around 4% more¹². For a smaller client just getting started, don't chase that ratio directly, it's a benchmark for mature companies, but do use it as a sanity check once their product has real usage: a bill wildly outside that band deserves a look before you add anything new on top of it. Kubernetes vs. AWS ECS vs. Nomad covers the third option if a client's existing hardware doesn't fit either cloud-native platform cleanly.

The most common failure isn't picking the wrong platform, it's picking a platform, then quietly letting the client's setup drift out of sync with what you'd actually recommend to a new client today. A cluster or ECS service that was reasonable two years ago can accumulate manual patches, undocumented workarounds, and forgotten credentials until nobody, including you, fully understands its current state.

Schedule a standing review of every active client's infrastructure once or twice a year, even if nothing seems broken. Catching drift on your own schedule, on a quiet afternoon, is far cheaper than discovering it during an incident when the client is already upset.