View a markdown version of this page

ネットワークを に移行する AWS - AWS 変換
ステップ 1: ソースネットワークマッピングステップ 2: 追加の設定ファイルステップ 3: ネットワークトポロジステップ 4: セキュリティグループのマッピングステップ 5: ネットワークを確認して最適化するステップ 6: ネットワーク図ステップ 7: リソースのタグ付けを設定するステップ 8: ネットワークをデプロイするデプロイされたネットワークリソースを削除する設定ファイルの抽出

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

ネットワークを に移行する AWS

AWS Transform を使用すると、手動で設計およびデプロイするのにかかるわずかな時間 AWS で、ネットワークを に移行できます。 AWS Transform は AI 搭載のエージェントを使用して、ソース環境設定を VPCs、サブネット、セキュリティグループ、NAT ゲートウェイ、トランジットゲートウェイ、Elastic IPs、ルート、ルートテーブルなどの本番環境対応の AWS ネットワークリソースに変換します。デプロイ前に、会話インターフェイスを使用して生成されたネットワーク設定を確認して変更します。 AWS Transform を使用して直接デプロイするか、自己デプロイを選択して、Infrastructure as Code (IaC) を任意の形式で受信できます。、 Landing Zone Accelerator (LZA) AWS Cloud Development Kit (AWS CDK)、または HashiCorp Terraform。

AWS Transform エージェントは、意思決定中に分析と生成を処理する以下のステップを案内します。

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

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

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

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

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

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

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

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

注記

マルチアカウントデプロイでは、ネットワーク移行を開始する前に、クロスアカウント IAM ロールと AWS Organizations の信頼されたアクセスを設定する必要があります。移行タイプの詳細については、「」を参照してくださいステップ 1: 移行タイプの選択。

ステップ 1: ソースネットワークマッピング

AWS Transform は、さまざまなソースネットワーク設定ファイルからターゲットネットワークインフラストラクチャを生成します。ソース環境から 1 つ以上の設定ファイルをアップロードすると、 AWS Transform は情報を使用して Amazon VPCs、サブネット、セキュリティグループなどのターゲットネットワークを生成します。 AWS Transform はファイアウォールまたはロードバランサーリソースを生成しませんが、これらのネットワーク要素の設定をターゲットネットワークを生成するための入力として使用できます。

AWS Transform は、次のソースタイプの設定ファイルを受け入れます。

  • Software Defined Networks (SDN): Import/Export for VMware NSX network virtualization or Cisco ACI config for Cisco Application Centric Infrastructure。

  • VMware vSphere ネットワーク: RVTools。RVTools ファイルを使用する場合、 AWS Transform は Amazon VPC 設定のみを生成します。セキュリティグループ設定には、ファイアウォールまたはソフトウェア定義のネットワークファイルからの追加の入力が必要です。追加のファイルからセキュリティグループを生成する方法の詳細については、「追加の設定ファイル」を参照してください。

  • ファイアウォール設定データに基づくネットワーク: Palo Alto Networks Firewall、Fortinet FortiGate Firewall、または Cisco ACI からファイルをエクスポートします。サポートされているバージョンと抽出手順の詳細については、「設定ファイルの抽出」を参照してください。

  • VMware ワークロードと非 VMware ワークロードの両方を実行するハイブリッドネットワーク: AWS 検出ツールまたは modelizeIT を変換します。 modelizeIT

  • その他のファイルタイプ: AWS Transform は、チェックポイントや F5 設定などの他のネットワーク設定ファイルも受け入れます。設定ファイルが上記の形式のいずれでもない場合、 AWS Transform は自動的に変換し、それを使用してターゲットネットワークを生成します。この変換には、ファイルのサイズと複雑さに基づいて最大 2 時間かかる場合があります。

注記

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

注記

ネットワークレビュー中に古いセキュリティグループルールの削除を有効にするには、AWS 変換検出ツールまたは modelizeIT から観測されたネットワークトラフィックデータをソースネットワーク設定と一緒に送信します。詳細については、「ガイド付きネットワークの推奨事項」を参照してください。

警告

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: 追加の設定ファイル

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

AWS Transform は、次の追加の設定ファイルタイプをサポートしています。1 つのプラットフォームからアップロードできる設定ファイルは 1 つだけです。

  • Cisco Application Centric Infrastructure (ACI) は、ネットワークポリシー設定を提供します。

  • Palo Alto Networks はファイアウォールセキュリティポリシーを提供します。

  • Fortinet FortiGate は、ファイアウォールセキュリティポリシーを提供します。

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

サポートされているバージョンと抽出手順の詳細については、「設定ファイルの抽出」を参照してください。

ステップ 3: ネットワークトポロジ

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

分離された VPC

デプロイされる内容

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

AWS Transform は、次のリソースを作成します。

  • 検出されたソースネットワークセグメントごとに専用の VPC。

  • ソースネットワーク設定に基づくプライベートサブネット。

  • セキュリティグループ (ファイアウォールまたは SDN 設定ファイルを提供した場合）。

セットアップを完了する

AWS Transform は、コアネットワークインフラストラクチャをデプロイします。組織の要件に合わせて、最終的な接続とセキュリティ設定を完了します。

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

  1. インターネットゲートウェイを作成し、VPC にアタッチします。

  2. インターネットアクセスが必要な各アベイラビリティーゾーンにパブリックサブネットを作成します。インターネットゲートウェイ0.0.0.0/0を指すルートを追加します。サブネット設定の詳細については、「VPC のサブネット」を参照してください。

  3. パブリックサブネットに NAT ゲートウェイを作成します (高可用性のために AZ ごとに 1 つ）。NAT ゲートウェイごとに Elastic IP を割り当てます。

  4. プライベートサブネットルートテーブルを更新します。同じ AZ 内の NAT ゲートウェイ0.0.0.0/0を指すルートを追加します。

  5. セキュリティグループのルールを確認します。アウトバウンドルールで、ワークロードに必要なトラフィック (HTTPS、DNS など) が許可されていることを確認します。

VPC-to-VPC ピアリングまたは Transit Gateway を設定し、各 VPC のルートテーブルを更新して、トラフィックをピアリング接続または TGW アタッチメントにルーティングします。

ハブとスポーク

このモデルでは、AWS Transit Gateway は複数のワークロード VPCs (スポーク) を接続する中央ハブとして機能します。

デプロイされる内容

AWS Transform は、次のリソースを作成します。

  • スポーク VPCs: 検出されたソースネットワークセグメントごとに 1 つの VPC、プライベートサブネットと Transit Gateway アタッチメント。

  • 検査 VPC: トラフィック検査のためにファイアウォールアプライアンスをホストします。すべてのクロス VPC トラフィックは、この VPC を介してルーティングされます。Transit Gateway アタッチメントは、アプライアンスモードを使用します。これは、接続の両方向に同じアプライアンスを介してトラフィックが対称的に流れるようにする設定です。

  • インバウンド VPC: パブリックインターネット (南北インバウンド) からネットワークに入るトラフィックを処理します。複数のアベイラビリティーゾーンにまたがるインターネットゲートウェイとパブリックサブネットが含まれます。

  • アウトバウンド VPC: ネットワークからパブリックインターネット (南北アウトバウンド) へのトラフィックを処理します。インターネットゲートウェイ、高可用性のために各アベイラビリティーゾーンに Elastic IP アドレスを持つ NAT ゲートウェイ、および 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) を介してアカウント間で共有されます。

トラフィックフロー

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

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

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

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

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

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

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

セットアップを完了する

AWS Transform は、トランジットゲートウェイ、スポーク VPCs、トラフィックルーティングなど、コアネットワークインフラストラクチャをデプロイします。組織のセキュリティ要件に合わせて、ファイアウォール設定とインバウンドサービスの設定を完了します。

注記

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

ファイアウォールをデプロイする: ファイアウォールエンドポイントの検査 VPC に追加のサブネットを作成します。 AWS Transform は Transit Gateway アタッチメントのサブネットのみを作成します。TGW アタッチメントサブネットからファイアウォールエンドポイントにトラフィックをルーティングし、ファイアウォールサブネットから Transit Gateway にトラフィックをルーティングします。AWS Network Firewall またはサードパーティーアプライアンスをデプロイできます。Transit Gateway を使用したファイアウォールのデプロイの詳細については、「Creating a firewall with a Transit Gateway」を参照してください。

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

インバウンドサービスを設定する: パブリック向けサービスをホストするには、Application Load Balancer または Network Load Balancer をインバウンド VPC パブリックサブネットにデプロイします。Transit Gateway を介してスポーク VPCs 内のインスタンスを指すターゲットグループを設定し、Inspected ルートテーブルにインバウンド VPC へのリターンルートがあることを確認します。

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

ステップ 4: セキュリティグループのマッピング

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

重要

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

セキュリティグループの参照

セキュリティグループが生成されると、 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 移行アプローチ

移行には 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 ユーザーガイド」の「設定の編集」で説明[RESET_VALUE]されているように を使用します。

ステップ 5: ネットワークを確認して最適化する

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

ターゲットアカウントの既存の VPCs

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

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

注記

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

ネットワークの最適化

注記

これらのオペレーションはワークロード 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 ベースのルールをセキュリティグループ参照に変換するか、またはその逆に変換する可能性があります。変更を加えた後、セキュリティグループのルールを確認して、要件を満たしていることを確認します。

ガイド付きネットワークレコメンデーション

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) を許可するセキュリティグループルールにフラグを付けます。

  • 古いセキュリティグループルールの削除: オンプレミス環境から移行された未使用のインバウンドファイアウォールルールを特定し、削除を提案します。そのため、目的を果たさなくなったセキュリティ公開を繰り越すことはありません。未使用のルールを識別するために、 AWS Transform は Transform AWS 検出ツールまたは modelizeIT によって収集された観測されたネットワークトラフィックデータを使用します。このトラフィックデータは、ソースネットワーク入力と一緒に送信する必要があります。 AWS Transform は、移行されたファイアウォールルールを、そのデータにキャプチャされた監視ウィンドウで観測されたトラフィックと比較し、インバウンドトラフィックが一致しない場合、ルールに未使用としてフラグを付けます。トラフィックデータがない場合、 AWS Transform は未使用のルールを特定できず、削除を提案しません。 AWS Transform は未使用の進入 (インバウンド) ルールのみを削除します。観測されたインバウンドトラフィックがないことは、ルールが未使用であるという信頼性の高いシグナルです。適用する前に、推奨される削除を確認して、セキュリティポリシーと一致していることを確認します。

  • VPC 統合: 論理的な分離要件ではなく、物理インフラストラクチャの制限で区切られたフラグメント化された VPCs を特定し、マージを提案します。

注記

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

ステップ 6: ネットワーク図

生成された VPC 設定を確認した後、オプションでネットワーク図を生成してネットワークトポロジを視覚化できます。 AWS Transform は次の図形式をサポートしています。

  • Mermaid コード (.mmd): この形式は、Mermaid 互換ツールでレンダリングできるテキストベースの図定義ファイルを生成します。

  • イメージ (.png): この形式は、ネットワークトポロジのレンダリングされたイメージを生成します。

ステップ 7: リソースのタグ付けを設定する

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

起動とレプリケーションの自動タグ

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

カスタムタグ

AWS Transform によって自動的に適用されるタグに加えて、オプションでカスタムタグを追加して、移行されたネットワークリソースのコンプライアンスを整理、追跡、管理できます。カスタムタグは 2 つのレベルで適用できます。

  • ジョブレベルのタグ: すべての VPCs、サブネット、セキュリティグループ、ルートテーブルなど、このジョブによって作成されたすべてのリソースに適用されます。

  • VPC レベルのタグ: 特定の VPC に適用し、関連するすべてのリソース (サブネット、セキュリティグループ、ルートテーブル) に自動的にカスケードします。

注記

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

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

AWS Migration Acceleration プログラム

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

  • キー : map-migrated 値: migMPE_ID

ステップ 8: ネットワークをデプロイする

タグ付け後、デプロイ戦略を選択します。

  • AWS トランスフォームマネージドデプロイ: AWS トランスフォームは CloudFormation テンプレートを使用してネットワークをデプロイし、Reachability Analyzer を実行して、複数の VPCs 間および同じ VPC 内のサブネット間の接続をチェックします。

    注記

    ネットワークデプロイリクエストを実行する前に、明示的な承認を取得する必要があります。「デプロイ承認プロセス」を参照してください。

  • 自己デプロイ: 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 コマンドを使用してローカルに生成されたハッシュと比較します。

デプロイの承認プロセス

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

デプロイされたネットワークリソースを削除する

デプロイをロールバックする必要がある場合は、 AWS Transform がデプロイしたネットワークリソースを削除できます。リソースは、デプロイが完了した直後に削除できます。デプロイ後にデプロイされたネットワークリソースを変更した場合、リソースを自動的に削除することはできません。

  • AWS Transform-managed deployments: AWS Transform は、デプロイ中に作成されたすべての CloudFormation スタックを削除します。このアクションには、 AWS Transform Approvals タブによる承認が必要です。

  • 自己デプロイ: デプロイされたリソースは、 AWS マネジメントコンソールまたは CLI AWS を使用して手動で削除する必要があります。

設定ファイルの抽出

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

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

Fortinet FortiGate

  • ファームウェアバージョンは v7.0 以降である必要があります。

  • グローバルレベルで super_adminまたは super_admin_readonly権限が必要です。

  • 手順:

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

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

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

Palo Alto Networks

  • ファームウェアバージョンは 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

  • ファームウェアバージョンは 6.0 以降である必要があります。

  • すべての権限を持つ管理者ロールと、設定された Secure Copy Protocol (SCP)、SSH File Transfer Protocol (SFTP)、または File Transfer Protocol (FTP) の送信先が必要です。

  • 手順:

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

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

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

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