User guide

Cloud Certainty Memora is a web console for Amazon ElastiCache (Valkey, Redis OSS and Memcached) that runs in your organisation's own AWS account. You see every cache across the AWS accounts and Regions your administrator connected, with their metrics, cost and findings; you operate them; and for Valkey and Redis OSS you browse keys, run commands, analyse memory and watch the server, with a record of who did what.

Open the portal URL your administrator gave you and sign in with your company account. You see the caches an administrator granted you; what you may do with each depends on your permissions:

Permissions are granted per AWS account (connection), Region and cache id pattern, so you may be able to change data in orders-* and only view billing-*. On the Business plan, an administrator can also limit your read and write to some keys, for example cart:* (see Key patterns). Buttons for actions you can't take are greyed out, and their tooltip says why.

Some features depend on your organisation's plan (Starter, Team, Business or Enterprise). A feature the plan doesn't include shows a plan badge, for example Team plan or Business plan. This guide notes the plan next to each such feature.

The top bar has Fleet, Scripts, History, Bulk jobs and, for administrators, Administration, plus Go to… (the command palette) and Sign out. The footer shows the version and your plan, and has a theme switch (System, Light, Dark).

#Signing in

Memora uses your organisation's sign-in: AWS IAM Identity Center, another SAML or OIDC identity provider, or Memora's own user pool with multi-factor authentication. Your administrator chose one when installing Memora (Identity providers).

The first time you sign in you may see no caches at all: nobody sees anything until an administrator gives them a grant. Ask your Memora administrator for access, naming the AWS account, the Region and the caches you need, and whether you need to read data, change data or operate the caches.

#Fleet

Fleet lists every cache you may view, in every connection and Region you have a grant in: replication groups (Valkey or Redis OSS, with or without cluster mode), serverless caches and clusters (Memcached, or a single-node Redis OSS cluster). For each cache:

• the engine and version, and the kind;
• the status and the size (nodes and node type, or serverless);
• Memory (peak use in the period), CPU (average engine CPU, or host CPU where there is none), Hit rate and Ops/s;
• Monthly: the estimated monthly cost at on-demand list prices;
• Findings, counted by severity, and a trend of operations or memory.

The tiles at the top add up Caches, Nodes, Estimated monthly cost, Potential savings and High findings. Choose the metrics period (1 hour, 24 hours, 7 days or 30 days), search by name or description, filter by connection and Region, engine, kind, status and findings, and sort by any column. The link in your browser keeps the filters, so you can share a view with a colleague, who sees only what their own grants allow. Figures come from Amazon CloudWatch; Memora keeps cache lists for 2 minutes and metrics for 5, shows how old they are, and Refresh reads them again.

Costs are estimates: reserved nodes, savings plans and data transfer are not counted. Serverless caches are priced with the prices your administrator set.

Screenshot

#Findings

Select Findings (or the Potential savings tile) to see every finding across the filtered fleet, grouped by severity (High, Medium, Low and Information), with the monthly saving each one adds up to. Check narrows the list to one kind of finding, and Download CSV exports it. Findings come from each cache's settings and 14 days of CloudWatch metrics:

• Security: no encryption in transit, no encryption at rest, no authentication (no AUTH token and no user group).
• Cost and support: Redis OSS 4 and 5 on paid Extended Support (with the surcharge), Redis OSS 6 reaching the end of standard support, old Memcached versions, the saving of the same cache on Valkey, previous-generation nodes and their Graviton equivalent, and nodes larger than they need to be (underused for 14 days, with the next size down).
• Resilience: no automatic failover, Multi-AZ off, no automatic backups.
• Health: memory pressure or evictions, swapping, close to the connection limit, throttled commands on serverless caches, service updates waiting.

Screenshot

#Creating a cache

With manage on a connection with Full access, Create cache opens Create a cache: choose Node-based (a replication group with a node type, shards and replicas per shard) or Serverless (with optional maximum data stored and ECPUs per second), the connection and Region, a name, the engine (Valkey (recommended) or Redis OSS) and version, the network (subnet group or subnets, and security groups), encryption in transit, an optional user group, backup retention and tags. ElastiCache takes a few minutes; the cache's page shows the progress.

#Cache page

Open a cache from the fleet, a finding or the command palette. The header shows the engine and version, the kind, the status, the estimated monthly cost, the endpoints (with a copy button) and Open in AWS console. While ElastiCache is changing the cache, the page checks its status every 10 seconds.

Browser, Workbench, Analysis and Monitor work with Valkey and Redis OSS. For Memcached they are greyed out: Memora shows its configuration, metrics, events and findings.

Screenshot

#Overview

• Last 24 hours: the key numbers of the cache with sparklines; Every metric opens the Metrics tab.
• Quick actions: Scale (or Change limits for serverless), Upgrade to Valkey for Redis OSS (or Change engine version), Backup and maintenance settings and Take a backup.
• Findings for this cache, with what fixing them could save.
• Cost: the estimate, the price per node and how it was worked out.
• Data: how Memora signs in (IAM authentication, Secrets Manager or no authentication) and which connector reaches the cache, or what is missing.
• Security: encryption in transit and at rest, authentication, user groups, VPC, subnet group and security groups.
• Topology: shards and nodes with their role (primary or replica), Availability Zone, status and endpoint. Serverless caches show their limits instead.

#Browser

The key browser lists keys with SCAN, never KEYS, so it is safe on a production cache. In cluster mode it scans every primary.

• Pattern: a Redis glob such as cart:* (* any run, ? one character, [abc] one of); press Enter or Scan. Text without wildcards finds keys containing it. Filter by type with All types.
• List or Tree: the tree groups keys by prefix, split by the Delimiter (: by default), with Expand all and Collapse all.
• Per scan sets how many keys each SCAN step asks for (your administrator sets the default). Load more continues the scan; the list keeps up to a fixed number of keys, so narrow the pattern to see others.
• Each key shows its type, TTL and size (MEMORY USAGE; not reported on serverless caches).

Choose a key to see its value. Edit TTL sets or removes the expiry (EXPIRE, Remove expiry), Rename renames it, Delete deletes it, Open in workbench opens the command that reads it, and Bulk job for keys like this starts a bulk job for its prefix.

Add key creates a string, hash, list, set, sorted set, stream or JSON key, with an optional TTL. Values longer than the limit your administrator set (1 MiB by default) are cut and shown as read only; use GETRANGE in the workbench to read the rest. Binary values are shown with \x escapes. Every change in the browser is recorded in your command history.

Screenshot

#Workbench

Type commands in redis-cli syntax, one per line (double and single quotes, \xHH escapes; lines starting with # or // are comments). The editor completes commands, subcommands and options for every Valkey, Redis OSS, JSON and Bloom command Memora knows, and the help panel shows the syntax of the command under the cursor, its class (Read, Write, Admin, Flush or Blocked) and how Memora runs it on this cache.

• Run all (Ctrl or Cmd + Enter) or Run line or selection (Shift + Enter). Up to 100 commands and 512 KiB go in one request; they run one after another on one connection, so a MULTI ... EXEC pair runs as a transaction.
• Run on (cluster mode disabled with replicas): run on the Primary or a replica. Replicas refuse writes.
• In cluster mode, commands such as DBSIZE, INFO or SLOWLOG run on every primary, and the reply shows each node.
• Results appear newest first, as Text, Table or JSON, with the time each took. They stay until you reload the page; Clear results removes them.
• Save as script saves the commands as a script; Command history opens your history for this cache.

Memora checks every command before it is sent: a command you may not run, or one that never runs through Memora, refuses the whole request with the reason (see What is refused, and why). KEYS, FLUSHDB and FLUSHALL ask you to type the cache id first.

Screenshot

#Analysis

Analyse memory samples keys with SCAN and measures each one with MEMORY USAGE, TYPE and PTTL, in batches; it never runs KEYS. Choose the Sample size (keys) (up to your plan's limit: 10,000 on Starter, 50,000 on Team, 100,000 on Business and 250,000 on Enterprise), the Delimiter for prefixes, an optional Key pattern and the Prefix depth.

A report shows the Total keys, the Estimated memory, the sampled bytes, keys without a TTL, keys expiring within an hour and the duration, then:

• Recommendations, with links to browse a prefix, open a key or set a TTL with a bulk expire job;
• Memory by type;
• TTL distribution;
• Prefixes: a tree of key prefixes with their share of memory, each linking to the browser;
• Biggest keys.

Analyses are stored for your plan's history days; open earlier ones, or delete your own, under Analyses. On serverless caches, which don't allow MEMORY USAGE, sizes are estimated from each value's length and the report says so. If your grants limit you to some keys, the analysis covers only those keys and only you and administrators can see it. An analysis stores key names and sizes, never values.

Screenshot

#Monitor

• Server: INFO from every node, with the engine, uptime, used memory against maxmemory, fragmentation, clients, operations per second, hit ratio, evicted keys and the keyspace per database, and Every field with a filter. Every 10 s refreshes it on its own.
• Slow log: commands slower than the parameter group's slowlog-log-slower-than, from every primary, newest first, with the time by command. Reset (operate) clears it on every primary.
• Clients: CLIENT LIST from every node, with a filter. With operate, end a client's connection; Memora's own connections can't be ended from here, and the action is audited.
• Pub/Sub: Listen to channels subscribes to channels and patterns for a window of 1 to 10 seconds and shows what was published in it; Keep listening repeats windows. Messages published between two windows are missed: this is a sampling tool, not a reliable consumer. With write, Publish a message runs PUBLISH. Pub/Sub needs access to every key, because channels are not keys.

Serverless caches have no slow log or client list, and no pattern subscriptions; the tab says so.

Screenshot

#Metrics

Every Amazon CloudWatch metric of the engine, grouped (CPU, memory, cache efficiency, latency, connections, throughput, network, and serverless usage in ECPUs and throttled commands), for 1 hour, 24 hours, 7 days or 30 days. Node shows one node instead of the primaries of the whole cache. A new cache starts reporting metrics after a few minutes.

#Backups

Backups are point-in-time copies of the cache's data, kept by ElastiCache in your account. The tab shows the automatic backup retention and window, and every backup with its type (Automatic or Manual), status, size, node type and engine.

• Take backup (operate): for a cluster mode disabled cache, ElastiCache backs up the primary; the cache stays available.
• Copy (operate): a copy with a new name. Copy an automatic backup to keep it beyond the retention period.
• Restore (manage, on the new cache id too): Restore to a new cache creates a new cache from the backup with this cache's subnet group, security groups, parameter group, encryption, user groups and engine; you can choose another node type. Restoring always creates a new cache.
• Delete (manage): manual backups only; ElastiCache removes automatic ones itself.

Memcached keeps data in memory only, so ElastiCache takes no backups of it.

#Configuration

Each change asks for confirmation and says what ElastiCache will do, and each is written to the audit log. Serverless caches have no parameters, nodes or service updates to manage; the tab says so.

Screenshot

#Events

ElastiCache events for the cache and its nodes, newest first, for the period you choose (ElastiCache keeps events for 14 days).

#Data access

How Memora reaches this cache's data (see Data access in the admin guide): Current state with Test connection, which shows the engine, the user Memora signed in as and the nodes it reached; IAM data access with Set up IAM data access; and Change data access. Setting it up needs manage; IAM set-up also needs a connection with Full access.

#Key patterns

Business plan and above. An administrator can limit your read and write on a cache to keys that match patterns, such as cart:* and session:*. Then:

• the key browser lists only matching keys, and memory analyses and bulk jobs touch only matching keys;
• a command that names another key is refused before it reaches the cache;
• commands that can reach keys they don't name are refused: EVAL, EVALSHA, FCALL and their read-only forms, KEYS, SCAN typed in the workbench (use the key browser), RANDOMKEY, FLUSHDB, FLUSHALL, SWAPDB, MOVE, COPY with DB, SORT with BY or GET, and every Pub/Sub command.

view, operate and manage are not limited by key patterns.

#Scripts

Scripts are saved lists of commands to run in a cache's workbench. My scripts lists yours; Shared lists the scripts others shared (Team and above). Search by name, description, tag or cache, and filter by folder or tag.

New script (or Save as script in the workbench) saves a name, a description, a folder, tags, the Visibility (Private, or shared with everyone signed in on Team and above) and an optional Target cache. Every save is a new version: your plan keeps the latest 5 (Starter), 25 (Team), 50 (Business) or 100 (Enterprise), and Compare with editor shows what changed. Run in workbench opens the target cache's workbench with the script loaded, or asks which cache.

Running a script needs the same permissions as typing its commands: a shared script gives you nothing. Only the owner and administrators can change or delete a script; if two people save at once, the second is told to reload. Your plan limits how many scripts each person keeps: 50 on Starter, 500 on Team, 2,000 on Business, unlimited on Enterprise.

#History

History (Command history) lists the commands you ran through Memora: in the workbench, from scripts, writes in the key browser and Pub/Sub publishes. Each record shows the time, the cache, the source, the commands with their class and up to three keys each, the result and how long it took. Run again opens the workbench with the commands, Export CSV downloads the page, and a cache's workbench links to its own history. Administrators can switch to Everyone and choose a day.

Command values are not recorded unless an administrator turned on recording them; the page says which. Records are kept for your plan's history days: 30 on Starter, 90 on Team, 365 on Business and 730 on Enterprise.

#Bulk jobs

Team and above, with write. A bulk job deletes, expires or persists every key that matches a pattern, in batches at a rate you choose, so a production cache stays healthy:

Start one with New bulk job on Bulk jobs, from a key in the browser (Bulk job for keys like this) or from an analysis recommendation. Choose the cache, the action, the Key pattern, an optional Key type, the Rate (keys per second) and Stop after (keys) (at most 100,000 on Team, 1,000,000 on Business, unlimited on Enterprise). Preview counts the matches in the first 10,000 keys and shows a sample, without changing anything. Then type the cache id and start the job.

Memora's own Step Functions workflow in your organisation's account carries out the job, as you. Before every batch it checks your permission and key patterns again: if your grant is removed, the job stops. The job page shows the progress, the keys scanned, matched, applied and failed, the rate, the parameters and the Step Functions execution. Cancel the job stops it after the current batch; keys already changed stay changed. Bulk jobs are kept for your plan's history days.

Screenshot

#Command palette

Press Ctrl+K (Cmd+K on a Mac), or Go to… in the top bar, to jump to a cache in any account and Region, a recent cache, key, script or bulk job, a script, or a page (for administrators, the Administration pages too). Type a few letters, move with the arrow keys and press Enter.

#What is refused, and why

Memora classifies every command before it is sent, and the connector checks it again in the cache's VPC:

• Never run through Memora: commands that block or hold a connection (BLPOP, BRPOP, BLMOVE, BZPOPMIN, XREAD ... BLOCK, WAIT, SUBSCRIBE and friends outside Pub/Sub sampling, MONITOR, SYNC, PSYNC), commands ElastiCache restricts on every cache (BGSAVE, SAVE, BGREWRITEAOF, CONFIG, DEBUG, MIGRATE, REPLICAOF, SLAVEOF, SHUTDOWN, CLUSTER slot and node changes, ACL SETUSER, ACL DELUSER, ACL LOAD, ACL SAVE, MODULE) and connection state (AUTH, HELLO, SELECT, CLIENT SETNAME, RESET, QUIT). The workbench names the reason.
• KEYS blocks the engine while it walks every key, so it needs you to type the cache id. The key browser scans without blocking.
• FLUSHDB and FLUSHALL are off unless an administrator allows them. Even then they need write, access to every key, and the cache id typed.
• Admin commands that change how the server runs (SLOWLOG RESET, CLIENT KILL, SCRIPT FLUSH, SCRIPT KILL, FUNCTION DELETE, FUNCTION FLUSH) need operate.
• Unknown commands are treated as writes and need write.
• Serverless caches refuse some commands, and Memora refuses them first, naming the restriction: CLIENT subcommands other than CLIENT SETNAME and CLIENT GETNAME, KEYS, MONITOR, SLOWLOG, COMMANDLOG, LATENCY, MEMORY, OBJECT, FUNCTION, FCALL, FCALL_RO, PSUBSCRIBE, PUNSUBSCRIBE, SCRIPT KILL, LASTSAVE, MOVE, SWAPDB, WAIT and ACL LOG. Multi-key commands, transactions and scripts must stay in one hash slot there.
• Limits: at most 100 commands and 512 KiB per request; values are cut at the size your administrator set, and responses at 5 MB.