翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Quick Sight のデータソース接続の問題 次のセクションでは、データソースへの接続に関するトラブルシューティングについて説明します。続行する前に、データベースが現在使用可能であることを確認してください。また、接続情報が正しく認証情報が有効であることも確認してください。 **Topics** + [接続できないがデータソース接続オプションは正しい (SSL) ように見受けられる](troubleshoot-connect-SSL.md) + [Amazon Athena に接続できない](troubleshoot-connect-athena.md) + [Amazon S3 に接続できない](troubleshoot-connect-S3.md) + [既存の Adobe Analytics データソースからデータセットを作成または更新できない](troubleshoot-connect-adobe-analytics.md) + [データソースへの接続を検証する、またはデータソース設定を変更する必要がある](troubleshoot-connect-validate.md) + [MySQL に接続できない (SSL と認可の問題)](troubleshoot-connect-mysql.md) + [RDS に接続できない](troubleshoot-connect-RDS.md) # 接続できないがデータソース接続オプションは正しい (SSL) ように見受けられる 接続時の問題は、Secure Sockets Layer (SSL) が正しく設定されていない場合に発生することがあります。以下の現象が発生することがあります。 + 他の方法でまたは他の場所からデータベースに接続できますが、この場合は接続できません。 + 同様のデータベースに接続できるが、このデータベースには接続できない。 続行する前に、以下の状況は除外してください。 + アクセス権限の問題 + 可用性の問題 + 証明書が期限切れまたは無効 + 自己署名証明書 + 間違った順番の証明書チェーンです + ポートが有効になっていない + ファイアウォールが IP アドレスをブロック + WebSocket がブロックされる + 仮想プライベートクラウド (VPC、virtual private cloud) またはセキュリティグループの設定が正しくありません。 SSL に関する問題を見つけるのに役立つように、オンラインの SSL チェッカー、または OpenSSL のようなツールを使用できます。 以下のステップでは、疑わしい SSL 接続に関するトラブルシューティングを行っています。この例では、管理者は OpenSSL をすでにインストールしているとします。 **Example** 1. ユーザーは現在のデータベースへの接続時に問題が発生していることがわかりました。ユーザーは、別の AWS リージョンにある別のデータベースに接続できることを確認しました。ユーザーが、同じデータベースの他のバージョンをチェックしたところ、簡単に接続できました。 1. 管理者は問題を検証し、証明書が正しく機能していることを確認することにします。管理者は、「OpenSSL を使用した、SSL 接続に関するトラブルシューティングまたはデバッグ」について、オンラインで記事を検索しました。 1. OpenSSL を使用して、管理者はターミナルで SSL 設定を確認します。 ``` echo quit openssl s_client –connect :port ``` その結果、証明書が機能していないことがわかりました。 ``` ... ... ... CONNECTED(00000003) 012345678901234:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:782: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 278 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None Start Time: 1497569068 Timeout : 300 (sec) Verify return code: 0 (ok) --- ``` 1. 管理者は、ユーザーのデータベースサーバーに SSL 証明書をインストールすることで問題を修正します。 この例の解決策の詳細については、*Amazon RDS ユーザーガイド*の、[SSL を使用した DB インスタンスへの接続の暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)を参照してください。 # Amazon Athena に接続できない | | | --- | |    対象者: Amazon Quick 管理者  | このセクションでは、Athena への接続に関するトラブルシューティングについて説明します。 Amazon Athena に接続できない場合、クエリの実行時に、アクセス許可が設定されていないことを示す、不十分なアクセス許可によるエラーが発生する場合があります。Amazon Quick Sight を Athena に接続できることを確認するには、次の設定を確認してください。 + AWS Amazon Quick Sight 内のリソースアクセス許可 + AWS Identity and Access Management (IAM) ポリシー + Amazon S3 ロケーション + クエリ結果の場所 + AWS KMS キーポリシー (暗号化されたデータセットのみ) 詳細については、以下を参照してください。その他の Athena の問題のトラブルシューティングについては、「[Amazon Quick Sight で Amazon Athena を使用する場合の接続の問題](troubleshoot-athena.md)」を参照してください。 ## Amazon Quick Sight に Athena の使用を許可していることを確認します。 | | | --- | |    対象者: Amazon Quick 管理者  | 次の手順を使用して、Amazon Quick Sight に Athena の使用を正常に承認していることを確認します。 AWS リソースへのアクセス許可は、すべての Amazon Quick Sight ユーザーに適用されます。 このアクションを実行するには、Amazon Quick Sight 管理者である必要があります。アクセス権があるかどうかをチェックするには、右上のプロファイルからメニューを開いたときに、**[Manage QuickSight]** (QuickSight の管理) オプションが表示されることを確認します。 **Amazon Quick Sight が Athena にアクセスすることを許可するには** 1. プロファイル名 (右上) を選択します。**「クイックサイトの管理**」を選択し、**「カスタムアクセス許可**」セクションまでスクロールダウンします。 1. **AWS リソース**を選択し、**追加または削除**を選択します。 1. リストで Athena を検索します。Athena のチェックボックスをオフにしてからもう一度オンにして、Athena を有効にします。 次に、[**Connect both (両方を接続)**] を選択します。 1. Amazon Quick Sight からアクセスするバケットを選択します。 ここでアクセスする S3 バケットの設定は、リストから Amazon S3 を選択してアクセスする設定と同じです AWS のサービス。他のユーザーが使用しているバケットを誤って無効にしないように注意してください。 1. **[Finish]** (完了) を選択して、選択を確定します。保存せずに終了するには、**[Cancel]** (キャンセル) を選択します。 1. **更新**を選択して、Amazon Quick Sight アクセスの新しい設定を保存します AWS のサービス。または、**[Cancel]** (キャンセル) を選択して、変更を加えずに終了します。 1. AWS リージョン 完了したら、正しい を使用していることを確認してください。 このプロセスの最初のステップ AWS リージョン の一部として を変更する必要がある場合は、以前使用 AWS リージョン していた に戻します。 ## IAM ポリシーが適切な許可を付与することを確認する | | | --- | |    対象者: システム管理者  | AWS Identity and Access Management (IAM) ポリシーは、特定のアクションにアクセス許可を付与する必要があります。IAM ユーザーまたはロールは、Athena がクエリに使用する S3 バケットの入力と出力の両方を読み込み/書き込みできる必要があります。 データセットが暗号化されている場合、IAM ユーザーは指定されたキーのポリシーで AWS KMS キーユーザーである必要があります。 **IAM ポリシーにクエリに S3 バケットを使用するアクセス権限があることを確認するには** 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. 使用している IAM ユーザーまたはロールを見つけます。ユーザー名またはロール名を選択し、関連するポリシーを確認します。 1. ポリシーのアクセス許可が正しいことを確認します。確認するポリシーを選択し、**[Edit policy]** (ポリシーの編集) を選択します。デフォルトで開くビジュアルエディタを使用します。JSON エディタを開いた場合は、[**Visual editor**] (ビジュアルエディタ) タブを選択します。 1. リスト内の S3 エントリを選択し、その内容を確認します。ポリシーでは、リスト、読み取り、書き込みのアクセス権限を付与する必要があります S3 がリストにない場合、または適切なアクセス許可がない場合は、ここで追加します。 Quick Sight で動作する IAM ポリシーの例については、「」を参照してください[Quick の IAM ポリシーの例](iam-policy-examples.md)。 ## IAM ユーザーが S3 の場所に対する読み取り/書き込みアクセス権を持っていることを確認する | | | --- | |    対象者: Amazon Quick 管理者  | Quick Sight から Athena データにアクセスするには、まず Athena とその S3 ロケーションが ** QuickSight の管理**画面で承認されていることを確認します。詳細については、「[Amazon Quick Sight に Athena の使用を許可していることを確認します。](#troubleshoot-connect-athena-authorizing)」を参照してください。 次に、関連する IAM アクセス許可を確認します。Athena 接続の IAM ユーザーには、結果が保存される S3 内の場所への、読み込み/書き込みアクセス権が必要です。まず、IAM ユーザーに [Athena へのアクセスを許可する](https://docs.aws.amazon.com/athena/latest/ug/setting-up.html#attach-managed-policies-for-using-ate) `AmazonAthenaFullAccess` のようなポリシーがアタッチされていることを確認します。Athena で必要な名前を使用してバケットを作成し、QuickSight がアクセスできるバケットのリストにこのバケットを追加します。結果バケットのデフォルトの場所 (`aws-athena-query-results-*`) を変更する場合、IAM ユーザーが新しい場所への読み込みと書き込みのアクセス許可を持っていることを確認します。 S3 URL に AWS リージョン コードを含めていないことを確認します。たとえば、`s3://us-east-1.amazonaws.com/awsexamplebucket/path` ではなく `s3://awsexamplebucket/path` を使用します。誤った S3 URL を使用すると、`Access Denied` エラーが発生します。 バケットポリシーとオブジェクトアクセスコントロールリスト (ACL、access control list) が、[IAM ユーザーがバケット内のオブジェクトにアクセスすることを許可している](https://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html)ことも確認します。IAM ユーザーが別の にある場合は AWS アカウント、*Amazon Athena ユーザーガイド*」の[「クロスアカウントアクセス](https://docs.aws.amazon.com/athena/latest/ug/cross-account-permissions.html)」を参照してください。 データセットが暗号化されている場合は、IAM ユーザーが指定されたキーのポリシーで AWS KMS キーユーザーであることを確認します。これは、[https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) の AWS KMS コンソールで実行できます。 **Athena クエリ結果の場所へのアクセス許可を設定するには** 1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。 1. 使用するワークグループが選択されていることを確認します。 + 上部の **[Workgroup]** (ワークグループ) オプションを検証します。これは、**Workgroup: *group-name*** の形式を持っています。使用するグループ名である場合は、次のステップまでスキップします。 + 別のワークグループを選択するには、上部の **[Workgroup]** (ワークグループ) を選択します。使用するワークグループを選択し、**[Switch workgroup]** (ワークグループの切り替え) を選択します。 1. 右上の **[Settings]** (設定) を選択します。 (一般的ではありません) 「ワークグループが見つかりません」というエラーが表示された場合は、以下のステップに従って修正します。 1. 現時点ではエラーメッセージは無視し、代わりに **[Settings]** (設定) ページで、**[Workgroup: *group-name*]** を検索します ワークグループ名はハイパーリンクです。ワークグループ名を開きます。 1. **[Workgroup: **]** ページで、左側の **[Edit workgroup]** (ワークグループの編集) を選択します。エラーメッセージを閉じます。 1. **[Query result location]** (クエリ結果の場所) 近くで、ファイルフォルダアイコン付きの **[Select]** (選択) ボタンをクリックし、S3 ロケーションセレクターを開きます。 1. Athena の S3 の場所名の末尾にある小さな矢印を選択します。名前は `aws-athena-query-results` で始まる必要があります。 1. (オプション) クエリ結果を暗号化するには、**[Encrypt results stored in S3]** (S3 に保存されている結果を暗号化する) チェックボックスをオンにします。 1. [**Save (保存)**] を選択し、設定を保存します。 1. エラーが再び表示されない場合は、**[Settings]** (設定) に戻ります。 場合によっては、エラーが再び表示されることがあります。この場合は、次のステップを実行します。 1. [ワークグループ]、**[View details]** (詳細の表示) の順に選択します。 1. (オプション) 設定を保持するには、ワークグループの設定を書き留めるか、スクリーンショットを撮ります。 1. **[Create workgroup]** (ワークグループの作成) を選択します。 1. ワークグループを新しいワークグループに置き換えます。正しい S3 の場所と暗号化オプションを設定します。後で必要になるため、S3 の場所を書き留めます。 1. **[Save]** (保存) を選択して続行します。 1. 元のワークグループが不要になった場合は、無効にします。表示される警告を注意して読んでください。無効にすると喪失するものがわかります。 1. 前のステップでトラブルシューティングによって取得しなかった場合は、右上の **[Settings]** (設定) を選択し、**[Query result location]** (クエリ結果の場所) として表示される S3 ロケーションの値を取得します。 1. **[Encrypt query results]** (クエリ結果の暗号化) が有効な場合、SSE-KMS または CSE-KMS を使用しているかをチェックします。キーを書き留めます。 1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で S3 コンソールを開き、正しいバケットを開いて、**[Permissions]** (アクセス許可) タブを選択します。 1. IAM ユーザーがアクセス権を持っていることを確認するには、**[Bucket Policy]** (バケットポリシー) を表示します。 ACL を使用してアクセスを管理する場合は、[**Access Control List (アクセスコントロールリスト)**]を表示して、アクセスコントロールリスト (ACL)が設定されていることを確認します。 1. データセットが暗号化されている場合 (ワークグループ設定で**暗号化クエリ結果**が選択されている場合）、IAM ユーザーまたはロールがそのキーのポリシーで AWS KMS キーユーザーとして追加されていることを確認します。 AWS KMS 設定には [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) からアクセスできます。 **Athena が使用する S3 バケットへのアクセスを許可するには** 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。 1. **[Query result location]** (クエリ結果の場所) で、Athena が使用する S3 バケットを選択します。 1. [**Permissions**] (アクセス許可) タブで、アクセス許可を確認します。 詳細については、 AWS サポートの記事[「Athena クエリを実行すると、「アクセスが拒否されました」というエラーが表示されます](https://aws.amazon.com/premiumsupport/knowledge-center/access-denied-athena/)。 # Amazon S3 に接続できない Amazon S3 に正常に接続するには、認証を設定し、アクセスするバケット内に有効なマニフェストファイルを作成する必要があります。また、マニフェストによって定義されたファイルが使用可能であることを確認します。 認証を検証するには、Amazon Quick Sight が S3 アカウントにアクセスすることを許可していることを確認してください。ユーザーが許可されているだけでは不十分です。Amazon Quick Sight は個別に承認する必要があります。 **Amazon Quick Sight が Amazon S3 バケットにアクセスすることを許可するには** 1. 右上 AWS リージョン のリストで、米国東部 (バージニア北部) リージョンを選択します。これは、アカウントのアクセス許可の編集中に AWS リージョン 一時的に使用します。 1. Amazon Quick Sight 内で、プロファイル名 (右上) を選択します。**「クイックサイトの管理**」を選択し、**「カスタムアクセス許可**」セクションまでスクロールダウンします。 1. **AWS リソース**を選択し、**追加または削除**を選択します。 1. リストで Amazon S3 を探します。次のいずれかのアクションを選択して、S3 バケットを選択できる画面を開きます。 + チェックボックスがオフになっている場合は、Simple Storage Service (Amazon S3) の横にあるチェックボックスをオンにします。 + チェックボックスがオンになっている場合は、**[Details]** (詳細)、**[Select S3 buckets]** (S3 バケットを選択) の順に選択します。 1. Amazon Quick Sight からアクセスするバケットを選択します。続いて、**[Select]** (選択) を選択します。 1. **[更新]** を選択します。 1. このプロセスの最初のステップ AWS リージョン で を変更した場合は、使用する に戻 AWS リージョン します。 マニフェストファイルが有効であることを確認することを強くお勧めします。Amazon Quick Sight がファイルを解析できない場合、エラーメッセージが表示されます。これは、「JSON が有効なため、マニフェストファイルを解析できません」または「S3 バケットに接続できません」などと表示されます。 **マニフェストファイルを確認するには** 1. マニフェストファイルを開きます。これは、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) の Amazon S3 コンソールから直接実行できます。マニフェストファイルに移動し、**[Open]** (開く) を選択します。 1. マニフェストファイル内で指定されている URI または URL が、接続先のファイルを示していることを確認します。 1. ファイルをアップロードするのではなく、マニフェストファイルへのリンクを使用する場合は、マニフェストファイルが正しく形成されていることを確認します。リンクには、`.json` という単語の後に追加のフレーズを含めるべきではありません。S3 コンソールの詳細で [**リンク**] の値を見ることで、S3 ファイルへの正しいリンクを得ることができます。 1. [https://jsonlint.com](https://jsonlint.com) にあるような JSON バリデーターを使用して、マニフェストファイルの内容が有効であることを確認してください。 1. バケットまたはファイルに対するアクセス権限を確認します。[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で、Amazon S3 バケットに移動し、**[Permissions]** (アクセス許可) タブをクリックして、適切なアクセス許可を追加します。アクセス権限のレベルが適切である (バケットに対するもの、またはファイルに対するもの) であることを確認します。 1. `s3://` ではなく `https://` プロトコルを使用している場合は、バケットを直接参照していることを確認します。例えば、*s3://s3-us-west-2.amazonaws.com/awsexamplebucket/myfile.csv* の代わりに *s3://awsexamplebucket/myfile.csv* を使用します。`s3://` と `s3-us-west-2.amazonaws.com` を使用して Amazon S3 を二重に指定すると、エラーが発生します。 マニフェストファイルと Amazon S3 への接続の詳細については、「[Amazon S3 のマニフェストファイルでサポートされている形式](supported-manifest-file-format.md)」を参照してください。 加えて、Amazon S3 データセットが [Amazon S3 ファイルを使用したデータセットの作成](create-a-data-set-s3.md) のステップに従って作成されたことを確認します。 Athena を使用して Amazon S3 に接続する場合は、「[Amazon Athena に接続できない](troubleshoot-connect-athena.md)」を参照してください。 # 既存の Adobe Analytics データソースからデータセットを作成または更新できない 2022 年 5 月 1 日現在、Quick Sight は Adobe Analytics でレガシー OAuth およびバージョン 1.3 および SOAP API オペレーションをサポートしていません。既存の Adobe Analytics データソースからデータセットを作成または更新しようとしたときにエラーが発生した場合は、古いアクセストークンがある可能性があります。 **既存の Adobe Analytics データソースからデータセットを作成または更新する際のエラーをトラブルシューティングするには** 1. Quick Sight を開き、左側の**データ**を選択します。 1. **New** then **Dataset** を選択します。 1. **データセットの作成**ページで、既存のデータソースのリストから更新する Adobe Analytics データソースを選択します。 1. **[Edit data source]** (データソースの編集) を選択します。 1. **[Edit Adobe Analytics data source]** (Adobe Analytics データソースの編集) ページが開いたら、**[Update data source]** (データソースの更新) を選択して、Adobe Analytics 接続を再認証します。 1. データセットを再作成するか、再度更新してみてください。データセットの作成または更新は成功するはずです。 # データソースへの接続を検証する、またはデータソース設定を変更する必要がある 場合によっては、データソースの更新、または接続エラーの発生により、設定のチェックが必要な場合があります。これらの場合、次のステップに従います。 **データソースへの接続を検証するには** 1. Quick Sight ホームページから、左側の**データ**を選択します。 1. **New** then **Dataset** を選択します。 1. 既存のデータソースのリストが表示されます。 1. テストまたは変更するデータソースを選択します。 1. オプションが表示された場合は、[**Edit/Preview data (データの編集/プレビュー)**] を選択します。 1. [**Validate connection (接続を検証)**] を選択します。 1. 必要な変更を行い、[**Update data source (データソースの更新)**] を選択します。 # MySQL に接続できない (SSL と認可の問題) MySQL での一般的な接続に関する問題を確認するには、以下のステップに従ってください。この手順は、SSL を有効にしたかどうか、使用権限を付与したかどうかを調べるのに役立ちます。 **MySQL で一般的な接続問題の解決策を見つけるには** 1. `/etc/my.cnf` をチェックして、SSL で MySQL が有効になっていることを確認します。 1. MySQL で、次のコマンドを実行します。 ``` show status like 'Ssl%'; ``` SSL が動作している場合は、次のような結果が表示されます。 ``` +--------------------------------+----------------------+ | Variable_name | Value | +--------------------------------+----------------------+ | Ssl_accept_renegotiates | 0 | | Ssl_accepts | 1 | | Ssl_callback_cache_hits | 0 | | Ssl_cipher | | | Ssl_cipher_list | | | Ssl_client_connects | 0 | | Ssl_connect_renegotiates | 0 | | Ssl_ctx_verify_depth | 18446744073709551615 | | Ssl_ctx_verify_mode | 5 | | Ssl_default_timeout | 0 | | Ssl_finished_accepts | 0 | | Ssl_finished_connects | 0 | | Ssl_session_cache_hits | 0 | | Ssl_session_cache_misses | 0 | | Ssl_session_cache_mode | SERVER | | Ssl_session_cache_overflows | 0 | | Ssl_session_cache_size | 128 | | Ssl_session_cache_timeouts | 0 | | Ssl_sessions_reused | 0 | | Ssl_used_session_cache_entries | 0 | | Ssl_verify_depth | 0 | | Ssl_verify_mode | 0 | | Ssl_version | | +--------------------------------+----------------------+ ``` SSL が無効の場合は、次のような結果が表示されます。 ``` +--------------------------------+-------+ | Variable_name | Value | +--------------------------------+-------+ | Ssl_accept_renegotiates | 0 | | Ssl_accepts | 0 | | Ssl_callback_cache_hits | 0 | | Ssl_cipher | | | Ssl_cipher_list | | | Ssl_client_connects | 0 | | Ssl_connect_renegotiates | 0 | | Ssl_ctx_verify_depth | 0 | | Ssl_ctx_verify_mode | 0 | | Ssl_default_timeout | 0 | | Ssl_finished_accepts | 0 | | Ssl_finished_connects | 0 | | Ssl_session_cache_hits | 0 | | Ssl_session_cache_misses | 0 | | Ssl_session_cache_mode | NONE | | Ssl_session_cache_overflows | 0 | | Ssl_session_cache_size | 0 | | Ssl_session_cache_timeouts | 0 | | Ssl_sessions_reused | 0 | | Ssl_used_session_cache_entries | 0 | | Ssl_verify_depth | 0 | | Ssl_verify_mode | 0 | | Ssl_version | | +--------------------------------+-------+ ``` 1. サポートされている SSL 証明書がデータベースサーバーにインストールされていることを確認します。 1. SSL を使用して接続する特定のユーザーに使用権限を付与します。 ``` GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL; ``` **注記** MySQL 接続用の TLS 1.2 には、MySQL バージョン 5.7.28 以降が必要です。MySQL サーバーが TLS 1.2 のみを適用し (例: `tls_version = TLSv1.2`)、サーバーバージョンが 5.7.28 未満の場合、SSL ハンドシェイクは`Communications link failure`エラーで失敗します。これを解決するには、MySQL または Aurora MySQL データベースをバージョン 5.7.28 以降にアップグレードします。 この例での解決策の詳細については、以下を参照してください。 + *Amazon RDS ユーザーガイド*の [MySQL DB インスタンスに対する SSL サポート](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.SSLSupport.html) + *Amazon RDS ユーザーガイド*の [SSL を使用した DB インスタンスへの接続の暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) + [MySQL のドキュメント](https://dev.mysql.com/doc/refman/5.6/en/using-encrypted-connections.html) # RDS に接続できない Amazon RDS への接続に関するトラブルシューティングの詳細については、「[データベースからのデータセットの作成](create-a-database-data-set.md)」を参照してください。 接続のトラブルシューティングについては、Amazon RDS ドキュメントの [Amazon RDS DB インスタンスに接続できない](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Connecting)を参照することもできます*。*