SRGについて技術記事採用情報
SRGについて技術記事採用情報
HOME/技術記事/AWS ElastiCache & RDSのIAM認証詳解

AWS ElastiCache & RDSのIAM認証詳解

メディア統括本部 サービスリライアビリティグループ（SRG）の石川雲（@ishikawa_kumo）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事では、AWS ElastiCache および RDS における IAM 認証について、実際の実装手順と、運用の中で遭遇したハマりどころを整理します。パスワード管理に伴う運用負荷を軽減し、よりセキュアで効率的なインフラ構築を行うための参考になれば幸いです。

ElastiCache & RDS IAM 認証について

AWS のマネージドデータストアである ElastiCache と RDS では、従来、ElastiCache のデフォルトユーザ認証、RDS の Master ユーザによるパスワード認証が一般的に利用されてきました。
しかし、パスワード管理には明確な限界があります。
  • シークレットの保管場所が分散する
  • ローテーション運用が煩雑
  • 一時的な接続のために恒久的な認証情報を発行してしまう
  • セキュリティ事故の原因になりやすい
これらの問題に耐えられなくなった場合の現実的な選択肢が IAM 認証です。IAM 認証を使うことで、「パスワードを持つ」という前提そのものを排除できます。

ユースケース

1. Container 環境の DB・キャッシュ接続

コンテナ環境では、シークレット管理が最も手間で、最も事故を起こしやすいポイントです。リスク低減の観点からは Secrets Manager からの直接参照が求められますが、実際には以下のような複数レイヤーの設計が必要になります。
  • Secrets Manager
  • Pod への注入方法
  • ローテーション設計
  • IAM 権限設計
特に EKS の場合、External Secrets や Secret Operator の運用が必要になり、初期構築・保守ともにコストが高くなります。IAM 認証を利用すれば、
  • パスワードを環境変数に置かない
  • Secret として管理しない
  • Pod に付与された IAM 権限のみで接続する
という構成が可能になります。

2. ローカル環境・EC2 の DB Client

一時的な接続のために、パスワードをローカル環境や EC2 に保持すること自体がリスクです。
ローテーションという手段は存在しますが、
  • 手動作業が多い
  • 接続断が発生する
  • 開発者体験が悪化する
という理由で、実運用では形骸化しがちです。IAM 認証であれば、短命なトークン + IAM 権限で接続でき、「その場限りのアクセス」を安全に実現できます。

考慮事項（制限事項）

現時点のIAM認証には、無視できない制限が多数存在します。

ElastiCache における制限

抜粋
  • IAM 認証は、ElastiCache for Valkey 7.2 以上、または Redis OSS 7.0 以上でのみ利用可能です
  • IAM 認証トークンの有効期限は15 分、IAM 認証で確立された接続は 12 時間で自動的に切断されます

RDS における制限

抜粋
  • IAM データベース認証は、すべての IAM グローバル条件キーをサポートしていません。
  • PostgreSQL では、ユーザ（Master ユーザ含む）に rds_iam ロールを付与すると、パスワード認証は使用できなくなります。
  • IAM DB 認証は安定した接続には の追加メモリが必要です。
  • アプリケーションにおける新しい接続は 未満の場合、IAM認証の使用が推奨されます

ElastiCache IAM 認証

筆者は Replication Group の Redis を主に運用しています。Serverless や Valkey では一部挙動が異なります。

ElastiCache Cluster 要件

  • Valkey または Redis の特定バージョン以上、Memcached は非対応
  • TLS必須
    • TLS必須にしないと、UserGroupの指定ができません。
    • NodeType は最新世代であれば問題なし

ElastiCache User Group 要件

  • Redis
    • Default User を必ず含める
      • UserName=default、UserID 別の default ユーザを作成
      • 実際の IAM 認証用ユーザは別途作成
    • default ユーザは access string をすべて拒否、パスワード認証無効化
    • ValkeyはDefault User不要
  • IAM認証用ユーザはUserNameとUserIDが一致しなけれならない

TLS に関する注意点（公式ドキュメントの誤訳）

日本語ドキュメントには以下の誤訳があります。
転送時の暗号化は、以下のノードタイプを実行しているレプリケーショングループでのみサポートされます: M1、M2。
英語原文は以下です。
In-transit encryption is not supported for replication groups running the following node types: M1, M2.
意味は真逆です。現在の新しめの NodeType では TLSの有効化ができます。

Terraform Provider の既知バグとTLS変更手順

既存 Replication Group で TLS 有効化と User Group 指定を同時に行うと、encryption-in-transit が正しく反映されないケースがあります。
手動で変更し、その後Terraformで一致させる方法を取っています。
  1. 手動変更
      • transit_encryption_enabled = true
      • transit_encryption_mode = preferred
  1. 手動変更
      • transit_encryption_mode = required
  1. User Group 指定
      • Access Control方式にユーザグループと指定し、user_group_ids を指定（Terraform 実行可）
また、既存のTLS OffのServerless/Valkeyクラスタが、TLS有効化する際に、認証モードの直接変更ができないため、Preferred -> Requiredの手順を踏む必要があります。ReplicationGroup以外では、手動ではなく、Terraformによる複数回の実行によって、変更できます。

ElastiCache IAM 認証の設定フロー

  1. IAM 認証用ElastiCache ユーザを作成
  1. Pod/EC2/IAM Roleに IAM Policy を付与
具体的にはこういうポリシーです。このポリシーはResource Tagで制限することができます。

接続フロー

  1. SigV4 で IAM 認証トークンを生成
    1. 残念ですが、2025年12月時点では、UserTokenを生成する専用のCLIがないため、ProgramでSigV4 Tokenを生成する必要があります。公式ドキュメントではJavaの例がありますが、Goを作ってみました。
  1. TLS 接続で Redis に接続
IAM 認証トークン生成の例（Go）
生成されたトークンの構成
redis-cli 接続例

RDS IAM 認証

RDS のIAM認証は、ElastiCacheと比べて圧倒的に簡単です。主に二つの要件があります。
  • クラスタ内のIAM認証有効化設定
  • SQL文による、ユーザロール・AWSAuthenticationPluginの指定
クラスタ内のIAM認証有効化設定は主に の話です。
またログの指定もお勧めします。原因究明の時に使いやすいです。
 
SQLに関して、マスターユーザに指定する際の方法はMySQL、PosgreSQLによって違います。
筆者PosgreSQLしか検証していないため、情報が偏る可能性があります。
基本Master userをIAM認証の対象にした方がいいと思いますが、IAM認証に切り替えた瞬間から、パスワード認証ができなくなるため、アプリケーション側の切り替え方法を考えた方がいいです。

IAM Policyについて

IAM PolicyがRDS IAM認証最大な弱点だと考えています。
RDS IAM 認証は、従来の RDS API 群とは別に用意された、RDS IAM 認証専用 API（） を利用しています。この rds-db で利用できる Action は の 1 つのみです。
この Action が、環境名や Prefix を付与できない RDS の Cluster ID（Cluster 名ではない）でしかResource を指定できません。
また、ResourceTag をはじめとした Condition Key には一切対応していません。ARNのみになります。
IAM 認証を使う理由の一つは、本来、既存の IAM Policy が持つ ABAC などの柔軟な表現力を、DB 認証にも持ち込みたいからです。しかし、RDS IAM 認証ではそれができず、結果として IAM Policy では RDS の を直接指定するか、Terraform の Data ブロックなどを使って 静的に参照する構成を取らざるを得ません。
Terraformで書くと、こういう感じにになります。

接続フロー

  1. IAM 認証トークンを生成 (Tokenの生成は、AWS CLIで実行可能)
  1. TLS 接続で DB に接続
 
TokenはClientのパスワードとして指定します。
公式ドキュメントでは、 とか、とかでSSL証明書を指定する部分がありますが、sslmodeをrequiredにして、証明書は指定しなくても接続できます。

そのほかのハマりポイント

ElastiCache と RDS の IAM 認証は条件と相性が悪いです。
ElastiCache のドキュメントには以下の記載がありますが
When using IAM authentication with replication groups, aws:SourceIp and aws:ResourceTag/%s are supported.
しかし、これはどうやら嘘でした。
弊社の内部Federationシステムでは、発行したトークンは発行者PCのIPしか使えないという制限を入れているため、IAM認証がどうしても繋がらない問題がありました。SourceIPを取り外せば、すぐに使えるようになりました。

終わりに

IAM 認証は、パスワード管理を前提としないインフラ構成を実現できますが、トークンの扱いや条件キーなどの制限を理解せずに導入すると、確実に詰みます。
また、IAM 認証に関しては、公式ドキュメントに不十分な点が複数あります。実装や運用を想定した説明が足りず、仕様を正しく理解するには追加の検証が必要になる場面があります。筆者も公式ドキュメントを前提に実装を進めましたが、正しい構成に辿り着くまでに不要な検証コストを払いました。
パスワード認証に比べて導入のハードルが高く、アプリケーション側に求められる実装責務も増えます。そのため IAM 認証は、単に便利な機能として扱うのではなく、使いどころと前提条件を理解した上で選択すべき仕組みだと考えています。本記事が、IAM 認証をそのように捉えるための材料になれば幸いです。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。