<p>Amazon EKS Auto Mode now supports the Kubernetes Gateway API, giving customers a standard, portable way to define how traffic reaches their applications. Customers can configure application load balancing using Gateway and HTTPRoute resources, and EKS Auto Mode provisions and manages the underlying AWS infrastructure automatically.</p> <p>With this launch, EKS Auto Mode customers can adopt the next-generation Kubernetes traffic management standard without installing or configuring a separate controller. Capabilities include HTTP and gRPC routing, cross-namespace traffic routing for multi-team environments, weighted traffic splitting, header-based routing, and automatic TLS certificate discovery through AWS Certificate Manager. Existing workloads using Ingress resources continue to work alongside Gateway API resources.</p> <p>To get started, see the <a href="https://docs.aws.amazon.com/eks/latest/userguide/auto-configure-gateway-api.html">Amazon EKS documentation</a>. Gateway API support is included as part of EKS Auto Mode and is available in all AWS Regions where EKS Auto Mode is supported. Standard charges apply for the AWS load balancing resources provisioned.</p>

<p>Amazon Elastic Kubernetes Service (EKS) Auto Mode now lets you tune kubelet settings, Linux kernel sysctls, and hugepages directly in the NodeClass Kubernetes resource. You can now run workloads that require specific node tuning on EKS Auto Mode, which automates node provisioning, scaling, patching, and upgrades for you.</p> <p>With the new advancedCompute field in NodeClass, you can configure user namespaces for rootless container builds in CI/CD pipelines, tune eviction thresholds and container log rotation to protect nodes from disk and memory pressure, raise network and ARP cache limits for large clusters, and pre-allocate 2Mi or 1Gi hugepages for HPC, database, and latency-sensitive workloads. You apply these settings declaratively using the Kubernetes API. EKS Auto Mode validates them, applies them at node boot, and preserves them through scaling and upgrade events, so your workloads get the tuning they need while EKS Auto Mode continues to manage the underlying infrastructure, with no EC2 launch templates, custom AMIs, or privileged DaemonSets to maintain.</p> <p>Amazon EKS Auto Mode advanced compute configuration is available in all AWS Regions where EKS Auto Mode is available.</p> <p>To get started, see the <a href="https://aws.amazon.com/eks/auto-mode/">Amazon EKS Auto Mode</a> product page, and see <a href="https://docs.aws.amazon.com/eks/latest/userguide/create-node-class.html#kubelet-config">Create a Node Class for Amazon EKS</a> in the Amazon EKS documentation.</p>

⚠️ Action Required CRD Updates (Required) There is no Gateway API graduation in this release -- the controller remains built against Gateway API CRDs v1.6.0 (unchanged from v3.5.0). As a safety measure, we recommend applying the latest AWS-vended CRDs before upgrading the controller. Apply the latest AWS-vended CRD definitions: Action : • kubectl apply -k "github.com/aws/eks-charts/stable/aws-load-balancer-controller/crds?ref=master" • kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/config/crd/gateway/gateway-crds.yaml 🚀 What's New Cross-account TargetGroupBinding -- AZ-aware IP registration (opt-in) Cross-account TargetGroupBinding IP targets can now be registered with the pod's actual Availability Zone, improving cross-account zonal routing. Opt-in to preserve existing behavior by default. (#4877, @cqi1217) frontend-nlb-status-only annotation for Ingress New annotation to control whether the Ingress status hostname exposes only the frontend NLB -- fixes ExternalDNS record creation when fronting an ALB Ingress with an NLB. If the NLB is not yet provisioned, no hostname is written. (#4849, @dominikhei) Gateway API customization for downstream/automode importers Importers embedding the controller can now customize Gateway names, customize finalizers, and customize the Gateway controller wiring - enabling consumers to extend Gateway behavior. ReferenceGrant now uses the v1 apiVersion. (#4878, #4886, #4887, @zac-nixon) 🔧 Enhancements and Fixes Gateway • Avoid DuplicateTargetGroupName for Services with multiple named target ports (#4876) • Use v1 for the ReferenceGrant apiVersion; allow finalizers to be customized (#4886) • Use a / separator in Gateway route-loader cache keys to avoid cache-key collisions (#4916) • Fix the deletion guard for Gateway TargetGroupConfigurations still referenced by TCPRoutes (#4802) • Ignore unpermitted cross-namespace TCPRoutes in the Gateway TGC deletion guard, so a TCPRoute without a ReferenceGrant can no longer pin another namespace's TGC finalizer (#4919) **AWS Certificates Management ** • Use the public Route 53 zone for Amazon-issued ACM DNS validation in split-horizon DNS setups (#4847) Networking / TargetGroupBinding • Canonicalize CIDRs for security-group inbound rules to avoid spurious reconciliation failures (#4904) • Fix TargetGroupBinding networking with empty ports (#4909) WAF • Ignore a WAF ACL set to an empty string (treat as unset) (#4888) Controller / Informer robustness • Handle DeletedFinalStateUnknown tombstones in TypedInformer's DeleteFunc (#4879) • Make the pod informer transform idempotent so WatchList streaming sync no longer falls back to a full LIST (#4881) Misc • Clearer OIDC permission messaging (#4912) 📖 Documentation Updates • Warn against manually deleting controller-generated TargetGroupBinding objects (#4902) • Document security/trust implications of AllowedRoutes.Namespaces.From: All (#4872) • Remove unsupported vpcId field from LoadBalancerConfiguration docs (#4760) • Fix wrong default for frontend-nlb-eip-allocations in annotation docs (#4871) • Fix ipam-ipv4-pool-id example plus tip/note block spacing (#4752) What's Changed • Document security/trust implications of AllowedRoutes.Namespaces.From… by @wweiwei-li in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4872 • docs: Remove vpcId from LoadBalancerConfiguration documentation by @dominikhei in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4760 • fix(gateway): avoid DuplicateTargetGroupName for Services with multiple named targetPorts by @legal90 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4876 • fix: ipam-ipv4-pool-id example, tip and note block spacing by @wind0r in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4752 • feat(gateway custom): allow importers to customize gateway names by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4878 • fix: handle DeletedFinalStateUnknown tombstones in TypedInformer's DeleteFunc by @ginbear in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4879 • Make pod informer transform idempotent so WatchList streaming sync does not fall back to full LIST by @yash97 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4881 • use v1 for referencegrant apiversion, allow finalizers to be customized for gateway api by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4886 • refactor: Allow automode controllers to customize the gateway controller by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4887 • fix(waf): ignore waf acl set to empty string by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4888 • refactor: making tests configurable to run on eks auto framework by @jupdec in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4891 • test: mirror UDP/GRPC test images to networking-e2e-test-images by @jupdec in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4894 • test/gateway: make e2e suite partition-aware and register ECR tag resolver by @jupdec in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4908 • chore: OIDC permission messaging by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4912 • fix: canonicalize CIDRs for security group inbound rules to avoid reconciliation failures by @bobert-2 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4904 • test: default GRPC/UDP images to public ECR to fix the tests by @shraddhabang in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4911 • Fix TGB networking with empty ports by @dlanov in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4909 • docs: warn against manually deleting controller-generated TargetGroupBinding by @shashankvarma499 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4902 • Register cross-account TargetGroupBinding IP targets with the pod's availability zone (opt-in) by @cqi1217 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4877 • Fixed wrong default for frontend-nlb-eip-allocations in annotation docs by @dominikhei in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4871 • Added frontend-nlb-status-only annotation to fix ExternalDNS record creation when using a frontend NLB by @dominikhei in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4849 • fix: use '/' separator in Gateway route-loader cache keys to avoid co… by @wweiwei-li in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4916 • fix: use public Route 53 zone for Amazon-issued ACM DNS validation in split-horizon DNS by @niv1612 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4847 • Fix deletion guard for Gateway TargetGroupConfigurations still referenced by TCPRoutes by @immanuwell in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4802 • fix: ignore unpermitted cross namespace TCPRoutes in gateway target TGC deletion guard by @shraddhabang in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4919 • cut v3.6.0 release by @shraddhabang in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4921 New Contributors • @dominikhei made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4760 • @legal90 made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4876 • @wind0r made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4752 • @ginbear made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4879 • @yash97 made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4881 • @dlanov made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4909 • @shashankvarma499 made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4902 • @cqi1217 made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4877 • @niv1612 made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4847 Full Changelog: https://github.com/kubernetes-sigs/aws-load-balancer-controller/compare/v3.5.0...v3.6.0

<p>Today, Amazon Elastic Kubernetes Service (Amazon EKS) announced certificate authority (CA) rotation, enabling customers to rotate their cluster's CA through a managed lifecycle with automated safeguards. Each Amazon EKS cluster has its own CA that allows encrypted connections to the cluster's Kubernetes API, and now you can rotate the CA before it expires to ensure your cluster remains operational and secure.</p> <p>Amazon EKS clusters created since launch in 2018 have CAs with a 10-year validity period, and clusters from that era are now approaching the point where CA rotation activities should begin. CA rotation in Amazon EKS is a shared responsibility. Amazon EKS manages the rotation lifecycle and automatically updates AWS-managed components to trust the successor CA. Customers are responsible for replacing their worker nodes and updating external clients to trust the successor CA before it is activated. EKS Auto Mode instances and AWS Fargate nodes are updated automatically by AWS, but customers are still responsible for updating any external clients that connect to the cluster's API server. Amazon EKS provides automated safeguards to support customers through this process, including advance notifications before CA expiration, automatic appending of a successor CA if one is not created by the customer, and automatic activation if the customer does not activate on their own schedule. A rollback capability allows customers to revert to the previous CA to resolve any issues that may arise with their updates during the transition to the successor CA.</p> <p>Amazon EKS CA rotation is available at no additional cost in all commercial AWS Regions. To get started with CA rotation, you can use the AWS CLI, EKS APIs, CloudFormation, and the AWS console. For more information, see the <a href="https://docs.aws.amazon.com/eks/latest/userguide/certificate-authority-rotation.html">Amazon EKS documentation</a>&nbsp;and&nbsp;<a href="https://aws.amazon.com/blogs/containers/deep-dive-into-amazon-eks-certificate-authority-rotation/">Deep dive into Amazon EKS certificate authority rotation</a>.</p>

Discover Amazon EKS Auto Mode: Simplifies Kubernetes with automation, reducing management duties for efficient deployments

YouTube video by The Zacs' Show Talking AWS

On Amazon EKS Auto Mode, node failures are detected, drained, and replaced automatically before anyone reaches for a laptop. This post shows how the Node Monitoring Agent and Karpenter form a detect-and-replace cycle that runs by default, why specific faults trigger node replacement, and how to collect node diagnostics without SSH.

Documentation Thanks to all our contributors!💜💜💜 ⚠️ Action Required Gateway API CRD Updates (All Gateway API users) Who: All users running Gateway API resources (Gateway, HTTPRoute, GRPCRoute, TCPRoute, UDPRoute) with the AWS Load Balancer Controller. Why: This release requires Gateway API CRDs v1.6.0. The controller is built against this version for conformance and feature support Important: Update CRDs before upgrading the controller. If you upgrade the controller first, NLB Gateway (TCPRoute/UDPRoute/TLSRoute) will be automatically disabled until the CRDs are updated. Since the standard install no longer serves v1alpha2, you must update any existing v1alpha2 route manifests to gateway.networking.k8s.io/v1 Action: Apply v1.6 Gateway CRDs kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/standard-install.yaml LBC Gateway CRD Updates (All Gateway API users) Who: All users running Gateway API resources (Gateway, HTTPRoute, GRPCRoute, TCPRoute, UDPRoute) with the AWS Load Balancer Controller. Why: This release adds v1 as the storage version for LBC-specific Gateway CRDs (LoadBalancerConfiguration, TargetGroupConfiguration, ListenerRuleConfiguration), with v1beta1 marked as deprecated. The controller reads v1 only, but existing v1beta1 resources are transparently converted to v1 by the API server — no immediate manifest changes required. However, v1beta1 will stop being served in a future release. We recommend updating your manifests to use gateway.k8s.aws/v1 at your earliest convenience. Action: Apply the updated LBC Gateway CRDs: kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/config/crd/gateway/gateway-crds.yaml 🚀What's New Gateway API v1 Graduation This release graduates Gateway API support to v1 for L4 routes. TCPRoute and UDPRoute now use the stable gateway.networking.k8s.io/v1 API version (previously v1alpha2), and the controller passes Gateway API conformance v1.6.0. The AWS-vended Gateway API CRDs have been upgraded to v1 accordingly. 🔧Enhancements and Fixes Certificate Management • Fix ACM certificate creation for Ingresses with wildcard hosts — the character in hostname was breaking ACM tag validation Certificate list support for ECDSA/RSA use • Add certificate management controller flag to helm chart Route Precedence • Unified cross-kind route precedence for HTTPRoute/GRPCRoute, single code path eliminates non-transitivity • Fix non-transitive rule precedence for routes without hostnames Networking • Filter EndpointSlices by IP family for target group registration • Match hosted zones by longest suffix in GetHostedZoneID • Fix: ICMP Type/Code constants • Fix: render feature gates as parseable key-value pairs Module & Build • Module path updated to sigs.k8s.io/aws-load-balancer-controller/v3. Users who are importing the code base will need to adjust their imports accordingly. Helm • Correct enableEndpointSlices default in Helm values comment 📖 Documentation Updates • Add guidance on migrating between services without downtime • Clarify scheme change replacement behavior • Fix Markdown formatting of blue/green guide • Fix stale contributor setup and invalid IAM role ARN examples • Fix doc annotation name • Fix admonition indentation for ipam-ipv4-pool-id annotation • Clarify WAF addon ownership and document IngressGroup security risks • Remove CloudFormation link What's Changed • Fix Markdown formatting of blue/green guide by @Tenzer in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4835 • ci: Add GO-2026-5932 to govulncheck ignore list by @shraddhabang in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4839 • use /v3 in module name by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4770 • feat(gateway): Use Gateway API v1 for TCPRoute and UDPRoute by @nicomazzarello in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4829 • upgrade AWS vended Gateway API CRDs to v1 by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4844 • update code to use v1 crds by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4845 • Add label for accessing secrets - to support restricted access for EKS Auto LBC by @jupdec in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4838 • docs: fix admonition indentation for ipam-ipv4-pool-id annotation by @nikhilmaheshwari24 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4837 • v1.6.0 conformance + rule refactor by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4861 • fix: handle invalid condition name for tgb by @zac-nixon in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4862 • Fix ACM certificate creation for Ingresses with wildcard hosts by @nbr in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4786 • docs: clarify scheme change replacement by @kappa8219 in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4860 • fix: use "/" separator in getCacheKey to avoid TGB cache collisions by @jupdec in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4864 • fix: subnet auto-discovery to IPv6-capable subnets for dualstack ip address type by @jupdec in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4865 • Add ipv6 check for tests by @wweiwei-li in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4868 • cut v3.5.0 release by @wweiwei-li in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4869 New Contributors • @Tenzer made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4835 • @nicomazzarello made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4829 • @nikhilmaheshwari24 made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4837 • @kappa8219 made their first contribution in https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/4860 Full Changelog: https://github.com/kubernetes-sigs/aws-load-balancer-controller/compare/v3.4.2...v3.5.0

In this post, we walk through how zonal shift integrates with Amazon Elastic Kubernetes Service (Amazon EKS) and what happens when a shift is triggered. We also show how to enable it on both self-managed Karpenter and EKS Auto Mode (EKS Auto) clusters.

<p>Amazon Elastic Kubernetes Service (EKS) now supports Amazon EC2 placement groups and Elastic Fabric Adapter (EFA) network device configuration for node pools on EKS Auto Mode and the open-source Karpenter project, enabling you to optimize EKS workloads for performance and availability. These capabilities allow you to control EFA network interface configuration and how EC2 instances are physically distributed across AWS infrastructure for distributed training and inference workloads.<br> <br> With EKS Auto Mode and Karpenter’s EFA configuration, you can configure network interfaces as EFA-only or standard ENI on EFA-capable instances with both dynamic and static capacity node pools. EFA-only interfaces do not consume IP addresses, giving you fine-grained control over IP utilization in your VPC while achieving full interconnect bandwidth. With placement group support, you can launch EC2 instances using cluster, spread, or partition strategies directly from your EKS Auto Mode or Karpenter node pool configuration, giving you control over how instances are physically distributed without additional operational workarounds. Together, these capabilities let you optimize for the performance, availability, and fault isolation characteristics your workloads require, whether that's maximizing throughput for distributed training jobs or minimizing blast radius for critical production services.<br> <br> These features are available in all AWS Regions where Amazon EKS is available. To get started and learn more, see the <a href="https://docs.aws.amazon.com/eks/latest/userguide/create-node-class.html#static-network-interfaces">EKS Auto Mode User Guide</a> and <a href="https://karpenter.sh/docs/concepts/nodeclasses/#specnetworkinterfaces">Karpenter documentation</a>.</p>

<p>Amazon Elastic Kubernetes Service (Amazon EKS) now supports <a href="https://aws.amazon.com/application-recovery-controller/">Amazon Application Recovery Controller</a> (ARC) zonal shift and autoshift for clusters using <a href="https://docs.aws.amazon.com/eks/latest/userguide/automode.html">EKS Auto Mode</a>. ARC helps you manage and coordinate recovery across AWS Regions and Availability Zones (AZs). With this launch, EKS Auto Mode automatically protects your compute during a zonal shift at no additional cost or configuration, helping you maintain Kubernetes application availability by shifting in-cluster network traffic away from an impaired AZ.</p> <p>Customers run highly available applications across multiple AZs in Amazon EKS to eliminate a single point of failure. Because EKS Auto Mode manages compute on your behalf, you get zonal shift support without setting flags, granting permissions, or managing Karpenter versions; simply enable ARC zonal shift on your cluster. When a zonal shift is activated, EKS Auto Mode stops provisioning new capacity in the impaired AZ and halts voluntary disruptions such as consolidation and drift for nodes in that zone. It also prevents voluntary disruptions in healthy zones if they depend on scheduling pods to the impaired zone. When the shift expires or is canceled, normal operations resume. You can start a shift manually, or authorize AWS to manage it using <a href="https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html">zonal autoshift</a>, with practice runs to verify your cluster functions with one less AZ.</p> <p>ARC zonal shift support for EKS Auto Mode is available in all AWS Regions where EKS Auto Mode is offered. To learn more, visit the <a href="https://aws.amazon.com/eks/">Amazon EKS product page</a>, the <a href="https://docs.aws.amazon.com/eks/latest/userguide/zone-shift.html">ARC zonal shift documentation</a>, and the <a href="https://docs.aws.amazon.com/eks/latest/userguide/automode.html">Amazon EKS Auto Mode documentation</a>.</p>

In this post, you walk through a practical migration scenario where a Node.js web application running on EC2 instances is migrated into a highly scalable, containerized service on EKS Auto Mode. You will learn how to configure and use the AWS and Amazon EKS MCP Servers with Kiro CLI to automate critical migration tasks from Dockerfile creation and image optimization to Kubernetes manifest generation and production deployment on EKS Auto Mode.

<p>Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode now offers significantly reduced management fees for GPU and accelerated instance types. Beginning July 1, 2026, G-series Auto Mode management fees are reduced by 35%, and P-series and AWS Trainium fees are reduced by 60%. These reductions apply automatically to all EKS Auto Mode clusters and no action is required from customers already using GPU instances with Auto Mode.</p> <p>EKS Auto Mode simplifies Kubernetes operations by automatically provisioning and managing infrastructure for machine learning inference, fine-tuning, rendering, and batch processing workloads. It includes capabilities built for accelerated workloads: automatic parallel image pulling and unpacking on GPU instances with local NVMe storage, so large container and model images start faster, and accelerator-aware node repair that detects GPU hardware failures and automatically replaces unhealthy nodes. With today's price reduction, customers can run GPU workloads on Auto Mode at lower management fees, making its fully managed infrastructure more cost-effective.</p> <p>This pricing update is available in all AWS Regions where EKS Auto Mode is available. Amazon ECS is implementing identical management fee reductions for GPU instances on ECS Managed Instances. See the ECS What's New post for details.</p> <p>To get started with GPU workloads on EKS Auto Mode, see the <a href="https://docs.aws.amazon.com/eks/latest/userguide/ml-on-eks.html">EKS for AI/ML documentation</a>. For the complete updated rate table, see <a href="https://aws.amazon.com/eks/pricing/">Amazon EKS pricing</a>.</p>

<p><a href="https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html" target="_blank" rel="noopener noreferrer">Amazon Elastic Kubernetes Service </a>(Amazon EKS) now supports Kubernetes <a href="https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html" target="_blank" rel="noopener noreferrer">version rollback</a>, enabling you to revert to the previous Kubernetes minor version within 7 days if any issues arise after an upgrade. This provides an additional safety net for your upgrade workflow, allowing you to validate the new version under real production conditions and rollback if needed.<br> <br> You can initiate a rollback using the Amazon EKS console, AWS CLI, or AWS SDKs. Before proceeding, Amazon EKS evaluates your cluster <a href="https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html" target="_blank" rel="noopener noreferrer">rollback readiness insights</a> that include automated checks covering API compatibility, version skew, add-on compatibility, cluster health, and more. For clusters running <a href="https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode.html" target="_blank" rel="noopener noreferrer">EKS Auto Mode</a>, EKS automatically manages the rollback of worker nodes before reverting the control plane, honoring your configured disruption controls.<br> <br> Amazon EKS version rollback is available at no additional cost in all AWS Regions where Amazon EKS is available. To get started, see <a href="https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html" target="_blank" rel="noopener noreferrer">version rollback</a> in the <i>Amazon EKS User Guide</i>.</p>

In this post, we walk through the performance and scalability improvements we shipped across the four pillars of EKS Auto Mode: runtime, compute, storage, and networking.

In this post, you will learn how Amazon EKS Auto Mode and Istio Ambient Mesh work together to automate infrastructure management while providing automatic mTLS-based service-to-service security, helping reduce operational overhead and designed to help strengthen your security posture.

In this post, we explore how to maximize Auto Mode's value through comprehensive cost visibility, proactive governance, and continuous optimization strategies. We cover essential cost management dimensions: establishing spending visibility, forecasting resource needs, implementing governance controls, and measuring efficiency improvements. For both new and experienced Amazon EKS Auto Mode users, this guide offers actionable insights to balance performance, reliability, and cost-efficiency in Kubernetes deployments.

<p>Amazon Elastic Kubernetes Service (Amazon EKS) now supports Dynamic Resource Allocation (DRA) for Elastic Fabric Adapter (EFA), simplifying high-performance inter-node communication and RDMA (Remote Direct Memory Access) for artificial intelligence, machine learning, and High Performance Computing (HPC) workloads. The EFA DRA driver, built on the upstream <a title="DRANET project" href="https://github.com/kubernetes-sigs/dranet" target="_blank" rel="noopener noreferrer">DRANET project</a>, brings EFA interface sharing and topology-aware allocation for workloads running on Kubernetes.<br> <br> With the EFA DRA driver, you can allocate EFA interfaces and accelerator devices that share the same PCIe root or device group, ensuring inter-node traffic flows through the closest network interface to each NVIDIA GPU, AWS Trainium, or AWS Inferentia device on the node. The EFA DRA driver also supports EFA interface sharing across workloads on the same node to maximize EFA interface utilization.<br> <br> The EFA DRA driver is recommended for new deployments on Amazon EKS clusters running Kubernetes version 1.34 or later with EKS managed node groups or self-managed nodes. The EFA DRA driver is available in all AWS Regions where Amazon EKS is available. The EFA device plugin remains supported and is recommended for use with Karpenter and Amazon EKS Auto Mode.<br> <br> To learn more, see <a href="https://docs.aws.amazon.com/eks/latest/userguide/device-management-efa.html" target="_blank" rel="noopener noreferrer">Manage EFA devices on Amazon EKS</a> in the Amazon EKS User Guide.</p>

This post covers how EKS Auto Mode handles VPC CNI optimization, pod density scaling, network security implementation, and hybrid connectivity.

In this post, we look at how Generali is using Amazon EKS Auto Mode and its integration with other AWS services to enhance performance while reducing operational overhead, optimizing costs, and enhancing security.

<p>Amazon Elastic Kubernetes Service (Amazon EKS) Node Monitoring Agent is now open source. You can access the Amazon EKS Node Monitoring Agent source code and contribute to its development on <a title="GitHub" href="https://github.com/aws/eks-node-monitoring-agent">GitHub</a>.<br> <br> Running workloads reliably in Kubernetes clusters can be challenging. Cluster administrators often have to resort to manual methods of monitoring and repairing degraded nodes in their clusters. The Amazon EKS Node Monitoring Agent simplifies this process by automatically monitoring and publishing node-level system, storage, networking, and accelerator issues as node conditions, which are used by Amazon EKS for automatic node repair. With the Amazon EKS Node Monitoring Agent’s source code available on GitHub, you now have visibility into the agent’s implementation, can customize it to fit your requirements, and can contribute directly to its ongoing development.<br> <br> The Amazon EKS Node Monitoring Agent is included in Amazon EKS Auto Mode and is available as an Amazon EKS add-on in all AWS Regions where Amazon EKS is available.<br> <br> To learn more about the Amazon EKS Node Monitoring Agent and node repair, visit the <a href="https://docs.aws.amazon.com/eks/latest/userguide/node-health.html">Amazon EKS documentation</a>.<a title="GitHub" href="https://github.com/aws/eks-node-monitoring-agent"></a></p>

<p>Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode’s managed capabilities can now be configured as log delivery sources using Amazon CloudWatch Vended Logs. This integration enables customers to monitor and troubleshoot their EKS Auto Mode clusters more effectively by automatically collecting logs from Auto Mode’s managed Kubernetes capabilities for compute autoscaling, block storage, load balancing, and pod networking.<br> <br> Customers can configure log delivery for Auto Mode capabilities using CloudWatch APIs or the AWS Console. Each Auto Mode capability can be configured as a CloudWatch Vended Logs delivery source, enabling reliable, secure log delivery with built-in AWS authentication and authorization at a reduced price compared to standard CloudWatch Logs. Customers can deliver these logs to CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose destinations.<br> <br> This feature is available today in all regions where EKS Auto Mode is available. Standard CloudWatch Logs, S3, or Kinesis charges apply depending on the chosen destination.<br> <br> To learn more about EKS Auto Mode logging capabilities, visit the&nbsp;<a href="https://docs.aws.amazon.com/eks/latest/userguide/auto-observability.html">Amazon EKS documentation</a>.</p>

This blog post dives deeper into optimizing Amazon EKS Auto Mode clusters using AWS&nbsp;Graviton and Amazon EC2&nbsp;Spot instances. AWS customers adopt AWS Graviton instances to achieve up to 40% higher price-performance ratio and up to 60% less energy to meet their sustainability goals. Additionally, AWS customers use Amazon EC2 Spot instances for eligible workloads to save up to 90% on Amazon Elastic Compute Cloud (Amazon EC2) On-Demand costs.

Amazon Web Services (AWS) announced the availability of DNS-based and Admin network policies for Amazon Elastic Kubernetes Service (EKS) Auto mode and Admin network policies for both EKS Auto mode and EKS on Amazon Elastic Compute Cloud (EC2), providing enhanced capabilities to secure network traffic both within your clusters and to external endpoints. In this post, we explore practical use cases that demonstrate how these policies solve real-world challenges and remove the need to rely on third-party software across different deployment scenarios, from securing access to external services to hybrid cloud integration and multi-tenant environments.