EKS

EKS Auto Mode is Amazon EKS with AWS running the node layer for you: it provisions EC2 instances with Karpenter-style logic, patches and replaces them on a fixed lifetime, and runs networking, DNS, block storage and load balancing as managed capabilities instead of add-ons you install. You pay for it with a management fee per EC2 instance-hour, on top of the normal EC2 price, and you give up node-level access and custom AMIs.

That is the whole trade in one sentence. The rest of this guide is about whether it is a good trade for your cluster: how the pricing actually works (with a worked example), how Auto Mode compares to managed node groups, self-managed Karpenter and Fargate, what changed in 2025-2026, what breaks when you migrate, and a one-week pilot to decide without risking production.

What EKS Auto Mode is

EKS Auto Mode, generally available since December 1, 2024, shifts more Kubernetes infrastructure responsibility from you to AWS. You still run an EKS cluster in your AWS account, and your workloads still use the Kubernetes API, but AWS takes over much of the compute, storage, networking, node lifecycle, and core add-on management that platform teams usually wire together themselves.

For compute, Auto Mode uses Karpenter under the hood. When pods are unschedulable, Auto Mode provisions nodes that fit the workload’s requirements: instance family, size, architecture, capacity type, and availability zone. When capacity is no longer useful, it consolidates and terminates nodes. The nodes run a locked-down variant of Bottlerocket with SELinux enforcing and a read-only root filesystem, and there is no SSH or SSM access.

The important framing is this: Auto Mode is not “EKS without nodes.” It is EKS where AWS manages the node lifecycle more aggressively. You own the workloads, their scheduling requirements, their disruption behavior, and the operational consequences of those choices. AWS owns more of the infrastructure plumbing.

What it replaces

Before Auto Mode, running EKS in production usually meant choosing and operating several layers yourself:

• Managed node groups: you chose instance types, defined scaling ranges, managed AMI updates, handled node draining, and configured Cluster Autoscaler or another scaling mechanism.
• Self-managed Karpenter: more flexible than managed node groups, but you owned the Karpenter controller, IAM, NodePools, EC2NodeClasses, the Spot interruption queue, disruption settings, upgrades, and failure modes.
• Fargate: AWS-managed compute per pod, with no node management, but no DaemonSets, a narrower workload compatibility envelope, and a different cost model.

EKS Auto Mode replaces a large part of that platform assembly with a managed model: declare workload intent and high-level compute constraints; AWS provisions and manages the EC2 instances behind it. If you are still deciding between the two open-source autoscalers, see Cluster Autoscaler vs Karpenter first; Auto Mode is essentially “Karpenter, operated by AWS”.

EKS Auto Mode pricing: how the fee actually works

This is the part most people search for, and the part most summaries get slightly wrong. The official structure, from the Amazon EKS pricing page (checked September 2026), is:

Monthly cost of an EKS Auto Mode cluster =
    EKS control plane            ($0.10 per cluster-hour, standard support)
  + EC2 instances                (normal price: On-Demand, Spot, RI or Savings Plans)
  + EKS Auto Mode management fee (per instance-hour, by instance type and region)
  + everything else              (EBS, load balancers, NAT, data transfer, CloudWatch...)

Auto Mode fee = Σ (Auto Mode-managed instance runtime × regional fee for that instance type)

Four details matter more than the headline:

• The fee is per instance, not per cluster. It is charged only on EC2 instances that Auto Mode launches and manages. A cluster that runs a mix of Auto Mode nodes and legacy managed node groups only pays the fee on the Auto Mode ones.
• It is billed like EC2: per second, with a one-minute minimum.
• It is independent of how you buy the EC2 capacity. On-Demand, Spot, Reserved Instances and Compute Savings Plans all work with Auto Mode, but the management fee does not get discounted with them. This is the single most important pricing detail, and we will see why in the example below.
• It varies by instance type and region. AWS does not publish it as a contractual percentage. In the public examples for US West (Oregon) the fee works out to exactly 12% of the On-Demand rate, but always pull the real per-type rate for your region before modelling anything.

The published Oregon examples are:

GPU and accelerated instances have their own fee schedule, and AWS cut it on July 1, 2026: management fees for G-series instances dropped by 35%, and for P-series and Trainium by 60%, automatically for every Auto Mode cluster. If your earlier cost model for an ML cluster was built in 2025, redo it.

Worked example: 10 × m5a.2xlarge for a month

Take a steady cluster of ten m5a.2xlarge nodes in us-west-2, running 730 hours a month:

On raw bill, Auto Mode is about +11.7% for this cluster. Now apply discounts to the EC2 part only, because that is what happens in reality (the discount levels below are illustrative, not quotes):

The better you already are at buying compute, the more expensive Auto Mode looks in relative terms, because the fee is anchored to the On-Demand-scale price and does not shrink with your discount. A team that runs mostly Spot pays the equivalent of roughly a third on top of its compute bill.

The other side of the ledger is efficiency. If Auto Mode’s consolidation lets the same workloads run on nine nodes instead of ten, the Auto Mode bill becomes $2,260.08 EC2 + $271.21 fee + $73 = $2,604.29, within 1% of the managed node group cluster. In other words, you need roughly 11-12% better bin packing to break even on the raw bill at On-Demand prices. Clusters with fixed-shape node groups sized “just in case” often waste more than that; clusters already on well-tuned Karpenter usually do not.

Then add the part the bill does not show. The fee on this cluster is about $3,600 a year. At 100 nodes it is about $36,000 a year. Compare that against the hours your team spends on AMI rotation, autoscaler upgrades, add-on version matrices and node incidents. For a two-person platform team the fee is usually cheap; for a large platform team that already automated all of it, it is usually not.

Fargate for comparison

Fargate is priced per pod, per second, on requested vCPU and memory. In US East (N. Virginia), Linux/x86 is about $0.04048 per vCPU-hour and $0.004446 per GB-hour (September 2026), so a 1 vCPU / 2 GB pod running all month costs about $36. There is no node to pay for, but also nothing to bin-pack: you pay for requests, not usage, which makes right-sized requests and limits even more important than on EC2. And Amazon EKS does not support Fargate Spot.

EKS Auto Mode vs managed node groups vs Karpenter vs Fargate

EKS Auto Mode vs managed node groups

This is the comparison most teams actually face. Managed node groups give you a fixed capacity shape and full control of the node: your AMI, your kubelet flags, your host agents. Auto Mode gives you dynamic capacity and removes node operations, but takes the node away from you.

Pick managed node groups if you need custom or hardened AMIs, Windows, host-level security tooling, specific kernel settings, or if your capacity is steady and already heavily discounted (the fee hurts most there). Pick Auto Mode if your node groups are over-provisioned, your team spends real time on AMI rotations and add-on upgrades, and your workloads tolerate nodes being replaced at least every 21 days.

The two can coexist in the same cluster, which is also how migrations work: new workloads on Auto Mode, legacy or special ones on node groups.

EKS Auto Mode vs Karpenter

Auto Mode is Karpenter, but not your Karpenter. Both share the karpenter.sh/v1 NodePool API; the node class differs (NodeClass in eks.amazonaws.com/v1 for Auto Mode, EC2NodeClass in karpenter.k8s.aws/v1 for self-managed), and so do the instance labels (eks.amazonaws.com/instance-family vs karpenter.k8s.aws/instance-family).

Self-managed Karpenter has no fee and lets you choose the AMI, OS (including Windows), and node lifetime. In exchange you operate the controller, its IAM, the Spot interruption queue, GPU drivers and device plugins, and every upgrade. Auto Mode handles Spot interruptions without an SQS queue, ships NVIDIA and Neuron drivers, enables node repair by default, and upgrades the controller for you. If you already run Karpenter well, the fee buys you little. If you were about to adopt Karpenter, Auto Mode removes most of the adoption cost.

How it works in practice

You create or update an EKS cluster with Auto Mode enabled. The default setup uses two AWS-managed built-in node pools, system and general-purpose, which you can enable or disable but not modify. If you need more control, you create a NodeClass for Auto Mode infrastructure settings and a NodePool for workload-facing scheduling constraints.

# NodeClass: EKS Auto Mode infrastructure settings for managed EC2 nodes.
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-compute
spec:
  subnetSelectorTerms:
    - tags:
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        aws:eks:cluster-name: prod-eks
  ephemeralStorage:
    size: "100Gi"

# NodePool: workload-facing constraints for nodes that Auto Mode may provision.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-purpose-custom
spec:
  template:
    metadata:
      labels:
        billing-team: platform
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: private-compute
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: eks.amazonaws.com/instance-category
          operator: In
          values: ["c", "m", "r"]
  limits:
    cpu: "1000"
    memory: 1000Gi
  disruption:
    consolidationPolicy: Balanced
    consolidateAfter: 1m

The NodeClass is where you express AWS infrastructure placement and node-level defaults. The NodePool is where you express what kind of capacity is acceptable for workloads. Do not copy a self-managed Karpenter EC2NodeClass into Auto Mode; Auto Mode uses its own NodeClass API.

A few defaults are worth knowing because they drive both disruption and cost. Auto Mode consolidates underutilized nodes, expires nodes after 336 hours (14 days) unless you change it, never lets a node live beyond 21 days, applies a disruption budget of 10% of nodes, and replaces nodes for drift when a new Auto Mode AMI ships, roughly once a week. consolidationPolicy accepts WhenEmpty, WhenEmptyOrUnderutilized and Balanced; the last one weighs disruption cost against savings and skips consolidations that are not worth it, which is a sensible default for most production pools. A billing label in the NodePool template (like billing-team above) is the cheapest way to get per-team cost allocation later.

Built-in components are managed differently than in a classic EKS build. Pod networking (with network policy enforcement), service networking, cluster DNS, compute autoscaling, EBS block storage, load balancing, the Pod Identity agent and node monitoring are Auto Mode capabilities. With Auto Mode compute, add-ons such as Amazon VPC CNI, kube-proxy, CoreDNS, the Amazon EBS CSI Driver and the EKS Pod Identity Agent become redundant for Auto Mode nodes, and the controllers run on AWS-owned infrastructure rather than as visible pods in your account. Autoscaling of replicas is still yours: Auto Mode adds nodes for pending pods, but you still need an HPA or KEDA to create those pods (see HPA best practices).

The workload support matrix is broader than Fargate, but not identical to self-managed nodes:

What changed in 2025 and 2026

Auto Mode has moved fast since launch, and several of the early “reasons not to use it” are gone. The ones worth knowing, all from AWS announcements:

• October 2025, networking and security controls. The NodeClass gained podSubnetSelectorTerms and podSecurityGroupSelectorTerms for separate pod subnets, advancedNetworking options for public IP control and forward HTTPS proxies (httpsProxy, noProxy), certificateBundles for enterprise CAs, KMS encryption of root and ephemeral volumes, and support for On-Demand Capacity Reservations and Capacity Blocks for ML. Corporate proxies and private CAs used to be hard blockers; they are not anymore.
• October 2025, GovCloud. Auto Mode became available in AWS GovCloud (US-East) and (US-West), and later in the AWS China Regions.
• February 2026, enhanced logging. Auto Mode’s managed capabilities (compute autoscaling, block storage, load balancing, pod networking) can be configured as CloudWatch Vended Logs sources and delivered to CloudWatch Logs, S3 or Firehose. This closes the “black box” gap: you can finally see why the managed Karpenter did or did not launch a node.
• April 2026, hidden managed instances. New Auto Mode instances and their resources are hidden by default from EC2 console views and API list operations. Good for accidental-deletion safety, surprising for cost and inventory tooling that lists EC2 instances directly. Adjust the managed resource visibility settings if your FinOps scripts rely on them.
• July 2026, cheaper accelerated compute. Management fees cut by 35% for G-series and 60% for P-series and Trainium, effective July 1.
• July 2026, zonal shift. Integration with Application Recovery Controller zonal shift: during a zonal shift Auto Mode stops provisioning in the impaired AZ and pauses voluntary disruption, at no extra cost.
• July 2026, EFA and placement groups for Auto Mode node pools, aimed at distributed training.
• Static capacity NodePools. Setting replicas on a NodePool keeps a fixed number of nodes regardless of demand, useful for latency-sensitive inference. Once set it cannot be removed, and static pools are never consolidated, so set limits.nodes above replicas to leave headroom for node replacement.

What you gain

Reduced operational surface. Node group management, AMI lifecycle, Cluster Autoscaler tuning, Karpenter controller upgrades, and a chunk of add-on wiring move out of your day-to-day scope.

Better provisioning shape by default. Dynamic provisioning is usually a better fit than fixed node group shapes. You get nodes that more closely match actual pod requirements instead of trying to pre-plan a small set of instance types, and that is exactly the efficiency that has to pay for the fee.

Automatic node patching. AWS manages the node image and replacement flow. That reduces toil, but it also means your workloads need disruption policies that let AWS replace nodes safely.

Faster cluster bootstrapping. A new Auto Mode cluster gets to a usable production baseline faster than a hand-assembled EKS cluster with node groups, autoscaling, networking add-ons, storage drivers, and load balancer controllers.

Native Spot integration. Spot interruptions, rebalance recommendations, scheduled maintenance and instance health events are handled for you, with no Node Termination Handler or SQS queue. You still need workload-level interruption tolerance: replicas, budgets, graceful shutdown, and queue semantics where relevant.

What you give up

Node-level access. Auto Mode nodes are intentionally locked down. If your incident response process assumes SSH, SSM, manual package inspection, or ad hoc host changes, it needs to change. Ephemeral debug containers become your main tool; the patterns in debugging distroless containers apply almost verbatim.

Custom AMIs. AWS determines the operating system and AMI for Auto Mode managed instances; you cannot directly access the instance or install software on it. If your organization requires internally built, hardened, or certified AMIs, Auto Mode is likely blocked. (For how Bottlerocket compares to other container-optimized OSes, see Talos vs Bottlerocket vs Flatcar.)

Unrestricted host agents. Kubernetes DaemonSets are supported, but they are the sharp edge. Anything that assumes privileged host access, custom kernel modules, hostPath writes, or low-level runtime integration needs a proof of compatibility.

Less tuning surface. You give up direct control over kubelet flags, container runtime configuration, bootstrap scripts, and arbitrary node setup. That is the point of the product, but it is also the boundary.

Different cost visibility. Managed node groups make capacity easy to reason about because you chose it up front. Auto Mode changes capacity dynamically and, since April 2026, hides its instances from default EC2 listings, so cost control moves toward NodePool limits, billing labels, Cost Explorer and workload-level resource hygiene.

When NOT to use EKS Auto Mode

Auto Mode is a good default, but there are clear cases where it is the wrong answer:

• You need Windows nodes. Auto Mode is Linux only.
• You must own the node image supply chain: certified or hardened AMIs, CIS images built in-house, or specific kernel modules.
• Your security or observability stack needs host access that the locked-down Bottlerocket nodes do not allow, and the vendor has no supported Auto Mode deployment.
• Your compute is already heavily discounted and efficiently packed. With mostly Spot or Savings Plans and a well-tuned Karpenter, the fee is a large relative premium for work you have already automated.
• You run singleton stateful workloads that cannot tolerate node replacement at least every 21 days. Auto Mode will rotate the node anyway; if the PDB blocks it, you are just postponing an incident.
• You rely on an alternative CNI or networking setup that Auto Mode does not support.
• You need tight kubelet or runtime tuning (custom eviction thresholds, runtime configuration, special sysctls on the host).

When to use EKS Auto Mode

Use Auto Mode if:

• You run EKS on AWS and do not have a hard requirement to manage nodes yourself
• You do not require custom AMIs or custom node bootstrap logic
• You want to reduce the operations surface for node lifecycle management
• You want Karpenter-like provisioning without operating Karpenter yourself
• Your workloads are mostly stateless or disruption-tolerant
• Your observability, security, and storage agents are compatible with Auto Mode

Stick with managed node groups if:

• Your organization requires internally certified or hardened AMIs
• You need specific kernel configuration, kubelet flags, bootstrap scripts, or host packages
• You depend on privileged DaemonSets or host-level security tooling that Auto Mode cannot support
• You are in a regulated environment where the node image supply chain must be owned internally
• Your platform team already operates Karpenter well and values the extra control

Use Fargate if:

• You specifically want per-pod compute isolation
• Your workload does not need DaemonSets or host-level integrations
• You accept Fargate’s scheduling, networking, storage, and observability constraints
• You want to avoid managing EC2 capacity entirely for a narrow class of workloads

Migration from managed node groups

Migrating an existing cluster to Auto Mode is supported, but it is not a one-command operational migration. You must update the cluster IAM role permissions and trust policy, enable the compute, block storage, and load balancing capabilities together, and meet required add-on versions when those add-ons are installed. AWS does not support direct migration of EBS volumes from the standard EBS CSI provisioner to the Auto Mode one, of existing load balancers from AWS Load Balancer Controller to Auto Mode, or of clusters using alternative CNIs. A conservative path looks like this:

1. Enable Auto Mode on a non-production cluster running a supported Kubernetes version (1.29 or later).
2. Inventory workloads by scheduling assumptions: node selectors, affinities, tolerations, topology spread, PDBs, privileged mode, hostPath, local storage, and DaemonSet dependencies.
3. Create or select the relevant Auto Mode NodeClass and NodePool resources.
4. Move a low-risk namespace first by changing selectors, tolerations, or labels so pods land on Auto Mode nodes (eks.amazonaws.com/compute-type: auto identifies them).
5. Watch scheduling, replacement, load balancer behavior, persistent volume provisioning, logging, metrics, and security events.
6. Taint old node groups to stop new scheduling once the pilot workloads are stable.
7. Drain old nodes gradually and delete old managed node groups only after workload owners have signed off.

You can keep AWS Load Balancer Controller installed during the migration when you need both models; separate them with IngressClass or loadBalancerClass and plan a blue-green move for existing load balancers.

The hardest part is usually not enabling Auto Mode. It is discovering which workloads and platform agents quietly depended on a mutable node.

What breaks when you migrate

Auto Mode changes the node contract. The Kubernetes API still looks familiar, but the host underneath is no longer yours in the same way.

DaemonSets need a compatibility audit. Logging agents, metrics agents, service mesh node components, security scanners, CSI node plugins, and custom infrastructure daemons often assume host access. Datadog, Falco, custom CSI drivers, eBPF agents, file integrity tools, and in-house node agents should be tested explicitly rather than assumed compatible.

PodDisruptionBudgets can block AWS-managed maintenance. If every critical Deployment has maxUnavailable: 0, or singleton workloads have no safe disruption path, node replacement becomes harder, and the 21-day lifetime means it will happen anyway. Auto Mode can manage nodes, but it cannot make an application disruption-tolerant after the fact.

nodeSelector and affinity rules can strand pods. Workloads pinned to old node group labels, instance types, capacity labels, zones, or custom AMI labels may never schedule on Auto Mode capacity. Replace legacy labels with stable requirements Auto Mode can satisfy, and remember that instance labels use the eks.amazonaws.com/ prefix, not karpenter.k8s.aws/.

topologySpreadConstraints can become too strict. Auto Mode provisions capacity dynamically, but strict zone spreading plus narrow selectors can create unschedulable pods. Check whenUnsatisfiable, label selectors, and minimum domain assumptions.

Privileged pods and hostPath volumes are migration blockers until proven otherwise. Anything that needs /var/lib, /proc, /sys, container runtime sockets, kernel capabilities, or host networking deserves a separate test. For a broader list of patterns that hurt under node churn, see Kubernetes features that hurt in production.

Observability and security agents may lose host assumptions. The dangerous failure mode is not CrashLoopBackOff; it is silent loss of telemetry or enforcement.

Storage drivers must be reviewed. EBS integration is part of Auto Mode, but it uses the provisioner ebs.csi.eks.amazonaws.com, not the standard ebs.csi.aws.com. Custom CSI drivers, EFS patterns, snapshot controllers, and topology-aware storage classes should be validated. Pay attention to provisioner names, volume binding mode, encryption settings, and IAM assumptions.

Runbooks need rewriting. “SSH to the node and inspect X” is not a valid first response anymore. Incident procedures should move toward kubectl describe, events, logs, ephemeral debug containers, the Auto Mode vended logs, cloud-side metrics, and vendor-supported diagnostics.

Cost and inventory scripts may go blind. Since April 2026, Auto Mode instances are hidden from default EC2 list operations. Anything that inventories or tags instances by listing EC2 directly needs the visibility setting changed or a switch to Kubernetes-side data.

1-week pilot: evaluate Auto Mode without risking production

Use a short pilot to answer compatibility and economics questions before touching production.

Day 1: build a representative test cluster. Same region, Kubernetes minor version, VPC shape, IAM model, ingress pattern, and storage classes where possible.

Day 1-2: enable Auto Mode with one custom NodeClass and NodePool. Keep the first pool boring: on-demand capacity, two or three common instance families, the same private subnet pattern as production, and a billing label.

Day 2-3: move three workload types. One stateless service, one stateful service with EBS, and one platform-heavy workload that uses observability or security agents. Run the scheduling audit (selectors, affinity, topology spread, PDBs, tolerations, privileged mode, hostPath, DaemonSets) before each move.

Day 4: force normal failure modes. Roll deployments, delete pods, scale replicas up and down, trigger consolidation, and simulate one Spot-tolerant workload if you plan to use Spot.

Day 5: validate platform signals. Confirm logs, metrics, traces, runtime alerts, security events, load balancer provisioning, DNS, and persistent volume operations. Enable the Auto Mode vended logs and check that you can explain every node launch.

Day 6-7: compare costs and toil. Record the EC2 instance mix, the published fee for each instance type in your region, pod density, pending time, interruption behavior, and operator actions required. Rerun the worked example above with your real numbers and your real discounts.

Success criteria should be explicit:

• 95%+ of pilot pods schedule without manual intervention
• No silent loss of logs, metrics, traces, or security alerts
• PDBs allow node replacement for replicated services
• Stateful workloads survive rescheduling and volume attachment tests
• Cost model is understood at instance-type level, including the fee on discounted capacity
• Production migration blockers are documented with owners

If the pilot fails, that is still useful. It tells you which node assumptions are real and which workloads should stay on managed node groups.

The honest assessment

EKS Auto Mode is a good default candidate for many teams running Kubernetes on AWS, and a better one in late 2026 than at launch: proxies, private CAs, capacity reservations, logging and zonal shift were real gaps that have been closed. The operational simplification is real: node provisioning, AMI updates, core add-on integration, and scaling behavior are areas where teams burn time and create incidents.

The constraints are also real. Custom AMIs, Windows, unrestricted host access from DaemonSets, privileged pods, custom CSI drivers, and strict disruption policies are the common blockers. And the fee is not trivial for teams that already buy compute cheaply: it does not shrink with Spot or Savings Plans.

The right question is not whether Auto Mode is “better” than managed node groups. It is which operational contract your workloads can live with, and whether the fee is smaller than the node-management work it removes. The more your organization can treat nodes as replaceable capacity, the more value you get. The more your platform treats nodes as customized machines, the less Auto Mode fits.

Frequently Asked Questions

Sources

• Amazon EKS pricing
• AWS Fargate pricing
• AWS News Blog: Streamline Kubernetes cluster management with new Amazon EKS Auto Mode
• AWS Containers Blog: Getting started with Amazon EKS Auto Mode
• AWS Containers Blog: New Amazon EKS Auto Mode features for enhanced security, network control, and performance
• Amazon EKS User Guide: Automate cluster infrastructure with EKS Auto Mode
• Amazon EKS User Guide: Create a cluster with Amazon EKS Auto Mode
• Amazon EKS User Guide: Enable EKS Auto Mode on an existing cluster
• Amazon EKS User Guide: Migrate to EKS Auto Mode
• Amazon EKS User Guide: Create a Node Class for Amazon EKS
• Amazon EKS User Guide: Create a Node Pool for EKS Auto Mode
• Amazon EKS User Guide: Manage compute for AI/ML workloads with EKS Auto Mode and Karpenter
• Amazon EKS User Guide: Learn about Amazon EKS Auto Mode managed instances
• Amazon EKS User Guide: Deploy an accelerated workload
• Amazon EKS User Guide: Update organization controls for EKS Auto Mode
• Amazon EKS User Guide: Amazon EKS add-ons
• Amazon EKS User Guide: Deploy Windows nodes on EKS clusters
• Amazon EKS User Guide: Simplify compute management with AWS Fargate
• AWS What’s New: EKS Auto Mode reduces GPU management fees by up to 60% (July 2026)
• AWS What’s New: EKS Auto Mode supports ARC zonal shift (July 2026)
• AWS What’s New: EKS Auto Mode enhanced logging (February 2026)
• AWS What’s New: EFA and placement groups for EKS Auto Mode and Karpenter (July 2026)
• AWS What’s New: EKS Auto Mode now available in AWS GovCloud (US-East) and (US-West)
• AWS China What’s New: Amazon EKS Auto Mode now available in AWS China Regions