Cloud / AWS Fargate Interview questions

AWS Fargate is a serverless compute engine for containers. You declare the CPU and memory a workload needs, and AWS finds the capacity, runs the container, and removes it when it stops. There are no EC2 instances to choose, patch, or scale.

It is not an orchestrator on its own. Fargate is the compute layer behind Amazon ECS and Amazon EKS, which decide what runs and when. Each task or pod runs in its own isolated environment instead of sharing a kernel with other workloads.

You pay for the vCPU and memory a task requests, not for idle servers. The trade-off is less control: no SSH access to hosts, no privileged containers, and no custom AMIs.

Fargate works with Amazon ECS and Amazon EKS. AWS Batch can also run jobs on Fargate. The way you ask for Fargate differs for each.

Self-managed Kubernetes and Docker Swarm cannot use Fargate as a compute backend.

A task definition is the JSON blueprint ECS uses to launch a task. It lists the containers, images, ports, environment variables, log settings, and IAM roles. Revisions are grouped under a family such as orders-api:7.

Fargate adds a few mandatory settings: networkMode must be awsvpc, requiresCompatibilities must include FARGATE, and cpu and memory must be set at the task level.

{
  "family": "orders-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
  "containerDefinitions": [{
    "name": "api",
    "image": "111122223333.dkr.ecr.us-east-1.amazonaws.com/orders-api:1.4.2",
    "essential": true,
    "portMappings": [{"containerPort": 8080}]
  }]
}

Revisions are immutable. Editing a definition registers a new revision, and running tasks keep the revision they started with until you update the service.

Fargate only accepts fixed pairings of task-level vCPU and memory. Each CPU size has its own memory range, so you cannot mix them freely.

In the task definition, CPU is written in units (256, 512, 1024 and so on) and memory in MiB. An invalid pair fails at registration. Windows tasks start at 1 vCPU and top out at 4 vCPU.

You are billed for the size you configure, so pick the smallest combination that covers peak usage.

awsvpc gives every task its own elastic network interface (ENI) with a private IP from your subnet and its own security groups. It is the only network mode Fargate supports.

Containers in the same task share that interface, so they reach each other over localhost. Port mappings also stay simple, because each task has its own IP and there is no host port to collide on.

Two practical consequences follow:

• Every running task consumes one IP address, so subnets must be sized for peak task count including rolling deployments.
• In a public subnet the task needs assignPublicIp=ENABLED to reach the internet. In a private subnet it needs a NAT gateway or VPC endpoints.

Load balancers register tasks by IP, so target groups must use target type ip.

A platform version identifies the runtime environment a Fargate task runs on: the kernel, container runtime, and ECS agent. It decides which features the task can use.

Linux and Windows have independent numbering. The LATEST Linux version is 1.4.0 and the LATEST Windows version is 1.0.0. Version 1.4.0 is the one that brought per-task ENIs, EFS support, and configurable ephemeral storage.

AWS patches the platform by publishing new revisions of a version. A running task is never patched in place. New tasks start on the latest revision, and old ones are retired and replaced. Services handle this automatically, but standalone tasks you launched yourself have to be started again.

Both are IAM roles on a task, but they serve different callers. The execution role is used by ECS and Fargate to set the task up. The task role is used by your application code at runtime.

A frequent mistake is putting S3 or DynamoDB permissions on the execution role. The application never uses it, so the calls fail with AccessDenied.

Every Fargate task gets 20 GiB of ephemeral storage by default. On Linux platform version 1.4.0 or later you can raise it to a maximum of 200 GiB with the ephemeralStorage setting.

"ephemeralStorage": {
  "sizeInGiB": 100
}

The space is shared by the pulled image layers, each container's writable layer, and any bind-mount volumes the containers share. It exists only for the life of the task, so everything is lost when the task stops.

Storage above the default 20 GiB is billed per GB-hour. If data must outlive the task, use EFS or an EBS volume instead of growing ephemeral storage.

Fargate Spot runs ECS tasks on spare Fargate capacity at a discount of up to about 70% compared with On-Demand. The catch is that AWS can reclaim the capacity, so a task can be interrupted.

When that happens, the task gets a two-minute warning: a SIGTERM is sent to the containers, and after the stopTimeout (up to 120 seconds on Fargate) they are killed. Your code should shut down cleanly inside that window.

Spot suits workloads that tolerate interruption: batch jobs, queue workers, CI runners, and stateless services running at the same time as On-Demand tasks. It is a poor fit for a single-task service or anything holding state in memory.

You enable it through the FARGATE_SPOT capacity provider.

Fargate bills for the vCPU and memory configured on a task, charged per second with a one-minute minimum for Linux. Billing runs from the moment the image pull starts until the task terminates, so startup time costs money too.

Several levers change the rate:

Remember the costs around the task as well: NAT gateway data processing, load balancers, CloudWatch Logs ingestion, and cross-AZ traffic often add up faster than people expect.

An ECS service keeps a specified number of copies of a task definition running and replaces any that fail. It is how you run long-lived workloads such as web APIs on Fargate.

The scheduler compares desiredCount with the running count. If a task crashes, fails its health check, or is retired, the scheduler starts a replacement, possibly in another Availability Zone.

A service also handles:

• registering and deregistering tasks with an Application or Network Load Balancer
• rolling out new task definition revisions with deployment settings
• scaling the task count through Application Auto Scaling

Fargate only supports the REPLICA scheduling strategy. The DAEMON strategy, which places one task per instance, is not available because there are no instances to place on.

Use aws ecs run-task (or the equivalent API call). It starts one or more tasks that run to completion and are not restarted, which suits batch jobs and one-off scripts.

aws ecs run-task \
  --cluster prod \
  --launch-type FARGATE \
  --task-definition report-job:3 \
  --count 1 \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0a1b2c],securityGroups=[sg-0d4e5f],assignPublicIp=DISABLED}" \
  --overrides '{"containerOverrides":[{"name":"job","command":["python","run.py","--date","2026-10-01"]}]}'

The network configuration is required because of awsvpc. The overrides block lets you change the command or environment for this run without registering a new revision.

Once the essential container exits, the task moves to STOPPED and billing ends. Check stoppedReason and the container exit code to see how it went.

Fargate runs Linux tasks on X86_64 and ARM64 (AWS Graviton). Windows tasks run on X86_64 only.

You choose the architecture in the task definition:

"runtimePlatform": {
  "cpuArchitecture": "ARM64",
  "operatingSystemFamily": "LINUX"
}

ARM64 tasks are typically about 20% cheaper at the same size, and many workloads run as fast or faster. The image must match, though. If an x86 image is launched on an ARM64 task, the container fails with an exec format error.

Build multi-architecture images with docker buildx build --platform linux/amd64,linux/arm64 so one tag works for both, and check that native dependencies have ARM builds.

Fargate supports Linux and Windows Server containers. Linux is the common case and has the most features.

For Windows you pick the Windows Server version in runtimePlatform.operatingSystemFamily, such as WINDOWS_SERVER_2022_CORE or WINDOWS_SERVER_2019_FULL. It must match the Windows Server version the container image was built on.

Windows tasks differ in a few ways:

• They use platform version 1.0.0, numbered separately from Linux.
• Tasks start at 1 vCPU, so there are no 0.25 or 0.5 vCPU sizes, and the maximum is 4 vCPU.
• Only X86_64 is available, with no ARM64 and no Fargate Spot.
• The hourly rate is higher because it includes the Windows license.

Fargate has no host to SSH into, so logs have to be shipped. The simplest option is the awslogs log driver, which sends container stdout and stderr to CloudWatch Logs.

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/orders-api",
    "awslogs-region": "us-east-1",
    "awslogs-stream-prefix": "api"
  }
}

The task execution role needs logs:CreateLogStream and logs:PutLogEvents. Add logs:CreateLogGroup if you set awslogs-create-group to true.

Streams are named prefix/container-name/task-id. You can follow them live with aws logs tail /ecs/orders-api --follow. For routing to other destinations such as S3, Firehose, or third-party tools, use FireLens.

ECS Exec opens an interactive shell, or runs a single command, inside a running container without SSH or a bastion. It rides on AWS Systems Manager Session Manager.

To use it on Fargate:

1. Set enableExecuteCommand on the service or in run-task. Only tasks started afterwards get it.
2. Add the ssmmessages:CreateControlChannel, CreateDataChannel, OpenControlChannel and OpenDataChannel permissions to the task role.
3. Make sure the task can reach the SSM endpoints, through NAT or an ssmmessages VPC endpoint.
4. Install the Session Manager plugin for the AWS CLI and run the command below.

aws ecs execute-command --cluster prod --task <task-id> \
  --container api --interactive --command "/bin/sh"

It is valuable for debugging, but in production you should log the sessions to CloudWatch or S3 through the cluster's execute-command configuration.

A capacity provider strategy tells ECS where to place tasks and in what proportion. On Fargate the two providers are FARGATE (On-Demand) and FARGATE_SPOT.

Each entry has two knobs:

• base: the minimum number of tasks to run on that provider. Only one provider in a strategy can have a base.
• weight: the relative share of the remaining tasks.

capacityProviderStrategy=[
  {"capacityProvider":"FARGATE",      "base":2, "weight":1},
  {"capacityProvider":"FARGATE_SPOT", "weight":3}
]

With ten tasks, two land on FARGATE as the base. The other eight split 1:3, so about two more go On-Demand and six go to Spot. If Spot capacity dries up, the guaranteed base keeps the service available.

Reference the secret in the container's secrets block instead of putting the value in environment. ECS fetches it from AWS Secrets Manager or SSM Parameter Store when the task starts and injects it as an environment variable.

"secrets": [
  {
    "name": "DB_PASSWORD",
    "valueFrom": "arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/db-AbCdEf:password::"
  }
]

The task execution role must be allowed secretsmanager:GetSecretValue (or ssm:GetParameters) and kms:Decrypt if a customer-managed key is used.

Values are resolved only at launch. Rotating a secret does not update running tasks, so you must start new ones, for example with update-service --force-new-deployment. A task that cannot fetch the secret fails with a ResourceInitializationError.

You need a task definition with Fargate settings and an aws_ecs_service that references it with launch_type = "FARGATE" and a network configuration.

resource "aws_ecs_task_definition" "api" {
  family                   = "orders-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 512
  memory                   = 1024
  execution_role_arn       = aws_iam_role.exec.arn
  task_role_arn            = aws_iam_role.app.arn
  container_definitions    = file("api.json")
}

resource "aws_ecs_service" "api" {
  name            = "orders-api"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.api.id]
    assign_public_ip = false
  }
}

Three details trip people up. network_mode must be awsvpc, and cpu and memory must form a valid Fargate pair. The execution role pulls the image and writes logs, while the task role carries the application's own permissions. The service needs subnets and security groups because each task gets its own ENI.

Add a load_balancer block if the service sits behind an ALB, and consider lifecycle { ignore_changes = [desired_count] } when auto scaling manages the task count.

If a container marked essential: true stops, for any reason, ECS stops every other container in the task and the task moves to STOPPED. A task definition needs at least one essential container.

In a service, the scheduler then launches a replacement task. For a standalone task, it simply ends.

Containers marked essential: false can exit without affecting the rest. That is the right setting for init steps and helpers whose failure should not take the app down. Use dependsOn to control start order:

"containerDefinitions": [
  {"name": "migrate", "essential": false, ...},
  {"name": "api", "essential": true,
   "dependsOn": [{"containerName": "migrate", "condition": "SUCCESS"}]}
]

Here api starts only after migrate exits with code 0. Make log-router and monitoring sidecars essential only if you really want the task to die without them.

Both run the same ECS tasks. The difference is who manages the servers. With Fargate, AWS does. With the EC2 launch type, you run and patch a fleet of instances that ECS places tasks on.

Fargate trades flexibility for less operational work. EC2 gives you control and can be cheaper at sustained high utilization.

Choose Fargate when you would rather spend engineering time on the application than on the cluster. It is the better default for most new container workloads.

It fits especially well when:

• Traffic is spiky or unpredictable. You pay per task and there is no spare instance capacity to buy up front.
• The team is small. No AMI pipelines, patching windows, or capacity planning.
• Workloads are batch or event-driven and run briefly, so an always-on fleet would sit idle.
• Isolation matters. Each task has its own kernel boundary, which helps with multi-tenant or compliance-sensitive services.
• Tasks are small. Packing many 0.25 to 2 vCPU tasks onto instances rarely saves enough to offset the operations effort.

Start on Fargate and move a service to EC2 only when you hit a concrete limit, such as a GPU requirement or a measured cost gap at steady load.

Choose the EC2 launch type when a requirement is something Fargate cannot offer, or when sustained utilization makes managing instances worth it.

A mixed setup is common: Fargate for web services and jobs, EC2 for the one GPU or host-level workload.

An ECS task on Fargate moves through a fixed set of states. Knowing them tells you where to look when something stalls.

stateDiagram-v2
  [*] --> PROVISIONING
  PROVISIONING --> PENDING
  PENDING --> ACTIVATING
  ACTIVATING --> RUNNING
  RUNNING --> DEACTIVATING
  DEACTIVATING --> STOPPING
  STOPPING --> DEPROVISIONING
  DEPROVISIONING --> STOPPED
  STOPPED --> [*]

1. PROVISIONING: Fargate reserves capacity and creates the task's ENI in your subnet.
2. PENDING: the agent is starting; images are pulled and secrets fetched.
3. ACTIVATING: containers are started and the task is being registered with load balancers or service discovery.
4. RUNNING: the task is serving. Health checks and metrics apply.
5. DEACTIVATING: the task is being removed from load balancers and deregistered.
6. STOPPING: containers get SIGTERM, then SIGKILL after stopTimeout.
7. DEPROVISIONING: the ENI is detached and resources are released.
8. STOPPED: the task is finished. Its stoppedReason stays visible for a short time.

A task stuck in PROVISIONING or PENDING usually points to subnet IPs, image pull, or secret problems, while repeated STOPPED tasks point to application or health check failures.

From the moment you call RunTask or a service needs a new task, ECS and Fargate coordinate several steps before your code runs.

sequenceDiagram
  participant U as You or Service Scheduler
  participant E as ECS Control Plane
  participant F as Fargate
  participant V as Your VPC
  participant R as ECR / Secrets
  U->>E: RunTask (task definition, subnets, SGs)
  E->>F: Request capacity (cpu, memory, AZ)
  F->>V: Create ENI in chosen subnet
  F->>R: Pull image, fetch secrets (execution role)
  F->>F: Start containers in microVM
  F->>E: Report RUNNING
  E->>V: Register task IP with load balancer

1. ECS validates the task definition and picks a subnet and Availability Zone.
2. Fargate allocates an isolated microVM with the requested vCPU and memory.
3. An ENI is attached to the task in your subnet using your security groups.
4. The agent assumes the task execution role, pulls the image, and resolves secrets.
5. Containers start in dependsOn order and any container health checks begin.
6. The task reports RUNNING and, for a service, the target group registers its IP.

Any failure in steps 3 or 4, such as no IPs, no route to ECR, or missing permissions, shows up as a stopped task with a stoppedReason.

Every Fargate task runs in its own isolated compute environment built on Firecracker microVM technology. Tasks do not share a kernel, CPU, memory, or network interface with tasks from other customers, or with your other tasks.

That is a real difference from the EC2 launch type, where all tasks on an instance share the host kernel and rely on container namespaces and cgroups for separation.

Within a single task the boundary is softer. Containers in the same task share the task's kernel, ENI, and ephemeral storage, which is why localhost networking works between them. Put workloads with different trust levels in separate tasks, not as sidecars of each other.

Isolation also explains some Fargate limits. With no shared host there is nothing to mount or inspect, so privileged mode, host networking, and host path mounts are not offered.

The task failed to download its image before any container started. Start with aws ecs describe-tasks and read the stoppedReason. It usually names the cause.

Check these in order:

1. Network path to the registry. A task in a private subnet needs a NAT gateway, or VPC endpoints for ecr.api, ecr.dkr, an S3 gateway endpoint (layers live in S3), and logs if you use awslogs. In a public subnet, assignPublicIp must be ENABLED.
2. Security group egress. Outbound HTTPS (443) must be allowed.
3. Execution role. It needs ecr:GetAuthorizationToken, ecr:BatchGetImage, and ecr:GetDownloadUrlForLayer.
4. Image URI and tag. A typo, a deleted tag, or the wrong region or account causes a not-found error.
5. External registries. Docker Hub rate limits or missing credentials in repositoryCredentials will fail pulls.

If it only fails sometimes, suspect rate limits or a flaky NAT path rather than permissions.

A task sitting in PROVISIONING or PENDING has not yet started its containers. Work out which phase it is stuck in: networking, image pull, or secrets.

Run aws ecs describe-services and read the events list, then describe-tasks for the stopped task's stoppedReason. The service event log is often the fastest clue. If the reason says the ENI could not be created, look at the subnet and security group first.

Exit code 137 means the container received SIGKILL (128 + 9). On Fargate this is most often the out-of-memory killer, though it can also appear when a container ignores SIGTERM and ECS force-kills it after stopTimeout.

To tell which one it is:

1. Run describe-tasks and read stoppedReason. OutOfMemoryError: Container killed due to memory usage confirms OOM.
2. Check MemoryUtilization in CloudWatch Container Insights for the minutes before the kill.
3. If the memory graph is flat and the stop was a deployment, the app probably does not handle SIGTERM.

Fixes for the OOM case:

• Raise the task memory, within a valid CPU and memory pairing.
• Set a hard container memory limit lower than the task size so a leaky sidecar cannot starve the app.
• Tune the runtime. For Java, use -XX:MaxRAMPercentage=75 so the heap respects the container limit.
• Profile for leaks and unbounded caches.

ECS service auto scaling uses Application Auto Scaling to change the service's DesiredCount. Because Fargate has no instances, scaling the task count is the whole story. There is no cluster capacity to scale first.

Built-in metrics are ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization, and ALBRequestCountPerTarget. For queue consumers, publish a custom metric such as messages per task.

Scale-out is fast, but a new task still takes time to provision and pull its image. Keep a sensible minimum and use shorter scale-out than scale-in cooldowns so traffic spikes are handled without flapping.

Cost comes from task size multiplied by running time, so most savings come from smaller tasks, fewer hours, or cheaper rates.

1. Right-size tasks. Compare actual CPU and memory in Container Insights with the configured size. Compute Optimizer also gives ECS on Fargate recommendations.
2. Switch to ARM64 (Graviton). About 20% lower rates for compatible images.
3. Use Fargate Spot for fault-tolerant tasks, mixed with a small On-Demand base.
4. Buy Compute Savings Plans to cover the steady baseline.
5. Scale down off-hours with scheduled scaling, especially in dev and test environments.
6. Trim startup time. Billing starts at image pull, so smaller images save money on every launch.
7. Cut the extras. Use VPC endpoints instead of NAT for ECR and S3 traffic, and set log retention.

Do the right-sizing first. It is free and usually the largest saving, since many services run at 10-20% of the memory they reserve.

Compute Savings Plans apply to Fargate usage automatically. You commit to a dollar amount of compute per hour for one or three years, and in return the covered usage is billed at a lower rate.

The same commitment covers EC2, Lambda, and Fargate. It is not tied to a region, instance family, or operating system, so you can move workloads between services and still use the discount.

Things to know:

• Usage above the commitment is billed at normal On-Demand rates.
• Fargate Spot is priced on its own and is not discounted further by a Savings Plan.
• The commitment is in dollars, not vCPUs, so size it to your steady baseline, not your peak.
• Unused commitment is lost for that hour. Do not cover bursty usage.

A common approach is to use the plan for baseline On-Demand tasks, run extra capacity on Spot, and review coverage and utilization in Cost Explorer.

Treat interruption as a normal event, not a failure. When AWS reclaims capacity, ECS sends SIGTERM to the task's containers about two minutes before termination, and SIGKILL follows after stopTimeout (maximum 120 seconds on Fargate).

Make the application cooperate:

1. Catch SIGTERM. Stop accepting new work, finish or checkpoint what is in flight, and exit with code 0.
2. Raise stopTimeout in the container definition so the shutdown has time, up to the 120 second limit.
3. Make work idempotent. A queue message that was not deleted will return after its visibility timeout and be processed again.
4. Keep an On-Demand base. Use a capacity provider strategy with base on FARGATE so the service never drops to zero.
5. Spread the risk. Use several subnets in different Availability Zones.

You can also watch the ECS Task State Change events in EventBridge. A stop caused by Spot reclaim is reported in the task's stoppedReason, which helps you track how often it happens.

Ephemeral storage disappears with the task, so durable data needs another option. Fargate supports two: Amazon EFS and Amazon EBS.

For EFS, create mount targets in the task's subnets, allow NFS (port 2049) between the task and mount target security groups, and declare an efsVolumeConfiguration in the task definition. Access points and IAM authorization give per-service control.

Data stores like S3 or DynamoDB are often better than any disk. Prefer them when the application can use an API instead of a file system.

ECS can create and attach an encrypted EBS volume to each Fargate task when it launches. You mark the volume as configuredAtLaunch in the task definition, then supply the details when you run the task or create the service.

1. In the task definition, declare a volume with "configuredAtLaunch": true and mount it in the container with a mountPoints entry.
2. In run-task or create-service, pass volumeConfigurations with a managedEBSVolume: size, volume type, encryption, optional KMS key or snapshot.
3. Provide an ECS infrastructure IAM role that lets ECS manage the volume on your behalf.

"volumeConfigurations": [{
  "name": "data",
  "managedEBSVolume": {
    "roleArn": "arn:aws:iam::111122223333:role/ecsInfrastructureRole",
    "volumeType": "gp3",
    "sizeInGiB": 50,
    "encrypted": true,
    "filesystemType": "ext4"
  }
}]

Each volume attaches to a single task and cannot be shared. By default the volume is deleted when the task ends, so use a snapshot or terminationPolicy settings if the data must survive.

Put an Application Load Balancer (HTTP/HTTPS) or Network Load Balancer (TCP/UDP/TLS) in front of the service and register tasks through a target group with target type ip. Instance targets do not work because tasks use awsvpc and have no host instance.

flowchart LR
  C[Client] --> L["ALB in public subnets"]
  L --> T1["Task 1 IP, private subnet AZ-a"]
  L --> T2["Task 2 IP, private subnet AZ-b"]
  L --> T3["Task 3 IP, private subnet AZ-c"]

The service definition ties the pieces together:

"loadBalancers": [{
  "targetGroupArn": "arn:aws:elasticloadbalancing:...:targetgroup/api/abc123",
  "containerName": "api",
  "containerPort": 8080
}],
"healthCheckGracePeriodSeconds": 60

ECS registers each new task IP when it becomes ready and deregisters it on shutdown. The task security group must allow inbound traffic from the load balancer's security group on the container port. Set a grace period so slow-starting apps are not killed by early failed health checks.

Also match the target group's deregistration delay to the container's stopTimeout. That way in-flight requests finish before the task receives SIGKILL, and rolling deployments don't drop connections.

Both let services find each other by name. Cloud Map service discovery is plain DNS. ECS Service Connect adds a proxy sidecar that handles the connection, and it uses a Cloud Map namespace underneath.

Service Connect is the better default for service-to-service calls inside a cluster, because it avoids DNS caching surprises and gives you request metrics. Plain Cloud Map still makes sense when you need DNS records for non-ECS clients or want no proxy.

In a rolling update (the default ECS deployment), the scheduler starts tasks from the new task definition revision and stops old ones step by step until all tasks are replaced.

Two settings control the pace:

• minimumHealthyPercent (default 100): the floor of healthy tasks, as a percentage of desiredCount, during the rollout.
• maximumPercent (default 200): the ceiling of total tasks, including old and new ones.

With four tasks and the defaults, ECS can launch up to four new tasks beside the four old ones, wait for them to pass health checks, then drain the old ones. Capacity never drops below four. On Fargate there is no instance limit to block this, but you pay for the extra tasks for a few minutes and need spare subnet IPs.

Setting minimumHealthyPercent to 50 and maximumPercent to 100 replaces tasks in place with no extra cost, but at half capacity during the rollout. Pair either with the deployment circuit breaker to roll back failed releases. For traffic shifting and instant rollback, ECS also offers blue/green deployments.

The deployment circuit breaker watches a rolling deployment and stops it if new tasks keep failing, so a bad release doesn't loop forever. With rollback enabled it also returns the service to the last good revision.

flowchart TD
  A["New deployment starts"] --> B["Launch tasks from new revision"]
  B --> C{Tasks reach steady state?}
  C -- Yes --> D["Deployment completes"]
  C -- No, launches or health checks keep failing --> E{Failure threshold reached?}
  E -- No --> B
  E -- Yes --> F["Deployment marked FAILED"]
  F --> G["Roll back to last completed deployment"]

A failure is counted when a task cannot start or fails health checks. The threshold scales with the service's desired count, with a minimum of a few tasks. When it is crossed, the deployment is marked failed.

deploymentConfiguration={
  "deploymentCircuitBreaker": {"enable": true, "rollback": true}
}

Typical triggers on Fargate are a wrong image tag, a missing secret, an app that crashes at startup, or health check paths that return errors. Use it with CloudWatch alarms for application-level errors it cannot see.

Fargate tasks can be checked at two levels, and they do different jobs. A container health check runs a command inside the container. A load balancer health check makes an HTTP or TCP request to the task's IP.

"healthCheck": {
  "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
  "interval": 30,
  "timeout": 5,
  "retries": 3,
  "startPeriod": 60
}

• startPeriod gives the app time to boot before failures count.
• If an essential container turns UNHEALTHY, ECS stops the task and the service replaces it.
• The target group health check decides whether the ALB sends traffic to the task. A failing target is deregistered and, in a service, replaced.
• healthCheckGracePeriodSeconds on the service stops ECS from replacing tasks that are still warming up.

The container command must exist in the image. A distroless or scratch image without curl will report unhealthy even if the app is fine.

AWS secures the underlying host and platform. You secure what runs on it: identity, network, image, and secrets. This is the shared responsibility model.

Add VPC endpoints so traffic to AWS APIs stays off the internet, and use CloudTrail to audit who changed task definitions and services.

There is no host for a container to be privileged on. In Fargate you do not own the instance, and AWS keeps the platform locked down so tasks cannot affect it, or each other.

This shows up as concrete limits:

• privileged: true is rejected.
• No host network mode and no host path or /var/run/docker.sock mounts.
• Linux capabilities cannot be freely added. Only SYS_PTRACE is allowed to be added.
• No custom kernel modules or sysctl changes beyond what the platform exposes.

Tools that need these rights, such as Docker-in-Docker, host monitoring agents, and eBPF tools, do not work directly. Workarounds are to build images in CodeBuild instead, use rootless build tools like Kaniko, or run the workload on the EC2 launch type.

Because the microVM boundary already isolates the task, the lost flexibility is also what gives Fargate its security guarantee.

On Linux platform version 1.4.0 and later, a task's ephemeral storage is encrypted at rest with AES-256 by default, using an encryption key managed by AWS Fargate. You do nothing to turn it on.

If your compliance rules require your own key, configure a customer-managed KMS key at the cluster level through managedStorageConfiguration, using the fargateEphemeralStorageKmsKeyId setting.

aws ecs create-cluster --cluster-name secure-prod \
  --configuration 'managedStorageConfiguration={fargateEphemeralStorageKmsKeyId=arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab}'

The key policy must allow the Fargate service to use the key. Only tasks launched after the key is configured use it. Existing tasks keep the old encryption.

This covers storage inside the task. EFS and EBS volumes are encrypted separately with their own key settings, and data in transit still needs TLS.

Startup time is the sum of ENI creation, image pull, container start, and the health check delay before traffic arrives. Image pull and application boot are the parts you control.

1. Shrink the image. Use multi-stage builds, slim or distroless bases, and remove build tools and caches.
2. Use SOCI lazy loading. A Seekable OCI index lets Fargate start a container before the whole image is downloaded, which helps large images.
3. Keep ECR in the same region and use VPC endpoints so pulls take a short, fast path.
4. Cut application boot time. Lazy-load, trim startup work, and for Java consider class data sharing or AOT options.
5. Tune health checks. A startPeriod and grace period that match real boot time avoid false failures that restart tasks.
6. Scale ahead of demand. Scheduled scaling or a higher minimum hides the delay from users.

Do not rely on layer caching between tasks, since each new task may start on fresh infrastructure. Measure with the task's createdAt, pullStartedAt, pullStoppedAt, and startedAt timestamps to see where time goes.

Monitoring uses four layers: metrics, logs, events, and traces. Since you cannot install agents on the host, everything is delivered through ECS features or sidecars.

Inside a task, the task metadata endpoint v4 (from the ECS_CONTAINER_METADATA_URI_V4 variable) returns the task ARN, container stats, and network details for the application to use.

Useful alarms: running task count below desired, memory above 80%, target group unhealthy hosts, and deployment failure events.

FireLens lets you route container logs to many destinations by running a Fluent Bit (or Fluentd) sidecar called the log router. Your app container sends logs with the awsfirelens driver, and the sidecar forwards them.

You need two parts in the task definition:

{
  "name": "log_router",
  "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:stable",
  "essential": true,
  "firelensConfiguration": {"type": "fluentbit"}
},
{
  "name": "api",
  "image": "...",
  "logConfiguration": {
    "logDriver": "awsfirelens",
    "options": {
      "Name": "firehose",
      "region": "us-east-1",
      "delivery_stream": "app-logs"
    }
  }
}

The destination is chosen by the Name option. Fluent Bit supports CloudWatch, Amazon Data Firehose, S3, OpenSearch, and partner tools such as Datadog and Splunk.

You can also supply a custom config file for parsing, filtering, or multiline handling. Give the log router enough CPU and memory, because it shares the task's resources, and decide deliberately whether it is essential.

A Fargate profile tells EKS which pods should run on Fargate. When a pod is created and matches a profile's selectors (a namespace and optional labels), EKS schedules it onto Fargate instead of an EC2 worker node.

flowchart TD
  A["Pod created"] --> B{Matches a Fargate profile selector?}
  B -- Yes --> C["Mutating webhook sets scheduler to fargate-scheduler"]
  C --> D["Fargate starts a microVM sized to the pod"]
  D --> E["Pod runs on its own virtual node"]
  B -- No --> F["Default scheduler places it on EC2 nodes"]

What happens behind the scenes:

• A mutating admission webhook changes the pod's scheduler to fargate-scheduler.
• EKS launches a dedicated microVM for that pod, which appears as its own node.
• The pod is sized from the sum of its container resource requests, plus a small overhead for Kubernetes components, and rounded up to the next Fargate size.
• The profile supplies the pod execution role and the private subnets to use.

A pod that does not match any profile will not run on Fargate, even if a Fargate node exists. Always set resource requests, since they determine what you are billed.

Fargate on EKS suits stateless pods, but it removes features that rely on controlling the node. Know these before you move workloads.

DaemonSet-based tools, such as log collectors and security agents, need a replacement. Use sidecars for logging, or the platform's built-in log router for Fargate pods.

A job on Fargate is just a task started on a timer. The usual setup is Amazon EventBridge Scheduler (or an EventBridge rule) with an ECS RunTask target.

1. Create a task definition for the job with a command that exits when finished.
2. Create a schedule, for example cron(0 2 * * ? *) for 02:00 UTC daily.
3. Choose the ECS cluster, the task definition, a FARGATE launch type or capacity provider, and the network configuration.
4. Give the scheduler an IAM role allowed to call ecs:RunTask and iam:PassRole for the task roles.

You pay only while the task runs. Add a FARGATE_SPOT strategy for jobs that can retry.

For heavier needs, there are two other options:

• AWS Batch with a Fargate compute environment, which adds queues, retries, array jobs, and dependencies.
• Step Functions with the ecs:runTask.sync integration, which waits for the task and lets you branch on success or failure.

Make the job idempotent, set an alarm on STOPPED tasks with a non-zero exit code, and keep a retry policy on the schedule.

High availability on Fargate means removing single points of failure in the task layer, the network layer, and the deployment process. Fargate already manages the hosts, so the design focuses on the rest.

flowchart TD
  U[Users] --> ALB["ALB across 3 public subnets"]
  ALB --> S["ECS service, desiredCount 6"]
  S --> A["Tasks in private subnet AZ-a"]
  S --> B["Tasks in private subnet AZ-b"]
  S --> C["Tasks in private subnet AZ-c"]
  A --> D[(Database, Multi-AZ)]
  B --> D
  C --> D
  AS["Application Auto Scaling"] --> S

1. Spread across at least two Availability Zones. List private subnets from each AZ in the service. ECS balances tasks across them.
2. Run a minimum of two tasks, and more if losing one AZ must not hurt capacity. Size for N-1 AZs.
3. Use an ALB with health checks and a grace period, so only ready tasks get traffic.
4. Mix capacity. Put a base on FARGATE and let extra tasks run on FARGATE_SPOT.
5. Auto scale on CPU or request count, with a floor equal to your availability minimum.
6. Deploy safely. Rolling updates with minimumHealthyPercent 100, the circuit breaker with rollback, or blue/green.
7. Handle shutdown. Catch SIGTERM, set stopTimeout, and keep deregistration delay in line.
8. Keep state outside the task in a Multi-AZ database, EFS, S3, or a managed cache.

For regional resilience, repeat the stack in a second region behind Route 53 health-checked routing, and replicate images with ECR cross-region replication.