![[レポート] Amazon VPC Latticeを使ったモダンなアプリケーション移行アプローチを紹介するセッションに参加しました #AWSreInvent #NET309](https://images.ctfassets.net/ct0aopd36mqt/4pUQzSdez78aERI3ud3HNg/fe4c41ee45eccea110362c7c14f1edec/reinvent2025_devio_report_w1200h630.png?w=3840&fm=webp)
[レポート] Amazon VPC Latticeを使ったモダンなアプリケーション移行アプローチを紹介するセッションに参加しました #AWSreInvent #NET309
はじめに
皆様こんにちは、あかいけです。
AWS re:Invent 2025に参加しており、
「A modern approach to application migration with Amazon VPC Lattice」というセッションを聞いてきました。
レガシーなモノリシックアプリケーションのモダナイゼーションは、多くの企業が直面する課題です。
ただ、「ビッグバン」的なの一括移行はリスクが高く、ビジネスへの影響も大きいですよね。
このセッションでは、Amazon VPC Latticeを活用して段階的にマイクロサービス化を進める方法について、AWSのSolutions Architectと実際のお客様事例であるGoldman Sachsの担当者から詳しく解説がありましたので、その内容をまとめてみました。
セッション概要
タイトル
A modern approach to application migration with Amazon VPC Lattice [SIMULCAST]
概要
Modernizing legacy apps? It doesn't have to be a "big bang". Discover how to use Amazon VPC Lattice and AWS services to drive a smooth, step-by-step migration. Learn proven patterns for breaking down monoliths into microservices without disrupting your business. Through real-world examples, we will explore secure communication, multi-account setups. We will show how IP overlap is easily handled, and may even be an asset for Amazon EKS cluster upgrades.
レガシーアプリのモダナイゼーションをお考えですか?「ビッグバン」は必要ありません。Amazon VPC LatticeとAWSのサービスを活用して、スムーズで段階的な移行を実現する方法をご紹介します。ビジネスに支障をきたすことなく、モノリスをマイクロサービスに分割するための実証済みのパターンを学びます。実例を通して、安全な通信や複数アカウントの設定方法を探ります。IPアドレスの重複を簡単に処理する方法、そしてAmazon EKSクラスターのアップグレードに役立つ可能性についてもご紹介します。
スピーカー
- Jamie Wenzel (Principal Solutions Architect, AWS)
- Yecine Allouache (Senior Solutions Architect, AWS)
- Ryan J McDonough (Technology Fellow/Vice President, Goldman Sachs)
セッション情報
- レベル: 300 - Advanced
- セッションタイプ: Breakout session
- トピック: Application Integration, Networking & Content Delivery

セッション内容
アジェンダ
セッションは以下の流れで構成されていました。

- Current Landscape: 現在の状況 - どこから始まり、どのようにしてここに来たのか、何が必要か
- Requirements: 要件 - 何を変える必要があるのか
- VPC Lattice: VPC Latticeとは何か、どのように役立つのか
- Modernize: VPC Latticeを使ったモダナイゼーションの方法と理由
- Real world example: Goldman Sachsの実例
現在の状況: なぜ複雑なアーキテクチャが生まれるのか

セッションでは、なぜ企業のアーキテクチャが複雑になるのかについて説明がありました。
- ビジネスニーズに基づいてスタートする
- ビジネスが成長すると、要件も増加する
- 要件はめったに順序立てて発生しない
- 顧客は既存のものの上に構築し、できる限り要件を満たそうとする
その結果、以下のような複雑なアーキテクチャが生まれます。

複数のVPC、PrivateLink、オンプレミスのデータセンターとの接続など、様々なコンポーネントが絡み合った状態になりがちです。
現場が抱える課題

セッションでは、企業が直面する典型的な課題が紹介されました。
- Site-to-Site VPNのスケーラビリティとセキュリティ: パートナーからの不満
- PrivateLinkの限界: 買収により、双方向のPrivateLinkソリューションの容量が不足
- IPv6対応の必要性: 顧客の要求により、現在の接続ソリューションがスケールしない
- メインフレームのセキュリティ: バックエンドサービスとのみ通信させたい
- コンテナ化の推進: モノリシックなコンピュートをコンテナに置き換えたい
- 買収企業の統合: オンプレミスデータベースへのアクセスが必要
VPC Latticeとは

VPC Latticeは、VPCとアカウントをまたいでサービスとリソースを接続するフルマネージドサービスです。

主な特徴
- Compute: Amazon EC2、AWS Fargate、Amazon ECS、Amazon EKS、AWS Lambdaをサポート
- Protocol Support: HTTP/HTTPS、TCP、TLS、Custom IP/DNS
- Databases: Amazon RDS、Oracle Database@AWS、セルフマネージドデータベース
- Hybrid: オンプレミスとの接続
- Shared developer experience: アプリケーション、ネットワーク、セキュリティチームに統一された体験を提供
VPC Latticeの構成要素
Services(サービス)

サービスは、コンピュートエンドポイントを公開するためのメカニズムを提供します。
- ターゲットグループ、ロードバランシングオプション、ルーティングルール、認証ポリシーを設定
- サービスあたり最大10個のターゲットグループをサポート
- Blue/Greenデプロイメント、アップグレードなどを簡素化
Services & Resources

Application-Resourceとして、Amazon RDS、DNS、IPなどのTCP対応の宛先を定義できます。
Accounts(マルチアカウント対応)

複数のアカウントにまたがるサービスを、VPC Lattice Service Networkを通じて接続できます。
- Account A/Bのクライアントサービス・リソース
- Account Cのサービス群とリソース設定
- すべてがService Networkを通じて連携
VPC Lattice vs Transit Gateway

ここでは「部屋の中の象」として、VPC LatticeとTransit Gatewayの違いについて説明がありました。
| 観点 | Transit Gateway | VPC Lattice |
|---|---|---|
| 概要 | 複数のVPCと外部ネットワーク間の接続を中央ハブで実現するネットワーキングサービス | VPCとアカウントをまたいだサービス間通信を簡素化するフルマネージドサービス |
| フォーカス | Core Networking - L3/L4でのスケーラブルで信頼性の高いネットワーク間接続、ルーティングとサブネットを使用したセキュアなデータ転送 | Application Networking - サービス通信、ディスカバリ、負荷分散、認証、L7でのオブザーバビリティ |

同等の構成でのコスト比較
- TGW/ALB構成: $1,387/月 (1 Transit Gateway + 4 Application Load Balancers)
- VPC Lattice構成: $750/月 (1 Service Network + 4 services)
VPC Latticeを使うことで、約45%のコスト削減が可能という試算でした。
移行戦略: ステップバイステップのアプローチ

セッションでは、段階的な移行アプローチが詳しく解説されました。
Step 1: VPC Lattice + RAM (Resource Access Manager)の構成

- VPC Lattice Service Networkを作成し、VPCを関連付け
- RAMでService Networkを共有
- IAMポリシーでアクセスとルーティングを制御するサービスを作成
Step 2: ポリシーによるセキュアな通信

VPC Latticeでは、3つのレベルでポリシーを設定できます。
- Service Network: 粗い粒度のポリシー - Service Networkを通過できる人を制御
- Service: 細かい粒度のポリシー - 個々のサービスへのアクセスを制御
- Resource: 個々のリソースへのアクセスを許可する設定
Step 3: IPオーバーラップの解決
VPC Latticeの大きな利点の一つは、IPアドレスの重複を気にする必要がないことです。
買収した企業や異なる環境で同じIPレンジを使っていても、VPC Latticeを通じてシームレスに接続できます。

Goldman Sachsの実例
セッションの後半では、Goldman SachsのRyan McDonough氏から、実際の導入事例が紹介されました。

Fast Track: 開発者体験の向上
Goldman Sachsでは「Fast Track」というプラットフォームを構築し、開発者が簡単にAWSリソースを利用できるようにしています。
- Developer → Fast Track Control Plane → Account Provisioning → GS Organization Management
- Push Changes → Deployment Pipeline → SDLC/Application AWS Accounts
VPC Sharingからの進化

従来のVPC Sharing構成では、
- Shared VPC AccountにCorp Routable SubnetsとInternal subnetsを配置
- Service EndpointsとAWS Private Endpointsを設定
次世代ネットワークアーキテクチャの目標

Goldman Sachsが目指したネットワークアーキテクチャの目標
- 強力なネットワーク分離の実現
- リソース競合の回避
- 異なるアカウントに公開されるエンドポイントの可視性確保
- エンタープライズサービスがシームレスに利用できる、開発者向けのシンプルなネットワーキング体験の提供
VPC Latticeによる新しいアーキテクチャ

新しいアーキテクチャでは、
- 各チームが独自のVPCを定義(接続なしの状態からスタート)
- Service Networkを通じて必要なサービスのみを公開・利用

複数のService Networkを追加することで、
- Shared Services Service Network: 共通サービスを提供
- Team Service Network: チーム固有のサービスを管理
- External Vendor Endpoint: 外部ベンダーとの接続
既存PrivateLinkからの移行

既存のPrivateLinkサービスをResource Configurationに適応させる方法も紹介されました。
Service Owner AccountのAWS PrivateLinkとResource Configurationを組み合わせ、Shared Services Service Networkを通じてTeam 1 Accountに接続する構成です。
まとめ

このセッションでは、以下の点が印象的でした。
- VPC Latticeの価値: Transit Gatewayとは異なるレイヤー(L7)でのアプリケーションネットワーキングに特化
- 段階的な移行: 「ビッグバン」ではなく、サービスごとに少しずつ移行できる
- IPオーバーラップの解決: 買収や環境統合時の大きな課題を解決
- コスト削減: 同等構成で約45%のコスト削減が可能
- Goldman Sachsの実例: 大規模エンタープライズでの実践的な導入パターン
VPC Latticeは、マイクロサービス化やマルチアカウント構成を進める企業にとって、非常に有用なサービスだと感じました。
特に、既存の複雑なアーキテクチャを段階的にモダナイズしたい場合に効果を発揮しそうです。
さいごに
以上、「A modern approach to application migration with Amazon VPC Lattice」のセッションレポートでした。
VPC Latticeについてはシステムの要件を見極めた上で、今後の設計で積極的に検討していきたいと思います。
特にマルチアカウント環境でのサービス間通信の課題を抱えているシステムには、活用できるのではないでしょうか。
この記事が皆様のネットワーク設計の参考になれば幸いです。








