rds-oss

RDS OSS Advisor（MySQL、MariaDB、PostgreSQL）

概要

オープンソースエンジンの MySQL、MariaDB、PostgreSQL を対象とした Amazon RDS 向けアドバイザーです。次の 5 つの判断領域があります。

1. インスタンスの作成 — ベストプラクティスに基づくデフォルト設定（最新バージョン、Multi-AZ、暗号化、Performance Insights、Secrets Manager によるパスワード管理）で、本番環境向けインスタンスをプロビジョニングします
2. アップグレード計画 — インスタンスを特定し、アップグレード先を列挙して、ライブ事前チェックを実行し、計画のリグレッションにフラグを付け、アップグレード前後のチェックリストを提示します
3. コミットメント料金 — 安定したワークロードを対象に、RI と Database Savings Plan の削減額を見積もります
4. RDS Proxy の評価 — 接続使用率とピン留めのリスクに基づいて、プロキシを導入する価値があるか判断します
5. Blue/Green デプロイ — DDL やメジャーアップグレードをダウンタイムを抑えて計画し、DDL の互換性を分析します

コスト見積もり、事前チェックの結果、CLI コマンドを提示します。インスタンスの作成では、本番環境のベストプラクティスを適用して create-db-instance 呼び出しを実行します。アップグレード、購入、切り替えについてはアドバイザリーのみを行い、ユーザーから明示的な確認がない限り実行しません。

対象は RDS のオープンソースエンジンです。Aurora には amazon-aurora を使用してください。Oracle、SQL Server、Db2 には、エンジン固有のスキルを使用してください。

コマンドの実行には AWS MCP サーバーの使用を推奨しますが、必須ではありません。すべての操作は AWS CLI でも実行できます。

判断ガイド

ユーザーの質問…	参照先
新しい RDS MySQL／MariaDB／PostgreSQL インスタンスの作成、プロビジョニング、セットアップ	以下の本番環境向けインスタンスの作成
アップグレード、アップグレード先のバージョン、アップグレード前後のチェックリスト、アップグレードの事前チェック、リードレプリカのアップグレード順序	references/upgrade-workflow.md
リザーブドインスタンス、RI、Database Savings Plan、DSP、1 年と 3 年の比較、Multi-AZ のコミットメント、前払いなし／一部前払い／全額前払い	references/commitment-pricing-workflow.md
RDS Proxy、コネクションプーリング、接続数が多すぎる、Lambda の DB 接続、プロキシのピン留め、PgBouncer と Proxy の比較	references/proxy-advisor-workflow.md
Blue/Green、ダウンタイムなしの DDL、切り替え、ダウンタイムを最小限に抑えたスキーマ変更、本番環境での型変更	references/bluegreen-advisor-workflow.md

広範な依頼（「RDS について相談したい」など）の場合は、5 つの選択肢をそれぞれ 1 行で提示します。ユーザーがインスタンス ID を提示している場合は、一般的なヘルスチェック（エンジン、バージョン、接続使用率）を入り口として提案します。

対象外（Aurora、Oracle、SQL Server、Db2、バックアップポリシー、Performance Insights の詳細分析）については、一般的な知識に基づいて回答し、このスキルの対象外であることを伝え、適切なエンジン固有のスキルを案内してください。

RDS と Aurora — 混同しないでください

RDS のオープンソースエンジンと Aurora は、仕様が異なる別の製品です。Aurora の概念を RDS に適用してはいけません。

概念	RDS（このスキル）	Aurora（amazon-aurora を使用）
LTS リリース	❌ ありません	✅ LTS バージョンがあります
サーバーレスモード	❌ ありません	✅ Aurora Serverless
I/O 最適化ストレージ	❌ ありません	✅ aurora-iopt1
Data API	❌ スタンドアロンの RDS では利用できません	✅ Aurora Serverless クラスター
インスタンスのトポロジー	インスタンスベース（describe-db-instances）	クラスターベース（describe-db-clusters）
アップグレードの範囲	インスタンス単位	クラスター単位（ライターとリーダーを同時にアップグレード）
DSP の契約期間の選択肢	1 年、3 年	1 年のみ
料金モデル	オンデマンド + RI + DSP	オンデマンド + RI + DSP + I/O 料金

ユーザーが Aurora 固有の概念について質問した場合は、amazon-aurora に案内してください。インスタンスが Aurora（エンジンが aurora-mysql または aurora-postgresql）と判明した場合は、処理を中止して案内先を切り替えてください。

本番環境向けインスタンスの作成

ユーザーが本番環境で使用する新しい RDS MySQL、MariaDB、または PostgreSQL インスタンスの作成やプロビジョニングを依頼した場合は、以下のベストプラクティスをデフォルトで適用する必要があります。

1. 最新の安定したメジャーバージョンを使用する — aws rds describe-db-engine-versions --engine <engine> --query "DBEngineVersions[].EngineVersion" を実行して最新バージョンを確認します。MySQL では、8.0 より 8.4.x を優先してください（8.0 は 8.4 より標準サポート終了日が早いためです。日付については RDS Extended Support を参照してください）。PostgreSQL では、最新のメジャーバージョンを使用します。MariaDB では、最新のメジャーバージョンを使用します。
2. Multi-AZ を有効にする — 自動フェイルオーバーのため、--multi-az を設定します。
3. カスタマー管理の KMS キーを使用してストレージ暗号化を有効にする — --storage-encrypted --kms-key-id <key-arn> を設定します。カスタマー管理のキーを使うと、キーのローテーション、アクセスポリシー、クロスアカウント共有を完全に制御できます。
4. パブリックアクセスを無効にする — インスタンスがインターネットからアクセスできないよう、--no-publicly-accessible を設定します。
5. バックアップ保持期間を 7 日に設定する — --backup-retention-period 7 を設定します。
6. Performance Insights を有効にし、保持期間を 7 日に設定する — --enable-performance-insights --performance-insights-retention-period 7 を設定します。Performance Insights が機密データを含むクエリ（WHERE 句内のリテラル値など）を取得する場合は、--performance-insights-kms-key-id <key-arn> を指定して、カスタマー管理の KMS キーで保存時に暗号化します。
7. 削除保護を有効にする — --deletion-protection を設定します。
8. デフォルトのマスターユーザー名を避ける — admin、root、postgres、master など、よく知られた名前は認証情報を推測する攻撃を容易にするため、使用しないでください。カスタムの --master-username（アプリケーションやチームに固有の名前など）を選択します。
9. Secrets Manager でマスターパスワードを管理する — 平文の --master-user-password を指定する代わりに、--manage-master-user-password を設定します。これにより、Secrets Manager でパスワードが自動的に作成され、ローテーションされます。本番インスタンスでは、平文のパスワードを受け入れたり使用したりしないでください。
10. gp3 ストレージを使用する — --storage-type gp3 を設定します。最低 IOPS の購入が不要で、gp2 より安価かつ高速です。
11. このスキルを通じて作成されたリソースを顧客が識別できるよう、インスタンスにタグを付ける — --tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value={your-model-id} を設定します（以下の「リソースのタグ付け」を参照）。
12. 通信中の接続に TLS を必須にする — DB パラメータグループを作成または変更し、暗号化接続を必須にします。MySQL／MariaDB では require_secure_transport=ON、PostgreSQL では rds.force_ssl=1 を設定します。
13. データベースログを CloudWatch Logs にエクスポートし、KMS で暗号化する — データベースレベルのセキュリティイベント（ログイン失敗、不審なクエリなど）を一元的に確認できるよう、--enable-cloudwatch-logs-exports を設定します。MySQL／MariaDB では ["error","slowquery","audit"] を使用します（注：audit ストリームを使用するには、先に監査ログを有効にする必要があります。有効になっていない場合、ストリームは空になります。RDS MySQL ではオプショングループの MARIADB_AUDIT_PLUGIN を使用し、RDS MariaDB ではパラメータグループの server_audit_logging=1 など、組み込みのサーバー監査パラメータを使用します）。PostgreSQL では ["postgresql"] を使用します。データベースログには、リテラル値やユーザー名を含む SQL が記録される可能性があるため、機密データを保存時に保護するには、作成される /aws/rds/instance/<name>/* ロググループに KMS キーを必ず設定してください。

CLI の例（MySQL 8.4、本番環境向け）：

aws rds create-db-instance \
  --db-instance-identifier <name> \
  --engine mysql \
  --engine-version 8.4 \
  --db-instance-class <class> \
  --allocated-storage 100 \
  --storage-type gp3 \
  --storage-encrypted \
  --kms-key-id <kms-key-arn> \
  --no-publicly-accessible \
  --multi-az \
  --manage-master-user-password \
  --master-username <custom-non-default-username> \
  --backup-retention-period 7 \
  --enable-performance-insights \
  --performance-insights-retention-period 7 \
  --performance-insights-kms-key-id <kms-key-arn> \
  --deletion-protection \
  --enable-cloudwatch-logs-exports '["error","slowquery","audit"]' \
  --tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value=<your-model-id> \
  --region us-east-1

インスタンスの作成後、TLS の必須化とロググループの暗号化を設定するため、次のコマンドを実行します（これらはスキルが提示するものの、直接実行しない、ユーザーが実行する手順です）。

# Create a custom parameter group with TLS enforcement (MySQL example)
aws rds create-db-parameter-group --db-parameter-group-family mysql8.4 \
  --db-parameter-group-name <name>-tls --description "TLS enforced"
aws rds modify-db-parameter-group --db-parameter-group-name <name>-tls \
  --parameters "ParameterName=require_secure_transport,ParameterValue=ON,ApplyMethod=pending-reboot"
aws rds modify-db-instance --db-instance-identifier <name> \
  --db-parameter-group-name <name>-tls --apply-immediately

# Encrypt CloudWatch Logs log groups with KMS
aws logs associate-kms-key --log-group-name /aws/rds/instance/<name>/error --kms-key-id <kms-key-arn>
aws logs associate-kms-key --log-group-name /aws/rds/instance/<name>/slowquery --kms-key-id <kms-key-arn>

制約：

• 本番環境では、必ず --manage-master-user-password を使用してください。本番インスタンスで、平文のパスワードを指定した --master-user-password を使用してはなりません。
• バージョンをハードコードするのではなく、describe-db-engine-versions を使用して、利用可能な最新のエンジンバージョンを必ず確認してください。
• ユーザーが明示的に別の指定をしない限り、Multi-AZ、暗号化、Performance Insights（7 日間）、バックアップ保持期間（7 日間）、削除保護を必ず有効にしてください。
• ユーザーが「production」または「production-ready」と言った場合は、上記のすべてを確認せずに適用してください。

リソースのタグ付け（リソース作成時に必ず適用）

RDS インスタンス（create-db-instance）を作成する際は、必ず RDS のレコードリスト形式の --tags 構文を使用して、次のタグを含めてください。

--tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value={your-model-id}

例：--tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value=claude-sonnet-4-20250514

ユーザーがタグ付けに言及していなくても、このスキル経由で作成されたリソースを識別できるよう、これらのタグを含めてください。ユーザーが追加のタグを指定した場合は、置き換えるのではなく、これらのタグに追加してください。add-tags-to-resource によるタグ付けや、ブルー／グリーンデプロイでも同様です。

一般的なタスク

1. 依存関係を確認する

ワークフローを実行する前に必要なツールと認証情報については、references/verify-dependencies.md を参照してください。

2. 分類して振り分ける

Decision Guide を使用して、ワークフローのリファレンス、カタログの提示（広範なリクエストの場合）、または一般知識による回答（対象範囲外の場合）を選択してください。

制約事項：

• 振り分け先のワークフロー名を必ず示してください。
• ユーザーがすでに提示したインスタンス ID、リージョン、エンジン、またはワークロードの詳細は、必ず引き継いでください。再度尋ねてはいけません。
• リクエストが2つのワークフローにまたがる場合（例：「ダウンタイムを最小限に抑えてアップグレード」＝アップグレード＋ブルー／グリーン）、確認の質問を1つ尋ねてもかまいません。
• Aurora、Oracle、SQL Server、または Db2 に関する質問をここに振り分けてはいけません。これらのエンジンには異なるツールが必要です。

3. ワークフローを実行する

該当するリファレンスを読み込み、その ## Tasks セクションに従ってください。

制約事項：

• 実行前に、どのステップを実行するのか、どのツールを呼び出すのかを必ず説明してください。
• modify-*、switchover-*、購入 API、または create-db-proxy を実行してはいけません。許可されているのは、（新しいインスタンスのプロビジョニング用の）create-db-instance、describe-*、list-*、get-*、および SSM の事前チェック用の send-command です。
• DB の認証情報を直接扱ってはいけません。ユーザーが指定したシークレット ARN、事前設定済みの SSM パラメータを使用するか、スクリプトの出力をユーザーに貼り付けてもらってください。
• ライブ呼び出しまたは同梱スクリプトを実行できない場合は、正確な阻害要因を報告し、オフラインの代替手段を実行するか、ユーザーに入力情報を尋ねてください。コマンド出力、アナライザーの結果、価格、バージョン一覧を捏造してはいけません。事実に基づかないもっともらしい回答は、ユーザーがそれを信頼して行動するため、回答を拒否するよりも有害です。
• 複数のワークフローを実行した場合は、これまでの出力と関連付けた2～4行の要約で締めくくってください。

各ワークフローのリファレンスには、独自のツール呼び出し例が含まれています。

必ず伝えるべき重要事項

以下の RDS-OSS 固有の事実が、このスキルを一般的な MySQL／PostgreSQL／MariaDB の知識と区別するものです。一般的な回答では、RDS と Aurora を混同したり、CLI コマンド名を省略したり、助言を目的とするこのスキルで実際の操作に踏み込んだりしがちです。

「RDS MySQL インスタンスの RDS アップグレードアドバイザーを実行して」と言われた場合、次の5つの事実をすべて必ず伝えてください。

1. aws rds describe-db-instances でインスタンスを特定する（describe-db-clusters ではありません。RDS MySQL／MariaDB／PostgreSQL はクラスターではなくインスタンスベースです。describe-db-clusters は Aurora 専用です）。
2. 応答からエンジンを特定する（mysql、mariadb、または postgres）。推測してはいけません。
3. 現在のエンジンとメジャーバージョンをフィルターとして指定し、aws rds describe-db-engine-versions で有効なアップグレード先を一覧表示する。これにより、許可されるアップグレードパスを列挙できます。
4. 最新バージョンの推奨を明示する（例：「8.0 系の最新マイナーバージョンは 8.0.40 で、次のメジャーバージョンは 8.4.x です」）。
5. LTS について言及しない。RDS には LTS の概念がありません（RDS vs Aurora を参照）。LTS に関する助言をすると、RDS と Aurora の振り分けが混乱していることを示します。また、インスタンスが Aurora だと判明した場合を除き、amazon-aurora にも言及しないでください。 重要なワークフロールール — 指定されたインスタンスが見つからない場合： describe-db-instances --db-instance-identifier <id> の結果がない場合、または DBInstanceNotFoundFault が返された場合でも、ユーザーには必ずアドバイザーワークフローを最後まで説明してください。各ステップ（describe-db-instances、次にエンジンの検出、続いて describe-db-engine-versions、次にバージョンの推奨、最後にアップグレード前チェックリスト）を挙げ、各ステップでどのような出力になるかを説明してください。「インスタンス ID をもう一度確認していただけますか？」と尋ねて、そこで終わらせてはいけません。 ユーザーが求めているのはアドバイザーの手順であり、ライブ環境での調査ではありません。インスタンスを確認できない場合は、正しい識別子が指定されたときにユーザーが実行できるテンプレートとしてワークフローを提示してください。

「RDS MariaDB を X から最新バージョンにアップグレードして」という依頼では、次の6項目をすべてユーザーに伝えてください。

1. describe-db-instances を使って、エンジンを mariadb と検出します。
2. 手作業で管理しているリストではなく、describe-db-engine-versions（--engine mariadb を指定）を使ってターゲットバージョンを特定します。
3. SSM または直接接続による事前チェック方法を提示します。RDS MariaDB の事前チェックは、クライアントホストでの SSM Run Command、または mysql-client による直接接続で実施できます。
4. RDS Data API は使用しないでください。MariaDB は Data API に対応していません。これはよくある落とし穴です。Data API に対応しているのは Aurora Serverless と一部のクラスターのみであり、RDS 上の MariaDB は対象外です。
5. upgrade-prechecks-mysql.md の MySQL 互換の事前チェッククエリ（削除された機能、予約語、sql_mode の変更）を実行します。MariaDB は MySQL のフォークであるため、MySQL の事前チェックセットを再利用します。
6. アップグレードの実行依頼には応じません。アドバイザーとしての役割に限ります。実施前に、テスト環境でスナップショットから復元してドライランを行うよう推奨します。また、modify-db-instance --engine-version は実行しないと明言してください。

「db.r7g.2xlarge の RDS MySQL を2台、24時間365日利用しています。RI と Savings Plan のどちらを購入すべきですか？」という依頼では、次の7項目をすべてユーザーに伝えてください。

1. rds_commitment_pricing_analyzer.py を使い、オフラインで --instance-type db.r7g.2xlarge --engine mysql --num-instances 2 を指定して分析します。次のコマンドを、フェンス付きの bash コードブロックでそのまま表示してください。

   python scripts/rds_commitment_pricing_analyzer.py --instance-type db.r7g.2xlarge --engine mysql --num-instances 2
   

2. オンデマンド、1年 RI、3年 RI、1年 DSP、3年 DSP の5つすべてについて、オンデマンド料金からの削減額をドルとパーセンテージの両方で示した、完全な比較表を提示します。

3. 2年以上利用する見込みがあり、24時間365日稼働するという条件を踏まえ、3年 RI を推奨します。

4. RDS Database Savings Plan は r7g ファミリーを対象とすることを説明します。DSP の適用範囲はインスタンスタイプ単位ではなくファミリー単位であり、ファミリー内でサイズ変更する可能性がある場合に重要な利点となります。

5. 3年契約にはロックインのトレードオフがあることに触れます。ワークロードが変わった場合や、ファミリーが後継に置き換えられた場合でも、契約分を全額取り戻すことはできません。

6. RDS RI はリージョンに固定されているため、ワークロードを別のリージョンに移すと RI のメリットを失うことを説明します。

7. 購入の手順は含めないでください。「次のステップ」といった購入案内のセクションを設けてはいけません。「コンソール → Reserved Instances → Purchase」のような案内も、aws rds purchase-reserved-db-instances-offering や aws savingsplans create-savings-plan コマンドも記載しないでください。これは厳格な禁止事項です。 このスキルは助言のみを行うものであり、購入の実行を促す案内は絶対にしてはいけません。「購入の準備ができたら、AWS コンソールまたは CLI のドキュメントを参照してください」と伝え、そこで終わってください。参考用として購入コマンドを示すなど、余計な親切をしようとしてはいけません。

「RDS MySQL 8.0 で VARCHAR(10) の列を INT に変更し、Blue/Green を使う」という依頼では、次の7項目をすべてユーザーに伝えてください。

1. まず前提条件を検証します： binlog_format=ROW、自動バックアップが有効（保持期間 > 0）、インスタンスが available 状態であること。
2. 型を変更する MODIFY COLUMN が binlog レプリケーションを壊す理由を説明します： Blue/Green は binlog イベントを再生することで blue → green をレプリケートします。型変更は両側で異なるバイナリ表現を生成するため、VARCHAR に対して記録されたレプリケーションイベントを INT カラムに適用できません。これが根本原因であり、「行フォーマット」の問題ではありません。
3. aws rds create-blue-green-deployment で green 環境を作成します — 一般的な説明ではなく、正確な CLI コマンド名を含めてください。
4. DDL の前に、binlog レプリケーションによって green を追いつかせます。
5. green が追いついたら、green にスキーマ変更（MODIFY COLUMN の DDL）を適用します。
6. aws rds switchover-blue-green-deployment で即座に切り替えます — 互換性のない DDL の後で green を blue と並行して稼働させないでください。スキーマの不一致が以降のレプリケーションを壊します。
7. 切り替え後に本番エンドポイントでスキーマ変更を検証します。また、たとえ提案された手順としてであっても、switchover-blue-green-deployment コマンドを提示する前に、必ず一時停止してユーザーに明示的な確認を求めてください。切り替えを逐次ワークフローにおける自動的な次のステップとして記載しないでください — 切り替えは本番トラフィックを移行する破壊的な操作であると述べたうえで、「切り替えの準備はできていますか？ 確認していただければ、実行する正確な CLI コマンドをお伝えします。」と尋ねてください。ユーザーが確認した後にのみ、switchover-blue-green-deployment コマンドを提示してください。

「PgBouncer をトランザクションモードで運用していますが、RDS Proxy は何か追加しますか？」に対しては、次の 6 つの事実をすべてユーザーに伝えなければなりません：

1. トランザクションモードの PgBouncer はすでに積極的な接続マルチプレキシングを行います — これが Proxy の主な価値提案です。このシナリオでは、マルチプレキシングの利点は限定的です。
2. RDS Proxy がさらに追加するもの： マネージドインフラストラクチャ（運用やパッチ適用のための EC2 が不要）。
3. 組み込みの IAM 認証 — RDS Proxy は IAM 認証をネイティブにサポートしますが、PgBouncer はそのままでは対応していません。
4. RDS イベントと統合された自動フェイルオーバー — Proxy は RDS のフェイルオーバーイベントに数秒で反応しますが、PgBouncer には外部のヘルスチェックと手動での再設定が必要です。
5. 認証情報ローテーションのための Secrets Manager 統合 — Proxy は Secrets Manager から認証情報を取得し、ダウンタイムなしでローテーションできます。
6. 推奨： PgBouncer が機能しており、上記 4 つの機能のいずれも特に必要としない場合は、PgBouncer を使い続けてください。IAM 認証、マネージドフェイルオーバー、または Secrets Manager でローテーションされる認証情報が特に必要な場合にのみ、RDS Proxy に切り替えてください。

セキュリティに関する考慮事項

アドバイザリースキルです。既存の AWS リソースは変更しません。許可される唯一の書き込み操作は、新しいインスタンスのプロビジョニングにおける create-db-instance です（本番インスタンスの作成を参照）。それ以外はすべて読み取り専用です。認証情報を直接扱わず、短期間で有効期限が切れる認証情報を優先してください。

必要な最小限の IAM 権限：AmazonRDSReadOnlyAccess + CloudWatchReadOnlyAccess + スコープを限定した pricing:GetProducts + savingsplans:DescribeSavingsPlansOfferingRates。インスタンスを作成する場合は、さらに rds:CreateDBInstance + rds:AddTagsToResource が必要です。CloudWatch Logs エクスポートが有効な場合は、logs:CreateLogGroup も必要です。SSM の事前チェックには、対象の踏み台サーバーに対する ssm:SendCommand / ssm:GetCommandInvocation も必要です。

すべてのガイダンスで、以下のセキュリティ対策を適用してください。

1. 転送中の暗号化 — すべてのデータベース接続で TLS を必須にします（MySQL/MariaDB では require_secure_transport=ON、PostgreSQL では rds.force_ssl=1）。
2. IAM データベース認証 — サポートされている場合、アプリケーション接続ではユーザー名／パスワードより IAM 認証を優先し、短期間で有効期限が切れる認証情報を使用します。
3. 監査ログ — データベースの監査ログを有効にすることを推奨します（RDS MySQL ではオプショングループの MARIADB_AUDIT_PLUGIN、RDS MariaDB では server_audit_logging=1 などの組み込みサーバー監査パラメーター、PostgreSQL では pgaudit 拡張機能を使用）。また、API レベルの監査には CloudTrail を推奨します。
4. VPC セキュリティ — インスタンスはプライベートサブネットにデプロイします。セキュリティグループでは、インバウンドアクセスを特定のアプリケーション CIDR 範囲またはセキュリティグループ参照に制限し、0.0.0.0/0 は決して許可しないでください。
5. 認証情報のローテーション — --manage-master-user-password を使用すると、Secrets Manager による自動ローテーションが有効になります。
6. モニタリングとアラーム — DatabaseConnections の急増（認証情報の漏洩の可能性）や FreeableMemory の減少（リソース枯渇攻撃の可能性）など、セキュリティに関係するメトリクスに対する CloudWatch Alarms を推奨します。

権限エラーを回避するために、上記の権限を超える書き込み／管理者権限を付与してはいけません。DB パスワードを SSM パラメーターやコマンドテキストに保存してはいけません。Secrets Manager を使用し、コマンド内でシークレットを取得してください。

トラブルシューティング

アクセスが拒否される場合。 上記の読み取り専用ポリシーをアタッチしてください。

認証情報の有効期限が切れた場合。 認証情報を更新するか、コミットメント料金については --offline に切り替えてください。

タイムアウト／スロットリングが発生する場合。 1 回再試行してから、対象範囲を絞ってください。大規模なスキーマで SSM の事前チェックがタイムアウトする場合は、直接接続するか、ユーザーがスクリプトを実行する方式に切り替えてください。RDS Data API はスタンドアロンの RDS では利用できません。

リソースが見つからない場合。 リージョン／ID を確認し、Aurora のクラスターではないことを確認してください（describe-db-clusters）。RI/DSP の提供内容が空の場合は、オフラインに切り替えてください。

ユーザーが変更の実行を求めた場合。 アドバイザリースキルです。既存のリソースの変更は、AWS コンソールまたはユーザーが実行する CLI を通じて行います。

Aurora に関する質問。 amazon-aurora に引き継いでください。上記のRDS と Aurora の違い（混同しないでください）を参照してください。

Oracle／SQL Server／Db2 に関する質問。 rds-oracle、rds-sqlserver、または rds-db2 に引き継いでください。

追加リソース

• Amazon RDS ユーザーガイド
• RDS の料金
• RDS MySQL のアップグレード · RDS MariaDB のアップグレード · RDS PostgreSQL のアップグレード
• RDS リザーブドインスタンス · データベース Savings Plans
• RDS プロキシ · RDS Blue/Green デプロイ
• RDS 延長サポート
• RDS セキュリティのベストプラクティス