AWS Fargate for Amazon Elastic Kubernetes Service creates a dedicated compute environment for each individual pod rather than requiring customers to manage a fleet of shared worker nodes, according to a new technical explainer published by The New Stack. The service assigns each pod its own Elastic Network Interface in the customer's virtual private cloud, boots the Kubernetes components it needs, and dismantles the environment when the pod terminates. The approach shifts infrastructure management responsibility while preserving what Kubernetes expects from a node.
When a pod is selected for Fargate, the platform provisions capacity on demand instead of selecting from a pre-existing node pool. An admission webhook adds the matching Fargate profile's name to the pod's label and sets the pod's scheduler to the Fargate scheduler before the pod object is saved in the Kubernetes database. A dedicated scheduler then requests new capacity based on the pod's resource requirements and matching profile, tentatively associating the pod with a nominated node to prevent duplicate provisioning. The Fargate runtime registers the Kubernetes Node object when the environment is ready, starts the pod, reports its status through the API server, and removes the node when the pod terminates. Security-group rules and VPC routing apply to each pod's individual network interface rather than to a shared customer-managed worker node.
The report states that "serverless Kubernetes changes who manages the node, not what Kubernetes expects from it." According to the authors, the Fargate scheduler "requests new capacity for a pod rather than searching a pool of existing nodes," operating as a dedicated scheduler on the Kubernetes control plane. The explainer notes that making Kubernetes serverless "required more than hiding the worker node," as EKS had to preserve Kubernetes behaviors while changing the underlying lifecycle.
The architecture separates platform traffic from workload traffic through three logical Linux network namespaces: one for Fargate platform services including telemetry and credential vending, one for Kubernetes core data-plane components and the customer network interface, and one for the customer workload. The customer network interface is moved into the node namespace, where it provides the path for Kubernetes control-plane communication and pod traffic, while filtering prevents the pod from reaching platform metadata and management processes. The runtime image matches the Kubernetes control-plane version, supplying the kubelet and node components needed to register the node, receive pod specifications, start and restart containers, run probes, and report status. A custom PodAdmitHandler validates a pod before it starts, admitting only pods intended for the Fargate scheduling path to protect the one-pod-per-node model.
The report identifies several design considerations for customers adopting Fargate. Every pod must match a Fargate profile, and customers must plan network interface and subnet capacity accordingly, since a design that works on EC2 by sharing many pods on one node's interface must account for one interface per Fargate pod. Fargate profiles use private subnets without public IP addresses, so internet or AWS service access normally requires the private subnet's network address translation gateway or VPC endpoint design. Workloads requiring node-level control such as DaemonSets, host networking, privileged operations, or GPUs fall outside the Fargate pod contract and require an execution model that provides node-level access, while Amazon Elastic File System is the supported pattern for durable shared file storage since Amazon Elastic Block Store can't be mounted to Fargate pods. EKS periodically replaces Fargate pods so they receive the latest security patches without customer-managed node operations, using the Kubernetes Eviction API to gracefully remove pods before recycling the environment while respecting the customer's PodDisruptionBudget. The platform's invisibility when it works is the point of the service: deployments select a profile, pods start with the expected VPC access, and the underlying environment disappears when the workload is gone. For organizations already committed to Kubernetes primitives, the model removes operational overhead without requiring a rethink of deployment patterns. But the hard constraint—one network interface per pod—will force subnet redesigns for teams accustomed to dense EC2 packing, a tax paid in IP address planning rather than instance management.