How AWS Fargate Runs Serverless Kubernetes Without Worker Nodes

Serverless Kubernetes on Amazon EKS Fargate follows a one pod, one node approach. Every pod gets its own compute environment, so you don't have to create, patch, scale, or replace a fleet of worker nodes. Kubernetes still expects a node that registers with the control plane, reports capacity, runs a Kubelet, provides networking, and hosts workloads. Fargate handles all of that behavior for you.

When a pod is selected to run on Fargate, EKS sets up a dedicated compute environment, boots the Kubernetes components it needs, and gives the pod an Elastic Network Interface (ENI) in your virtual private cloud (VPC). Once the pod is gone, that environment is torn down too.

How serverless Kubernetes routes pods to Fargate

A single EKS cluster can use Amazon EC2 and Fargate nodes at the same time, so pod placement has to be explicit before the normal scheduling flow begins. The deciding piece is the Fargate profile, an AWS resource that selects pods by namespace and, optionally, by label. The profile also defines the private subnet and security group for the pod's ENI, so location and network access are chosen together.

In clusters with Fargate enabled, AWS manages an admission webhook inside the control plane. When a pod matches a profile, the mutating webhook adds the profile's name to the pod's label and changes its scheduler name to the Fargate scheduler. This decision happens before the pod object is stored in etcd, so the default scheduler never gets a chance to claim it.

The profile also sets the pod execution role, an IAM role the Fargate infrastructure uses to register its kubelet and pull images from Amazon ECR. This role is separate from the application identity your containers use. Because the environment is serverless, EC2 instance metadata isn't available to Fargate pods. Applications that call AWS services should use IAM roles for service accounts.

A dedicated scheduler that requests new capacity

The Fargate scheduler runs on the Kubernetes control plane. Instead of searching a pool of existing nodes, it requests new capacity based on the pod's resource requirements and its matching Fargate profile. After capacity is requested, the scheduler tentatively associates the pod with a nominated node so a retry or resync doesn't trigger a second environment for the same pod. The Fargate runtime registers the Node object when the environment is ready, and the scheduler performs the final bind once the node reports ready. When the pod terminates, the runtime removes the node and releases its capacity. If provisioning or binding fails, reconciliation clears the tentative assignment and reclaims the capacity before retrying.

One pod, one network interface

Fargate connects each pod to the VPC through its ENI. Security group rules and VPC routing apply directly to the pod's ENI, not to a shared worker node you manage yourself. That gives the pod its own place in the VPC: VPC flow logs can identify the interface, and security group rules can express the workload boundary you want. The network path has to serve two audiences. The Fargate platform needs a path for telemetry, credentials, and provisioning, while Kubernetes components need a path to the API server and the pod needs a path to the VPC. Fargate separates them with three logical Linux network namespaces:

• Platform: carries the Fargate platform services, including telemetry, credential vending, and provisioning.
• Node: carries the core Kubernetes data-plane components and the customer ENI.
• Workload: where your workload runs.

The customer ENI is moved into the node namespace, where it serves as the path for Kubernetes control-plane communication and pod traffic. The task metadata endpoint is reachable from the node namespace, so the node runtime can obtain the credentials it needs to register the node with the API server. Access from the workload namespace is blocked. The underlying implementation can change, but this separation keeps the managed platform, the Kubernetes node components, and the workload on distinct paths.

For small teams and business owners running applications on AWS, this model means node patching and scaling can be off your plate. There is a trade-off: EC2 instance metadata isn't available, so applications that call AWS services need to use IAM roles for service accounts.