AWS Fargate: Serverless Container Compute for ECS and EKS

AWS Fargate is a compute engine for containers used by Amazon ECS and Amazon EKS. It is not a separate orchestrator: ECS services/tasks or Kubernetes pods still express desired work, while Fargate supplies isolated compute without exposing an EC2 fleet for the customer to patch or scale.

The unit of capacity changes

With EC2-backed containers, teams buy instances and then pack workloads onto them. With Fargate, they request supported CPU, memory, ephemeral storage, platform, and architecture combinations per task or pod. This removes host bin-packing and idle-node management, but poor requests can still waste money or cause throttling and out-of-memory failures. Measure real workload demand before standardizing sizes.

Security and networking

Fargate tasks use awsvpc networking and receive their own network identity. Security groups, private subnets, VPC endpoints, and least-privilege task roles remain customer responsibilities. The isolation boundary is stronger than placing unrelated containers on one customer-managed host, yet application vulnerabilities, permissive IAM, exposed listeners, and compromised images remain fully relevant.

Operations and observability

There is no host to SSH into. Diagnostics therefore depend on container logs, ECS or Kubernetes events, metrics, distributed traces, and optional runtime debugging mechanisms. Images must start cleanly, handle termination signals, expose meaningful health checks, and externalize persistent state. Platform-version changes and supported feature matrices should be reviewed before relying on a kernel capability or storage behavior.

When to choose it

Fargate works well for variable services, scheduled tasks, and teams that do not need privileged containers, host networking, custom kernel modules, or specialized instance tuning. Stable, large fleets can be cheaper or more flexible on carefully managed EC2 capacity, especially with reservations or Spot. Compare the complete operating cost and risk, not only compute price.

ECS tasks and EKS pods are not identical products

On ECS, the task definition selects a supported Fargate CPU and memory combination, runtime platform, ephemeral storage, networking, roles, and containers that share the task boundary. On EKS, a Fargate profile selects eligible pods by namespace and optional labels, and the platform maps each pod to Fargate capacity. Kubernetes daemon sets, privileged pods, and some host-oriented assumptions do not translate to that model. Check the current ECS and EKS feature matrices separately instead of assuming a Fargate feature in one orchestrator exists in the other.

Platform versions and architecture choices matter. Pin or deliberately track the supported platform behavior, test both x86_64 and ARM64 images when changing architecture, and publish a multi-platform manifest only when every referenced image was built and tested for the advertised platforms. Image pull, initialization, sidecar shutdown, and storage consumption all occur inside the billed task or pod lifecycle.

Resource sizing is the capacity plan

Fargate enforces task-level CPU and memory combinations. Container-level reservations and limits must fit inside the task. CPU starvation, memory leaks, large image extraction, temporary files, and log buffering can still cause failures even though there is no node to manage. Load-test representative requests, observe peak resident memory and throttling, and include sidecars and startup spikes. Set an explicit ephemeral-storage budget and export durable state to an external service.

Autoscaling does not resize a running task. ECS Service Auto Scaling or Kubernetes controllers add and remove replicas based on metrics and policy. Scale-out latency includes placement, image pull, and application readiness, so keep images small and choose a minimum capacity that matches the latency objective. Scale-in must respect connection draining and termination handling. Downstream concurrency, not just frontend CPU, should cap the maximum replica count.

Network path and least privilege

Every ECS Fargate task uses awsvpc networking and receives an ENI. Select subnets with enough addresses and routes, and give the task only the security-group flows it needs. A task in a public subnet does not automatically receive a public IP unless configured; a private task needs NAT or appropriate VPC endpoints to reach required services. ECR image pulls can also depend on S3 and ECR endpoints according to the documented path.

Keep the task execution role separate from the task role. The former supports platform operations such as image pull and logs; the latter belongs to application code. In EKS, use the supported pod identity mechanism rather than a broad node identity. Secrets should come from a managed source through least-privilege references, and sensitive values must not be written to logs or baked into image layers.

Diagnosis without host access

Start with orchestrator evidence: ECS stopped-task reasons and service events, or Kubernetes pod status and events. Then inspect container exit codes, health checks, logs, CPU and memory metrics, ENI and DNS behavior, IAM denials, and image architecture. ECS Exec can provide controlled interactive access when it is deliberately enabled and authorized, but it should not replace logs, metrics, traces, or a reproducible debug image.

Maintain runbooks for image-pull failure, OutOfMemoryError, failed health checks, subnet exhaustion, dependency timeout, and stuck draining. A serverless compute plane removes host patching; it does not remove the need to know which artifact ran, which identity it used, which network path failed, and how to reproduce the task configuration.

For cost review, separate steady provisioned demand from burst demand and include public IPv4 charges where applicable, NAT processing, logs, data transfer, load balancers, and idle minimum replicas. Compare those measured costs with an EC2 capacity model that includes patching, autoscaling, unused headroom, and on-call labor; a raw vCPU price comparison omits the operational trade Fargate is designed to make.

Related:

Sources: