AWS Controllers for Kubernetes: the community repo behind ACK

What ACK solves, and who the community repo is actually for

A Kubernetes application usually needs a database, a queue and an object store alongside its pods. Those are AWS managed services, and provisioning them has traditionally meant leaving the cluster: Terraform runs, CloudFormation stacks, or a console session. ACK's answer is to expose AWS service resources as Kubernetes custom resources, so the application and its dependencies are declared in the same place. The README puts it plainly: ACK "lets you define and use AWS service resources directly from Kubernetes", without defining resources outside the cluster or running supporting services inside it.

The repository in question is not that machinery. aws-controllers-k8s/community is the coordination repository. The README describes ACK as "composed of many source code repositories" holding a common runtime, a code generator, common testing tools, and Kubernetes custom controllers for individual AWS service APIs, with links pointing to aws-controllers-k8s/runtime, aws-controllers-k8s/code-generator and aws-controllers-k8s/test-infra. The top level here contains docs/, scripts/, GOVERNANCE.md, CONTRIBUTING.md, ADOPTERS.md and CODEOWNERS. If you arrived looking for something to install, you are one repository away from the right place. This repo is for people deciding whether ACK fits, tracking which service controllers exist, and contributing to the project itself.

How ACK works: CRDs, controllers, and the code generator

ACK extends the Kubernetes API. The README defines it as "a collection of Kubernetes custom resource definitions (CRDs) and custom controllers working together to extend the Kubernetes API and manage AWS resources on your behalf." That sentence is the whole architecture in miniature. A CRD registers a new kind in the cluster, and a controller watches objects of that kind, calling the corresponding AWS API to create, update or delete the real resource.

The second half of the mechanism is the code generator. Because AWS has a large number of service APIs and they change, ACK does not hand-write every controller. The generator consumes a service API model and produces the controller and its CRDs, which is why the project ships as many per-service repositories rather than one monolith. The runtime is the shared library those generated controllers build on. The practical consequence for an operator is that coverage is uneven by design: a service is supported when someone has generated and released a controller for it, and the list of controllers sits in the project documentation rather than in this README.

Resource schemas are documented separately. The README points readers to reference documentation to "view the list of custom resources and each CR's schema", which is where you check whether a particular field is exposed before writing a manifest.

Installing an ACK controller and applying a first custom resource

The README does not give install commands for this repository, because this repository is not installed. It directs readers to the install documentation and states that any controller in the RELEASED project stage can be installed with Helm, which it calls the recommended route, or manually from the raw Kubernetes manifests in that controller's own source repository.

The starting point is the service controller list, which the README links as the place to see controllers "currently in one of our project stages". Pick the service you need, confirm it is in the RELEASED stage, then follow the install documentation for that controller. The README itself gives no Helm chart name, repository URL or controller name, and it does not spell out any kubectl invocation, so take the exact commands from that controller's own instructions rather than from this page.

What the README does say is what happens next: once a controller is installed, Kubernetes users "may apply a custom resource (CR) corresponding to one of the resources exposed by the ACK service controller for the service". A CR is an ordinary Kubernetes object, so it goes through kubectl the same way any other manifest does. What you should see is the object appearing in the cluster and the controller reconciling it against AWS. The exact kind, its fields and its required spec all come from the reference documentation for that service, which the README links as the place to check each CR's schema.

The Preview maintenance phase is the limitation that matters most

ACK's own README carries a warning that is easy to skim past. It asks readers to study the release versioning and maintenance phases documentation, and states that service controllers in the Preview maintenance phase "are not recommended for production use". It goes further: use of Preview controllers is subject to the AWS Service Terms, particularly the Beta Service Participation Service Terms.

That is a real constraint, not boilerplate. It means the answer to "does ACK support service X" is incomplete without a second question: in which phase is that controller? A service can have a controller and still be a poor choice for a regulated production workload. The README also notes that controllers live in separate repositories, so their maturity varies independently of this one.

There is a second boundary worth naming. ACK manages AWS resources through the Kubernetes API. If your organisation has no Kubernetes cluster and no intention of running one, ACK adds a control plane you do not otherwise need, and a Terraform or CloudFormation workflow will be simpler. ACK is for teams that already treat Kubernetes as the place where application dependencies are declared.

ACK against Terraform and CloudFormation

The obvious alternative is Terraform. The difference is where state lives and who owns reconciliation. Terraform holds a state file, and you drive it: plan, apply, and the provider reconciles your declared configuration against the cloud on your command. Drift is detected when you next run a plan. ACK has no state file. The custom resource in the cluster is the desired state, and the controller reconciles continuously, the same way a Deployment controller replaces a deleted pod. If someone changes the AWS resource outside Kubernetes, the controller can bring it back.

The trade-off runs the other way too. Terraform can provision an entire account, including the cluster itself, and it has providers for things Kubernetes does not host. ACK only manages what a given service controller exposes, and it runs inside the cluster it manages, which is an awkward position if the cluster is unhealthy. CloudFormation is closer to ACK in being AWS-native and declarative, but it is driven from outside Kubernetes and does not reconcile against cluster state.

The honest summary: ACK is not a Terraform replacement. It is what you reach for when the resource belongs to the application and the application lives in Kubernetes.

Maintenance, versioning and the Apache-2.0 licence

This repository is not archived, and its last push was on 2026-09-23. The README documents an ongoing rhythm: an ACK community meeting on the last Thursday of every month at 9:00 AM PST, with notes captured in a linked agenda document and a Zoom link, plus a Kubernetes Slack channel named #aws-controllers-k8s for help. For a project spread across many repositories, that meeting and the governance files at the top level (GOVERNANCE.md, CODEOWNERS, OWNERS_ALIASES) are where cross-repository decisions are recorded.

Upgrade cost is a function of the individual controllers, not of this repo. Because each service controller ships from its own repository, upgrading one is an independent operation, and the release versioning documentation the README links is the place to check what a version bump means for a given controller. The README does not document rollback for a controller upgrade, so treat that as something to confirm with the specific controller's documentation before you need it.

The licence is Apache-2.0, stated in the README and present as a LICENSE file at the top level. For most users that means permissive use with the usual obligations around notices and attribution; ATTRIBUTION.md and NOTICE are also present. This is a description of what the repository says, not legal advice, and anyone redistributing ACK should read the licence text itself.

Editorial conclusion

Adopt ACK if you already run Kubernetes and want AWS resources declared as custom resources in the same cluster, and check the project stage of each service controller before production use, since the README warns that Preview controllers are not recommended there. Do not start from aws-controllers-k8s/community expecting an installable component: it carries documentation, governance and the community meeting notes, while the runtime, code generator and per-service controllers live in separate repositories. Verify the maintenance phase of the specific controller you need, and confirm which install path its own repository documents.

Frequently asked questions

Official sources

1. aws-controllers-k8s/community on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README