Skipping “what is serverless compute” — this chapter covers the concepts that matter once Fargate is running real production traffic.

A Fargate task is not “a container on a shared host” — it’s a dedicated microVM

Every Fargate task runs inside its own lightweight virtual machine, isolated at the hypervisor level using the same Firecracker microVM technology that underpins AWS Lambda — this is a fundamentally stronger isolation boundary than the shared-kernel container isolation you get running multiple containers on one EC2 instance under standard ECS-on-EC2. This distinction matters enormously for multi-tenant SaaS architectures: a noisy or compromised task on Fargate cannot see or affect another task’s kernel, memory, or CPU scheduling the way containers sharing a single EC2 host’s kernel theoretically could under certain container-escape scenarios.

Task size is the true unit of billing and scheduling, not “a container”

A Fargate task is defined by a specific vCPU and memory combination chosen from a constrained set of valid pairings — you cannot request arbitrary combinations; Fargate enforces a fixed matrix of vCPU-to-memory ratios. Billing is per-second, calculated against the task’s requested vCPU and memory for its entire running duration, regardless of actual utilization — a task provisioned for 4 vCPU that only uses 0.5 vCPU on average is billed for the full 4 vCPU the whole time it runs. This is the single most consequential cost lever in Fargate: right-sizing task definitions against real observed utilization, not against a generously padded guess, directly determines cost efficiency.

Networking mode is not optional — every task gets its own ENI

Fargate tasks always run in awsvpc network mode, meaning every single task is assigned its own Elastic Network Interface (ENI) with its own private IP address inside your VPC, exactly as if it were its own miniature EC2 instance from a networking perspective. This has real implications for security group design (security groups attach at the task level, not shared across a host) and for subnet IP address exhaustion — a large fleet of frequently-scaling Fargate tasks can consume VPC subnet IP addresses far faster than teams used to EC2-based capacity planning typically expect.

Fargate Spot is capacity-market pricing, not a discount tier

Fargate Spot offers tasks at a significant discount versus standard Fargate pricing, but in exchange, AWS can reclaim that capacity with a two-minute interruption notice when the underlying spare capacity is needed elsewhere — this is architecturally identical in spirit to EC2 Spot, just applied at the task level instead of the instance level. Workloads suitable for Spot are specifically those that tolerate abrupt termination and restart gracefully (batch processing, CI/CD runners, stateless request handling behind a load balancer with health checks) — anything holding long-lived, hard-to-resume state has no business running exclusively on Fargate Spot.

graph TB
    subgraph ECSEC2["ECS on EC2 (Shared Host Model)"]
        HOST[EC2 Instance] --> C1[Container A]
        HOST --> C2[Container B]
        HOST --> C3[Container C]
        C1 -.shared kernel.-> HOST
        C2 -.shared kernel.-> HOST
    end
    subgraph FARGATE["Fargate (MicroVM Model)"]
        T1[Task 1
Own Firecracker microVM] --> ENI1[Own ENI + IP]
        T2[Task 2
Own Firecracker microVM] --> ENI2[Own ENI + IP]
        T3[Task 3
Own Firecracker microVM] --> ENI3[Own ENI + IP]
    end
        

What actually happens, mechanically, between a task launch request and containers running production traffic.

Placement: the scheduler you never see

When you launch a Fargate task, you never choose which physical host it runs on — because there is no host from your perspective. Internally, AWS operates a large, multi-tenant fleet of capacity that it bin-packs across many customers’ tasks, using its own placement and capacity management systems that are entirely opaque to you. This is the actual mechanism behind “serverless”: the abstraction isn’t fake, it’s a genuine internal fleet-management layer AWS operates on your behalf, and the reason you can launch a task in seconds without any capacity planning is that AWS is doing that capacity planning continuously, across all customers, in aggregate.

Task startup sequence: provisioning the microVM, not just pulling an image

A Fargate task launch involves several sequential internal steps: allocating a Firecracker microVM from available capacity, attaching the task’s ENI within your VPC subnet, pulling the specified container image(s) from the registry (ECR or another configured registry), and finally starting the container processes inside the now-isolated, now-networked microVM. Image pull time is frequently the largest single component of Fargate task startup latency — this is precisely why advanced teams optimize image size and layer caching aggressively for Fargate workloads with tight cold-start requirements, since there’s no persistent host to keep a warm image cache across unrelated task launches the way there might be on a long-running EC2 instance.

Ephemeral storage internals

Every Fargate task gets ephemeral storage (a default amount, expandable up to a configurable maximum) backed by encrypted, per-task storage that exists only for the task’s lifetime — it is not shared, not persistent across task restarts, and is automatically wiped when the task stops. This is fundamentally different from an EC2 instance’s local disk, which can persist state across container restarts on the same host; a Fargate task’s ephemeral storage is exactly as ephemeral as the microVM itself.

Networking internals: how awsvpc mode actually routes traffic

Because each task has its own ENI and IP inside your VPC, traffic to and from a Fargate task flows through your VPC’s normal routing, security groups, and NACLs exactly as if the task were an EC2 instance — there’s no additional NAT or overlay layer specific to Fargate itself sitting between the task and your VPC network fabric. This is what makes Fargate tasks first-class VPC citizens capable of participating in VPC peering, PrivateLink, and Transit Gateway topologies without special-casing.

sequenceDiagram
    participant U as ECS/EKS Control Plane
    participant Cap as Fargate Capacity Fleet
    participant VM as Firecracker microVM
    participant VPC as Your VPC Subnet
    participant Reg as Container Registry

    U->>Cap: Request task placement (vCPU/mem spec)
    Cap->>Cap: Bin-pack against available capacity
    Cap->>VM: Allocate isolated microVM
    VM->>VPC: Attach dedicated ENI + private IP
    VM->>Reg: Pull container image(s)
    Reg-->>VM: Image layers delivered
    VM->>VM: Start container process(es)
    VM-->>U: Task RUNNING
        

Tracing a task from scheduling through termination, and where the lifecycle causes real production incidents at scale.

The task lifecycle states that matter operationally

A Fargate task moves through PROVISIONING (capacity being allocated, ENI being attached), PENDING (image pull and container startup in progress), RUNNING (containers actively executing), DEACTIVATING/STOPPING (graceful shutdown signal sent, a configurable stop timeout applies), and STOPPED (fully terminated, ephemeral storage wiped). The state most often mishandled operationally is the STOPPING transition — tasks that don’t handle SIGTERM gracefully within the configured stop timeout are forcibly killed (SIGKILL), which for anything mid-transaction or mid-write can produce partial, corrupted work.

Scaling lifecycle: how ECS Service Auto Scaling actually drives task count

When an ECS service configured on Fargate scales, it doesn’t reconfigure existing tasks — it launches entirely new tasks (each going through the full provisioning sequence from Chapter Two) and, on scale-in, stops existing ones. This means Fargate scaling is fundamentally a “replace the fleet’s shape,” not “resize existing units,” model — a scale-up event’s user-facing latency is bounded by full task startup time (image pull included), which is why teams with aggressive traffic spikes often pre-warm capacity via scheduled scaling ahead of known demand patterns rather than relying purely on reactive metric-based scaling.

Fargate Spot interruption lifecycle

A Spot-capacity task receives a two-minute SIGTERM-based interruption warning before reclamation — the same STOPPING mechanism as a normal scale-in, just triggered by capacity reclamation rather than a scaling decision. Well-designed Spot workloads treat every task as though it could receive this signal at any moment, checkpointing progress on batch jobs and relying on the load balancer’s health-check-driven traffic draining for request-serving workloads, so an interruption reads as a routine scale-in event rather than an outage.

Fargate’s scaling story is bounded by task startup latency and subnet capacity, not by any inherent throughput ceiling.

Startup latency is the real scaling constraint under burst load

Because scaling always means launching fresh tasks (Chapter Three), Fargate’s responsiveness to sudden traffic spikes is gated by how quickly new tasks can reach RUNNING — dominated by image pull time. Teams with strict burst-response requirements invest heavily in minimizing image size, using multi-stage builds to strip unnecessary layers, and in some cases maintaining a small baseline of always-running tasks specifically to absorb the first moments of a spike while reactive scaling catches up.

Subnet IP exhaustion is a silent scaling ceiling

Because every task consumes one IP address from its subnet for its entire lifetime, a fleet that scales into the thousands of concurrent tasks can exhaust a modestly-sized subnet’s available IP space — and when that happens, new task launches fail with a placement error that looks, at first glance, unrelated to networking at all. Advanced VPC designs for large Fargate fleets deliberately size subnets (or use secondary CIDR ranges) with headroom well beyond current peak task count, anticipating future scale rather than sizing to exactly today’s load.

Bin-packing efficiency is AWS’s problem, but task-size choice is yours

Because AWS bin-packs your tasks across its own capacity fleet, you don’t control (or need to worry about) physical host-level packing efficiency the way you would with self-managed EC2 clusters — but you do control your own cost efficiency by choosing task vCPU/memory sizes that closely match real workload needs. Right-sizing based on CloudWatch Container Insights utilization data, rather than static guesses, is the highest-leverage performance/cost lever available at the task-definition level.

Multi-AZ task placement is the default HA mechanism

An ECS service running on Fargate, configured across multiple subnets in multiple Availability Zones, has its tasks distributed across those AZs automatically by the ECS scheduler — a single AZ’s disruption takes down only the tasks placed there, not the entire service, provided the service was configured with multi-AZ subnets in the first place and desired task count is high enough that losing one AZ’s share still leaves adequate remaining capacity.

Reliability separation: AWS’s capacity fleet vs. your application’s own resilience

Fargate’s underlying capacity fleet has its own extensive redundancy that you never interact with directly, but this doesn’t eliminate your responsibility for application-level resilience — a Fargate task crashing due to an application bug is restarted by ECS according to your service’s desired-count configuration, but that restart still means a brief capacity dip and, for stateful in-flight work, potential data loss unless the application itself is designed to checkpoint or externalize state before termination.

Health checks are what actually make failover work in practice

Neither ECS nor the load balancer in front of a Fargate service will remove an unhealthy task from rotation unless health checks are correctly configured and tuned — a task that’s technically RUNNING but application-level broken (deadlocked, out of memory but not yet OOM-killed, dependent downstream service unreachable) will continue receiving traffic indefinitely without a properly configured health check catching it. This is a frequent gap in real deployments: infrastructure-level “is the container running” checks pass while the application itself is effectively down.

graph LR
    A[ECS Service
desired count: 6] --> AZ1[AZ-1: 2 tasks]
    A --> AZ2[AZ-2: 2 tasks]
    A --> AZ3[AZ-3: 2 tasks]
    AZ1 -->|AZ-1 disruption| LOST[2 tasks lost]
    LOST --> RESCHED[ECS reschedules
replacement tasks in AZ-2/AZ-3]
    RESCHED --> RESTORED[Desired count restored
across remaining AZs]
        

Task IAM roles are the correct, and only recommended, way to grant AWS permissions

Each Fargate task can be assigned its own IAM task role, scoping exactly which AWS API calls the containers inside it can make — this should always be scoped to the specific permissions that task’s application genuinely needs, never a broad shared role reused across unrelated services. Because each task is already hypervisor-isolated, a well-scoped task role is what closes the remaining gap: even if a container is compromised, its blast radius is limited to whatever that specific task role permits.

Secrets should never live in task definitions as plaintext environment variables

Fargate task definitions support pulling secrets at container startup from AWS Secrets Manager or Systems Manager Parameter Store directly into environment variables, injected at launch time rather than stored in the task definition itself — task definitions are visible to anyone with read access to ECS describe APIs, so plaintext secrets embedded directly in a task definition are effectively as exposed as if they were checked into a shared, widely-readable configuration file.

Hypervisor isolation reduces, but does not eliminate, the need for image-level security hygiene

The Firecracker microVM boundary is a strong isolation layer between tasks, but it says nothing about vulnerabilities inside a single task’s own container image — a container running outdated dependencies with known CVEs is just as exploitable within its own isolated microVM as it would be anywhere else. Image scanning (via ECR’s built-in scanning or third-party tooling) integrated into the CI/CD pipeline remains a required control regardless of the strength of Fargate’s tenant isolation.

Security groups apply per task, enabling tighter segmentation than host-based models

Because each task has its own ENI, security groups can be scoped precisely per service, or even per task if warranted, rather than being shared across every container placed on a common EC2 host — this makes network micro-segmentation dramatically easier to reason about and enforce correctly than in a shared-host container model where security groups apply at the instance level regardless of which containers happen to be co-located.

Container Insights is the primary source of per-task utilization truth

Amazon CloudWatch Container Insights provides per-task and per-service CPU, memory, network, and storage metrics specifically scoped to Fargate’s execution model — this is the data source that makes the right-sizing decisions from Chapter Five possible; without it, task-size choices are just guesses. Advanced teams treat sustained gaps between requested and actually-used vCPU/memory as an ongoing cost-optimization backlog item, not a one-time setup task.

Log routing has to be explicit — there’s no host to tail logs from

Because there’s no persistent underlying host, Fargate task logs must be explicitly routed via the awslogs log driver (or another configured driver) to CloudWatch Logs, or to another centralized destination, at the task definition level — a task without log routing configured produces logs that are simply gone the moment the task stops, with no way to retroactively retrieve them, unlike an EC2 instance where you could at least theoretically SSH in and inspect local files after the fact.

What “monitoring Fargate” actually means operationally

Effective operational monitoring tracks: per-task startup latency trends (a creeping increase often signals image bloat), health-check failure rates (catching the “RUNNING but broken” gap from Chapter Six), Spot interruption frequency and how gracefully the application absorbed each one, and subnet IP utilization trending toward the exhaustion ceiling described in Chapter Five — none of these are things a generic “is the service up” dashboard alone will surface.

Fargate as a launch type across two distinct orchestrators

Fargate isn’t tied to one orchestrator — it’s a launch type available under both Amazon ECS and Amazon EKS (via Fargate profiles). The underlying microVM isolation, per-task ENI networking, and per-second billing model are the same regardless of orchestrator; what differs is the scheduling API surface and ecosystem (ECS task definitions and services vs. Kubernetes pods and Fargate profiles), which shapes which teams reach for which orchestrator on top of the same Fargate execution substrate.

Deployment strategies natively supported on Fargate services

ECS services on Fargate support rolling deployments natively, and blue/green deployments through integration with AWS CodeDeploy — the latter is the preferred pattern for production services requiring instant rollback capability, since it stands up an entirely new task set behind a separate target group and shifts traffic only once health checks against the new set pass, rather than replacing tasks incrementally in place.

Infrastructure-as-code and CI/CD integration

Task definitions, services, and Fargate profiles are all API-addressable resources managed cleanly via CloudFormation, Terraform, or CDK, and CI/CD pipelines commonly build a new container image, push it to ECR, then trigger a new task definition revision and service deployment as a single automated pipeline stage — the absence of any host-level configuration to manage (patching, AMI updates) removes an entire category of infrastructure drift that EC2-backed deployments have to account for.

graph TD
    IMG[Container Image] --> ECR[Amazon ECR]
    ECR --> ECS[ECS Service
Fargate Launch Type]
    ECR --> EKS[EKS Pod
Fargate Profile]
    ECS --> BG[CodeDeploy
Blue/Green Deployment]
    ECS --> ROLL[Native Rolling Deployment]
    EKS --> K8SSCHED[Kubernetes Scheduler
via Fargate Profile]
        

Pattern: Slim images, aggressive layer caching

Multi-stage builds that ship only the minimal runtime layer, combined with deliberate layer ordering to maximize cache hits, directly reduce the image-pull-dominated startup latency that gates Fargate’s burst scaling responsiveness.

Pattern: Mixed capacity providers — standard plus Spot

ECS capacity provider strategies let a single service split its desired task count across standard Fargate and Fargate Spot, maintaining a baseline of guaranteed capacity on standard while absorbing additional scale on discounted Spot capacity — balancing cost savings against interruption risk deliberately, rather than choosing one pricing model exclusively.

Pattern: Externalized state via EFS, not local disk assumptions

Workloads needing persistent or shared storage across tasks mount Amazon EFS directly into Fargate tasks, rather than assuming any form of durable local storage — this keeps tasks fully interchangeable and stateless from the scheduler’s perspective, preserving Fargate’s replace-not-resize scaling model without surprising data loss.

Anti-Pattern: Treating a Fargate task like a pet EC2 instance

Designing application logic that assumes a task will live indefinitely, hold in-memory state indefinitely, or resume gracefully from wherever it left off without any checkpointing, directly contradicts Fargate’s scaling and Spot-interruption model — any task can be replaced at any time, and applications not designed for that reality experience data loss or inconsistency the first time a scale-in or Spot reclamation happens.

Anti-Pattern: Ignoring subnet sizing until exhaustion hits production

Launching a Fargate fleet into an undersized subnet without modeling peak concurrent task count against available IP addresses is a scaling ceiling that typically only reveals itself during an actual traffic spike — precisely the worst possible time to discover it.