Ivan CernjaAWS gives you multiple ways to run containers in production. The three main options are EKS (managed Kubernetes), ECS with EC2 instances, and ECS with Fargate. Each puts a different amount of infrastructure responsibility on your team. A fourth option, infrastructure-from-code, removes container management from the equation altogether.
Picking between them comes down to how much operational control you need and how much operational work you're willing to absorb.
EKS: managed Kubernetes on AWS
Amazon EKS runs the Kubernetes control plane for you. AWS handles the API server, etcd storage, and control plane availability across multiple availability zones. You supply the worker nodes (EC2 instances or Fargate pods) where your containers actually run.
What you manage: Worker node provisioning and patching (unless using managed node groups or Fargate), Kubernetes version upgrades, cluster networking via the VPC CNI plugin, IAM-to-Kubernetes RBAC mappings, ingress controllers, logging and monitoring pipelines, Helm charts or manifests for every workload, and the CI/CD pipeline that deploys into the cluster.
Cost profile: $0.10/hour for the control plane ($73/month), plus EC2 or Fargate costs for worker nodes. A small production cluster with three t3.medium nodes runs around $90-100/month before you add load balancers, NAT gateways, and data transfer. Costs scale linearly with node count but benefit from reserved instance pricing and Spot instances for non-critical workloads.
Complexity: High. Kubernetes has a steep learning curve, and running it well requires ongoing attention. Cluster upgrades, RBAC policies, network policies, pod security standards, and the general health of the cluster are your responsibility. Teams typically need at least one engineer with deep Kubernetes experience.
When it fits: Organizations running many services that benefit from Kubernetes-native tooling. If you have 20+ microservices, need advanced traffic management (service mesh, canary deployments, traffic splitting), or your team already has Kubernetes expertise, EKS gives you a well-supported managed control plane on AWS. The ecosystem of Helm charts, operators, and observability tools is unmatched.
ECS with EC2: AWS-native container orchestration
Amazon ECS is AWS's own container orchestration service. Instead of Kubernetes primitives (pods, deployments, services), you work with ECS concepts: task definitions, services, and clusters. When backed by EC2 instances, you manage the underlying compute that your containers run on.
What you manage: EC2 instance fleet (AMI updates, scaling, instance types), ECS cluster capacity providers, task definitions (container images, CPU/memory, environment variables, log configuration), service definitions, Application Load Balancer target groups, VPC networking, security groups, IAM task roles, and auto-scaling policies for both the EC2 fleet and ECS services.
Cost profile: No control plane fee. You pay for the EC2 instances you run, whether or not containers fully utilize them. A pair of t3.medium instances costs around $60-80/month. The gap between provisioned capacity and actual container usage is waste you optimize manually or through capacity providers. Like EKS on EC2, you benefit from reserved instances and Spot pricing.
Complexity: Moderate. ECS concepts are simpler than Kubernetes, and the AWS Console provides a more integrated experience. The trade-off is less ecosystem tooling. You won't find the equivalent of Helm, ArgoCD, or Istio for ECS. Infrastructure configuration still requires substantial Terraform or CloudFormation, but the surface area is smaller than a full Kubernetes deployment.
When it fits: Teams already invested in AWS that want container orchestration without Kubernetes. If your services are straightforward (web servers, API backends, background workers) and you don't need the advanced scheduling and traffic management that Kubernetes provides, ECS on EC2 gives you familiar AWS tooling with lower cognitive overhead.
ECS with Fargate: serverless containers
AWS Fargate is a compute engine for ECS (and EKS) that removes server management. You define your task and Fargate provisions the compute. No EC2 instances to patch, scale, or monitor.
What you manage: Task definitions, ECS service configuration, VPC and subnet setup, security groups, load balancer configuration, IAM roles, auto-scaling policies, and CloudWatch logging. The infrastructure list is shorter than EC2-backed ECS because you skip instance management, but networking and service configuration remain your responsibility.
Cost profile: You pay per vCPU-hour and per GB-hour of memory, billed per second with a one-minute minimum. A task with 0.5 vCPU and 1 GB memory costs roughly $15-18/month running continuously. Fargate is more expensive per compute unit than equivalent EC2 instances, but you eliminate the waste from underutilized instances. For variable workloads, the economics can work out better than maintaining a fixed EC2 fleet.
Complexity: Low to moderate. Fargate removes the entire node management layer, which is a meaningful reduction in operational work. You still write the same task definitions and service configurations as EC2-backed ECS. Debugging can be harder since you don't have SSH access to the underlying host.
When it fits: Teams that want managed containers without managing servers. Fargate is a good default for small-to-medium workloads on AWS where you don't need the control of EC2 or the ecosystem of Kubernetes. It pairs well with applications that have variable traffic, since you aren't paying for idle instances during quiet periods.
Comparison table
| EKS | ECS + EC2 | ECS + Fargate | Encore Cloud | |
|---|---|---|---|---|
| Control plane | Managed by AWS | Managed by AWS | Managed by AWS | Managed by Encore |
| Compute | You manage (EC2/Fargate) | You manage (EC2) | Managed by AWS | Managed by Encore |
| Networking | You configure | You configure | You configure | Automatic |
| Load balancing | You configure | You configure | You configure | Automatic |
| IAM / security | You configure | You configure | You configure | Automatic |
| Databases | Separate provisioning | Separate provisioning | Separate provisioning | Declared in code |
| Minimum complexity | High | Moderate | Low-moderate | Low |
| Control plane cost | $73/mo | Free | Free | Included in plan |
| Infrastructure config | K8s manifests + Terraform | Terraform/CloudFormation | Terraform/CloudFormation | None |
| Scaling flexibility | Very high | High | Moderate | Moderate |
| Multi-cloud | Via K8s portability | No | No | AWS + GCP |
Encore Cloud: skip container management entirely
All three AWS options require you to configure and manage container infrastructure. The differences are in degree: how many layers you handle yourself versus hand off to AWS. Even with Fargate, you're still writing task definitions, configuring networking, setting up load balancers, and managing IAM roles.
Encore Cloud takes a different approach. Instead of configuring infrastructure, you write your backend using Encore's open-source framework, and infrastructure requirements are expressed in your application code. When you deploy, Encore provisions AWS resources in your account automatically.
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic, Subscription } from "encore.dev/pubsub";
const db = new SQLDatabase("shipments", { migrations: "./migrations" });
export interface ShipmentEvent {
shipmentId: string;
status: string;
}
export const shipmentUpdates = new Topic<ShipmentEvent>("shipment-updates", {
deliveryGuarantee: "at-least-once",
});
export const createShipment = api(
{ method: "POST", path: "/shipments", expose: true },
async (req: { origin: string; destination: string }) => {
const row = await db.queryRow`
INSERT INTO shipments (origin, destination, status)
VALUES (${req.origin}, ${req.destination}, 'created')
RETURNING id`;
await shipmentUpdates.publish({
shipmentId: row.id,
status: "created",
});
return { id: row.id };
}
);
This code declares an API endpoint, a PostgreSQL database, and a Pub/Sub topic. Encore deploys it to your AWS account as ECS Fargate services, an RDS database, SQS queues, a VPC with proper subnet configuration, an Application Load Balancer with TLS, and IAM roles scoped to each service. The resources are standard AWS, visible in your console, and not locked into a proprietary runtime.
What you manage: Application code and database migrations. Encore handles networking, compute, IAM, secrets, environment isolation, and the CI/CD pipeline.
When it fits: Teams that want production-grade AWS infrastructure without the operational overhead of managing containers. If your goal is running services on AWS and not becoming experts in AWS container orchestration, infrastructure-from-code removes the configuration layer that consumes the most engineering time. You lose some of the fine-grained control that direct EKS or ECS configuration provides, which matters at large scale with specialized requirements. For most teams shipping product, that trade-off works in their favor.
Making the choice
Start with the level of control you actually need, not the level you think you might need someday.
If your team has Kubernetes expertise and runs enough services to justify the operational investment, EKS is a proven choice on AWS. The ecosystem is deep, and managed node groups plus Fargate profiles reduce the operational surface.
If you want AWS-native container orchestration without Kubernetes, ECS with EC2 gives you more cost control for steady-state workloads, while Fargate removes server management at a higher per-unit price.
If you'd rather not manage containers or infrastructure configuration at all, Encore Cloud lets you deploy to your own AWS account by writing application code. You skip task definitions, VPC configuration, and Terraform.
The best infrastructure setup is the one your team can operate confidently. Overprovisioning complexity is just as costly as overprovisioning compute.