AWS Builder Center

Builder Center

Amazon EKS now supports local clusters on AWS Outposts with Amazon EC2 instance store

AWS has overhauled how the control plane is managed for EKS local clusters on EC2 instance store-backed Outposts racks, handing etcd backup operations to a service-owned account. The update also brings IRSA, EKS Pod Identity, and other cloud EKS security features to Outposts for the first time.

haruki

Introduction

On June 11, 2026, AWS announced support for Amazon EKS local clusters running on AWS Outposts racks that boot Amazon EC2 instances from instance store. The update overhauls how the Kubernetes control plane is managed, significantly closing the feature gap with EKS clusters running in the cloud.
If you're running an EKS local cluster on Outposts, you've likely felt the friction of managing etcd backups yourself, or not having access to the authentication and access control mechanisms you take for granted in the cloud. This update closes that gap directly.
This post walks through what changed, what it means for existing clusters, how to get started, and where this update delivers the most value. If you're running EKS on Outposts today, or evaluating it, read on.

What Changed

If you've run an EKS local cluster on Outposts, you've likely felt how much "you can't do that here" compared to EKS in the cloud.
AreaBeforeAfter
Control plane managementYou manage etcd backups and logging agents yourselfManaged by Amazon EKS in a service-owned account; no action required on your part
Authentication and access controlIRSA, EKS Pod Identity, OIDC authentication, and access entries are unavailableAll of the above are now supported
Worker node OS optionsAmazon Linux 2023 onlyAmazon Linux 2023 plus Bottlerocket
New version availabilityReleased on a separate timeline for local clustersReleased in step with EKS in the cloud

The Previous Challenge

EKS local clusters on Outposts that boot from EC2 instance store run the control plane on Outposts, but operating it hasn't been as fully supported as the cloud experience. Configuring and operating etcd backups and logging agents was your responsibility, and keeping the control plane available added directly to your operational load.
On top of that, authentication and access control mechanisms you'd take for granted in the cloud, including IRSA and EKS Pod Identity, simply weren't available. Worker nodes were limited to Amazon Linux 2023. Despite carrying the same "EKS" name, the feature set on Outposts lagged behind.

How the New Architecture Solves This

The new architecture hands control plane management to a service-owned account operated by Amazon EKS. As a result, etcd backups and logging agent operations are no longer your responsibility, and you gain access to the same feature set as cloud EKS: IRSA, EKS Pod Identity, OIDC authentication, access entries, and Bottlerocket worker nodes.
This new architecture only applies to Outposts racks that boot EC2 instances from instance store. Outposts that boot from Amazon EBS continue to run on the original architecture. We cover the exact scope in the "Scope and Requirements" section below.
Note: As of this writing (June 2026), the individual feature pages for IAM Roles for Service Accounts and EKS Pod Identity in the Amazon EKS User Guide still state that these features aren't available on local clusters on AWS Outposts, without distinguishing between the original and updated architectures. This is inconsistent with the What's New announcement for this update. Until AWS reconciles the documentation, verify behavior in your own environment or check with AWS Support before relying on this.

Architecture Deep Dive

The previous section covered what changed at a feature level. This section digs into why this change was possible from an architectural standpoint. If you only care about getting started, feel free to skip ahead.

Control Plane Management Handoff

The core of this update is that responsibility for managing the Kubernetes control plane moves to a service-owned account operated by Amazon EKS. Because Amazon EKS now manages the control plane from this service-owned account, you're no longer responsible for etcd backups or logging agent operations.
It's worth clarifying what doesn't change: the control plane doesn't physically move to the cloud. The Kubernetes control plane continues to run on EC2 instances on your Outposts rack, so your data residency requirements are preserved. What changes is who operates and backs up the control plane, and under which account's authority. Think of it as the same separation you already get with cloud EKS, where you don't need to think about the control plane's internals, now extended to local clusters on Outposts.

EC2 Instance Store Static Stability

This update also builds on EC2 instance store static stability , announced in November 2024. Static stability lets EC2 instances backed by instance store automatically recover from power failures or reboots, even when the connection to the parent AWS Region is temporarily unavailable. This update extends that same benefit to EKS local clusters.
It's worth distinguishing this from network disconnect resilience. Local clusters were already designed to keep the control plane and nodes running on the Outpost, so applications keep running through a temporary network disconnect from the cloud. Static stability goes a step further: it adds automatic recovery even when a power failure or reboot happens on top of that disconnect.
Static stability isn't available for EC2 instances that boot from Amazon EBS. AWS states this explicitly. AWS doesn't explain why, but a reasonable explanation, and this is the author's own inference, is that EC2 instance store is local storage physically attached to the host, while EBS is network-attached block storage, which makes it harder to guarantee the kind of autonomous operation during a network disconnect that static stability depends on. This is likely the technical reason this update is scoped to Outposts racks that boot from instance store.

Architecture Diagram

At a simplified level, the architecture looks like this:
The control plane in this diagram is managed by a service-owned AWS account, and the Outposts rack boots from EC2 instance store. Worker nodes can run Bottlerocket or Amazon Linux 2023. Control plane management responsibility has moved to AWS, but the control plane itself continues running on the Outposts rack.

Scope and Requirements

The scope of this update is well defined. The new architecture applies when you build a local cluster on a first- or second-generation AWS Outposts rack that boots EC2 instances from instance store.
ItemDetails
Supported rack generationsFirst- and second-generation AWS Outposts racks
Boot requirementEC2 instances that boot from EC2 instance store
Not supportedOutposts that boot from Amazon EBS (continues on the original architecture)
Supported RegionsAll commercial AWS Regions that support AWS Outposts racks
Outposts that boot from Amazon EBS are out of scope and continue running the original architecture, where you manage etcd backups and logging agents yourself. If you're ordering a new Outpost, keep in mind that your boot type choice directly determines which architecture you get.

Impact on Existing Clusters

One open question remains. Neither the AWS announcement nor the user guide states whether an existing local cluster automatically moves to the new architecture, or whether it needs to be recreated.
For context, EC2 instance store static stability, announced in November 2024 and the capability this update builds on, was automatically applied to all instance-store-backed instances with no action required. That doesn't guarantee the same will hold for this control plane architecture change. If you're running a production cluster, confirm the migration path with AWS Support or your account team before making any assumptions.

Implementation Walkthrough

AWS Outposts isn't a service you spin up in minutes like an EC2 instance. It's hardware you order and have physically installed as a rack or server. This section is an implementation guide for anyone who already has an Outposts environment, or is evaluating one, rather than a "follow along live" tutorial (the AWS console and AWS CLI support the same operations as well).
You'll need an Outposts rack that boots from EC2 instance store, the latest versions of eksctl, kubectl, and the AWS CLI, and an IAM principal with create and describe permissions for EKS clusters.

Creating the Cluster Configuration File

Define a ClusterConfig like the one below. Set outpost.controlPlaneOutpostARN to your target Outpost's ARN, and the control plane is created on that Outpost.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-local-cluster
region: us-east-1
version: "1.33"
vpc:
clusterEndpoints:
privateAccess: true
id: "vpc-xxxxxxxxxxxxxxxxx"
subnets:
private:
outpost-subnet-1:
id: "subnet-xxxxxxxxxxxxxxxxx"
outpost:
controlPlaneOutpostARN: arn:aws:outposts:us-east-1:111122223333:outpost/op-xxxxxxxxxxxxxxxxx
controlPlaneInstanceType: m5.large
If you omit controlPlaneInstanceType, eksctl selects the smallest instance type available on the Outpost. The control plane always deploys with three instances, and you can't change that number. To maintain quorum, at least two of the three instances must be healthy at all times.

Creating the Cluster

1
eksctl create cluster -f my-local-cluster.yaml
Creation takes a few minutes. When it's done, you'll see a line like EKS cluster "my-local-cluster" ... is ready. If you want to create node groups in the same configuration file, check the official documentation for the required VPC and local gateway setup.

Automatic Access Entry Creation

When you create a cluster with eksctl, it automatically creates an access entry for the IAM principal that created the cluster, granting it administrator access to Kubernetes objects. This is a concrete example of access entries, covered earlier in "What Changed," actually working on local clusters under the new architecture. You can view access entries from the console's Access tab, or by running aws eks list-access-entries --cluster-name my-local-cluster.

Verifying the Cluster

1
2
3
4
5
aws eks describe-cluster --name my-local-cluster --region us-east-1 --query "cluster.status"

aws eks update-kubeconfig --name my-local-cluster --region us-east-1

kubectl get nodes
Once status shows ACTIVE, the cluster is ready. Run kubectl get nodes to confirm your worker nodes are recognized.

Use Cases

Here's how this update solves specific problems, based on everything covered above.

Operating Local Clusters on Outposts Feels Heavy

If you've been running an EKS local cluster on an instance-store-backed Outpost and spending real operational effort on etcd backups and logging agents, this update hands that work directly to AWS. As covered in the architecture section, control plane management responsibility itself moves to a service-owned AWS account, removing the operational risk of missed backups or misconfigured logging agents.

You Want the Same Security Model as Cloud EKS

This update also addresses the need to use the same mechanisms you rely on in cloud EKS, including IRSA, EKS Pod Identity, and access entries, on Outposts. As noted earlier, the individual user guide pages for IRSA and EKS Pod Identity still list Outposts as unsupported, so verify behavior in your own environment before relying on this in production.

You Need Both Data Residency and Network Resilience

If your environment requires keeping data physically on site, the defining property of local clusters, running the entire Kubernetes control plane on premises, matters most. This update lets you meet data residency requirements while also gaining the benefit of static stability: automatic recovery from power failures and reboots. For sites where the connection back to the Region is prone to instability, being able to keep both applications and cluster operations running is a meaningful source of reassurance.

Conclusion

This post covered the new architecture for EKS local clusters on Outposts racks backed by EC2 instance store.

How This Compares to Other EKS Deployment Options

Local clusters aren't the only way to run Kubernetes on Outposts. It helps to compare deployment options by where the control plane and worker nodes actually run.
Deployment optionControl planeWorker nodesBest fit
EKS local clusters (Outposts)On Outposts (on premises)On Outposts (on premises)Network disconnect resilience, strict data residency
EKS Hybrid NodesAWS Region (cloud)Your own on-premises or edge hardwareBringing existing on-premises hardware into EKS
EKS Auto ModeAWS Region (cloud)AWS Region (cloud, managed by AWS)Reducing operational overhead in the cloud
EKS Hybrid Nodes keeps the control plane in the cloud while letting you bring your own on-premises hardware in as worker nodes, so there's no need to procure dedicated Outposts hardware. But because the control plane lives in the cloud, it behaves differently from local clusters during a network disconnect, since local clusters keep the entire control plane on premises. EKS Auto Mode, meanwhile, is a cloud-only option for EKS and isn't really comparable to Outposts at all. If you need both network disconnect resilience and strict data residency, local clusters are the option that fits.
This update, while scoped to a specific configuration, directly addresses the operational burden and feature gap that local cluster users have dealt with for years. The caveats covered throughout this post still apply, so verify them against your own environment before rolling this out.

Additional Resources

# amazon-eks# kubernetes# outposts# amazon-ec2
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article