Version and Upgrade Strategy
Explore how to manage ElastiCache engine versions and upgrades, focusing on Redis OSS and Valkey. Understand lifecycle stages, risks of extended support, and upgrade types. Learn to plan coordinated upgrades including cluster mode transitions to modernize caching infrastructure while minimizing downtime and operational disruption.
The previous lesson covered newer ElastiCache capabilities for AI workloads, such as vector search in Amazon ElastiCache for Valkey 8.2 on node-based clusters, semantic caching, and memory patterns for agent-based applications. Teams still running Redis OSS 4 or 5 cannot use newer Valkey features such as vector search. The gap between current engine capabilities and older Redis OSS versions is more than a feature gap. It also creates lifecycle risk as older versions leave standard support and require Extended Support or an upgrade plan.
ElastiCache engine versions follow a defined support lifecycle. Each version moves through standard support, transitions into Extended Support, and eventually reaches an automatic upgrade deadline. Standard support for Redis OSS versions four and five ended on January 31, 2026, which means clusters running those versions are now accumulating additional cost and reduced patch coverage. Ignoring this timeline does not pause it. It simply converts a planned migration into an eventual emergency.
This lesson unpacks the key terms that govern this lifecycle:
The following diagram illustrates how these lifecycle stages relate to each other and where Redis OSS 4 and 5 currently sit on the timeline.
Redis OSS lifecycle and Extended Support
When a Redis OSS version exits standard support, AWS stops releasing regular security patches and bug fixes for that version under the standard model. The engine remains available, but the safety net shrinks.