Run Docker-compatible containers on AWS without provisioning, patching, or managing EC2 worker servers. This guide explains AWS Fargate from first principles and shows how ECS, task definitions, networking, IAM, ECR, load balancers, logging, scaling, and cost fit together.
What problem does AWS Fargate solve?
Containers need somewhere to run. With Amazon ECS on EC2 capacity, teams create and maintain EC2 instances, patch operating systems, manage cluster capacity, and ensure that enough hosts exist for tasks. With Fargate, AWS handles that infrastructure layer.
You still manage the application container, task definition, networking, security, scaling, logs, and deployment configuration. Day-to-day ownership of worker EC2 hosts is removed.
The easiest mental model
Source code → Docker image → Amazon ECR. Amazon ECS then orchestrates the workload, AWS Fargate supplies compute, and the result is a running container task.
Docker packages the application. Amazon ECS orchestrates the containers. AWS Fargate supplies the serverless compute used to run ECS tasks.
Fargate is not Docker, ECS, Lambda, or Kubernetes
Technology
What it does
Docker
Builds and runs containers.
Amazon ECR
Stores container images.
Amazon ECS
Schedules and manages container tasks and services.
AWS Fargate
Provides serverless compute capacity for containers.
AWS Lambda
Runs event-driven functions rather than long-running container services.
Amazon EKS
Provides a managed Kubernetes control plane and can use Fargate for Pod compute in supported designs.
ECS tasks, services, and Fargate
Task definition
The blueprint: container image, CPU, memory, ports, environment variables, IAM roles, logging, volumes, and other settings.
Task
A running instance of a task definition. One task can contain one or more containers.
Service
Maintains a desired number of tasks and can integrate with load balancing and auto scaling.
Fargate
The compute layer that runs those tasks without customer-managed EC2 container hosts.
Typical production architecture
A common design places an Application Load Balancer in public subnets and Fargate tasks across private subnets in multiple Availability Zones. Supporting services can include ECR, CloudWatch Logs, Secrets Manager, and private databases or APIs.
The task security group should accept application traffic from the load balancer security group instead of the entire internet.
How a Fargate task starts
Build a container image.
Push the image to Amazon ECR or another registry.
Register an ECS task definition.
Select Fargate capacity.
Choose VPC subnets and security groups.
ECS requests compute capacity from Fargate.
A task elastic network interface is created in the VPC.
The container image is pulled.
The task starts and sends logs to its configured destination.
If it belongs to an ECS service, ECS maintains the requested task count.
Fargate networking
For Amazon ECS tasks on Fargate, awsvpc networking is required. Each task receives its own elastic network interface and private IP address from the chosen subnet, and security groups attach directly to the task networking configuration.
Public subnet
A task in a public subnet can receive a public IP when required. The subnet route table must provide the necessary route to an internet gateway.
Private subnet
Private subnets are commonly preferred for application tasks. Tasks requiring outbound internet access can use a NAT Gateway. AWS PrivateLink VPC endpoints can reduce or remove some internet and NAT requirements for services such as ECR.
Security group example
security-groups.txt
ALB Security Group
Inbound:
443 from 0.0.0.0/0
Fargate Task Security Group
Inbound:
8080 from ALB-SG only
Database Security Group
Inbound:
5432 from Fargate-Task-SG only
This creates a trust chain instead of exposing every component publicly.
Task execution role vs task role
IAM role
Purpose
Task execution role
Used by ECS and Fargate for launch operations such as pulling images and sending logs when configured.
Task role
Credentials used by the application container when it calls AWS APIs such as S3, DynamoDB, SQS, or Secrets Manager.
Use an ECS service when an application must remain running. The service can maintain multiple Fargate tasks across Availability Zones and replace unhealthy or stopped tasks.
service-layout.txt
Desired count = 2
Availability Zone A → Task 1
Availability Zone B → Task 2
↑
Application Load Balancer
Service Auto Scaling can change the desired task count based on CPU, memory, request count, or custom CloudWatch metrics.
One-off jobs are also a strong Fargate use case
A Fargate workload does not need to be a permanent web service. A task can run to completion, after which its compute billing stops.
Database export, import, or environment-refresh jobs.
ETL and data-processing tasks.
Scheduled cleanup jobs.
Image or document processing.
Migration utilities.
Security scanners.
Deployment helper jobs.
Example: database refresh job
database-refresh-flow.txt
GitHub Actions
|
| OIDC / AWS API
v
Amazon ECS RunTask
|
v
AWS Fargate container
|
+----> Private production database (read/export)
+----> Private staging database (write/import)
+----> S3 temporary encrypted dump, if required
GitHub can orchestrate the workflow while the data-copy process runs inside the AWS VPC, avoiding exposure of a private database to a public CI runner.
CPU and memory
Fargate tasks use supported combinations of task-level CPU and memory. Start with the smallest combination that meets measured requirements, monitor it, and adjust. Oversizing raises cost; undersizing can produce poor performance or out-of-memory failures.
Ephemeral storage and persistent data
Treat containers as replaceable. Important state should live in a persistent service rather than only in the task filesystem. Depending on the workload, use Amazon S3, RDS, DynamoDB, EFS, or another external data service.
Fargate vs ECS on EC2
Area
Fargate
ECS on EC2
Worker servers
AWS manages them.
You manage EC2 capacity.
OS patching
No host OS management.
Your responsibility.
Capacity planning
Task-level.
Host- and task-level.
Control
Less host-level control.
More host-level flexibility.
Billing model
Allocated task resources while running.
EC2 instance capacity.
Good fit
Teams prioritizing operational simplicity.
Large steady workloads or special host requirements.
Fargate vs Lambda
Use Fargate when
Use Lambda when
You already have a containerized application.
The workload fits a function and event model.
You need a long-running service or worker.
Execution is short-lived and event-driven.
You need explicit CPU and memory sizing.
You prefer function-level serverless abstraction.
You need normal container processes and libraries.
You want minimal infrastructure configuration.
Fargate vs EKS
Fargate and Kubernetes are not direct alternatives. EKS supplies Kubernetes orchestration; Fargate supplies compute. Use ECS with Fargate for a simpler AWS-native container experience, or EKS with Fargate when Kubernetes is required and the workload fits supported Fargate Pod patterns.
Fargate Spot
Amazon ECS can use Fargate Spot capacity providers for interruption-tolerant workloads. Spot can reduce compute cost, but tasks may be interrupted when AWS needs capacity. It suits resilient workers, batch processing, stateless jobs, and other interruption-aware workloads.
How Fargate pricing works
Fargate compute cost depends on configured task resources and runtime. Application Load Balancers, NAT Gateways, public IPv4 addresses, CloudWatch Logs, ECR storage, data transfer, EFS, and other AWS services can add separate charges.
When Fargate is a good choice
Containerized APIs and web applications.
Microservices.
Background workers.
Scheduled or one-off jobs.
CI/CD helper workloads.
Private VPC database-maintenance tasks.
Teams that do not want to manage container worker hosts.
Variable workloads that scale up and down.
When Fargate may not be the best choice
Deep host access or custom kernel and host configuration is required.
The workload needs specialized hardware or unsupported capabilities.
A very large, stable workload may be more economical on carefully optimized EC2 capacity.
Kubernetes-specific features point the design toward EKS.
Security best practices
Use private subnets when public IPs are unnecessary.
Use security-group-to-security-group rules.
Use task IAM roles instead of static credentials.
Store secrets in AWS Secrets Manager or Systems Manager Parameter Store as appropriate.
Use immutable image tags or digests for controlled releases.
Scan images before deployment.
Run containers as a non-root user when possible.
Send application logs to a central destination.
Use multiple Availability Zones where resilience is required.
Common Fargate problems and troubleshooting
Problem
Common cause
Task stuck in PENDING
Capacity, configuration, quota, networking, or task-definition issue.
CannotPullContainerError
Registry access, IAM execution role, NAT or public IP, or VPC endpoint issue.
Task exits immediately
The container command finishes or the application crashes.
ALB reports unhealthy
Wrong target port, health-check path, security group, or application binding.
Cannot reach database
Security groups, route tables, DNS, subnet placement, or database listener.
OutOfMemory
Task memory is too small or application memory usage is uncontrolled.
Frequently asked questions
Is AWS Fargate the same as Docker?
No. Docker is container technology. Fargate is AWS-managed compute used to run containers.
Does Fargate use EC2 behind the scenes?
AWS operates the underlying infrastructure, but customers do not provision or manage Fargate’s worker hosts.
Do I need ECS to use Fargate?
Fargate integrates with AWS container orchestrators. Amazon ECS on Fargate is a common simpler option; Amazon EKS also supports Fargate for applicable Kubernetes workloads.
Can Fargate connect to private RDS databases?
Yes. A Fargate task has networking inside the VPC and can reach private resources when subnets, routes, DNS, and security groups permit it.
Can Fargate run only when needed?
Yes. Launch one-off ECS tasks, wait for completion, and allow them to stop.
Recommended beginner lab
Create an ECR repository.
Build a small NGINX or Node.js container.
Push the image to ECR.
Create an ECS cluster.
Register a Fargate task definition.
Create a security group.
Run one Fargate task.
Inspect its elastic network interface and private IP.
AWS Fargate is serverless compute for containers. Docker packages the application, ECR stores the image, ECS manages tasks and services, and Fargate runs those tasks without requiring customers to operate EC2 worker servers. It is a practical option for teams that want containers without host-management overhead.
No comments yet. Start the discussion.