AWS Lambda から Amazon RDS for PostgreSQL への接続が "remaining connection slots are reserved" で失敗します。同時実行と max_connections の見積もり方を教えてください
困っていること
AWS Lambda の関数から、Amazon RDS for PostgreSQL の DB インスタンスに接続しています。
アクセスが増えると、次のエラーで接続が拒否されるようになりました。
remaining connection slots are reserved for roles with privileges of the "rds_reserved" role
DB インスタンスの CPU とメモリには余裕があります。
原因と、max_connections に合わせて Lambda の同時実行数をどう見積もればよいかを知りたいです。
どう対応すればいいの？
Lambda 関数に予約済み同時実行数を設定して、関数の同時実行数に上限を設けてください。
Lambda からの接続数の合計が、「max_connections から、予約済み接続スロットの数と Lambda 以外の接続数を引いた数」 に収まるようにします。
同時実行数を絞ると処理が追いつかない場合は、Amazon RDS Proxy を使います（手順 4）。
max_connections のうち一部の接続スロットは、スーパーユーザーや RDS の管理用のロールのために予約されています。
それ以外の接続スロットがすべて埋まると、予約済み接続スロットを使えないユーザーの接続は拒否されます。
予約済み接続スロットの数は、rds.rds_reserved_connections パラメータによって決まります。Amazon RDS 予約済み接続スロットの数を考慮して、max_connections パラメータの値を調整する必要が生じる場合があります。
rds.rds_reserved_connections による予約済み接続スロットは、17.1・16.5・15.9・14.14・13.17・12.21 以降のバージョンで有効です。
Lambda は、同時に処理するリクエストごとに、実行環境を 1 つずつ用意します。
Lambda は、同時実行リクエストごとに、実行環境の個別のインスタンスをプロビジョニングします。
ハンドラーの外で接続を作成し、呼び出しをまたいで再利用する実装では、実行環境ごとに接続を持ち続けます。そのため、同時実行数が増えた分だけ、DB への接続数も増えます。
予約済み同時実行数を設定していない関数は、アカウントの同時実行数のクォータ（デフォルトで 1,000）までスケールすることがあります。
次の手順で見積もり、上限を設定してください。
SHOW max_connectionsで max_connections を確認します。予約済み接続スロットの数は、superuser_reserved_connectionsとrds.rds_reserved_connectionsを SHOW で確認します。PostgreSQL 16 以降では、reserved_connectionsも確認します。カスタムのパラメータグループで値を変更している場合は、RDS のコンソールの「パラメータグループ」でも確認できます。
- max_connections から、予約済み接続スロットの数と、Lambda 以外の接続数（バッチ処理や管理用のツールなど）を引きます。残りが、Lambda に割り当てられる接続数です。これを実行環境ごとの接続数（接続プールを使う場合は、プールの最大接続数）で割った値が、同時実行数の上限です。関数が複数あるときは、すべての関数の接続数の合計がこの数に収まるようにします。
- 例：max_connections が 100、予約済み接続スロットが 9（下の検証の値）、Lambda 以外の接続が 10 本なら、100 − 9 − 10 = 81 本です。
- 例：実行環境ごとの接続が 1 本なら上限は 81、プールの最大接続数が 5 なら 81 ÷ 5 = 16.2 を切り捨てて 16 です。
- Lambda のコンソールの「Event Functions」で関数を開き、「設定」タブの「同時実行」で「編集」を選びます。「同時実行を編集」の画面で「同時実行の予約」を選び、手順 2 で求めた値以下の値を入力して「保存」を選びます。
画面の 5 は、項目の位置を示すために入力した値です。同時実行数のクォータが 10 の検証用のアカウントでは、この値は保存できません（画面には「予約されていないアカウントの同時実行数: 5」と表示されました）。
- 同時実行数を絞ると処理が追いつかない場合は、RDS Proxy を使います。
予約済み同時実行数は、DB の接続のようなダウンストリームのリソースを保護する目的にも使えます。
さらに、予約済同時実行数は、データベース接続などのダウンストリームリソースが過負荷になるのを防ぐために同時実行を制限するために使用できます。
RDS Proxy は、複数の実行環境からの接続を、共有の接続プールにまとめます。そのため、DB の接続を使い切らずに、同時実行数を上げられます。
データベースプロキシは、共有されたデータベース接続のプールを管理します。これを使用することで、データベース接続を消耗することなく、関数の同時実行レベルを上げることができます。
設定した後は、アクセスが多い時間帯の CloudWatch メトリクス DatabaseConnections（最大）が、max_connections から予約済み接続スロットの数を引いた数（例では 91）に、余裕を持って収まっていることを確認します。このメトリクスには、Lambda 以外の接続も含まれます。
Lambda のログに、接続のエラーが出ていないことも確認してください。
注意点は次のとおりです。
- 関数の同時実行数が予約済み同時実行数に達すると、それを超える呼び出しはスロットリングされます。同期呼び出しでは、呼び出し側に 429 のエラー（TooManyRequestsException）が返ります。指数バックオフとジッターを入れ、回数に上限を付けて再試行してください。非同期呼び出しでは、Lambda が自動で再試行します。
- 「予約されていないアカウントの同時実行」は、100 以上残す必要があります。そのため、予約できるのは、「予約されていないアカウントの同時実行」から 100 を引いた値までです。新しいアカウントでは同時実行数のクォータが低く、使用状況に応じて AWS が自動で引き上げます。検証用のアカウントのクォータは 10 でした。
- RDS Proxy には、DB インスタンスの vCPU 数に応じた 1 時間あたりの料金がかかります（2026 年 10 月時点）。
確認してみた
東京リージョンの RDS for PostgreSQL 18.3 の DB インスタンスで、max_connections を 20 にして試しました。
予約済み接続スロットは合計 9 でした。内訳は、superuser_reserved_connections が 3、reserved_connections が 2、rds.rds_reserved_connections が 4 です。
手元の端末からマスターユーザーで接続を 1 本ずつ増やすと、11 本目までは接続できました。
12 本目は、冒頭と同じ remaining connection slots are reserved for roles with privileges of the "rds_reserved" role のエラーで拒否されました。
11 本は、20 から予約済み接続スロットの合計 9 を引いた数です。この検証では、マスターユーザーでも予約済み接続スロットは使えませんでした。
