ElastiCache Serverless (Valkey): how can a client read the effective eviction policy? INFO omits maxmemory_policy and sectioned INFO returns empty

On ElastiCache Serverless for Valkey, there is currently no supported way to read the effective maxmemory-policy at runtime. The configuration parameters for serverless caches are not modifiable and certain introspection commands are restricted or return limited information compared to node-based clusters.

As you've discovered, serverless caches have several limitations:

1. The INFO command returns only a minimal set of fields and does not include maxmemory-policy or other memory-related configuration details
2. Sectioned INFO commands (like INFO memory) return empty responses
3. The CONFIG GET command is restricted and cannot be used to query configuration parameters

The documentation does confirm that serverless caches run with a fixed maxmemory-policy of "volatile-lru" (items with a TTL set are evicted following least-recently-used estimation when memory limits are reached), but this value is not exposed through any runtime API or command.

This is indeed a compatibility difference from node-based ElastiCache clusters, where INFO memory does expose the maxmemory_policy field. For applications that perform capability detection by reading the eviction policy—such as the Symfony cache component you mentioned—this creates a practical problem where the application cannot verify the policy and may refuse to operate.

Your current workaround of overriding the detection in application code is the appropriate approach given the current limitations. You can safely hardcode the assumption that serverless caches use "volatile-lru" as the eviction policy, since this is the fixed configuration for all serverless deployments.

This feedback about exposing maxmemory_policy through INFO commands on serverless caches would be valuable to share through your AWS Support channels, as it represents a real compatibility gap that affects common application frameworks.
Sources
Valkey and Redis OSS configuration and limits - Amazon ElastiCache
Supported and restricted Valkey, Memcached, and Redis OSS commands - Amazon ElastiCache

No, there's no supported runtime command that returns the effective maxmemory-policy on a Serverless cache today. Your findings match what everyone else hits:

• CONFIG GET maxmemory-policy — blocked, as CONFIG is restricted across all of ElastiCache.
• Argless INFO — returns only the minimal handshake fields, no maxmemory_*.
• INFO <section> (e.g. INFO memory) — the section argument isn't honored and comes back empty.

So the runtime genuinely won't tell you. The only authoritative source is the docs, which state Serverless uses a fixed volatile-lru policy — see Valkey and Redis OSS configuration and limits.

For the RedisTagAwareAdapter case specifically: volatile-lru is actually an accepted policy for that adapter — it only rejects allkeys-* and blank/unknown values. Your writes fail purely because detection reads maxmemory_policy from INFO, gets "", and bails before it ever checks whether the policy is acceptable. So overriding the detection is the right call, not a workaround. The cleanest form is to make the client report maxmemory_policy:volatile-lru (the documented value) so the adapter's check passes on the real policy rather than skipping it. Keep it behind a single shim in case the documented default ever changes.

Your ask to expose this on Serverless (matching node-based INFO memory) is a reasonable one, and there are a few good ways to get it to the ElastiCache team:

• Open a Support case under the general guidance / feature request category — this routes feedback straight to the service team.
• If you have an account team or TAM, they can log the feature request against your account so it's tracked.
• The "Provide feedback" link at the bottom of the relevant documentation page (e.g. the config/limits page above) is a quick way to flag the behavior and docs gap.