Amazon ElastiCache and MemoryDB Security: Users, IAM auth, TLS and network controls

A managed Valkey or Redis OSS cache answers any client that reaches its port and passes its authentication check, so the user model, TLS setting and subnet placement you choose decide who can read session tokens, cached records and queues held in memory. Amazon ElastiCache and Amazon MemoryDB run the engines for you, while users, access strings, IAM authentication, encryption and network placement remain customer-side settings. This guide covers role-based access control (RBAC) users and user groups in ElastiCache, users and ACLs in MemoryDB, IAM authentication, legacy AUTH tokens, encryption in transit and at rest, logging and a hardening baseline. Both services are covered in parallel, with each service's own setting names. It is for platform engineers, application developers and cloud security reviewers. Engine-level hardening for self-managed deployments is in the Redis Security Guide; this page stays with the managed service settings.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation for Amazon ElastiCache and Amazon MemoryDB as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Replace the default user. In ElastiCache, create a new user named default that is off or has a strong password and put it in the user group; in MemoryDB, keep clusters off the open-access ACL.
• TLS is the foundation for authentication. ElastiCache needs in-transit encryption before a user group or AUTH token can be attached, and MemoryDB clusters without TLS can only use the open-access ACL.
• Use IAM authentication for AWS workloads. On Valkey 7.2 or later and Redis OSS 7.0 or later, clients connect with 15-minute SigV4 tokens authorised by elasticache:Connect or memorydb:Connect, so no cache password is stored.
• Scope every user with an access string. Key patterns and command categories such as on ~app::* -@all +@read keep each application to its own keys and commands.
• Choose at-rest encryption at creation. For node-based ElastiCache replication groups it is set when the group is created; serverless caches and durability-enabled clusters always encrypt at rest.

How identity and access work in ElastiCache and MemoryDB

Access has two layers. The control plane (elasticache: and memorydb: API actions such as CreateUser, ModifyUser, ModifyReplicationGroup and UpdateCluster) is governed by IAM. The data plane, where clients send engine commands, is governed by engine users with access strings, authenticated by password or by IAM token.

In ElastiCache, RBAC is available on Valkey 7.2 onward and Redis OSS 6.0 to 7.2, and it is the access control model for serverless caches. A user group for the VALKEY engine contains only users with an authentication mechanism (password or IAM). AWS also states that caches with a public endpoint need every user in the associated user group to use IAM authentication.

Access strings

Both services use space-delimited access strings. A user without on is off and has no access, and a command needs permission for both the command and every key it touches.

Passwords never go in the access string; set them with CreateUser and ModifyUser (ElastiCache) or CreateUser and UpdateUser (MemoryDB). In MemoryDB, vector search commands sit in the @search category, so leave it out of access strings for users that should not run search. For key naming and least privilege across data stores, see the Database Security Guide.

Admin roles and privileged access

Whoever can change users, user groups, ACLs or encryption settings controls every connection to the cache. Treat these control-plane actions as privileged.

• Admin users inside the engine: keep any on ~* +@all user for break-glass use only, with a password held in a secrets manager and every use reviewed. Day-to-day applications get scoped access strings.
• Human access: engineers debugging production should use an IAM-authenticated read-only user, reached through a short IAM Identity Center session, rather than a shared password. See the AWS IAM Identity Center Guide.
• Separate key administration: if you use a customer managed KMS key, the people who manage its policy should not also hold cache admin rights. See the AWS KMS Security Guide.

Integrations, API tokens and service accounts

Caches are used almost entirely by machines: web tiers storing sessions, workers draining queues, Lambda functions and containers. Each is a non-human identity, and the choice is between a stored password and a short-lived IAM token.

IAM authentication (preferred for AWS workloads)

1. Create an engine user with authentication mode iam. In ElastiCache, the user name and user ID must be identical.
2. Add the user to a user group (ElastiCache) or ACL (MemoryDB) and attach it to the cache or cluster.
3. Grant the workload's IAM role elasticache:Connect or memorydb:Connect on both the cache or cluster ARN and the user ARN.
4. Use a client with a credentials provider that generates tokens. Tokens are valid for 15 minutes, and IAM-authenticated connections are disconnected after 12 hours unless the client re-authenticates with AUTH or HELLO and a new token.

Condition keys add network context. For ElastiCache serverless caches reached through a VPC endpoint, AWS lists aws:SourceVpc, aws:SourceVpce and aws:VpcSourceIp among the supported keys; for replication groups, aws:SourceIp and aws:ResourceTag. ElastiCache converts cache names to lowercase at creation, so token generation code must use the lowercase name. Re-authentication cannot run inside MULTI/EXEC blocks, so plan token refresh outside transactions.

Password users and AUTH tokens

Where a client cannot use IAM, give each application its own password user with a scoped access string, store the password in AWS Secrets Manager, and rotate it using the two-password slot so existing connections stay up during the change. AWS notes that RBAC supports automatic password rotation through Secrets Manager. See the AWS Secrets Manager Guide.

Older node-based ElastiCache clusters may still use a single AUTH token. AWS describes AUTH as superseded by RBAC. To rotate a token, run ModifyReplicationGroup with the ROTATE strategy (the server then accepts the old and new tokens), move clients to the new token, then apply SET so only the new token is valid. Tokens are 16 to 128 printable characters. To move to RBAC, AWS documents ModifyReplicationGroup with --auth-token-update-strategy DELETE and the user group to add. Shared tokens in application config files are a common source of T1552.001 exposure, so prioritise this migration.

Logging and detection

• CloudTrail: records control-plane calls such as CreateUser, ModifyUser, ModifyUserGroup, ModifyReplicationGroup, UpdateACL and UpdateCluster. Alert when these come from anything other than the pipeline role. See the AWS CloudTrail Guide.
• Service events: user group and ACL changes apply asynchronously; watch the service's events and the PendingChanges field so a security change is confirmed, not assumed.
• Configuration checks: AWS Security Hub CSPM includes ElastiCache.4 (replication groups encrypted at rest), ElastiCache.5 (encrypted in transit), ElastiCache.6 (AUTH on earlier Redis OSS versions), ElastiCache.7 (no default subnet group), ElastiCache.1 (automatic backups) and ElastiCache.2 (automatic minor version upgrades). See the AWS Security Hub Guide.
• KMS events: with a customer managed key, key usage appears in CloudTrail. Disabling or deleting the key, or revoking its grants, makes an encrypted cache unrecoverable, so alert on key state changes.

Metrics that show the controls are working

• TLS coverage: percentage of caches passing ElastiCache.5, and MemoryDB clusters with TLS on.
• Authentication model: number of caches still on AUTH tokens or the open-access ACL, trending to zero.
• IAM adoption: percentage of application users using authentication mode iam.
• Scoped users: number of non-break-glass users with ~* and +@all.
• Encryption at rest: percentage of replication groups passing ElastiCache.4.

Hardening baseline

The sequence below is NHI Mgmt Group guidance, not a vendor requirement; adjust it to your environment.

1. Inventory: list caches, clusters, user groups, ACLs and users, with the application that owns each user.
2. Network placement: use private subnets in a dedicated subnet group (ElastiCache.7 flags the default subnet group) and security groups that allow the cache port only from the application's security group. See the Amazon VPC Security Guide.
3. Encryption in transit: create caches and clusters with TLS on. It is the prerequisite for RBAC, AUTH and restricted MemoryDB ACLs.
4. Encryption at rest: for node-based ElastiCache replication groups, set AtRestEncryptionEnabled at creation (it defaults to true for Valkey). To encrypt an existing unencrypted group, back it up, restore into a new encrypted group, repoint the application and delete the old group. Use a customer managed symmetric KMS key where you need key policy control; it supports automatic rotation. Note that backups exported to S3 use S3 server-side encryption.
5. Users: replace the ElastiCache default user with your own default user set to off; create one user per application with a scoped access string; in MemoryDB, attach a restricted ACL rather than open access.
6. Authentication: move AWS-hosted clients to IAM authentication; store remaining passwords in Secrets Manager with rotation.
7. Patching and backups: keep automatic minor version upgrades on (ElastiCache.2) and automatic backups on (ElastiCache.1), and apply vendor security updates promptly as published in AWS security bulletins.
8. Logging: CloudTrail alerts for user, group, ACL and security setting changes.

Testing and rollback: add the new user group or ACL alongside existing access, confirm with ACL WHOAMI from each client that it authenticates as the intended user, then remove the old token or default user. Because password users hold two passwords and AUTH supports ROTATE, most changes can be reversed without downtime. Small teams with one or two caches can go straight to IAM authentication on a new TLS-enabled cache; larger estates usually run a migration wave per application, with the access string reviewed by the application owner.

Common misconfigurations

• Default user left in place: a user group or ACL that still includes an enabled default user with all commands and keys, so any client that reaches the port has full access.
• One shared password for every service: a single AUTH token or password user in every config file, so rotation breaks everything and logs cannot separate clients.
• Over-broad access strings: on ~* +@all given to applications that need a few keys and read commands.
• Encryption left for later: node-based replication groups created without at-rest encryption, which then need a backup and restore to fix.
• Wide security groups: port 6379 open to whole VPC CIDRs or peered networks rather than the application's security group.
• Token refresh inside transactions: IAM clients that try to re-authenticate inside MULTI/EXEC or Lua scripts and drop connections at the 12-hour mark.

Framework mapping

Practitioner checklist

• Every ElastiCache cache and MemoryDB cluster has TLS on.
• The ElastiCache default user is replaced by a default user set to off; no MemoryDB cluster uses the open-access ACL.
• Each application has its own engine user with a scoped access string.
• AWS-hosted clients use IAM authentication with elasticache:Connect or memorydb:Connect scoped to the cache and user ARNs.
• Remaining passwords are in Secrets Manager with rotation; AUTH tokens are on a migration plan to RBAC.
• Node-based replication groups are encrypted at rest, with customer managed keys where key control is required.
• Caches sit in dedicated private subnet groups with security groups that reference application security groups.
• CloudTrail alerts cover user, user group, ACL and security setting changes; Security Hub ElastiCache controls pass.

Standards and references

• AWS: Role-Based Access Control (RBAC) for ElastiCache
• AWS: Authenticating with IAM in ElastiCache
• AWS: Authenticating with the Valkey and Redis OSS AUTH command
• AWS: At-rest encryption in ElastiCache
• AWS: Authenticating users with Access Control Lists in MemoryDB
• AWS: Authenticating with IAM in MemoryDB
• AWS: Security Hub controls for ElastiCache
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Redis Security Guide, Database Security Guide, AWS Secrets Manager Guide, Amazon DocumentDB Security, Data Security Guide.