RDS Proxyとは？対応エンジン・料金・接続プールの仕組みと導入手順を解説

Amazon RDS Proxyは、アプリケーションとAmazon RDS／Auroraの間に入り、データベース接続をプールして再利用するフルマネージドのプロキシです。Lambdaのように短時間で接続が急増するワークロードでも、データベースの接続上限に到達させずにスケールできます。この記事では、接続プールの仕組み、2026年時点で対応するDBエンジンとポート、vCPU課金の料金体系、CLIとCloudFormationでの構築手順、IAM／Secrets Managerによる認証、そして効果を打ち消すセッションピンニングの回避策までを、実際のコマンドとポリシー例で整理します。導入前に判断すべき「使うべきでない場面」も条件付きで示します。

まとめ：RDS Proxyの要点

• 役割：接続プールでDB接続を再利用し、同時接続数の爆発とフェイルオーバー時の切断を吸収する。アプリのコード変更はほぼ不要。
• 対応エンジン：Aurora（MySQL／PostgreSQL）、RDS for MySQL・MariaDB・PostgreSQL・SQL Server。かつて非対応だったMariaDBとSQL Serverも現在は対応（ただしSQL Server 2022／2014のメジャーバージョンは除外）。
• 料金：プロビジョンドは関連DBインスタンスのvCPUあたり0.015ドル／時（最小2vCPU）、Aurora Serverless v2はACU時間あたり0.015ドル（最小8ACU／プロキシ＝月最低およそ87.6ドル）。稼働している間は常に課金される。
• 認証：クライアント→プロキシはIAM、プロキシ→DBはSecrets Managerの資格情報またはIAM DB認証。通信はTLSで暗号化。
• 注意点：SETや一時テーブル、16KB超のSQLなどでセッションピンニングが起きると多重化が無効になり効果が消える。リードレプリカには関連付けできず、書き込みインスタンス専用。

RDS Proxyの仕組み：接続プールとトランザクション多重化

通常のRDS接続では、クライアントが接続するたびに新しいDBセッションが確立されます。RDS ProxyはアプリとDBの間に入り、あらかじめ確立した接続の「プール」を保持して、複数のクライアントリクエストで使い回します。これにより、実際にDBへ張られる接続数を大きく抑えられます。中核となるのがトランザクション多重化で、既定ではトランザクション単位でプールから接続を貸し出し、コミット／ロールバック直後にプールへ返却します。1つのDB接続を短時間で多数のクライアントが共有できるため、接続確立のオーバーヘッドとメモリ消費を削減できます。

アプリケーション側の接続プール（JavaのHikariCPなどのコネクションプール）はプロセス内でしか接続を共有できませんが、RDS Proxyはインフラ層で全クライアントを横断してプールするため、Lambdaのように実行環境が分散・使い捨てになる構成でも接続を共有できる点が異なります。両者は排他ではなく、アプリ側プールで無駄な再接続を減らしつつRDS Proxyでバックエンド接続数を抑える、という併用が実務では有効です。

フェイルオーバー時に接続を維持する仕組み

マルチAZ構成でプライマリDBに障害が起きると、通常はクライアント側で接続が切れて再接続処理が必要になります。RDS Proxyはバックエンドの状態を監視し、フェイルオーバーを検知すると新しい書き込みインスタンスへルーティングを自動で切り替えます。クライアントとプロキシの間の接続は維持されるため、アプリは接続先を意識せず処理を続行できます。AWSのマネージドフェイルオーバーでの接続断時間を短縮できるのが、可用性面での主な価値です。ただしフェイルオーバー直後は一時的に接続待ちが発生し得るため、アプリ側にはタイムアウトとリトライ（指数バックオフ）の設計を残しておきます。

対応するDBエンジン・バージョンとポート

RDS Proxyの対応エンジンは拡大しており、2026年時点では以下が利用できます。旧来「MariaDBやSQL Serverは非対応」と説明されることがありますが、これは古い情報です。CloudFormationのEngineFamilyで指定するエンジンファミリと、プロキシが待ち受けるポートは次の通りです。

プロキシは上記の固定ポートで待ち受け、DBへはインスタンス設定で指定したポートで接続します。SQL Serverはメジャーバージョン2022と2014が対象外で、クライアント→プロキシのIAM認証も使えない（Secrets Managerでの資格情報連携は可能）点が他エンジンと異なります。バージョン別の可否はリージョンでも差があるため、導入前にAWSの「Supported Regions and DB engines for Amazon RDS Proxy」で対象バージョンを確認してください。なおAurora MySQL 8.4のような新しいバージョンを使う場合は、対応状況の確認を先に行うと手戻りを防げます。

RDS Proxyの料金体系

RDS Proxyには追加料金が発生します。プロビジョンドインスタンスでは、プロキシを関連付けたDBインスタンスのvCPUあたり0.015ドル／時で、1インスタンスあたり最小2vCPUが課金対象です。たとえば2vCPUのdb.t3.medium／db.r6g.largeに関連付けると、2 × 0.015＝0.03ドル／時（720時間換算で月およそ21.6ドル）が目安になります。Aurora Serverless v2ではvCPUではなく消費したACU（Aurora Capacity Unit）時間あたり0.015ドルで課金されますが、プロキシあたり最小8ACUが課金対象になる点に注意が必要です。DBが0.5ACUしか使っていなくても8ACUぶん（730時間換算で月最低およそ87.6ドル）が発生するため、負荷の低いServerless v2にプロキシを付けると割高になりやすく、導入判断ではこの最低課金を先に見積もります。

課金は1秒単位で計上され、プロキシの作成・開始・変更といった状態変化後は最低10分ぶんが課金されます。プロキシは稼働している限り接続の有無にかかわらず料金が発生するため、検証用に作ったプロキシを消し忘れないよう注意します。加えて、データ転送量やSecrets Managerの利用にも個別課金があるため、総コストはこれらを合算して見積もります。最新の単価はリージョンで異なるので、AWSのRDS Proxy料金ページで確認してください。

RDS Proxyの導入手順（CLI・CloudFormation）

導入の流れは、(1) Secrets ManagerにDB資格情報を登録、(2) プロキシがそのシークレットを読むためのIAMロールを作成、(3) プロキシを作成してターゲットを登録、(4) アプリの接続先をプロキシのエンドポイントに変更、の4段階です。プロキシはDBと同じVPC内に配置する必要があり、パブリックには公開できません。

AWS CLIでのプロキシ作成

Secrets Managerのシークレットと、それを読むIAMロールを用意したうえで、プロキシを作成してDBインスタンスをターゲット登録します。

aws rds create-db-proxy \
  --db-proxy-name my-app-proxy \
  --engine-family MYSQL \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds-db-creds-AbC123","IAMAuth":"REQUIRED"}]' \
  --role-arn arn:aws:iam::123456789012:role/rds-proxy-role \
  --vpc-subnet-ids subnet-aaaa subnet-bbbb \
  --require-tls

aws rds register-db-proxy-targets \
  --db-proxy-name my-app-proxy \
  --db-instance-identifiers my-mysql-instance

--require-tlsでクライアント→プロキシ間のTLSを必須化し、IAMAuth:REQUIREDでIAM認証を強制しています。ステータスがavailableになれば、発行された接続エンドポイントを利用できます。

CloudFormation（AWS::RDS::DBProxy）での管理

Infrastructure as Codeで管理する場合は、プロキシ本体をAWS::RDS::DBProxy、ターゲットの割り当てをAWS::RDS::DBProxyTargetGroupで定義します。

Resources:
  AppProxy:
    Type: AWS::RDS::DBProxy
    Properties:
      DBProxyName: my-app-proxy
      EngineFamily: MYSQL
      RequireTLS: true
      RoleArn: !GetAtt ProxyRole.Arn
      Auth:
        - AuthScheme: SECRETS
          SecretArn: !Ref DBSecret
          IAMAuth: REQUIRED
      VpcSubnetIds:
        - !Ref SubnetA
        - !Ref SubnetB
  ProxyTargets:
    Type: AWS::RDS::DBProxyTargetGroup
    Properties:
      DBProxyName: !Ref AppProxy
      TargetGroupName: default
      DBInstanceIdentifiers:
        - !Ref MyDBInstance

DebugLoggingを一時的にtrueにすると、ピンニングの原因になるSQLをCloudWatch Logsで特定できます（ログにSQL文が出るため常用は避けます）。

エンドポイントとアプリ側の接続変更

プロキシには既定エンドポイントに加え、1プロキシあたり最大20個の追加エンドポイントを作成できます。読み取り専用のエンドポイントを分けたい場合などに使います。アプリ側は、接続先ホストを従来のRDSエンドポイントからプロキシのエンドポイント（my-app-proxy.proxy-xxxx.ap-northeast-1.rds.amazonaws.com）へ差し替えるだけで、接続文字列以外のコード変更は基本的に不要です。ただしセッション変数やカーソルを多用するアプリは挙動が変わり得るため、テスト環境での確認を挟みます。

IAM認証とSecrets Managerによる資格情報管理

RDS Proxyは認証を2段構えにします。クライアントからプロキシへの接続はIAMで認可し、プロキシからDBへの接続はSecrets Managerに保存した資格情報（またはIAM DB認証）で行います。これにより、DBのユーザー名・パスワードをアプリのコードや環境変数に埋め込む必要がなくなります。

Secrets Managerとプロキシ用ロール

DBのユーザー名とパスワードをSecrets Managerのシークレットとして保存し、プロキシに割り当てるIAMロールにそのシークレットの読み取り権限を与えます。1つのプロキシには最大200個のシークレット（＝最大200ユーザー）を関連付けできます。プロキシ用ロールに付与する最小権限は次の通りです。Secrets ManagerとParameter Storeの使い分けに迷う場合は、自動ローテーションが必要なDB資格情報はSecrets Manager側に置くのが基本です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds-db-creds-*"
    },
    {
      "Effect": "Allow",
      "Action": ["kms:Decrypt"],
      "Resource": "*",
      "Condition": {"StringEquals": {"kms:ViaService": "secretsmanager.ap-northeast-1.amazonaws.com"}}
    }
  ]
}

クライアント側のIAM認証（rds-db:connect）

アプリ（例：Lambda実行ロール）がプロキシに接続する側では、rds-db:connect権限をプロキシのリソースARNに対して付与します。ARNにはDBインスタンスIDではなくプロキシのリソースID（prx-で始まる）を使う点に注意します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds-db:ap-northeast-1:123456789012:dbuser:prx-0123456789abcdef/app_user"
    }
  ]
}

接続時は静的パスワードの代わりに一時トークンを取得して使います。トークンの有効期限は15分で、通信はTLSで暗号化されます。

TOKEN=$(aws rds generate-db-auth-token \
  --hostname my-app-proxy.proxy-xxxx.ap-northeast-1.rds.amazonaws.com \
  --port 3306 --username app_user)

mysql -h my-app-proxy.proxy-xxxx.ap-northeast-1.rds.amazonaws.com \
  -P 3306 -u app_user --enable-cleartext-plugin --password="$TOKEN"

セッションピンニングと回避策

RDS Proxyの効果は、接続がプールに戻って再利用されることが前提です。しかしセッション固有の状態を持つ操作が来ると、プロキシはそのクライアント接続を1本のDB接続に固定します。これをセッションピンニング（ピン留め）と呼び、固定された接続は多重化の対象から外れるため、ピンニングが多発すると接続プールの効果が実質的に失われます。導入したのに接続数が減らない、という典型的な失敗はこれが原因です。

ピンニングが発生する主な条件

• テキストサイズが16KBを超えるSQL文（全エンジン共通）。
• PostgreSQL：SET、PREPARE／DISCARD／DEALLOCATE／EXECUTE、一時テーブル・一時シーケンス・一時ビューの作成、カーソル宣言、LISTEN、auto_explainなどのライブラリ読み込み。
• MySQL／MariaDB：実行可能コメント（/*! ... */）、テーブルロック、ユーザー変数の使用など。

初期化クエリとピンニングフィルタでの回避策

まず、全接続で共通の初期化（文字コードやタイムゾーンのSETなど）は、アプリ側で毎回実行するのではなく、プロキシの初期化クエリ（initialization query）に移します。プロキシ側で初期化すればトランザクション多重化を保ったまま初期状態を揃えられます。MySQL系ではセッションピンニングフィルタを設定し、影響がないと分かっている操作をピンニング対象から除外できます（PostgreSQLはフィルタ非対応のため、変数はDB側に設定する方針を採ります）。CloudWatchのDatabaseConnectionsCurrentlySessionPinnedやDebugLoggingで原因SQLを特定し、該当箇所を潰していくのが実務の進め方です。

AWS Lambdaとの連携

Lambdaはリクエストごとに実行環境が起動するため、同時実行が数百〜数千に達するとRDSの接続上限をすぐ超えてしまいます。RDS Proxyを挟むと、各Lambdaはプロキシのプール経由で接続を共有するため、バックエンドへの新規接続を抑えられます。設定の要点は、Lambdaの実行ロールにrds-db:connectを付与し、プロキシのエンドポイントへIAM認証で接続することです。AWS SAMなどでLambda・プロキシ・シークレットをまとめて定義しておくと、権限とネットワーク（同一VPC・サブネット）の設定漏れを防げます。

ただしLambdaでもトランザクションを短く保つことは重要です。1回の呼び出しで長時間トランザクションを保持すると接続がピン留めされ、他の同時実行がプールを奪い合ってスループットが落ちます。関数内では処理をトランザクションスコープ最小で書き、接続はプロキシ任せにするのが基本方針です。

RDS Proxyを使うべきでない場面・導入前チェック

RDS Proxyは万能ではなく、コストと制約に見合わないケースがあります。導入前に次の条件に当てはまらないかを確認してください。

• 同時接続数がそもそも少ない：常時稼働のECS／EC2で接続数が安定し、アプリ側プールで足りているなら、追加料金に見合う効果は薄い。接続数の急増やLambdaの大量並列がない構成では見送る判断が妥当です。
• ピン留めが避けられないワークロード：一時テーブルやセッション変数、長時間トランザクションが処理の中心なら、多重化がほとんど効かず料金だけがかかります。まずアプリ側の実装見直しが先です。
• リードレプリカへ直接向けたい：RDS（非Aurora）のレプリケーション構成では、プロキシは書き込み（ライター）インスタンスにのみ関連付けでき、リードレプリカ単体には付けられません。この場合の読み取り分散はレプリカのエンドポイントなど別手段を使います。Auroraではプロキシの読み取り専用エンドポイントでリーダーへ振り分けられるため、この制約は主に非AuroraのRDSに当てはまります。
• VPC構成が合わない：テナンシーがdedicatedのVPCや、暗号化制御でEnforce Modeが有効なVPCでは利用できません。プロキシはDBと同一VPC内で、パブリック公開もできません。

アカウントあたりのプロキシ数は既定で20個、緩和はService Quotasから申請します。これらの制約とvCPU課金を踏まえ、「接続の急増・使い捨て接続・フェイルオーバー時の切断を減らしたい」という明確な目的があるときに導入するのが、費用対効果を外さない判断です。

よくある質問

RDS Proxyの料金はいくらですか？

プロビジョンドインスタンスでは、関連付けたDBインスタンスのvCPUあたり0.015ドル／時（最小2vCPU）です。2vCPUなら約0.03ドル／時・月およそ21.6ドルが目安で、Aurora Serverless v2はACU時間あたり0.015ドル・最小8ACU（月最低およそ87.6ドル）で課金されます。稼働中は接続の有無にかかわらず課金される点に注意してください。

RDS Proxyのポート番号はいくつですか？

プロキシの待ち受けポートはエンジンで固定です。MySQL・MariaDBは3306、PostgreSQLは5432、SQL Serverは1433です。プロキシからDBへは、DBインスタンスで設定したポートで接続します。

RDS ProxyはSQL Serverに対応していますか？

RDS for SQL Serverに対応しています。ただしメジャーバージョンのSQL Server 2022と2014は対象外で、クライアント→プロキシのエンドツーエンドIAM認証やActive Directory認証は利用できません。認証はSecrets Managerの資格情報連携で行います。

接続プール（コネクションプール）とは何ですか？

あらかじめ確立したDB接続をまとめて保持し、複数のリクエストで使い回す仕組みです。RDS Proxyはこれをインフラ層で提供し、トランザクション単位で接続を貸し借りする多重化によって、実際にDBへ張る接続数を抑えます。

セッションのピン留め（ピンニング）とは何ですか？

セッション固有の状態を持つ操作（SET、一時テーブル、16KB超のSQLなど）が来たとき、その接続を1本のDB接続に固定する挙動です。固定された接続は多重化されないため、ピン留めが多いとプールの効果が失われます。共通の初期化を初期化クエリに移し、ピンニングフィルタを設定することで発生を抑えます。

関連記事

• HikariCPとは？設定パラメータとSpring Bootでのプール設定・リーク対策を解説
• Amazon Aurora Serverless v2の概要と新機能の徹底解説
• Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提
• パラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説