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.

ACK considerations for EKS

This topic covers important considerations for using the EKS Capability for ACK, including IAM configuration, multi-account patterns, and integration with other EKS capabilities.

IAM configuration patterns

The ACK capability uses an IAM Capability Role to authenticate with AWS. Choose the right IAM pattern based on your requirements.

Simple: Single Capability Role

For development, testing, or simple use cases, grant all necessary permissions directly to the Capability Role.

When to use:

Example: Add S3 and RDS permissions to your Capability Role with resource tagging conditions:

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": ["rds:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        },
      }
    }
  ]
}

This example limits S3 and RDS operations to specific regions and requires RDS resources to have a ManagedBy: ACK tag.

Production: IAM Role Selectors

For production environments, use IAM Role Selectors to implement least-privilege access and namespace-level isolation.

When to use:

Benefits:

For detailed IAM Role Selector configuration, see Configure ACK permissions.

Integration with other EKS capabilities

GitOps with Argo CD

Use the EKS Capability for Argo CD to deploy ACK resources from Git repositories, enabling GitOps workflows for infrastructure management.

Considerations:

GitOps provides audit trails, rollback capabilities, and declarative infrastructure management. For more on Argo CD, see Working with Argo CD.

Resource composition with kro

Use the EKS Capability for kro (Kube Resource Orchestrator) to compose multiple ACK resources into higher-level abstractions and custom APIs.

When to use kro with ACK:

Example patterns:

kro handles dependency ordering, status propagation, and lifecycle management for composed resources. For more on kro, see kro concepts.

Organizing your resources

Organize ACK resources using Kubernetes namespaces and AWS resource tags for better management, access control, and cost tracking.

Namespace organization

Use Kubernetes namespaces to logically separate ACK resources by environment (production, staging, development), team (platform, data, ml), or application.

Benefits:

Resource tagging

EKS automatically applies tags to AWS resources managed by ACK, including the capability resource ARN. Add additional tags for cost allocation, ownership tracking, and organizational purposes.

Recommended tags:

Migration from other Infrastructure-as-code tools

Many organizations are finding value in standardizing on Kubernetes beyond their workload orchestration. Migrating infrastructure and AWS resource management to ACK allows you to standardize infrastructure management using Kubernetes APIs alongside your application workloads.

Benefits of standardizing on Kubernetes for infrastructure:

ACK supports adopting existing AWS resources without recreating them, enabling zero-downtime migration from CloudFormation, Terraform, or resources external to the cluster.

Adopt an existing resource:

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: existing-bucket
  annotations:
    services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
  name: my-existing-bucket-name

Once adopted, the resource is managed by ACK and can be updated through Kubernetes manifests. You can migrate incrementally, adopting resources as needed while maintaining existing IaC tools for other resources.

ACK also supports read-only resources. For resources managed by other teams or tools that you want to reference but not modify, combine adoption with the retain deletion policy and grant only read IAM permissions. This allows applications to discover shared infrastructure (VPCs, IAM roles, KMS keys) through Kubernetes APIs without risking modifications.

For more on resource adoption, see ACK concepts.

Deletion policies

Deletion policies control what happens to AWS resources when you delete the corresponding Kubernetes resource. Choose the right policy based on the resource lifecycle and your operational requirements.

Delete (default)

The AWS resource is deleted when you delete the Kubernetes resource. This maintains consistency between your cluster and AWS, ensuring resources don’t accumulate.

When to use delete:

The default delete policy aligns with Kubernetes' declarative model: what’s in the cluster matches what exists in AWS.

Retain

The AWS resource is kept when you delete the Kubernetes resource. This protects critical data and allows resources to outlive their Kubernetes representation.

When to use retain:

apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: production-db
  annotations:
    services.k8s.aws/deletion-policy: "retain"
spec:
  dbInstanceIdentifier: prod-db
  # ... configuration

For more on deletion policies, see ACK concepts.

Upstream documentation

For detailed information on using ACK:

Next steps