Inside AWS EKS Fargate: How One Pod Gets Its Own Dedicated Node

Serverless Kubernetes fundamentally shifts responsibility for node operations without changing what Kubernetes itself requires from infrastructure. The platform still needs nodes to register with the control plane, report available capacity, run a Kubelet process, supply networking, and execute workloads. AWS Fargate delivers all of these capabilities without forcing customers to build, maintain, patch, or scale their own fleet of worker nodes.

Amazon Elastic Kubernetes Service (EKS) Fargate achieves this by elevating the pod to the status of infrastructure unit. When EKS selects a pod for Fargate execution, it spins up a dedicated compute environment, initializes the necessary Kubernetes components, assigns the pod an Elastic Network Interface (ENI) within the customer's virtual private cloud (VPC), and tears down the environment once the pod finishes running.

Serverless Kubernetes changes who manages the node, not what Kubernetes expects from it.

This customer experience rests on several interconnected architectural decisions. Admission-time routing prevents the standard scheduler from interfering with Fargate pods. A Fargate-specific scheduler handles capacity provisioning rather than picking from an existing node pool. A streamlined runtime image supplies only the Kubernetes node components required, while separate network namespaces isolate the platform's infrastructure path from the application workload path. An admission handler on the node enforces the one-pod, one-environment constraint.

Routing a pod before scheduling

An EKS cluster can simultaneously run nodes from Amazon Elastic Compute Cloud (Amazon EC2) and Fargate. Placement decisions therefore must be explicit and happen before the standard scheduling process begins.

EKS introduces the Fargate profile, an AWS resource that specifies which pods should execute on Fargate. A profile identifies target pods by namespace and optional pod labels. It also designates the private subnet and security group for the pod's Elastic Network Interface, ensuring that placement and network configuration are determined together.

When Fargate is active on a cluster, AWS operates an admission webhook as part of the Kubernetes control plane. Upon matching a pod to a profile, the mutating webhook attaches the profile's name as a pod label and sets the pod's scheduler name to the Fargate scheduler, directing the pod through the Fargate scheduling path. This routing occurs before the pod object is written to the Kubernetes database (etcd) and before the default scheduler has any opportunity to claim it.

The profile also specifies a pod execution role—an AWS Identity and Access Management (IAM) role that Fargate infrastructure uses to register its kubelet and retrieve images from Amazon Elastic Container Registry (Amazon ECR). This role differs from the application identity that containers themselves assume. Since Fargate is a serverless infrastructure, EC2 instance metadata is unavailable to Fargate pods, so applications calling AWS services should rely on IAM roles for service accounts.

Provisioning a node for the pod

The Fargate scheduler operates as a dedicated scheduler on the Kubernetes control plane. Rather than searching through a pool of pre-existing nodes, it requests new capacity based on the pod's resource requirements and its matching Fargate profile.

The Fargate scheduler is a dedicated scheduler that runs on the Kubernetes control plane. It requests new capacity for a pod rather than searching a pool of existing nodes.

Once capacity is requested, the scheduler tentatively binds the pod to a nominated node. This tentative binding prevents retries or resyncs from launching a second environment for the same pod. The Fargate runtime registers the Kubernetes Node object when the environment becomes ready, and the scheduler completes the final binding after the node signals readiness. The runtime then launches the pod and communicates its status through the API server.

Upon pod termination, the runtime deletes the node and releases its capacity. If provisioning or binding encounters problems, reconciliation removes the tentative assignment and frees the capacity before attempting again.

One pod, one network interface

Each Fargate pod connects to the customer's VPC through its own ENI. The Fargate profile determines which private subnet and security group apply to that interface. VPC routing rules and security-group policies therefore govern the pod's ENI directly rather than a shared customer-managed worker node.

An ENI grants the pod a direct, first-class identity within the VPC. VPC flow logs can track the interface, and security-group rules can define the workload boundary explicitly.

The network design must serve two distinct purposes simultaneously. Fargate's platform requires a path for managed telemetry, credential delivery, and provisioning operations. Kubernetes components require connectivity to the API server, and the customer pod requires access to the VPC. Fargate maintains these paths where Kubernetes requires them while segregating platform traffic from application traffic.

Fargate establishes three logical Linux network namespaces. The platform namespace carries Fargate platform services, including telemetry, credential vending, and provisioning. The node namespace carries Kubernetes core data-plane components and the customer ENI. The workload namespace runs the customer workload. Although the underlying Fargate implementation may evolve, this separation ensures the managed platform, Kubernetes node components, and workload remain on distinct paths.

The customer ENI moves into the node namespace, where it provides the path for Kubernetes control-plane communication and pod traffic. The task metadata endpoint is accessible from the node namespace, allowing the node runtime's AWS authentication path to retrieve the credentials needed to register the node with the API server, while access from the workload namespace is blocked. A bridge and virtual Ethernet (veth) pair created by the Container Network Interface (CNI) connect the node namespace to the workload namespace. The node namespace handles traffic destined for Kubernetes management endpoints; all other traffic flows to the workload namespace and exits through the customer ENI. Filtering prevents the pod from accessing platform metadata and management processes.

The runtime image is a Kubernetes node in miniature

The runtime image aligns with the Kubernetes control-plane version, ensuring the kubelet and supporting components remain compatible. It supplies the kubelet and Kubernetes node components necessary to register the node, receive pod specifications, start and restart containers, run probes, report status, and provide operations such as logs and exec.

During kubelet startup validation, the default scheduler could theoretically place a pod before the Fargate kubelet finishes initialization. EKS runs a custom PodAdmitHandler that validates pods before they start and admits only pods intended for the Fargate scheduling path. This safeguard protects the one-pod-per-node model when another pod appears while the kubelet is starting up and provides a second validation boundary after API-server admission.

The managed kubelet does not require every capability available on a general-purpose node. Kubernetes provides controls to disable the logs, profiling, and debug-flags handlers, and EKS uses them to restrict the runtime surface to the operations the service needs. EKS contributed some of these controls upstream through changes that disable the logs handler and changes that disable profiling and debug flags.

Fargate patching and considerations

Fargate's managed runtime receives continuous maintenance, and EKS periodically replaces Fargate pods so they receive the latest available security patch without requiring customer-managed node operations. When a Fargate environment requires patching, EKS identifies the affected pod, notifies the customer, and uses the Kubernetes Eviction API to gracefully remove the pod before recycling the environment. For controller-managed workloads, this allows a replacement pod to become ready before the old environment is retired.

A customer's PodDisruptionBudget controls how much application capacity can be unavailable during this process. EKS respects the budget when it requests eviction and retries when eviction would violate it. The budget must leave room for planned disruption; if eviction still cannot succeed by the scheduled termination time, EKS can eventually delete the pod so it can create the patched environment. Replicas and readiness probes determine whether the application continues serving traffic.

Customers must design around this independent pod lifecycle. Every pod must match a Fargate profile.

Customers should plan ENI and subnet capacity accordingly. A design that works on EC2 because many pods share a node's interface must account for one ENI per Fargate pod. Fargate profiles use private subnets, and Fargate pods are not assigned public IP addresses. Internet or AWS-service access normally uses the private subnet's network address translation (NAT) gateway or VPC endpoint design. Because the customer ENI carries both Kubernetes data-plane and pod traffic, its security group must allow the Kubernetes management traffic needed for operations such as kubectl logs and kubectl exec.

A workload contract that fits the model

Most Kubernetes application workloads fit naturally on Fargate, including Deployments, Jobs, and multi-tenant applications whose isolation boundary is the pod. Workloads that require node-level control, such as DaemonSets, host networking, host ports, privileged operations, or GPUs, fall outside the Fargate pod contract and require an execution model that provides node-level access.

Storage follows the same boundary. HostPath and host-attached block storage depend on a persistent node, and Amazon Elastic Block Store (Amazon EBS) cannot be mounted to Fargate pods. For durable shared file storage, Amazon Elastic File System (Amazon EFS) is the supported pattern. For supported Kubernetes features, read the current EKS Fargate documentation.

Making Kubernetes serverless required more than hiding the worker node. EKS had to preserve Kubernetes behaviors while changing the underlying lifecycle.

Admission establishes placement intent before schedulers compete. A scheduler provisions capacity and waits for a node to prove readiness. Runtime components supply the node contract, while node-level admission protects the pod boundary. VPC networking gives each pod a direct, controllable identity, while namespace and VM boundaries keep the managed platform separate from the workload.

These decisions are mostly invisible when they work. A deployment selects a profile, a pod starts with the expected VPC access, logs and exec behave like Kubernetes operations, and the underlying environment disappears when the workload is gone.

That invisibility is the point of the service. Customers can use familiar Kubernetes objects and workflows while EKS and Fargate absorb the work of provisioning, isolation, node lifecycle, and runtime maintenance. The infrastructure is managed, but the contract remains Kubernetes: a pod is admitted, scheduled, connected, and observed as a first-class workload.