G-gen の奥田です。当記事は、Google Cloud Next 26 Tokyo の1日目に行われたカスタマーセッション「 CDP だけで顧客理解は不十分？Google Cloud と生活者データで実現する「Why 分析」最前線 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 データはあるのに顧客が見えない データの量ではなく種類が足りない 再発する 5 つの症状 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 勘と経験がもつ 3 つの限界 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは ID 突合ではなく確率的な意味マッチング 処理の 4 ステップ 既存テーブルを変更せずに列が増える Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH 発見 2: Gemini による出力品質の独立検査 発見 3: 承認済みルーティンによる双方の資産保護 Why 分析の先にあるもの AI の均質化とブランドらしさ 業種を越えた共通フレームワークへ 関連記事 セッションの概要 当セッションでは、株式会社博報堂による発表が行われました。CDP（Customer Data Platform、顧客データを個人単位で統合管理する基盤）だけでは捉えられない「顧客が行動した理由（Why）」を、生活者データと BigQuery の機能を組み合わせて補完する手法が紹介されました。 セッションは以下の 5 章で構成されていました。 データはあるのに顧客が見えない Why を補ってきた「勘と経験」の正体 生活者データという「Why の辞書」と Why 分析の方法 Google Cloud だから実現できた 3 つの発見 Why 分析の先にあるもの 当記事では BigQuery の基礎的な説明は割愛します。BigQuery そのものについては、以下の記事を参照してください。 blog.g-gen.co.jp データはあるのに顧客が見えない データの量ではなく種類が足りない セッション前半では、多くの企業が直面する課題として「データ量は十分にあるが、データの種類が足りていない」という点が提示されました。 CDP に記録されるのは、会員属性、購買履歴、行動ログ、解約記録といった「What（結果）」のデータです。一方、価値観、生活文脈、意思決定の傾向、不安や願望といった「Why（原因）」は、CDP のどこにも記録されません。登壇者はこれを氷山にたとえ、水面上に見えるのが What、水面下に隠れているのが Why であると説明しました。 たとえば「妥協して選んだ」という本音は、購買履歴という結果データからは読み取れません。同じ商品を買った顧客でも、買った理由は三者三様です。 再発する 5 つの症状 この構造的な欠落が原因となり、データを精緻化しても再発する症状として、以下の 5 つが挙げられました。 セグメントの画一化 メッセージの一律化 LTV（Life Time Value、顧客生涯価値）向上の頭打ち 静かな離反の見落とし 新規獲得の非効率 登壇者は、CDP や CRM（Customer Relationship Management、顧客関係管理システム）の整備自体は不可欠な土台であり、ID 統合、行動ログの蓄積、施策の自動化という期待された役割は果たしていると強調しました。問題は、CDP だけではカバーできない領域（なぜ買ったのか、なぜ離れたのか、なぜ選んだのか）が存在することです。 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 これまで Why の欠落を埋めてきたのは、マーケターの「勘と経験」でした。セッションでは、その正体は「5W1H を同時に読む力」であると定義されました。 ベテランマーケターは、Who（どんな生活状況か）、When（いま何が起きそうか）、Where（どこで接点を持つか）、Why（なぜその選択か）、How（どう情報収集し選ぶか）を、過去事例の蓄積による暗黙のパターンマッチで同時に推論しています。たとえば「40 代男性が SUV を購入した」という購買データから、「家族の安全を重視する層である」と言い当てる、といった推論です。 勘と経験がもつ 3 つの限界 一方で、この勘と経験には 3 つの構造的な限界があると指摘されました。 スケールしない: 顧客一人ひとりに勘と経験を働かせるのは物理的に不可能 引き継げない: ベテランの退職は「顧客理解資産」の消失を意味する 共有できない: 「なんとなく刺さる」という判断では合意形成が属人的になる 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは この課題に対する解決策として、博報堂が保有する生活者データを「Why の辞書」として使用し、マーケターの脳内プロセスを機械化する手法が紹介されました。材料となるのは、圧倒的な量の Why の語彙と、生活者インサイト（購買行動の背後にある価値観や動機）を推論する技術の 2 つです。 博報堂独自の観点として、価値観、動機、幸福感といった軸（たとえば購入時の価値観として、価格、幸せ、機能性など）が生活者データの中で 5W1H により体系化されています。 ID 突合ではなく確率的な意味マッチング 特徴的なのは、顧客データと生活者データを ID 突合（異なるデータベース間で共通の ID をキーにレコードを結合すること）ではなく「確率的な意味マッチング」で接続する点です。これにより以下の 3 点が実現されます。 個人を特定しない 既存の CDP をそのまま使用できる Cookie 規制（サードパーティ Cookie によるトラッキングの制限）の影響を受けにくい 処理の 4 ステップ 処理は以下の 4 ステップで構成されます。 翻訳: 企業ごとに異なる顧客 CDP の項目を、生活者データの共通言語にマッピングする 数値化: 顧客データと生活者データを「意味の座標」上に配置し、意味の近さを距離として比較できるようにする 検索: 生活者データの中から、意味的に最も近い人を選ぶ 特徴付与: 生活者データに近い特徴を顧客データにも付与する 既存テーブルを変更せずに列が増える この手法の利点は、既存の顧客テーブルを変更する必要がないことです。顧客 ID、属性、購買金額といった従来の列はそのままに、以下のような生活者インサイトの列が追加されます。 価値観（なぜ買うのか。指名買い、コスパ重視など） 意思決定傾向（どう選ぶのか。SNS 影響、即決型など） ライフスタイル（どう生きるのか。都市型ライフ、子育て重視など） 既存の顧客データ基盤が、そのまま顧客理解基盤へ進化するという表現が用いられました。 Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 博報堂独自の生活者データを AI 時代に使用するには 3 つの条件が必要であり、Google Cloud はそのすべてを満たすと説明されました。 意味の近さを計算できる BigQuery が標準機能としてベクトル検索（テキストなどを数値ベクトルに変換し、意味の近さで検索する仕組み）を備えています。 マーケターが直接触れる SQL やダッシュボードで完結し、ノーコードまたはローコードで操作できるため、マーケター自身が仮説をすぐ検証できます。 データを動かさない 顧客データは企業環境から一切出さず、顧客環境内で処理が完結します。 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH セッション後半では、実運用から得られた発見として次の3点が紹介されました。1 つ目は、マーケターの直感を SQL で再現できたことです。「この人は、こんな価値観の人と似ているな」というベテランマーケターの頭の中の処理は、これまで言語化も再現もできない暗黙知でした。この処理を、BigQuery の標準機能である VECTOR_SEARCH 関数への変換（SQL Translation）によって再現しています。 これにより「意味の近さ」が可視化され、感覚でしかなかった判断を数字として表現できるようになりました。 参考 : ベクトル検索の概要 発見 2: Gemini による出力品質の独立検査 2 つ目は、出力品質を Gemini で独立検査する仕組みです。付与されたインサイトが施策の判断材料になる以上、品質に責任を持つ必要があります。人間による品質検査には量的な限界があるため、Gemini による5観点の独立評価を、品質保証レイヤーとして組み込んでいます。これは LLM ジャッジ（Large Language Model による評価）と呼ばれる、大規模言語モデルに出力の良し悪しを判定させる手法です。5 観点は以下のとおりです。 一貫性: 矛盾するタグがないか 妥当性: その人らしいか 網羅性: 必要な観点があるか 不足検出: タグの抜けはないか 実用性: マーケティング施策に使えるか 発見 3: 承認済みルーティンによる双方の資産保護 3 つ目は、データを守りながらロジックも守る仕組みです。顧客データは企業環境から一切出さない一方で、博報堂の推論ロジックも公開しません。この双方の資産保護を、BigQuery の承認済みルーティン（Authorized Routine）で実現しています。承認済みルーティンは、呼び出し元に定義内容を開示せず、実行権限のみを付与できる機能です。 参考 : 承認済みルーティン Why 分析の先にあるもの AI の均質化とブランドらしさ 最終章では、AI エージェントが購買の意思決定を担う時代の展望が語られました。購買が AI エージェント経由になるほど、効率最適化により「どのブランドも同じ答え」に収束するリスク（AI の均質化）があります。 エージェントが最適解を出す時代では、生活者の「なぜ（Why）」への深い理解こそがブランドらしさの源泉であり、ブランドに求められるのは最適化ではなく「選ばれる理由」を持ち続けることである、と締めくくられました。 業種を越えた共通フレームワークへ また、この設計様式は博報堂だけの話ではない、という点も強調されました。ID 突合に依存しないポストクッキー時代（サードパーティ Cookie が使えなくなる時代）のマーケティング手法として、また「データを動かさず、処理を動かす」という厳格なデータガバナンス下で AI 利用を進めるための共通フレームワークとして、規制業界を含むデータを持つすべての企業に波及していくという展望が示されました。対象業種の例として、小売、金融、通信、旅行、メディアが挙げられました。 関連記事 blog.g-gen.co.jp 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh

はじめに 株式会社 MIXI は、コミュニケーションを軸に、ソーシャルネットワーキングサービスからゲーム、スポーツ、ライフスタイルサービスへと事業を多角化してきた日本の企業です。「モンスターストライク」や「家族アルバム みてね」といったサービスに加え、FC東京をはじめとするプロスポーツチームの運営を通じて、人と人との豊かなコミュニケーションの場を提供しています。 本記事では、MIXI が FC東京向けに開発した「写真選定業務効率化システム」のバックエンドデータベースとして、Amazon Aurora DSQL 採用の経緯と技術的な工夫、得られた効果を、お客様の声を交えて紹介します。 ※本画像は、FC東京様と MIXI 様の許諾を得て掲載しています 解決したかった課題 FC東京では、試合ごとに公式カメラマンが撮影した約 1 万枚の写真を、試合当日に Web 公開するマッチレポートといったマーケティング・広報用途に活用しています。これまでは担当者が写真を目視で 1 枚ずつ確認しながら選定する運用を行っており、選定に時間がかかることでタイムリーに写真素材を活用できないことが課題でした。そこで、画像認識モデルと生成 AI を組み合わせて自動的に写真を分析・選定し、Web UI から候補を素早くプレビューできるシステムを新規に構築することにしました。 ただし、その開発・運用を担うのは少人数のチームであり、データベースの管理に人手をかけられないという事情がありました。加えて、試合は基本的に週 1〜2 回、主に土日に開催され、そのたびに写真の取り込み・分析・選定が短時間に集中する一方、試合と試合の間には、データベースへのアクセスが発生しない時間帯が生じます。こうした稼働に波のあるワークロードでは、データベースにアクセスしない時間帯のコストを抑える最適化も必要でした。 なぜ Aurora DSQL を選んだのか これらの前提を踏まえ、データベースに求めたのは、少人数で無理なく運用でき、稼働の波にも無駄なく対応できる運用特性でした。決め手は次の点です。 メンテナンス・バージョン管理が不要 ：エンジンのバージョンアップやメンテナンスウィンドウを意識する必要がなく、専任 DBA を置かずに少人数のチームで運用できる 使った分だけの課金 ： 「リクエストベースの、使用量主導型の価格モデル」 を採用しており、データベースへのアクセスが発生しない時間帯は処理に対する課金が発生しないため、固定インスタンス（常時稼働）の構成と比べて利用に波のある本ワークロードでも無駄なコストを抑えられる 通常の RDB として利用できる ：使い慣れた SQL でデータを扱え、PostgreSQL のドライバー・ORM・ツールも活かせる（後述のとおり一部の対応を実施） アーキテクチャ概要 システム全体のアーキテクチャは以下の通りです。 技術的に工夫した点 本システムでは、JavaScript / TypeScript の ORM である Drizzle（ https://orm.drizzle.team/ ）を採用しています。Aurora DSQL が PostgreSQL 互換であることを活かして Drizzle をベースに実装を進めました。ただし、一部の PostgreSQL 機能との非互換 や トランザクションサイズなどの制限 があり、次のような対応を行っています。なお、本記事で触れる Aurora DSQL の制約・仕様は執筆時点のものです。Aurora DSQL は継続的に機能追加・改善が行われているため、最新の情報は公式ドキュメントをご確認ください。 1. ORM の Drizzle が出力する DDL を Aurora DSQL 互換形式に変換するスクリプトを内製 Drizzle が生成するスキーマ変更 DDL は通常の PostgreSQL を想定しており、Aurora DSQL の制約・仕様に合わない箇所があります。AWS は Aurora DSQL 向けに、 一部の ORM フレームワーク用のアダプター／ダイアレクトや、各種データベースドライバー用のコネクター を公開していますが、本システムで採用している Drizzle 向けのアダプターは執筆時点では提供されていませんでした。そこで、Drizzle が出力する DDL を Aurora DSQL の制約・仕様に合わせて変換するスクリプトを内製しました。主な処理は次の通りです。 インデックス作成 ：Aurora DSQL では単体の CREATE INDEX 文に非同期指定（CREATE INDEX ASYNC）が必須のため、Drizzle が出力する CREATE INDEX を CREATE INDEX ASYNC に変換する処理 外部キー制約 ：Aurora DSQL は外部キー制約をサポートしていないため、Drizzle が生成する外部キー制約の ALTER TABLE（ADD FOREIGN KEY）を削除する処理 トランザクションの分割 ：Aurora DSQL は 1 トランザクションにつき DDL を 1 つしか実行できないため、複数の DDL 変更を 1 つのトランザクションでまとめて適用しようとする Drizzle のマイグレーションを、1 つずつ個別のトランザクション（BEGIN … COMMIT）に分割する処理 これらの変換は、Drizzle のマイグレーションを実行するコマンド（npm script）に組み込んでいます。ローカルでも CI/CD パイプラインでも同じコマンドで実行されるため、開発者は通常の Drizzle のワークフローのままスキーマ変更を進められます。 2. トランザクションサイズ制限への対応：大きな更新を複数のトランザクションに分割 Aurora DSQL には、1 トランザクションあたりに変更できる行数に上限があります（3,000 行）。1 試合あたり約 1 万枚の写真それぞれに 5〜6 個のタグを付与します。レコード数はタグだけで約 5〜6 万件に達し、さらに写っている人物の関連付け（人数分のレコード）も登録します。これらをまとめて 1 つのトランザクションで反映すると上限（3,000 行）を超えてしまいます。本システムでは、一時的な不整合が許容できる処理を整理したうえで、分析結果の反映については複数の小さなトランザクションに分割して処理する方式にしました。これにより、1 トランザクションあたりの変更行数を上限内に抑えています。利用者には処理中かどうかの状態を画面に表示し、アップロード・分析の進捗を把握できるようにしています。 3. OCC（楽観的同時実行制御）への対応 Aurora DSQL は OCC を採用しており、コミット時に競合が検出された場合はトランザクションをリトライする必要があります。本システムでは、ドライバー層にリトライ処理を作り込み、競合時には数回リトライしたうえで、それでも成功しない場合はデッドレターキューへ退避させて後続のハンドリングを行っています。 開発・運用面で得られた効果 本システムの設計・実装は、「AWS Prototyping Program」の支援を受けて進めました。これは、AWS の Prototyping Engineer が課題に合わせてシステムのプロトタイプを開発するプログラムです。約 1 か月の開発期間を経て、プロジェクト開始から約 2 か月後には本番稼働まで到達できました。DSQL 採用後に開発チームが実感している効果は次の通りです。 メンテナンスウィンドウ・バージョン管理が不要 「DB の存在を意識せず開発・運用できる」ことが採用後最大のメリットでした。標準でマルチ AZ 構成になっており、実際、本番稼働後 DB 起因の障害は発生していません。従来型の（プロビジョンド構成の）RDB を採用していた場合は 0.5 人月程度を要すると想定していましたが、Aurora DSQL の採用後はこうした作業がほぼ不要となりました。 少人数チームでアプリ開発に集中できる DBA を専任で置く必要がなく、インスタンスのサイジングやスケーリングといったキャパシティ設計そのものが不要なため、少人数のチームでもアプリケーション機能の実装に集中でき、開発スピードを保てました。本システムはデータベースを含むアプリケーション全体を実質 1 名で開発していますが、サーバーレス構成によりキャパシティを意識せずデータベースを扱えたことが、開発の高速化に直結しています。なお、開発メンバーは PostgreSQL の利用経験があり、DSQL 自体の学習コストはほとんど発生しませんでした。DSQL 固有の制約事項についても理解・把握は短時間で済み、それらへの具体的な対応は前述の「技術的に工夫した点」のとおり実装で吸収しています。 使った分だけの課金で無駄のないコスト構造 稼働に波がある本システムでは、使った分だけの課金というコストモデルが特によく合致しました。アクセスが発生しない時間帯は処理に対するコストがかからないため、こうしたワークロードでも無駄なコストを抑えられています。 性能要件を十分に満たせている 複雑な検索条件を設定してもサムネイル一覧の初期表示は 1 秒以内に収まり、写真分析のスループットも実用上十分な速度で完了しています。実運用において、データベースがボトルネックになったことはありません。もちろん DB 性能だけで実現したわけではありませんが、Aurora DSQL がこれらの要件を性能面の問題なく支えられていることが、システム全体としての設計余地を広げてくれています。 さいごに 株式会社 MIXI では、FC東京向けの写真選定業務効率化システムのバックエンドに Aurora DSQL を採用し、利用が特定の時間帯に偏るワークロードを、運用工数を最小限に抑えながら短期間で本番稼働まで到達させることができました。株式会社 MIXI の數藤氏は次のように振り返っています。 「DB の存在を意識せずに開発・運用できることが一番のメリットでした。メンテナンスやスケーリングの設計から解放され、少人数のチームでもアプリケーション開発に集中できています。こうした特性を持つワークロードでは、今後も積極的に Aurora DSQL を活用していきたいと考えています。」 Aurora DSQL の採用を検討しているチームにとって、本事例が一つの参考になれば幸いです。 株式会社 MIXI ライブエクスペリエンス事業本部 企画推進部 エンジニアリング支援グループ 數藤 智幸 氏

2026 年 3 月 24 日に公開された “ Building a modern network for your VMware workloads using Amazon Elastic VMware Service ” を翻訳したものです。 組織がクラウド移行を加速させようとする中で、多くのお客様は既存の VMware ワークロードを Amazon Web Services (AWS) にリフトアンドシフトする方法を求めており、アプリケーションのリファクタリングやスタッフの再トレーニングのオーバーヘッドを避けたいと考えています。 Amazon Elastic VMware service (Amazon EVS) は、VMware Cloud Foundation (VCF) を Amazon Virtual Private Cloud (VPC) 内で直接実行でき、VMware ワークロードを AWS で移行・運用するための最も迅速な方法を提供します。 VMware ワークロードを AWS に移行する際にお客様が課題として挙げるのが、クラウドでのネットワーク接続とアーキテクチャ設計です。Amazon EVS のネットワークモデルは、一般的なオンプレミスの VMware デプロイメントとはいくつかの違いがあります。本稿では、Amazon EVS のネットワークモデルを解説し、実証済みのアーキテクチャパターンをご紹介し、Amazon EVS の計画と導入を成功させるための重要な考慮事項をご説明します。 Amazon EVS ネットワークコンポーネント Amazon EVS は、図 1 に示すように、AWS インフラストラクチャ上で VCF ワークロードをデプロイし、運用するために構築された AWS マネージド自動化フレームワークです。Amazon EVS は、VCF の Software-Defined Data Center (SDDC) スタック (vSphere, vSAN, NSX) を Amazon VPC に完全に統合し、VMware ツールと API を保持しながら、シームレスなハイブリッドクラウド運用を可能にします。Amazon EVS ネットワークは、Amazon VPC ネットワークを分離する 2 層モデルに従い、お客様が VMware NSX Software-Defined Networking を使用できるようにします。 アンダーレイ層 (VPC infrastructure) : Amazon VPC, サブネット, ルートテーブル, およびお客様が選択したサブネット内で実行される ENI 接続 ESXi ホストで構成されます。この層はホストマネジメントトラフィック (vSphere, vSAN) を処理し、デフォルトまたはメイン VPC ルートテーブルを通じて IP 接続を実現します。 オーバーレイ層 (NSX Software-Defined Networking) : NSX Manager はマネジメントワークロードドメイン内にデプロイされ、ロジカルスイッチ (セグメント), T0/T1 ゲートウェイ, およびサービス (NAT, Load Balancing, DHCP) をオーケストレーションします。NSX マイクロセグメンテーションとポータブルネットワークポリシーが有効化され、アンダーレイ VPC ネットワークから抽象化し、お客様のワークロードはオーバーレイセグメント上でのみ実行されます。 図 1: ルートサーバーエンドポイントを使用した Amazon EVS と Amazon VPC の統合 主要コンポーネントの詳細 vSphere クラスター: Amazon EVS は統合された VCF アーキテクチャ (vCenter, NSX Manager, vSAN) をデプロイし、お客様が 1 つ以上のワークロードドメインを作成できるようにします。ESXi ホストは、お客様所有の VPC とサブネット内で Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンス (例: i4i.metal) として起動されます。SDDC Manager と vCenter は、SDDC と vSphere クラスターコンポーネントの管理を担います。これらのコンポーネントは、管理ドメインとも呼ばれる最初の SDDC クラスター内で実行されます。さらに、3 つのクラスター化された NSX Manager が SDDC クラスター内で実行され、一元化されたネットワークポリシーオーケストレーションを可能にします。コントロールプレーンは、オーバーレイトランスポートゾーン、セグメントプロファイル、ゲートウェイファイアウォールルールを設定します。 NSX Edge ノード: 2 つの Edge ノードが最初のクラスターまたは管理ドメイン内の Edge クラスターにデプロイされます。T0 Gateway は各 AWS アベイラビリティーゾーン (AZ) サブネット内の VPC ルートサーバーエンドポイントと eBGP ピアリングを確立し、オーバーレイ CIDR をアドバタイズします。T1 Gateway (テナント/ワークロードごとに 1 つ) はセグメントを接続し、ステートフルサービスを提供します。NSX Edge はレジリエンシーのためにアクティブ-スタンバイ構成です。 VPC ルートサーバーエンドポイントと BGP ピアリング: Amazon EVS は Amazon VPC ルートサーバー をアンダーレイ BGP ネイバーとして使用します。各 T0 Edge は VPC ルートサーバーエンドポイントに接続し、アンダーレイ ENI 上で eBGP セッションを確立します。VPC のデフォルトまたはメインルートテーブルのみが変更されます。Amazon EVS はアウトバウンドトラフィック用に T0 ENI を指す 0.0.0.0/0 を注入し、オーバーレイプレフィックスをインバウンドに伝播します。この設計により、カスタムルートテーブルの拡散が排除され、自動化が合理化されます。 ネットワークアーキテクチャの計画 Amazon EVS の導入を成功させるには、導入前のネットワーク計画が重要です。特に CIDR 割り当て、サブネット分離、DNS 解決に関する計画が必要です。Amazon EVS では、運用の安定性、スケーラビリティ、他の AWS サービスとの統合を提供するための厳格な制約があります。これらの領域での設定ミスは、導入失敗の主要な原因となっています。 CIDR の計画と制約 Amazon EVS では、インフラストラクチャとワークロードのネットワークに専用の重複しない CIDR ブロックが必要です。AWS では、この情報をまとめるためのツールをお客様に提供しています。 このツール は、アカウント、VPC、CIDR、DNS の情報を含むスプレッドシートで、オンボーディング中の計画に使用し、プロビジョニング前の実現可能性を検証します。 VCF では、図 2 に示すように、用途毎 (マネジメント, vSAN, NSX インターフェース, アプライアンスなど) に異なるサブネットを使用します。Amazon EVS では、適切なサブネットデプロイメントを提供するオーケストレーションを提供します。アンダーレイインフラストラクチャには VPC あたり最小 /24 CIDR が必要で、Amazon EVS マネジメントサブネットではお客様のワークロード (踏み台ホストや監視エージェントを含む) を起動することはできません。これらは VCF コンポーネント専用です。 VCF 以外のサブネットは、同じ VPC 内にデプロイして使用できます。Amazon EVS VPC に他のワークロードを追加する際には、 AWS Well-Architected のベストプラクティスを考慮してください。 Amazon EVS のサブネットの最大サイズは /24 です。host-vtep ネットワークはホストあたり 2 つのアドレスを消費するため、/24 では最大 112 台のホストをホストできます。 図 2: オーバーレイネットワーク用の EVS VLAN サブネット オーバーレイセグメント設計と VM ネットワーク: これらはオーバーレイセグメントに階層的に CIDR を割り当てます (例：アプリケーションティアごとに /24)。成長とワークロード数の増加を想定し、ルートテーブルの効率化のために、ルート集約を検討してください。 CIDR が重複しないこと: すべてのオーバーレイ CIDR は以下と重複してはいけません。 VPC プライマリ CIDR オンプレミスネットワーク ( AWS Direct Connect と AWS Transit Gateway 用) 同じ AWS アカウント内の他の Amazon EVS ワークロードドメイン。Amazon EVS は BGP プレフィックスアドバタイズメントを使用し、重複はサイレントトラフィックブラックホールを引き起こします。 NSX ネットワークセグメント内での重複サブネットは、テスト目的のワークロードを隔離するのに良い方法です。 DNS DNS 解決は Amazon EVS のデプロイメント前に設定と検証を行う必要があります。DNS 解決が適切に行われていない場合やタイプミスがある場合、Amazon EVS (VCF) のデプロイメントは失敗します。 Amazon EVS は DNS 解決に Amazon Route 53 Resolver を使用できます。vCenter と NSX Manager アプライアンスには DNS フォワーダーが事前設定されており、Route 53 Resolver インバウンドエンドポイント (VPC にデプロイ) にクエリを送信できます。 Amazon EVS は Microsoft DNS、Infoblox、その他のサードパーティソリューションなど、他の DNS サービスも使用できます。 Amazon EVS の起動前に外部ホストから nslookup や dig -x でテストを行うことで、時間のかかる潜在的にコストの高いデプロイメント失敗を防ぐことができます。 前提条件 この 前提条件チェックリスト を参照して、デプロイメントを成功させるための情報収集と整理を行ってください。これは、前述した スプレッドシート と併用できます。適切な事前計画により、Amazon EVS ネットワークデプロイメントの問題の 90% を解決できます。このチェックリストでは、以下の項目について触れています。 VPC CIDR Amazon EVS (VCF) サブネット Route 53 Resolver エンドツーエンドで検証された正引き / 逆引き DNS 一般的なネットワークパターン このセクションでは、デプロイメントで検討すべき一般的なアーキテクチャについて説明します。 パターン 1: Transit Gateway と AWS Cloud WAN を使用した Amazon EVS VPC から他の VPC およびオンプレミスネットワークへの接続 図 3: Transit Gateway を使用した Amazon EVS VPC から他のネットワークへの接続 図 3 に示すこのパターンは、Amazon EVS オーバーレイセグメントから複数の VPC、オンプレミス/外部ネットワーク、および他の AWS リージョンへの一貫性のあるスケーラブルな接続が必要な場合に使用します。 このパターンでは以下の点が重要です: 本稿の執筆時点 (2026/3) では、VPC ピアリングはサポートされていません。Amazon EVS VPC から他の VPC への接続には Transit Gateway や AWS Cloud WAN が必要です。 Transit VIF を使用した Direct Connect や AWS Site-to-Site VPN は、Amazon EVS アンダーレイ VPC ではなく、Transit Gateway / AWS Cloud WAN で終端する必要があります。Amazon EVS は Private VIF や VGW ベースの Site-to-Site VPN をサポートしていません。 NSX オーバーレイプレフィックスは BGP を通じて VPC ルートサーバーによって学習され、VPC ルートテーブルに伝播されますが、Transit Gateway と AWS Cloud WAN はこれらのルートを自動的にインポートしません。そのため、各 NSX オーバーレイ CIDR 範囲について、Amazon EVS VPC アタッチメントを指す静的ルートを Transit Gateway/AWS Cloud WAN ルートテーブルに追加する必要があります (図 3 参照)。AWS Cloud WAN の場合、これらの静的ルートはコアネットワークポリシーで設定します。 より多くの AWS リージョンに拡張する際は、モダンなポリシー駆動型のグローバルネットワークを提供するAWS Cloud WAN を検討してください。これにより、手動での Transit Gateway ピアリングが不要になり、AWS リージョンと VPC 間の動的ルーティングが可能になります。 パターン 2: AWS PrivateLink を使用した Amazon EVS から AWS および非 AWS サービスへのプライベート接続 図 4: Amazon EVS VPC から AWS および非 AWS サービスへのプライベート接続 NSX オーバーレイセグメント上のワークロードが、インターネットを経由することなく、AWS サービス ( Amazon Simple Storage Service (Amazon S3) や Amazon DynamoDB など)、お客様が管理するサービス、またはサードパーティ ISV サービスをプライベートに利用する必要があるパターンです。 インターフェースエンドポイント : AWS サービスへの接続には、インターフェース VPC エンドポイントを使用します。インターフェースエンドポイントは、Amazon EVS VPC 内の非 Amazon EVS サブネットに配置するか、 Transit Gateway / AWS Cloud WAN 経由でアクセス可能な別の共有サービス VPC に配置 します。Amazon EVS オーバーレイから T0 を通じてエンドポイントへトラフィックをルーティングします。2026/3 時点では、S3 ゲートウェイエンドポイントは Amazon EVS でサポートされていません。Amazon EVS ワークロードからの Amazon S3 アクセスには、インターフェースエンドポイントを使用する必要があります。 プライベート DNS : VPC DNS 属性を有効にする必要があります。プライベート DNS でインターフェースエンドポイントを使用する場合は、スプリットホライズン DNS シナリオに対して適切な Route 53 Resolver 転送ルールを設定します。 サービスネットワークエンドポイントとリソースエンドポイント : サービス間またはリソース接続でゼロトラストな接続に VPC Lattice を使用したい場合は、サービスネットワークエンドポイントまたはリソースエンドポイントを使用できます。Lattice サービスネットワークエンドポイントとリソースエンドポイントは、T0 を通じて VPC への NSX オーバーレイネットワークからアクセスできます。2026/3 時点では、Lattice サービスネットワーク関連付けは Amazon EVS でサポートされておらず、接続にはエンドポイントの使用が必要です。 ベストプラクティス: Amazon EVS 専用の VPC Amazon EVS VPC は Amazon EVS リソース専用とすることを検討してください。共有サービスやその他の Amazon EVS 以外のワークロードは、Transit Gateway または AWS Cloud WAN を通じて接続された VPC に配置します。このアプローチにより、より明確な障害範囲の境界、より良いコスト配分とチャージバック、コンプライアンスとセキュリティ監査が提供されます。 セキュリティポリシーの適用 Amazon EVS におけるセキュリティには多層防御アプローチが必要で、複数のレイヤーでポリシーを適用します。 NSX Distributed Firewall (DFW) vDefend の DFW は、ハイパーバイザーカーネル内の VM のネットワークインターフェースに直接適用される L2 – L7 ファイアウォール機能を提供します。また、DFW はマイクロセグメンテーションを可能にし、以下のような機能を持っています。 NSX 論理セグメント間の East-West トラフィック制御 タグベースの動的セキュリティグループ vDefend を通じた IDS/IPS 機能や、アプリケーション対応フィルタリングなどのその他のセキュリティ機能 現在の VCF NSX ライセンスオプションについては、Broadcom VMware アカウントチームにご相談ください。 AWS セキュリティコントロール AWS セキュリティグループは Amazon EVS VLAN サブネット上の Amazon EVS ENI には適用されません。ただし、セキュリティグループを使用して、インターフェースエンドポイントや Amazon EVS 以外のサブネット内の他のワークロードへのトラフィックを制御できます。 Amazon EVS VLAN サブネット上でアンダーレイのアクセス制御においては Network ACL (NACL) を使用して、DNS, SSH, オンプレミスへのハイブリッド接続用の Hybrid Cloud Extension (HCX), VPC ルートサーバーピアリング用の BGP などのプロトコルのトラフィックを許可することができます。 以下の用途で、VPC の Ingress / Egress ポイントに AWS Network Firewall またはパートナーファイアウォールソリューション ( Gateway Load Balancer 経由) の導入を検討してください。 North-South トラフィックの検査・制御 Amazon EVS 環境に出入りするトラフィックの IDS/IPS URL フィルタリング, 脅威インテリジェンス, コンプライアンス・監査ログなどのセキュリティ機能 モニタリング VPC Flow logs などの AWS モニタリングサービスは、Amazon EVS ENI のアンダーレイトラフィックのみを確認でき、NSX オーバーレイトラフィックは確認できません。オーバーレイのモニタリングは、Aria operations for Networks、NSX Traceflow などの VMware ツールを使用してください。 考慮事項 NSX トランスポート MTU 設定が Amazon EC2/VPC アンダーレイ機能と一致していることを確認してください。現世代の EC2 インスタンスは最大 9001 バイトのジャンボフレームをサポートし、Transit Gateway は最大 8500 バイト、Direct Connect は Transit VIF で最大 8500 バイトをサポートします。NSX 内の MTU 制限を考慮してください。 NSX Edge T0 ゲートウェイは、サイズが不十分な場合にスループットのボトルネックになる可能性があります。NSX Edge データパスメトリクスを監視し、Edge のサイジングとチューニングに関する VMware のパフォーマンスガイダンスに従ってください。 Amazon EVS では、同一アベイラビリティーゾーン内でのレジリエンシーのために 2 つの VPC ルートサーバーエンドポイントが必要です。2 つの NSX Edge T0 ノードは Active/Standby モードで動作し、各エッジは 1 つの VPC ルートサーバーエンドポイントとピアリングします。 アクティブな T0 エッジがすべての North-South トラフィックを処理します。フェイルオーバー時間を監視し、障害シナリオをテストして、アプリケーションが Edge ノードフェイルオーバーイベントに対応できることを確認してください。 Amazon EVS は IPv4 のみをサポートします。執筆時点 (2026/3) では IPv6 は利用できません。 Amazon EVS は、ピアの生存確認にデフォルトの BGP キープアライブメカニズムをサポートします。Multi-hop Bidirectional Forwarding Detection (BFD) はサポートされていません。 作成時、VLAN サブネットは VPC のメインルートテーブルに暗黙的に関連付けられます。デプロイ後、Amazon EVS VLAN サブネットをカスタムルートテーブルに明示的に関連付けることができます。NSX 接続用にカスタムルートテーブルを作成することをお勧めします。 セキュリティグループは Amazon EVS ENI には適用されません。アンダーレイのアクセス制御には NACL を使用してください。Amazon EVS ワークロードにステートフルなセキュリティポリシーを提供するために、より多くの NSX セキュリティオプションを検討してください。 本稿の情報は、今後の Amazon EVS サービスのアップデートにより変更される可能性があります。 まとめ Amazon Elastic VMware Service (Amazon EVS) は、VMware Cloud Foundation スタックを VPC 内に直接配置し、AWS での VMware テクノロジーの制御と柔軟性を提供します。デプロイメントを成功させるには、事前に十分な計画を立て、適切なルーティングパターンを選択し、適切なレイヤーでセキュリティを実装してください。これらの原則に従うことで、VMware ワークロードを AWS インフラストラクチャ上で実行し、確立されたネットワーク、セキュリティ、運用パターンを適用し、モダナイゼーションとイノベーションのための幅広い AWS サービスを活用することができます。 著者について Victor Babasanmi Victor は AWS のシニアネットワークスペシャリストソリューションアーキテクトです。彼はベストプラクティスを使用したソリューションの計画と構築に関する技術的なガイダンスをお客様に提供し, AWS 環境を運用面で健全に保つことに積極的に取り組んでいます。仕事以外では、サッカーやワークアウト、新しいことに取り組んでいます。 Craig Herring Craig Herring は AWS でシニアスペシャリストソリューションアーキテクトを務めており、インフラストラクチャの移行とモダナイゼーションを専門としています。2021 年に入社して以来、Craig は 35 年にわたる豊富な業界経験を活かして、お客様が AWS ソリューションへの移行とその効果の最大化を支援しています。仕事以外では、Craig は妻の Lindy と 8 人の子供と 3 人の大家族との時間を大切にしています。個人的な興味は友人との交流、ドライブ、アクティブなライフスタイルの維持、オーディオ機器の製作など多岐にわたります。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。