mcpField
D
dms-schema-conversion

dms-schema-conversion

github.com/awsデータ・データベース3.3k4.8k 回インストール1 日前に更新
リポジトリ

dms-schema-conversion について

初期設定から既存プロジェクトでの変換まで、DMS Schema Conversion のライフサイクルを扱うスキルです。プロジェクト選択、評価と変換、変換済みオブジェクトのエクスポートや適用を支援します。

主な機能

  1. 01移行プロジェクトのセットアップ
  2. 02ソースメタデータのインポート
  3. 03データベース変換の複雑さ評価
  4. 04選択したスキーマオブジェクトの変換
  5. 05変換済みオブジェクトのエクスポートや適用

活用シーン

  1. 01データベース移行プロジェクトの準備
  2. 02移行前の変換作業量の見積もり
  3. 03選択したスキーマやテーブルの変換

MCP 対応

実行、監査ログ、可観測性のために AWS MCP サーバーを推奨します。サーバーが利用できない場合は AWS CLI でも操作できます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/aws/agent-toolkit-for-aws --skill dms-schema-conversion

インストール後、Claude Code で/dms-schema-conversionを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
action-items.md
cancel-operations.md
schema-conversion-operations.md
setup-wizard.md
troubleshooting.md

詳細

DMS スキーマ変換

概要

このスキルでは、初回セットアップから既存プロジェクトでの変換実行まで、DMS スキーマ変換のライフサイクル全体を扱います。

効率的な実行、監査ログ、可観測性を実現するため、AWS MCP サーバーの使用を推奨します。MCP サーバーを利用できない場合は、すべての操作を AWS CLI から直接実行できます。

主なドキュメント：

全般的な制約： 対象の資料に基づいて操作する前に、リンク先のドキュメントを取得して必ず読んでください。参照資料（選択ルール、変換ルール、トラブルシューティングガイド、ネットワーク設定など）の内容を記憶に頼ってはいけません。ドキュメントには、エンジンや API のバージョンによって変わる、ベンダー固有の詳細が記載されています。

ガードレール — このスキルのファイルの場所（MCP とローカルインストール）

このスキルの読み込み方法は 2 通りあり、同梱ファイルの参照先が異なります。参照ファイルを読む前に、スキルがどの方法で読み込まれたかを確認してください。

  • AWS MCP の retrieve_skill ツールを通じて読み込まれた場合： スキルはローカルファイルシステムにインストールされていません。各参照ファイルは、file パラメーター（例：file="references/setup-wizard.md"）を指定して retrieve_skill で必ず取得してください。これらのパスはディスク上に存在しないため、ローカルで file_read を実行してはいけません。
  • ローカルにインストールされている場合（例：.kiro/skills/dms-schema-conversion/ または ~/.claude/skills/dms-schema-conversion/）：相対パスを使って、ローカルのスキルディレクトリからファイルを読み込んでください。

この区別は、スキルに同梱されたファイルにのみ適用されます。ユーザーデータやセッションの成果物は、常にユーザーの作業ディレクトリから読み書きしてください。retrieve_skill を通じて顧客データを取得したり、書き込んだりしてはいけません。

依存関係の確認

作業を始める前に、AWS CLI コマンドを実行できることを確認してください。

制約：

  • AWS CLI コマンドを実行できることを、MCP サーバーのツール経由またはシェルから直接、必ず確認してください。
  • 実行方法が利用できない場合は、必ず顧客に伝え、作業を続行するかどうかを尋ねてください。
  • 使用する AWS リージョンを必ず顧客に確認してください。STS の応答から推測してはいけません（リージョンフィールドは含まれていません）。顧客が判断できない場合は、AWS_DEFAULT_REGION 環境変数、または使用中の --region フラグを確認するよう提案してください。
  • このエージェント型ワークフロー中に実行する呼び出しを CloudTrail の userAgent フィールドで識別できるよう、このスキルで AWS CLI コマンドを実行する前に、必ず AWS_EXECUTION_ENV 環境変数を AWSMCP-DMSSchemaConversion-Skill に設定してください。この値は AWS CLI と botocore により、exec-env/AWSMCP-DMSSchemaConversion-Skill としてリクエストの User-Agent に追加されます。セッション中に一度設定する（export AWS_EXECUTION_ENV=AWSMCP-DMSSchemaConversion-Skill）か、各コマンドの前に指定してください（AWS_EXECUTION_ENV=AWSMCP-DMSSchemaConversion-Skill aws dms ...）。この値はベストエフォートの識別マーカーにすぎず、アクセス制御には使われません。また、User-Agent の単一トークンとして扱われるよう、スペースを含めてはいけません。

プロジェクトの選択

既存の移行プロジェクトがあるか確認します。

aws dms describe-migration-projects
  • プロジェクトが1つだけ存在する場合 → 顧客に「移行プロジェクト <name> が見つかりました。このプロジェクトを使用しますか、それとも新規作成しますか？」と尋ねます。使用することを確認した場合は、migration_project_identifier を保存してアクションメニューに進みます。新規作成を希望する場合は、セットアップウィザードを実行します。
  • 複数のプロジェクトが存在する場合 → プロジェクトの一覧を表示して1つ選ぶよう顧客に尋ねるか、新規プロジェクトの作成を提案します。migration_project_identifier を保存して、アクションメニューに進みます。
  • プロジェクトが存在しない場合 → 「移行プロジェクトが見つかりませんでした。作成しますか？」と尋ねます。はいの場合は、setup-wizard.mdを読み込み、フェーズ1からセットアップウィザードをすべて実行します。ウィザードの完了後、自動インポートを実行してから、アクションメニューに進みます。

自動インポート

このセクションは、セットアップウィザードで新規プロジェクトを作成した後にのみ実行します。既存のプロジェクトでは実行しないでください。

  1. ソースサーバーからすべてのスキーマをインポートする選択ルールを作成します。server-name には、データプロバイダー識別子（ARN内の短いID。例：JIFET2LUZJEJZPDYSOSGANOA2M）、またはデータプロバイダーの設定にあるリテラルの ServerName 値（オフラインのソースの場合は "offline" など）を使用します。SQL Serverの場合は、オブジェクトロケーターに database-name を必ず含めてください。JSON形式については、DMS Schema Conversionの選択ルールを参照してください。

  2. --origin SOURCE --refresh と手順1の選択ルールを指定して start-metadata-model-import を実行します。応答から RequestIdentifier を抽出します。

  3. DMSウェイターを使用してインポートの完了を待ちます。

    aws dms wait metadata-model-imported \
  --migration-project-identifier <migration_project_identifier> \
  --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>'

    ウェイターが失敗した場合、または利用できない場合は、--filter Name=request-id,Values=<RequestIdentifier> を指定して、30秒ごとに describe-metadata-model-imports をポーリングします。終了ステータスは SUCCESS（続行）または FAILED（応答の Error フィールドでエラーを確認）です。

  4. 検出されたスキーマを表示します： 成功したら、ルートレベルで --origin SOURCE を指定して describe-metadata-model-children を呼び出し、インポートされたスキーマ／データベースを一覧表示します。検出された名前を顧客に提示し、正しいデータベース接続が確立されたことを確認してもらいます。

    「インポートが完了しました。次のスキーマ／データベースが見つかりました：<list>。こちらで問題ありませんか？」

  5. アクションメニューに進みます。

アクションメニュー

利用可能であれば、構造化された選択ツール（例：AskUserQuestion）を使ってアクションメニューを表示します。これにより、お客様はクリックまたは選択できるリストを利用できます。

SQL Server → PostgreSQL/Aurora PostgreSQL のプロジェクトの場合（単一選択の質問「何をしますか？」として表示します）：

  1. データベースを変換 — スキーマオブジェクトをターゲットエンジン向けに変換します（変換評価レポートも生成します）
  2. データベースを評価 — 互換性評価を実行します（変換評価レポートも生成します）
  3. ステートメントを変換 — 単一の SQL ステートメントを変換します
  4. クリーンアップ — 移行プロジェクトと関連する DMS リソースを削除します

その他すべてのエンジンの組み合わせの場合（単一選択の質問「何をしますか？」として表示します）：

  1. データベースを変換 — スキーマオブジェクトをターゲットエンジン向けに変換します（変換評価レポートも生成します）
  2. データベースを評価 — 互換性評価を実行します（変換評価レポートも生成します）
  3. ツリーを操作 — メタデータモデルツリーを参照します
  4. クリーンアップ — 移行プロジェクトと関連する DMS リソースを削除します

お客様はいつでも「その他」からカスタムリクエストを入力できます（例：「ツリーを操作」「データベース統計を表示」「終了」）。お客様が「その他」を選択し、このスキルで対応できるアクションを説明した場合は、それに応じて処理します。

各アクションの完了後、同じ選択肢を再度表示して、このメニューに戻ります。

メタデータの読み込みに関する注意： start-metadata-model-import（Refresh=false を指定）、start-metadata-model-assessment、start-metadata-model-conversion はいずれも、対象オブジェクトのソースツリーを読み込みます。現在のセッションで特定のサブツリーのメタデータをすでにインポートしている場合、再インポートは不要です。これらの操作では、すでに読み込まれているメタデータを使用できます。

データベースを変換する

  1. 変換対象を確認する: 何を変換したいか（例：「すべてのスキーマ」「スキーマ public」「PROD_ で始まるテーブル」）をお客様に確認します。

  2. 選択ルールを作成する: お客様の自然言語での指定を、選択ルールの JSON に変換します。形式、ワイルドカード、ベンダー固有のロケーターについては、DMS Schema Conversion の選択ルールを参照してください。

  3. 変換を実行する: 移行プロジェクトと選択ルールを指定して start-metadata-model-conversion を呼び出します。応答から RequestIdentifier を取得します。

  4. 完了を待つ: DMS のウェイターを使用して待機します。

    aws dms wait metadata-model-converted \
  --migration-project-identifier <migration_project_identifier> \
  --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>'

    ウェイターが失敗するか利用できない場合は、--filter Name=request-id,Values=<RequestIdentifier> を指定して describe-metadata-model-conversions を 30 秒ごとにポーリングします。終端ステータスは SUCCESS（続行）または FAILED（エラーを確認）です。

  5. 変換評価レポートをエクスポートする: 変換が成功したら、rule-action: "explicit" を指定して選択ルールとともに export-metadata-model-assessment を呼び出します（この API では include ではなく明示的なルールが必要です）。PDF と CSV の両方のレポートについて、S3 リンク（PdfReport.S3ObjectKey と CsvReport.S3ObjectKey）をお客様に提供します。

  6. 概要を表示する: aws s3 cp s3://<bucket>/<CsvReport.S3ObjectKey> ./Summary.csv を使用して、概要 CSV を S3 からダウンロードします。内容をお客様に提示します。カテゴリごとのオブジェクト数、自動で変換された数、複雑さの各レベルでアクション項目がある数を示します。

  7. 変換後のサブメニュー: 概要を表示した後、選択肢を提示します。ターゲットがライブターゲット（仮想ターゲットではない）の場合に限り、「ターゲットに適用」を表示します。

    「次に何をしますか？

    1. アクション項目を修正 — 変換評価レポートのアクション項目を確認して修正します
    2. スクリプトとしてエクスポート — 変換済み DDL を SQL スクリプトとして S3 にエクスポートします
    3. ターゲットに適用 — 変換済みオブジェクトをターゲットデータベースに適用します（ライブターゲットのみ）
    4. 戻る — アクションメニューに戻ります」
    • アクション項目を修正: action-items.md を読み込み、記載されている修正ワークフローに従います。
    • スクリプトとしてエクスポート: aws dms start-metadata-model-export-as-script --migration-project-identifier <migration_project_identifier> --origin TARGET --selection-rules '<json>' を実行します。RequestIdentifier を取得します。aws dms wait metadata-model-exported-as-script --migration-project-identifier <id> --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>' を実行して待機します。完了したら S3 リンクを提供します。
    • ターゲットに適用: aws dms start-metadata-model-export-to-target --migration-project-identifier <migration_project_identifier> --selection-rules '<json>' を実行します。お客様が確認した場合は、必要に応じて --overwrite-extension-pack を渡します。RequestIdentifier を取得します。aws dms wait metadata-model-exported-to-target --migration-project-identifier <id> --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>' を実行して待機します。完了したらお客様に知らせます。
    • 戻る: アクションメニューに戻ります。

完了後、お客様に次に何をしたいか尋ねます。

データベースを評価する

評価では、オブジェクトを実際に変換することなく、変換の複雑さを分析し、変換評価レポートを生成します。変換を実行する前に、移行に必要な作業量を把握したいとお客様が希望する場合に使用してください。

重要： お客様が同じ範囲ですでに変換を実行している場合、個別に評価を行う必要はありません。変換によって、すでに変換評価レポートが生成されています。お客様に次のように伝えてください：「実行済みの変換による変換評価レポートがすでにあります。代わりにそのレポートを表示しますか？それとも、別の範囲で評価を再実行しますか？」

  1. 評価対象を確認する： 何を評価したいか（例：「すべてのスキーマ」、「スキーマ pg_catalog」、「PROD_ で始まるテーブル」）をお客様に確認します。

  2. 選択ルールを作成する： お客様の自然言語による指定を、選択ルールの JSON に変換します。形式、ワイルドカード、ベンダー固有のロケーターについては、DMS Schema Conversion の選択ルールを参照してください。

  3. 評価を実行する： 移行プロジェクトと選択ルールを指定して start-metadata-model-assessment を呼び出します。応答から RequestIdentifier を取得します。

  4. 完了を待つ： DMS ウェイターを使用して待機します。

    aws dms wait metadata-model-assessed \
  --migration-project-identifier <migration_project_identifier> \
  --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>'

    ウェイターが失敗した場合、または利用できない場合は、--filter Name=request-id,Values=<RequestIdentifier> を指定して describe-metadata-model-assessments を 30 秒ごとに呼び出し、ポーリングします。終端ステータスは SUCCESS（続行）または FAILED（エラーを確認）です。

  5. 変換評価レポートをエクスポートする： 成功したら、同じ選択ルールを指定して export-metadata-model-assessment を呼び出します。PDF レポートと CSV レポートの両方の S3 リンク（PdfReport.S3ObjectKey と CsvReport.S3ObjectKey）をお客様に提供します。レポートには、変換の複雑さに関する統計、アクション項目、推定作業量が含まれます。

  6. 概要を表示する： aws s3 cp s3://<bucket>/<CsvReport.S3ObjectKey> ./Summary.csv を使用して、概要 CSV を S3 からダウンロードします。その内容をお客様に提示します。カテゴリごとのオブジェクト数、自動的に変換された数、各複雑さレベルでアクション項目がある数を示してください。

  7. アクション項目の修正を提案する： お客様に次のように確認します。

    「アクション項目の修正をお手伝いしましょうか？」

    「はい」の場合は、action-items.md を読み込み、そこに記載されている修正ワークフローに従います。

完了後、お客様に次に何をしたいかを確認します。

アクション項目を確認する

action-items.md を読み込み、そこに記載されているワークフローに従います。

完了後、お客様に次に何をしたいかを確認します。

ツリーを操作する

メタデータツリーは、データベーススキーマを階層的に表します。次の2種類の要素が含まれます。

  • オブジェクト — SQL 定義を持つ実際のデータベースオブジェクト（テーブル、関数、ビュー、シーケンス、インデックス）
  • カテゴリ — ナビゲーション用にオブジェクトを整理する仮想的なグループコンテナー（「スキーマ」、「テーブル」、「関数」）。SQL 定義はありません。

ツリーではオンデマンド読み込みが使用されます。メタデータは、インポートされた場合にのみデータベースから取得されます。詳しくは、メタデータモデルの操作をご覧ください。

ナビゲーションでは、2つの API を使用します。

  • describe-metadata-model-children — 指定されたノードの子を返します。各子には、さらに下の階層に進むための独自の SelectionRules が含まれます。
  • describe-metadata-model — 特定のオブジェクトの名前、タイプ、SQL 定義を返します。

どちらも --origin SOURCE または --origin TARGET が必要で、explicit 選択ルールのみを受け付けます。

  1. ツリーのルートを表示する： ルートレベルを対象とする選択ルールと --origin SOURCE を指定して、describe-metadata-model-children を呼び出します。ツリーが空の場合は、メタデータのインポートを自動的に実行し（自動インポートと同じ）、ツリーのルートを再表示します。

  2. 移動する： 応答内の各子には MetadataModelName と SelectionRules が含まれます。子を表示して、次に何をするかお客様に尋ねます。

    • 子を表示 — 子の SelectionRules を --selection-rules パラメーターとして指定し、describe-metadata-model-children を呼び出して子の階層に進みます
    • 定義を表示 — 選択したオブジェクトの DDL を表示します（手順3を参照）。カテゴリではなく、オブジェクトでのみ使用できます。
    • 上へ移動 — 親ノードに戻ります
    • ツリーを終了 — アクションメニューに戻ります

  3. 定義を表示する： 子の SelectionRules と --origin SOURCE を指定して、describe-metadata-model を呼び出します。応答には Definition（SOURCE DDL）と TargetMetadataModels（変換後の対応オブジェクトのリスト。それぞれ独自の SelectionRules を持ちます）が含まれます。TARGET DDL を取得するには、TargetMetadataModels[0] の SelectionRules と --origin TARGET を指定して、もう一度 describe-metadata-model を呼び出します。どちらも SOURCE と TARGET と明記して表示します。

  4. データベースから更新する： お客様から更新を依頼された場合は、現在のツリー位置を範囲とする選択ルール、--origin SOURCE --refresh を指定して、start-metadata-model-import を実行します。RequestIdentifier を抽出します。aws dms wait metadata-model-imported --migration-project-identifier <id> --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>' を使用して完了を待ちます。更新が完了したら、現在のノードの子を再表示します。

完了後、次に何をしたいかお客様に尋ねます。

ステートメントの変換

制限事項： この機能は、SQL Server → PostgreSQL/Aurora PostgreSQL の移行プロジェクトでのみ利用できます。それ以外のソース／ターゲットエンジンの組み合わせでは、このオプションを提示または表示しないでください。

  1. コンテキストを特定する： メタデータツリーをたどって、ターゲットの場所を見つけます。SQL Server の場合はサーバー → データベース → スキーマ、その他のエンジンの場合はサーバー → スキーマです。describe-metadata-model-children を使用してノードをたどり、スキーマレベルに到達します。顧客にスキーマ（SQL Server の場合はデータベースとスキーマ）を選択してもらいます。ツリーが空の場合は、場所を手動で指定するよう顧客に依頼します。

  2. SQL ステートメントを取得する： 変換したい SQL ステートメントを顧客に尋ねます。

  3. スキーマの選択ルールを作成する： スキーマの場所を対象とする選択ルールを作成します。書式とベンダー固有のロケーターについては、DMS Schema Conversion の選択ルールを参照してください。

  4. メタデータモデルを作成する： 一意のモデル名（例：statement-<timestamp>）を生成します。次の引数を指定して start-metadata-model-creation を呼び出します。

    • --selection-rules — ステップ 3 で作成したスキーマの選択ルール
    • --metadata-model-name — 生成したモデル名
    • --properties '{"StatementProperties": {"Definition": "<sql_statement>"}}'

    レスポンスから RequestIdentifier を抽出します。次のコマンドで待機します：aws dms wait metadata-model-created --migration-project-identifier <id> --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>'。

  5. ステートメントの選択ルールを作成する： 特定のステートメントを対象とする選択ルールを作成します。書式については、DMS Schema Conversion の選択ルールを参照してください。statement-name にはモデル名を設定します。

  6. 作成したモデルを変換する： ステップ 5 で作成したステートメントの選択ルールを指定して start-metadata-model-conversion を呼び出します。RequestIdentifier を抽出します。次のコマンドで待機します：aws dms wait metadata-model-converted --migration-project-identifier <id> --filter 'Name=schema-conversion-operation-id,Values=<RequestIdentifier>'。

  7. 変換結果を表示する： ステップ 5 のステートメントの選択ルールと --origin SOURCE を指定して describe-metadata-model を呼び出します。レスポンスから TargetMetadataModels[0].SelectionRules を抽出します。次に、そのターゲット選択ルールと --origin TARGET を指定して describe-metadata-model を呼び出します。Definition フィールドの変換後 SQL を、顧客にわかりやすく提示します。

  8. 変換評価レポートをエクスポートする： ステップ 5 のソース選択ルールを指定して export-metadata-model-assessment を呼び出します。PDF と CSV のレポートへの S3 リンクを顧客に提供します。

完了後、次に何をしたいか顧客に尋ねます。

データベースの統計情報

お客様からソースデータベースの統計情報（オブジェクト数、オブジェクトの種類、スキーマのサイズ、全般的な概要など）について質問された場合は、評価を実行し、結果を簡潔にまとめて提示します。

  1. 選択ルールを作成します： お客様の対象範囲に基づいて作成します。特定のスキーマまたはオブジェクトが指定されている場合は、それに合わせて対象範囲を設定します。対象範囲が指定されていない場合は、ソースサーバー上のすべてのスキーマ（ワイルドカード %）をデフォルトとして使用します。JSON 形式については、DMS Schema Conversion の選択ルールを参照してください。

  2. 評価を実行します： 移行プロジェクトと選択ルールを指定して、start-metadata-model-assessment を呼び出します。実行の詳細については、schema-conversion-operations.mdを参照してください。

  3. schema-conversion-operations.mdの説明に従って、DMS ウェイターまたは代替のポーリングを使用して、完了を待ちます。

  4. 変換評価レポートをエクスポートします： 同じ選択ルールを指定して、export-metadata-model-assessment を呼び出します。

  5. ダウンロードして、お客様が求めた情報のみを提示します： S3 から Summary CSV をダウンロードします。

    aws s3 cp s3://<bucket>/<CsvReport.S3ObjectKey> ./Summary.csv

    レポートには多くのデータポイントが含まれています。お客様が求めた情報のみを提示してください。レポート全体をそのまま出力しないでください。たとえば：

    • 「テーブルはいくつありますか？」と尋ねられた場合 → テーブル数のみを表示します
    • 特定のスキーマについて尋ねられた場合 → そのスキーマの統計情報のみを表示します

  6. 次のステップを提案します： 変換の複雑さを確認するか、変換を進めるかを尋ねます。

制約：

  • お客様が対象範囲を指定した場合は、それを使用します。指定がない場合は、すべてのスキーマをデフォルトとして使用します。
  • お客様が求めた情報のみを提示します。求められていないデータで圧倒しないでください。
  • 統計情報は、分かりやすい表形式で提示します。

完了したら、次に何を行いたいかお客様に尋ねます。

クリーンアップ

移行プロジェクトと関連する DMS リソースを削除します。リソースは依存関係の順序に従って削除する必要があります。

  1. お客様に確認します： 削除するリソースを列挙し、確認を求めます。

    aws dms describe-migration-projects --filter Name=migration-project-identifier,Values=<migration_project_identifier>

    プロジェクト名、ソース／ターゲットのデータプロバイダー、およびインスタンスプロファイルを表示します。

  2. 移行プロジェクトを削除します：

    aws dms delete-migration-project \
  --migration-project-identifier <migration_project_identifier>

  3. データプロバイダーを削除します： ソースとターゲットの両方のデータプロバイダーを削除します。

    aws dms delete-data-provider \
  --data-provider-identifier <source_data_provider_identifier>
aws dms delete-data-provider \
  --data-provider-identifier <target_data_provider_identifier>

  4. インスタンスプロファイルを削除します：

    aws dms delete-instance-profile \
  --instance-profile-identifier <instance_profile_identifier>

  5. サブネットグループを削除します：

    aws dms delete-replication-subnet-group \
  --replication-subnet-group-identifier <subnet_group_identifier>

  6. 完了を確認します： すべての DMS Schema Conversion リソースが削除されたことをお客様に伝えます。

制約：

  • リソースを削除する前に、お客様から明示的な確認を必ず得てください。
  • 必ず次の順序で削除してください：最初に移行プロジェクト、次にデータプロバイダー、続いてインスタンスプロファイル、最後にサブネットグループを削除します。順序を誤ると、依存関係により削除に失敗します。
  • 基盤となるインフラストラクチャ（VPC、サブネット、セキュリティグループ、RDS インスタンス、Secrets Manager のシークレット）は削除しないでください。これらは DMS Schema Conversion のクリーンアップ対象外です。

完了したら、次に何を行いたいかお客様に尋ねます。

キャンセルに関する注意

実行中の非同期操作において、お客様からキャンセルの依頼があった場合は、適切なキャンセルコマンドの対応付けについてcancel-operations.mdを参照してください。

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

  • 認証情報： すべてのデータベース認証情報は AWS Secrets Manager に保存されます。データプロバイダーの設定に認証情報を埋め込んだり、出力に記録したりしないでください。
  • 保存時の暗号化： S3 バケットでは SSE-S3 暗号化（デフォルト）が使用されます。SSE-KMS は DMS Schema Conversion ではサポートされていません。
  • 転送中の暗号化： オンライン接続では、require またはそれより強い SSL モードを使用してください。none は、隔離されたテスト環境でのみ使用してください。
  • 最小権限の IAM： すべての IAM ロールでは、混乱した代理人に関する条件キー（aws:SourceAccount、aws:SourceArn）と、範囲を限定したリソース ARN を使用します。
  • ネットワークアクセス： DMS インスタンスプロファイルは、セキュリティグループでアクセスが制限された VPC サブネット内で動作します。
  • 詳細については、DMS のセキュリティに関するベストプラクティスを参照してください。

エラー処理

操作が失敗したり、エラーが返されたりした場合は、troubleshooting.md を読み込み、そのガイダンスに従って問題を診断し、解決してください。エラーの内容をお客様にわかりやすく説明し、再試行する、別の操作を試す、終了するという選択肢を提示してください。

コメント

Markdown 対応