Amazon EKS Capabilities: Managed Argo CD, ACK, and kro Without Running More Controllers

Amazon EKS Capabilities is one of the more consequential EKS launches for platform teams because it moves beyond “managed Kubernetes control plane” and starts managing common platform controllers around the cluster as well. AWS announced Amazon EKS Capabilities on November 30, 2025, and as of April 10, 2026 the public capability set includes managed Argo CD, managed ACK, and managed kro.

That matters because most teams are not failing at Kubernetes itself. They are failing at the operational pile that accumulates next to Kubernetes: GitOps controllers, AWS resource controllers, platform composition layers, upgrades, IAM, and the constant question of who owns what. EKS Capabilities is AWS trying to reduce that pile without asking you to abandon standard Kubernetes APIs.

What Amazon EKS Capabilities Actually Does

The easiest way to think about EKS Capabilities is this: AWS runs the controller implementation, but your cluster still gets the Kubernetes APIs needed to use it.

For example, if you enable a capability for Argo CD, ACK, or kro, AWS installs and manages the relevant custom resources in the cluster while the controller runtime itself runs in AWS-managed infrastructure, not on your nodes. That changes a few things immediately:

• you do not schedule another controller deployment on your worker nodes
• you do not patch or upgrade that controller yourself
• you do not size nodes around one more always-on control-plane-style workload
• you still interact with Kubernetes-native resources instead of a proprietary API

This makes EKS Capabilities a platform abstraction, not just another add-on. It sits closer to internal platform engineering than to basic cluster setup. If you are still working through Amazon EKS basics or cleaning up access control in EKS RBAC and security, solve those first. Managed controllers do not fix weak cluster fundamentals.

The Capability Types Available Right Now

As of April 10, 2026, AWS documentation describes three capability families:

• Argo CD capability for GitOps deployment workflows
• ACK capability for provisioning AWS services through Kubernetes-style APIs
• kro capability for higher-level resource orchestration and composition

That combination is deliberate. Argo CD handles delivery. ACK handles AWS resource creation. kro handles composition across multiple resources. In other words, AWS is managing the three layers platform teams often end up stitching together manually.

If you already run GitOps on EKS, compare this model against your current stack before you migrate. The existing ArgoCD on EKS guide and Helm on EKS guide are still relevant because EKS Capabilities does not remove the need for sound packaging and rollout discipline. It changes who operates the controllers.

Why This Is Operationally Interesting

Self-hosted controllers are rarely expensive individually. The real cost is ongoing ownership:

• version drift between clusters
• controller upgrades during EKS upgrades
• IAM role design for each controller
• incident response when a controller starts reconciling incorrectly
• node capacity wasted on platform components that every cluster has to run

EKS Capabilities reduces those problems by shifting the controller runtime into AWS-managed infrastructure. You still define desired state, but AWS owns the controller lifecycle.

That is a meaningful difference from projects like Crossplane versus Terraform on Kubernetes. With Crossplane, you still operate Crossplane. With EKS Capabilities, AWS is trying to give you some of the same control-surface benefits while removing a chunk of the runtime burden.

What Changes for Your Team

The biggest practical change is that ownership boundaries become clearer.

Application teams can keep working with Git repos, manifests, and higher-level abstractions. Platform teams can define which managed capabilities are allowed in each cluster and standardize the operating model across environments. The cluster stops being a dumping ground for every controller someone wanted to install “just for one service.”

There are also technical limits you need to know before designing around it:

• AWS documentation currently states that a cluster can have one capability resource of each type
• EKS Capabilities is billed hourly, so this is not a free abstraction layer
• capability-specific prerequisites still exist, including IAM roles and, for Argo CD, AWS IAM Identity Center integration

That last point matters. Managed does not mean zero-configuration. It means AWS owns the controller software lifecycle, not that AWS designs your identity model for you.

Where EKS Capabilities Fits Best

EKS Capabilities is a strong fit when all of the following are true:

• you run multiple EKS clusters and want the same controller stack everywhere
• platform teams are tired of operating Argo CD or ACK themselves
• you want Kubernetes-native APIs without yet another self-hosted control plane
• you care more about reducing operational overhead than about deep controller customization

It is a weaker fit when any of the following is true:

• you need controller customizations that AWS does not expose
• you already have a stable, heavily customized in-cluster Argo CD or ACK deployment
• your team prefers full controller-level debugging and upgrade control
• you are only running one small cluster and the overhead is not actually painful

That tradeoff is the real decision. EKS Capabilities is not automatically “better.” It is better when the operational ownership cost is higher than the flexibility you would lose.

A Practical Adoption Pattern

If I were introducing this into a production environment, I would not start with the most business-critical cluster. I would use a controlled rollout:

1. Pick one non-critical EKS cluster with a clean IAM model.
2. Enable one capability only, usually Argo CD if GitOps standardization is the immediate goal.
3. Keep application packaging simple and avoid capability sprawl in the first rollout.
4. Document exactly what moved from platform ownership to AWS ownership.
5. Measure operational outcomes: fewer upgrades, fewer incidents, less node overhead, and clearer troubleshooting paths.

The goal is not to prove the feature exists. The goal is to prove it simplifies platform operations in your environment.

What It Does Not Replace

EKS Capabilities does not replace Kubernetes knowledge. It does not remove the need for:

• sane cluster networking
• IRSA or pod identity decisions
• RBAC design
• deployment review and rollback discipline
• workload-level observability

It also does not magically replace every platform pattern you already use. If you have a mature GitOps workflow, EKS Capabilities should slot into it, not force a redesign of it. Think of it as managed controller operations, not managed platform architecture.

That is why it fits naturally beside EKS Auto Mode rather than instead of it. Auto Mode reduces the node and infrastructure management surface. EKS Capabilities reduces the controller management surface. Different layers, same direction.

Final Recommendation

Amazon EKS Capabilities is worth serious attention if your EKS estate has grown to the point where the controller layer is becoming platform toil. The feature is compelling precisely because it targets a real operational pain: platform teams want Kubernetes-native workflows, but they do not want to babysit every controller those workflows require.

If you only run one straightforward cluster, the value may be marginal. If you run EKS as an internal platform, the value proposition is much stronger. That is the lens to use on April 10, 2026: not “is this new?” but “does this remove enough controller ownership to matter?”

Official AWS Sources Used

• Amazon EKS Capabilities user guide
• Amazon EKS Capabilities launch announcement, November 30, 2025
• Amazon EKS Capabilities pricing page