Azure Cache for Redis to STACKIT Valkey, hands-on

The walk-through at a glance

1. 01

   1. Describe the caches in Terraform

   The demo has a virtual network, a subnet and two azurerm_redis_cache resources: redis-shop-ratelimit (Standard, family C) and redis-shop-sessions (Premium, two shards, two zones, RDB persistence, injected into the subnet).

2. 02

   2. Assess

   Both caches are RECONFIGURE with MEDIUM confidence and a Key Value Store target. The class says the service has a STACKIT counterpart but its configuration is not a copy.

3. 03

   3. Read the draft

   Per cache the engine writes a stackit_valkey_instance and a stackit_valkey_credential, plus a sensitive output for the generated password.

4. 04

   4. Fill the variables

   Plan name, Valkey version and the list of allowed client CIDRs are variables without a default. The CIDR list has a validation that rejects an empty list.

5. 05

   5. Decide what has no counterpart

   Sharding, private-only access and the exact eviction behaviour are architect decisions listed in the architect report.

6. 06

   6. Plan the data

   Caches are usually rebuilt. When they must be carried, the data-movement file lists the unit and leaves the mechanism open.

A Standard cache becomes a Valkey instance

Left: the Standard-tier cache as written. Right: the blocks of the STACKIT Terraform the engine wrote for it, without the review comments that sit above them in the file.

resource "azurerm_redis_cache" "ratelimit" {
  name                = "redis-shop-ratelimit"
  location            = azurerm_resource_group.cache.location
  resource_group_name = azurerm_resource_group.cache.name
  capacity            = 1
  family              = "C"
  sku_name            = "Standard"
  minimum_tls_version = "1.2"
}

resource "stackit_valkey_instance" "ratelimit" {
  project_id = var.project_id
  name       = "redis-shop-ratelimit"
  plan_name  = var.ratelimit_plan_name
  version    = var.ratelimit_version
  parameters = {
    sgw_acl = join(",", var.ratelimit_allowed_cidrs)
  }
}

resource "stackit_valkey_credential" "ratelimit" {
  project_id  = var.project_id
  instance_id = stackit_valkey_instance.ratelimit.instance_id
}

output "ratelimit_valkey_credential_password" {
  description = "The password STACKIT generated for the credential stackit_valkey_credential.ratelimit of azurerm_redis_cache.ratelimit. Sensitive: tofu output hides it from the plan, the state holds it in plain text."
  value       = stackit_valkey_credential.ratelimit.password
  sensitive   = true
}

• Size and family are not carried

  Capacity 1 of family C is not translated into a plan. The draft names plan_name as a variable and says the cache size is yours to choose. The tier tells you the target needs a replica plan, because high availability on STACKIT is the plan.

• The access list replaces the network boundary

  The allowed CIDRs variable has no default. Without a list STACKIT applies its default access list, which covers address ranges of STACKIT customers in general. The draft therefore refuses an empty list.

• The password is generated

  The credential resource returns host, port, user and password. The draft exposes the password only as a sensitive output and creates no secret for it: you read it after the apply and hand it to the clients before the cut-over.

A Premium cache with shards, zones and persistence

From the same run. This cache sets almost everything an architect would ask about. The target draft carries the instance, the access list and the credential, and the table below shows what happens to the rest.

resource "azurerm_redis_cache" "sessions" {
  name                          = "redis-shop-sessions"
  location                      = azurerm_resource_group.cache.location
  resource_group_name           = azurerm_resource_group.cache.name
  capacity                      = 1
  family                        = "P"
  sku_name                      = "Premium"
  non_ssl_port_enabled          = false
  minimum_tls_version           = "1.2"
  public_network_access_enabled = false
  subnet_id                     = azurerm_subnet.cache.id
  shard_count                   = 2
  zones                         = ["1", "2"]

  redis_configuration {
    maxmemory_policy      = "allkeys-lru"
    rdb_backup_enabled    = true
    rdb_backup_frequency  = 60
    rdb_backup_max_snapshot_count = 1
    rdb_storage_connection_string = var.rdb_connection_string
  }
}

resource "stackit_valkey_instance" "sessions" {
  project_id = var.project_id
  name       = "redis-shop-sessions"
  plan_name  = var.sessions_plan_name
  version    = var.sessions_version
  parameters = {
    sgw_acl = join(",", var.sessions_allowed_cidrs)
  }
}

resource "stackit_valkey_credential" "sessions" {
  project_id  = var.project_id
  instance_id = stackit_valkey_instance.sessions.instance_id
}

• Ten open points on one cache

  The architect report leaves 10 critical points of this cache to a person (12 source properties stand behind them: exposure, backup settings, maxmemory policy, shard count, SKU, zones, the backup connection string, location, name and resource group), against 4 points for the Standard cache. That gap is where the review time goes.

• Private-only becomes an access list

  A Valkey instance is not inside the project network. It has its own host name and IPv4 address and is reached from STACKIT address ranges and whatever you add to the access list. The report says to narrow it to the egress addresses of the application and never to open it to all addresses.

• Persistence is not in the block

  The report advises carrying the snapshot frequency into the snapshot parameter, but the drafted block sets only the access list. Add the parameter by hand after you have chosen the frequency.

What each Azure Redis setting becomes

Left column from the demo input, middle column from the STACKIT Key Value Store documentation and the architect report of the run, right column from the run.

Checks before the first client connects

• Plan is a replica plan where the source had replicas

  Single instances are described by STACKIT as not intended for production, and the instance type cannot be changed later.

• Valkey version matches the client libraries

  STACKIT advises choosing the newest version your clients support; even minor version differences can stop some clients from connecting.

• Access list is narrow

  Only the egress addresses of the applications, never 0.0.0.0/0.

• Clients use TLS

  Connection strings start with rediss://, and the host comes from the credential.

• Eviction and expiry behaviour is tested

  The maxmemory policy of the source is an open setting. Test the application's cache behaviour under memory pressure before cut-over.

• Admin commands are tried

  A comment in the draft notes that a test on a STACKIT project found the CONFIG command denied for a service key. If a client or tool relies on it, find out before cut-over.

Moving the data, or not

The run lists both caches as stateful units with the mechanism unknown. It moves nothing.

1. 01

   Rebuild if you can

   Session and rate-limit data is usually short-lived. The mapping reason for both units says cached data is usually rebuilt rather than migrated. Warm the new instance by letting traffic fill it.

2. 02

   Export from Azure

   Azure import and export of RDB snapshots exists for the Premium and Enterprise tiers, not for Basic and Standard. The Standard cache in this demo has no such export; the Premium cache exports to a page blob in a storage account.

3. 03

   Restore into STACKIT

   STACKIT's managed restore targets the same instance and overwrites it. To load a snapshot into another instance you download the backup, which needs an encryption key, and restore it yourself.

4. 04

   Copy keys live

   STACKIT publishes a tutorial that copies keys by running MIGRATE on the source, which pushes them straight to the target, and verifies with INFO KEYSPACE and a sorted key diff; it gives about 50 seconds per GB on average. That path does not work from Azure: Microsoft lists MIGRATE among the commands Azure Cache for Redis disables. For the Premium cache, export an RDB file instead; for the Standard cache, rebuild or copy with a client-side tool.

5. 05

   Cut over

   Stop writers on the source, copy, verify, switch the connection strings, and keep the source until the checks hold. This order is general practice, not a run output.

Decisions the architect owns

• Plan per cache

  Single or replica, vCPU, RAM and disk, from the real dataset size and load. STACKIT's planning page puts RAM at no less than 125 % of the data size and the disk at about three times the data size, and a plan can be scaled up but not down.

• Sharded keyspace

  Fit one primary, or shard in the application across instances.

• Persistence

  Snapshot frequency, and whether a backup restore is a recovery path you rely on.

• Exposure

  Which CIDRs reach the instance, and whether that is acceptable for a cache that was private.

• Timing

  Microsoft has announced a retirement timeline for Azure Cache for Redis and recommends Azure Managed Redis. Whether to move to STACKIT directly is a platform decision, not a cache setting.

Questions about Redis to Valkey

Sources

• Import and export data, Azure Cache for Redis (Microsoft Learn)
• Migrate data to a new instance (STACKIT Key Value Store)
• Backup and restore your instances (STACKIT Key Value Store)
• Plan your instance (STACKIT Key Value Store)
• How to configure Azure Cache for Redis (Microsoft Learn)
• Service plans (STACKIT Key Value Store)