Comparing EKS Capability for ACK to self-managed ACK - Amazon EKS
Differences from upstream ACKMigration pathNext steps

Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

Comparing EKS Capability for ACK to self-managed ACK

The EKS Capability for ACK provides the same functionality as self-managed ACK controllers, but with significant operational advantages. For a general comparison of EKS Capabilities vs self-managed solutions, see EKS Capabilities considerations. This topic focuses on ACK-specific differences.

Differences from upstream ACK

The EKS Capability for ACK is based on upstream ACK controllers but differs in IAM integration.

IAM Capability Role: The capability uses a dedicated IAM role with a trust policy that allows the capabilities.eks.amazonaws.com service principal, not IRSA (IAM Roles for Service Accounts). You can attach IAM policies directly to the Capability Role with no need to create or annotate Kubernetes service accounts or configure OIDC providers. A best practice for production use cases is to configure service permissions using IAMRoleSelector. See Configure ACK permissions for more details.

Resource compatibility: ACK custom resources work identically to upstream ACK with no changes to your ACK resource YAML files. The capability uses the same Kubernetes APIs and CRDs, so tools like kubectl work the same way. All GA controllers and resources from upstream ACK are supported.

For complete ACK documentation and service-specific guides, see the ACK documentation.

Migration path

You can migrate from self-managed ACK to the managed capability with zero downtime:

  1. Update your self-managed ACK controller to use kube-system for leader election leases, for example:

    helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.namespace=kube-system

    This moves the controller’s lease to kube-system, allowing the managed capability to coordinate with it.

  2. Create the ACK capability on your cluster (see Create an ACK capability)

  3. The managed capability recognizes existing ACK-managed AWS resources and takes over reconciliation

  4. Gradually scale down or remove self-managed controller deployments:

    helm uninstall ack-s3-controller --namespace ack-system

This approach allows both controllers to coexist safely during migration. The managed capability automatically adopts resources previously managed by self-managed controllers, ensuring continuous reconciliation without conflicts.

Next steps