Create it
- Console
- CLI and API
- Coding agent
- Open the environment, then New service › Blueprint.
- Find Amazon ElastiCache for Redis in the catalog and pick the major version.
- Fill in the variables. Required ones are marked; the others use their defaults.
- Create the service, and deploy it now or later.
Variables and outputs
Generated fromqbm.yml at AWS/redis/7/1.1.2, the manifest the Console form is built from.
All 17 variables
All 17 variables
All 18 outputs
All 18 outputs
Reference
From the Blueprint’s README. Creates an AWS ElastiCache for Redis 7 replication group with configurable node type, topology, backups, maintenance window, and network settings. Traffic is encrypted in transit and protected by an auth token, and data is encrypted at rest. The replication group id isredis_name lowercased (AWS requirement). Applications connect over TLS as the built-in default user with the auth token as password: rediss://default:<token>@<host>:6379/0, published as the redis_url output.
Variables
Required
Available node types: every ElastiCache node type Qovery offers for native managed Redis (the
cache.t3, t4g, m4–m7g, r4–r7g and c7gn families; r6gd is left out because it needs data tiering). The full list is in qbm.yml.
Credentials
In the Console, leaving the field blank omits it. Through the API or Terraform, omit the variable rather than sending an empty string: the platform rejects an empty variable value.
Instance & topology
instances_number = 1 creates a single node with no replica. Above 1, the group switches to cluster mode: N shards, one replica each (so 2N nodes), with automatic failover and Multi-AZ enabled because AWS requires both there, and the default.redis7.cluster.on parameter group instead of default.redis7. Clients then need a cluster-aware Redis library and the redis_configuration_endpoint_address output.
Pick the topology at creation. ElastiCache cannot turn cluster mode on for an existing group, so raising instances_number from 1 fails at apply rather than resharding — deploy a new service instead. Changing it between two cluster-mode values (2 → 4) does reshard in place.
Security
Encryption in transit is always on and is not a variable: ElastiCache only accepts an auth token on a TLS-enabled group, so a group without TLS would also be a group reachable with no password by anything inside the cluster security group. Clients must connect with
rediss://.
Network
By default the group is attached to the Qovery cluster network: the ElastiCache subnet group created at cluster bootstrap (named
elasticache-<cluster vpc id>) and the cluster workers security group, so pods in the cluster can reach Redis out of the box. On clusters deployed into an existing VPC (user-provided network), the ClusterId tag lookup may not resolve and the bootstrap subnet group may not exist; set both variables explicitly in that case.
Maintenance & upgrades
The window is lowercased before it reaches AWS, which is how AWS stores and reports it, so a changed window applies without leaving a diff behind.
Backups
With
skip_final_snapshot = false, destroying the service leaves a snapshot named <replication group id>-final-snap-<creation timestamp> behind, which keeps costing storage until deleted. The timestamp is stamped once at creation, so it is unique per group — successive create/destroy cycles of the same name do not collide on an existing snapshot id — while staying stable across plans. snapshot_name is read at creation only: pointing it at a different snapshot later does nothing.
Outputs
Lifecycle ignore_changes
log_delivery_configuration,notification_topic_arn,user_group_ids— configured outside the blueprint.transit_encryption_mode— AWS pickspreferredvsrequiredand reports its own value back.tags— preserves tags set on the group outside the blueprint.
engine_version is deliberately not ignored, so a version change applies. ElastiCache only upgrades forward.
Auth token
auth_token and auth_token_update_strategy are deliberately not ignored. An adopted group’s state holds no token, and the AWS provider sends the token from state on any update of the group: ignored, it would reach AWS empty and the apply would fail with Invalid AUTH token provided.
So the first apply after an adoption sends redis_password with ROTATE, immediately: the provider forces ApplyImmediately on that call, whatever apply_changes_now says. Nothing here checks redis_password against the live token. Set it to the live one: a stale value is added as a second valid token. Rehearsed once (2026-11-03, a 7.0 replication group with the live token): AWS accepted the call and the token kept working. Not run on 7.1.
Changing redis_password later rotates through Terraform: ROTATE adds the new token and keeps the old one valid. Revoke the old one with aws elasticache modify-replication-group --replication-group-id <id> --auth-token <new> --auth-token-update-strategy SET --apply-immediately.
Before moving a service created on an earlier version to this one, make redis_password equal the group’s live token. Earlier versions ignored auth_token, so a token rotated out-of-band left the old one in state, and the first apply on this version sends redis_password with ROTATE.