

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AMS ワークロード取り込み (WIGS)
<a name="ams-workload-ingest"></a>

**Topics**
+ [ワークロードの移行: Linux と Windows の前提条件](ex-migrate-instance-prereqs.md)
+ [移行でリソースを変更する方法](ex-migrate-changes.md)
+ [ワークロードの移行：標準プロセス](mp-migrate-stack-process.md)
+ [ワークロードの移行: CloudEndure ランディングゾーン (SALZ)](ex-migrate-instance-cloud-endure.md)
+ [AMS Tools アカウント (ワークロードの移行)](tools-account.md)
+ [ワークロードの移行: Linux の取り込み前検証](ex-migrate-instance-linux-validation.md)
+ [ワークロードの移行: Windows の取り込み前検証](ex-migrate-instance-win-validation.md)
+ [ワークロード取り込みスタック: の作成](#ex-workload-ingest-col)

AMS クラウド移行パートナーで AMS ワークロード取り込み変更タイプ (CT) を使用して、既存のワークロードを AMS マネージド VPC に移動します。AMS ワークロード取り込みを使用すると、移行したインスタンスを AMS に移行した後にカスタム AMS AMI を作成できます。このセクションでは、移行パートナーと自分自身が AMS ワークロードの取り込みのために実行するプロセス、前提条件、および手順について説明します。

**重要**  
オペレーティングシステムは、AMS ワークロードの取り込みでサポートされている必要があります。サポートされているオペレーティングシステムについては、「」を参照してください[ワークロードの移行: Linux と Windows の前提条件](ex-migrate-instance-prereqs.md)。  
ワークロードとアカウントはそれぞれ異なります。AMS はお客様と協力して、成功する結果に備えます。

次の図は、AMS ワークロードの取り込みプロセスを示しています。

![\[Workflow diagram showing workload ingestion process from customer instance to AMS stack.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/appguide/images/Workload_ingestion_product_process.png)


## ワークロード取り込みスタック: の作成
<a name="ex-workload-ingest-col"></a>

### コンソールを使用したインスタンスの AMS スタックへの移行
<a name="wig-create-con"></a>

AMS コンソールでのこの変更タイプのスクリーンショット:

![\[Instance migration details showing ID, execution mode, version, classification, and description.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/appguide/images/guiIngestStackFromPartMigStackCreateCT.png)


仕組み:

1. **RFC **の作成ページに移動します。AMS コンソールの左側のナビゲーションペインで**RFCs** をクリックして RFCsリストページを開き、**RFC の作成**をクリックします。

1. デフォルトの変更タイプ参照ビューで一般的な**変更タイプ** (CT) を選択するか、**カテゴリ別選択ビューで CT **を選択します。
   + **変更タイプ別に参照**: **クイック作成**エリアで一般的な CT をクリックすると、すぐに **RFC の実行**ページを開くことができます。クイック作成で古い CT バージョンを選択することはできません。

     CTs をソートするには、**カード**ビューまたは**テーブル**ビューで**すべての変更タイプ**領域を使用します。どちらのビューでも、CT を選択し、**RFC の作成**をクリックして **RFC の実行**ページを開きます。必要に応じて、RFC **の作成ボタンの横に古いバージョンで**作成オプションが表示されます。 ****
   + **カテゴリ別に選択**: カテゴリ、サブカテゴリ、項目、オペレーションを選択すると、CT 詳細ボックスが開き、必要に応じて**古いバージョンで作成する**オプションが表示されます。**RFC の作成**をクリックして、**RFC の実行**ページを開きます。

1. **RFC の実行**ページで、CT 名エリアを開き、CT の詳細ボックスを表示します。**件名**は必須です (**変更タイプの参照**ビューで CT を選択した場合は入力されます）。**追加設定**エリアを開き、RFC に関する情報を追加します。

   **実行設定**領域で、使用可能なドロップダウンリストを使用するか、必要なパラメータの値を入力します。オプションの実行パラメータを設定するには、**追加設定**エリアを開きます。

1. 完了したら、**実行** をクリックします。エラーがない場合、**RFC が正常に作成された**ページに、送信された RFC の詳細と最初の**実行出力**が表示されます。

1. **Run parameters** 領域を開き、送信した設定を確認します。ページを更新して RFC 実行ステータスを更新します。必要に応じて、RFC をキャンセルするか、ページ上部のオプションを使用して RFC のコピーを作成します。

**注記**  
RFC が拒否された場合、実行出力には Amazon CloudWatch logsへのリンクが含まれます。AMS ワークロード取り込み (WIGS) RFCs は、要件が満たされていない場合、例えば、インスタンスでウイルス対策ソフトウェアが検出された場合などに拒否されます。CloudWatch ログには、失敗した要件と修復のために実行するアクションに関する情報が含まれます。

### CLI を使用してインスタンスを AMS スタックに移行する
<a name="wig-create-cli"></a>

仕組み:

1. インライン作成 (すべての RFC と実行パラメータを含む`create-rfc`コマンドを発行) またはテンプレート作成 (2 つの JSON ファイルを作成し、1 つは RFC パラメータ用、もう 1 つは実行パラメータ用) のいずれかを使用し、2 つのファイルを入力として`create-rfc`コマンドを発行します。どちらの方法もここで説明します。

1. 返された RFC ID を使用して RFC: `aws amscm submit-rfc --rfc-id ID` コマンドを送信します。

   RFC: `aws amscm get-rfc --rfc-id ID` コマンドをモニタリングします。

変更タイプのバージョンを確認するには、次のコマンドを使用します。

```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID
```
**注記**  
変更タイプのスキーマの一部であるかどうかにかかわらず、任意の RFC で任意の`CreateRfc`パラメータを使用できます。たとえば、RFC ステータスが変更されたときに通知を受け取るには、リクエストの RFC パラメータ部分 (実行パラメータではなく) `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"`にこの行を追加します。すべての CreateRfc パラメータのリストについては、[AMS 変更管理 API リファレンス](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html)を参照してください。

AMS CLI を使用して、AMS アカウントに移行された非 AMS インスタンスから AMS インスタンスを作成できます。
**注記**  
前提条件に従っていることを確認してください。[「ワークロードの移行: Linux と Windows の前提条件](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-prereqs.html)」を参照してください。

変更タイプのバージョンを確認するには、次のコマンドを使用します。

```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID
```

*インライン作成*:

インラインで指定された実行パラメータ (インラインで実行パラメータを指定する場合は引用符をエスケープ) を指定して create RFC コマンドを発行し、返された RFC ID を送信します。たとえば、コンテンツを次のような内容に置き換えることができます。

```
aws amscm create-rfc --change-type-id "ct-257p9zjk14ija" --change-type-version "2.0" --title "AMS-WIG-TEST-NO-ACTION" --execution-parameters "{\"InstanceId\":\"INSTANCE_ID\",\"TargetVpcId\":\"VPC_ID\",\"TargetSubnetId\":\"SUBNET_ID\",\"TargetInstanceType\":\"t2.large\",\"ApplyInstanceValidation\":true,\"Name\":\"WIG-TEST\",\"Description\":\"WIG-TEST\",\"EnforceIMDSV2\":\"false\"}"
```

*テンプレートの作成*:

1. 0この変更タイプの実行パラメータ JSON スキーマをファイルに入力します。例ではMigrateStackParams.json:

   ```
   aws amscm get-change-type-version --change-type-id "ct-257p9zjk14ija" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > MigrateStackParams.json
   ```

1. 実行パラメータ JSON ファイルを変更して保存します。たとえば、コンテンツを次のような内容に置き換えることができます。

   ```
   {
   "InstanceId":          "MIGRATED_INSTANCE_ID",
   "TargetVpcId":         "VPC_ID",
   "TargetSubnetId":      "SUBNET_ID",
   "Name":                "Migrated-Stack",
   "Description":         "Create-Migrated-Stack",
   "EnforceIMDSV2":       "false"
   }
   ```

1. RFC テンプレート JSON ファイルを出力します。MigrateStackRfc.json:

   ```
   aws amscm create-rfc --generate-cli-skeleton > MigrateStackRfc.json
   ```

1. MigrateStackRfc.json ファイルを変更して保存します。たとえば、コンテンツを次のような内容に置き換えることができます。

   ```
   {
   "ChangeTypeId":         "ct-257p9zjk14ija",
   "ChangeTypeVersion":    "2.0",
   "Title":                "Migrate-Stack-RFC"
   }
   ```

1. MigrateStackRfc ファイルと MigrateStackParams ファイルを指定して、RFC を作成します。

   ```
   aws amscm create-rfc --cli-input-json file://MigrateStackRfc.json  --execution-parameters file://MigrateStackParams.json
   ```

   レスポンスで新しい RFC の ID を受け取り、それを使用して RFC を送信およびモニタリングできます。送信するまで、RFC は編集状態のままであり、開始されません。

   新しいインスタンスは、関連する VPC のアプリケーション所有者のアカウントのインスタンスリストに表示されます。

1. RFC が正常に完了したら、アプリケーション所有者に通知して、新しいインスタンスにログインし、ワークロードが動作していることを確認します。

**注記**  
RFC が拒否された場合、実行出力には Amazon CloudWatch logsへのリンクが含まれます。AMS ワークロード取り込み (WIGS) RFCs は、要件が満たされていない場合、例えば、インスタンスでウイルス対策ソフトウェアが検出された場合などに拒否されます。CloudWatch ログには、失敗した要件と修復のために実行するアクションに関する情報が含まれます。

### ヒント
<a name="ex-workload-ingest-tip"></a>

**注記**  
前提条件に従っていることを確認してください。[「ワークロードの移行: Linux と Windows の前提条件](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-prereqs.html)」を参照してください。

**注記**  
移行するインスタンスのタグに RFC で指定されたタグと同じキーがある場合、RFC は失敗します。

**注記**  
最大 4 つのターゲット IDs、ポート、アベイラビリティーゾーンを指定できます。

**注記**  
RFC が拒否された場合、実行出力には Amazon CloudWatch logsへのリンクが含まれます。AMS ワークロード取り込み (WIGS) RFCs は、要件が満たされていない場合、例えば、インスタンスでウイルス対策ソフトウェアが検出された場合などに拒否されます。CloudWatch ログには、失敗した要件と修復のために実行するアクションに関する情報が含まれます。

**注記**  
RFC が拒否された場合、実行出力には Amazon CloudWatch logsへのリンクが含まれます。AMS ワークロード取り込み (WIGS) RFCs は、要件が満たされていない場合、例えば、インスタンスでウイルス対策ソフトウェアが検出された場合などに拒否されます。CloudWatch ログには、失敗した要件と修復のために実行するアクションに関する情報が含まれます。



必要に応じて、[「ワークロード取り込み (WIGS) 失敗](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-troubleshoot.html#rfc-valid-execute-wigs)」を参照してください。