RDS Proxyの使い方｜LambdaからDB接続を安定させる設定

RDS Proxy は、アプリと RDS・Aurora の間に置く、AWS が運用する接続プールです。 Lambda のように「同時に何百も起動し、それぞれが DB に接続する」使い方では、DB の同時接続の上限（max_connections）にすぐ達します。RDS Proxy はアプリからの接続を受け、少ない数の DB 接続をトランザクションごとに使い回します（多重化）。ただし、セッションの状態を変える SQL を使うと、その接続は使い回されず固定されます。これをピン留め（pinning）と呼び、多いと効果が薄れます。

Lambda（同時 500）──► RDS Proxy ──► DB（接続は max_connections × MaxConnectionsPercent まで）
   各実行環境が1接続        トランザクションが終わるたびに DB 接続を別のクライアントに回す

確認環境：AWS CLI 1.46.1・boto3 1.43.112（Linux）。AWS には接続せず、moto 5.2.4 のサーバーモードで create-db-proxy・register-db-proxy-targets・describe-db-proxies・describe-db-proxy-targets・modify-db-proxy-target-group の形を確かめました。Lambda の Python コード（psycopg 3.3.6）は、moto の Secrets Manager からパスワードを読み、PostgreSQL 16.15 に接続して動かしています。ピン留めの原因になるドライバーの動き（psycopg のプリペアドステートメント）は PostgreSQL で確かめました。プロキシの多重化・ピン留めの条件・上限・料金は AWS のドキュメントと料金ページに基づいています（確認日 2026年10月13日）。

なぜ必要か：Lambda と接続数

RDS Proxy を置くと、次のように変わります（ドキュメント）。

DB 側の接続数の見方は、関連記事「PostgreSQL接続数の確認｜pg_stat_activityの見方と対処」で扱っています。MySQL で上限に達したときは、関連記事「MySQL Too many connectionsの原因と直し方」で扱っています。

作成手順（CLI）

① シークレットを作る

SECRET_ARN=$(aws secretsmanager create-secret --name app-db/app-user \
  --secret-string '{"username":"app_user","password":"Str0ng-Passw0rd-0123"}' \
  --query ARN --output text)

username と password を持つ JSON です（ドキュメントの形）。1 つのプロキシに付けられるシークレットは 200 個までで、DB ユーザーごとに 1 つ作ります。シークレットの扱いは、関連記事「AWS Secrets Managerの使い方 CLI・boto3取得早見表」で扱っています。

② プロキシ用の IAM ロール

cat > proxy-trust.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
  "Principal":{"Service":"rds.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role --role-name rds-proxy-role --assume-role-policy-document file://proxy-trust.json

cat > proxy-secrets.json <<EOF
{"Version":"2012-10-17","Statement":[
  {"Effect":"Allow","Action":"secretsmanager:GetSecretValue","Resource":"$SECRET_ARN"},
  {"Effect":"Allow","Action":"kms:Decrypt","Resource":"arn:aws:kms:ap-northeast-1:123456789012:key/KEY_ID",
   "Condition":{"StringEquals":{"kms:ViaService":"secretsmanager.ap-northeast-1.amazonaws.com"}}}
]}
EOF
aws iam put-role-policy --role-name rds-proxy-role --policy-name read-db-secrets \
  --policy-document file://proxy-secrets.json

kms:Decrypt は、シークレットを独自の KMS キーで暗号化した場合に要ります。IAM ロールの考え方は、関連記事「IAMロールとは｜ユーザー・ポリシーとの違いとAssumeRole、信頼ポリシー」で扱っています。

③ プロキシを作り、DB を登録する

aws rds create-db-proxy --db-proxy-name app-proxy \
  --engine-family POSTGRESQL \
  --role-arn arn:aws:iam::123456789012:role/rds-proxy-role \
  --vpc-subnet-ids subnet-0aaa1111 subnet-0bbb2222 \
  --vpc-security-group-ids sg-proxy \
  --auth "[{\"AuthScheme\":\"SECRETS\",\"SecretArn\":\"$SECRET_ARN\",\"IAMAuth\":\"REQUIRED\",\"ClientPasswordAuthType\":\"POSTGRES_SCRAM_SHA_256\"}]" \
  --require-tls --idle-client-timeout 1800

# RDS インスタンスなら --db-instance-identifiers、Aurora なら --db-cluster-identifiers
aws rds register-db-proxy-targets --db-proxy-name app-proxy --db-instance-identifiers app-db

aws rds describe-db-proxies --db-proxy-name app-proxy \
  --query 'DBProxies[0].[Status,Endpoint,RequireTLS,IdleClientTimeout]'
aws rds describe-db-proxy-targets --db-proxy-name app-proxy \
  --query 'Targets[].[RdsResourceId,Port,TargetHealth.State,TargetHealth.Reason]'

moto で作ったときの応答の一部です。

"DBProxyArn": "arn:aws:rds:ap-northeast-1:123456789012:db-proxy:prx-fcit7ksjaph1u3ryx",
"Status": "available",
"EngineFamily": "POSTGRESQL",
"Auth": [{ "AuthScheme": "SECRETS", "IAMAuth": "REQUIRED", "ClientPasswordAuthType": "POSTGRES_SCRAM_SHA_256", ... }],
"RequireTLS": true,
"IdleClientTimeout": 1800,

ターゲットは登録直後 REGISTERING で、describe-db-proxy-targets で AVAILABLE になりました。AWS のエンドポイントは app-proxy.proxy-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com の形です。

④ セキュリティグループ

aws ec2 authorize-security-group-ingress --group-id sg-proxy --protocol tcp --port 5432 --source-group sg-lambda
aws ec2 authorize-security-group-ingress --group-id sg-db    --protocol tcp --port 5432 --source-group sg-proxy

ドキュメントでは、サブネットに空いている IP アドレスが足りないとプロキシが増えられない（RDS-EVENT-0243）とされ、db.*.xlarge 以下の DB で 10 個、2xlarge で 15 個などを空けておく目安が示されています。セキュリティグループの操作は、関連記事「AWS CLIでセキュリティグループ設定｜ルール追加・削除・確認」で扱っています。

プールの設定（ターゲットグループ）

cat > pool.json <<'EOF'
{"MaxConnectionsPercent": 80, "MaxIdleConnectionsPercent": 20,
 "ConnectionBorrowTimeout": 10, "InitQuery": "SET TIME ZONE 'Asia/Tokyo'"}
EOF
aws rds modify-db-proxy-target-group --db-proxy-name app-proxy --target-group-name default \
  --connection-pool-config file://pool.json

DB を管理ツールやバッチからも直接使うなら、MaxConnectionsPercent を 100 より下げて、その分の接続を残します。 moto では InitQuery は保存されず、ほかの 3 つの値だけが返りました。

Lambda から接続するコード

import json, os
import boto3
import psycopg

DB_HOST = os.environ["DB_HOST"]             # RDS Proxy のエンドポイント
DB_PORT = int(os.environ.get("DB_PORT", "5432"))
DB_NAME = os.environ.get("DB_NAME", "app")
SECRET_ID = os.environ.get("DB_SECRET_ID")  # パスワード認証のとき
DB_USER = os.environ.get("DB_USER", "app_user")
USE_IAM = os.environ.get("DB_IAM_AUTH") == "1"
SSLMODE = os.environ.get("DB_SSLMODE", "require")

_conn = None   # 実行環境が再利用される間、接続を使い回す


def _password() -> tuple[str, str]:
    if USE_IAM:   # IAM 認証：15 分有効のトークンをパスワードとして使う
        rds = boto3.client("rds")
        return DB_USER, rds.generate_db_auth_token(
            DBHostname=DB_HOST, Port=DB_PORT, DBUsername=DB_USER)
    secret = boto3.client("secretsmanager").get_secret_value(SecretId=SECRET_ID)
    s = json.loads(secret["SecretString"])
    return s["username"], s["password"]


def _connect():
    user, password = _password()
    return psycopg.connect(
        host=DB_HOST, port=DB_PORT, dbname=DB_NAME, user=user, password=password,
        sslmode=SSLMODE, connect_timeout=5,
        prepare_threshold=None,   # サーバー側のプリペアドステートメントを使わない（ピン留めを避ける）
        autocommit=True,
    )


def get_conn():
    global _conn
    if _conn is None or _conn.closed:
        _conn = _connect()
    return _conn


def lambda_handler(event, context):
    try:
        conn = get_conn()
        rows = conn.execute("SELECT id, item FROM orders ORDER BY id LIMIT %s", (event.get("limit", 10),)).fetchall()
    except psycopg.OperationalError:
        # プロキシのアイドルタイムアウトなどで切れていたら 1 回だけつなぎ直す
        global _conn
        _conn = None
        rows = get_conn().execute("SELECT id, item FROM orders ORDER BY id LIMIT %s", (event.get("limit", 10),)).fetchall()
    return {"count": len(rows), "items": [r[1] for r in rows], "backend_pid": get_conn().info.backend_pid}

moto の Secrets Manager に入れたパスワードで、PostgreSQL にハンドラーを3回続けて呼んだ結果です。

1 {'count': 2, 'items': ['apple', 'banana'], 'backend_pid': 7029}
2 {'count': 2, 'items': ['apple', 'banana'], 'backend_pid': 7029}
3 {'count': 2, 'items': ['apple', 'banana'], 'backend_pid': 7029}

同じ実行環境の中では、1回目に作った接続（同じ backend_pid）が使い回されました。プロキシ経由では、トランザクションごとに DB 側の接続が入れ替わることがあります（多重化）。

例のアクセスキーで作った IAM 認証トークンの形です（改行は見やすくするため）。ホスト名はプロキシのエンドポイントにします。

app-proxy.proxy-abcdefghijkl.ap-northeast-1.rds.amazonaws.com:5432/?Action=connect
  &DBUser=app_user
  &X-Amz-Algorithm=AWS4-HMAC-SHA256
  &X-Amz-Credential=AKIAIOSFODNN7EXAMPLE%2F20261013%2Fap-northeast-1%2Frds-db%2Faws4_request
  &X-Amz-Date=20261013T040646Z
  &X-Amz-Expires=900
  &X-Amz-SignedHeaders=host
  &X-Amz-Signature=61bff97f...

Lambda の実行ロールには、プロキシへの接続を許すポリシーを付けます。リソースはプロキシの ID（prx-）と DB ユーザー名です。

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

Lambda の作成とデプロイは、関連記事「AWS CLIでLambdaを作成・更新 環境変数とレイヤー」で扱っています。

ピン留め（pinning）の原因一覧

ピン留めは、プロキシが「この接続は使い回すと危ない」と判断し、クライアントのセッションが終わるまで DB 接続を1つ占有させる動きです。 ピン留めされたセッションが多いと、DB の接続数はプロキシが無いときと変わらなくなります。

ピン留めにならないもの：ストアドプロシージャ・関数の呼び出し（中でセッションの状態を変えても、プロキシは追いません）、MySQL の SET LOCAL。

ドライバーが自動でピン留めの原因を作る例

psycopg 3 は、同じ SQL を 5 回実行すると、6 回目からサーバー側のプリペアドステートメントを作ります（prepare_threshold の既定 5）。PostgreSQL で同じ SQL を6回実行し、pg_prepared_statements を見た結果です。

import psycopg
dsn = "host=127.0.0.1 port=5437 dbname=app user=app_user password=..."
for th in (5, None):
    with psycopg.connect(dsn, prepare_threshold=th) as conn:
        for i in range(6):
            conn.execute("SELECT item FROM orders WHERE id = %s", (1,)).fetchone()
        rows = conn.execute("SELECT name, statement FROM pg_prepared_statements").fetchall()
        print(f"prepare_threshold={th}: {rows}")

prepare_threshold=5: [('_pg3_0', 'SELECT item FROM orders WHERE id = $1')]
prepare_threshold=None: []

既定のままでは、セッションにプリペアドステートメント（_pg3_0）が作られました。RDS Proxy 経由では、これがピン留めの原因になります。prepare_threshold=None で作られなくなりました。

ピン留めを見つける

aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name DatabaseConnectionsCurrentlySessionPinned \
  --dimensions Name=ProxyName,Value=app-proxy \
  --start-time "$(date -u -d '1 hour ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Sum --output text

# 拡張ログ（調べる間だけ。SQL の中身もログに出る）
aws rds modify-db-proxy --db-proxy-name app-proxy --debug-logging

ClientConnections が多いのに DatabaseConnections が少なければ、多重化が効いています。2つが近く、SessionPinned が多ければ、ピン留めの原因を探します。

料金

単価はリージョンで違うので、料金ページか料金計算ツールで確かめます。月額の目安は「DB の vCPU 数 × vCPU 時間の単価 × 730 時間」です。例えば 2 vCPU の db.r6g.large につなぐなら、2 × 単価 × 730 になります。料金の確かめ方は、関連記事「AWSの料金を確認する方法｜Cost Explorer・CLI・予算アラート」で扱っています。

Aurora Serverless v2 で最小 0 ACU（自動一時停止）を使っているなら、RDS Proxy を付けると一時停止しなくなります。 プロキシが各インスタンスへの接続を保つためです（ドキュメント）。関連記事「Aurora Serverless v2の使い方｜ACUの決め方と0への自動停止」で扱っています。

上限と制限

よくある質問

Q. Lambda からなら、必ず RDS Proxy を使うべきですか。 A. Lambda のドキュメントでは、単純な使い方は直接接続、短い接続を何度も開け閉めする関数や本番には RDS Proxy が勧められています。同時実行数が小さく、DB の max_connections に余裕があるなら、予約済み同時実行数で上限を決める方法もあります。

Q. RDS Proxy を入れたら遅くなりませんか。 A. 1 つ中継が増えるので、1 回ごとの往復は少し増えます。一方で、新しい接続の TLS と認証の時間はプロキシ側で省けます。

Q. プロキシ経由の接続やクエリが、混んでいる時間だけタイムアウトします。 A. DB 接続が全部使われ、ConnectionBorrowTimeout を過ぎている可能性があります。DatabaseConnectionsBorrowLatency が伸びていないかを見ます。ピン留めが多い、トランザクションが長い、MaxConnectionsPercent が小さい、DB の max_connections が小さい、のどれかを見ます。

Q. 接続がしばらくすると切れます。 A. クライアントの接続は、IdleClientTimeout（既定 30 分）使われないと切られます。Lambda のコードのように、切れていたらつなぎ直す作りにします。

まとめ

• RDS Proxy は トランザクションごとに DB 接続を使い回す接続プール。Lambda の接続数の山をならす
• 作成は シークレット → IAM ロール → create-db-proxy → register-db-proxy-targets → SG
• 接続先は プロキシのエンドポイント、TLS 必須。IAM 認証なら rds-db:connect を prx-... に
• ピン留めの原因は SET・プリペアドステートメント・一時テーブル・ロック・16 KB 超の SQL など
• psycopg 3 は既定で 6 回目からプリペア。prepare_threshold=None で止める
• DatabaseConnectionsCurrentlySessionPinned でピン留めを見る
• 料金は DB の vCPU（Serverless v2 は ACU）× 時間。0 ACU の自動一時停止とは両立しない

参考・出典

確認日はいずれも 2026年10月13日です。

• Amazon RDS User Guide「Amazon RDS Proxy」（上限・制限）：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html
• Amazon RDS User Guide「RDS Proxy concepts and terminology」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.howitworks.html
• Amazon RDS User Guide「Creating a proxy for Amazon RDS」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-creating.html
• Amazon RDS User Guide「Setting up database credentials for RDS Proxy」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-secrets-arns.html
• Amazon RDS User Guide「Configuring IAM authentication for RDS Proxy」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-iam-setup.html
• Amazon RDS User Guide「Setting up network prerequisites for RDS Proxy」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-network-prereqs.html
• Amazon RDS User Guide「Connecting to a database through RDS Proxy」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-connecting.html
• Amazon RDS User Guide「Avoiding pinning an RDS Proxy」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-pinning.html
• AWS CLI Command Reference「rds modify-db-proxy-target-group」：https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-proxy-target-group.html
• AWS Lambda 開発者ガイド「Amazon RDS で AWS Lambda 使用する」：https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-database.html
• Amazon RDS Proxy の料金：https://aws.amazon.com/rds/proxy/pricing/
• クラスメソッド「RDS Proxyを使ってAWS LambdaからRDBにコネクションプールで接続する」：https://dev.classmethod.jp/articles/using-relational-databases-with-aws-lambda-easy-connection-pooling/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。