RDS Proxy のスタート方法

以下のセクションでは、RDS Proxy のセットアップおよび管理方法について説明します。また、関連するセキュリティオプションの設定方法が記載されています。これらのオプションは、各プロキシにアクセスできるユーザーと、各プロキシから DB インスタンスに接続する方法を制御します。

ネットワーク前提条件の設定

RDS Proxy を使用するには、Aurora DB クラスターと RDS Proxy の間に、共通の仮想プライベートクラウド (VPC) が必要です。この VPC には、異なるアベイラビリティーゾーンにあるサブネットが 2 つ以上必要です。アカウントは、これらのサブネットを所有することも、他のアカウントと共有することもできます。VPC 共有の詳細については、共有 VPC の操作を参照してください。

Amazon EC2、Lambda、Amazon ECS などのクライアントアプリケーションリソースは、プロキシと同じ VPC に置くことができます。または、プロキシとは別の VPC に置くこともできます。 Aurora DB クラスターに正常に接続できた場合は、既に必要なネットワークリソースが存在します。

トピック

• サブネット情報の取得
• IP アドレス容量の計画

サブネット情報の取得

Aurora の使用を開始したばかりの場合は、「Amazon Aurora の環境をセットアップする」の手順に従って、データベースに接続するための基本を学習できます。「Amazon Aurora の開始方法」のチュートリアルに従うこともできます。

プロキシを作成するには、プロキシが動作するサブネットと VPC を指定する必要があります。次の Linux の例は、AWS アカウント が所有する VPC とサブネットを調べる AWS CLI コマンドを示しています。特に、CLI を使用してプロキシを作成するときは、サブネット ID をパラメータとして渡します。

aws ec2 describe-vpcs
aws ec2 describe-internet-gateways
aws ec2 describe-subnets --query '*[].[VpcId,SubnetId]' --output text | sort

次の Linux の例は、特定の Aurora DB クラスターに対応するサブネット ID を決定する AWS CLI コマンドを示しています。

Aurora クラスターの場合は、まず、関連付けられた DB インスタンスの 1 つの ID を見つけます。その DB インスタンスで使用されているサブネット ID を抽出できます。そのためには、DB インスタンスの describe 出力で、DBSubnetGroup とSubnets 属性内のネストされたフィールドを調べます。データベースサーバーのプロキシを設定するときに、それらのサブネット ID の一部またはすべてを指定します。

$ # Find the ID of any DB instance in the cluster.
$  aws rds describe-db-clusters --db-cluster-identifier my_cluster_id --query '*[].[DBClusterMembers]|[0]|[0][*].DBInstanceIdentifier' --output text

my_instance_id
instance_id_2
instance_id_3

DB インスタンス識別子を見つけたら、関連する VPC を調べて、そのサブネットを見つけます。次の Linux の例は、その方法を示しています。

$ #From the DB instance, trace through the DBSubnetGroup and Subnets to find the subnet IDs.
$ aws rds describe-db-instances --db-instance-identifier my_instance_id --query '*[].[DBSubnetGroup]|[0]|[0]|[Subnets]|[0]|[*].SubnetIdentifier' --output text

subnet_id_1
subnet_id_2
subnet_id_3
...

$ #From the DB instance, find the VPC.
$ aws rds describe-db-instances --db-instance-identifier my_instance_id --query '*[].[DBSubnetGroup]|[0]|[0].VpcId' --output text

my_vpc_id

$ aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc_id --query '*[].[SubnetId]' --output text

subnet_id_1
subnet_id_2
subnet_id_3
subnet_id_4
subnet_id_5
subnet_id_6

IP アドレス容量の計画

RDS Proxy は、登録されている DB インスタンスのサイズと数に基づき、必要に応じて自動的に容量を調整します。特定の操作には、登録されたデータベースのサイズの増加や内部 RDS Proxy メンテナンス操作など、プロキシ容量の追加が必要になる場合もあります。これらのオペレーション中、プロキシは追加の容量をプロビジョニングするため、より多くの IP アドレスを必要とする場合があります。これらの追加アドレスによって、ワークロードに影響を与えずにプロキシを拡張できます。サブネットに空き IP アドレスがない場合、プロキシのスケールアップはできません。そのため、クエリの待ち時間が長くなったり、クライアント接続が失敗したりする可能性があります。サブネットに十分な空きの IP アドレスがないと、RDS はイベント RDS-EVENT-0243 を通じて通知します。このイベントのフィールドの詳細については、「RDS Proxy イベントの使用」を参照してください。

以下は、DB インスタンスのクラスサイズに基づいて、プロキシ用としてサブネットで未使用のままにすべき最小の IP アドレス数の推奨値です。

DB インスタンスクラス	IP アドレスの最小値
db.*.xlarge 以下	10
db.*.2xlarge	15
db.*.4xlarge	25
db.*.8xlarge	45
db.*.12xlarge	60
db.*.16xlarge	75
db.*.24xlarge	110

これらの推奨 IP アドレス数は、デフォルトのエンドポイントのみを使用するプロキシの推定値です。エンドポイントまたはリードレプリカを追加したプロキシには、さらに多くの空き IP アドレスが必要になる場合があります。エンドポイントを追加するたびに、追加で 3 つの IP アドレスを予約することをお勧めします。各リードレプリカに、そのリードレプリカのサイズに基づき、表に指定された IP アドレスを追加で予約することをお勧めします。

注記

RDS Proxy は、VPC 内で 215 を超える IP アドレスをサポートしていません。

例えば、Aurora DB クラスターに関連付けられるプロキシに必要な IP アドレスを見積もるとします。

この場合、次のように仮定します。

• Aurora DB クラスターには、サイズが db.r5.8xlarge のライターインスタンスが 1 つと、サイズが db.r5.2xlarge のリーダーインスタンスが 1 つあります。

• この DB クラスターに接続されているプロキシには、デフォルトのエンドポイントと、読み取り専用ロールのカスタムエンドポイントが 1 つずつあります。

この場合、プロキシには約 63 個の空き IP アドレスが必要です (ライターインスタンス用に 45 個、リーダーインスタンス用に 15 個、追加のカスタムエンドポイント用に 3 個)。

AWS Secrets Manager でのデータベース認証情報の設定

作成するプロキシごとに、まず Secrets Manager サービスを使用してユーザー名およびパスワード認証情報のセットを保存します。Aurora DB クラスターで、プロキシの接続先のデータベースユーザーアカウントごとに個別の Secrets Manager シークレットを作成します。

Secrets Manager コンソールでは、username および password フィールドの値を使用してこれらのシークレットを作成します。これにより、プロキシに関連付けた Aurora DB クラスターの対応するデータベースユーザーにプロキシから接続できます。これを行うには、[他のデータベース認証情報]、[RDS データベース認証情報]、[他の種類のシークレット] のいずれかの設定を使用します。[ユーザー名] フィールドと [パスワード] フィールドに適切な値を入力し、その他の必須フィールドに値を入力します。プロキシは、ホスト や ポート などの他のフィールド (シークレット内に存在する場合) を無視します。これらの詳細は、プロキシによって自動的に提供されます。

[その他のタイプのシークレット] を選択することもできます。この場合、username と password という名前のキーを使用してシークレットを作成します。

プロキシが使用するシークレットは特定のデータベースサーバーには関連しないため、複数のプロキシでシークレットを再利用できます。そのためには、複数のデータベースサーバーで同じ認証情報を使用します。例えば、開発サーバーとテストサーバーで同じ認証情報を使用できます。

特定のデータベースユーザーとしてプロキシ経由で接続するには、シークレットに関連付けられているパスワードが、そのユーザーのデータベースパスワードと一致していることを確認してください。不一致がある場合は、Secrets Manager で該当するシークレットを更新できます。この場合でも、シークレットの認証情報とデータベースパスワードが一致する他のアカウントには接続できます。

AWS CLI または RDS API を通じてプロキシを作成する場合、対応するシークレットの Amazon リソースネーム (ARN) を指定します。プロキシがアクセスできるすべての DB ユーザーアカウントに対し、同じように操作します。AWS Management Console では、シークレットをそのわかりやすい名前を使用して選択します。

Secrets Manager でシークレットを作成する手順については、Secrets Manager ドキュメントのシークレットの作成ページを参照してください。次のいずれかの方法を使用します。

• コンソールで Secrets Manager を使用します。

• CLI を使用して RDS Proxy 用の Secrets Manager シークレットを作成するには、次のようなコマンドを使用します。

  aws secretsmanager create-secret
    --name "secret_name"
    --description "secret_description"
    --region region_name
    --secret-string '{"username":"db_user","password":"db_user_password"}'

例えば、以下のコマンドは、2 つのデータベースユーザーの Secrets Manager シークレットを作成します。1 つは admin という名前で、もう 1 つはapp-user という名前です。

aws secretsmanager create-secret \
  --name admin_secret_name --description "db admin user" \
  --secret-string '{"username":"admin","password":"choose_your_own_password"}'

aws secretsmanager create-secret \
  --name proxy_secret_name --description "application user" \
  --secret-string '{"username":"app-user","password":"choose_your_own_password"}'

AWS アカウントが所有する秘密を確認するには、次のようなコマンドを使用します。

aws secretsmanager list-secrets

CLI を使用してプロキシを作成する場合、1 つ以上のシークレットの Amazon リソースネーム (ARN) を --auth パラメータに渡します。次の Linux の例は、AWS アカウントが所有する各シークレットの名前と ARN のみを含むレポートを準備する方法を示しています。この例では、--output table バージョン 2 で使用可能な AWS CLI パラメータを使用します。AWS CLI バージョン 1 を使用している場合は、代わりに --output text を使用します。

aws secretsmanager list-secrets --query '*[].[Name,ARN]' --output table

シークレットに正しい資格情報を正しい形式で格納したことを確認するには、次のようなコマンドを使用します。your_secret_name は、短縮名またはシークレットの ARN に置き換えます。

aws secretsmanager get-secret-value --secret-id your_secret_name

出力には、次のような JSON でエンコードした値を表示する行を含める必要があります。

"SecretString": "{\"username\":\"your_username\",\"password\":\"your_password\"}",

AWS Identity and Access Management (IAM) ポリシーの設定

Secrets Manager でシークレットを作成したら、これらのシークレットにアクセスできる IAM ポリシーを作成します。IAM の使用に関する一般情報については、「Amazon Aurora での Identity and Access Management」を参照してください。

ヒント

以下の手順は、IAM コンソールを使用する場合に適用されます。RDS に AWS Management Console を使用する場合は、RDS によって自動的に IAM ポリシーが作成されます。その場合は、以下の手順を省略できます。

プロキシで使用する Secrets Manager シークレットにアクセスするための IAM ポリシーを作成するには

1. IAM コンソールにサインインします。「IAM ロールの作成」で説明されているロールの作成プロセスに従い、[AWS のサービスにアクセス許可を委任するロールの作成] を選択します。

   [信頼されたエンティティタイプ] で、[AWS サービス] を選択します。[ユースケース] で、[他の AWS サービスのユースケース] ドロップダウンから [RDS] を選択します。[RDS – ロールをデータベースに追加する] を選択します。

2. 新しいロールの場合は、インラインポリシーを追加するステップを実行します。「IAM ポリシーの編集」と同じ一般的な手順を使用します。以下の JSON を [JSON] テキストボックスに貼り付けます。自分のアカウント ID に置き換えます。AWS リージョンを us-east-2 に置き換えてください。作成したシークレットの Amazon リソースネーム (ARN) を置き換えます。「IAM ポリシーステートメントで KMS キーを指定する」を参照してください。kms:Decrypt アクションには、デフォルトの AWS KMS key の ARN または独自の KMS キーに置き換えてください。どちらを使用するかは、Secrets Manager のシークレットの暗号化に使用されたものによって決まります。

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "VisualEditor0",
               "Effect": "Allow",
               "Action": "secretsmanager:GetSecretValue",
               "Resource": [
                   "arn:aws:secretsmanager:us-east-2:account_id:secret:secret_name_1",
                   "arn:aws:secretsmanager:us-east-2:account_id:secret:secret_name_2"
               ]
           },
           {
               "Sid": "VisualEditor1",
               "Effect": "Allow",
               "Action": "kms:Decrypt",
               "Resource": "arn:aws:kms:us-east-2:account_id:key/key_id",
               "Condition": {
                   "StringEquals": {
                       "kms:ViaService": "secretsmanager.us-east-2.amazonaws.com"
                   }
               }
           }
       ]
   }
   

3. この IAM ロールの信頼ポリシーを編集します。以下の JSON を [JSON] テキストボックスに貼り付けます。

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "",
         "Effect": "Allow",
         "Principal": {
           "Service": "rds.amazonaws.com"
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }

次のコマンドは、AWS CLI で同じ操作を実行します。

PREFIX=my_identifier
USER_ARN=$(aws sts get-caller-identity --query "Arn" --output text) 

aws iam create-role --role-name my_role_name \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":["rds.amazonaws.com"]},"Action":"sts:AssumeRole"}]}'

ROLE_ARN=arn:aws:iam::account_id:role/my_role_name

aws iam put-role-policy --role-name my_role_name \
  --policy-name $PREFIX-secret-reader-policy --policy-document '{"Version":"2012-10-17","Statement":[{"Sid":"getsecretvalue","Effect":"Allow","Action":["secretsmanager:GetSecretValue","kms:Decrypt"],"Resource":"*"}]}'

aws kms create-key --description "$PREFIX-test-key" --policy '{
  "Id":"$PREFIX-kms-policy",
  "Version":"2012-10-17",
  "Statement":
    [
      {
        "Sid":"Enable IAM User Permissions",
        "Effect":"Allow",
        "Principal":{"AWS":"arn:aws::iam:account_id:root"},
        "Action":"kms:*","Resource":"*"
      },
      {
        "Sid":"Allow access for Key Administrators",
        "Effect":"Allow",
        "Principal":
          {
            "AWS":
              ["$USER_ARN","arn:aws::iam:account_id:role/Admin"]
          },
        "Action":
          [
            "kms:Create*",
            "kms:Describe*",
            "kms:Enable*",
            "kms:List*",
            "kms:Put*",
            "kms:Update*",
            "kms:Revoke*",
            "kms:Disable*",
            "kms:Get*",
            "kms:Delete*",
            "kms:TagResource",
            "kms:UntagResource",
            "kms:ScheduleKeyDeletion",
            "kms:CancelKeyDeletion"
          ],
        "Resource":"*"
      },
      {
        "Sid":"Allow use of the key",
        "Effect":"Allow",
        "Principal":{"AWS":"$ROLE_ARN"},
        "Action":["kms:Decrypt","kms:DescribeKey"],
        "Resource":"*"
      }
    ]
}'

RDS Proxy の作成

DB クラスターに対する接続を管理するには、プロキシを作成します。プロキシは、Aurora MySQL または Aurora PostgreSQL DB クラスターに関連付けることができます。

AWS Management Console

プロキシを作成するには

1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

2. ナビゲーションペインで、[プロキシ] を選択します。

3. [Create proxy (プロキシの作成)] を選択します。

4. プロキシのすべての設定を選択します。

   [プロキシの設定] で、以下の情報を提供します。

   • エンジンファミリー。この設定は、データベースとの間で送受信されるネットワークトラフィックを解釈するときに、プロキシが認識するデータベースネットワークプロトコルを決定します。Aurora MySQL の場合は、[MariaDB and MySQL] (MariaDB と MySQL) を選択します。Aurora PostgreSQL の場合は、[PostgreSQL] を選択します。

   • プロキシ識別子。AWS アカウント ID と現在の AWS リージョン内で一意の名前を指定します。

   • アイドル状態のクライアント接続のタイムアウト。プロキシがクライアント接続を閉じるまでに接続がアイドル状態を継続できる時間を選択します。デフォルトは 1,800 秒 (30 分) です。クライアント接続がアイドル状態と見なされるのは、前のリクエストの完了後、新しいリクエストが指定時間内にアプリケーションから送信されない場合です。基となるデータベース接続は開いたままで、接続プールに返されるため、新しいクライアント接続で再利用できます。

     プロキシで古い接続を事前に削除するには、クライアント接続でのアイドル状態のタイムアウトを短くします。ワークロードがスパイクしているときは、接続を確立するコストを節約するために、アイドル状態のクライアント接続のタイムアウトを長くします。

   [ターゲットグループの設定] で、以下の情報を提供します。

   • データベース。このプロキシを介してアクセスする Aurora DB クラスターを 1 つ選択します。このリストには、互換性のあるデータベースエンジン、エンジンバージョン、および他の設定を持つ DB インスタンスとクラスターのみが含まれます。リストが空の場合は、RDS Proxy と互換性のある新しい DB インスタンスまたはクラスターを作成します。これを行うには、「Amazon Aurora DB クラスターの作成」の手順に従います。次に、プロキシの作成をもう一度試します。

   • 接続プールの最大接続数。1～100 の値を指定します。この設定は、RDS Proxy が接続に使用できる max_connections 値の割合 (%) を表します。この DB インスタンスまたはクラスターで 1 つのプロキシのみを使用する場合は、この値を 100 に設定できます。この設定を RDS Proxy で使用する方法の詳細については、「MaxConnectionsPercent」を参照してください。

   • セッションの固定フィルター。(オプション) このオプションを使用すると、検出された特定のタイプのセッション状態に対して RDS プロキシが PIN されないようにすることができます。これにより、クライアント接続間でデータベース接続を多重化するというデフォルトの安全対策が回避されます。現在、設定は PostgreSQL についてはサポートされていません。唯一の選択肢は EXCLUDE_VARIABLE_SETS です。

     この設定を有効にすると、ある接続のセッション変数が他の接続に影響を与える可能性があります。これにより、クエリが現在のトランザクション以外に設定されたセッション変数値に依存している場合、エラーや正確性の問題が発生する可能性があります。アプリケーションがクライアント接続間でデータベース接続を共有しても安全であることを確認した後に、このオプションの使用を検討してください。

     以下のパターンは安全だと考えられます。

     • 有効なセッション変数値に変更がない、つまりセッション変数に変更がない SET ステートメント。

     • セッション変数の値を変更し、同じトランザクションでステートメントを実行します。

     詳細については、「固定を回避する」を参照してください。

   • 接続の借用タイムアウト。場合によっては、利用可能なすべてのデータベース接続をプロキシが使い切ることがあります。このような場合、プロキシがタイムアウトエラーを返す前に、データベース接続が使用可能になるまで待つ時間を指定できます。最大 5 分の期間を指定できます。この設定は、プロキシで最大数の接続が開いていて、すべての接続が既に使用されている場合にのみ適用されます。

   • 初期化クエリ。(オプション) 新しい各データベース接続を開くときに実行するプロキシ用の 1 つ以上の SQL ステートメントを指定できます。設定は通常、各接続のタイムゾーンや文字セットなどの設定が同一であることを確認するために、SET ステートメントとともに使用されます。複数のステートメントの場合は、セミコロンをセパレータとして使用します。例えば、1 つの SET ステートメントに SET x=1, y=2 など複数の可変を含めることもできます。

   [Authentication] (認証) には、次の情報を入力します。

   • IAM ロール。前に選択した Secrets Manager シークレットに対するアクセス許可のある IAM ロールを選択します。または、AWS Management Console から新しい IAM ロールを作成することもできます。

   • Secrets Manager シークレット。プロキシが Aurora DB クラスターにアクセスできるようにするデータベースユーザー認証情報を含む Secrets Manager シークレットを少なくとも 1 つ選択します。

   • クライアント承認タイプ。プロキシがクライアントからの接続に使用する認証タイプを選択します。選択した内容は、このプロキシに関連付けるすべての Secrets Manager シークレットに適用されます。シークレットごとに異なるクライアント認証タイプを指定する必要がある場合は、代わりに AWS CLI または API を使用してプロキシを作成します。

   • IAM 認証。プロキシへの接続に対し、IAM 認証の要求、拒否のいずれかを選択します。選択した内容は、このプロキシに関連付けるすべての Secrets Manager シークレットに適用されます。シークレットごとに異なる IAM 認証を指定する必要がある場合は、代わりに AWS CLI または API を使用してプロキシを作成します。

   [接続] で、以下の情報を提供します。

   • Transport Layer Security が必要。プロキシですべてのクライアント接続に対して TLS/SSL を適用する場合は、この設定を選択します。プロキシへの暗号化された接続または暗号化されていない接続を使用すると、プロキシは基となるデータベースへの接続時に同じ暗号化設定を使用します。

   • サブネット。このフィールドには、VPC に関連付けられたすべてのサブネットがあらかじめ入力されています。このプロキシに不要なサブネットは削除できます。少なくとも 2 つのサブネットを残す必要があります。

   追加の接続設定を定義します。

   • VPC セキュリティグループ。既存の VPC セキュリティグループを選択します。または、AWS Management Console から新しいセキュリティグループを作成することもできます。アプリケーションがプロキシにアクセスできるようにインバウンドルールを設定する必要があります。また、DB ターゲットからのトラフィックを許可するようにアウトバウンドルールを設定する必要があります。

     注記

     このセキュリティグループは、プロキシからデータベースへの接続を許可する必要があります。同じセキュリティグループが、アプリケーションからプロキシへのイングレスと、プロキシからデータベースへのエグレスに使用されます。例えば、データベースとプロキシに同じセキュリティグループを使用するとします。この場合は必ず、そのセキュリティグループ内のリソースが同じセキュリティグループ内の他のリソースと通信できるように指定してください。

     共有 VPC を使用する場合、VPC のデフォルトのセキュリティグループや、別のアカウントに属しているセキュリティグループを使用することはできません。自分のアカウントに属しているセキュリティグループを選択します。存在しない場合は、作成します。この制限事項の詳細については、共有 VPC の操作を参照してください。

     RDS は、高可用性を確保するために複数のアベイラビリティーゾーンにプロキシをデプロイします。このようなプロキシでクロス AZ 通信を有効にするには、プロキシサブネットのネットワークアクセスコントロールリスト (ACL) で、エンジンポート固有のエグレスとすべてのポートのイングレスを許可する必要があります。ネットワーク ACL の詳細については、「ネットワーク ACL を使用してサブネットへのトラフィックを制御する」を参照してください。プロキシとターゲットのネットワーク ACL が同じである場合は、ソースを VPC CIDR に設定した、TCP プロトコルイングレスルールを追加する必要があります。また、ソースを VPC CIDR に設定した、エンジンポート固有の TCP プロトコルエグレスルールも追加する必要があります。

   (オプション) 詳細設定を定義します。

   • 拡張ログ記録の有効化。この設定を有効にして、プロキシの互換性やパフォーマンスの問題のトラブルシューティングを行うことができます。

     この設定を有効にすると、RDS Proxy は SQL ステートメントに関する詳細情報をログに含めます。この情報に基づいて、SQL の動作やプロキシ接続のパフォーマンスとスケーラビリティに関する問題をデバッグできます。デバッグ情報には、プロキシ経由で送信する SQL ステートメントのテキストが含まれます。したがって、この設定を有効にするのは、デバッグのため、またはログ内の機密情報を保護するセキュリティ対策がある場合に限ります。

     プロキシに関連するオーバーヘッドを最小限に抑えるために、この設定は有効にしてから 24 時間後に RDS Proxy によって自動的にオフにされます。特定の問題のトラブルシューティングを行うには、その設定を一時的に有効にします。

5. [Create proxy (プロキシの作成)] を選択します。

AWS CLI

AWS CLI を使用してプロキシを作成するには、以下の必須パラメータを指定して create-db-proxy コマンドを呼び出します。

• --db-proxy-name

• --engine-family

• --role-arn

• --auth

• --vpc-subnet-ids

--engine-family 値では、大文字と小文字が区別されます。

例

Linux、macOS、Unix の場合:

aws rds create-db-proxy \
    --db-proxy-name proxy_name \
    --engine-family { MYSQL | POSTGRESQL | SQLSERVER } \
    --auth ProxyAuthenticationConfig_JSON_string \
    --role-arn iam_role \
    --vpc-subnet-ids space_separated_list \
    [--vpc-security-group-ids space_separated_list] \
    [--require-tls | --no-require-tls] \
    [--idle-client-timeout value] \
    [--debug-logging | --no-debug-logging] \
    [--tags comma_separated_list]

Windows の場合:

aws rds create-db-proxy ^
    --db-proxy-name proxy_name ^
    --engine-family { MYSQL | POSTGRESQL | SQLSERVER } ^
    --auth ProxyAuthenticationConfig_JSON_string ^
    --role-arn iam_role ^
    --vpc-subnet-ids space_separated_list ^
    [--vpc-security-group-ids space_separated_list] ^
    [--require-tls | --no-require-tls] ^
    [--idle-client-timeout value] ^
    [--debug-logging | --no-debug-logging] ^
    [--tags comma_separated_list]

以下は、--auth オプションの JSON 値の例です。この例では、各シークレットに異なるクライアント認証タイプを適用します。

[
  {
    "Description": "proxy description 1",
    "AuthScheme": "SECRETS",
    "SecretArn": "arn:aws:secretsmanager:us-west-2:123456789123:secret/1234abcd-12ab-34cd-56ef-1234567890ab",
    "IAMAuth": "DISABLED",
    "ClientPasswordAuthType": "POSTGRES_SCRAM_SHA_256"
  },
  
  {
    "Description": "proxy description 2",
    "AuthScheme": "SECRETS",
    "SecretArn": "arn:aws:secretsmanager:us-west-2:111122223333:seret/1234abcd-12ab-34cd-56ef-1234567890cd",
    "IAMAuth": "DISABLED",
    "ClientPasswordAuthType": "POSTGRES_MD5"
    
  },
  
  {
    "Description": "proxy description 3",
    "AuthScheme": "SECRETS",
    "SecretArn": "arn:aws:secretsmanager:us-west-2:111122221111:secret/1234abcd-12ab-34cd-56ef-1234567890ef",
    "IAMAuth": "REQUIRED"
  }
  
]

ヒント

--vpc-subnet-ids パラメータに使用するサブネット ID がまだわからない場合は、「ネットワーク前提条件の設定」を使用して、ID を検索する方法の例を参照してください。

注記

セキュリティグループは、プロキシの接続先のデータベースへのアクセスを許可する必要があります。同じセキュリティグループが、アプリケーションからプロキシへのイングレスと、プロキシからデータベースへのエグレスに使用されます。例えば、データベースとプロキシに同じセキュリティグループを使用するとします。この場合は必ず、そのセキュリティグループ内のリソースが同じセキュリティグループ内の他のリソースと通信できるように指定してください。

共有 VPC を使用する場合、VPC のデフォルトのセキュリティグループや、別のアカウントに属しているセキュリティグループを使用することはできません。自分のアカウントに属しているセキュリティグループを選択します。存在しない場合は、作成します。この制限事項の詳細については、共有 VPC の操作を参照してください。

プロキシに適切な関連付けを作成するには、register-db-proxy-targets コマンドも使用します。ターゲットグループ名 default を指定します。RDS Proxy は、各プロキシを作成するときに、この名前のターゲットグループを自動的に作成します。

aws rds register-db-proxy-targets
    --db-proxy-name value
    [--target-group-name target_group_name]
    [--db-instance-identifiers space_separated_list]  # rds db instances, or
    [--db-cluster-identifiers cluster_id]        # rds db cluster (all instances)

RDS API

RDS Proxy を作成するには、Amazon RDS API オペレーション CreateDBProxy を呼び出します。AuthConfig データ構造でパラメータを渡します。

RDS Proxy は、各プロキシを作成するときに、default という名前のターゲットグループを自動的に作成します。RegisterDBProxyTargets 関数を呼び出して、このターゲットグループに Aurora DB クラスターを関連付けます。

RDS Proxy の表示

1 つまたは複数の RDS プロキシを作成すると、すべてのプロキシを表示できます。これにより、設定の詳細を確認して、変更や削除などを行う設定を選択できます。

データベースアプリケーションがプロキシを使用するためには、接続文字列でプロキシエンドポイントを指定する必要があります。

AWS Management Console

プロキシを表示するには

1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

2. AWS Management Console の右上隅で、RDS Proxy を作成した AWS リージョンを選択します。

3. ナビゲーションペインで、[プロキシ] を選択します。

4. 詳細を表示する RDS Proxy の名前を選択します。

5. 詳細ページの [ターゲットグループ] セクションに、プロキシと特定の Aurora DB クラスターとの関連付けが表示されます。[デフォルト] ターゲットグループページへのリンクに従って、プロキシとデータベースの関連付けの詳細を表示できます。このページでは、プロキシの作成時に指定した設定を確認できます。これには、最大接続数の割合 (%)、接続借用タイムアウト、エンジンファミリー、セッション固定フィルターが含まれます。

CLI

CLI を使用してプロキシを表示するには、describe-db-proxies コマンドを使用します。デフォルトでは、AWS アカウントが所有するすべてのプロキシが表示されます。単一のプロキシの詳細を表示するには、 --db-proxy-name パラメータで名前を指定します。

aws rds describe-db-proxies [--db-proxy-name proxy_name]

プロキシに関連付けられた他の情報を表示するには、以下のコマンドを使用します。

aws rds describe-db-proxy-target-groups  --db-proxy-name proxy_name

aws rds describe-db-proxy-targets --db-proxy-name proxy_name

プロキシに関連付けられている情報の詳細を表示するには、次のコマンドのシーケンスを使用します。

1. プロキシのリストを取得するには、describe-db-proxies を実行します。

2. プロキシが使用できる接続の最大割合などの接続パラメータを表示するには、describe-db-proxy-target-groups --db-proxy-name を実行します。プロキシの名前をパラメータ値として使用します。

3. 返されたターゲットグループに関連付けられている Aurora DB クラスターの詳細を表示するには、describe-db-proxy-targets を実行します。

RDS API

RDS API を使用してプロキシを表示するには、DescribeDBProxies オペレーションを使用します。DBProxy データ型の値が返されます。

プロキシの接続設定の詳細を表示するには、この戻り値のプロキシ識別子を DescribeDBProxyTargetGroups オペレーションで使用します。DBProxyTargetGroup データ型の値が返されます。

プロキシに関連付けられている RDS インスタンスや Aurora DB クラスターを表示するには、DescribeDBProxyTargets オペレーションを使用します。DBProxyTarget データ型の値が返されます。

RDS Proxy を介したデータベースへの接続

Aurora DB クラスター、またはプロキシを介してAurora Serverless v2 を使用するクラスターを接続する方法は、データベースに直接接続する方法と同じです。主な違いは、クラスターのエンドポイントの代わりに、プロキシのエンドポイントを指定することです。すべてのプロキシ接続にはデフォルトで読み取り/書き込み機能があり、ライターインスタンスを使用します。通常、読み取り専用の接続にリーダーエンドポイントを使用する場合は、プロキシ用の追加の読み取り専用エンドポイントを作成できます。そして、そのエンドポイントを同じ方法で使用できます。詳細については、「プロキシエンドポイントの概要」を参照してください。

トピック

• ネイティブ認証を使用したプロキシへの接続
• IAM 認証を使用したプロキシへの接続
• PostgreSQL でプロキシに接続する際の考慮事項

ネイティブ認証を使用したプロキシへの接続

以下のステップを使用して、ネイティブ認証を使用してプロキシに接続します。

1. プロキシエンドポイントを見つけます。AWS Management Console では、プロキシの詳細ページで対応するエンドポイントを見つけることができます。AWS CLI では、describe-db-proxies コマンドを使用できます。以下の例のように指定します。

   # Add --output text to get output as a simple tab-separated list.
   $ aws rds describe-db-proxies --query '*[*].{DBProxyName:DBProxyName,Endpoint:Endpoint}'
   [
       [
           {
               "Endpoint": "the-proxy.proxy-demo.us-east-1.rds.amazonaws.com",
               "DBProxyName": "the-proxy"
           },
           {
               "Endpoint": "the-proxy-other-secret.proxy-demo.us-east-1.rds.amazonaws.com",
               "DBProxyName": "the-proxy-other-secret"
           },
           {
               "Endpoint": "the-proxy-rds-secret.proxy-demo.us-east-1.rds.amazonaws.com",
               "DBProxyName": "the-proxy-rds-secret"
           },
           {
               "Endpoint": "the-proxy-t3.proxy-demo.us-east-1.rds.amazonaws.com",
               "DBProxyName": "the-proxy-t3"
           }
       ]
   ]

2. クライアントアプリケーションの接続文字列で、そのエンドポイントをホストパラメータとして指定します。例えば、mysql -h オプションまたは psql -h オプションの値としてプロキシエンドポイントを指定します。

3. 通常と同じようにデータベースのユーザー名とパスワードを指定します。

IAM 認証を使用したプロキシへの接続

RDS Proxy で IAM 認証を使用する場合は、通常のユーザー名とパスワードで認証するようにデータベースユーザーを設定します。IAM 認証は、Secrets Manager からユーザー名とパスワードの認証情報 RDS Proxy を取得する場合に適用されます。RDS Proxy から基礎となるデータベースへの接続は IAM を経由しません。

IAM 認証を使用して RDS Proxy に接続するには、Aurora DB クラスターとの IAM 認証と同じ一般的な接続手順で行います。IAM の使用に関する一般情報については、「Amazon Aurora でのセキュリティ」を参照してください。

RDS Proxy での IAM の使用方法の主な違いは以下のとおりです。

• 認可プラグインで個々のデータベースユーザーを設定することはありません。データベースユーザーが通常使用するユーザー名とパスワードはデータベース内に保管されています。これらのユーザー名とパスワードを含む Secrets Manager シークレットを設定し、RDS Proxy に Secrets Manager からの認証情報の取得を認可します。

  IAM 認証がクライアントプログラムとプロキシ間の接続に適用されます。その後、プロキシは、Secrets Manager から取得したユーザー名とパスワードの認証情報を使用して、データベースに対して認証します。

• インスタンス、クラスター、またはリーダーの各エンドポイントの代わりに、プロキシエンドポイントを指定します。プロキシエンドポイントの詳細については、「IAM 認証を使用した DB クラスターへの接続」を参照してください。

• 直接 DB IAM 認証では、データベースユーザーを選択し、特別な認証プラグインで識別されるように設定します。その後、IAM 認証を使用してそれらのユーザーに接続できます。

  プロキシのユースケースでは、ユーザーのユーザー名とパスワード (ネイティブ認証) を含むシークレットをプロキシに提供します。次に、IAM 認証を使用してプロキシに接続します。ここでは、データベースエンドポイントではなく、プロキシエンドポイントで認証トークンを生成して実行します。また、指定したシークレットのユーザー名の 1 つと一致するユーザー名を使用します。

• IAM 認証を使用してプロキシに接続する場合は、Transport Layer Security (TLS) / Secure Sockets Layer (SSL) を使用していることを確認してください。

IAM ポリシーを変更することで、特定のユーザーにプロキシへのアクセスを許可できます。以下に例を示します。

"Resource": "arn:aws:rds-db:us-east-2:1234567890:dbuser:prx-ABCDEFGHIJKL01234/db_user"

PostgreSQL でプロキシに接続する際の考慮事項

PostgreSQL では、クライアントが PostgreSQL データベースへの接続をスタートする際は起動メッセージを送信します。このメッセージには、パラメータ名と値の文字列のペアが含まれています。詳細については、PostgreSQL ドキュメントの「PostgreSQL Message Formats」で StartupMessage を参照してください。

RDS Proxy を介して接続する場合、起動メッセージには、現在認識されている以下のパラメータを含めることができます。

• user

• database

• replication

起動メッセージには、以下の追加のランタイムパラメータを含めることもできます。

• application_name

• client_encoding

• DateStyle

• TimeZone

• extra_float_digits

PostgreSQL メッセージの詳細については、PostgreSQL ドキュメントの「Frontend/Backend Protocol」を参照してください。

PostgreSQL では、JDBC を使用する場合、ピニングを回避するために以下の操作をお勧めします。

• 固定を回避するために、JDBC 接続パラメータ assumeMinServerVersion を 9.0 以上に設定します。これにより、JDBC ドライバーが SET extra_float_digits = 3 を実行するとき、接続の始動時に余分なラウンドトリップを実行しなくなります。

• 固定を回避するために、JDBC 接続パラメータ ApplicationName を any/your-application-name に設定します。これを行うと、JDBC ドライバーが SET application_name = "PostgreSQL JDBC Driver" を実行するとき、接続のスタートアップ中に余分なラウンドトリップを実行しなくなります。JDBC パラメータは ApplicationName ですが、PostgreSQL StartupMessage パラメータは application_name です。

詳細については、「固定を回避する」を参照してください。JDBC を使用した接続の詳細については、PostgreSQL ドキュメントの「Connecting to the Database」を参照してください。