

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

# ネットワークを に移行する AWS
<a name="transform-vmware-migrate-network"></a>

 AWS Transform を使用すると、ネットワークを に移行できます AWS。 AWS Transform は、必要に応じてソース環境設定を VPCs、サブネット、セキュリティグループ、NAT ゲートウェイ、トランジットゲートウェイ、Elastic IPs、ルート、ルートテーブルなどの AWS同等のネットワークリソースに変換します。デプロイ前に、生成されたネットワーク設定を確認および変更できます。ネットワーク接続の AWS 変換と分析を使用して設定をデプロイできます。または、自己デプロイを選択し、Infrastructure as Code (IaC) を任意の形式で受け取ることもできます。、Landing Zone Accelerator (LZA) AWS Cloud Development Kit (AWS CDK)、または HashiCorp Terraform。

ネットワークを移行するには、次の手順に従います。

1. ソースネットワークファイルをアップロードします。

1. 追加の設定ファイルをアップロードします (オプション、RVTools 環境の場合）。

1. ネットワークトポロジを選択します。

1. セキュリティグループのマッピング戦略を選択します。

1. ネットワークを確認して最適化します。

1. ネットワーク図を生成します (オプション）。

1. リソースのタグ付けを設定します。

1. ネットワークをデプロイします。

**注記**  
マルチアカウントデプロイでは、ネットワーク移行を開始する前に、クロスアカウント IAM ロールと AWS Organizations の信頼されたアクセスを設定する必要があります。移行タイプの詳細については、「」を参照してください[ステップ 1: 移行タイプの選択](transform-vmware-connect-target-account.md#transform-vmware-cta-migration-type)。

## ステップ 1: ソースネットワークマッピング
<a name="transform-vmware-source-network-mapping"></a>

ネットワークマッピングプロセスでは、ソース環境から設定ファイルをアップロードする必要があります。選択するツールは、ソースネットワークタイプによって異なります。
+ **Software Defined Networks (SDN):** VMware NSX ネットワーク仮想化の場合は Import/Export、Cisco Application Centric Infrastructure の場合は Cisco ACI 設定。
+ **VMware vSphere ネットワーク:** [RVTools](https://www.dell.com/en-us/shop/vmware/sl/rvtools)。RVTools ファイルを使用する場合、 AWS Transform は Amazon VPC 設定のみを生成します。セキュリティグループ設定には、ファイアウォールまたはソフトウェア定義のネットワークファイルからの追加の入力が必要です。追加のファイルからセキュリティグループを生成する方法の詳細については、[「追加の設定ファイル](#transform-vmware-firewall-and-sdn-config-files)」を参照してください。
+ **ファイアウォール設定データに基づくネットワーク:** Palo Alto Networks Firewall、Fortinet FortiGate Firewall、または Cisco ACI からファイルをエクスポートします。サポートされているバージョンと抽出手順の詳細については、[「設定ファイルの抽出](#transform-vmware-config-file-extraction)」を参照してください。
+ **VMware ワークロードと非 VMware ワークロードの両方を実行するハイブリッドネットワーク:** [AWS 検出ツールまたは modelizeIT を変換](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool.html)します。 modelizeIT
+ **その他のファイルタイプ:** 設定ファイルが上記のサポートされている形式のいずれでもない場合、ファイルはサポートされている形式に自動的に変換されます。この変換には、ファイルサイズと複雑さに基づいて最大 2 時間かかる場合があります。

**注記**  
サポートされているソースネットワークファイルの最大サイズは 70 MB です。

**警告**  
[https://www.dell.com/en-us/shop/vmware/sl/rvtools](https://www.dell.com/en-us/shop/vmware/sl/rvtools) の公式の Dell サイトからのみ RVTools をダウンロードします。非公式のソースから RVTools をダウンロードしないでください。

各ソースネットワークセグメントは、独自の VPC にマッピングされます。ネットワークセグメンテーションはソースタイプによって異なります。
+ **vNetwork:** AWS VMs vSwitch と仮想 LAN (VLAN) で変換します。VLANsは複数の vSwitchesの下に表示されます (VLAN 0 を除く）。
+ **NSX ネットワーク:** AWS Tier-1 ルーターに基づいてネットワークをセグメント化し、ルーターをグループ化してセグメントを収集します。

## ステップ 2: 追加の設定ファイル
<a name="transform-vmware-firewall-and-sdn-config-files"></a>

RVTools ソース環境では、オプションで追加の設定ファイルをアップロードして、セキュリティグループの生成を有効にすることができます。追加の設定ファイルをアップロードしない場合、RVTools ベースの移行用のセキュリティグループは生成されません。

AWS Transform では、次の追加の設定ファイルタイプがサポートされています。1 つのプラットフォームからアップロードできる設定ファイルは 1 つだけです。
+ Cisco Application Centric Infrastructure (ACI) は、ネットワークポリシー設定を提供します。
+ Palo Alto Networks はファイアウォールセキュリティポリシーを提供します。
+ Fortinet FortiGate は、ファイアウォールセキュリティポリシーを提供します。

ファイアウォールまたは Cisco ACI ファイルをアップロードすると、 AWS Transform はネットワークインフラストラクチャとセキュリティグループを生成します。RVTools ファイルを単独でアップロードすると、 AWS Transform はネットワークインフラストラクチャのみを生成します。

サポートされているバージョンと抽出手順の詳細については、[「設定ファイルの抽出](#transform-vmware-config-file-extraction)」を参照してください。

## ステップ 3: ネットワークトポロジ
<a name="network-topologies"></a>

ネットワーク定義ステップでは、ネットワークトポロジを選択します。**分離された VPCs** トポロジまたは **Hub トポロジとスポーク**トポロジを選択できます。

### 分離された VPC
<a name="isolated-vpcs"></a>

#### デプロイされる内容
<a name="isolated-vpcs-deployed"></a>

分離された VPCsは、 内で個別のユニットとして動作する独立したネットワーク環境です AWS。VPCs は完全に分離され、それらの間に組み込みの通信パスはありません。この分離により、最高レベルのネットワーク境界保護が提供されます。

AWS Transform は、次のリソースを作成します。
+ 検出されたソースネットワークセグメントごとに専用の VPC。
+ ソースネットワーク設定に基づくプライベートサブネット。
+ セキュリティグループ (ファイアウォールまたは SDN 設定ファイルを指定した場合）。

#### セットアップを完了する
<a name="isolated-vpcs-complete-setup"></a>

AWS Transform はネットワークインフラストラクチャをデプロイしますが、インターネットアクセスと VPC 間接続を残すため、組織の要件を満たす設定を選択できます。

分離された VPC のインターネットアクセスを有効にするには、次の手順を実行します。

1. [インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)を作成し、VPC にアタッチします。

1. インターネットアクセスが必要な各アベイラビリティーゾーンにパブリックサブネットを作成します。インターネットゲートウェイ`0.0.0.0/0`を指すルートを追加します。サブネット設定の詳細については、[「VPC のサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html)」を参照してください。

1. パブリックサブネットに [NAT ゲートウェイを作成します](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) (高可用性のために AZ ごとに 1 つ）。NAT ゲートウェイごとに Elastic IP を割り当てます。

1. プライベートサブネット[ルートテーブル](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html)を更新する — 同じ AZ 内の NAT ゲートウェイ`0.0.0.0/0`を指すルートを追加します。

1. [セキュリティグループルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)を確認する — アウトバウンドルールで、ワークロードに必要なトラフィック (HTTPS、DNS など) が許可されていることを確認します。

VPC-to-VPC [ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)または [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) を設定し、各 VPC のルートテーブルを更新して、トラフィックをピアリング接続または TGW アタッチメントにルーティングします。

### ハブとスポーク
<a name="hub-and-spoke"></a>

このモデルでは、[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は複数のワークロード VPCs (スポーク) を接続する中央ハブとして機能します。

#### デプロイされる内容
<a name="hub-and-spoke-deployed"></a>

AWS Transform は、次のリソースを作成します。
+ **スポーク VPCs:** 検出されたソースネットワークセグメントごとに 1 つの VPC、プライベートサブネットと Transit Gateway アタッチメント。
+ **検査 VPC:** トラフィック検査のためにファイアウォールアプライアンスをホストします。すべてのクロス VPC トラフィックは、この VPC を介してルーティングされます。Transit Gateway アタッチメントは[、アプライアンスモード](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-appliance-scenario.html)を使用します。これは、トラフィックが接続の両方向に同じアプライアンスを対称的に流れるようにする設定です。
+ **インバウンド VPC: **パブリックインターネット (南北インバウンド) からネットワークに入るトラフィックを処理します。複数のアベイラビリティーゾーンにまたがる[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)とパブリックサブネットが含まれます。
+ **アウトバウンド VPC:** ネットワークからパブリックインターネット (南北アウトバウンド) へのトラフィックを処理します。インターネットゲートウェイ、高可用性のために各アベイラビリティーゾーンに [Elastic IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)を持つ [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)、および Transit Gateway アタッチメントのプライベートサブネットが含まれます。
+ **Transit Gateway ルートテーブル:** 2 つのルートテーブルがインスペクション VPC を介してトラフィックを誘導します。*未検査*テーブルは、スポーク VPCs、インバウンド VPC、アウトバウンド VPC に関連付けられています。すべてのトラフィック (0.0.0.0/0) を検査 VPC アタッチメントにルーティングし、デフォルトの関連付けルートテーブルです。*Inspected* テーブルは Inspection VPC に関連付けられています。これにはすべてのスポーク VPCs、デフォルトの伝播ルートテーブルです。

マルチアカウントデプロイの場合、Transit Gateway は [AWS Resource Access Manager (RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) を介してアカウント間で共有されます。

#### トラフィックフロー
<a name="hub-and-spoke-traffic-flow"></a>

すべてのクロス VPC トラフィックは次のパスに従います。

1. スポーク VPC からのトラフィックは Transit Gateway (デフォルトルート 0.0.0.0/0) に送信されます。

1. 未検査ルートテーブルは、トラフィックを検査 VPC にルーティングします。

1. 検査 VPC のファイアウォールはトラフィックを検査し、トランジットゲートウェイに転送します。

1. Inspected ルートテーブルは、伝播されたルートを使用してトラフィックを送信先スポーク VPC にルーティングします。

アウトバウンドインターネットトラフィックの場合、検査済みルートテーブルはトラフィックをアウトバウンド VPC にルーティングします。NAT ゲートウェイは、トラフィックがインターネットゲートウェイに転送される前にプライベート IP アドレスを変換します。アウトバウンド VPC パブリックルートテーブルには、Transit Gateway に戻る各スポーク VPC クラスレスドメイン間ルーティング (CIDR) 範囲の特定のルートが含まれます。これらのルートにより、リターントラフィックが正しいスポーク VPC に到達できるようになります。

インバウンドインターネットトラフィックは、インバウンド VPC のインターネットゲートウェイを経由して入り、同じ検査パスに従ってスポーク VPCs。

#### セットアップを完了する
<a name="hub-and-spoke-complete-setup"></a>

AWS Transform はネットワークインフラストラクチャをデプロイしますが、ファイアウォール設定とインバウンドサービスの設定はそのままにしておくため、組織の要件を満たすセキュリティアプライアンスとポリシーを選択できます。

**注記**  
デフォルトでは、クロス VPC トラフィックは検査なしで検査 VPC を通過します。トラフィック検査を有効にするには、ファイアウォールをデプロイする必要があります。

**ファイアウォールをデプロイする:** ファイアウォールエンドポイントの検査 VPC に追加のサブネットを作成します。 AWS Transform は Transit Gateway アタッチメントのサブネットのみを作成します。TGW アタッチメントサブネットからファイアウォールエンドポイントにトラフィックをルーティングし、ファイアウォールサブネットから Transit Gateway にトラフィックをルーティングします。[AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html) またはサードパーティーアプライアンスをデプロイできます。Transit Gateway を使用したファイアウォールのデプロイの詳細については、「[Creating a firewall with a Transit Gateway](https://docs.aws.amazon.com/network-firewall/latest/developerguide/create-tgw-firewall.html)」を参照してください。

**接続の確認:** ファイアウォールをデプロイしたら、スポーク VPC インスタンス ( など) からのアウトバウンドインターネットアクセスをテストします`curl https://aws.amazon.com`。[Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) を使用して、接続の問題をトラブルシューティングできます。

**インバウンドサービスを設定する:** パブリック向けサービスをホストするには、[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) または [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) をインバウンド VPC パブリックサブネットにデプロイします。Transit Gateway を介してスポーク VPCs 内のインスタンスを指すターゲットグループを設定し、Inspected ルートテーブルにインバウンド VPC へのリターンルートがあることを確認します。

VPCs 間の通信をきめ細かく制御する場合は、**分離VPCs**オプションを選択し、生成されたネットワークを変更して、必要な特定の通信パスを作成します。

## ステップ 4: セキュリティグループのマッピング
<a name="transform-vmware-security-group-association"></a>

ソースセキュリティポリシーを AWS セキュリティグループに変換する方法を選択します。 AWS Transform は、ソース環境設定に基づいてセキュリティグループを作成します。セキュリティポリシー、セキュリティポリシールール、ゲートウェイポリシー、ゲートウェイポリシールールは、セキュリティグループに変換されます。

**重要**  
AWS Transform は、ソース環境に合わせてベストエフォートベースでセキュリティグループを作成します。生成されたセキュリティグループを確認して変更し、会社のニーズとセキュリティポリシーを満たしていることを確認します。

### セキュリティグループの参照
<a name="security-group-referencing"></a>

セキュリティグループが生成されると、 AWS Transform はサポートされているセキュリティグループ参照を使用します。セキュリティグループ参照は、特定の IP アドレス範囲 (CIDR ブロック) ではなく、別のセキュリティグループ ID に基づいてセキュリティルールを設定します。このアプローチは、より柔軟で保守可能なセキュリティ設定を提供します。

セキュリティグループルールは、同じ VPC 内、または同じリージョン内に接続されている VPC 内の他のセキュリティグループのみを参照できます。クロスアカウント参照もサポートされています。接続されていない VPC またはリージョン間でセキュリティグループを参照することはできません。接続された VPCs、クロス VPC セキュリティグループ参照をサポートするのはインバウンドルールのみです。アウトバウンドルールは CIDR ベースのルールを使用する必要があります。 AWS Transform がセキュリティグループルールを作成する方法は、選択したネットワークトポロジによって異なります。
+ **ハブとスポーク:** Transit Gateway はVPCs 間のネットワーク接続を提供します。 AWS Transform は、VPC 内およびクロス VPC/クロスアカウント進入ルールの両方に参照を使用します。クロス VPC/クロスアカウント出力 (アウトバウンド) ルールは、CIDR ベースのルールを使用します。
+ **分離VPCs:** VPCs 間にネットワーク接続がありません。 AWS Transform は VPC 内ルールの参照のみを使用します。すべてのクロス VPC ルールとクロスアカウントルールは CIDR ベースのルールを使用します。

CIDR ベースのルールは、ソース設定が対称でない場合にも使用されます。

次のいずれかのセキュリティグループマッピング戦略を選択します。
+ **MAP:** セキュリティルールをソース環境から AWS セキュリティグループとルールに変換します。このオプションは、静的 IP アドレス指定を使用する移行に使用します。
+ **MAP\_DHCP (DHCP サポートで翻訳):** ソース環境のセキュリティルールを DHCP 互換で翻訳します。DHCP は、サブネットの CIDR 範囲から IP アドレスを動的に割り当てます。その結果、VPC 間の出力ルールは、完全な送信先サブネット CIDR と一致するように拡張されます。CIDR を絞り込むと、その範囲外の DHCP 割り当て IPs がブロックされます。移行後にこれらのルールを確認してください。

  このオプションは、クロス VPC Transit Gateway 通信での DHCP サポートに使用します。また、静的 IPs でも動作しますが、MAP よりも広範なルールを生成する可能性があります。
+ **SKIP:** セキュリティルールを翻訳しません。移行後に AWS セキュリティグループを手動で設定します。静的 IP 環境と DHCP 環境の両方で動作します。追加の設定ファイルがない RVTools ソース環境の場合、 AWS Transform は自動的に SKIP を使用します。

**注記**  
マッピング戦略によって、IP 割り当てオプションが決まります。MAP は静的 IP のみをサポートします。MAP\_DHCP と SKIP は、静的と DHCP の両方をサポートします。

### IP 移行アプローチ
<a name="ip-migration-approaches"></a>

移行には 2 つのネットワーク設定があります。

**ネットワーク範囲の選択**
+ **既存の範囲を保持 (IP アドレス範囲の保持):** 移行中は元の IP アドレス範囲を保持します。特にハードコードされた IP 依存関係や既存のファイアウォールルールを持つレガシーアプリケーションでは、変更 AWS なしでアプリケーションを に移動する (lift-and-shift移行に最適です。
+ **新しい IP 範囲の更新 (CIDR 更新):** 移行中に各 VPC CIDR 範囲を変更でき、 AWS Transform はサブネット、ルートテーブル、セキュリティグループに変更を自動的に伝達します。

**IP アドレスの割り当て**
+ **固定 IP アドレス (静的):** AWS 変換は CIDR に基づいて静的 IPs を割り当てます。これは、予測可能なネットワーク動作、DNS 管理、または IP ベースのアクセスコントロールを必要とするアプリケーションに最適です。IPs、インスタンスにアタッチされた仮想ネットワークカードである Elastic Network Interface (ENIs) を介してインスタンスの再起動全体で保持されます。
+ **動的 IP 割り当て (AWS DHCP):** インスタンスの起動時にサブネットプールから IPs を自動的に割り当てます。クラウドおよび Auto Scaling ワークロードで実行されるように設計されたアプリケーションに最適です。運用上のオーバーヘッドを削減しますが、アプリケーションは DNS またはサービス検出を使用する必要があります。

いずれかの範囲選択をいずれかの IP 割り当て方法と組み合わせることができます。

**注記**  
IP アドレス割り当て戦略はウェーブレベルで設定されます。ウェーブファイルをカスタマイズすることで、特定のサーバーにさまざまな戦略を割り当てることができます。たとえば、ウェーブに静的 IP アドレスアプローチを選択し、特定のサーバーに動的アプローチを割り当てる場合は、*「MGN ユーザーガイド*」の[「設定の編集](https://docs.aws.amazon.com/mgn/latest/ug/configuration-editing.html)」で説明`[RESET_VALUE]`されているように を使用します。

## ステップ 5: ネットワークを確認して最適化する
<a name="transform-vmware-review-vpc-configs"></a>

 AWS Transform がターゲットネットワーク設定を生成したら、 AWS インフラストラクチャに集約されたオンプレミスネットワークセグメントを確認できます。ビジュアルインターフェイスを使用してネットワークを確認し、チャットインターフェイスを使用して変更を行い、ガイド付きレコメンデーションを受け取ります。 AWS Transform はカスケード影響分析を実行し、必要な変更を実装してネットワークの一貫性とベストプラクティスへの準拠を維持します。変換 AWS にネットワークを分析して最適化を提案するように依頼することもできます。[「ガイド付きレコメンデーション](#transform-vmware-guided-recommendations)」を参照してください。

### ターゲットアカウントの既存の VPCs
<a name="transform-vmware-brownfield-network"></a>

ターゲットアカウントに以前の移行フェーズまたは並列インフラストラクチャプロジェクトからの VPCs がすでに含まれている場合、 AWS Transform はそれらを自動的に検出し、レビュープロセス中にマッピングされた VPCsとともに表示します。マルチアカウント移行の場合、 AWS Transform は AWS Organization 内のすべてのアカウントで既存の VPCs を検出します。

この可視性は、計画されたネットワークが既存のインフラストラクチャにどのように関連しているかを理解し、潜在的な CIDR の競合を特定し、デプロイ前に情報に基づいた意思決定を行うのに役立ちます。

**注記**  
AWS Transform は既存の VPCsのみを検出します (サブネットやその他のリソースは検出しません）。検出は読み取り専用 — AWS 変換は既存の VPCsを変更しません。

### ネットワークの最適化
<a name="transform-vmware-optimization-operations"></a>

**注記**  
これらのオペレーションはワークロード VPCsにのみ適用されます。ハブおよびスポークトポロジ (検査、インバウンド、アウトバウンド) VPCs では、IP アドレスの変更のみがサポートされます。  
削除、マージ、分割の各オペレーションを元に戻すことはできません。これらの変更を適用する前に、設定を注意深く確認してください。

VPCs では、次のオペレーションを使用できます。
+ **削除:** 設定から VPC を完全に削除します。これは、移行すべきではない古いネットワークセグメントに使用します AWS。
+ **除外:** 段階的な移行戦略のために、移行から VPC を一時的に削除します。除外VPCs はデプロイされませんが、後で再含めることができます。
+ **含める:** 以前に除外した VPC を移行に追加します。
+ **マージ:** 2 つの VPCsに結合します。最初の VPC はアイデンティティを保持し、2 番目の VPC のすべてのサブネットを吸収します。セキュリティグループはマージされた VPC に移動され、それに応じて関連付けが再構築されます。最初の VPC の CIDR は、元の CIDR の両方を含む最小CIDRs 範囲に拡張され、ルーティングは自動的に更新されます。2 番目の VPC は設定から削除されます。

  マージ要件:
  + サブネット CIDRsは、2 つの VPCs 間で重複してはいけません。
  + マージされた CIDR は /16 を超えることはできません。
  + マルチアカウントデプロイの場合、両方の VPCsを同じアカウントに割り当てる必要があります。
+ **IP アドレスの変更:** プレフィックスの長さを同じままに VPC CIDR の基本 IP アドレスを変更します。 AWS Transform は、すべてのサブネット CIDRsで自動的に変換します。たとえば、VPC を から に変更`10.0.0.0/16`すると`10.20.0.0/16`、サブネットが から `10.0.1.0/24`に移行されます`10.20.1.0/24`。

  古い VPC CIDR と正確に一致するセキュリティグループルールは自動的に更新されます。部分的に重複するルールや古い CIDR と一致しないルールは変更されません。変更後にこれらのルールを確認してください。
+ **名前の変更:** コスト配分、コンプライアンス追跡、運用標準に関する組織の命名規則に合わせて VPC の名前を変更します。
+ **サイズ変更:** VPC CIDR のプレフィックスの長さを変更して、IP アドレス範囲を拡大または縮小します。
  + **プレフィックスの長さが短**くなる (IPsの数が増える、たとえば /20 から /16): サブネットはより大きな範囲内に収まります。サブネットの変更は必要ありません。
  + **プレフィックスの長さの増加** (/16 から /20 など、IPs が少ない): 新しい範囲外のサブネットは、まずサブネットのサイズ変更オペレーションを使用してサイズ変更する必要があります。

  古い VPC CIDR と正確に一致するセキュリティグループルールは自動的に更新されます。部分的に重複するルールや古い CIDR と一致しないルールは変更されません。サイズ変更後にこれらのルールを確認してください。

  サイズ変更の要件:
  + 新しい CIDR は /16 から /28 の間である必要があります。
  + 新しい CIDR は、ネットワーク内の他の VPCs (ハブおよびスポークトポロジ) と重複してはいけません。
  + CIDR を減らす場合、既存のサブネットはすべて新しい CIDR 内に収まる必要があります。必要に応じて、最初にサブネットのサイズを変更します。
+ **分割:** 指定した CIDR 境界に基づいて VPC を 2 つの VPCs に分割します。サブネットは、CIDR に含まれる新しい VPC に割り当てられます。セキュリティグループは両方の新しい VPCs にクローンされますが、セキュリティグループルール CIDRsは自動的に更新されません。分割後にルールを確認して、VPC 間の通信が期待どおりに動作することを確認します。元の VPC は 2 つの新しい VPCs。

  分割要件:
  + 2 つの CIDR 範囲のみを指定する必要があります。
  + 2 つの CIDRs重複してはいけません。
  + 各 CIDR は /16 から /28 の間である必要があります。
  + すべてのサブネットは、2 つの CIDRs。サブネットが収まらない場合、オペレーションは拒否されます。

サブネットでは、次のオペレーションを使用できます。
+ **IP アドレスの変更:** サブネット CIDR の基本 IP アドレスを変更しながら、プレフィックスの長さを同じにします。
+ **削除:** 親 VPC に影響を与えることなく、設定からサブネットを完全に削除します。
+ **サイズ変更:** サブネット CIDR のプレフィックスの長さを変更して、IP アドレス範囲を拡大または縮小します。

  サブネットのサイズ変更要件:
  + 新しい CIDR は /16 から /28 の間である必要があります。
  + 新しい CIDR は、同じ VPC 内の他のサブネットと重複してはいけません。
  + 新しい CIDR は親 VPC CIDR 内にある必要があります。

各オペレーションの後、 AWS Transform はセキュリティグループ参照を再評価します。これにより、CIDR ベースのルールをセキュリティグループ参照に変換したり、その逆を行ったりする可能性があります。変更を加えた後、セキュリティグループのルールを確認して、要件を満たしていることを確認します。

### ガイド付きネットワークレコメンデーション
<a name="transform-vmware-guided-recommendations"></a>

AWS Transform は、マッピングされたネットワークを分析し、チャットインターフェイスを通じて優先順位の高いレコメンデーションを提供します。推奨事項はネットワークデータに基づいており、変更を適用する前に確認する必要があります。

AWS 変換では、次の最適化が推奨される場合があります。
+ **CIDR 競合の解決:** AWS 組織内のすべてのアカウントで、マッピングVPCs と既存の VPCsの間で CIDR 範囲が重複するフラグを立てます。競合VPCs が最初に表示されます。マッピングされた VPC を再アドレスするか、除外または削除するか、競合を確認してデプロイ後に自分で解決することで、競合を解決できます。
+ **命名標準化:** 一貫したパターンに従わない VPC 名 (ハードウェアリファレンスを含む名前など) にフラグを付けます。 AWS Transform は、置き換えを提案する前にクラウドの命名規則を要求します。
+ **スコープレビュー:** レガシーシステムや廃止保留中のコンストラクトなど AWS、移行する必要のないネットワークセグメントを特定します。 AWS Transform は、コンストラクトを除外する前に確認を求めます。
+ **VPC 容量の適切なサイズ設定:** CIDR に含まれるサブネットのサイズが大きすぎるか小さすぎるように見える VPCs を表面化します。 AWS Transform は現在の容量データを表示し、サイズを変更するかどうかを決定できます。
+ **セキュリティレビュー:** レビューのために無制限のインバウンドトラフィック (0.0.0.0/0) を許可するセキュリティグループルールにフラグを付けます。
+ **VPC 統合:** 論理的な分離要件ではなく、物理インフラストラクチャの制限で区切られたフラグメント化された VPCs を特定し、マージを提案します。

**注記**  
すべてのレコメンデーションには、 AWS Transform が変更を適用する前に明示的な確認が必要です。 AWS Transform は、レコメンデーションがネットワークの複数の側面に影響を与える場合にトレードオフを提示します。

## ステップ 6: ネットワーク図
<a name="transform-vmware-network-diagram"></a>

生成された VPC 設定を確認したら、オプションでネットワーク図を生成してネットワークトポロジを視覚化できます。 AWS Transform は次の図形式をサポートしています。
+ **Mermaid コード (.mmd):** この形式は、Mermaid 互換ツールでレンダリングできるテキストベースの図定義ファイルを生成します。
+ **イメージ (.png):** この形式は、ネットワークトポロジのレンダリングされたイメージを生成します。

## ステップ 7: リソースのタグ付けを設定する
<a name="transform-vmware-tag-network-resources"></a>

ネットワークリソースには、起動とレプリケーションのタグが付けられます。カスタムタグと AWS Migration Acceleration Program (MAP) タグを追加することもできます。

### 起動とレプリケーションの自動タグ
<a name="transform-vmware-tag-replication-launch"></a>

AWS 変換は、移行されたネットワークリソース (VPCs、サブネット、セキュリティグループ、ルートテーブル) に次のタグを自動的にタグ付けします。
+ **キー** : `CreatedBy` **値**: `AWSApplicationMigrationService`
+ **キー** : `ATWorkspace` **値**: `{{workspace-id}}`

これらのタグにより、VPC とサブネットを使用してテストインスタンスとカットオーバーインスタンスを起動できます AWS。

**注記**  
移行された VPCs とサブネットにはデフォルトでインターネット接続が含まれていないため、レプリケーションのステージング領域として適していません。

また、VPC とサブネットをステージングエリア (レプリケーション) として使用するには、次のタグを手動で追加します。
+ **キー** : `CreatedFor` **値**: `AWSTransform`
+ **キー** : `ATWorkspace` **値**: `{{workspace-id}}`

これらのタグを既存の AWS ネットワークリソースに適用して、レプリケーションに使用できるようにすることもできます。

ウェブアプリの URL を AWS 変換する: https://... /workspace/{{workspace-id}}/job/job-id

### カスタムタグ
<a name="transform-vmware-tag-custom"></a>

 AWS Transform によって自動的に適用されるタグに加えて、オプションでカスタムタグを追加して、移行されたネットワークリソースのコンプライアンスを整理、追跡、管理できます。カスタムタグは 2 つのレベルで適用できます。
+ **ジョブレベルのタグ:** すべての VPCs、サブネット、セキュリティグループ、ルートテーブルなど、このジョブによって作成されたすべてのリソースに適用されます。
+ **VPC レベルのタグ:** 特定の VPC に適用し、関連するすべてのリソース (サブネット、セキュリティグループ、ルートテーブル) に自動的にカスケードします。

**注記**  
リクエストあたり最大 40 タグ。各タグにはキーと値が必要です。 AWS タグ付け規則が適用されます。

AWS Transform は、Infrastructure as Code テンプレートを生成するときにこれらのタグを適用します。

### AWS Migration Acceleration プログラム
<a name="transform-vmware-tag-map"></a>

移行が **AWS Migration Acceleration Program (MAP 2.0) **の一部である場合、 AWS Transform はリソースに MAP タグを適用します。移行プロセスの前半で MPE ID を指定した場合、タグは自動的に適用されます。それ以外の場合、生成された VPC 設定の確認が完了すると、 AWS Transform は MAP 契約があるかどうかを尋ね、大文字と数字 (ABCDE12345 など) を使用した 10 文字のコードである MPE ID の入力を求めます。適用されたタグは次の形式を使用します。
+ **キー** : `map-migrated` **値**: `mig{{MPE_ID}}`

## ステップ 8: ネットワークをデプロイする
<a name="transform-vmware-deploy-network"></a>

タグ付け後、デプロイ戦略を選択します。
+ **AWS トランスフォームマネージドデプロイ:** AWS トランスフォームは CloudFormation テンプレートを使用してネットワークをデプロイし、Reachability Analyzer を実行して、複数の VPCs 間および同じ VPC 内のサブネット間の接続をチェックします。
**注記**  
ネットワークデプロイリクエストを実行する前に、明示的な承認を取得する必要があります。[「デプロイ承認プロセス](#deployment-approvals-process)」を参照してください。
+ **自己デプロイ:** AWS Transform は、Infrastructure as Code (IaC) テンプレートを生成します。 CloudFormation テンプレートはデフォルトで生成されます。追加の出力形式を選択することもできます。
  + AWS CDK は、プログラムによるインフラストラクチャデプロイ用の TypeScript プロジェクトを生成します。
  + HashiCorp Terraform は、ネットワークリソースを管理するための HashiCorp 設定言語 (HCL) テンプレートを生成します。
  + Landing Zone Accelerator (LZA) は、LZA ネットワーク設定用の network-config.yaml ファイルを生成します。

**注記**  
Landing Zone Accelerator (LZA) パイプラインを介してデプロイする場合、 AWS Transform アカウントと LZA のインストールは同じ AWS Organization に存在する必要があります。Organization IDs。

自己デプロイの場合は、提供されたリンクを使用して、生成されたテンプレートを含む zip ファイルをダウンロードします。zip フォルダには、生成されたテンプレートの使用方法を説明する README.md ファイルが含まれています。

ダウンロードしたファイルが破損または改ざんされていないことを確認するには、チェックサムを生成してダウンロードし、 `openssl dgst -sha256 -binary <file.zip> | base64` コマンドを使用してローカルに生成されたハッシュと比較します。

### デプロイの承認プロセス
<a name="deployment-approvals-process"></a>

ネットワークの変更が組織のセキュリティ標準とアーキテクチャ要件に準拠していることを確認するために、すべてのデプロイリクエストは承認ワークフローを通過します。ネットワークデプロイリクエストを実行する前に、明示的な承認を取得する必要があります。デプロイリクエストを送信すると、 AWS Transform Approvals タブを介して自動的に承認承認者にルーティングされます。承認者は CloudFormation 、テンプレートとネットワーク設定の両方を検証して、セキュリティ標準とアーキテクチャ要件への準拠を確認します。各送信は新しいレビューサイクルをトリガーし、デプロイは確認を受け取った後にのみ続行されます。承認者がリクエストを拒否した場合は、直接連絡して必要な変更について話し合います。 AWS Transform は監査目的ですべての承認決定を追跡し、デプロイ履歴を維持します。

## デプロイされたネットワークリソースを削除する
<a name="transform-vmware-network-deletion"></a>

デプロイをロールバックする必要がある場合は、 AWS Transform がデプロイしたネットワークリソースを削除できます。リソースは、デプロイが完了した直後に削除できます。デプロイ後にデプロイされたネットワークリソースを変更した場合、リソースを自動的に削除することはできません。
+ **AWS Transform-managed deployments:** AWS Transform は、デプロイ中に作成されたすべての CloudFormation スタックを削除します。このアクションには、 AWS Transform Approvals タブによる承認が必要です。
+ **自己デプロイ:** デプロイされたリソースは、 AWS マネジメントコンソールまたは CLI AWS を使用して手動で削除する必要があります。

## 設定ファイルの抽出
<a name="transform-vmware-config-file-extraction"></a>

ソース環境で Cisco ACI、Palo Alto Networks、または Fortinet FortiGate を使用している場合は、 AWS Transform に提供する設定ファイルを抽出する必要があります。これらのファイルは、スタンドアロンのソースファイルとして使用してネットワークインフラストラクチャとセキュリティグループを生成したり、RVToolsファイルとして使用してセキュリティグループ生成を追加したりすることができます。抽出プロセスはどちらの場合も同じです。

ファイアウォール環境とネットワーク環境から設定ファイルを抽出するには、次の手順に従います。最新情報については、ベンダーのドキュメントを参照してください。

### Fortinet FortiGate
<a name="fortinet-fortigate-extraction"></a>
+ ファームウェアバージョンは v7.0 以降である必要があります。
+ グローバルレベルで `super_admin`または `super_admin_readonly`権限が必要です。
+ 手順:

  1. SSH または組み込み CLI クライアント経由でファイアウォールに接続する

  1. 実行: `show | grep ""` (`| grep ""`ページ分割を無効にします)

  1. `show` コマンドからすべての出力をファイルに保存

### Palo Alto Networks
<a name="palo-alto-extraction"></a>
+ ファームウェアバージョンは 10.1 以降である必要があります。
+ superadmin ロールが必要です。
+ SSH 経由でファイアウォールに接続し、次のコマンドを実行してページ分割を無効にし、出力形式を設定し、設定モードに入り、設定と事前定義されたオブジェクトをエクスポートします。出力を保存します。

  ```
  set cli pager off
  set cli config-output-format set
  configure
  show              # Save as palo-conf.txt
  show predefined   # Save as palo-default.txt
  ```

### Cisco ACI
<a name="cisco-aci-extraction"></a>
+ ファームウェアバージョンは 6.0 以降である必要があります。
+ すべての権限を持つ管理者ロールと、設定された Secure Copy Protocol (SCP)、SSH File Transfer Protocol (SFTP)、または File Transfer Protocol (FTP) の送信先が必要です。
+ 手順:

  1. ブラウザから Application Policy Infrastructure Controller (APIC) に接続する

  1. **管理者**メニューを開き、**Config Rollbacks** を選択します。

  1. **「スナップショットを作成する**」ダイアログで、リモートロケーションオプションを選択し、「今すぐ**スナップショットを作成する**」を選択します。

  1. 「転送成功」メッセージを受信したら、リモートロケーションサーバーに接続し、最新のスナップショットファイル (.gz ファイル) を取得します。