AWS 156: AWS Fargate
Why this lesson matters
Run ECS tasks or EKS pods without managing worker instances while understanding CPU-memory shapes, networking, ephemeral storage, platform versions, and cost.
Fargate is serverless compute capacity for containers used by ECS and EKS; it is not a third orchestrator and not “free because there are no servers.” AWS owns host provisioning and patching, while you still own images, task/pod resources, networking, identity, availability, data, monitoring and per-second capacity cost.
What you will be able to do
By the end, you can:
- explain aws fargate in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Run ECS tasks or EKS pods without managing worker instances while understanding CPU-memory shapes, networking, ephemeral storage, platform versions, and cost. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Fargate. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Fargate. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid calling Fargate free or serverless in a way that hides running task charges and ENI or load-balancer dependencies. |
How the request flows
+----------------------+
| Task request |
+----------------------+
|
v
+----------------------------------------------+
| Fargate CPU, memory, network, and platform |
+----------------------------------------------+
|
v
+----------------------+
| Isolated task |
+----------------------+
|
v
+-------------------------------------------+
| Runtime, cost, logs, and scale evidence |
+-------------------------------------------+For AWS Fargate, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Fargate. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Fargate. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use Fargate when per-task isolation and reduced host operations outweigh shape, feature, and cost constraints. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid calling Fargate free or serverless in a way that hides running task charges and ENI or load-balancer dependencies. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Runtime and sizing model
For ECS, choose a supported task-level vCPU/memory combination, OS/architecture and current Fargate platform version. All containers share task resources according to reservations/limits and essential behavior. Billing is based on requested vCPU, memory, supported OS duration and additional ephemeral storage from image-pull start until task termination, with minimum billing duration and prices varying by Region/platform. An over-requested idle task costs its reservation; right-size from p95/p99 plus headroom and load/failure tests.
Each ECS Fargate task uses awsvpc and gets an ENI. A public subnet only provides internet when public IP assignment and route/SG/NACL are correct; a private task needs NAT or all required endpoints/routes for ECR API/DKR, S3 image layers, Logs, Secrets/SSM/KMS and application dependencies. Tasks consume subnet IPs and ENI quotas. Platform networking is visible in VPC Flow Logs, but DNS/application TLS still need separate evidence.
Linux platform versions currently provide default ephemeral storage with configurable expansion up to current limits; pulled compressed/uncompressed image layers consume it. Ephemeral means replacement loses it. Use EFS where supported for shared persistent files or durable services/databases for state, and include mount-target/security/identity behavior. Secrets injected at startup do not rotate inside a running container automatically.
Fargate Spot discounts interruptible ECS capacity with short interruption notice; workloads need draining, idempotency, checkpointing and On-Demand base capacity where required. Savings Plans may reduce eligible steady Fargate cost. GPU, privileged containers, host access, special kernel/module and some storage/network features may require EC2 capacity; check current support instead of forcing Fargate.
EKS Fargate schedules matching pods through Fargate profiles, with one isolation VM boundary per pod and Kubernetes resource-to-supported-size rounding. DaemonSets, privileged/host features, storage and identity/add-on support differ from EC2 nodes; notably current EKS Pod Identity availability must be checked for Fargate, with IRSA often required. Fargate profiles and ECS capacity providers are unrelated constructs.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open ECS, Clusters, Services and Tasks with Fargate launch type or capacity provider; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws ecs describe-services --cluster replace-with-cluster --services replace-with-service --query 'services[].{Name:serviceName,LaunchType:launchType,Capacity:capacityProviderStrategy,Network:networkConfiguration,Running:runningCount,Desired:desiredCount}' --output json
aws ecs describe-tasks --cluster replace-with-cluster --tasks replace-with-task-arn --query 'tasks[].{LaunchType:launchType,Platform:platformVersion,Cpu:cpu,Memory:memory,Ephemeral:ephemeralStorage}' --output tableExpected interpretation
Fargate removes host management, not task networking, IAM, image, runtime, logging, scaling, availability, or application responsibility.
Practical work
Compare two steady web tasks, a 15-minute batch task, and a GPU requirement across Fargate and EC2 capacity. Calculate idle cost, operations, startup, constraints, and interruption choices.
Add ECS Managed Instances and EKS Auto Mode where applicable. Calculate requested versus observed CPU/memory, per-AZ subnet IP demand, image/ephemeral size, NAT versus VPC endpoint break-even, On-Demand/Spot interruption exposure and Savings Plans. Test unsupported CPU-memory pair, exhausted IPs, missing ECR/S3 endpoint, secret denial, disk full, OOM, Spot interruption, AZ failure and persistent-state loss.
Diagnose this topic from its own evidence
Task definition registration errors identify unsupported size/platform settings. PROVISIONING delays need Fargate capacity, quota and subnet-IP evidence. Pull/init errors need execution role plus ECR/S3/log/secret/KMS path. Exit 137/OOM needs task/container memory and application profile; disk errors need image plus ephemeral usage; no outbound traffic needs ENI route/NAT/endpoints/SG/DNS. Fargate removes node SSH, so design logs/metrics/exec and reproducible images before incidents.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Run ECS tasks or EKS pods without managing worker instances while understanding CPU-memory shapes, networking, ephemeral storage, platform versions, and cost.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Fargate.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Fargate.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid calling Fargate free or serverless in a way that hides running task charges and ENI or load-balancer dependencies.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass when the learner treats Fargate as ECS/EKS compute, chooses valid resources/platform/network/storage, separates identities, quantifies requested-cost and IP/NAT dependencies, and handles Spot/state/unsupported features. Fail if Fargate is called an orchestrator, public subnet alone is said to provide internet, ephemeral disk is durable, or host-level requirements are ignored.