SOFTWARE / SYSTEMS / AIEngineering news. Technical depth.
NEWS / Cloud · 2 MIN READ

AWS adds online migration to ElastiCache Serverless for Valkey

Supported EC2-hosted Valkey and Redis OSS clusters can migrate directly to serverless Valkey 9.0, with manual or automatic cutover and separate migration billing.

Announcement: · From AWS

AWS announced on October 20, 2026 that Amazon ElastiCache Serverless for Valkey supports online migration from self-managed Valkey and Redis OSS on Amazon EC2. AWS says the feature is available in all commercial AWS Regions, China Regions and AWS GovCloud (US) Regions. AWS announcement.

Supported sources and cutover controls

Supported sources are self-managed caches in cluster mode on EC2 running Redis OSS 4.0–7.2 or Valkey 7.2–8.1. AWS says these can migrate directly to Valkey 9.0. To begin, create or select an empty ElastiCache Serverless destination and initiate migration through the ElastiCache console or AWS CLI. Supported configurations.

The process has three stages: preparation, data synchronization and cutover. During preparation, ElastiCache supplies a migration endpoint that applications can point to. Once synchronization starts, it continuously replicates source data. Operators choose when writes move to the serverless cache, using manual cutover or automatic cutover once data is synchronized. Cache events record each step and reasons for failures. Source connections use TLS and authentication, with credentials read from AWS Secrets Manager. Migration workflow.

What the downtime claim covers

AWS defines “zero downtime” as zero errors returned to clients during migration, measured using the ElastiCache SLA’s availability methodology. It says applications continue reading and writing through cutover without third-party replication tools. AWS’s definition.

For engineers, that is an error-availability definition, not a latency measurement. A rollout plan should include endpoint configuration, application read/write validation and latency checks rather than treating successful synchronization as the sole acceptance criterion.

Migration fees are separate from cache charges

Migration usage is free for the first 180 days per AWS account, starting when that account first prepares a migration. After that period, active migrations incur per-node-hour charges for the migration nodes that replicate data. The destination cache is billed separately at standard serverless storage and ECPU rates throughout, including during the free migration period. Billing terms.

That account-level clock matters for staged rollouts: teams should budget later migrations against the account’s original preparation date, not assume each workload receives a fresh 180-day allowance.

SOURCES & CONTEXT

See the original announcement for availability and release details.