EKS or ECS, chosen deliberately
ECS if you want fewer moving parts, EKS if you need the ecosystem or already run Kubernetes elsewhere. Both, occasionally, in different accounts.
Build
Modern app development
Containers on EKS or ECS, services split where the split pays for itself, and enough observability that a 3am page starts with evidence instead of guesswork.
EKS / ECSObservabilityTwelve-factor
What is cloud-native application development on AWS?
It means running the application in containers on a managed platform, ECS or EKS, with the infrastructure defined in code, deploys that need no maintenance window, and logs, metrics and traces wired up before launch instead of after the first incident.
The problem
Microservices are an organisational choice, not a technical upgrade
Splitting a service that one team owns usually buys you a distributed monolith: the same coupling, now over the network, with tracing homework attached. We split along team and deployment boundaries, and leave the rest alone until there is a reason.
99.9%
typical uptime target
0
downtime deploys
3
signals: logs, metrics, traces
What you get
Included in the engagement
Observability from day one
Structured logs, metrics and traces wired up before launch, not after the first incident where nobody could see anything.
Autoscaling that has been load tested
HPA and cluster scaling with thresholds derived from a real load test, so the first spike is not also the first trial.
Zero-downtime deploys
Rolling or blue-green with health checks that mean something, plus a drain that respects in-flight requests.
Application work when it helps
The same engineers can go into the codebase for the parts that block the infrastructure: connection handling, graceful shutdown, config, migrations.
How it runs
How the rebuild runs
Runtime choice is made against the team you have, not the team a conference talk assumes.
Choose the runtime
EKS or ECS, decided deliberately. Kubernetes is the right answer only when somebody is going to own it.
Twelve-factor cleanup
Config out of the image, state out of the container, health checks that mean something. This is what makes everything after it possible.
Observability before the move
Logs, metrics and traces wired up first, so a regression afterwards is visible rather than argued about.
Autoscaling under load
Scaling policies set from a load test rather than a default, including what happens when the database becomes the limit.
Zero-downtime deploys
Rolling or blue-green with automatic rollback on a failed health check, exercised in staging until it is dull.
Comparison
ECS on Fargate or EKS
Both run containers on AWS. What separates them is how much platform you want to own.
| Dimension | ECS on Fargate | EKS |
|---|---|---|
| What you operate | Task definitions and services | A Kubernetes cluster, plus add-ons and their upgrades |
| Learning curve | A day for someone who knows containers | Weeks, and it keeps going |
| Ecosystem | AWS services, and that is the list | Helm, operators, service meshes, anything Kubernetes |
| Version upkeep | AWS handles the platform | Cluster and add-on upgrades a few times a year, on their schedule |
| Portability | Tied to AWS | Manifests move, though the surrounding AWS pieces do not |
| Usually right when | One team, a handful of services, nobody wants a platform to own | You already run Kubernetes, or need the ecosystem or cluster-level multi-tenancy |
Fit
Who this is for
If none of these sound like you, say so on the call and we will tell you honestly whether this is the right piece of work to start with.
- You are running containers on hand-built EC2 nodes and it has stopped being fun.
- Deploys need a maintenance window.
- Debugging production means SSH and tail, at night.
Do we need Kubernetes?
Probably not on day one. ECS on Fargate covers a large share of workloads with a fraction of the operational surface. We recommend EKS when you need the ecosystem, multi-tenancy at the cluster level, or portability you will actually use.
What is the difference between ECS and EKS?
ECS is AWS's own container scheduler and on Fargate there are no nodes to run. EKS is managed Kubernetes: far more capability, and a cluster plus add-ons that somebody has to upgrade several times a year. Pick by how much platform you want to own.
Should we split our monolith into microservices?
Only along team and deployment boundaries. Splitting a service one team owns usually buys a distributed monolith: the same coupling, now over the network, with tracing homework attached. We leave the rest alone until there is a reason.
How do you get to zero-downtime deploys?
Rolling or blue-green releases, health checks that test something real rather than returning 200, and a drain that lets in-flight requests finish. Then a rollback path that has been run at least once outside an incident.
What observability do you set up?
Structured logs, metrics and traces, wired before launch. The test is whether a 3am page starts with evidence: which service, which release, which tenant. If answering that needs SSH, it is not done.
Do you write application code as well?
For the parts that block the infrastructure, yes: connection handling, graceful shutdown, configuration, database migrations. Full product development is a different engagement, though it is usually the same engineers.
Reference
The AWS documentation we work from
Related
Work that usually comes with this
DevOps and platform
Terraform, deployment pipelines and environments that rebuild from code. Deploys a new hire can run in their first week without supervision.
PlatformRead more
Serverless environments
Lambda, API Gateway, EventBridge and Step Functions built where they pay off, and left alone where a container is simply cheaper to run.
ServerlessRead more
Multi-tenant web apps
Pool, silo and bridge tenancy models on AWS, with per-tenant limits, isolation you can prove to an auditor, and cost attribution that adds up.
ArchitectureRead more
Send us your AWS bill
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.