Serverless Kubernetes fundamentally shifts responsibility for node lifecycle management, but the Kubernetes platform itself remains unchanged. The control plane still expects nodes to register, declare capacity, run a Kubelet, provide networking, and execute workloads. AWS Fargate delivers these capabilities without requiring customers to provision, maintain, patch, or manage a fleet of worker nodes.
Amazon Elastic Kubernetes Service (EKS) Fargate achieves this by elevating the pod to the primary unit of infrastructure. When EKS selects a pod for Fargate execution, it automatically provisions a dedicated compute environment, initializes the necessary Kubernetes components, assigns an Elastic Network Interface (ENI) within the customer's virtual private cloud (VPC), and deprovisioning the environment once the pod terminates.
Serverless Kubernetes changes who manages the node, not what Kubernetes expects from it.
This user experience depends on coordinated architectural decisions working in concert. Admission-time routing intercepts pods before the default scheduler can claim them. A Fargate-specific scheduler provisions fresh capacity rather than selecting from an existing pool. A minimal runtime image supplies only the Kubernetes node components required. Separate network namespaces isolate the managed platform from the 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 pods on Amazon Elastic Compute Cloud (Amazon EC2) instances and on Fargate. Explicit placement decisions must occur before the standard scheduling process begins.
EKS uses a Fargate profile—an AWS resource that declares which pods execute on Fargate. The profile selects pods by namespace and optional pod labels, and simultaneously specifies the private subnet and security group for the pod's ENI. This ties placement decisions and network access configuration together.
For Fargate-enabled clusters, AWS operates an admission webhook integrated into the Kubernetes control plane. When a pod matches a profile, the mutating webhook attaches the profile name as a pod label and sets the pod's scheduler name to the Fargate scheduler, routing the pod through Fargate's scheduling path. This occurs before the pod object reaches the Kubernetes database (etcd) and before the default scheduler can intervene.
The profile also defines the 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 execution role differs from the application identity used by containers. Since Fargate is serverless, EC2 instance metadata is unavailable to Fargate pods; applications calling AWS services should use IAM roles for service accounts instead.
Provisioning a node for the pod
The Fargate scheduler operates as a dedicated scheduler on the Kubernetes control plane. Rather than selecting from a pre-existing node pool, 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.
After requesting capacity, the scheduler tentatively reserves the pod to a nominated node, preventing duplicate environment provisioning if reconciliation loops occur. The Fargate runtime registers the Kubernetes Node object when the environment is ready, and the scheduler completes the binding after the node reports readiness. The runtime then launches the pod and communicates its status through the API server.
When the pod ends, the runtime deletes the node and releases its capacity. If provisioning or binding encounters an error, reconciliation removes the tentative assignment, reclaims the capacity, and initiates a retry.
One pod, one network interface
Fargate connects each pod to the customer's VPC via a dedicated ENI. The Fargate profile specifies the private subnet and security group for this interface. VPC routing and security-group rules then apply directly to the pod's ENI rather than to a shared customer-managed worker node.
An ENI grants the pod a first-class identity within the VPC. VPC flow logs can track the interface, and security-group rules can express workload boundaries explicitly.
The network architecture must simultaneously serve the Fargate platform and Kubernetes. The platform requires connectivity for managed telemetry, credential delivery, and provisioning operations. Kubernetes components need access to the API server, and the customer pod needs VPC connectivity. Fargate maintains these paths where Kubernetes requires them while segregating platform traffic from workload traffic.
Fargate establishes three distinct 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 separate paths.
The customer ENI moves into the node namespace, where it enables Kubernetes control-plane communication and pod traffic. The task metadata endpoint is accessible from the node namespace, allowing the node runtime's AWS authentication to obtain credentials for API server registration, while access from the workload namespace is blocked. A bridge and virtual Ethernet (veth) pair created by the Container Network Interface (CNI) connects the node namespace to the workload namespace. The node namespace handles traffic destined for Kubernetes management endpoints; all other traffic routes 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 version matches the Kubernetes control-plane version, ensuring the kubelet and supporting components remain compatible. It provides the kubelet and Kubernetes node components necessary to register the node, receive pod specifications, start and restart containers, execute probes, report status, and support 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, admitting only pods intended for the Fargate scheduling path. This safeguards the one-pod-per-node model when another pod appears during kubelet startup 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 operations the service requires. EKS contributed upstream 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 to deliver the latest security patches without customer-managed node operations. When a Fargate environment requires patching, EKS identifies the affected pod, alerts 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 governs how much application capacity can become unavailable during this process. EKS respects the budget when requesting eviction and retries if eviction would violate it. The budget must accommodate planned disruption; if eviction cannot succeed by the scheduled termination time, EKS can eventually delete the pod to create the patched environment. Replicas and readiness probes determine whether the application continues handling traffic.
Customers must architect their applications around this independent pod lifecycle. Every pod must match a Fargate profile.
Customers should provision ENI and subnet capacity appropriately. A design that works on EC2 because multiple pods share a node's interface must account for one ENI per Fargate pod. Fargate profiles use private subnets, and Fargate pods do not receive public IP addresses. Internet or AWS-service access typically 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 permit 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 run naturally on Fargate, including Deployments, Jobs, and multi-tenant applications whose isolation boundary is the pod. Workloads requiring 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 providing 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 attach to Fargate pods. For durable shared file storage, Amazon Elastic File System (Amazon EFS) is the supported pattern. For supported Kubernetes features, consult 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.
Implementing serverless Kubernetes demanded more than abstracting away worker nodes. EKS had to maintain Kubernetes semantics while transforming the underlying lifecycle. Admission establishes placement intent before schedulers compete. A scheduler provisions capacity and waits for a node to demonstrate readiness. Runtime components fulfill the node contract, while node-level admission enforces the pod boundary. VPC networking grants each pod a direct, controllable identity, while namespace and VM boundaries isolate the managed platform from the workload.
These design choices remain mostly invisible when functioning correctly. A deployment selects a profile, a pod starts with expected VPC access, logs and exec behave like standard Kubernetes operations, and the underlying environment vanishes when the workload completes.
That invisibility defines the service's value. Customers leverage familiar Kubernetes objects and workflows while EKS and Fargate handle provisioning, isolation, node lifecycle, and runtime maintenance. The infrastructure is managed, yet the contract remains Kubernetes: a pod is admitted, scheduled, connected, and observed as a first-class workload.