rds-db2

Amazon RDS for Db2

概要

Amazon RDS for Db2 は、マネージド IBM Db2 LUW サービスです。RDS for Db2 はマネージドサービスであり、ホストへの SSH 接続、エージェントのインストール、C/COBOL でのフェンスなし外部ストアドプロシージャの実行はできません。Java ストアドプロシージャは sqlj.install_jar で動作します。このスキルでは、IBM ライセンスを使用したプロビジョニング、クライアントのインストールと TLS 接続、Linux/AIX/Windows/z/OS/AS400 上のセルフマネージド Db2 からの移行、S3 バックアップと復元、Multi-AZ とクロスリージョンのスタンバイレプリカ、SYSCTRL/SYSMAINT 権限に代わる RDSADMIN ストアドプロシージャという、オペレーター向けのライフサイクルを扱います。

また、セキュリティと運用に関する次の 6 つの追加領域も扱います。カスタマーマネージド KMS キー（BYOK）、Kerberos 認証を使用するセルフマネージド Active Directory、S3 への Db2 監査ログ出力、コードページと照合順序の選択（EBCDIC、CCSID）、IAM 権限の最小化、Multi-AZ のレイテンシーとフェイルオーバーに対応するための EC2/RDS の同一配置です。

AWS MCP サーバーの使用を推奨しますが、必須ではありません。すべての操作は AWS CLI 構文で記述されており、AWS MCP サーバーの有無にかかわらず実行できます。

該当するサブスキルのリファレンスに移動します。該当するリファレンスのみを読み込んでください。

よくあるタスク

依存関係の確認

RDS for Db2 のワークフローを実行する前に、必要なツールが存在することを確認してください。まだインストーラーや API 呼び出しを実行しないでください。

• すべての RDS API 呼び出しに AWS CLI v2
• 管理された仕組み（IAM ロール、インスタンスプロファイル、ada credentials update）による AWS 認証情報 — 貼り付けた認証情報は使用しないでください
• クライアントのインストール：bash/curl へのアクセス。root として、また db2inst1 として実行します
• エアギャップ環境でのインストール：インターネットに接続されたマシンと、S3、SSM、Secrets Manager 用の VPC エンドポイントが設定されたターゲット
• メインフレームの移行：z/OS へのアクセス、IBM ADB2GEN ライセンス、Python 3
• BYOK / カスタマーマネージド KMS：インポートするキー素材をラップするための openssl と、get-parameters-for-import の出力を解析するための jq
• セルフマネージド Active Directory + Kerberos：クライアント上の realmd、sssd、adcli、krb5-workstation と、有効な Kerberos チケット（kinit で TGT を取得し、klist で確認します）
• Kerberos JDBC テスト：JDK と Db2 JDBC ドライバー db2jcc4.jar v4.33 以降（これより前のドライバーバージョンは securityMechanism=11 の Kerberos サポートがありません）

制約：

• エージェントは、インストールまたは AWS API コマンドを実行する前に、依存関係を必ず確認しなければなりません。
• 認証情報は IAM ロールまたはインスタンスプロファイルを通じて必ず渡す必要があるため、エージェントはユーザーに認証情報の貼り付けを求めてはなりません。
• エージェントは、不足している依存関係をユーザーに伝え、ユーザーが中止を選択した場合は必ずその判断を尊重しなければなりません。
• エージェントは各ステップの実行前に、そのステップで何を行うのか、なぜ行うのか、どのツールを呼び出すのかを説明しなければなりません。

分類してルーティングする

ユーザーの質問を適切なサブスキルのリファレンスに割り当て、そのファイルだけを読み込みます。

ユーザーの発言	サブスキル	読み込むファイル
create / provision / parameter group / IBM customer ID / IBM site ID / License Manager / BYOL / GovCloud	プロビジョニング	provisioning.md
connect / SQL30082N / SQL1531N / DSN / CLP / Python / Java / CloudShell / airgap	接続	connectivity.md
SSL / TLS / GSKit / certificate / truststore / bundle.pem	接続 TLS	connectivity-tls.md
Python driver / JDBC / laptop / multi-instance / db2_use	接続ドライバー	connection-drivers.md
migrate / DMS / Q Replication / IIDR / AIX / Windows / AS400 / precheck	移行	migration.md
z/OS / mainframe / ADB2GEN / schema conversion	メインフレーム移行	mainframe-migration.md
code page / collation / CCSID / EBCDIC / UTF-8 / CODEUNITS32 / territory	コードページと照合順序	code-page-collation.md
snapshot / backup / restore / rollforward / PiTR / S3 integration	バックアップと復元	backup-restore.md
Multi-AZ / standby replica / read replica / HADR / cross-region / failover	HA と DR	ha-dr.md
parameter group / RDSADMIN / scale / storage / CloudWatch / registry variable	運用	operations.md
BYOK / customer-managed KMS / bring your own key / imported key material / multi-region key	BYOK	byok-kms.md
Active Directory / Kerberos / domain join / self-managed AD / kinit / SPN / realm	AD と Kerberos	ad-kerberos.md
audit / DB2_AUDIT / audit policy / audit to S3 / option group	DB2 監査	db2-audit.md
minimum IAM / least privilege / IAM policy / trust policy / permissions	最小限の IAM	minimum-iam.md
colocation / co-locate / EC2 app latency / ASG / ALB / failover routing	コロケーション	colocation.md

制約：

• エージェントは、コンテキストを絞るため、ユーザーの質問に一致するリファレンスファイルだけを必ず読み込んでください。
• エージェントは、RDSADMIN プロシージャのシグネチャを創作してはなりません。パラメーターの順序が間違っていると実行時に失敗するため、必ずリファレンスファイルに記載されたシグネチャを引用してください。
• 回答の情報源がブログの場合、ユーザーが詳細を確認できるよう、エージェントは必ずブログの URL を引用してください。
• 質問が 2 つのサブスキルにまたがる場合（例：「ほぼゼロダウンタイムで z/OS を移行する」や「BYOK とクロスリージョンのスタンバイを組み合わせる」）、エージェントは該当する各リファレンスを読み込み、内容を組み合わせて回答してください。

ワークフローの実行

振り分け後は、参照ファイルに基づいた、具体的で実行可能な回答をユーザーに提示します。

パラメーターの取得：

• 必須パラメーター（リージョン、インスタンス識別子、ソース／ターゲット ARN、S3 バケット、プレフィックス、--master-username の値）は、すべて最初の1回のメッセージで収集する必要があります。
• パラメーターの形式を指定する必要があります。リージョンは us-east-1 形式、インスタンス識別子は ^[a-zA-Z][a-zA-Z0-9-]{0,62}$、ARN は arn:aws:rds:<region>:<account>:db:<name>、S3 バケットは小文字で3～63文字です。
• エージェントは、直接入力、JSON／YAML ファイルのパス、または URL によるパラメーター指定を受け付ける必要があります。

ツールの使用：

• RDS 操作には AWS CLI を使用します（例：aws rds create-db-instance-read-replica --db-instance-identifier <name> --source-db-instance-identifier <arn> --replica-mode mounted --region <dr-region>）。すべての操作を AWS CLI の構文で記述することで、AWS MCP サーバーがインストールされているかどうかにかかわらず実行できます。
• インストール手順を書き直すのではなく、同梱スクリプト（db2-driver.sh、db2client-configure.sh、db2client-airgap.sh、functions.sh）を使用します。
• 移行計画、アップグレード計画、検証レポートは、実行時に作業ディレクトリ内に作成するローカルの artifacts/<app-name>/ ディレクトリに書き込みます（これは実行時の出力先であり、配布されるスキルには含まれません）。

制約：

• 動作が決定的な場合、エージェントは「Multi-AZ を有効にする」のような説明ではなく、正確な CLI コマンドを提示する必要があります。
• エージェントは IAM ロールまたはインスタンスプロファイルを通じて AWS 認証情報を取得する必要があり、ユーザーに認証情報の貼り付けを求めてはなりません。
• 公開されている資料に基づく回答には、ユーザーが確認できるよう、エージェントは必ず元となるブログまたはドキュメントの URL を記載する必要があります。
• エージェントは、長文の成果物をローカルの artifacts/<app-name>/ ディレクトリ（実行時に作業ディレクトリ内に作成）に書き込み、ワークスペースを確認できるようにする必要があります。
• マネージド RDS for Db2 でリクエストされた操作がサポートされていない場合、エージェントはその制限を明確に述べる必要があります。「サポートに制限がある」や「特別な設定で可能」などと曖昧にしてはなりません。また、サポートされる代替策を提示します（たとえば、フェンスなしの C／COBOL ストアドプロシージャはサポートされていないため、sqlj.install_jar を使って Java で書き直すか、SQL PL で書き直します）。
• AWS MCP サーバーの使用を推奨しますが、必須ではありません。MCP サーバーを使用する場合は、call_aws で位置指定のファイルシステム引数を使うより、インライン JSON 文字列を優先します。これは MCP を使う場合のみの指針であり、必須要件ではありません。操作を実行する唯一の方法として call_aws や run_script を扱ってはなりません。AWS CLI コマンドは単独で常に実行できます。

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

RDS for Db2 リソース（create-db-instance、create-db-parameter-group、Multi-AZ デプロイ用の create-db-cluster、スタンバイレプリカ用の create-db-instance-read-replica）を作成するときは、必ず RDS のレコードリスト形式の --tags 構文を使って、次のタグを含めます。

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

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

BYOK 暗号化インスタンス（create-db-instance --storage-encrypted --kms-key-id ...）、監査用オプショングループ（create-option-group）、カスタマーマネージド KMS キーなど、このスキルが作成するすべてのリソースにも同じ規則を適用します。KMS キーには、KMS のタグ構文に従い、--tags TagKey=created_by,TagValue=rds-db2-skill TagKey=generation_model,TagValue={your-model-id} を付けます。

ユーザーがタグ付けに言及していなくても、このスキルを通じて作成されたリソースを識別できるよう、これらのタグを含めます。ユーザーが追加のタグを指定した場合は、既存のタグを置き換えずに追加します。既存のリソースに add-tags-to-resource でタグを付ける場合も同様です。

エージェントが常に伝えるべき RDS 管理情報

これらのRDS for Db2固有の情報が、このスキルを一般的なIBM Db2の知識と区別するものです。一般的なDb2の回答では、RDSで管理される制約（フェンスなしのC／COBOL非対応、Secrets Managerのローテーションによる副作用、rdsadmin.*プロシージャ）や、AWSネイティブの移行ツールに関する詳細（DMSのz/OS制限、ADB2GENとSCTの違い）が省略されがちです。

「DR用のクロスリージョン・スタンバイレプリカを作成する」場合は、以下の6つの事実をすべて必ず伝えてください。

1. aws rds create-db-instance-read-replicaを、--replica-mode mountedおよびクロスリージョンのソースARNとともに使用します。Db2のクロスリージョン・スタンバイではマウント済みレプリカモードを使用し、トランザクション型リードレプリカモードは使用しません。
2. **ソース側の前提条件：**ソースインスタンスで自動バックアップが有効になっていること（バックアップ保持期間が0より大きいこと）。
3. **ターゲットリージョン側の前提条件：**コマンドを実行する前に、ターゲットリージョンにカスタムパラメータグループを作成しておくこと。
4. **ターゲットリージョン側の前提条件：**ターゲットリージョンでKMSキーを使用できること（マルチリージョンKMSキー、またはターゲットリージョンのカスタマーマネージドKMSキー）。
5. **状態に関する前提条件：**すべてのデータベースがactive状態で、再起動の保留がなく、クロスリージョンレプリカを妨げるライセンスモデルの制限がないこと。
6. **マウント済みレプリカとトランザクション型レプリカの違いを説明します。**マウント済みレプリカは、アプリケーションからの読み取りやSQLを受け付けません。昇格が可能なDR用スタンバイとしてのみ存在します。読み取り負荷の分散用途は提案しないでください。

「S3からDb2バックアップを復元する（マルチパート、Nファイル）」場合は、以下の6つの事実をすべて必ず伝えてください。プロシージャ名は一切省略しないでください。

1. --feature-name S3_INTEGRATIONを指定して**aws rds add-role-to-db-instanceからS3アクセス権限を持つIAMロールをアタッチします。**
2. **rdsadmin.set_configurationから復元パフォーマンスのパラメータを設定します。**復元を開始する前に、USE_STREAMING_RESTORE、RESTORE_DATABASE_NUM_BUFFERS、PARALLELISMを調整します。
3. **5つのパラメータを次の順序で指定してrdsadmin.restore_databaseを呼び出します。**データベース名、復元モード（OFFLINEまたはONLINE）、S3プレフィックス、S3バケット、リージョンです。複数ファイル（マルチパート）バックアップは共有プレフィックスで処理され、マルチパート専用のフラグパラメータはありません。（シグネチャ：rdsadmin.restore_database(dbname, type, prefix, bucket, region)。）
4. ONLINE復元モードの場合は、続けてrdsadmin.rollforward_databaseでアーカイブログを再生し、その後rdsadmin.complete_rollforwardで完了させます。OFFLINE復元ではロールフォワードは不要です。
5. **rdsadmin.get_task_statusで進行状況を監視します。**すべてのrdsadminプロシージャはタスクIDを返すため、そのIDをポーリングします。
6. プライベートサブネットからインターネットへのアウトバウンド通信がない場合は、S3用VPCエンドポイントが必要であることを警告します。また、ソースバックアップとRDSインスタンスのエンジンバージョン間のDb2バージョン互換性についても警告します（前方互換性はありますが、後方互換性はありません）。

「C／COBOLのフェンスなし外部ストアードプロシージャをRDS for Db2へリフト＆シフトできるか？」場合は、以下の4つの事実をすべて必ず伝えてください。

1. CおよびCOBOLのフェンスなし外部ストアードプロシージャは、RDS for Db2ではサポートされていません。「サポートされていません」と断定してください。「一部サポート」や「特別な設定をすれば可能」といった表現で曖昧にしないでください。
2. **RDS for Db2では、すべてのルーチンをフェンス付きにする必要があります。**これはフラグで変更できるものではなく、マネージドサービスのアーキテクチャ上の制約です。
3. Javaストアードプロシージャはサポートされています。sqlj.install_jarからインストールします。C／COBOLのストアードプロシージャはJavaまたはSQL PL（OracleのPL/SQLに相当するDb2の手続き型SQL）で書き直す必要があります。
4. どのストアードプロシージャがフェンスなしで実行されているかの特定を支援し、呼び出し頻度に基づいて書き換えの優先順位を付けることを提案してください（呼び出し頻度の高いコードパスを最優先）。

「Db2 for z/OSからRDS for Db2へ、ほぼゼロのダウンタイムで移行する」場合は、以下の5つの事実をすべて必ず伝えてください。

1. z/OS からのダウンタイムをほぼゼロにするには、Q Replication（IBM IIDR）、Qlik Replicate、または Precisely を使用してください — これらは、Db2 for z/OS をソースとして、RDS for Db2 にストリーミングできる CDC ツールです。
2. AWS DMS が Db2 for z/OS からサポートするのは、フルロードのみです。 DMS は z/OS ソースからの CDC をサポートしていません。ダウンタイムをほぼゼロにする切り替えには DMS を使用せず、1 回限りの一括ロードに使用してください。
3. z/OS からのスキーマ変換には ADB2GEN を使用してください。 AWS SCT はソースとして Db2 for z/OS をサポートしていません — これはよくある落とし穴です。z/OS ソースに対して SCT を推奨しないでください。
4. コードページ変換（EBCDIC → UTF-8）が、移行における主なリスクです。 切り替えの前に、照合順序とコードページのマッピングを明示的に計画してください — 気付かないうちにデータが破損するのが、起こりうる障害です。
5. ターゲットの RDS インスタンスでは、照合順序を明示的に選択し、z/OS ソースの意味的な並び順に合わせてください。

RDS 管理のマスターユーザーで「SQL30082N — USERNAME AND/OR PASSWORD INVALID」が発生した場合（ユーザーがパスワードを変更していない場合）、次の 4 点をすべてユーザーに伝える必要があります。

1. 正常に接続できていたのに SQL30082N が発生する場合、ほとんどの場合、Secrets Manager でマスターパスワードがローテーションされています。 RDS for Db2 は Secrets Manager のスケジュールに従ってマスターパスワードをローテーションします。キャッシュされたパスワードを使用しているクライアントは、ユーザー側で何も変更していなくても SQL30082N が発生するようになります。
2. 修正方法：db2_use <instance-id> を実行します（functions.sh または同梱のヘルパーを使用）。これにより、Secrets Manager から現在のパスワードを取得し、新しい値で ~/.db2env を書き換えます。
3. 別の方法として、db2_test_connection を実行し、ヘルパーによる修正が最初から最後まで正しく機能したことを確認できます。
4. db2_use がインストールされていない場合、ユーザーは aws secretsmanager get-secret-value を使用して現在のパスワードを取得し、ローカルの認証情報キャッシュを手動で更新する必要があります。問題の原因はパスワードのローテーションなので、パスワードをローテーションするよう伝えないでください。

「RDS for Db2 の BYOK ／カスタマー管理の KMS キー」については、次の 6 点をすべてユーザーに伝える必要があります。

1. 独自のキーマテリアルをインポートする場合は、--origin EXTERNAL を指定したマルチリージョン KMS キーを使用してください。 これにより、同じキー ID とキーマテリアルを DR リージョンにレプリケートできます。
2. キーを作成するプリンシパルには、そのキーに対する kms:CreateGrant と kms:DescribeKey が必要です。 これらがないと、インスタンスの作成に失敗します。
3. 暗号化はインスタンス作成時に --storage-encrypted --kms-key-id <alias|arn> を指定して設定します。 既存の未暗号化インスタンスをその場で暗号化することはできません — スナップショットの作成 → copy-db-snapshot --kms-key-id → restore-db-instance-from-db-snapshot の順に実行してください。
4. リージョン間の DR では、まずマルチリージョンキーを DR リージョンにレプリケート（kms:ReplicateKey）し、その後、レプリカキーを使用してリージョン間で copy-db-snapshot を実行してください。
5. インポートトークンの有効期限は 24 時間です — 期限切れで import-key-material が失敗した場合は、get-parameters-for-import を再実行して、新しいトークンとラッピングキーを取得してください。
6. ブログ記事 DBBLOG-5188 と byok-kms.md を参照してください。 KMS パラメータ名をでっち上げないでください。

「RDS for Db2 の Kerberos を使用したセルフマネージド Active Directory」については、次の 6 点をすべてユーザーに伝える必要があります。

1. RDS は --domain-fqdn、--domain-ou、--domain-auth-secret-arn、--domain-dns-ips を使用して AD に参加します — セルフマネージド AD の方法であり、AWS Managed Microsoft AD は不要です。
2. Secrets Manager のシークレットではキー SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME（sAMAccountName のみ — DOMAIN\ プレフィックスは付けません。付けると作成に失敗します）と SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD を使用します。専用の KMS キーで暗号化し、aws:SourceArn と aws:SourceAccount で保護された rds.amazonaws.com を信頼するリソースポリシーを設定します（混乱した代理人への対策）。
3. 9 つの AD 権限を、1 つの OU にスコープを限定した専用サービスアカウントに委任します。ADUC の委任ウィザードではなく、ADSI Edit を使用して、User オブジェクトの servicePrincipalName に読み取り／書き込み権限を付与してください（ウィザードではこの属性がフィルタリングされます）。これが最もよくある失敗です。
4. RDS とドメインコントローラーの間で AD ポートを開放します。DNS 53、Kerberos 88 および 464、LDAP 389 および 3268、RPC 範囲 49152～65535 です。 RPC 範囲を開放し忘れることが、断続的なドメイン参加失敗の最大の原因です。時刻のずれは 5 分未満にしてください。
5. RDS のマスターユーザーはローカルアカウントであり、Kerberos チケットを取得できません。 AD ユーザーには kinit と GRANT CONNECT が必要です。Kerberos JDBC では securityMechanism=11 と、sslCertLocation で指定するリージョン固有の PEM を使用します（global-bundle.pem は使用しないでください）。
6. セルフマネージド AD のブログと ad-kerberos.md を参照してください。describe-db-instances ... DomainMemberships を実行し、Status: joined と表示されることを確認します。

トラブルシューティング

エラー	原因	対処方法
SQL30082N	Secrets Manager でパスワードがローテーションされた	db2_use <instance-id> を実行します。ヘルパーが最新のパスワードを再取得し、~/.db2env に書き込みます。
SQL1531N	DSN がまだキャッシュにない	db2 terminate を実行してキャッシュをクリアしてから、再試行します。それでも失敗する場合は、db2client-configure.sh を再実行します。
SQL01013N / TCP タイムアウト	セキュリティグループが 50000/50443 をブロックしている	SG のインバウンドルールを確認し、クライアントの SG を TCP 50000（プレーン）または 50443（SSL）に追加します。
GSKit / SSL 証明書エラー	RDS 証明書バンドルがない、または RSA 証明書が先頭にない	RDS トラストストアから <region>-bundle.pem を再ダウンロードし、db2client-configure.sh を再実行します。
RDSADMIN 呼び出しでアクセス拒否	IAM ロールに S3_INTEGRATION 機能がない	aws rds add-role-to-db-instance --feature-name S3_INTEGRATION --role-arn <role-arn> --db-instance-identifier <id> を実行します。
「database in rollforward pending」でリストアに失敗する	ONLINE リストアにより DB がロールフォワード状態になった	各アーカイブログに対して rdsadmin.rollforward_database を呼び出し、その後 rdsadmin.complete_rollforward を呼び出します。
スタンバイレプリカの作成に失敗する	前提条件が不足している	自動バックアップが有効であること、DR リージョンにカスタムパラメータグループがあること、KMS マルチリージョンキーがあること、保留中の rdsadmin タスクがないこと、およびすべてのデータベースがアクティブ状態であることを確認します。
AD ドメイン参加の Status が joined ではない	RPC ポート範囲がブロックされている、シークレットの形式が正しくない、または SPN 属性がない	RDS と DC の間で RPC 49152～65535 を開放し、シークレットのユーザー名が DOMAIN\ プレフィックスのない sAMAccountName であることを確認します。また、ADSI Edit を使用して User オブジェクトの servicePrincipalName に権限を付与します。ad-kerberos.md を参照してください。
import-key-material が失敗する — トークンの有効期限切れ	インポートトークンの発行から 24 時間以上経過している	get-parameters-for-import を再実行して新しいトークンとラッピングキーを取得し、openssl でマテリアルを再ラップしてから、インポートを再試行します。byok-kms.md を参照してください。
RDS API によるスロットリング	API リクエストレートの上限を超えた	ジッターを加えた指数バックオフを使用し、操作をバッチ処理します。Service Quotas を確認してください。

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

本番環境で RDS for Db2 をデプロイする際に助言する場合は、以下の制御を提示してください。これらは、サブスキルが詳しく説明しているセキュリティガイダンスをまとめたものです。

• 保存時および転送中の暗号化 — インスタンスは必ず --storage-encrypted を指定して作成してください。キーの所有権とコンプライアンスのために、カスタマーマネージド KMS キー（BYOK）を使用し、DR にはマルチリージョンキーを使用してください。すべての接続で TLS（ポート 50443、<region>-bundle.pem）を強制し、本番環境では平文で接続しないでください。byok-kms.md と connectivity-tls.md を参照してください。（ガイドライン 1）
• 最小権限の IAM — minimum-iam.md に記載されているスコープを限定したポリシーと信頼ポリシーを使用してください。*FullAccess のマネージドポリシーは絶対にアタッチしないでください。iam:PassRole のスコープを限定し、リソースレベルの権限に対応する変更ステートメントには ARN パターンを指定してください。（ガイドライン 5）
• ネットワークの分離 — インスタンスはプライベートサブネットに配置し、セキュリティグループはアプリケーション／送信元の SG に制限してください（0.0.0.0/0 は絶対に指定しないでください）。S3／SSM／Secrets Manager には VPC エンドポイントを使用し、トラフィックがパブリックインターネットを経由しないようにしてください。colocation.md を参照してください。（ガイドライン 5）
• 監査ログとモニタリング — Db2 の監査ログを S3 に有効化し（db2-audit.md）、RDS 拡張モニタリングと、RDS／KMS／Secrets Manager の API コールに対する CloudTrail を有効にしてください。ログイン失敗と設定変更に対してアラームを設定してください。（ガイドライン 12）
• シークレットのローテーション — --manage-master-user-password を指定してプロビジョニングし、RDS がマスターパスワードを Secrets Manager に保存してローテーションするようにしてください。平文のパスワードを埋め込まないでください。ローテーション後は、db2_use <instance-id> を使用してクライアントを更新してください。（ガイドライン 13）
• バックアップの暗号化と保持期間 — バックアップの保持期間を設定し、スナップショットの自動作成分と手動作成分を KMS キーで暗号化してください。また、Db2 の監査ログまたはバックアップ用のバケットには、S3 バケットの暗号化とライフサイクル／保持期間の設定を適用してください。（ガイドライン 13）

追加リソース

対象範囲内のドキュメントとブログ

• AWS ドキュメント — RDS for Db2：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDSDb2.html
• AWS ドキュメント — RDS for Db2 の IAM 権限：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.html
• AWS ドキュメント — RDS for Db2 の Kerberos 認証：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/db2-kerberos.html
• ブログ — CloudShell から RDS for Db2 に接続する：https://aws.amazon.com/blogs/database/connect-to-amazon-rds-for-db2-using-aws-cloudshell/
• ブログ — セルフマネージドの Db2 Linux を RDS for Db2 に復元する：https://aws.amazon.com/blogs/database/restore-self-managed-db2-linux-databases-in-amazon-rds-for-db2/
• ブログ — Q Replication を使用して AIX／Windows から RDS for Db2 へダウンタイムをほぼゼロに抑えて移行する：https://aws.amazon.com/blogs/database/near-zero-downtime-migrations-from-self-managed-db2-on-aix-or-windows-to-amazon-rds-for-db2-using-ibm-q-replication/
• ブログ — クロスリージョンのスタンバイレプリカ：https://aws.amazon.com/blogs/database/configure-amazon-rds-for-db2-standby-replicas-for-high-availability-and-faster-disaster-recovery/
• ブログ — メインフレームの DDL 変換（z/OS から RDS for Db2）：https://aws.amazon.com/blogs/database/migrating-tables-from-ibm-db2-for-z-os-to-amazon-rds-for-db2/
• ブログ — メインフレーム移行時のコードページと照合順序：https://aws.amazon.com/blogs/database/choosing-the-right-code-page-and-collation-for-migration-from-mainframe-db2-to-amazon-rds-for-db2/
• ブログ — RDS for Db2 でカスタマーマネージド KMS キーを使用する（DBBLOG-5188）：https://aws.amazon.com/blogs/database/bring-your-own-key-to-amazon-rds-for-db2-with-a-customer-managed-kms-key/
• ブログ — RDS for Db2 で Kerberos を使用するセルフマネージドの Active Directory：https://aws.amazon.com/blogs/database/use-kerberos-authentication-with-a-self-managed-active-directory-for-amazon-rds-for-db2/

関連トピック（引用リソース。まだ参照先サブスキルには展開されていません）

これらの関連トピックは、今回の反復では参照先にルーティングされる項目として展開されていません。各トピックは、以下の引用リソースから確認できます。

• RDS for Db2 のリバースログシッピング（DBBLOG-5352）：https://aws.amazon.com/blogs/database/implement-reverse-log-shipping-for-amazon-rds-for-db2/
• 複数アカウント接続：ワークスペースのソース 04-db2-client/RDS-Db2-Multiple-Account-Connectivity/
• Terraform によるプロビジョニング：ワークスペースのソース 04-db2-client/RDS-Db2-Terraform/
• CIS コンプライアンス：ワークスペースのソース 04-db2-client/CIS-Compliance/
• db2mon によるモニタリング：ワークスペースのソース 04-db2-client/db2mon_RDS/
• 圧縮によるコスト削減：ワークスペースのソース 04-db2-client/Compression-Savings/
• 移行の前提条件チェック（DBBLOG-5048）：https://aws.amazon.com/blogs/database/migrate-from-ibm-db2-to-amazon-rds-for-db2-using-a-migration-prerequisite-check/
• S3 からのロード：ワークスペースのソース 04-db2-client/load-from-s3/
• Java ストアドプロシージャのサンプル：ワークスペースのソース 04-db2-client/sample-java-sp/

ブログカタログ

公開済みの RDS for Db2 ブログおよびサンプルツールの正規リストは、https://github.com/aws-samples/sample-rds-db2-tools/tree/main で管理されています。ブログ記事と関連コードの最新一覧については、こちらを参照してください。

• 関連スキル（Db2 LUW から PostgreSQL への移行）：rds-postgres-migration（コーパスに存在する場合）。

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

このスキルは直接呼び出すことも、aws-database-selection 親スキルで要件のヒアリングを行い、requirements.json アーティファクトを生成した後に、そのスキルから開始することもできます。直近の会話に aws_dbs_requirements/*/requirements.json に一致するバッククォートで囲まれたパスがある場合は、aws-database-selection/references/handoff-contract.md のエントリープロトコルに従ってください。

1. file_read を使用してアーティファクトを読み取ります。
2. aws-database-selection/references/workload-primary-artifact.schema.json に照らして検証します。形式が不正、または読み取れない場合はユーザーに伝え、アーティファクトなしで進めます。
3. アーティファクトの概要を示す高レベルの事実（主要な形状、厳しい制約、移行の背景）を引用し、関連する内容を1～2文の太字で伝えます。アーティファクト全体をそのまま繰り返してはいけません。
4. スコープを確認します。このスキルの対象は Amazon RDS for Db2、つまり Db2 z/OS または LUW からの移行、HADR、スタンバイレプリカ、SQL PL ルーチン、Q Replication のカットオーバーです。アーティファクトの workload_primaries.dominant_shapes または migration_context がこのスコープに一致しない場合は、引き継ぎ契約に従って控えめなバックプレッシャーを示します。Db2 から PostgreSQL へのリファクタリングには amazon-aurora を、Db2 が移行元でない場合は aws-database-selection に戻ることを提案し、その後、戻るか、このまま進めるかをユーザーに尋ねます。アーティファクトを適用範囲外の目的に黙って使用してはいけません。
5. このスキル固有のワークフローを進めます。要件に基づく推奨事項では、アーティファクトのパスを根拠として引用します。

親の aws-database-selection スキルが使用する、厳選された RDS for Db2 の選定情報は assets/selection-knowledge-input.json にあります（人が読みやすい形式の補助ファイルは assets/selection-knowledge-input.md です）。これらには、対象となる移行元シナリオ、厳しい制約、HA／DR オプション、セキュリティ領域が、再利用可能な構造化形式でまとめられています。情報を再構成せず、厳選された選定情報を参照する必要がある場合は、これらを読み取ってください。

このスキルのユーザー向け出力はすべて、引き継ぎ契約に定められた Markdown プリミティブのみを使用する書式規則に従います。太字のラベル、パスや列挙値を囲むバッククォート、選択肢を示す箇条書きを使用し、ASCII アートや罫線文字は使用しません。