Containers

New Amazon EKS Auto Mode features for enhanced security, network control, and performance

When we launched Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode at Amazon Web Services (AWS) re:Invent 2024, we introduced a transformative approach to Kubernetes cluster management on AWS.

EKS Auto Mode fully automates Kubernetes cluster management for compute, storage, and networking, so that you can focus on building applications that drive innovation rather than managing cluster infrastructure.

EKS Auto Mode addresses a fundamental challenge: although users choose Amazon EKS for the open standards of Kubernetes combined with the capabilities of AWS, they often struggle with the operational complexity of production-grade infrastructure. Managing compute provisioning, maintaining essential plugins for autoscaling, storage, and networking, handling OS patches, and optimizing resource utilization all require significant ongoing effort that takes focus away from the kind of innovation that their users want.

EKS Auto Mode handles the complete Kubernetes cluster infrastructure lifecycle through five key capabilities:

  • Automated compute management: Intelligent node provisioning, scaling, and lifecycle management that adapts to workload demands without manual intervention.
  • Integrated networking and storage: Pre-configured Amazon Virtual Private Cloud (Amazon VPC) CNI, Amazon Elastic Block Store (Amazon EBS) CSI drivers, and load balancer controllers that work together seamlessly from day one
  • Secure and optimized compute runtime: Enforced encryption, automated patching, and secure access management that maintains compliance without operational overhead.
  • Built-in cost optimization: Automatic instance type selection, Spot integration, and right-sizing that continuously optimizes spend based on actual usage patterns.
  • Simplified cluster lifecycle: One-click cluster creation and updates that handle the complexity of Kubernetes version management and component compatibility

This foundation has enabled many customers, from large enterprises to scaling startups, to shift cluster operations to AWS, freeing up valuable time and energy on their teams while retaining full Kubernetes interoperability. Teams can deploy production workloads faster, achieve better performance outcomes, and reduce infrastructure costs without needing specialized Kubernetes expertise.

Since launch, we’ve been expanding Auto Mode’s capabilities based on our customers’ feedback and real-world usage patterns. This post covers the features and improvements we’ve delivered to address specific operational challenges and extend the functionality of EKS Auto Mode for diverse workloads.

Recent feature highlights

Over the past 10 months, we’ve delivered a steady stream of enhancements that expand the capabilities of EKS Auto Mode and address diverse customer requirements:

Performance and capacity management

Optimized node lifecycle management: EKS Auto Mode has significantly improved cluster scaling performance through several key enhancements. It now implements intelligent scheduling timeouts and multi-threaded node filtering, delivering increased performance by parallelizing node evaluation and spreading API server load over time. These optimizations particularly benefit AI/ML workloads that require rapid capacity provisioning and time-sensitive applications that need fast recovery from infrastructure changes.

Amazon EC2 capacity reservations support (ODCRs and Capacity Blocks for ML): EKS Auto Mode now supports controlling deployment of workloads into Amazon EC2 On-Demand Capacity Reservations (ODCR), including both standard ODCRs and Capacity Blocks for ML. The new capacityReservationSelectorTerms in the NodeClass combined with the new reserved Capacity Type in the NodePool allow you to explicitly control which ODCRs your workloads use, maximizing utilization of pre-purchased capacity. This feature is particularly valuable for AI/ML workloads that require guaranteed access to in-demand, specialized instances such as P5s or for making sure that critical workloads have the capacity they need. When these are configured, nodes provisioned using ODCRs have karpenter.sh/capacity-type: reserved and are prioritized over on-demand and spot instances.

The following shows how to configure ODCR targeting:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: [ "reserved", "on-demand" ]
--
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: odcr-nodeclass
spec:
  capacityReservationSelectorTerms:
    - tags:
        Environment: production
        Team: ml-training
--
kind: Pod
apiVersion: v1
spec:
  nodeSelector:
    karpenter.k8s.aws/capacity-type: reserved

For Capacity Blocks, you can update your NodePool to include the capacity-block reservation type:

kind: NodePool
apiVersion: karpenter.sh/v1
spec:
  template:
    spec:
      requirements:
        # specify Capacity Block reservation type
        - key: karpenter.k8s.aws/capacity-reservation-type
          operator: In
          values: [ "capacity-block" ]

Intelligent capacity management: EKS Auto Mode now includes intelligent capacity management that automatically handles minimum flexibility requirements for instance selection. When you specify minimum values for instance diversity (such as requiring at least 2 instance categories from c, m, r families, or 5 unique instance families), EKS Auto Mode can now automatically relax these constraints when necessary to maintain workload availability. This addresses scenarios where strict minimum requirements could prevent pod scheduling during capacity constraints or when specific instance types become temporarily unavailable. The system operates in “BestEffort” mode, intelligently balancing your diversity preferences with actual availability, making sure that workloads can start even when the preferred instance type diversity cannot be fully met.

Advanced networking capabilities

Separate pod subnets: We introduced support for separate pod subnets through the new podSubnetSelectorTerms and podSecurityGroupSelectorTerms fields in the EKS NodeClass. This feature is particularly valuable for separating infrastructure traffic (node-to-node communication) from application traffic (pod-to-pod communication), implementing different security policies or routing rules for nodes and pods, and configuring reverse proxies or network filtering specifically for node traffic without affecting pod traffic. Using separate pod subnets reduces pod density per node because the primary network interface is dedicated to the node subnet.

Configure separate pod subnets for enhanced network isolation:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: separate-pod-subnets
spec:
  # Node subnets
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-cluster
        Type: node-subnet
  # Separate pod subnets
  podSubnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-cluster
        Type: pod-subnet
  # Pod-specific security groups
  podSecurityGroupSelectorTerms:
    - tags:
        Name: pod-security-group
        Environment: production

You can use this configuration to implement network segmentation where nodes and pods operate in different subnets, enabling more granular security policies and traffic flow control.

Public IP address control: EKS Auto Mode now provides explicit control over public IP address assignment through the associatePublicIPAddress field in the NodeClass advancedNetworking configuration. This feature addresses enterprise security requirements where Service Control Policies (SCPs) enforce strict controls over public IP assignment, regardless of subnet configuration. By default, EKS Auto Mode follows the subnet’s MapPublicIpOnLaunch setting, but this new capability allows you to explicitly override that behavior to ensure compliance with organizational security policies that require all EC2 instances to launch without public IP addresses.

Forward network proxy support: EKS Auto Mode now supports forward network proxies through the advancedNetworking configuration in the EKS NodeClass, so that customers can route traffic through corporate proxy infrastructure. This feature supports both HTTP and HTTPS proxies with comprehensive noProxy configuration for excluding specific domains and IP ranges. The proxy support is commonly used with certificateBundles for custom certificate management when dealing with self-signed or private certificates required needed by corporate proxy infrastructure.

Configure explicit public IP control and/or proxy settings for enhanced security compliance and corporate environments:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: proxy-nodeclass
spec:
  advancedNetworking:
    # Explicitly prevent public IP assignment regardless of subnet settings
    associatePublicIPAddress: false
    # Commonly port 3128 (Squid) or 8080 (Nginx)
    httpsProxy: 'http://proxy.company.com:3128'
    noProxy:
      - localhost
      - 127.0.0.1
      - .company.com
      - .internal
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16

IPv4 egress in IPv6 clusters: EKS Auto Mode now automatically translates IPv4 traffic egressing from IPv6 clusters to the v4 address of the node primary ENI, providing seamless dual-stack networking support.

Security and compliance

Enterprise certificate management: EKS Auto Mode now supports custom certificate authority bundles through the certificateBundles configuration in the EKS NodeClass, enabling seamless integration with enterprise PKI infrastructure. This feature allows nodes to automatically trust custom certificate authorities required for corporate environments, eliminating the need for manual certificate distribution or custom Amazon Machine Image (AMI) builds. Certificate bundles work particularly well with proxy support to handle self-signed or private certificates used by corporate proxy infrastructure, ensuring secure communication across enterprise network environments.

Configure custom certificate bundles for enterprise PKI integration:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: enterprise-pki-nodeclass
spec:
  certificateBundles:
    - name: corporate-ca
      # base64-encoded cert data
      data: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t..."
    - name: internal-ca
      data: "WP0tLS1SHUdJTiBDRAJIWUZJQ0FUJI0tLS0t..."

Comprehensive AWS KMS encryption for all storage: EKS Auto Mode now provides complete encryption coverage using customer-managed AWS Key Management Service (AWS KMS) keys for both ephemeral storage and root volumes. This enhancement addresses strict security requirements by making sure that all EBS volumes attached to EKS Auto Mode instances use your specified AWS KMS key. The ephemeral storage encryption covers data volumes used for temporary files and logs, while root volume encryption extends protection to the read-only operating system volumes, providing comprehensive encryption at rest for the entire instance storage footprint.

Configure customer-managed AWS KMS encryption for complete storage protection:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: encrypted-storage-nodeclass
spec:
  ephemeralStorage:
    size: "80Gi"
    iops: 3000
    throughput: 125
    # Customer-managed KMS key encrypts both ephemeral and root volumes
    kmsKeyID: arn:aws:kms:us-west-2:123456789012:key/12345678-1234-1234-1234-123456789012

Why these features matter

  • Compliance and security requirements: The AWS KMS encryption and certificate bundle support directly address findings where security teams would flag unencrypted ephemeral storage and missing enterprise CA trust chains. Customers no longer need to build custom AMIs or manage certificate distribution through user data scripts.
  • Network architecture integration: Separate pod subnets and proxy support solve the common challenge of integrating Kubernetes into existing enterprise network designs. Teams can now maintain their established network segmentation patterns and corporate proxy requirements without complex CNI customizations or additional network overlays.
  • Enterprise-scale complexity: The intelligent capacity management and optimized node lifecycle improvements eliminate the trade-offs platform teams previously faced between cost optimization and availability at enterprise scale. These enhancements resolve minutes-long scaling delays and workload scheduling failures during capacity constraints, delivering performance improvements while maintaining both cost efficiency and operational reliability without manual intervention.
  • Capacity planning for specialized workloads: ODCR support addresses the challenge of ensuring GPU availability for training jobs and inference workloads. Rather than over-provisioning or dealing with spot interruptions during critical training runs, teams can now target pre-reserved capacity while still benefiting from EKS Auto Mode’s automated scaling for the rest of their workloads.

Getting started with EKS Auto Mode

If you haven’t tried EKS Auto Mode yet, getting started is simple:

  1. New clusters: Use the Amazon EKS console’s Quick Configuration option or create through AWS Command Line Interface (AWS CLI)/Infrastructure-as-Code (IaC) tools.
  2. Existing clusters: Enable EKS Auto Mode on existing EKS clusters running Kubernetes 1.29+.
  3. Migration: Migrate from Managed node groups, Karpenter, or Amazon EKS with AWS Fargate using our migration guides.

For hands-on experience, try our EKS Auto Mode workshop, which provides step-by-step guidance for deploying workloads and exploring the capabilities of EKS Auto Mode.

We’re also excited about upcoming events where you can learn more about EKS Auto Mode:

Conclusion

Amazon EKS Auto Mode represents our vision for how Kubernetes should work—automating cluster operations so that infrastructure complexity fades into the background, allowing you to focus on what matters most: building and running applications that drive innovation for your customers. By delegating this work to AWS, you can leverage the scalability and operational excellence of AWS, without deep Kubernetes expertise or ongoing infrastructure management overhead.

The features we’ve delivered since launch demonstrate our commitment to continuous innovation based on customer feedback. Whether you’re running micro-services, data analytics, AI/ML inferencing, or enterprise applications, EKS Auto Mode provides the foundation for increasing agility, improving performance and security, and optimizing costs for reliable, scalable Kubernetes operations.

Ready to try EKS Auto Mode? Get started with EKS Auto Mode today and join the thousands of customers who have streamlined their Kubernetes operations while maintaining the compatibility and control they need.

About the authors

Alex Kestner is a Principal Product Manager for EKS.

Todd Neal is a Principal Software Engineer for EKS.

Sajjan Gundapuneedi is a Software Development Manager for EKS.