What is AWS Fargate? Serverless containers on ECS and EKS explained

What is AWS Fargate?

AWS Fargate is a serverless compute engine for containers. It runs ECS tasks and EKS pods without requiring you to provision or manage EC2 instances. You define CPU and memory at the task level, and AWS handles everything below that: hardware allocation, OS patching, container runtime, and capacity management.

The trade-off is straightforward: you give up control over the underlying host in exchange for not having to operate it.

How Fargate works

Fargate is a launch type — a deployment mode you select when creating an ECS service or EKS node group. The alternative is the EC2 launch type, where you manage an Auto Scaling group of EC2 instances that join your cluster.

With Fargate:

• You specify vCPU (0.25 to 16) and memory (0.5 to 120 GB) in the task definition
• AWS provisions isolated compute for each task using Firecracker micro-VMs, giving each task a hardware-isolated environment
• Each task gets its own Elastic Network Interface (ENI) with a private IP address in your VPC subnet
• You pay per second of vCPU and GB-memory used, billed only while the task is running

There are no instances in your account to patch, no AMIs to manage, no cluster capacity to forecast. Scaling is purely at the task level.

ECS + Fargate: key concepts

Task definition

The task definition is the blueprint for your container workload. It specifies:

• Container images and registries
• CPU and memory allocation
• Environment variables and secrets (via SSM Parameter Store or Secrets Manager)
• IAM roles (task execution role and task role)
• Logging configuration
• Port mappings

{
  "family": "api-service",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789.dkr.ecr.us-east-1.amazonaws.com/api:latest",
      "portMappings": [{"containerPort": 8080}],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/api-service",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

networkMode: awsvpc is required for Fargate. This is what enables the per-task ENI.

Service

An ECS Service keeps N copies of your task running at all times. It handles rolling deployments (drain old tasks, start new ones), integrates with Application Load Balancer target groups for traffic routing, and respects deployment configuration like maximum and minimum healthy percentages.

Cluster

A Fargate cluster is a logical grouping of services. Unlike EC2-backed clusters, there are no instances to manage — the cluster is just a namespace.

Networking in Fargate

Fargate tasks use awsvpc networking exclusively. The practical implications:

Each task gets its own ENI. Unlike EC2 where the host shares one or more ENIs across all containers, a Fargate task has a dedicated network interface with its own private IP. This means security groups attach to the task itself, not to a shared host.

Subnet placement. You specify which subnets tasks run in when creating or updating the service. Backend workloads should run in private subnets. Keep them off public subnets unless you specifically need public IP addresses — and even then, consider whether an ALB is the better answer.

Internet access for outbound calls. Tasks in private subnets reach the internet through a NAT Gateway in a public subnet. For AWS service access (ECR image pulls, CloudWatch logs, Secrets Manager), you can avoid NAT Gateway costs by creating VPC endpoints for the specific services.

Inbound traffic via ALB. The standard pattern for HTTP/S workloads is an Application Load Balancer in public subnets routing to Fargate tasks in private subnets. The ALB handles TLS termination (with ACM certificates), health checks, and target deregistration during deployments.

Security group rules follow the task ENI directly. A common mistake is misconfiguring the security group on the ALB or the tasks such that health checks fail — verify that the ALB's security group allows outbound on the container port, and the task's security group allows inbound from the ALB's security group.

Fargate vs EC2 launch type

For new workloads, Fargate is the default choice. The operational savings — no cluster capacity planning, no patching, simpler scaling — outweigh the cost premium except at high scale or for GPU workloads. At very high task density, EC2 becomes cheaper because you can pack many containers onto one instance.

Pricing

Fargate pricing (Linux/amd64, us-east-1):

• vCPU: $0.04048/hour
• Memory: $0.004445/GB/hour

Example: one task with 1 vCPU and 2 GB memory, running 24/7 for 30 days:

(1 × $0.04048 + 2 × $0.004445) × 24 × 30 = ~$32/month

Compare to a t3.medium (2 vCPU, 4 GB, $0.0416/hour on-demand = ~$30/month). At similar resource allocation, Fargate is cost-comparable or slightly higher, but eliminates all instance management overhead.

Fargate Spot offers the same compute at up to 70% discount by using spare AWS capacity. Tasks can be interrupted with a two-minute warning. Suitable for batch jobs, data processing pipelines, and fault-tolerant worker pools — not for latency-sensitive user-facing services.

IAM roles for Fargate

Fargate tasks use two distinct IAM roles:

Task execution role is used by the ECS agent, not your application code. It grants permission to:

• Pull container images from ECR
• Write logs to CloudWatch
• Read secrets from Secrets Manager or SSM Parameter Store at startup

AWS provides a managed policy for the basics: arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy. Attach it to your execution role and extend it if you reference secrets.

Task role is what your application code assumes at runtime. When your service calls S3, DynamoDB, or any other AWS API, it uses this role. Apply least privilege here — define only the specific actions and resources the service needs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

The two roles are separate so that the permissions needed to start a container (pull image, write logs) are distinct from what the running application can do. Conflating them is a common mistake that results in overly broad task permissions.

Logging with Fargate

Fargate supports three logging drivers:

awslogs sends container stdout/stderr directly to CloudWatch Logs. Zero infrastructure, works out of the box, costs $0.50/GB ingested. The most common starting point.

awsfirelens runs Fluent Bit or Fluentd as a sidecar container and routes logs to any destination: S3, Kinesis Data Firehose, Datadog, Splunk, OpenSearch. More flexible and can be configured to filter or transform logs before shipping. Adds sidecar overhead (typically 0.1 vCPU, 128 MB memory).

ADOT (AWS Distro for OpenTelemetry) runs as a sidecar collector for teams already invested in the OpenTelemetry ecosystem. Useful when you want to unify traces, metrics, and logs under a single pipeline.

Most teams start with awslogs and move to Firelens when they need log routing to a centralized platform or want to reduce CloudWatch ingestion costs by filtering at the edge.

Common Fargate patterns

API backend behind an ALB

The most common Fargate deployment: an ECS service running in private subnets, an ALB in public subnets with an ACM certificate for TLS, and a target group connecting the two. The service registers and deregisters tasks from the target group automatically on deployments.

Scheduled batch jobs

ECS Scheduled Tasks run on a cron expression via EventBridge. The task starts, does its work (nightly ETL, report generation, data sync), and stops. You pay only for the duration the task runs. No infrastructure sits idle between runs.

aws events put-rule \
  --schedule-expression "cron(0 2 * * ? *)" \
  --name nightly-etl

aws events put-targets \
  --rule nightly-etl \
  --targets "Id=1,Arn=arn:aws:ecs:us-east-1:123:cluster/my-cluster,\
RoleArn=arn:aws:iam::123:role/ecsEventsRole,\
EcsParameters={TaskDefinitionArn=arn:aws:ecs:...,LaunchType=FARGATE,...}"

Async worker pool

An ECS service consuming messages from an SQS queue, scaled by the ApproximateNumberOfMessagesVisible metric via Application Auto Scaling. When the queue depth grows, new tasks launch within seconds. When the queue drains, tasks scale back to zero (or a configured minimum). This pattern handles variable-throughput async workloads without keeping idle compute running.

# Application Auto Scaling target
ScalingPolicy:
  TargetValue: 10          # messages per task
  CustomizedMetricSpecification:
    MetricName: ApproximateNumberOfMessagesVisible
    Namespace: AWS/SQS
    QueueName: my-work-queue

Infrastructure visibility with Fargate

Fargate tasks run in your VPC subnets and attach to security groups just like EC2 instances — but because the underlying "instance" is invisible, it is easy to lose track of which services can reach which. The per-task ENI model means your network topology can include dozens of transient IP addresses that never appear in EC2 dashboards. VizCon surfaces Fargate task ENIs in your AWS network diagram alongside your other resources, making it straightforward to audit security group rules, verify that private backend services are not inadvertently reachable from the internet, and understand how your Fargate services connect to the rest of your VPC.