Fargate #

In the modern cloud computing ecosystem, containerization with Docker has become the de facto standard for packaging, deploying, and running applications consistently across environments. However, running container-based applications at production scale traditionally requires managing the underlying virtual server infrastructure (like AWS EC2). We have to configure server clusters, set up auto-scaling groups for VMs, and continuously patch operating systems.

This is where AWS Fargate comes in as a revolutionary solution: a serverless compute engine designed specifically for running containers. With Fargate, we no longer need to think about the virtual machines underneath our container clusters. The development team’s focus shifts entirely from managing servers to running application containers.


What is AWS Fargate? #

AWS Fargate is a serverless compute engine for containers that acts as the execution backend option for AWS’s two main container orchestration services:

  1. Amazon ECS (Elastic Container Service): AWS’s own container orchestration service — simple, fast, and tightly integrated with the AWS ecosystem.
  2. Amazon EKS (Elastic Kubernetes Service): The industry-standard managed Kubernetes service for running Kubernetes workloads.

When using ECS or EKS without Fargate, we must choose EC2 (VM) instance types to act as worker nodes in our cluster. We’re fully responsible for the availability and capacity of those nodes. Conversely, when we choose Fargate as the launch type, AWS abstracts away all those worker nodes. AWS dynamically provides compute power for each ECS task or EKS pod we request, then shuts it down when the task finishes.

flowchart TD
    Client["Internet Client"] -->|HTTP/HTTPS| ALB["Application Load Balancer"]
    
    subgraph VPC["Virtual Private Cloud (VPC)"]
        subgraph SubnetAZ1["Public Subnet (AZ 1)"]
            ALB
        end
        
        subgraph SubnetAZ2["Private Subnet (AZ 1)"]
            Task1["Fargate Task (MicroVM 1)<br/>IP: 10.0.1.50"]
        end
        
        subgraph SubnetAZ3["Private Subnet (AZ 2)"]
            Task2["Fargate Task (MicroVM 2)<br/>IP: 10.0.2.75"]
        end
        
        ALB -->|Route Traffic| Task1
        ALB -->|Route Traffic| Task2
        
        Task1 -.->|Save Data| EFS["AWS EFS (Persistent Storage)"]
        Task2 -.->|Save Data| EFS
    end

    Task1 -->|IAM Task Role| AWS_Services["AWS Services (S3, DynamoDB)"]
    Task2 -->|IAM Task Role| AWS_Services

Comparative Matrix: Lambda vs. Fargate vs. EC2 #

To determine when we should use Fargate versus AWS’s other compute options, let’s review the following comparison matrix:

CriteriaAWS Lambda (FaaS)AWS Fargate (Serverless Container)AWS EC2 (Virtual Machine)
Main AbstractionSingle FunctionContainer Image (Docker)Operating System (Virtual Machine)
Execution Time LimitMax 15 minutesNo limit (can be long-running)No limit
Cost ModelPer invocation & per millisecond of executionPer vCPU & RAM per second of executionFlat rate per hour/second of server uptime
Startup SpeedMilliseconds (very fast)Seconds to minutes (medium)Minutes (slow)
Protocol FlexibilityLimited (HTTP, event triggers)Free (TCP, UDP, WebSockets, etc.)Fully free
Operational OverheadNear zero (only manage code)Very low (manage containers)High (manage OS, patches, network, VMs)

Essential AWS Fargate Configuration #

Configuring Fargate correctly ensures optimal application performance and cloud budget efficiency.

1. vCPU and Memory (RAM) Allocation #

When defining a container on Fargate, we must set a rigid vCPU and memory capacity combination according to the standards AWS supports. We can’t allocate very large RAM with very small CPU.

Commonly supported capacity combinations include:

  • 0.25 vCPU: RAM allocation of 0.5 GB, 1 GB, or 2 GB.
  • 0.50 vCPU: RAM allocation of 1 GB, 2 GB, 3 GB, or 4 GB.
  • 1.00 vCPU: RAM allocation between 2 GB and 8 GB (in 1 GB increments).
  • 2.00 vCPU: RAM allocation between 4 GB and 16 GB.
  • 4.00 vCPU: RAM allocation between 8 GB and 30 GB.

2. awsvpc Network Mode #

All tasks running on AWS Fargate must use the awsvpc network mode. This is the most advanced and secure network mode in ECS.

Characteristics of awsvpc mode:

  • Each Fargate task gets its own Elastic Network Interface (ENI) inside our VPC subnet.
  • Each task gets its own private IP address, just like a normal EC2 instance.
  • We can apply traffic security rules using Security Groups granularly at the individual task level, not at the global cluster level.

3. Two Types of IAM Roles (Task Role vs. Task Execution Role) #

One of the most crucial security aspects in ECS Fargate is the separation of two distinct IAM roles:

  • Task Execution Role: The IAM role used by the AWS ECS agent to perform external administrative actions before our application container starts. For example: the permission to pull Docker images from Amazon Elastic Container Registry (ECR) and the permission to write stdout logs to Amazon CloudWatch Logs.
  • Task Role: The IAM role used by the application inside our container once running, to access other AWS services. For example: giving our Node.js code permission to read files from an Amazon S3 bucket or write data to Amazon DynamoDB.

Data Storage Integration #

Containers are ephemeral by default. When a container dies or is destroyed, all new files written in the container’s local memory are lost. Fargate provides two data storage options to address this:

Ephemeral Storage #

Each Fargate task gets 20 GB of temporary local storage for free by default (which can be increased up to 200 GB at additional cost). This storage is very fast since it sits on the host server’s local physical disk, but its contents are permanently deleted when the Fargate task is stopped or restarted. Suitable for temporary caching or file buffering before uploading to S3.

Persistent Storage with Amazon EFS #

For applications needing permanent file storage that can be safely shared across many containers at once (like a WordPress CMS or legacy applications), Fargate supports mounting Amazon Elastic File System (EFS) volumes based on the NFS protocol. Data in EFS remains safely stored even if all our Fargate containers are destroyed and replaced with new instances.


Startup Optimization with Multi-Stage Docker Builds #

Fargate container startup speed is heavily influenced by the size of the Docker image file we use. Every time Fargate spawns a new task, it must download that image from the ECR registry over the network. Gigabyte-sized images trigger slow task cold starts.

Here’s an example of a Dockerfile optimized using the Multi-Stage Build technique to produce the smallest possible image for a Node.js application.

# ==========================================
# STAGE 1: Build Stage
# ==========================================
FROM node:20-alpine AS builder

# Set the working directory inside the container
WORKDIR /app

# Copy dependency manifests
COPY package*.json ./

# Install all dependencies (including devDependencies for TypeScript/babel compilation)
RUN npm ci

# Copy the entire application source code
COPY . .

# Run the build process (e.g., compiling TypeScript to JavaScript)
RUN npm run build

# Remove development dependencies to save storage space
RUN npm prune --production

# ==========================================
# STAGE 2: Production Stage
# ==========================================
# ✓ CORRECT: Using a minimal base image (alpine) in the final stage
FROM node:20-alpine AS runner

WORKDIR /app

# Set the production environment variable
ENV NODE_ENV=production

# ✓ CORRECT: Only copying the compiled files and production dependencies from Stage 1
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package*.json ./

# Run the application as a non-root user for container security
USER node

# Set the application port
EXPOSE 3000

# Run the Node.js application
CMD ["node", "dist/index.js"]

With this Multi-Stage Build technique, development helper libraries (devDependencies) and raw TypeScript source files are discarded from the final image, shrinking the Docker image from ~800 MB to under ~120 MB. This drastically speeds up Fargate startup time.


Summary #

  • AWS Fargate is a serverless compute engine that executes Docker containers without requiring us to manage virtual servers (EC2) or worker node clusters.
  • Fargate bridges the FaaS (Lambda) gap by supporting long-running processes, free non-HTTP network protocols, and removing runtime restrictions.
  • The awsvpc network mode gives each Fargate task a dedicated ENI and unique private IP, enabling granular traffic security with Security Groups.
  • Understand the IAM role difference: the Task Execution Role is used by the ECS platform for running preparation, while the Task Role is used by our application code for SDK access.
  • Use the Multi-Stage Docker Build technique to minimize Docker image size, cutting image download time and speeding up Fargate container startup.
← Previous: Lambda   Next: SQS →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact