AWS load balancer controller v3.3.0

Kubernetes ingress on AWS has had an annoying last mile for years. The load balancer could be declared from Kubernetes, but the certificate often still had to be requested, validated, attached, and renewed through separate AWS steps. AWS Load Balancer Controller v3.3.0 changes that. The new release adds ACM certificate management, so the controller can create and manage TLS certs directly from Ingress hostnames instead of just discovering ones that already exist. ### What is this controller actually doing? AWS Load Balancer Controller is the Kubernetes component that watches Ingress, Service, and Gateway objects and turns them into AWS load balancers — mostly ALBs for Ingress and NLBs for Services. It has been the bridge between Kubernetes intent and AWS networking resources for a while, but cert lifecycle was mostly outside that bridge. ### What changed in v3.3.0? The big addition is called ACM Certificate Management. In v3.3.0, the controller can automatically create and manage TLS certificates in AWS Certificate Manager using hostnames from Ingress resources. This shipped in the v3.3.0 release published on GitHub, and the release notes flag it as a new Ingress feature rather than a side experiment. ### Wasn’t hostname-based cert handling already there? Sort of — but only the easier half. Earlier versions could do certificate discovery, which means the controller could look at Ingress `tls` entries or host rules and attach an existing ACM certificate if one matched. That is useful, but it still assumes someone created the cert first. The new feature crosses that line and handles certificate creation and management too. ### How do you turn it on? It is not on by default. You enable the feature gate with `--feature-gates=EnableCertificateManagement=true`, and then opt an Ingress in with the `create-acm-cert: "true"` annotation. The release also says teams need updated IAM permissions if they enable it, because the controller now needs ACM and Route53 access in addition to its normal load balancer permissions. ### Where does domain validation happen? For public Amazon-issued certificates, the flow uses DNS validation through Route53. Basically, if your Ingress hostname lives in a Route53-managed zone and the controller has the right permissions, the cert request and DNS proof can be wired together automatically. The feature also supports private certificates through AWS Private CA, which matters for internal platforms and private service meshes. ### Why is that a meaningful upgrade? Because certificate automation is usually where “Kubernetes-native” stories get less native. Platform teams can already declare listeners, target groups, and routing rules from manifests. But HTTPS often breaks the flow — someone has to notice a new hostname, request a cert, wait for validation, and remember renewals or replacements later. itself. ### What’s the catch? The catch is security scope. The controller now needs broader permissions, and the release notes explicitly call out IAM policy updates plus CRD updates as action items. That means teams should treat this like a real control-plane expansion, not just a convenience toggle. If your cluster has lots of tenants, who gets to create an Ingress may now map more directly to who can trigger certificate issuance. ### Who benefits most? EKS teams that already use Route53 and ACM get the cleanest win. They can keep expressing public entrypoints in Kubernetes and let the controller handle the AWS certificate plumbing too. Teams outside that setup still may need extra DNS or PKI work, but for the common “ALB + Route53 + ACM” stack, this removes one of the last manual HTTPS chores. Bottom line is simple: v3.3.0 makes AWS Load Balancer Controller more opinionated and more useful. It no longer just finds a certificate for your Ingress — it can become the thing that gets the certificate in the first place.