Leveraging EKS Capabilities for Managed Kubernetes Infrastructure and Resource Orchestration

Stop Managing Kubernetes Infrastructure Manually — Use EKS Capabilities Instead

Amazon EKS Capabilities, a GA feature released in November 2025, runs AWS Controllers for Kubernetes (ACK) and Kube Resource Orchestrator (KRO) as fully managed services. This shift allows platform engineers to provision AWS resources like SQS and DynamoDB directly through kubectl without managing controller pods or manual IRSA configurations.

Why This Matters

Traditional Kubernetes management requires engineers to manually wire Helm charts and debug IRSA roles, which often leads to operational fatigue and resource waste on controller pods. By using EKS Capabilities, infrastructure management is abstracted into a managed service model where AWS handles scaling, patching, and upgrades, allowing teams to focus on defining standardized ‘golden paths’ for application delivery.

Key Insights

• EKS Capabilities (GA Nov 2025) removes the need to host and manage ACK and KRO controller pods within the cluster, reducing operational overhead.
• AWS Controllers for Kubernetes (ACK) allows cloud resources like DynamoDB and SQS to be managed as native Kubernetes Custom Resources (CRDs).
• Kube Resource Orchestrator (KRO) enables platform teams to define ResourceGraphDefinitions, creating custom Kubernetes APIs for complex multi-resource stacks.
• A specific RBAC binding is required for the managed KRO identity, which uses an STS assumed-role ARN with a ‘/KRO’ suffix, to manage child resources like Deployments.
• Kubernetes naming compliance (RFC 1123) is strictly enforced for metadata names, even when the underlying AWS resource name supports mixed case.

Working Examples

CLI command to enable the KRO managed capability on an EKS cluster.

aws eks create-capability \
--region us-east-1 \
--cluster-name Eks-Capabilities \
--capability-name kro \
--type KRO \
--role-arn $ROLE_ARN \
--delete-propagation-policy RETAIN

RBAC configuration required to allow the managed KRO service to create and manage child Kubernetes resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kro-resource-manager-binding
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: "arn:aws:sts::<ACCOUNT_ID>:assumed-role/Eks-Capabilities-capabilities-role/KRO"

A 13-line YAML manifest that provisions a Deployment, Service, and AWS SQS queue using a KRO-defined API.

apiVersion: kro.run/v1alpha1
kind: WebApp
metadata:
  name: orders-app
spec:
  appName: orders-app
  image: nginx:1.27
  replicas: 2
  service_name: orders-app-svc
  queueName: Eks-Dev-notifications

Practical Applications

• Standardized Developer Platforms: Using KRO to define a ‘WebApp’ resource that bundles app code with SQS infrastructure for consistent deployments.
• Infrastructure Reconciliation: Leveraging ACK to ensure that if an AWS SQS queue is manually deleted via the AWS console, Kubernetes automatically recreates it.
• Pitfall: Using mixed-case strings in the metadata.name field of a KRO template, which violates RFC 1123 and causes resource creation to fail.
• Pitfall: Forgetting to add the ‘/KRO’ suffix to the IAM role ARN in ClusterRoleBindings, which results in silent permission failures for managed orchestrators.

References:

• https://dev.to/aws-builders/stop-managing-kubernetes-infrastructure-manually-use-eks-capabilities-instead-2ap2