Amazon Redshift Serverless への接続

Amazon Redshift Serverless インスタンスをセットアップしたら、以下に示すさまざまな方法で接続できます。チームやプロジェクトが複数存在し、それらのコストを別々に管理したい場合は、個別に AWS アカウント を使用できます。

Amazon Redshift Serverless が利用できる AWS リージョン の一覧については、「Amazon Web Services 全般のリファレンス」の「Redshift Serverless API」に記載されているエンドポイントを参照してください。

Amazon Redshift Serverless は、現在の AWS リージョン で AWS アカウント 内のサーバーレス環境に接続します。Amazon Redshift Serverless は、5431～5455 と 8191～8215 のポート範囲内の VPC で実行されます。デフォルトは 5439 です。現在、ポートを変更できるのは API オペレーション UpdateWorkgroup と AWS CLI オペレーション update-workgroup のみです。

Amazon Redshift Serverless への接続

Amazon Redshift Serverless で次の構文を使ってデータベース (dev という名前) に接続できます。

workgroup-name.account-number.aws-region.redshift-serverless.amazonaws.com:port/dev

例えば、以下の接続文字列では、リージョンに us-east-1 が指定されます。

default.123456789012.us-east-1.redshift-serverless.amazonaws.com:5439/dev

JDBC ドライバー経由での Amazon Redshift Serverless への接続

次のいずれかの方法で、好みの SQL クライアントから、Amazon RedShift が提供する JDBC ドライバーバージョン 2 を使用して Amazon Redshift Serverless に接続できます。

JDBC ドライバーバージョン 2.1.x 以降を使用して、データベース認証のサインイン認証情報で接続するには、次の構文を使用します。ポート番号はオプションです。含まれていない場合、Amazon Redshift Serverless のデフォルトのポート番号は 5439 です。5431-5455 または 8191-8215 のポート範囲から別のポートに変更できます。サーバーレスエンドポイントのデフォルトのポートを変更するには、AWS CLI と Amazon Redshift API を使用します。

jdbc:redshift://workgroup-name.account-number.aws-region.redshift-serverless.amazonaws.com:5439/dev

例えば、次の接続文字列では、デフォルトのワークグループ、アカウント ID 123456789012、リージョン us-east-2 を指定しています。

jdbc:redshift://default.123456789012.us-east-2.redshift-serverless.amazonaws.com:5439/dev

JDBC ドライバのバージョン 2.1.x 以降を使用して IAM に接続するには、次の構文を使用します。ポート番号はオプションです。含まれていない場合、Amazon Redshift Serverless のデフォルトのポート番号は 5439 です。5431-5455 または 8191-8215 のポート範囲から別のポートに変更できます。サーバーレスエンドポイントのデフォルトのポートを変更するには、AWS CLI と Amazon Redshift API を使用します。

jdbc:redshift:iam://workgroup-name.account-number.aws-region.redshift-serverless.amazonaws.com:5439/dev

例えば、次の接続文字列では、デフォルトのワークグループ、アカウント ID 123456789012、リージョン us-east-2 を指定しています。

jdbc:redshift:iam://default.123456789012.us-east-2.redshift-serverless.amazonaws.com:5439/dev

ODBC には、次の構文を使用します。

Driver={Amazon Redshift (x64)}; Server=workgroup-name.account-number.aws-region.redshift-serverless.amazonaws.com; Database=dev

バージョン 2.1.0.9 以前の JDBC ドライバーを使用して IAM に接続する場合は、次の構文を使用する必要があります。

jdbc:redshift:iam://redshift-serverless-<name>:aws-region/database-name

例えば、次の接続文字列では、デフォルトのワークグループとリージョン AWS リージョン us-east-1 を指定しています。

jdbc:redshift:iam://redshift-serverless-default:us-east-1/dev

ドライバーの詳細については、「Amazon Redshift での接続の設定」を参照してください。

JDBC と ODBC の接続文字列の検索

SQL クライアントツールでワークグループに接続するには、JDBC または ODBC 接続文字列が必要です。接続文字列は、Amazon Redshift Serverless コンソールの、ワークグループの詳細ページにあります。

Data APIを使用した Amazon Redshift Serverless への接続

Amazon Redshift Data API を使用して、Amazon Redshift Serverless に接続することもできます。AWS CLI の呼び出しでは、cluster-identifier パラメータではなく、workgroup-name パラメータを使用します。

Data API の詳細については、「Amazon Redshift Data API の使用」を参照してください。Python で Data API を呼び出すコードの例やその他の例については、「Redshift Data API の開始方法」と、quick-start フォルダおよび use-cases フォルダを GitHub で参照してください。

SSL での Amazon Redshift Serverless への接続

Amazon Redshift Serverless への安全な接続を設定する

SSL 接続をサポートするために、Redshift Serverless では、AWS Certificate Manager(ACM) によって発行された SSL 証明書をワークグループごとに作成してインストールします。ACM 証明書は、ほとんどのオペレーションシステム、ウェブブラウザ、およびクライアントから公的に信頼されています。SQL クライアントまたはアプリケーションが、sslmode接続オプションをrequire、verify-ca、またはverify-fullに設定した SSL を使用して Redshift Serverless に接続する場合は、証明書バンドルをダウンロードする必要があるかもしれません。クライアントが証明書を必要とする場合、Redshift Serverless は以下のようにバンドル証明書を提供します。

デフォルトでは、ワークグループデータベースは SSL の使用の有無にかかわらず接続を受け入れます。

SSL 接続のみを受け入れる新しいワークグループを作成するには、 create-workgroup コマンドを使用して require_sslパラメータを true に設定します。次の例を使用するには、yourNamespaceName を名前空間の名前に置き換え、yourWorkgroupName をワークグループの名前に置き換えます。

aws redshift-serverless create-workgroup \
--namespace-name yourNamespaceName \
--workgroup-name yourWorkgroupName \
--config-parameters parameterKey=require_ssl,parameterValue=true

既存のワークグループを更新して SSL 接続のみを受け入れるには、 update-workgroup コマンドを使用して require_sslパラメータを true に設定します。require_ssl パラメータを更新すると、Redshift Serverless によってワークグループが再起動されることに注意してください。次の例では、yourWorkgroupName をワークグループの名前に置き換えます。

aws redshift-serverless update-workgroup \
--workgroup-name yourWorkgroupName \
--config-parameters parameterKey=require_ssl,parameterValue=true

Amazon Redshift では、Elliptic Curve Diffie—Hellman Ephemeral (ECDHE) 鍵契約プロトコルがサポートされます。ECDHE を使用すると、クライアントとサーバーはそれぞれ、安全でないチャネルを介して共有シークレットを確立するために使用される楕円曲線パブリック/プライベートキーペアを持ちます。ECDHE を有効にするために、Amazon Redshift で設定を行う必要はありません。ECDHE を使用してクライアント/サーバー間の通信を暗号化する SQL クライアントツールから接続する場合、Amazon Redshift は提供された暗号リストを使用して適切な接続を行います。詳細については、ウィキペディアの Elliptic curve diffie—hellman と OpenSSL ウェブサイトの Ciphers を参照してください。

Amazon Redshift Serverless への FIPS 準拠の SSL 接続の設定

FIPS 準拠の SSL を使用する新しいワークグループを作成するには、create-workgroup コマンドを使用して use_fips_ssl パラメータを true に設定します。次の例を使用するには、yourNamespaceName を名前空間の名前に置き換え、yourWorkgroupName をワークグループの名前に置き換えます。

aws redshift-serverless create-workgroup \
--namespace-name yourNamespaceName \
--workgroup-name yourWorkgroupName \
--config-parameters parameterKey=use_fips_ssl,parameterValue=true

FIPS 準拠の SSL 接続を使用するように既存のワークグループを更新するには、update-workgroup コマンドを使用して use_fips_ssl パラメータを true に設定します。use_fips_ssl パラメータを更新すると、Redshift Serverless によってワークグループが再起動されることに注意してください。次の例では、yourWorkgroupName をワークグループの名前に置き換えます。

aws redshift-serverless update-workgroup \
--workgroup-name yourWorkgroupName \
--config-parameters parameterKey=use_fips_ssl,parameterValue=true

FIPS 準拠の接続を使用するように Redshift Serverless を設定する方法の詳細については、「Amazon Redshift データベースデベロッパーガイド」の「use_fips_ssl」を参照してください。

Amazon Redshift マネージド VPC エンドポイントから Amazon Redshift Serverlessへの接続

他の VPC エンドポイントからの Amazon Redshift Serverless への接続

Amazon Redshift Serverless ワークグループのマネージド VPC エンドポイントの構成または設定については、「Amazon Redshift での Redshift 管理の VPC エンドポイントの操作」を参照してください。

インターフェイス VPC エンドポイントからの Amazon Redshift Serverless への接続 (AWS PrivateLink)

インターフェイス VPC エンドポイント (AWS PrivateLink) からの Amazon Redshift Serverless への接続の詳細については、「インターフェイス VPC エンドポイント」を参照してください。

別のアカウントまたは別のリージョンの Redshift VPC エンドポイントから Amazon Redshift Serverless への接続

クロス VPC エンドポイントからの Amazon Redshift Serverless への接続

Amazon Redshift Serverless は VPC でプロビジョニングされます。別のアカウントの VPC にアクセス許可を付与して、自身のアカウントの Amazon Redshift Serverless にアクセスできます。これはマネージド VPC エンドポイントからの接続と似ています。ただし、この場合の接続は、例えば別のアカウントのデータベースクライアントから発信されます。実行できるオペレーションは、次のとおりいくつかあります。

クロスアカウントアクセスの主な利点は、データベースコラボレーションが容易になることです。データベースが配置されているアカウントにユーザーをプロビジョンする必要なくアクセスできるため、設定ステップの低減、時間の節約につながります。

別のアカウントの VPC へのアクセスを付与するために必要なアクセス許可

アクセスを付与したり、許可されているアクセスを変更したりするには、付与者に次のアクセス許可を持つアクセス許可ポリシーが割り当てられている必要があります。

AWS マネージドポリシー AmazonRedshiftFullAccess で指定されているその他のアクセス許可が必要になる場合があります。詳細については、「Amazon Redshift Serverless へのアクセス許可の付与」を参照してください。

被付与者には、次のとおりのアクセス許可があるアクセス許可ポリシーが割り当てられている必要があります。

ベストプラクティスとして、アクセス許可ポリシーを IAM ロールにアタッチし、それを必要に応じてユーザーやグループに割り当てることをお勧めします。詳細については、「Amazon Redshift での Identity and Access Management」を参照してください。

クロス VPC アクセスを設定するために使用されるリソースポリシー例は次のとおりです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CrossAccountCrossVPCAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                   "123456789012",
                   "234567890123"
                ]
             },
            "Action": [
                "redshift-serverless:CreateEndpointAccess",
                "redshift-serverless:UpdateEndpointAccess",
                "redshift-serverless:DeleteEndpointAccess",
                "redshift-serverless:GetEndpointAccess"
            ],
            "Condition": {
                "ArnLike": {
                    "redshift-serverless:AuthorizedVpc": [
                        "arn:aws:ec2:us-east-1:123456789012:vpc/*",
                        "arn:aws:ec2:us-east-1:234567890123:vpc/vpc-456",
                        "arn:aws:ec2:us-east-1:234567890123:vpc/vpc-987"
                        ]
                    }
                }
            }
        }
    ]
}

このセクションで説明する手順では、アクセスを付与するユーザーに適切なアクセス許可が割り当てられていることを前提としています。例えば、リストされているアクセス許可を持つ IAM ロールが割り当てられている場合などです。この手順では、ワークグループに適切なリソースのアクセス許可が付与された IAM ロールがあることも前提としています。

コンソールを使用した別のアカウントへの VPC アクセスの付与

この手順では、データベースの所有者がデータベースへのアクセスを付与する場合にデータベースのアクセスを設定するステップを説明します。

変更を保存すると、追加したアカウントが [許可を付与されたアカウント] リストに表示されます。このエントリには、[アカウント ID] とアクセス権を付与した VPC のリストが表示されます。

データベース所有者は、アカウントへのアクセスを取り消すこともできます。所有者は、いつでもアクセスを取り消すことができます。

アクセス権が付与されたら、権限受領者のデータベース管理者はコンソールを調べてアクセス権の有無を確認できます。

CLI コマンドを使用した別のアカウントへのアクセスの付与

アクセスを付与するアカウントは、まず put-resource-policy を使用して接続する別のアカウントにアクセス権を付与する必要があります。データベース所有者は、put-resource-policy を呼び出して、別のアカウントがワークグループへの接続を作成することを許可できます。その後、被付与者アカウントは、create-endpoint-authorization を使用して、許可された VPC を介したワークグループへの接続を作成できます。

特定のアカウントと VPC へのアクセスを許可するために呼び出すことができる put-resource-policy のプロパティは次のとおりです。

aws redshift-serverless put-resource-policy
--resource-arn <value> 
--policy <value>

コマンドを呼び出した後、get-resource-policy を呼び出して resource-arn を指定すると、リソースへのアクセスを許可されているアカウントと VPC を確認できます。

被付与者が実行できる呼び出しは、次のとおりです。付与されたアクセス権に関する情報が表示されます。具体的には、アクセス権が付与された VPC を含むリストが返されます。

aws redshift-serverless list-workgroups
--owner-account <value>

この目的は、被付与者が付与されるアカウントからエンドポイントの承認に関する情報を取得することにあります。owner-account は共有するアカウントです。これを実行すると、ワークグループごとの CrossAccountVpcs、つまり許可されている VPC のリストが返されます。参考までに、ワークグループで使用できるすべてのプロパティは、次のとおりです。

Output: workgroup (Object)
workgroupId String,
workgroupArn String,
workgroupName String,
status: String,
namespaceName: String,
baseCapacity: Integer, (Not-applicable)
enhancedVpcRouting: Boolean,
configParameters: List,
securityGroupIds: List,
subnetIds: List,
endpoint: String,
publiclyAccessible: Boolean,
creationDate: Timestamp,
port: Integer,
CrossAccountVpcs: List

追加リソース

ネットワークトラフィックの設定手順については、「Public accessibility with default or custom security group configuration」を参照してください。このセクションでは、クラスターへのパブリックアクセス可能な場合のユースケースについても説明しています。

ネットワークトラフィックの設定手順については、「Private accessibility with default or custom security group configuration」を参照してください。このセクションでは、クラスターがインターネットで利用できない場合のユースケースについても説明します。

アクセス許可の付与、追加サービスへのアクセスの許可、IAM ロールの作成など、Amazon Redshift Serverless への安全な接続の詳細については、「Amazon Redshift Serverless での Identity and Access Management」を参照してください。