Your ElastiCache Cluster Names Are About to Go Public

AWS sent out a Health Dashboard notification recently that's easy to skim past. The subject line is about TLS certificates. The actual content is about something more specific: if you've ever given an ElastiCache cluster a name that reveals something sensitive, that name is about to become permanently public and there's no way to undo it.

What AWS Actually Said

Google's Chrome Root Program now requires all publicly trusted TLS certificates to be submitted to Certificate Transparency (CT) logs, effective June 2026. When you enable in-transit encryption on an ElastiCache cluster, AWS provisions a TLS certificate for the cluster's endpoint, and that certificate includes your cluster name. Because of the Chrome policy change, those certificates are now landing in public CT logs whenever they're issued or renewed.

The retroactive part is what makes this worth paying attention to: clusters created before June 2026 aren't exempt. Their names get logged the next time the certificate renews, which is a maintenance event most people aren't watching for.

AWS's own guidance is blunt about the remediation options, because there basically aren't any:

• You cannot remove a cluster name from CT logs once it's logged. They're append-only by design.
• You cannot rename an existing ElastiCache cluster.
• If a cluster name contains anything sensitive, the only fix is to create a new cluster with a non-sensitive name, migrate your data, and delete the original.

Why This Is Only Showing Up Now

Certificate Transparency itself isn't new. It's been a de facto requirement for public CAs since around 2018, when Chrome started enforcing SCT (Signed Certificate Timestamp) checks on certificate validation. What changed is the scope: the Chrome Root Program has been tightening the policy on CA owners, and ElastiCache's in-transit-encryption certificates are now getting swept into that requirement in a way they apparently weren't before.

The reason ElastiCache is affected at all comes down to which certificate authority it uses. ElastiCache's TLS certs chain up to a publicly trusted root, which is why they're subject to Chrome's CT policy in the first place. That's a meaningfully different setup from something like RDS, which issues certificates from AWS's own private rds-ca root - a CA that isn't in your browser's trust store by default and that you have to manually install. Private CAs aren't part of any public root program, so they aren't bound by the Chrome Root Program's CT logging mandate the same way.

What to Actually Check

If you have ElastiCache clusters with in-transit encryption enabled, this is a five-minute audit:

1. Check the Health Dashboard. The "Affected resources" section on the original notification lists the specific clusters. If you're subscribed to EventBridge, the affectedEntities field on the event carries the same information, and DescribeAffectedEntities gives you the same list via API if you want it in a script.
2. Review your cluster names. Look for anything that encodes a client name, an internal project codename, an unreleased product name, an employee name, or an environment detail you wouldn't want sitting in a public, permanently archived log that tools like crt.sh index and make trivially searchable.
3. If a name is sensitive, plan the migration now, not at renewal time. Standing up a new cluster, cutting over application config, and decommissioning the old one is nontrivial for anything stateful and in production. Renewal is the trigger, but you don't want to be doing this reactively when a cert is about to expire.

The Naming Convention Worth Adopting

The actual lesson here isn't about ElastiCache specifically. It's that any AWS resource name that ends up embedded in a publicly issued TLS certificate should be treated as public information from the moment you create it - not just for ElastiCache, but as a general default for anything with a public-CA-backed endpoint.

A cluster name like client-acme-prod-cache tells anyone reading the CT log who your client is. Something like cache-prod-us1-a1b2 tells them nothing. The second version costs you nothing in usability if you're already tracking the mapping in your infrastructure code or a tagging scheme, and it means the next policy tightening from a browser vendor doesn't turn into an incident.

If you're setting ElastiCache naming conventions today, this is a good moment to bake that in before it's a migration project instead of a naming choice.