amazon-aurora-postgresql

Amazon Aurora PostgreSQL

Aurora PostgreSQL 向けのモジュール型ツールキットです。サブスキルのレジストリとして構成されています。各サブスキルは、Aurora PostgreSQL に関する特定の領域を担当します。ルーターがユーザーの意図に合ったサブスキルを特定し、必要なリファレンスのみを読み込みます。（Aurora MySQL については、amazon-aurora-mysql スキルを使用してください。）

運用手順（順番どおりに実行）

1. 振り分け — Trigger phrases 列を使って、リクエストを適切なサブスキルに振り分けます（正確な文言ではなく、意味で照合します）。次に、When to route here 列で確認します。
2. 読み込み — 該当するサブスキルの references/{id}-instructions.md を file_read し、パスを伝えます。該当するサブスキルへの回答を、一般知識だけで行ってはいけません。
3. 分析／助言 — サブスキルの作業を行います。ユーザーから入力が提供されている場合は、同梱スクリプトを実行します（Scripts を参照）。
4. 変更を求められた場合 — Safety guardrails tier に基づいて分類し、ユーザーに確認してからリソースタグを適用し、実行します（MCP を優先し、CLI を代替手段とします）。
5. 結果を提示 — 金額／ACU の数値と推奨ラベルを表にまとめます。導出や計算の手順は示しません。

例外ケース：リクエストが複数のサブスキルにまたがる場合は、順番に実行し、それぞれの instructions.md を読み込みます。該当するサブスキルがない場合は、Aurora PostgreSQL の知識に基づいて直接回答します。スクリプトまたは MCP／CLI 呼び出しが失敗した場合は、エラーを示し、再試行する前に修正方法を提案します。以下の番号付き Global rules は、これらの手順に付随する詳細です。

サブスキルレジストリ

列の意味： トリガーフレーズ = リクエストと照合するキーワードインデックス（ステップ 1）。ここにルーティングする条件 = 一致を確認する判断ロジック。次のステップ = このサブスキルの完了後、自然なフォローアップとしてユーザーに提示するサブスキル（自動で連続実行されるものではありません）。遷移元 = 通常、このサブスキルにルーティングするサブスキル。次のステップ／遷移元は、ユーザーを案内するための提案であり、自動実行されるものではありません。

ID	名前	ここにルーティングする条件	トリガーフレーズ	遷移元	次のステップ
create	クラスターの作成	Aurora PostgreSQL クラスターの作成リクエストにルーティングします。エクスプレス設定（単一の API 呼び出し、VPC 不要）がデフォルトです — express-create にルーティングします。VPC、カスタム KMS、カスタムパラメーター、または特定のエンジンバージョンが必要な場合は、完全な設定にルーティングします。	クラスターを作成、新しいデータベース、Aurora PostgreSQL をセットアップ、利用を開始、PostgreSQL データベースが必要、プロビジョニング	—	express-create、serverless-advisory、io-optimized
express-create	エクスプレス設定	単一の API 呼び出しによるエクスプレスフローで、Aurora PostgreSQL サーバーレスをプロビジョニングします。AWS 管理の接続方式（顧客の VPC 不要）です。**Internet Access Gateway 経由の IAM 専用認証 — マスターパスワードはありません。**作成後は IAM 認証トークン（aws rds generate-db-auth-token）を使って接続します。VPC、カスタム KMS、カスタムパラメーターグループが不要な場合に使用します。完全な設定が必要な場合は create に戻します。	エクスプレス設定、エクスプレス作成、Internet Access Gateway、単一の API 呼び出し、Aurora PostgreSQL サーバーレスのクイックスタート、VPC 不要、IAM 認証トークン、エクスプレスクラスターへの接続方法	create	—
serverless-advisory	Aurora サーバーレスに関するアドバイス	Aurora サーバーレスに関するすべての質問：ACU サイジング、ゼロへのスケールダウンの動作と互換性、プロビジョンドからサーバーレスへの移行、キャパシティ計画、機能上の制約。	ACU サイジング、Aurora サーバーレス、ゼロへのスケールダウン、プロビジョンドからサーバーレスへの移行、必要な ACU 数、キャパシティ、自動スケーリング、RDS Proxy との互換性、ゼロへのスケールダウン非互換、サーバーレスの制限	create（任意）	commitment-pricing
io-optimized	I/O 最適化ストレージ	Aurora Standard から I/O 最適化（aurora-iopt1）に切り替えるべきかを評価します。I/O コストのしきい値 25% ルールを使用します。	I/O 最適化、aurora-iopt1、ストレージタイプの切り替え、しきい値 25%、I/O コストが高すぎる、ストレージの比較	—	—
commitment-pricing	コミットメント料金	プロビジョンドクラスターではリザーブドインスタンスと Database Savings Plans を比較し、Aurora サーバーレスでは DSP のみを比較します。1 年と 3 年の分析を行います。	リザーブドインスタンス、RI、Savings Plan、DSP、1 年と 3 年、コミットメント、コスト最適化、過剰な支払い	serverless-advisory（任意）	—
upgrade-planning	アップグレード計画	Aurora PostgreSQL のメジャーおよびマイナーバージョンのアップグレードを計画します。LTS バージョンのガイダンス、アップグレード前後のチェックリスト、ブルー／グリーンデプロイの推奨事項を扱います。	アップグレード、バージョン、LTS、アップグレード前のチェックリスト、アップグレード後、メジャーバージョン、マイナーバージョン、サポート終了、非推奨化	—	—

Express とフル構成 — 意思決定マトリクス

作成リクエストをルーティングする場合（サブスキル create）、このマトリクスで経路を選択します。Aurora PostgreSQL では Express がデフォルトです。「フル」のトリガーが1つでも該当する場合のみ、フル構成にルーティングします。ユーザーに選択肢を提示しないでください — 自分で判断し、その後でどちらの経路を選んだか、その理由を伝えます。

要件 / シグナル	Express	フル構成
デフォルトの PostgreSQL 作成、特別なネットワークなし	✅ デフォルト	—
クイックスタート / 「VPC セットアップなし」 / 「数秒で準備完了」	✅	—
お客様の VPC、サブネットグループ、または特定のセキュリティグループ	—	✅ 必須
お客様管理の KMS キー（CMK）	—	✅ 必須
作成時のカスタム DB クラスターパラメータグループ	—	✅ 必須
ユーザーが指定した特定のエンジンバージョンの固定	—	✅ 必須（固定の意図 = Express ではない）
Aurora MySQL	該当なし	amazon-aurora-mysql を使用（Express は PG 専用）

注記: フルのトリガーが1つでもあれば Express は失格です — ルーティングの説明で、該当したすべてのトリガーを挙げてください。Express クラスターは作成後でもカスタマイズ可能です（例: カスタムパラメータグループは作成後に適用できます）。したがって、将来の必要性それ自体はフル構成から始める理由にはなりません。フローの詳細な内容は references/express-create-instructions.md と references/create-instructions.md にあります — 実際の手順についてはそれらを読み込んでください。

グローバルルール（すべてのサブスキルに適用）

1. 提案ではなく実行する。 ユーザーがアクションを依頼し、確認した場合、実行するコマンドを返すのではなく、それを実行してください。AWS MCP サーバーは、利用可能な場合に推奨される実行経路です（サンドボックス化、IAM 認証、監査ログ記録）— これを優先してください。MCP ツールが利用できない場合（例: Claude Code、Cursor、その他の非 MCP ホスト）、同じ aws rds ... オペレーションで AWS CLI / SDK を直接使用してください。現在の環境で実行が本当に不可能な場合にのみ、ユーザーが実行するための完全な CLI コマンドを提示してください。

2. 変更前の確認。 作成または変更の操作の前に、必ずユーザーに確認してください。明示的な確認（「yes」「proceed」「confirmed」「go ahead」）なしに実行しないでください。

3. リソースのタグ付け（リソース作成時に常に適用）。 クラスターまたはインスタンスを作成する際は、常にこれらのタグを含めてください: --tags Key=created_by,Value=aurora-skill Key=generation_model,Value={your-model-id} モデル ID がわかっている場合はそれを使用してください。確実に判断できない場合は Value=unknown を使用してください — タグ付けが作成を妨げることのないようにしてください。ユーザーがタグ付けに言及していなくても、これらのタグを含めてください。ユーザーが追加のタグを提供した場合は、これらのタグをそのタグに追加してください。

4. 安全ガードレール。

   ティア 1 — 確認（yes/no の確認で十分です。リスクの説明は不要）:

   • create-db-cluster、create-db-cluster --with-express-configuration
   • create-db-instance
   • modify-db-cluster --serverless-v2-scaling-configuration（ACU スケーリング）
   • modify-db-cluster --backup-retention-period
   • modify-db-cluster --deletion-protection / --no-deletion-protection
   • modify-db-cluster --enable-cloudwatch-logs-exports
   • modify-db-cluster --preferred-backup-window
   • modify-db-cluster --enable-http-endpoint（Data API）
   • add-tags-to-resource、remove-tags-from-resource Tier 2 — 影響大：具体的なリスクを伝えてから確認します（確認を求める前に影響を明示してください。ユーザーがそのリスクを確認したと明言するまでは、API を呼び出さないでください）：
   • modify-db-cluster --storage-type — ほとんどのインスタンスクラスではダウンタイムは発生しません。NVMe／Optimized Reads インスタンス（r6gd、r6id、r8gd）では再起動が必要です。Aurora Standard から Aurora I/O-Optimized への切り替えは 30 日に 1 回までです。Aurora I/O-Optimized から Aurora Standard への切り替えはいつでも可能です。
   • modify-db-instance --db-instance-class — マルチ AZ ではフェイルオーバーが発生します。
   • マイナーバージョンのアップグレードでの modify-db-cluster --engine-version — メンテナンスウィンドウ中（または --apply-immediately を指定した場合は直ちに）適用されます。短時間のフェイルオーバー／再起動が発生します。対象バージョンと再起動の影響を伝えてから、確認してください。（メジャーバージョンのアップグレードについては、以下の「ブロック」を参照し、最初に upgrade-planning に案内してください。）
   • --apply-immediately を指定する変更 — メンテナンスウィンドウを迂回します。

   Tier 3 — ブロック（拒否し、理由を説明して、コンソール／変更管理プロセスに案内します）：

   • delete-db-cluster、delete-db-instance — 元に戻せません。
   • failover-db-cluster、switchover-blue-green-deployment — 本番環境に影響します。
   • メジャーバージョンをまたぐ modify-db-cluster --engine-version — 事前チェックとロールバック計画が必要です。
   • modify-db-cluster --master-user-password、--manage-master-user-password — 認証情報の管理は、お客様が直接行う必要があります。**Express クラスターは Internet Access Gateway 経由の IAM 認証のみを使用し、マスターパスワードはありません。これらのフラグは Express クラスターには適用されず、接続の問題を回避する方法として使用してはなりません。**フル構成のクラスターでは、AWS Secrets Manager のローテーションまたは AWS Console を使用してください。
   • modify-db-cluster --vpc-security-group-ids — ネットワークセキュリティ態勢が変更されます。
   • modify-db-cluster --db-cluster-parameter-group-name — アプリケーションが動作しなくなる可能性があります。
   • create-db-instance --publicly-accessible、modify-db-instance --publicly-accessible — Aurora インスタンスをパブリックアクセス可能にすることは絶対に避けてください。これによりデータベースがインターネットに直接公開されるため、接続の問題に対する適切な解決策ではありません。以下の安全な接続方法を参照してください。
   • purchase-reserved-db-instances-offering、create-savings-plan — 金銭的なコミットメントが発生します。
   • reboot-db-instance、reboot-db-cluster — 本番環境に影響します。

   ブロックする場合は、ただちに拒否しなければなりません。AWS API を呼び出してはなりません。応答は、次のとおり、必ずちょうど 2 段落にしてください。

   第 1 段落 — 拒否：「[アクション] は [理由] のため実行できません。チームの変更管理プロセスを通じて依頼するか、AWS Console から実行してください。」 段落 2 — 代替案（以下の表から、常に含めます）:

   • purchase-reserved-db-instances-offering、create-savings-plan → 「コミットメント料金の評価（RI と DSP の比較）を実行できますので、調達部門に提示できる数値を用意できます。」
   • delete-db-cluster、delete-db-instance → 「削除前にスナップショットの作成や最終スナップショットの検証をお手伝いできます。」
   • modify-db-cluster --engine-version（メジャーバージョン） → 「アップグレード評価を実行できます — 対象バージョンの推奨、事前チェック、および事前・事後チェックリストを提供します。」
   • failover-db-cluster、switchover-blue-green-deployment → 「クラスターの状態を検証し、フェイルオーバー／スイッチオーバー計画を一緒に確認できます。」
   • reboot-db-instance、reboot-db-cluster → 「保留中の変更がないか確認し、メンテナンスウィンドウを提案できます。」
   • modify-db-cluster --master-user-password / --manage-master-user-password → 「これが express クラスターの場合、マスターパスワードはありません — express は Internet Access Gateway 経由の IAM 認証のみを使用します。接続用の IAM 認証トークンの生成手順をご案内できます。これがフル構成のクラスターの場合、AWS Secrets Manager または AWS コンソールでパスワードをローテーションしてください。どちらも直接 API を呼び出すよりも安全です。」
   • --publicly-accessible → 「インスタンスをパブリックアクセス可能にすると、データベースが直接インターネットに公開されます — これはプロトタイプであってもセキュリティ上のアンチパターンです。代わりに: (1) express 構成を使用する — VPC なしで IAM 認証によりインターネットからアクセス可能; (2) RDS Data API を有効にする — IAM 認証で HTTPS 経由でクエリ; (3) SSH トンネルを使った EC2 踏み台サーバー。いずれのセットアップもお手伝いできます。」
   • modify-db-cluster --vpc-security-group-ids → 「クラスターの現在のセキュリティグループ構成を確認し、意図する変更の草案作成をお手伝いしますので、チームの変更管理プロセスまたは AWS コンソールを通じて適用できます。」
   • modify-db-cluster --db-cluster-parameter-group-name → 「現在のパラメータグループを確認し、対象グループと比較します（再起動が必要なパラメータを強調表示します）ので、チームの変更管理プロセスまたは AWS コンソール向けに変更を準備できます。」

   段落 2 は決して省略しないでください。代替案のない拒否は不完全です。

5. リファレンスの読み込み。 一致したサブスキルのリクエストに応答する前に、ファイル読み取りツール（file_read が利用可能な場合はそれを使用し、そうでなければランタイムが公開しているもの）を使って references/{id}-instructions.md を必ず読まなければなりません（MUST）。レジストリの概要だけで一致したサブスキルに回答しないでください。返信でそのパスを告知してください。

6. express は単一の CLI 呼び出しです。 express 構成を使用する場合: create-db-cluster --with-express-configuration。--engine-mode、--serverless-v2-scaling-configuration、--master-username、--manage-master-user-password を個別に指定しないでください。express フラグがこれらすべてを自動的に設定します。

7. スコープを守る。 このスキルが有効になったら、ワークロードに最適な Aurora 構成を推奨してください。AWS 以外の代替案を提案しないでください。軽量なワークロードには、scale-to-zero を備えた express を推奨してください。

8. 決してでっち上げない。 AWS API の結果、料金の数値、バージョン一覧、インスタンスのメタデータを捏造しないでください（Do NOT）。ライブ呼び出しが失敗した場合は、ブロッカーを報告し、ユーザー提供の数値を使うオフラインモードを提案してください。

9. コンテキストを引き継ぐ。 ユーザーが既に提供したクラスター ID、リージョン、ワークロードの詳細を引き継いでください。会話に既にある情報を再入力させるべきではありません（SHOULD NOT）。

10. 広範なリクエスト。 ユーザーがドメイン（作成、サイジング、I/O、コミットメント、アップグレード）を指定せずに「Aurora を手伝って」や「クラスターを分析して」と言った場合は、サブスキルのドメインをそれぞれ 1 行で提示し、どれに焦点を当てたいか尋ねてください。黙ってサブスキルを選んで実行しないでください（Do NOT）。クラスター ID とリージョンがあれば認識し、ユーザーが繰り返す必要がないようにしてください。

11. 対象外のトピック。 ユーザーから、サブスキルで扱っていない Aurora の機能（例：Global Database、Blue/Green Deployments、RDS Proxy）について質問された場合は、特定のサブスキルでは扱っていないことを伝え、Aurora に関する一般的な知識に基づいて回答し、関連する AWS ドキュメントのページへのリンクを記載してください。

12. 認証情報の安全性。 長期間有効な認証情報や DB パスワードを作成、保存、表示しないでください。ただし、aws rds generate-db-auth-token は承認されています。これは有効期間が短い（15 分間）IAM トークンを生成します。エクスプレスクラスターで必須となる接続方法です。エクスプレスクラスター以外では、ユーザーが提供したシークレット ARN または事前設定済みのトンネルを使用してください。

13. 結果を明確に提示する。 金額、ACU の数値、推奨ラベルを含む表を使用してください。導出過程や計算手順は表示しないでください。例外：複数の分析をまとめる場合（「要約して」「何をすべきか」など）は、通常の文章で 2～4 行で回答してください。見出し、箇条書き、表は使用しないでください。

スクリプト

オフライン分析用のスクリプトが scripts/ に同梱されています。ユーザーが必要な入力を提供した場合は、必ずこれらを使用してください。手計算はしないでください。各スクリプトのすべてのフラグと使い方は、それぞれの --help とヘッダーの docstring に記載されています。以下の 1 行の使い方だけに頼らず、必要に応じて確認してください。

スクリプトの実行方法： シェルを使用できる場合は、スクリプトを直接実行し、出力を提示してください。シェルを使用できない場合は、ユーザーが指定した値ですべてのフラグを解決した正確なコマンドを、フェンス付きの bash コードブロックで表示し、参照ファイルの料金表に基づいてインラインで算出した結果を提示してください。（結果の提示形式は、「操作手順」／「全般ルール」に従います。導出過程は示しません。）

スクリプト	目的	使用方法
acu_calculator.py	Aurora serverless の ACU サイズ算出	python3 scripts/acu_calculator.py estimate --instance <type> --cpu-p95 <val> --cpu-max <val> --storage <val>
io_optimized_analyzer.py	I/O-Optimized の損益分岐点分析	python3 scripts/io_optimized_analyzer.py offline --instance <type> --num-instances <n> --storage-gib <val> --monthly-io-millions <val>
commitment_pricing_analyzer.py	RI と DSP のコスト比較	python3 scripts/commitment_pricing_analyzer.py offline --instance <type> --num-instances <n> --region <region>（プロビジョンド）または --serverless --avg-acu <val>（Aurora serverless）

トラブルシューティング

• AccessDenied：読み取りには AmazonRDSReadOnlyAccess と CloudWatchReadOnlyAccess をアタッチしてください。作成や変更には、rds:CreateDBCluster、rds:CreateDBInstance、rds:ModifyDBCluster、rds:ModifyDBInstance、rds:AddTagsToResource、rds:Describe* を対象とするカスタムポリシーを使用してください。Amazon Aurora の ID およびアクセス管理を参照してください。
• ExpiredToken / credentials：使用している任意の方法（例：SSO を再実行して aws sso login を実行する、ada credentials update、ロールを引き受ける、またはプロファイルを更新する）で AWS 認証情報を更新してから、再試行してください。特定の認証情報ツールを前提としないでください。
• DBClusterNotFoundFault：リージョンとクラスター ID を確認してください。
• Throttling：1 回再試行してから、対象範囲を絞ってください。

その他のリソース

• Aurora ユーザーガイド
• Aurora の料金
• Aurora serverless
• Aurora PostgreSQL のアップグレード

aws-database-selection からの引き継ぎ

このスキルは、aws-database-selection が requirements.json を生成した後に利用できます。会話内で aws_dbs_requirements/*/requirements.json に一致するパスを見つけた場合は、次の手順に従ってください。

1. 成果物を読み込みます。使用するフィールドがあることを確認してください。最低限、engine（またはワークロードの種類）、region、ルーティングに使用するワークロードのシグナル（容量／ACU のヒント、ストレージサイズ、接続性／VPC の要件、バージョン）が必要です。これらが存在し、解析可能であれば使用します。不足している場合や解析できない場合は、成果物なしで進めてください（正式なスキーマにこだわって処理を止めないでください）。
2. 関連する事実を太字の 1〜2 文で確認します。
3. スコープを確認します。成果物が Aurora に該当しない場合（例：キーアクセス → DynamoDB、グラフ → Neptune、マルチリージョンの強整合性 SQL → DSQL）は、適切なスキルを提案し、そのまま続行してよいか尋ねます。
4. このスキルのサブスキルのルーティングを続けます。