App Runner vs ECS vs EKS: Which AWS Container Service Should You Pick in 2026?

Key Points:

• Short verdict: pick AWS App Runner for a handful of stateless HTTP services you want live today, Amazon ECS on Fargate for most production container workloads with no Kubernetes ambitions, and Amazon EKS when you need the Kubernetes ecosystem (operators, Helm-packaged vendor software, service mesh, KEDA, Argo) or portability across clouds and on-prem.
• Cost shape differs by service, not just by price. App Runner bills provisioned memory plus active CPU per request, ECS adds no charge for the orchestrator on EC2 and bills Fargate per vCPU-hour and GB-hour, and EKS adds a per-cluster control-plane fee on top of your nodes. Verify every rate on the live AWS pricing pages - they change.
• The real cost of EKS is day-2 ownership, not the control plane: version upgrades on AWS's support calendar, add-on lifecycle (VPC CNI, CoreDNS, kube-proxy, EBS CSI), autoscaler tuning, ingress, secrets, and an RBAC model ECS and App Runner never asked you to design.
• You can run EKS without building a platform team, but you have to choose who plays that role: a small internal platform team, an internal developer platform like Qovery, or an outsourced managed-Kubernetes service. Handing raw kubectl to application teams is the option that quietly costs the most.
• Qovery runs on your own AWS account (BYOC), so the cluster, the data and the bill stay yours and Savings Plans keep applying, while developers get git-push deploys, preview environments per pull request, environment auto-stop for non-prod, per-environment RBAC and managed cluster upgrades. The same model works on GCP, Azure, Scaleway, or a Kubernetes cluster you already run.

---

I keep having the same conversation with CTOs. A team picked EKS for four services because "we'll scale into it," and six months later one of their best engineers is doing nothing but babysitting the cluster. They didn't decide to hire a platform team. They backed into one.

So here is the verdict before any explanation. Pick AWS App Runner for simple stateless HTTP services and internal tools you want running today. Pick Amazon ECS on Fargate as the default for most production container workloads on AWS when you have no Kubernetes-specific requirement. Pick Amazon EKS only when you genuinely need the Kubernetes ecosystem - operators and CRDs, Helm-packaged vendor software, a service mesh, event-driven scaling, or parity with on-prem and other clouds. And whichever you pick, decide the developer deploy experience as a separate question, because that is the one teams forget until it hurts.

App Runner vs ECS vs EKS: which one should you actually pick?

App Runner hides the cluster entirely, ECS hides the control plane, and EKS hides only the Kubernetes masters and hands you everything above them. That single sentence predicts most of what follows, including who ends up operating what.

Here is a decision rule you can quote in a meeting:

• Fewer than ~10 stateless HTTP services and no custom networking - App Runner.
• Containers in production, VPC integration, sidecars, batch and queue workers, no Kubernetes requirement - ECS, Fargate first.
• Helm-packaged vendor software, operators and CRDs, service mesh, KEDA-style event scaling, or parity with on-prem or another cloud - EKS.

The question that settles most debates is simple: do you need the Kubernetes API, or do you need containers to run reliably? If nobody on the team can name a Kubernetes-specific capability they actually require, you are choosing EKS for reasons that will not survive a cost review.

I see the same mis-picks over and over. EKS chosen for four services. App Runner chosen for workloads that need private VPC egress controls and long-running queue consumers it was never built for. ECS chosen by a team whose entire vendor stack ships as Helm charts, so they end up hand-translating software that was designed to be helm install-ed.

What does each AWS container service actually cost in 2026?

Lead with the cost model, not a sticker price: App Runner bills provisioned memory continuously plus CPU only while a request is being served, ECS charges nothing extra for the orchestrator and bills Fargate per vCPU-hour and GB-hour, and EKS adds a fixed per-cluster control-plane charge on top of whatever nodes you run - with a higher rate once a version moves to extended support.

As of 2026, check the live page for every figure, because AWS rates vary by region and change over time. The numbers below are US East:

• App Runner (pricing): provisioned memory at $0.007 per GB-hour and active CPU at $0.064 per vCPU-hour. Idle instances drop to the provisioned tier, so you pay memory but little CPU when nothing is being served.
• Fargate (pricing): roughly $0.04048 per vCPU-hour and $0.004445 per GB-hour. There is no additional charge for ECS itself on EC2 - you pay only for the EC2 instances.
• EKS (pricing): $0.10 per cluster per hour in standard support, rising to $0.60 per cluster per hour once a version enters extended support, plus the cost of your nodes.

The line items people forget are where real bills come from: NAT gateways at $0.045 per hour plus $0.045 per GB processed (VPC pricing), Application Load Balancers at $0.0225 per hour plus $0.008 per LCU-hour (ELB pricing), cross-AZ data transfer, ECR storage, and CloudWatch logs ingestion. These apply to all three services and often dwarf the compute line.

Watch the cluster sprawl math on EKS. One cluster per environment multiplies the control-plane fee before a single pod runs. A shared cluster with namespace plus RBAC isolation is the cheaper default for most teams.

The biggest avoidable line is usually idle non-production capacity, not the control plane. Flexera's State of the Cloud research puts self-reported cloud waste at roughly 27-30%, and staging environments running 24/7 for a team that works 40 hours a week are a classic source. Auto-stop for non-prod and ephemeral per-PR environments attack that line directly.

And then there is engineering time, which never shows up on the AWS invoice. A DIY EKS platform is engineer-months of CI/CD, ingress, secrets, observability and upgrade work that App Runner and ECS largely do for you.

What do you own on day 2 with each service?

App Runner leaves you almost nothing to operate, ECS leaves you task definitions and (on EC2) the node layer, and EKS makes you the owner of cluster version upgrades, add-ons, autoscaling, ingress, pod identity and RBAC - which is where the hidden headcount lives.

Start with upgrade pressure. Kubernetes ships roughly three minor releases a year, about one every four months. On EKS, each minor version gets 14 months of standard support, then 12 months of extended support at the higher price. A cluster you never touch does not stay still - it drifts into an extended-support bill and a security risk, and eventually AWS auto-upgrades the control plane whether you are ready or not.

Then there are the add-ons you now own: VPC CNI, CoreDNS, kube-proxy, the EBS CSI driver, the AWS Load Balancer Controller, and an autoscaler such as Karpenter or Cluster Autoscaler. Each has its own version matrix against the Kubernetes version. None of this exists on App Runner or ECS.

Most of the migration pain is really a set of one-to-one translations, and it helps to see them plainly:

• Identity: an ECS task IAM role is one field in a task definition. On EKS the equivalent is IRSA or EKS Pod Identity plus a service-account convention you design.
• Scaling: ECS Service Auto Scaling becomes a Horizontal Pod Autoscaler plus Karpenter or Cluster Autoscaler. App Runner just autoscales on concurrent requests, including to zero.
• Ingress: an ECS service wired to a target group becomes a Kubernetes Ingress plus the AWS Load Balancer Controller plus ExternalDNS for records.
• Debugging: ECS Exec becomes kubectl exec; CloudWatch Container Insights becomes whichever observability stack you now operate.

The regression nobody budgets for is developer experience. A one-step CI deploy on ECS turns into kubectl context juggling, Helm values and chart review. That tax is paid on every deploy, by every developer, forever.

Can you run EKS without building a platform team?

Yes, but only if something else plays the platform-team role: a managed-Kubernetes service that operates the cluster for you, or an internal developer platform that gives developers self-service on top of it. The failure mode is choosing EKS and assuming kubectl is a developer interface. It is an operator interface.

There are three honest staffing models. Build a small internal platform team. Buy an internal developer platform. Or outsource cluster operations to a managed-Kubernetes provider such as Fairwinds. What you cannot do is leave the work unassigned, because it does not disappear - it defaults to your most senior engineer and silently becomes their full-time job.

Here is the minimum viable platform checklist. Every item has to be owned by a named person or a product:

1. CI/CD to the cluster
2. Ingress plus TLS plus DNS
3. Secrets management
4. Per-environment isolation
5. RBAC
6. Observability
7. Cost controls
8. Preview environments
9. A documented, rehearsed upgrade path

This is not a niche concern. Kubernetes production use hit 82% of container users in the 2025 CNCF survey, and the same research keeps naming tool complexity and the skills gap as leading technical barriers. Gartner, meanwhile, predicted 80% of large software engineering organizations would have platform teams by 2026, up from 45% in 2022. The platform work is real, common, and in demand.

Make the decision before the first cluster exists. Retrofitting a deploy experience onto a live EKS estate, with services already wired up by hand, is the expensive version of this project.

Which tools give developers a simple deploy experience on ECS or EKS inside your own AWS account?

Inside your own AWS account the realistic options are an internal developer platform (Qovery), an app-model framework you operate yourself (KubeVela), a dev-and-preview environment tool (Okteto), or Argo CD plus Helm as the honest DIY baseline. A lot of tools get thrown into this comparison that do not belong in it, so let me sort the categories first, because comparing a build tool to a PaaS helps nobody.

• Internal developer platform: Qovery.
• App-model framework (you operate it): KubeVela.
• GitOps engine: Argo CD, Flux.
• Dev / preview environment tool: Okteto.
• Build tool: Earthly.
• Cluster provisioner: Cluster API, eksctl, Terraform plus EKS Blueprints.
• Managed-Kubernetes service: Fairwinds.
• External PaaS (leaves your account): Render, Railway.

Now the honest read on each:

• Qovery installs into your own AWS account (BYOC) and runs on EKS you own. Developers get git-push deployments, preview environments per pull request, environment auto-stop for non-prod, per-environment RBAC, managed cluster upgrades, and databases backed by managed cloud services. The same model also runs on GCP, Azure, Scaleway, or an existing Kubernetes cluster. Where it wins: giving app teams App Runner-like simplicity on a cluster you still control.
• AWS Copilot (docs) is the genuinely simple path if you stay on ECS. If you are not going to Kubernetes, this is often the right answer and worth naming so this article is not Kubernetes-biased.
• KubeVela is a strong OAM-based application abstraction. The catch: you operate KubeVela itself and still design the platform around it. It wins when you want to build your own opinionated platform and like owning the abstraction.
• Okteto is strongest for development and preview environments on your own cluster. It is narrower than a full path to production, and that is fine - it wins at inner-loop and PR previews.
• Argo CD or Flux plus Helm is powerful, free, and the path that most reliably produces a platform team. It wins when you want full GitOps control and have people to run it.
• Coolify is a self-hosted PaaS that shines on a VM or a Docker host. It is not an EKS abstraction, so it wins on single-node simplicity, not Kubernetes.
• Earthly gives you reproducible builds in CI. It complements every option here and replaces none.
• Cluster API, eksctl, Terraform plus EKS Blueprints are provisioning tools. They create clusters; they do not give developers a deploy experience.
• Fairwinds is managed Kubernetes plus policy and cost tooling. It outsources operations and leaves the developer deploy-UX question open for you to answer separately.
• Render and Railway are excellent products, but workloads leave your AWS account, which breaks BYOC, Savings Plans, and many compliance and data-residency requirements. They win when leaving your account is acceptable and simplicity is everything.

How do you migrate from ECS to EKS without breaking production?

Provision EKS with Terraform or an internal developer platform, translate each ECS service into Kubernetes objects, move identity and secrets, run both stacks in parallel behind Route 53 weighted records, then cut over one service at a time and delete the ECS cluster when you are done. That sequence keeps production serving traffic the whole way.

Inventory first. List every ECS service, task definition, target group, scheduled task, sidecar, and every secret in SSM Parameter Store and Secrets Manager. You cannot translate what you have not written down.

The translations are mechanical once you know them: a task definition becomes a Deployment plus a Service plus an Ingress; ECS Service Auto Scaling becomes an HPA plus Karpenter; a task IAM role becomes IRSA or EKS Pod Identity; ECS Exec becomes kubectl exec; Fargate tasks become Fargate profiles or managed node groups. For networking, use the AWS Load Balancer Controller for ALB ingress, ExternalDNS for records, and Route 53 weighted routing so both stacks can serve the same hostname during the parallel run.

Leave your data where it is. RDS and ElastiCache should not move in the same change window as compute - never migrate state and stateless workloads together. Define "done" as the ECS cluster deleted, not merely idle, or you will pay for both forever.

This is where a platform product shortens the calendar. Environment templating, per-PR preview environments to validate each ported service before cut-over, and RBAC configured from day one remove most of the manual wiring. Be honest about the timeline, though: the compute move takes weeks, but the operational ownership is forever.

When is App Runner or ECS still the better answer than EKS?

If you run a handful of stateless services, have no Kubernetes-specific requirements, and nobody is asking for operators or Helm-packaged software, App Runner or ECS on Fargate is cheaper, faster and safer than EKS - and choosing it is not a career-limiting decision.

The strong reasons to choose EKS are specific: Helm-distributed vendor software, operators and CRDs, a service mesh, KEDA-style event scaling, fine-grained bin-packing, multi-cloud or on-prem parity, and a larger hiring pool for Kubernetes skills. If one of those is a real requirement, EKS earns its keep.

The weak reasons show up in every architecture review I have sat in: resume-driven design, "everyone uses Kubernetes," and a single vendor request that could be handled another way. None of those justify the day-2 ownership.

Be fair about App Runner's limits too. It is HTTP-request-oriented, gives you less networking control than ECS, and has fewer knobs for sidecars and background workers. If you need private egress controls or long-running queue consumers, that is an ECS conversation, not an App Runner one.

There are good middle paths: ECS on Fargate with AWS Copilot, keeping ECS while you standardize CI/CD, or running EKS as one shared cluster rather than one per environment. And if you do choose EKS, decide the developer deploy layer before the first cluster exists.

Why does Qovery fit the "EKS without a platform team" case?

Qovery installs into your own AWS account, runs your workloads on EKS you own, and gives developers git-push deploys with preview environments per pull request - which is the App Runner or ECS simplicity they are about to lose, without hiring a platform team to rebuild it.

The BYOC point is the one I care most about. The cluster, the data and the bill stay in your AWS account, so Savings Plans, EDP or PPA commitments, and negotiated discounts keep applying. You are not renting someone else's margin on top of compute you could buy directly.

On the developer side, Qovery's verified capabilities are git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, per-environment RBAC, and databases backed by managed cloud services. On the operations side, it handles managed cluster upgrades and add-on lifecycle - the exact work that usually forces a platform hire after an ECS-to-EKS move.

It is cloud-agnostic by design. The same model runs on GCP, Azure, Scaleway, or a Kubernetes cluster you already operate, which matters if AWS consolidation is step one of something bigger.

When is Qovery not the right fit? If you want to own every manifest and enjoy running the platform, use Argo CD plus Helm or KubeVela. If you are staying on ECS and AWS Copilot already covers you, stay there. If you only need dev environments, Okteto is more focused. And if you are happy to move workloads out of your AWS account for a managed PaaS, Render or Railway are genuinely good. For pricing and capability details, check qovery.com and hub.qovery.com rather than taking a number from a blog post.

The verdict

Choose App Runner for a few stateless HTTP services, ECS on Fargate as the sane default for production containers on AWS, and EKS only when the Kubernetes ecosystem or multi-cloud portability is a real requirement you can name. The compute choice is the easy half. The deploy experience for your developers, and who owns the platform work on day 2, is the half that decides whether EKS makes your team faster or quietly turns your best engineer into a full-time cluster operator. Decide both on purpose, before the first cluster exists.

App Runner vs ECS vs EKS: which AWS container service should I choose?

Choose App Runner for simple stateless HTTP services and internal tools, ECS on Fargate for most production container workloads with no Kubernetes requirement, and EKS when you need the Kubernetes ecosystem (operators, Helm charts, service mesh, event-driven scaling) or portability across clouds and on-prem. The deciding question is whether you need the Kubernetes API or just need containers to run reliably. If nobody can name a Kubernetes-specific requirement, you probably do not need EKS yet.

Is AWS App Runner cheaper than ECS Fargate or EKS?

It depends on traffic shape, not list price. App Runner bills provisioned memory continuously plus CPU only while serving requests, which is efficient for spiky, low-traffic HTTP services. ECS on Fargate bills steadily per vCPU-hour and GB-hour, and EKS adds a per-cluster control-plane fee on top of nodes. For a few low-traffic services App Runner often wins; for steady high utilization, Fargate or EKS nodes can be cheaper. Always check the live AWS pricing pages, since rates vary by region and change.

Do I need a platform team to run Amazon EKS?

Not literally a team, but something has to play that role: a small internal platform group, an internal developer platform like Qovery, or an outsourced managed-Kubernetes provider. EKS makes you the owner of version upgrades, add-ons, autoscaling, ingress, pod identity and RBAC. If no person or product owns that checklist, the work defaults to your most senior engineer and becomes their full-time job.

Can developers keep a one-command deploy experience on EKS without learning kubectl and Helm?

Yes, if you put an internal developer platform in front of the cluster. Tools like Qovery give developers git-push deploys and per-PR preview environments on EKS you own, so they interact with applications rather than raw Kubernetes objects. It does not remove all Kubernetes knowledge from the organization - someone still owns the cluster - but it removes kubectl and Helm from the daily path of application developers.

Is Qovery an alternative to KubeVela, Okteto, Argo CD or AWS Copilot?

They overlap but sit in different categories. Argo CD is a GitOps engine, KubeVela is an app-model framework you operate yourself, Okteto is strongest for dev and preview environments, and AWS Copilot is ECS and App Runner tooling. Qovery is a full internal developer platform that installs into your own AWS account and covers deploys, previews, RBAC and cluster upgrades together. If you want an all-in-one path to production on a cluster you own, it replaces assembling several of those tools yourself.

Should I run one EKS cluster per environment or share clusters with namespaces?

For most teams, share clusters with namespace plus RBAC isolation. Every separate cluster adds a control-plane fee of $0.10 to $0.60 per hour before a single pod runs, so cluster-per-environment multiplies that cost and the upgrade workload. Dedicated clusters make sense for hard isolation, compliance, or blast-radius requirements, not as a default.

Do Coolify, Render or Railway work with EKS inside my own AWS account?

Not in the way teams usually hope. Coolify is a self-hosted PaaS built for VMs and Docker hosts, not an EKS abstraction. Render and Railway are strong PaaS products, but they run workloads on their own infrastructure, so your containers leave your AWS account - which breaks BYOC, Savings Plans, and data-residency requirements. If keeping workloads in your own AWS account on EKS is the goal, look at an internal developer platform like Qovery or a GitOps stack instead.