About SRGTechnical ArticlesRecruitment Information
About SRGTechnical ArticlesRecruitment Information
HOME/Technical Articles/AWS ElastiCache & RDS IAM Authentication Details

AWS ElastiCache & RDS IAM Authentication Details

Ishikawa Kumo (Service Reliability Group (SRG) of the Media Headquarters)@ishikawa_kumo)is.
#SRG(Service Reliability Group) is a group that mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
In this article, we will explain the actual implementation steps for IAM authentication in AWS ElastiCache and RDS, as well as some of the pitfalls we encountered during operation. We hope this article will help you reduce the operational burden associated with password management and build a more secure and efficient infrastructure.

About ElastiCache & RDS IAM authentication

AWS managed data stores, ElastiCache and RDS, have traditionally commonly used default user authentication for ElastiCache and password authentication for the Master user for RDS.
However, password management has clear limitations.
  • Secrets are stored in a decentralized location
  • Rotation operation is complicated
  • Issuing permanent credentials for a temporary connection
  • It is likely to cause a security breach
If these problems become unbearable, what are your realistic options?IAM authenticationBy using IAM authentication, you can eliminate the very premise of having a password.

Use Cases

1. DB/cache connection in Container environment

In a container environment,Managing secrets is the most time-consuming and accident-prone pointFrom a risk reduction perspective, direct reference from Secrets Manager is required, but in reality, a multi-layered design like the one below is required.
  • Secrets Manager
  • How to inject into a Pod
  • Rotation Design
  • IAM permission design
In particular, EKS requires the operation of External Secrets and Secret Operator, which increases the costs of both initial construction and maintenance.
  • Don't put passwords in environment variables
  • Do not manage as a secret
  • Connect only with the IAM permissions granted to the Pod
This configuration becomes possible.

2. DB Client in local environment/EC2

Storing passwords locally or on EC2 for temporary connections is a risk in itself.
There is a method called rotation,
  • There is a lot of manual work
  • Loss of connection occurs
  • Poor developer experience
For this reason, it tends to become a mere formality in actual operation. With IAM authentication,Short-lived tokens + IAM permissionsThis allows for secure "ad hoc access."

Considerations (Limitations)

Currently, IAM authentication has a number of significant limitations.

ElastiCache Limits

excerpt
  • IAM authentication is only available for ElastiCache for Valkey 7.2 and above, or Redis OSS 7.0 and above.
  • IAM authentication tokens expire in 15 minutes, and connections established with IAM authentication are automatically disconnected after 12 hours.

RDS Limitations

excerpt
  • IAM database authentication does not support all IAM global condition keys.
  • In PostgreSQL, if you grant the rds_iam role to a user (including the Master user), password authentication will no longer be available.
  • 300〜1000 MiB
  • 1 秒あたり200

ElastiCache IAM authentication

I mainly use Redis in Replication Groups. Some behaviors are different in Serverless and Valkey.

ElastiCache Cluster Requirements

  • Valkey or Redis (certain versions or higher), Memcached is not supported
  • TLS required
    • If TLS is not required, you cannot specify a UserGroup.
    • There is no problem if the NodeType is the latest generation.

ElastiCache User Group Requirements

  • Redis
    • Always include Default User
      • Create a default user with UserName=default and UserID
      • The actual IAM authentication user is created separately.
    • The default user is denied all access strings and password authentication is disabled.
    • Valkey does not require a Default User
  • The UserName and UserID of the IAM authentication user must match.

TLS notes (mistranslation of official documentation)

The Japanese documentation contains the following mistranslation:
In-transit encryption is only supported for replication groups running the following node types: M1, M2.
The original English text is below.
In-transit encryption is not supported for replication groups running the following node types: M1, M2.
The meaning is quite the opposite: newer NodeTypes now allow you to enable TLS.

Known Terraform Provider bugs and TLS change procedures

If you enable TLS and specify a User Group for an existing Replication Group at the same time, encryption-in-transit may not be reflected correctly.
The solution is to manually change it and then match it in Terraform.
  1. Manual Change
      • transit_encryption_enabled = true
      • transit_encryption_mode = preferred
  1. Manual Change
      • transit_encryption_mode = required
  1. User Group specification
      • Specify user group as the Access Control method and specify user_group_ids (Terraform can be executed)
Also, when enabling TLS on an existing Serverless/Valkey cluster with TLS off, you cannot directly change the authentication mode, so you must go through the steps to change from Preferred to Required. For clusters other than ReplicationGroup, you can change the mode by running Terraform multiple times, rather than manually.

ElastiCache IAM authentication configuration flow

  1. Create an IAM user for ElastiCache authentication
  1. Assign an IAM Policy to a Pod/EC2/IAM Role
Specifically, the policy is as follows. This policy can be restricted by Resource Tag.

Connection Flow

  1. Generate IAM authentication tokens with SigV4
    1. Unfortunately, as of December 2025, there is no dedicated CLI for generating UserTokens, so you will need to generate SigV4 Tokens programmatically. The official documentation provides an example in Java, but I created one in Go.
  1. Connecting to Redis over a TLS connection
IAM authentication token generation example (Go)
Configure the generated token
redis-cli connection example

RDS IAM authentication

IAM authentication for RDS is much simpler than for ElastiCache. There are two main requirements:
  • Enable IAM authentication in the cluster
  • Specifying user role and AWSAuthenticationPlugin using SQL statements
iam_database_authentication_enabled = true
We also recommend specifying a log, as this will be useful when investigating the cause.
enabled_cloudwatch_logs_exports = ["iam-db-auth-error"]
 
Regarding SQL, the method for specifying the master user differs between MySQL and PostgreSQL.
The author has only tested PostgreSQL, so the information may be biased.
I think it's best to make the Master user the target of IAM authentication, but the moment you switch to IAM authentication, password authentication will no longer be possible, so it's better to consider how to switch on the application side.

About IAM Policy

I believe that IAM Policy is the biggest weakness of RDS IAM authentication.
connect
connect
Also, it does not support any condition keys such as ResourceTag. Only ARN is supported.
Cluster ID
If you write it in Terraform, it will look something like this:

Connection Flow

  1. Generate an IAM authentication token (Token generation can be performed using the AWS CLI)
  1. Connect to DB via TLS connection
 
Token is specified as the password for the client.
—sslmode=verify-full sslrootcert=full_path_to_ssl_certificate

Other addictive points

aws:SourceIp
The ElastiCache documentation states:
When using IAM authentication with replication groups, aws:SourceIp and aws:ResourceTag/%s are supported.
However, this was apparently a lie.
aws:SourceIp

Conclusion

IAM authentication allows you to configure an infrastructure that does not require password management, but if you implement it without understanding the restrictions on token handling and condition keys, you will definitely run into problems.
Furthermore, the official documentation for IAM authentication has several shortcomings. It lacks sufficient explanation for implementation and operation, and there are times when additional testing is required to correctly understand the specifications. I also implemented it based on the official documentation, but ended up paying unnecessary testing costs before arriving at the correct configuration.
Compared to password authentication, IAM authentication has a higher implementation hurdle and places greater responsibility on the application side to implement it. For this reason, IAM authentication should not be treated simply as a convenient feature, but rather as a system that should be selected after understanding its intended use and prerequisites. I hope this article will help you understand IAM authentication in this way.
SRG is looking for people to work with us.
If you are interested, please contact us here.