Cargando...
Cargando...
Run containers without managing servers — pay only for what your tasks consume.
AWS Fargate is a serverless compute engine for containers that works with both Amazon ECS and Amazon EKS, eliminating the need to provision, configure, or scale EC2 instances. It abstracts away the underlying infrastructure so you focus purely on building and running containerized applications. Fargate automatically scales compute resources, enforces task-level isolation using dedicated kernels, and integrates natively with the broader AWS ecosystem.
Remove operational burden of managing container host infrastructure while retaining the portability and density benefits of containerized workloads.
Use When
Avoid When
Serverless container execution (no EC2 management)
Core value proposition
ECS integration (EC2 and Fargate launch types)
Fargate is one of two ECS launch types
EKS integration via Fargate Profiles
Requires Fargate profile with namespace/label selectors
Fargate Spot (interruption-tolerant tasks)
Up to 70% cost savings vs on-demand Fargate
Amazon EFS persistent volume mounting
Requires platform version 1.4.0 or LATEST
Amazon EBS volume mounting (ECS tasks)
Supported for ECS Fargate tasks as of 2024; not available for EKS Fargate
AWS Graviton (ARM64) support
Fargate supports ARM64 architecture for cost and performance optimization
GPU support
GPU workloads require EC2 launch type — this is a critical exam trap
Privileged containers
Fargate enforces task-level kernel isolation; privileged mode is disallowed
DaemonSet pods (EKS)
DaemonSets are incompatible with Fargate; use managed node groups
Windows containers
Supported on ECS Fargate with specific platform versions; size limits apply
VPC networking (awsvpc network mode)
Fargate ALWAYS uses awsvpc mode — each task gets its own ENI
AWS CloudWatch Container Insights
Native observability integration
AWS X-Ray sidecar tracing
Run X-Ray daemon as sidecar container in the task definition
IAM Task Roles
Fine-grained per-task IAM permissions — different from EC2 instance profile
Secrets Manager / SSM Parameter Store injection
Inject secrets as environment variables at task startup
Auto Scaling via ECS Service Auto Scaling
Target tracking, step scaling, scheduled scaling all supported
Ephemeral storage expansion (up to 200 GB)
Requires platform version 1.4.0 or LATEST
Capacity provider strategies
Mix Fargate and Fargate Spot in a single ECS service for cost optimization
AWS PrivateLink / VPC Endpoints for ECR
Required when Fargate tasks run in private subnets without NAT Gateway
Fargate Launch Type for ECS Services
high freqThe primary integration — ECS acts as the orchestrator while Fargate provides the serverless compute. Define tasks in ECS task definitions, specify Fargate as the launch type, and ECS handles scheduling, health checks, and rolling deployments without any EC2 management.
EKS Fargate Profiles for Serverless Kubernetes
high freqFargate profiles define which Kubernetes pods (by namespace and label selectors) run on Fargate vs managed node groups. Enables serverless Kubernetes for specific workloads while retaining EC2 nodes for DaemonSets, GPU, or large-memory pods.
Private Container Registry Pull
high freqFargate tasks pull container images from ECR. In private subnets, configure ECR VPC endpoints (com.amazonaws.region.ecr.api and com.amazonaws.region.ecr.dkr) plus an S3 gateway endpoint to avoid NAT Gateway costs and keep traffic private.
Container Insights and Log Routing
high freqUse awslogs log driver to send container stdout/stderr to CloudWatch Logs. Enable Container Insights for cluster-level metrics. Use FireLens (Fluent Bit sidecar) for advanced log routing to S3, Kinesis Data Firehose, or third-party tools.
Complementary Serverless Compute Selection
high freqLambda for short-lived event-driven functions (≤15 min, ≤10 GB memory, ≤10 GB ephemeral storage). Fargate for containerized workloads, longer-running jobs, or applications requiring full OS-level control, specific runtimes, or >10 GB memory. They are NOT interchangeable.
Queue-Driven Batch Processing
high freqTrigger ECS tasks via EventBridge rules or Lambda when SQS queue depth grows. Fargate tasks process messages and terminate — no idle EC2 cost. ECS Service Auto Scaling with SQS-based custom metrics scales task count dynamically.
Shared Persistent Storage for Stateful Containers
high freqMount EFS file systems into Fargate tasks for shared, persistent storage across multiple tasks or task restarts. Requires Fargate platform version 1.4.0+. Common for CMS, ML model serving, and shared configuration use cases.
Mixed Capacity Provider Strategy
high freqUse ECS capacity providers to blend Fargate On-Demand, Fargate Spot, and EC2 Auto Scaling Groups in a single cluster. Optimize cost by running fault-tolerant tasks on Fargate Spot and critical tasks on Fargate On-Demand or EC2.
Blue/Green Deployment for ECS Fargate
high freqCodeDeploy integrates with ECS to perform blue/green deployments of Fargate tasks using two ALB target groups. Traffic shifts gradually (canary or linear) with automatic rollback on CloudWatch alarm breach.
Secure Secret Injection at Task Startup
high freqReference Secrets Manager ARNs or SSM Parameter Store paths in ECS task definitions. Fargate retrieves and injects secrets as environment variables before the container starts — no secrets baked into images.
Fargate ALWAYS uses awsvpc networking mode — each task gets its own Elastic Network Interface (ENI) and a private IP in your VPC. There is no host or bridge networking mode available. Security groups are applied at the task level, not the host level.
EFS mounting on Fargate REQUIRES platform version 1.4.0 or LATEST. If an exam question describes Fargate tasks needing persistent shared storage and asks about requirements, the platform version constraint is the answer differentiator.
Fargate does NOT support GPU instances, privileged containers, or DaemonSets (in EKS). Any exam scenario requiring these must use the EC2 launch type or EC2 managed node groups. This is one of the most tested Fargate limitations.
IAM Task Role vs Task Execution Role — these are DIFFERENT. The Task Execution Role is used by the Fargate agent to pull images from ECR and send logs to CloudWatch. The Task Role is the IAM role assumed by the application code INSIDE the container to call AWS APIs. Exam questions frequently test this distinction.
Fargate tasks in private subnets pulling from ECR need either a NAT Gateway OR VPC endpoints for ECR (both ecr.api and ecr.dkr endpoints) PLUS an S3 Gateway endpoint (for image layer storage). Missing any one of these causes task startup failures — a common architecture question trap.
For Kubernetes migrations to AWS, ECS+Fargate is NOT a Kubernetes-compatible solution — it uses ECS task definitions, not Kubernetes manifests. EKS+Fargate is the correct choice when retaining Kubernetes API compatibility is required. Exam questions about 'lift-and-shift Kubernetes workloads' should point to EKS.
Fargate ALWAYS uses awsvpc networking — tasks get their own ENI, security groups apply at the task level, and private subnet tasks need NAT Gateway or VPC endpoints (ECR needs ecr.api + ecr.dkr + S3 Gateway endpoints).
ECS ≠ EKS: For Kubernetes workload migrations requiring Kubernetes API compatibility, the answer is EKS (not ECS). ECS+Fargate is for ECS-native or greenfield containerized workloads. DaemonSets, GPU, and privileged containers require EC2 nodes regardless of ECS or EKS.
Task Execution Role (Fargate agent pulls images/secrets/logs) vs Task Role (your app code calls AWS APIs) — these are different IAM roles with different purposes. Task startup failures = Execution Role problem. Application permission errors = Task Role problem.
Fargate Spot tasks can be interrupted with a 2-minute warning. Design batch workloads with checkpointing or use a mix of Fargate On-Demand and Fargate Spot via capacity provider strategies. Never use Fargate Spot for latency-sensitive or stateful workloads without interruption handling.
Compute Savings Plans apply to Fargate and can reduce costs by up to 50% with 1- or 3-year commitments. Unlike EC2 Reserved Instances, Savings Plans are flexible across instance families and regions. Exam cost-optimization questions should consider Savings Plans for sustained Fargate workloads.
EKS Fargate does NOT support stateful workloads requiring persistent volumes via EBS — only EFS is supported for EKS Fargate. EBS volumes CAN be used with ECS Fargate tasks (as of 2024). Know which storage type works with which orchestrator+Fargate combination.
Fargate pricing is based on ALLOCATED vCPU and memory (what you request in the task definition), NOT actual utilization. Right-sizing task definitions is the primary lever for Fargate cost optimization — a common cost-optimization exam scenario.
Common Mistake
ECS and EKS are interchangeable when migrating existing Kubernetes workloads to Fargate
Correct
ECS uses its own orchestration model (task definitions, services, clusters) and is NOT Kubernetes-compatible. EKS is the managed Kubernetes service. If you have existing Kubernetes manifests, Helm charts, or rely on the Kubernetes API, you must use EKS — not ECS. ECS+Fargate is a great choice for greenfield or ECS-native workloads.
This is the #1 migration trap on SAP-C02 and DOP-C02. The question will describe a company with existing Kubernetes workloads wanting minimal refactoring — the correct answer is always EKS (with or without Fargate), never ECS.
Common Mistake
Fargate eliminates ALL operational overhead for Kubernetes, making self-managed Kubernetes unnecessary in all cases
Correct
EKS Fargate reduces node management overhead but introduces its own constraints: no DaemonSets, no GPU, no privileged pods, limited storage options, and potential cost increases for large-scale sustained workloads. Self-managed or managed node groups are still needed for many enterprise Kubernetes patterns. Fargate is not a universal Kubernetes replacement.
Exam questions present Fargate as a silver bullet for Kubernetes complexity. The correct answer acknowledges Fargate's constraints — DaemonSets, GPU, and Windows workloads require EC2 nodes even in EKS.
Common Mistake
Lambda and Fargate are equivalent choices for containerized microservices
Correct
Lambda has hard limits: 15-minute max execution time, 10 GB memory, 10 GB ephemeral storage, and cold start latency. Fargate supports tasks up to 16 vCPU and 120 GB memory with no execution time limit, and is better suited for long-running processes, legacy containerized apps, or workloads needing full OS control. They solve different problems.
Exam cost-optimization and architecture questions frequently offer both Lambda and Fargate as options. The differentiators are execution duration, memory requirements, container compatibility, and cold start sensitivity.
Common Mistake
Fargate tasks automatically have internet access when launched in a VPC
Correct
Fargate tasks in private subnets have NO internet access by default. You need either a NAT Gateway (for internet access) or VPC endpoints (for AWS service access like ECR, CloudWatch, Secrets Manager). Tasks in public subnets need a public IP assigned. Forgetting this causes task startup failures when pulling images from ECR.
Architecture questions about Fargate task failures or security design frequently hinge on this networking detail. The correct secure pattern is private subnets + VPC endpoints, not public subnets or NAT Gateway by default.
Common Mistake
The Fargate Task Execution Role and the Fargate Task Role serve the same purpose
Correct
The Task Execution Role is used by the Fargate INFRASTRUCTURE (the agent) to pull container images from ECR, retrieve secrets from Secrets Manager/SSM, and send logs to CloudWatch — before your application code runs. The Task Role is assumed by your APPLICATION CODE inside the container to make AWS API calls (e.g., read from S3, write to DynamoDB). Missing the Task Execution Role causes task startup failures; missing the Task Role causes application-level permission errors.
IAM role confusion is tested heavily. If a question describes 'tasks failing to start' or 'unable to pull image from ECR,' the answer is the Task Execution Role. If the question describes 'application cannot access S3,' the answer is the Task Role.
Common Mistake
Fargate can mount EBS volumes just like EC2 instances for persistent storage
Correct
EBS volume attachment for Fargate is only supported on ECS Fargate (added in 2024), NOT on EKS Fargate. For EKS Fargate, only EFS is supported for persistent storage. Additionally, EFS on ECS Fargate requires platform version 1.4.0+. Always verify the orchestrator (ECS vs EKS) before recommending a storage solution.
Storage questions are a growing area in exams. The ECS vs EKS distinction for EBS support is a new and frequently missed detail that differentiates well-prepared candidates.
Common Mistake
Fargate Spot is suitable for all production workloads because it saves 70% on costs
Correct
Fargate Spot tasks can be interrupted with only a 2-minute warning when AWS needs the capacity back. It is appropriate ONLY for fault-tolerant, stateless, and interruption-tolerant workloads like batch jobs, data processing, or CI/CD runners. Never use Fargate Spot for latency-sensitive APIs, stateful applications, or workloads without checkpointing.
Cost optimization questions may present Fargate Spot as the obvious answer for any Fargate workload. The correct approach is to evaluate fault tolerance first — Fargate Spot is only appropriate when tasks can be safely interrupted and retried.
FARGATE = 'Forget About Running & Getting Actual Task Environments' — you forget about the servers, AWS runs the environment.
Two Roles Rule: 'E before A' — Execution Role is for the Engine (Fargate agent pulling images/secrets). Application Role is for your App code inside the container.
EFS needs 1.4 — 'One Point Four Opens the Door' to persistent storage on Fargate.
DaemonSets Don't Do Fargate — if a Kubernetes workload needs DaemonSets, it needs EC2 nodes.
Private Subnet Checklist: NAT or VPC Endpoints? ECR needs THREE endpoints: ecr.api + ecr.dkr + S3 Gateway (remember 'API, DKR, S3 — the three keys to Fargate ECR').
Fargate Spot = 'Batch is Beautiful, APIs are Awful' — great for batch, terrible for latency-sensitive APIs.
CertAI Tutor · SAA-C03, SAP-C02, DOP-C02, CLF-C02 · 2026-02-21