Amazon RDSのIAMデータベース認証で接続レートがスケールするようになったので、RDS for MySQLで負荷テストしてみた
はじめに
2026年6月30日、Amazon RDSのIAMデータベース認証に関するアップデートが発表されました。
公式アナウンスの要点は以下の通りです。
IAM database authentication performance now scales with available instance resources, enabling enterprise workloads to leverage IAM authentication for high-volume connection patterns.
IAMデータベース認証のパフォーマンスが、インスタンスの利用可能なリソースに連動してスケールするようになりました。本記事では特に新規接続レートの観点で検証しています。
アップデート前後の比較
| 項目 | Before | After |
|---|---|---|
| 接続レート制限 | 固定的な上限あり（例: ~20 conn/sec） | インスタンスリソースに連動してスケール |
| ドキュメント上の記載 | 固定上限あり（時期により 20/sec、256/sec 等の記載が変動） | 具体的な数値の制限記載なし |
| 制約 | 高並列環境ではプーリング必須 | インスタンスのリソース次第 |
今回のアップデートで実際にどの程度の接続レートが出るようになったのか、負荷テストで確認したところ、ピーク1432 conn/secでもIAM認証エラーはゼロでした。
検証環境
- RDS: MySQL 8.4.8, シングルAZ, IAMデータベース認証有効
- インスタンスクラス:
- db.m8g.large（2 vCPU / 8 GiB）
- db.m8g.xlarge（4 vCPU / 16 GiB）
- db.t4g.micro（2 vCPU / 1 GiB）
- 踏み台 EC2: m7g.large → c8g.2xlarge（負荷生成能力向上のため途中で変更）
- リージョン: ap-northeast-1
テスト方法
テストスクリプトはPythonで作成し、以下の流れで1接続を処理します。
- IAM認証トークンを事前生成（15分有効、全接続で再利用）
mysql-connector-pythonでSSL接続（mysql_clear_passwordプラグイン指定）SELECT 1を実行- 即座に切断
これを並列で大量に実行し、秒あたりの成功接続数を計測しました。前半のテストではThreadPoolExecutorを使用しましたが、GILを含むPythonプロセス内の処理がボトルネックになりました。後半はmultiprocessing + ThreadPoolExecutorの組み合わせでこれを回避しています。
エラー発生時は種別を記録し、IAM認証拒否（レート制限起因）とmax_connections超過（接続数上限起因）を区別できるようにしました。
なお、本検証では事前生成した同一のIAM認証トークンを全接続で再利用しています。接続ごとにトークンを新規生成するパターンとは条件が異なる点に留意してください。
検証結果
Phase 1: EC2 m7g.large — ThreadPoolExecutor
| RDS クラス | max_connections | テスト条件 | 成功率 | 実効レート | ピーク | エラー |
|---|---|---|---|---|---|---|
| db.m8g.large | 630 | 600並列 × 6000回 | 100% | 210/sec | 263/sec | なし |
| db.m8g.xlarge | 1289 | 1000並列 × 10000回 | 100% | 205/sec | 未計測 | なし |
| db.t4g.micro | 60 | 30並列 × 3000回 | 100% | 48.8/sec | 104/sec | なし |
| db.t4g.micro | 60 | 50並列 × 5000回 | 96.3% | 67.6/sec | 未計測 | Too many connections (187件) |
db.t4g.microで発生した失敗は全て Too many connections（max_connections=60の超過）であり、IAM認証レート制限によるエラーではありません。
この段階ではクライアント側のEC2（m7g.large, 2 vCPU）が律速になっていました。RDSのインスタンスクラスを上げても実効レートはほぼ変わりません（db.m8g.large: 210/sec、db.m8g.xlarge: 205/sec）。
Phase 2: EC2 c8g.2xlarge — multiprocessing + ThreadPoolExecutor
クライアント側をc8g.2xlarge（8 vCPU）にスケールアップし、GILを回避するマルチプロセス構成にしました。
| RDS クラス | テスト条件 | 成功率 | 実効レート | ピーク | エラー |
|---|---|---|---|---|---|
| db.m8g.large | 8proc × 50threads × 10000回 | 100% | 360/sec | 516/sec | なし |
| db.m8g.large | 8proc × 70threads × 10000回 | 100% | 454/sec | 819/sec | なし |
| db.m8g.large | 8proc × 75threads × 10000回 | 98.0% | 429/sec | 803/sec | DNS 解決失敗 (202件) |
並列数を上げていくと、クライアント側の名前解決処理が追いつかなくなりました。DNS解決失敗が一部で発生しましたが、IAM認証起因のエラーは依然ゼロです。
Phase 3: EC2 c8g.2xlarge + dnsmasq キャッシュ
dnsmasqによるローカルDNSキャッシュを有効化し、DNSボトルネックを解消しました。まずdb.m8g.largeで再テストし、最終的にRDSもdb.m8g.xlargeへスケールアップしています。
| RDS クラス | テスト条件 | 成功率 | 実効レート | ピーク | エラー |
|---|---|---|---|---|---|
| db.m8g.large | 8proc × 120threads × 10000回 | 100% | 685/sec | 1058/sec | なし |
| db.m8g.xlarge | 8proc × 150threads × 20000回 | 100% | 728/sec | 1432/sec | なし |
db.m8g.xlargeの最終テストでは、テスト全体の平均である実効レート728 conn/sec、1秒単位での最大値であるピーク1432 conn/secを記録しました。全20000接続が成功し、IAM認証によるエラーは一切発生していません。
結果のまとめ
全テストケースを通じて、IAM認証レート制限に起因するエラーは ゼロ でした。
発生した失敗は以下の2種類のみで、いずれもIAM認証レートとは無関係です。
- Too many connections: max_connectionsの上限に達した場合（db.t4g.micro）
- DNS 解決失敗: 高並列時にクライアント側の名前解決が律速（dnsmasq導入で解消、Phase 2の一部テスト）
従来ドキュメントで言及されていた上限の目安（~20 conn/sec）と比較すると、今回の実測ピーク1432 conn/secは大幅な改善です。
まとめ
今回の検証では、従来ドキュメントで言及されていた固定的な接続レート上限の目安を大きく超え、ピーク1432 conn/secでもIAM認証起因のエラーは発生しませんでした。今回の検証条件では、律速要因はクライアント側の処理能力やmax_connectionsに移っており、RDSのIAM認証レートが先に制約となる状況は確認されませんでした。
LambdaやECSタスクのように短命な接続を大量に生成するワークロードでも、従来よりIAM認証の接続レートが制約になりにくくなったと考えられます。なお、本検証は同一のIAM認証トークンを再利用した条件での結果です。
