SERVERLESS CONTAINERS / 10
AWS Fargate
Run containers without managing servers
THE BIG PICTURE
Bring containers; leave host management to AWS
- Container imageYour application + dependencies
- ECS or EKSTask / pod configuration
- Fargate computeIsolated workload
- VPC resourcesApplication traffic / AWS APIs
ECS schedules tasks and EKS schedules pods. Fargate provides isolated compute for supported workloads; you configure resources, permissions, and networking.
01Compute engine and isolation
- Fargate provides serverless compute for containers scheduled by Amazon ECS or Amazon EKS
- AWS provisions, patches and manages the underlying hosts; you select application resource needs
- Each ECS task or EKS Pod has its own virtualization boundary and does not share its kernel with others
- Containers inside the same task or Pod share that workload's resources and can run as sidecars
- You still maintain container images, application security, IAM permissions and network configuration
02Running ECS workloads
- Register a Fargate-compatible task definition with images, task CPU, memory and awsvpc networking
- An ECS task launches one or more containers together; its definition also sets roles, logs and volumes
- Use an ECS service for applications that need a desired replica count and replacement of stopped tasks
- Run standalone tasks for finite jobs; an external scheduler or workflow handles recurring runs and retries
- Deploy a new service revision to change application settings; running containers do not update themselves
03Running EKS workloads
- An EKS Fargate profile selects Pods by namespace and optional labels, with subnets and an execution role
- A Pod must match a profile when scheduled; unmatched Pods intended for Fargate can remain Pending
- EKS Fargate uses private subnets and does not assign public IPs to Pods
- Profiles are immutable; create a replacement profile before retiring the old configuration
- DaemonSets, privileged Pods, HostNetwork and HostPort are unsupported; use compatible sidecar patterns
04CPU, memory and architecture
- ECS requires task-level CPU and memory from supported pairs; not every CPU-to-memory ratio is valid
- ECS supports Linux on x86_64 or ARM64 and supported Windows versions on x86_64
- EKS Fargate supports Linux x86_64; do not assume the ECS Windows or Arm options apply to EKS
- EKS combines container requests, accounts for init containers and system overhead, then rounds to a size
- Inspect an EKS Pod's CapacityProvisioned annotation for its actual allocated and billed compute size
05Images and startup flow
- Build an image for the selected OS and CPU architecture and publish it to a reachable container registry
- On launch, Fargate obtains registry access, pulls the image and starts the workload's containers
- Private ECR pulls on ECS Linux platform 1.4 need ECR API, registry and S3 endpoints when using PrivateLink
- Small images reduce download and unpack work; image layers also consume ephemeral disk space
- SOCI lazy loading can speed supported Linux ECS tasks with indexed ECR images; measure the benefit
06Networking and ingress
- ECS Fargate uses awsvpc: each task gets a dedicated ENI with security groups and a private IP
- Containers in the same ECS task can communicate through localhost without an external load balancer
- An ECS task in a public subnet can receive a public IP; internet access also needs the correct VPC route
- Private IPv4 workloads reach external services through NAT, or supported AWS services through endpoints
- Use IP targets with ALB or NLB for Fargate workloads; allow ingress only from intended sources
07Startup and application permissions
- The ECS execution role lets Fargate pull images, send configured logs and retrieve startup secrets
- The ECS task role grants application code its AWS permissions through temporary credentials
- The EKS Pod execution role serves platform components and image pulls; containers cannot use it as an app role
- Use IAM roles for service accounts for AWS access from applications in EKS Fargate Pods
- ECS secrets injected as environment variables are read at startup; replace tasks after secret rotation
08Temporary and durable storage
- Ephemeral storage is erased when a task or Pod stops; use it for caches and scratch files
- Modern ECS platforms include ephemeral storage; compressed and unpacked images reduce usable space
- Supported Linux ECS tasks can mount EFS; EKS Fargate uses EFS with static volume provisioning
- Supported Linux ECS tasks can use task-managed EBS; EKS Fargate Pods cannot mount EBS volumes
- ECS service-managed EBS is deleted on task termination, so plan snapshots or another durable data store
09Scaling and availability
- ECS Service Auto Scaling changes the number of tasks; Fargate supplies compute for each new task
- EKS Horizontal Pod Autoscaler changes replicas; resource requests determine each Pod's Fargate size
- Run replicas across AZs and check their placement; one task or Pod is still a single failure boundary
- New capacity takes time to provision and start; leave headroom when traffic rises faster than startup
- AWS maintenance can replace workloads; ECS services recover replicas, while standalone jobs need handling
10Fargate Spot
- Fargate Spot supplies discounted spare capacity for interruption-tolerant Linux ECS tasks
- EKS Fargate and ECS Windows tasks do not support Fargate Spot
- An ECS capacity provider strategy can mix FARGATE and FARGATE_SPOT using a base and weights
- Reclaimed Spot tasks receive a two-minute warning; handle termination, save progress and retry safely
- Spot shortages delay task launches; Fargate does not automatically replace Spot with regular capacity
11Logs, metrics and troubleshooting
- ECS awslogs sends stdout and stderr to CloudWatch; FireLens can route logs to other destinations
- EKS Fargate has a managed Fluent Bit router configured with aws-logging in aws-observability
- Container Insights and application telemetry help track resource use, errors and startup behavior
- ECS Exec provides container access through Systems Manager when enabled with suitable IAM permissions
- For failed starts, inspect ECS stopped reasons or EKS events, then check images, IAM, routing and subnet IPs
12Costs and practical limits
- Billing uses provisioned vCPU, memory and additional ephemeral storage, rather than actual CPU utilization
- Compute billing starts with image download and lasts until termination; minimum durations depend on OS
- Include EKS cluster fees, load balancers, NAT, public IPv4, persistent storage, transfer and logs separately
- Right-size tasks and Pods; compare Compute Savings Plans and Spot for eligible workloads
- GPU access and privileged containers are unsupported; check regional availability, quotas and platform features
Go to the source
Use AWS documentation for current limits, availability, and pricing.