ECS vs EKS: Which AWS Container Service Should Run Your Backend

Amazon ECS and Amazon EKS both run containers on AWS, and both can use Fargate so there are no EC2 instances to patch. ECS is AWS's own scheduler with nothing to upgrade, while EKS gives you a full Kubernetes control plane, with the ecosystem that comes with it and a version that has to move forward every year or so.

This comparison looks at a typical backend, a few HTTP services with a Postgres database, and covers cost, operations, networking and tooling on each. It also shows how Encore deploys the same code to ECS on Fargate or to EKS, so the orchestrator stays a setting rather than something baked into the application.

ECS vs EKS at a glance

Each option is covered below, starting with Encore.

Running one backend on ECS or EKS with Encore

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys into your own AWS or GCP account. On AWS, an environment runs either on Fargate behind an Application Load Balancer or on EKS, and the VPC, subnets, ECR registry, RDS database and an IAM role for each service are created from what the code declares.

A service and its database look the same whichever orchestrator runs them:

// orders/orders.go
package orders

import (
	"context"

	"encore.dev/storage/sqldb"
)

// RDS on AWS, Cloud SQL on GCP, a local Postgres under encore run.
var db = sqldb.NewDatabase("orders", sqldb.DatabaseConfig{
	Migrations: "./migrations",
})

type Order struct {
	ID         int64 `json:"id"`
	TotalCents int   `json:"totalCents"`
}

//encore:api public method=GET path=/orders/:id
func Get(ctx context.Context, id int64) (*Order, error) {
	o := &Order{ID: id}
	err := db.QueryRow(ctx,
		`SELECT total_cents FROM orders WHERE id = $1`, id,
	).Scan(&o.TotalCents)
	return o, err
}

The migration in orders/migrations creates the orders table the queries use:

-- orders/migrations/1_create_orders.up.sql
CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    total_cents INTEGER NOT NULL
);

When you create an environment, you choose Fargate or Kubernetes as the compute platform. On Fargate, each service gets a task definition, an ECS service with rolling deploys and a target group on the load balancer. On Kubernetes, Encore provisions an EKS cluster running on Fargate, or deploys into a cluster you already have, with a Deployment per service and a namespace per environment. Nothing in the code changes between the two, and encore run starts the services and a local Postgres before either is involved.

That split also keeps coding agents in application code. An agent adding an endpoint or a table never touches a task definition or a Helm chart, and which orchestrator production runs on stays a decision made in the environment settings.

Amazon ECS: AWS's own scheduler

Amazon ECS has no control plane for you to run or pay for. You register a task definition with the image, CPU, memory, environment and IAM roles, then create a service that keeps a desired number of tasks running, places them in subnets with security groups, and registers them with a load balancer target group. Tasks run on Fargate or on EC2 instances in a capacity provider.

On ECS little sits between you and AWS: there is no version to upgrade, IAM task roles map directly to services, and CloudWatch, Secrets Manager and the ALB integrate without add-ons. Everything around the task is yours to write: the VPC, the target groups, the autoscaling policies and the deploy pipeline, usually in Terraform or CloudFormation. ECS knowledge also stays on AWS, which matters if you might run on GCP one day.

Amazon EKS: managed Kubernetes

Amazon EKS runs a Kubernetes control plane for you across several Availability Zones. You deploy with standard Kubernetes objects and tools, so Helm charts, operators, Argo CD and anything else built for Kubernetes works, and your manifests can move to GKE or another cluster with modest changes.

That portability has a running cost, since per EKS pricing each cluster is $0.10 per hour while its Kubernetes version is in standard support, which lasts 14 months, and $0.60 per hour in extended support after that. Staying on supported versions means a cluster upgrade roughly every year, plus add-ons like the VPC CNI, CoreDNS and an ingress controller that move with it. EKS Auto Mode takes on node management for an extra fee per instance, but you still own the manifests and decide when the cluster moves to a new version.

Good to know

On both, the database is usually the bigger piece of setup. RDS has to sit in private subnets, the security groups have to let the tasks or pods reach it, and credentials have to reach the containers through Secrets Manager. That work is the same on ECS and EKS, and it is often what decides how long the first production deploy takes.

How to choose

Pick Encore when you want ECS on Fargate or EKS in your own AWS account with the VPC, database and IAM created from the code, and the same application code deploying to either orchestrator, or to GCP, with the compute platform chosen per environment.

Pick ECS when your team is AWS-only and wants the least to operate, and you are comfortable writing the surrounding infrastructure as code. Pick EKS when you already run Kubernetes elsewhere, depend on Helm charts or operators, or have a platform team that wants one Kubernetes API across clouds.

Related guides

• EKS vs ECS vs Fargate
• What is Amazon ECS?
• Do you need Kubernetes?
• How to deploy to AWS without Kubernetes