AWS のエッジ戦略 - Outposts・Local Zones・Wavelength が描くハイブリッドの未来
AWS が Outposts、Local Zones、Wavelength の 3 つのエッジサービスで展開するハイブリッド・エッジ戦略を、Azure Stack や GCP Distributed Cloud と比較し、選択肢の幅と設計思想の違いを解説します。
すべてのワークロードがクラウドに移行できるわけではない
パブリッククラウドの利点は広く認知されていますが、現実にはすべてのワークロードをパブリッククラウドのリージョンに移行できるわけではありません。データ主権の規制により特定の施設内にデータを保持する必要がある場合、超低レイテンシが求められるリアルタイム処理、工場や店舗などの現場でのエッジ処理、5G ネットワークとの統合が必要なモバイルアプリケーションなど、パブリッククラウドのリージョンだけでは対応しきれないユースケースが存在します。AWS はこの課題に対して、Outposts、Local Zones、Wavelength という 3 つの異なるエッジサービスを提供しています。それぞれが異なるユースケースに最適化されており、ユーザーは要件に応じて適切なサービスを選択できます。この「用途別に専門化されたエッジサービスを複数提供する」アプローチは、Azure や GCP とは異なる設計思想です。
Outposts - オンプレミスに AWS を丸ごと持ち込む
AWS Outposts は、AWS のインフラストラクチャ、サービス、API、ツールを顧客のオンプレミス環境に拡張するサービスです。AWS が設計・製造したラックを顧客のデータセンターに設置し、AWS のリージョンと同じ API で EC2、EBS、S3、RDS、ECS、EKS などのサービスを利用できます。Outposts の核心的な価値は「一貫性」です。オンプレミスとクラウドで同じ API、同じツール (CloudFormation、CDK)、同じ運用手順を使えるため、ハイブリッド環境の運用複雑性が大幅に低減されます。開発者はデプロイ先がリージョンか Outposts かを意識する必要がほとんどありません。Outposts は AWS が所有・管理するモデルであり、ハードウェアの保守、ソフトウェアのアップデート、セキュリティパッチの適用はすべて AWS が行います。顧客は電力、ネットワーク、物理的なスペースを提供するだけです。この運用モデルは、オンプレミスのハードウェア管理から解放されたいが、データの物理的な所在地は制御したいという要件に適しています。
Azure Stack との設計思想の違い
Azure のハイブリッドソリューションは、Azure Stack Hub、Azure Stack HCI、Azure Stack Edge の 3 つで構成されています。Azure Stack Hub は Outposts に最も近い位置づけですが、設計思想に重要な違いがあります。Azure Stack Hub は、顧客が購入・所有するハードウェア上で Azure のサービスを実行するモデルです。ハードウェアの調達、設置、保守は顧客 (またはパートナー) の責任であり、AWS Outposts の「AWS が所有・管理」モデルとは対照的です。また、Azure Stack Hub で利用できるサービスは Azure のフルセットではなく、サブセットに限定されます。API の互換性も完全ではなく、Azure のリージョンで動作するテンプレートがそのまま Azure Stack Hub で動作しないケースがあります。Azure Stack HCI は Windows Server ベースのハイパーコンバージドインフラであり、Azure Arc を通じて管理されます。これは既存の Windows Server 環境との親和性が高い一方、AWS のサービスとの一貫性という観点では Outposts に及びません。GCP は Distributed Cloud として Google Distributed Cloud Edge と Google Distributed Cloud Hosted を提供していますが、Outposts や Azure Stack と比較すると市場での実績が限定的です。
Local Zones - リージョンの延長線上にある超低レイテンシ拠点
AWS Local Zones は、AWS のリージョンを特定の都市に拡張するサービスです。リージョンの AZ とは異なり、大都市圏の中心部に近い場所に設置され、エンドユーザーとの間で 1 桁ミリ秒のレイテンシを実現します。Local Zones は、リアルタイムゲーム、ライブ動画配信、AR/VR、金融取引など、レイテンシに極めて敏感なワークロードに適しています。リージョンの AZ では物理的な距離の制約から達成できないレイテンシ要件を、Local Zones が補完します。Local Zones の重要な特徴は、親リージョンの VPC を拡張する形で利用できる点です。新しい VPC を作成する必要はなく、既存の VPC にサブネットを追加するだけで Local Zones のリソースを利用開始できます。IAM、CloudWatch、CloudTrail などの管理サービスも親リージョンと統合されており、運用の一貫性が保たれます。Azure と GCP には、Local Zones に直接対応するサービスがありません。Azure の Extended Zones (旧 Azure Edge Zones) は類似の概念ですが、展開都市数と利用可能なサービスの範囲で Local Zones に及びません。
Wavelength - 5G ネットワークの内側で動くクラウド
AWS Wavelength は、通信事業者の 5G ネットワーク内に AWS のコンピューティングとストレージを配置するサービスです。モバイルデバイスからのトラフィックが通信事業者のネットワークを離れることなく AWS のサービスにアクセスできるため、インターネットを経由する場合と比較して大幅にレイテンシが低減されます。Wavelength のユースケースは、5G の超低レイテンシを活用するアプリケーションです。自動運転車のリアルタイム判断、工場の産業用 IoT、リモート医療の遠隔手術支援、クラウドゲーミングなど、ミリ秒単位のレイテンシが要求される領域で価値を発揮します。AWS は KDDI、Verizon、Vodafone、SK Telecom など、世界の主要通信事業者と提携して Wavelength Zone を展開しています。日本では KDDI との提携により、東京と大阪に Wavelength Zone が設置されています。Azure や GCP にも 5G エッジの取り組みはありますが、Wavelength のように通信事業者のネットワーク内にクラウドインフラを直接配置するアプローチは、AWS が先行しています。
3 つのエッジサービスの使い分け
Outposts、Local Zones、Wavelength は、それぞれ異なるユースケースに最適化されています。Outposts は、データ主権やコンプライアンスの要件でデータを特定の施設内に保持する必要がある場合、またはオンプレミスのシステムとの低レイテンシ接続が必要な場合に選択します。Local Zones は、特定の都市のエンドユーザーに対して 1 桁ミリ秒のレイテンシを提供したい場合に選択します。リージョンの AZ では距離的に達成できないレイテンシ要件を補完します。Wavelength は、5G ネットワーク上のモバイルデバイスに対して超低レイテンシを提供したい場合に選択します。通信事業者のネットワーク内で処理が完結するため、インターネットを経由するレイテンシが排除されます。この 3 つの選択肢を持つことが AWS の強みです。Azure は Azure Stack と Extended Zones で一部をカバーしていますが、5G エッジの Wavelength に相当するサービスの成熟度は低く、3 つのユースケースを統一的な API と運用モデルでカバーする AWS のアプローチには及びません。 エッジコンピューティングの設計パターンを学ぶには関連書籍 (Amazon) も参考になります。
まとめ
AWS のエッジ戦略は、Outposts (オンプレミス拡張)、Local Zones (都市圏低レイテンシ)、Wavelength (5G エッジ) という 3 つの専門化されたサービスで構成されています。いずれも AWS のリージョンと同じ API、同じツール、同じ運用モデルで利用でき、ハイブリッド環境の複雑性を最小化する設計です。Azure Stack は顧客所有モデルであり API の完全互換性に課題があります。GCP の Distributed Cloud は市場実績が限定的です。エッジコンピューティングの需要が拡大する中、用途別に最適化された複数のエッジサービスを統一的に提供できる AWS のアプローチは、他社にない構造的な優位性です。