Amazon EKS Now Supports EFA and Placement Groups — Smoother Distributed Training Ahead

Hi, I'm Shii-chan! Today I'm sharing an update that gives Amazon EKS node pools a nice performance and reliability boost.

AWS What's New aws.amazon.com

What was announced?

AWS shared in its What's New feed that Amazon EKS (Elastic Kubernetes Service) node pools on EKS Auto Mode and the open-source Karpenter project now support EC2 placement groups and EFA (Elastic Fabric Adapter) network device configuration.

EFA is an EC2 network adapter that lets instances communicate with low latency and high throughput — commonly used for distributed training and inference workloads that need heavy node-to-node communication. Placement groups control how EC2 instances are physically distributed across AWS infrastructure (clustered close together, or spread apart). Now you can control both directly from your node pool configuration.

The story so far

EFA and placement groups already existed as EC2-level features, but EKS Auto Mode and Karpenter node pools didn't have a way to fine-tune EFA interface type or placement group strategy from their configuration. That meant teams optimizing for performance or availability sometimes needed extra operational workarounds to get the behavior they wanted.

What changes

With this update, you can configure network interfaces on EFA-capable instances in your EKS Auto Mode or Karpenter node pools as either of the following:

• EFA-only: uses EFA interfaces exclusively
• Standard ENI: uses regular Elastic Network Interfaces

This works with both dynamic and static capacity node pools. On top of that, you can now specify a placement group strategy directly in your node pool configuration, choosing from:

• cluster: packs instances physically close together for low-latency, high-bandwidth communication
• spread: distributes instances across separate hardware to minimize the blast radius of a single failure
• partition: groups instances into partitions for fault isolation while still keeping some grouping

This is especially useful for:

• ML engineers running distributed training or inference jobs who want to maximize inter-node bandwidth
• Infrastructure teams who want to minimize the blast radius of failures for critical production workloads
• Platform teams running EKS Auto Mode or Karpenter node pools who previously relied on separate workarounds to get this behavior

Dive Deep

One technical detail worth calling out: EFA-only interfaces do not consume IP addresses. With standard ENI configurations, every interface consumes an IP address from your VPC, but EFA-only interfaces let you achieve full interconnect bandwidth without that IP cost. For large distributed training clusters where VPC IP address space can become a real constraint, this is a meaningful detail.

These capabilities are configurable via the network interface configuration section of the EKS Auto Mode user guide, and via the NodeClass specification in Karpenter's documentation. In practice, you might pair EFA-only interfaces with a cluster placement group to maximize throughput for a distributed training job, or use a spread placement group for a critical production service where fault isolation matters more than raw bandwidth.

These features are available in all AWS Regions where Amazon EKS is available.

Wrap-up

• EKS Auto Mode and Karpenter node pools can now configure network interfaces as EFA-only or standard ENI
• EFA-only interfaces don't consume IP addresses, giving full interconnect bandwidth without the IP cost
• Placement group strategies (cluster, spread, partition) can now be set directly in node pool configuration
• Works with both dynamic and static capacity node pools
• Available in all AWS Regions where Amazon EKS is available

Whether you're chasing maximum throughput for distributed training or tighter fault isolation for production services, this update gives EKS teams more direct control over both.