Amazon Aurora DSQL の接続: ドライバー、接続文字列、ベストプラクティス

本記事は 2026 年 5 月 11 日に公開された「Amazon Aurora DSQL connections: Drivers, strings, and best practices」を翻訳したものです。

Amazon Aurora DSQL への初めての接続を設定しようとしていますか? PostgreSQL を使ったことがあれば流れは似ていますが、いくつか重要な違いがあります。長期間有効なパスワードの代わりに、短命の IAM 認証トークンを使用します。静的なエンドポイントの代わりに、複数のアベイラビリティゾーンにまたがる分散クラスターエンドポイントを使用します。接続タイムアウトのトラブルシューティング、トークンの有効期限管理、ドライバーの初回設定など、接続パターンを理解しておくと一般的な問題を回避できます。

本記事では、接続文字列の設定方法、Python・Java・Node.js でのドライバー設定、認証・接続プーリング・ライフサイクル管理のベストプラクティスについて説明します。

接続アーキテクチャ

Amazon Aurora DSQL は、従来の PostgreSQL デプロイとは根本的に異なる分散接続アーキテクチャを採用しています。アプリケーションは単一のデータベースインスタンスに接続するのではなく、複数のアベイラビリティゾーンにトラフィックを分散するルーティングレイヤーを介して接続します。ドライバーや接続文字列を設定する前に、エンドポイントの構造とワイヤプロトコルの動作を理解しておく必要があります。以下のセクションでは、接続前に知っておくべきエンドポイント形式とワイヤプロトコルの互換性について説明します。

エンドポイント形式

Amazon Aurora DSQL クラスターのエンドポイントは次のパターンに従います。

<cluster-id>.dsql.<region>.on.aws

例: weaxxxxxxxxxxxxxxxxqdqqm.dsql.us-east-1.on.aws

デュアルスタック形式で、IPv4 と IPv6 の両方をサポートしています。エンドポイントは Aurora DSQL の分散ルーティングレイヤーに接続し、複数のアベイラビリティゾーンへの接続分散を自動的に処理します。

主要な接続パラメータ:

Host: クラスターエンドポイント (上記の形式)。
Port: 5432 (PostgreSQL 標準ポート)。
Database: postgres (デフォルトのデータベース名)。
SSL Mode: すべての接続で必須。

ワイヤプロトコルの互換性

Amazon Aurora DSQL は標準の PostgreSQL v3 ワイヤプロトコルを使用しており、psql、pgjdbc、psycopg、psycopg2 などの一般的な PostgreSQL ドライバーとの互換性があります。既存のツールやライブラリは、最小限の設定変更で利用できます。

認証とセキュリティ

Aurora DSQL では、従来の PostgreSQL データベースとは異なる認証方式とネットワークセキュリティを採用しています。以下のセクションでは、IAM ベースのトークン生成、ネットワーク接続オプション、認証情報管理のベストプラクティスについて説明します。

IAM ベースの認証

Amazon Aurora DSQL は短命の IAM 認証トークンのみを使用します。IAM 認証には以下のセキュリティ上の利点があります。

セキュリティの強化: パスワードの保存やローテーションに伴うリスクを軽減します。
アクセス制御の一元化: AWS Identity and Access Management (AWS IAM) による統一的な権限管理が可能です。
監査証跡: 接続試行が AWS CloudTrail に記録されます。
自動期限切れ: トークンはデフォルトで 15 分後に期限切れになります (最大 1 週間まで設定可能)。デフォルトを超える有効期間の延長は推奨しません。漏洩した長命トークンは重大なセキュリティリスクです。延長が必要な場合は、トークンのスコープを最小限の権限に絞り、CloudTrail で長命トークンを監視してください。

アクセス制御パターンとセキュリティのベストプラクティスの詳細については、Amazon Aurora DSQL のセキュリティ対策：アクセス制御のベストプラクティスを参照してください。

AWS Command Line Interface (AWS CLI) でのトークン生成:

以下のコマンドで、AWS CLI を使用して Aurora DSQL クラスターの認証トークンを生成します。

aws dsql generate-db-connect-admin-auth-token \
--region us-east-1 \
--hostname <your-cluster-id>.dsql.us-east-1.on.aws

必要な IAM 権限:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Action": [
       "dsql:DbConnect",
       "dsql:DbConnectAdmin"
     ],
     "Resource": "arn:aws:dsql:region:account-id:cluster/cluster-id",
     "Condition": { 
       "IpAddress": { 
         "aws:SourceIp": ["10.0.0.0/8"] 
       } 
     }
   }
 ]
}

dsql:DbConnect: 通常のデータベースユーザーとしての接続権限を付与します。
dsql:DbConnectAdmin: 管理者権限を付与します。

最小権限の原則

ユースケースごとに必要最小限の権限のみを付与します。

標準のアプリケーションアクセスには dsql:DbConnect を使用します。
dsql:DbConnectAdmin は管理タスク専用に限定します。
既知のネットワーク範囲のみにアクセスを制限するため、IP ベースの条件を追加します。

ネットワークセキュリティ

Amazon Aurora DSQL はパブリックアクセスとプライベートアクセスの両方をサポートしています。

パブリックエンドポイントアクセスは以下によりセキュリティを確保します。

IAM ベースの認証 – パスワードベースの脆弱性を軽減します。
IP ベースのアクセス制御 – IAM ポリシー条件により接続を制限します。
SSL/TLS 暗号化の必須化 – 暗号化されたトランスポートが必須です。

プライベートエンドポイントアクセス (AWS PrivateLink) はトラフィックを AWS 内に保持します。

VPC インターフェイスエンドポイント – インターネットに公開されないプライベート接続。
VPC エンドポイントポリシー – ネットワークレベルの追加のアクセス制御。
セキュリティグループ – 特定のサブネットとポートへのトラフィックを制限。

VPC エンドポイントポリシーをアタッチして、エンドポイント経由で接続できるプリンシパルを制限します。設定しない場合、VPC 内のすべてのプリンシパルがエンドポイントを使用してクラスターに接続できます。

{
"Version": "2012-10-17",
"Statement": [
   {
     "Effect": "Allow",
     "Principal": {
       "AWS": "arn:aws:iam::account-id:role/your-app-role"
     },
     "Action": [
       "dsql:DbConnect"
     ],
     "Resource": "arn:aws:dsql:region:account-id:cluster/cluster-id"
   }
]
}

ネットワークエグレス制御

インバウンドアクセスの制御だけでは不十分です。エグレス制限がなければ、侵害されたアプリケーションが外部にデータを送出する可能性があります。アプリケーションホストからのアウトバウンドトラフィックを制限してください。

セキュリティグループのアウトバウンドルール – 必要な宛先 (Aurora DSQL のポート 5432、AWS サービスエンドポイントなど) へのトラフィックのみを許可します。
VPC Network ACLs – セカンダリレイヤーとしてサブネットレベルのエグレス制限を追加します。
VPC Flow Logs – 予期しないアウトバウンドトラフィックパターンを監視します。
AWS Network Firewall – セキュリティグループを超えた、きめ細かいエグレスフィルタリングに使用します。

認証情報の管理

Aurora DSQL に接続する際の認証情報管理のベストプラクティスを以下に示します。

認証情報をハードコードしない – アプリケーションコードに埋め込まないでください。
環境変数を使用する – ホスト名やリージョンなどの設定値には環境変数を使用します。
トークンを動的に生成する – 接続時に AWS SDK 呼び出しでトークンを生成します。
AWS Secrets Manager を使用する – 接続設定の保存に利用します。
IAM 認証情報を定期的にローテーションする – AWS のセキュリティベストプラクティスに従います。
認証試行を監視する – CloudTrail による異常検知を活用します。
認証トークンをログに記録・永続化しない – トークンはデータベースパスワードとして渡されるため、接続文字列ログ、アプリケーションログ、エラーメッセージに漏洩する可能性があります。ロギングフレームワークでパスワードフィールドを確実にマスクし、URL や診断出力にトークンを含めないでください。

接続の監視

CloudTrail はすべての Aurora DSQL 認証イベントを記録します。異常な接続アクティビティを検知するアラートを設定してください。

認証失敗 – DbConnect または DbConnectAdmin の繰り返し失敗に対して Amazon CloudWatch アラームを作成し、認証情報の悪用や設定ミスを検知します。
予期しない送信元 IP やリージョン – CloudTrail イベントを sourceIPAddress と awsRegion でフィルタリングし、想定外のネットワーク範囲からの接続をフラグ付けします。
異常な接続パターン – CloudWatch 異常検知を使用して、接続量の急増や通常の運用時間外の接続を監視します。
長命トークンの使用 – 要求された有効期間がデフォルトの 15 分を超える GenerateDbConnectAdminAuthToken 呼び出しを追跡します。

自動対応として、CloudTrail イベントの Amazon EventBridge ルールを使用して、Amazon Simple Notification Service (Amazon SNS) 通知や AWS Lambda による修復ワークフローをトリガーできます。

SSL/TLS の設定

Amazon Aurora DSQL は接続に暗号化トランスポートを必須としています。

sslmode=require – 暗号化の最小要件。
sslmode=verify-full – 完全な証明書検証とホスト名検証によるセキュリティ強化。

本番環境の推奨事項: verify-full モードを使用してください。証明書チェーンとホスト名の両方を検証し、中間者攻撃への対策となります。

Amazon Aurora DSQL コネクター

AWS は Amazon Aurora DSQL コネクターを提供しています。コネクターは透過的な認証レイヤーとして機能し、IAM トークンの生成とリフレッシュを自動的に処理します。認証コードではなく、接続コードだけを記述すれば済みます。

利用可能なコネクター

JDBC Connector – 標準の Java データベース接続レイヤーに IAM 認証を統合し、既存の Java データアクセスフレームワークとシームレスに連携します。
Python Connector – psycopg、psycopg2、asyncpg (非同期ワークロード) をサポートします。認証プラグインとして動作し、既存の接続ワークフローを変更せずにトークン生成を処理します。
Node.js Connectors – node-postgres (pg) と Postgres.js の両方に対応しています。
Go Connector – pgx をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。
Ruby Connector – Ruby アプリケーション向けの IAM ベース認証を提供します。
.NET Connector – Npgsql をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。
Rust Connector – SQLx をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。

実装の詳細については、Amazon Aurora DSQL Connectors GitHub を参照してください。

コネクター使用の利点

トークン管理の自動化 – クラスターホスト名からのリージョン自動検出を含む、IAM トークン生成とリフレッシュのライフサイクル全体を管理します。
シームレスな統合 – 接続プーリングライブラリ (HikariCP、psycopg ConnectionPool、psycopg2 ThreadedConnectionPool、asyncpg ネイティブプール) と透過的に連携します。
フレームワークサポート – Spring Boot、Django など、標準的なデータベースドライバーインターフェイスに依存するフレームワークと互換性があります。
ボイラープレートの削減 – 手動のトークン生成コードの記述やメンテナンスが不要です。

クイックスタート例 (JDBC コネクター)

以下の例は、Java で JDBC コネクターを使用して Aurora DSQL クラスターに接続する方法を示しています。コードを実行する前に、プロジェクトの依存関係に Aurora DSQL JDBC ドライバーを追加し、IAM 認証情報を設定済みであることを確認してください (環境変数、インスタンスプロファイル、または AWS 認証情報ファイルのいずれか)。JDBC URL に jdbc:aws-dsql:// プレフィックスを設定し、DriverManager.getConnection を呼び出します。コネクターが IAM トークン生成を自動的に処理するため、手動のトークンコードは不要です。コネクターは、トークンを長期間キャッシュするのではなく、新しい接続または接続プールの初期化ごとに新しいトークンを生成します。

// Change the JDBC URL prefix to jdbc:aws-dsql://
String url = "jdbc:aws-dsql://" + clusterEndpoint + ":5432/postgres";
Connection conn = DriverManager.getConnection(url, "admin", "");
// No password needed — the connector handles token generation automatically

手動接続パターン

コネクターを使用しない場合 (学習目的、デバッグ、カスタム認証フローなど) は、AWS SDK で IAM トークンを手動で生成し、データベースパスワードとして渡せます。

接続には最低限 sslmode=require が必要です。トークンは、呼び出し元の IAM アイデンティティから派生し、特定のクラスターホスト名にスコープされた、有効期限付きの認証情報です。

SDK	トークン生成メソッド
Python (boto3)	generate_db_connect_admin_auth_token
Java	DsqlClient.generateDbConnectAdminAuthToken
Node.js	GenerateDbConnectAdminAuthTokenCommand
Go	dsql.GenerateDbConnectAdminAuthToken
Ruby	Aws::DSQL::Client#generate_db_connect_admin_auth_token
.NET	AmazonDSQLClient.GenerateDBConnectAdminAuthToken
Rust	dsql::Client::generate_db_connect_admin_auth_token

生成したトークンを、接続確立時にデータベースパスワードとして渡します。

完全なコード例については、Amazon Aurora DSQL ユーザーガイドと Amazon Aurora DSQL Code Samples を参照してください。

接続プーリング

適切に設定された接続プーリングは、レイテンシーを低減し、Aurora DSQL の接続レート制限への到達を回避します。本セクションでは、プールの設定、サイジング、考慮すべき主要な制約について説明します。

クライアント側プーリングが必須

Aurora DSQL にはサービスレイヤーでの組み込み接続プーリングがありますが、新しい接続ごとに TLS ハンドシェイクとサービスによる認証が必要です。接続をプールすれば、そのコストをリクエストごとではなく一度だけ支払えばよくなります。

PgBouncer や pgpool-II などのサーバー側コネクションプーラーは使用しないでください。これらのツールは従来の PostgreSQL アーキテクチャ向けに設計されており、Amazon Aurora DSQL の分散接続処理で可用性の問題を引き起こす可能性があります。

プール設定

最も重要なパラメータは最大接続寿命です。Amazon Aurora DSQL は接続期間に 60 分のハードリミットを適用します。プールの最大ライフタイムを 45〜55 分に設定し、Aurora DSQL が接続を切断する前にプロアクティブにリサイクルしてください。

Java で HikariCP を使用する場合は、maximumPoolSize、maxLifetime (60 分未満) を設定し、手動のトークン管理を避けるために JDBC Connector を使用します。HikariCP の完全な設定については、公式ガイド「Using Amazon Aurora DSQL with JDBC, Hibernate, and HikariCP」を参照してください。

Python の場合は、手動で生成した IAM トークンを使用して psycopg2 で接続するか (Amazon Aurora DSQL ユーザーガイド – Psycopg2 の使用を参照)、Amazon Aurora DSQL Python Connector (GitHub) を使用してトークンのボイラープレートを完全に排除できます。

接続制限とクォータ

接続プールのサイジングを決定する前に、Amazon Aurora DSQL の接続制限を理解しておく必要があります。Amazon Aurora DSQL は接続作成レートの制御にトークンバケットアルゴリズムを使用しています。新しい接続ごとにトークンを 1 つ消費し、バケットは一定レートで補充されます。バケット容量を上限としてバーストも可能です。

クラスターあたりのデフォルト制限は以下のとおりです。

クォータ	デフォルト値	備考
最大確立接続数	10,000	クラスターごとの制限。Service Quotas で調整可能
新規接続レート (定常状態)	100 接続/秒	トークンバケットの補充レート
バースト容量	1,000 接続	補充前の t=0 時点で利用可能なトークン数
最大接続期間	60 分	ハードリミット。1 時間後に接続切断
最大トランザクション期間	5 分	トランザクションごと (BEGIN から COMMIT まで)

トークンバケットの実際の動作: アプリケーション起動時に 1,000 接続を開いた場合、すべて成功します (バーストトークン 1,000 個)。ただし、バケットは空になります。1,001 番目の接続は、バケットが 100 トークン/秒で補充されるのを待つ必要があります。クライアント側プーリングが重要な理由はここにあります。接続を再利用すれば、作成バジェットの消費を避けられます。

接続ライフサイクル

Aurora DSQL の接続には最大ライフタイムが固定されており、有効期限付きトークンを使用するため、アプリケーションは接続のリサイクルとトークンリフレッシュを適切に処理する必要があります。

1 時間の接続制限

Amazon Aurora DSQL のすべての接続の最大ライフタイムは 60 分です。1 時間後、接続がアイドル状態でもアクティブ状態でも、サービスが接続を切断します。これは設計上の仕様です。Aurora DSQL の分散アーキテクチャでは内部コンポーネントがバックグラウンドで障害復旧や交換されるため、1 時間の制限によりアプリケーションが定期的に新しい接続を確立し、正常なインフラに自然に接続されるようになっています。Aurora DSQL は切断にジッターを適用するため、接続が同時に切断されることはなく、トランザクション中の接続は切断されません。

トークンの有効期限管理

トークンはデフォルトで 15 分後に期限切れになります (最大 1 週間まで設定可能)。重要なポイント: 有効なトークンで接続が確立された後は、トークンが期限切れになっても接続は有効なままです。新しいトークンが必要なのは新しい接続を確立するときだけであり、60 分の接続制限がバインディング制約となります。トークンの有効期限は制約になりません。

トークンはリージョンスコープでもあります。region=us-east-1 で生成されたトークンは us-east-1 エンドポイントへの接続にのみ有効で、同じマルチリージョンクラスターの us-east-2 エンドポイントには使用できません。マルチリージョンデプロイでは、アプリケーションが接続する各リージョンエンドポイントに対して個別のトークンを生成してください。

推奨アプローチ: Amazon Aurora DSQL コネクターを使用してください。新しい接続ごとに自動的にトークンを生成するため、トークン管理コードが不要です。

接続リトライロジック

分散システムでは一時的な接続障害は例外ではなく通常の動作です。内部コンポーネントに障害が発生した場合、Aurora DSQL が自動的に処理しますが、アプリケーション側ではその接続に対するエラーが発生します。

SerializationFailure (OCC コンフリクト) と OperationalError (一時的な障害) の両方に対して、エクスポネンシャルバックオフとジッターを伴うリトライロジックを実装してください。推奨パターンについては、Amazon Aurora DSQL の同時実行制御ドキュメントと AWS Builders’ Library – タイムアウト、リトライ、ジッター付きバックオフを参照してください。

マルチリージョン接続パターン

地理的リージョンをまたいだ高可用性が必要なアプリケーション向けに、Amazon Aurora DSQL マルチリージョンクラスターはリージョンエンドポイントで読み書き両方をサポートするアクティブ-アクティブアーキテクチャを提供します。

アクティブ-アクティブマルチリージョンアーキテクチャ

Amazon Aurora DSQL マルチリージョンクラスターは、アクティブ-アクティブアクセスのためのリージョンエンドポイントを提供します。アプリケーションはどちらのエンドポイントにも接続して読み書きが可能で、地理的な分散とリージョンフェイルオーバーを実現します。

エンドポイント選択戦略

レイテンシーのために最寄りのリージョンエンドポイントに接続し、プライマリリージョンに問題がある場合はセカンダリエンドポイントへのヘルスベースのフェイルオーバーを実装します。フェイルオーバーロジックは事前にテストしておいてください。

一般的な接続問題のトラブルシューティング

本セクションでは、Aurora DSQL に接続する際に発生しやすいエラーや接続障害と、その原因および推奨される対処方法について説明します。認証失敗、タイムアウトエラー、ドライバーの互換性の問題のいずれの場合も、以下のガイダンスで問題を迅速に診断・解決できます。

問題 1: “Connection Attempt Failed”

症状: Amazon Aurora DSQL エンドポイントへの接続を確立できない

一般的な原因: IAM 権限の不備、認証トークンの期限切れ、ネットワーク接続の問題、エンドポイント形式の誤り

解決方法: 接続失敗を解決するには、以下の手順を順に実行してください。まず、IAM ユーザーまたはロールのポリシーに適切な dsql:DbConnect または dsql:DbConnectAdmin 権限がアタッチされていることを確認します。次に、認証トークンが期限切れでないことを確認します。トークンは短命であり、新しい接続試行のたびに再生成が必要です。クラスターエンドポイントの形式が正しいこと、ポート 5432 へのアウトバウンドトラフィックをブロックするネットワークレベルの制限 (セキュリティグループ、VPC ルーティングルール、ファイアウォールポリシーなど) がないことを確認してください。以下の例は、新しいトークンを生成して明示的なエラーハンドリングで接続を試みることで、根本原因を特定しやすくする方法を示しています。

# Verify IAM permissions
aws iam get-user

# Test token generation
aws dsql generate-db-connect-admin-auth-token \
--region us-east-1 \
--hostname <cluster-id>.dsql.us-east-1.on.aws

# Test network connectivity
nc -zv <cluster-id>.dsql.us-east-1.on.aws 5432

問題 2: “Access Denied” エラー

症状: 接続は確立されるが認証に失敗する

解決方法:

IAM ポリシーに dsql:DbConnect または dsql:DbConnectAdmin が含まれていることを確認します。
IAM ポリシーのアクセス制限条件 (aws:SourceIp、aws:RequestedRegion、aws:PrincipalTag など) を確認します。基本権限が付与されていても、条件によって接続がサイレントに拒否される場合があります。
トークンが正しいリージョンで生成されていることを確認します。
AWS 認証情報が期限切れでないことを確認します。

問題 3: PrivateLink 接続の問題

VPC の外部から PrivateLink 経由で接続する場合、クライアントはクラスターエンドポイントを VPC エンドポイント IP に解決する必要があります。2 つのアプローチがあります。

オプション 1: PGHOSTADDR で IP アドレスをオーバーライド

export PGHOSTADDR=<vpce-ip-address>
export HOSTNAME=<cluster-id>.dsql.<region>.on.aws
psql -h $HOSTNAME -U admin -d postgres

SNI に正しいホスト名を使用しながら VPC エンドポイント IP に接続します。

オプション 2: amzn-cluster-id 接続オプションを使用 (DNS 不要)

export CLUSTERID=<cluster-id>
export PGOPTIONS="-c amzn-cluster-id=$CLUSTERID"
psql -h <vpce-endpoint> -U admin -d postgres

クラスター識別子を接続オプションとして直接渡し、DNS 解決を不要にします。VPC エンドポイントのプライベート DNS が設定されていない場合に便利です。

詳細については、PrivateLink 接続エンドポイントを使用した Amazon Aurora DSQL への接続を参照してください。

問題 4: 接続プールのヘルスチェックストーム

症状: 負荷スパイク時の大量の接続切断と再確立、カスケード的なヘルスチェック失敗、接続レート制限エラー

原因: 短いヘルスチェック間隔 (HikariCP のデフォルト 5 秒タイムアウトなど) により、数千のプール接続に対して同時にヘルスチェックがトリガーされる場合があります。多数のチェックが同時に失敗すると、プールがすべての接続の再確立を試み、100 接続/秒のレート制限を使い果たして障害がカスケードします。