Since approximately 07:00 UTC today (10 September), interface VPC endpoints backing our ElastiCache Serverless caches in eu-west-2 have progressively stopped accepting TCP connections on port
6379. SYNs to the affected endpoint IPs are silently dropped (connection timeout, not refused). Throughout, the caches report "available", the VPC endpoints report "available", the ENIs report
"in-use", and nothing is shown on the Service Health Dashboard or in ElastiCache events.
Pattern observed:
- Failures are progressive: one endpoint failed ~07:00 UTC, another ~09:30, a third ~11:00 — across two separate VPCs and two separate serverless caches (one Redis OSS, one Valkey).
- Whether an endpoint works correlates exactly with the AWS-managed endpoint service (com.amazonaws.elasticache.serverless.eu-west-2.vpce-svc-…) behind it, not with anything in our VPCs.
Endpoints on vpce-svc-02b9b2177827c8ea4 and vpce-svc-07e01ad43b79080d2 are unreachable from every VPC; endpoints on sibling services in the same subnets with identical security groups work
normally.
- The failure appears AZ-scoped within a fleet: a multi-AZ endpoint on one affected service has 2 of 3 AZ ENIs dead, one still answering.
- VPC Reachability Analyzer over the failing path (instance → endpoint ENI, TCP/6379) returns reachable with no findings — routes, SGs and NACLs are verified correct by AWS's own tooling, so the
drop is inside the PrivateLink/ElastiCache data plane.
We've mitigated by pinning cache hostnames to the remaining reachable endpoint IPs, but that leaves no failover. Is anyone else in eu-west-2 seeing ElastiCache Serverless connection timeouts
today? And can anyone from AWS confirm whether there's a known issue with these fleet services? We're on Basic support so cannot raise a technical case.
