Cloud: OpenSearch, Valkey and RabbitMQ as Managed Services

bin/magento setup:config:set is the command that writes env.php on a single server, and the installer accepts the same options. On the cluster it is not run by the pods, because the file is read-only; it is still worth knowing, for two reasons. The first Job (pocketcoffee-install) runs setup:install in a writable throwaway app/etc and throws the generated file away, so the options of setup:install are what that Job uses; and on a laptop the command shows exactly which nodes Magento writes, so the template can be written to match. The options exist for three of the four services and not for the fourth:

Source: Mage-OS: SearchConfigOptionsList.php; Cache.php; Session.php; Amqp ConfigOptionsList.php

The search row corrects a common assumption. A guide that says "configure the search engine with setup:config:set --search-engine=opensearch`" is wrong for 2.4.9: `SearchConfigOptionsList is registered only by InstallCommand, and the command that writes the values is setup:install, which stores them in core_config_data through Magento\Search\Setup\InstallConfig. The redis and valkey spellings of the cache and session options write the same env.php nodes. The Valkey spelling is new in 2.4.9 and is the one Adobe documents; the redis spelling still works against Valkey (the existing page on caching ran with it), and the session node of env.php is still called redis for Valkey, because the session configuration class reads the paths session/redis/*. Both spellings are shown below, with the one used in the template stated.

The commands for the cache, the sessions and the queue, with the values read from the environment of the pod (the same names as in the secret and the ConfigMap of the cluster page):

Source: Adobe Commerce docs: Valkey for session storage

setup:config:set validates what it is given: the cache and session validators open a connection with the Credis client (the same client the backends use, so a tls:// host is accepted) and the queue validator connects to the broker. A command with a wrong host therefore fails at once, which is useful on a laptop and a trap in a Job that runs before the services exist. The search options of the first installation look like this; the first Job runs it once and discards the generated env.php:

Source: Adobe Commerce docs: Get the metapackage and install with Composer

--key is the encryption key: it is the secret reference MAGENTO_CRYPT_KEY of the secret pocketcoffee/prod/magento, created once for the installation (from the existing installation when you migrate, see Cloud: Migrating from a Single Server) and never typed or generated in a listing. The installer also writes the OpenSearch password into core_config_data in clear text, which is the reason for the next section’s rule: the values of The system node of env.php override it and the Job should not be the final word. Whether the installer is the right tool at all for a cluster, and how the Job is arranged, belongs to the cluster page.

The template reads the environment through one helper, so a missing variable stops PHP with a clear message instead of silently writing an empty host. This is the opening of the template and the part shared by the fragments of the next sections (the complete file also has the database, the key and the other nodes, which are on the cluster page):

Source: Adobe Commerce docs: env.php reference

Adobe’s system requirements for 2.4.9 name OpenSearch 3, and Amazon OpenSearch Service offers 3.5, 3.3 and 3.1 beside the 2.x lines (the engine version is written OpenSearch_3.5). 3.5 is the version of the page. AWS has not announced an end of standard support for 3.1 and later, while 2.19 ends standard support on 2027-11-07; a new domain therefore starts on 3.x. The existing pages of this site run the local test shop on OpenSearch 3.9.0 from the Docker Hub image; the managed service is behind that version, so a feature that appeared between 3.5 and 3.9 is not in the domain. Magento 2.4.9 needs nothing that specific, but test on the version you deploy. Everything about creating and sizing a domain (dedicated master nodes, UltraWarm, Serverless as an alternative) is on OpenSearch and search on AWS and not repeated; this page is about what Magento needs from it.

A Magento domain is a modest one. The data is a copy of the catalog, rebuilt by an indexer, so the size is set by the catalog (products times store views times attributes that are searchable or filterable), not by traffic that writes. The decisions that matter:

Magento’s OpenSearch client sends HTTP basic authentication, built from the options opensearch_username and opensearch_password, and does not sign requests with AWS Signature Version 4. AWS documents the consequence: if the master user is an IAM principal, every request must be signed; if it is a user of the internal user database, "you can use HTTP basic authentication (as well as IAM credentials)". Two settings follow.

The master user has all rights in the cluster, which is more than Magento needs. A better design creates a second internal user for Magento, maps it to a role that is limited to the index pattern pocketcoffee_* and to the cluster actions Magento uses, and keeps the master user for operators. What exactly that role needs (creating and deleting indexes, aliases, templates, bulk writes, search) was not derived from the Magento source and Adobe does not document it; build the role in OpenSearch Dashboards by trial against a staging domain, watching the 403 errors of the Magento log, before using it in production. The page keeps the master user in the examples because it is the one that works without that exercise.

Source: Amazon OpenSearch Service: Fine-grained access control

Two details of the client decide whether a managed domain works, and neither is in Adobe’s text. In Magento\OpenSearch\Model\SearchClient (the class that builds the connection), the configured host name is split: any http:// or https:// prefix is removed, the scheme found in it is kept and, if there was none, http is used; then the client builds <scheme>://<user>:<password>@<host>:<port>. The consequences are:

Source: Mage-OS: SearchClient.php

The Admin fields live under catalog/search: engine, opensearch_server_hostname, opensearch_server_port, opensearch_index_prefix, opensearch_enable_auth, opensearch_username, opensearch_password, opensearch_server_timeout (and opensearch_minimum_should_match, which the shop does not need). In the source the password field is a plain text field without a backend model, so what it saves is clear text in core_config_data, and Magento_OpenSearch lists the hostname, the user name and the password in the sensitive configuration of Magento\Config\Model\Config\TypePool. The template fixes all of them:

Source: Adobe Commerce docs: Configure search engine

Because the node is in env.php, the values are the same on every pod, they follow the environment (staging has its own domain and prefix) and nothing about the domain is in the image. Do not rely on app:config:dump for these paths: config.php is committed, and a dump taken on a developer machine would put its local localhost there. Check the effective value on a pod (bin/magento config:show catalog/search/opensearch_server_hostname) after the first deployment, and look in core_config_data for stale rows with select path, value from core_config_data where path like 'catalog/search/%'; the node wins over them, and the old rows are a reason for confusion when someone changes the database value in the Admin and nothing happens.

An index is named <prefix>_product_<store view id>_v<version>. The prefix is the namespace of the installation: two Magento installations that share a domain must have different prefixes or one deletes the other’s indexes when it reindexes. The prefix of the example is pocketcoffee; staging uses pocketcoffee_stg on its own domain, and a copy of the production database restored for a test must not reuse the production prefix against the production domain, because the first full reindex of the test would replace the indexes the shop is reading. Changing the prefix of a running shop leaves the storefront without an index until the indexer has rebuilt the new one, so do it as a planned change (First start, verification and what to expect) and not in the middle of a deployment. Adobe’s text on the field says the same: use a unique prefix per installation if one instance serves several.

The domain, its security group and the master password, with the three security prerequisites of fine-grained access control spelled out (encrypt_at_rest, node_to_node_encryption, enforce_https). The VPC, the private subnets, the node security group and the KMS key are those of the root module of the cluster page and are variables here, so the file validates by itself:

Source: AWS provider: aws_opensearch_domain

The password is generated by the random provider and therefore lands in the OpenTofu state, which is why the state bucket of the cluster page is encrypted and restricted; the value is copied into the JSON key opensearch_password of the secret pocketcoffee/prod/magento by the same configuration (the whole secret is assembled on the cluster page, with the keys of the three services here and the others). Rotating it is a change of the master_user_password followed by a rolling restart of the pods, because the value is read from the environment when a pod starts. The security group of the pods is a source, never a CIDR, so that the rule follows the nodes.

Three commands, run from a pod of the web Deployment (kubectl exec), prove the chain: the cluster health, the indexes of the prefix (which exist only after the first reindex), and then the Magento side. The script also covers Valkey and RabbitMQ, which are explained in the next sections:

Source: OpenSearch documentation: CAT indices API

The health of a fresh domain is green with three nodes and replicas of 1, and yellow with a single node (replicas cannot be placed). After the first indexer:reindex catalogsearch_fulltext, the second command lists one index per store view with the prefix. A reindex that fails with a 403 is a role problem (the mapping of the user), one that fails with a connection error is the scheme or the security group, and one that fails with a 401 is the password. The image used for the pods needs curl for these checks, and valkey-cli is only needed for the diagnostic pod, not in the shop image.

Adobe’s advice, in its Valkey page, is to use "a dedicated instance for each session, Commerce cache, and FPC", to give the cache instance enough memory to store the whole cache and no persistence ("the Commerce cache can be restored"), and to enable persistence for sessions. On this stack the full page cache is Varnish, so there are two groups: pocketcoffee-prod-cache and pocketcoffee-prod-session. Both are replication groups with cluster mode disabled (one primary and a replica, the primary endpoint), Multi-AZ with automatic failover, encryption at rest, TLS in transit and an AUTH token. Cluster mode is not chosen: Adobe’s text describes a single Valkey server per purpose (and Sentinel for failover), and Magento’s key layout (tag sets that must live in one place) has no documented cluster mode support. The existing page on Caching, Indexing and Performance lists the databases of one server (0 for the cache, 1 for the built-in full page cache, 2 for sessions); with two groups the cache is database 0 of its group and the sessions are database 0 of theirs, so that one flush can never touch the other.

The eviction policy of the cache group is a decision that Adobe’s documentation does not take for you: its Valkey page does not mention maxmemory-policy, and the ElastiCache default is volatile-lru. The Magento Redis backend (Cm_Cache_Backend_Redis) writes its cache entries with an expiry (capped at 30 days) and keeps the tag sets as keys without one, so volatile-lru evicts entries but never the tag sets; allkeys-lru could also evict a tag set and leave entries that no longer clean by tag, which is the reason the example does not use it. That is a reading of the backend code, not an Adobe recommendation, so treat the policy as something to confirm in staging: fill the group, watch the Evictions metric, and run cache:clean for a tag to see that it still cleans. The sessions are the opposite case: an evicted session logs a customer out and empties a cart in progress, so noeviction refuses new writes instead and an alarm on DatabaseMemoryUsagePercentage is part of operating the group (see Cloud: Autoscaling, Observability, Backups and Security).

Source: Adobe Commerce docs: Install and set up Valkey

ElastiCache offers in-transit encryption (TLS) and an AUTH token for replication groups, and the token can only be enabled together with TLS. The token must be 16 to 128 printable characters, and the only non-alphanumeric characters it allows are !, &, #, $, ^, <, > and -; the example uses 48 letters and digits. AWS notes that AUTH is superseded by role-based access control (RBAC) and that Secrets Manager can rotate RBAC passwords; Magento’s cache and session clients send a password only, which is what the default user with a token accepts, so the example uses AUTH and keeps RBAC out of the picture. If your security policy requires per-application users, check first that your version of the clients can send a user name; the constructor of Credis 1.17.0, the version read here, accepts one, but the Magento options do not expose it.

Neither Adobe’s Valkey pages nor the options of setup:config:set mention TLS, and the Adobe env.php reference shows plain server and host values. In the code the connection is made by the Credis client (colinmollenhour/credis), used by both Magento’s cache backend and its session handler and by the connection validator of the CLI. Credis reads a scheme in the host value: tcp://, tls://, ssl://, tlsv1.2://, or unix://, with an optional port after the host. So TLS is switched on with tls:// in front of the host, in the server option of the cache and in the host option of the session, with the port in its own option:

Source: Credis: Client.php

When PHP has the redis extension, Credis hands the scheme and host to it; when it does not, Credis opens the stream itself with stream_socket_client and the default TLS context of PHP, which verifies the certificate against the system store. The certificate of an ElastiCache endpoint is issued by Amazon, so the verification passes with a normal ca-certificates bundle. No connection to a real group was made and the two code paths (extension and stream) were not compared; test both if the image has the extension, as the failure is a connect error in the log and /health_check.php returns 500 (see What breaks when a service is unreachable). Adobe documents none of this, so the page states it as read from the code and not as an Adobe-supported setting.

Source: Adobe Commerce docs: env.php reference

The backend value is redis, the identifier the existing page ran against Valkey 9.1.3 on the test shop; 2.4.9 also has the identifier valkey (Magento\Framework\Cache\Backend\Valkey is a subclass of the Redis backend that only changes the type identifier), which is what --cache-backend=valkey writes. Either works; use the same one in every environment. id_prefix stays explicit so that a build that never touches Valkey and a pod that does agree on the keys. igbinary needs the PHP extension in the image (the page on the image says how to build it). The existing page on caching ran its test shop without the extension and the paths it exercised still worked, so the serializer is not checked on every path; install the extension and keep igbinary, or write 'serializer' => 'php' in the template, and do not leave the value without the extension. The page_cache frontend is deliberately absent: with Varnish selected as the full page cache the built-in frontend is unused, and pub/health_check.php walks every defined frontend, so an unused frontend would only add a failure point (see What breaks when a service is unreachable). Do not define it unless you switch the full page cache to the built-in one.

Magento’s built-in full page cache can live in Valkey (database 1 of the single-server layout) and is a PHP script that reads it, which is why Adobe recommends Varnish for production. On the cluster it is Varnish, a StatefulSet of memory-only caches in front of the web pods, with Magento purging them over HTTP; that is a different state with different rules and is the whole of Cloud: Varnish and Full Page Cache on Kubernetes. Switching system/full_page_cache/caching_application to Varnish does not need a Valkey group of its own, and the cache group of this page is not sized for a built-in full page cache.

Source: Adobe Commerce docs: Valkey for session storage

The values are Adobe’s defaults for every option except the host, the port, the password and the database, so a reader can compare them with the table of that page. The session handler locks a session while a request uses it, so that two concurrent requests of one browser do not overwrite each other: max_concurrency is how many processes may wait for one lock, break_after_frontend and break_after_adminhtml are the seconds after which a lock is broken, and disable_locking turns the mechanism off at the price of lost updates. With several pods the lock is held in Valkey, so it works across pods, which is the point of the move off the file system. Do not set disable_locking to speed up the Admin; the Admin uses long requests (imports, grids) and a broken lock is worse than a wait. A failover of the replication group moves the primary endpoint to the promoted replica in a minute or so; connections break, requests fail and the next ones succeed, and the sessions that were not yet replicated are lost, which is the reason the group has a replica and a daily snapshot and not a guarantee. persistent_identifier stays empty because persistent connections interact badly with a DNS change on failover; This was not measured, so test a failover in staging (aws elasticache test-failover) with a loop of requests running.

Sessions are not a rolling-update problem: a new pod reads the same group with the same token, so a customer keeps the session across releases. That holds only as long as the crypt/key is the same on every pod and every release, because the session data of the Admin and the form keys depend on it (see Cloud: Releases and Zero-Downtime Deployments).

Source: AWS provider: aws_elasticache_replication_group

The node type is an example; the cache group is sized by the rule of the table above and the node type of the session group by its sessions. engine_version = "9.0" pins the major and minor and lets ElastiCache choose the patch; use 9.1 if you want the newer minor, The primary endpoint prints as master.<group>.<id>.euw1.cache.amazonaws.com; with cluster mode disabled it is the name to put in the ConfigMap, and the replicas are for failover, not for reads, because Magento’s cache and session options have no read-replica setting in the options above.

The token changes in two steps so that the pods never lose access (the ROTATE and SET strategies of modify-replication-group, available for Valkey 7.2 and later with TLS): ROTATE adds the new token and keeps the old one, so the group accepts two; the secret is updated and the pods are restarted (the token is read from the environment at start, so kubectl rollout restart on the web, consumer and cron workloads, and the next CronJob run picks it up); SET then removes the old token. Do not run SET before every pod has restarted. The ExternalSecret refresh updates the Kubernetes Secret, but an environment variable of a running container does not change until the container restarts.

Source: Amazon ElastiCache: Authenticating with the Valkey and Redis OSS AUTH command

Amazon MQ for RabbitMQ recommends 4.3, supports 4.3 and 4.2 on the mq.m7g instance family only, and 3.13 on mq.t3, mq.m5 and mq.m7g; Adobe’s 2.4.9 table lists RabbitMQ 4.3. A new broker needs only the major and minor version ("RabbitMQ 4.3"). Two facts of the service shape how Magento uses it.

Amazon MQ for RabbitMQ does not support streams ("creating a stream will result in data loss"), which Magento does not use, and it does not vend per-queue metrics to CloudWatch for RabbitMQ 4 (only broker-level metrics); the queue length that KEDA scales on is read from the RabbitMQ management API, as in Cloud: Cron, Queue Consumers and Indexers.

Source: Amazon MQ: RabbitMQ 4

Source: Adobe Commerce developer docs: Message queues

Four details come from the code of Magento\Framework\Amqp.

The queues and the exchange are not created by the application at run time. Magento\Amqp\Setup\Recurring runs the topology installer, so setup:install and setup:upgrade declare the exchange magento and every queue and binding that the XML files of the installed modules describe. In the cluster that is the migrate Job, which also means the broker must be reachable from the Job and the broker user needs permission to declare, which the user created with the broker has. A module added later is not declared until the next setup:upgrade, so a new consumer in a release works from the release’s migrate Job and not before.

default_connection is amqp for the modules whose XML does not name a connection; a module that names db explicitly keeps using MySQL, as the existing page on queues explains. cron_consumers_runner has cron_run false so that the consumers are not started by cron inside the cron Job, because on the cluster they are Deployments of their own (the reason is in Cloud: Cron, Queue Consumers and Indexers).

Source: Mage-OS: Amqp Config.php; Connection/Factory.php

Source: AWS provider: aws_mq_broker

The broker is created in private subnets (publicly_accessible = false), so it has no address on the internet. The subnets of a cluster deployment are the three private subnets; check the current rule for the number of subnets on the pre-requisites page of Amazon MQ, because a single-instance broker takes one. auto_minor_version_upgrade lets AWS apply minor upgrades in the maintenance window; leave it on for a managed service and read the notice AWS sends before a version reaches end of support (AWS announces the end of support of a version 90 days ahead). The password is in the OpenTofu state and in the secret key amqp_password; the user created here is the application’s user, and the same password lets KEDA call the management API, so the RabbitMQ scaler of the consumer page uses a TriggerAuthentication that reads it from the secret.