AWSハイブリッド&エッジVol1｜Outposts・LocalZones・Wavelength

1. ハイブリッド&エッジの本番課題と3サービスの全体像

AWSのシステム設計において、リソースをリージョンに配置するのが基本です。可用性・スケーラビリティ・マネージドサービスの豊富さを最大限に活かせる場所として、リージョンは最も合理的な選択肢です。しかし本番運用の要件が複雑になると、「リージョンだけでは満たせない制約」に直面する場面が生まれます。

主な本番課題は3つです。

超低遅延要件: ゲーム・AR/VR・5Gモバイルアプリ・工場の制御システムのように、エンドユーザーや機器から物理的に近いコンピュートが必要な場合、リージョンまでのネットワーク往復遅延がボトルネックになります。物理的な距離は光の速度で制限されており、リージョンが数百キロメートル離れていれば、ネットワークをどれだけ最適化しても数十ミリ秒の壁は超えられません。マイクロ秒〜数ミリ秒レベルの応答時間が必要なワークロードでは、コンピュートを物理的にユーザーや機器の近傍に置く必要があります。

データレジデンシー要件: 法規制・業界規制・顧客契約により、データを特定の建物・都市・国内に物理的に留める義務がある場合、AWSリージョンにおける論理的な分離だけでは要件を満たせないことがあります。金融・医療・行政分野や、欧州GDPRおよび各国のデータ主権法が代表例です。「データを自社ビル内の物理ハードウェアで処理する」「データを国内のAWS施設のみで処理する」といった要件は、通常のリージョン構成では対応できない場合があります。

オンプレミス近接処理要件: 既存のオンプレデータセンターに大量のデータや制御システムが残っており、それらをクラウドへ移動させずにAWSサービスと近接させて処理したいケースです。データをリージョンへ転送するコスト・遅延・帯域を避けながら、AWSのマネージドサービスを活用したい需要がこれに当たります。製造業の工場内処理・医療機関のオンプレ電子カルテ連携・金融機関の基幹系連携などが代表的な要件です。

AWSはこれらの本番課題に対して「AWSのインフラ自体を物理的にリージョン外へ拡張する」3つのサービスを提供しています。AWS Outposts・AWS Local Zones・AWS Wavelengthはいずれも、EC2やEBSなどのコンピュートリソース自体を顧客施設・都市内拠点・通信事業者設備へ配置します。接続サービス（Direct Connect・VPN）やコンテンツ配信（CloudFront・Lambda@Edge）とは異なり、「AWSのインフラそのもの」を物理的に移動させる点が本記事の対象です。

1-1. 本記事のゴール

このVol1では、要件（低遅延・データ所在・オンプレ近接）からAWS Outposts・Local Zones・Wavelengthのどれを選ぶべきかを判断できる状態をゴールとしています。各サービスの仕組みと設計上の勘所（§2〜§4）、ネットワーク・データレジデンシー設計（§5）、運用・コスト構造（§6）、選定フロー（§7）、つまずきポイント・アンチパターン（§8）の順で体系的に解説します。

接続構築（Direct Connect/VPN/TGW）やコンテンツ配信（CloudFront）の操作手順は既存記事へのリンクで補います。本記事では「どこに何を配置するか・なぜそのサービスを選ぶか・本番運用でどこに注意するか」の配置設計と運用判断に集中します。

これらの配置サービスはいずれも「設置しただけでは意味がない」という性質を持ちます。既存のネットワーク・コンピュート・可観測性の設計と組み合わせて初めて価値を発揮します。本記事を読んだうえで既存記事を参照するという使い方を推奨します。

1-2. 読者像

AWSのリージョン構成（EC2・EKS・S3・RDSなど）での開発・運用経験があり、新たに低遅延要件・データレジデンシー要件・オンプレミス統合要件に直面したアーキテクトやインフラ担当者を主な読者として想定しています。

Direct Connect・VPN・TGWによる接続構築の基本は理解済みであることを前提とし、接続設計の手順の詳細は既存のネットワーク本番運用シリーズを参照します。EC2・Auto Scaling・GravitonなどリージョンコンピュートのWell-Architectedな設計はすでに把握しているものとします。

本記事では、それらの経験を踏まえたうえで「物理的な配置拡張」という追加レイヤーに特有の設計判断と運用上の注意点に絞って解説します。コスト・コンプライアンス観点でこれらのサービスを評価するFinOpsやセキュリティ担当者が、要件の適合性を判断するうえでも参考になります。

1-3. 3サービスの使い分け概観

3サービスはいずれも「AWSインフラをリージョン外へ物理的に拡張する」共通の仕組みを持ちますが、物理配置先・主目的・対応サービス幅が大きく異なります。

距離感を軸に整理すれば、「自社建物＝Outposts」「近隣大都市のAWSメトロ施設＝Local Zones」「5Gキャリア設備＝Wavelength」が選定の出発点になります。対応サービス幅はOutposts racksが最も広く、Wavelengthは最も限定的です。設計時には「使いたいサービスがその配置先で提供されているか」を必ず確認する必要があります。

いずれのサービスも親リージョンと連携して動作します。コントロールプレーンはリージョン側で動作し、親リージョンとの接続（service link・Direct Connect等）が必要条件になります。親リージョン断時の縮退動作も設計時に考慮が必要です（§6）。

各サービスの詳細な仕組みは§2（Outposts）・§3（Local Zones）・§4（Wavelength）でそれぞれ解説します。選定フローは§7で整理します。複合要件（例: Outpostsを活用したオンプレ処理＋リージョン側のDR）への対応も§7でカバーします。

1-4. 既存ネットワーク記事との棲み分け

AWSのハイブリッド・エッジ領域は関連記事が多く、本記事の対象範囲を明確にします。

本記事が扱う範囲（物理配置拡張レイヤー）

AWSのコンピュート・ストレージリソース自体を顧客施設・都市内施設・通信事業者施設へ物理的に配置する設計です。「AWSのインフラをどこに置くか」という配置設計が中心です。

本記事が扱わない範囲（既存記事を参照）

• 接続構築: Direct Connect・VPN・Transit Gateway・PrivateLinkの設定手順 → 既存ネットワーク本番運用シリーズ参照
• コンテンツ配信: CloudFront・Lambda@EdgeによるCDNエッジ配信 → Edge/CDN本番運用 Vol1参照
• リージョン内コンピュート: EC2・Auto Scaling・Graviton・Spotの操作設計 → Compute本番運用 Vol1参照
• 可観測性手順: CloudWatch・X-Ray・VPC Flow Logsの詳細設定操作 → ネットワーク可観測性 Vol1参照

本記事ではこれらの操作手順は既存記事へのリンクで補います。「接続はできている・コンピュートは動いている、ではどこに何を配置すべきか・配置後に何を監視しコストをどう管理するか」の判断にフォーカスします。

既存のネットワーク本番運用シリーズ・Compute本番運用シリーズを読んだうえで本記事を参照すると、全体像がよりクリアになります。

1-5. 3サービス共通の設計前提と注意点

コントロールプレーンはリージョン側で動作する

3サービスに共通する重要な設計前提として、コントロールプレーンは親リージョン側で動作するという点があります。EC2インスタンスの起動・停止・設定変更・AMIの作成などの管理操作はすべて、リージョンのAPIエンドポイントを通じて実行されます。配置先から親リージョンへの接続が断絶した場合、新たな管理操作は実行できません。

この特性から、エッジ/ハイブリッド配置のシステム設計では以下の前提を持つことが重要です。

• 管理操作（インスタンス起動・停止・スケール変更）は親リージョンとの接続が必要です
• すでに動いているインスタンスのデータプレーン処理は接続断後も継続できる場合があります（特にOutposts）
• システムの「起動後に自律動作できる範囲」を事前に明確化し、縮退動作を設計します（§6-4）

提供状況の変動に対する備え

Outpostsの対応サービス・Local Zonesの提供都市・Wavelengthの対応キャリアは、AWSが定期的に拡張を発表しています。本記事に記載された情報は執筆時点のものであり、実際の設計・導入時点では最新の情報と異なる可能性があります。

特に以下の点は変動が速いため、導入前に必ずAWS公式ドキュメントで最新情報を確認してください。

• Local Zones提供メトロ都市リスト（継続的に拡張中）
• Wavelength対応通信事業者リスト（地域・キャリアともに拡張中）
• Outpostsで利用可能なサービスと対応リージョン（サービス追加が継続中）
• 各Zoneで提供されるインスタンスタイプ（最新世代の追加が継続中）

設計時の情報をそのまま本番運用に持ち込むのではなく、定期的なドキュメント確認を運用フローに組み込むことを推奨します。

3サービスを組み合わせた複合アーキテクチャの考え方

本番ワークロードでは、3サービスを排他的に選ぶのではなく、要件に応じて組み合わせるアプローチが有効です。たとえば、製造業のシステムでは工場フロアにOutpostsを配置しながら、都市の販売拠点向けにLocal Zonesを使い、フィールドサービス担当のモバイル端末向けにWavelengthを組み合わせるような構成も考えられます。各サービスの選定フローと複合パターンの詳細は§7で解説します。

3サービスそれぞれが解決するビジネス課題・技術課題を整理したうえで、最終的な配置設計の判断をすることが、本番運用での成功につながります。本記事がその判断材料として役立てば幸いです。

Outposts導入時の事前準備

Outpostsは他の2サービスと比較して導入に事前準備が必要です。設置場所の電源・空調・ラッキングスペースの確認、Direct Connectや専用インターネット回線の手配、AWSとの発注・設置スケジュール調整など、インフラとしての設置工程があります。設計着手から実際の利用開始まで数ヶ月かかることも多いため、計画段階での事前確認が不可欠です。

オンプレ接続の構築手順はこちら（Hybrid Connectivity Direct Connect/VPN/TGW）

2. AWS Outposts — オンプレミスにAWSを設置する

AWS Outpostsは、AWSのサーバー・ストレージ・ネットワーク機器をお客様のオンプレミスデータセンターや施設に設置するフルマネージドサービスです。クラウドと同じAWS APIやツール・コンソールを使いながら、データとアプリケーションをオンプレミスの物理環境で動作させることができます。主に2つのハードウェア形態が提供されており、要件に応じた選択が重要です。

2-1. Outposts racks — 42Uラックによる本格的なオンプレ統合

AWS Outposts racksは、AWSが設計・製造した42Uの物理ラックをお客様のデータセンターに設置する形態です。AWSが所有・管理するハードウェアであり、設置・保守・アップグレードはすべてAWSが担当します。racksは対応サービス幅が広く、本格的なオンプレクラウド統合を必要とする企業向けの選択肢です。

対応サービス（racks）

Outposts racksはAWSサービスを幅広くサポートしており、主に以下のサービスが利用できます。なお、対応サービスとインスタンスファミリーはラック構成・世代・親リージョンによって異なり、設計時には最新の公式ドキュメントを確認してください。

• Amazon EC2: M5/C5/R5/M5d/C5d/I3en/G4dn など複数インスタンスファミリーをサポート
• Amazon EBS: ローカルに接続されたEBSボリューム（gp2/gp3/io1/sc1/st1）
• Amazon ECS: コンテナオーケストレーション（EC2起動タイプ）
• Amazon EKS: Kubernetesクラスターのワーカーノードをオンプレに配置
• Amazon RDS: MySQL/PostgreSQL/SQL ServerのDBインスタンス（Multi-AZは構成による）
• Amazon ElastiCache: Redis/Memcachedクラスターのオンプレ配置
• Amazon EMR: Hadoopエコシステムのビッグデータ処理をオンプレで実行
• Application Load Balancer (ALB): HTTPSロードバランサーのオンプレ配置
• Amazon S3 on Outposts: S3 APIを使いながらデータをオンプレに留めるストレージ

RDS・ElastiCache・EMR・S3 on Outpostsはracksとserversで対応状況に差異があります。設計フェーズでは必ず最新情報を確認し、必要なサービスが特定のOutposts構成でサポートされているかを確かめてください。

電源・冷却要件（racks）

1ラックあたりの電源要件はラック構成に依存します。第2世代ラック（2nd gen）では10/15/30kVAの電源オプションが選択可能です。冷却についてはAWSのデータセンター設計基準に準じた適切な空調設備が必要であり、設置前にAWSとの詳細な事前確認（Prerequisites Review）を行います。

ネットワーク要件（racks）

racksのネットワーク構成には以下の2つの主要コンポーネントがあります。

• service link用アップリンク: 親リージョンへのservice link用に専用のアップリンクが必要です。Direct Connect（private VIF / public VIF）またはインターネット経由で接続します。本番環境ではDirect Connect private VIFによる専用線接続が推奨です
• Local Gateway (LGW): ラックとオンプレLAN間のルーティングを担うコンポーネントです。BGPを使用してオンプレルーターと経路交換し、Outposts上のインスタンスとオンプレホストが直接通信できます。racksに標準で提供される重要な機能です

設置フロー（概要）

Outposts racksの設置は以下のフローで進みます。

1. AWSとの事前要件確認（物理スペース・電源・冷却・ネットワーク要件の照合）
2. ハードウェアの発注と設置日程調整（リードタイムは数週間〜数ヶ月）
3. AWSエンジニアによる現地設置（ハードウェアの物理設置はAWSが実施）
4. AWS Management ConsoleからのOutposts作成とVPCサブネット設定
5. service linkの確立と親リージョンとの接続確認

2-2. Outposts servers — 小型フォームファクタ(1U/2U)でのエッジ展開

AWS Outposts serversは、より小型のフォームファクタで、EC2のコンピュートをOT・店舗・支社などの小規模拠点に持ち込む形態です。racksと比べてサービス対応範囲は限定されますが、スペース・電源の制約がある場所でも設置できることが強みです。

1Uモデル（Graviton2プロセッサ）

• AWSが独自設計したGraviton2（Arm Neoverse N1ベース）プロセッサを搭載した1Uサイズのサーバー
• 最大消費電力は約1〜2kVAで、既存の一般的な電源設備で対応可能
• 対応インスタンス: c6g/m6g などGraviton2ベースのインスタンスファミリー
• 軽量な業務アプリケーション・IoTデータ処理・店舗内リアルタイム処理に向く

2Uモデル（Intel Xeonプロセッサ）

• Intel Xeonスケーラブルプロセッサを搭載した2Uサイズのサーバー
• 最大消費電力は約1〜2kVAで、1Uと同様に一般的な設備で対応可能
• 対応インスタンス: c5/m5 などx86ベースのインスタンスファミリー
• x86ネイティブのレガシーアプリや高速ネットワーク処理に向く

serversの対応サービス（racksとの主な違い）

racksと比べると対応範囲は限定されますが、エッジ用途では十分な場合が多いです。

• Amazon EC2: 各モデルに対応したインスタンスタイプ
• Amazon ECS: EC2起動タイプのコンテナオーケストレーション
• AWS IoT Greengrass: エッジデバイスとのIoT連携（serversならではの活用法）

RDS・ElastiCache・EMR・S3 on Outpostsはracksでのみ提供されることが多いため、これらが必要な場合はracksを選択することになります。最新の対応状況は公式ドキュメントで確認してください。

ネットワーク要件（servers）

serversは1GbEまたは10GbEのイーサネット接続で親リージョンへservice linkを接続します。racksのような専用光ファイバーは不要で、既存の企業ネットワーク上に重ねることが多いです。Layer2接続でオンプレLANと統合するシンプルなアーキテクチャが特徴です。Local Gatewayはオプションとなっており、設計がシンプルになります。

設置の柔軟性（servers）

serversはracksと異なり、顧客または承認されたパートナーが設置できます。これにより、AWSの設置スケジュールに依存せず迅速な展開が可能です。設置手順はAWSの設置ガイドに従い、ネットワーク接続後にOutpostsとして登録します。

第2世代(2nd gen)の改善点

Outposts serversの第2世代モデルではパフォーマンス向上・省電力化・安定性改善が図られています。発注時には最新世代を選択することを推奨します。

2-3. service link構成 — 親リージョンとの制御パス

Outposts racksとserversに共通する重要な概念がservice linkです。Outpostsのコントロールプレーン（APIエンドポイント・モニタリング・ハードウェア管理）は親リージョン側に存在し、service linkを通じてOutpostsハードウェアと通信します。

service linkの接続オプション

• Direct Connect private VIF（推奨）: 専用線経由で低レイテンシ・高信頼性の接続。SLA要件が厳しい本番環境では標準選択。帯域保証が得られ、インターネット障害の影響を受けない
• Direct Connect public VIF: パブリックAWSエンドポイントへの接続。特定要件がある場合に使用する
• インターネット経由: 本番用途には非推奨。開発・テスト環境や費用制約のある場合に限定使用し、インターネット障害がservice linkに直接影響する点を考慮する

コントロールプレーンとデータプレーンの分離

• コントロールプレーン: 親リージョン側（EC2 API・EKS API・CloudWatch等）。service linkを経由してOutpostsを制御します
• データプレーン: Outposts上でローカル実行します。EC2インスタンス間通信やEBSアクセスはオンプレ内で完結し、service linkを通過しません
• 重要な動作: 既に稼働中のインスタンスはservice link断時もLocal Gateway経由でオンプレとの通信を継続できます

接続構成（Direct Connect・VPN・Transit Gateway）の詳細な設計・構築手順は既存のネットワーク記事で解説しています。

Outposts service linkに使うDirect Connect/VPNの構築手順はこちら（Hybrid Connectivity Vol1）

2-4. データレジデンシー担保 — データをオンプレから出さない設計

Outpostsの最大の強みは、データが物理的にお客様の建物内に留まることです。金融・医療・政府・製造など、データが国境や建物の外に出てはならない要件に対して、最も強力なコントロールを提供します。

データがオンプレに留まる設計パターン

• 処理データをOutposts EBSに保存: EBSボリュームはOutpostsのハードウェア上にのみデータを保存します。親リージョンのS3等には自動複製されません
• S3 on Outpostsの活用: S3 APIを使いながらデータをオンプレに保存します。リージョンのS3バケットとは別管理で、データがオンプレから出ません
• Local Gateway経由のオンプレ直接通信: Outpostsのインスタンスがオンプレのデータベース・ストレージとLocal Gateway経由で直接通信します。データがインターネット経由で出ません
• 暗号化: すべての保存データと通信はAWS KMSで暗号化します。CMK（カスタマーマネージドキー）をオンプレKMSや外部HSMと統合できます
• VPCサブネットの分離: Outpostsのサブネットのインターネット出口を明示的に制御し、必要な通信のみを許可するセキュリティグループ・NACLを設定します

Dedicated Local Zones（DLZ）との違い

Dedicated Local Zonesは政府・金融向けの専用インフラで、特定の国や組織向けにAWSリージョン施設内で運用されるオプションです。Outpostsとは異なりAWSのデータセンター施設内に設置されますが、物理的なテナント分離と主権要件に対応します。お客様の建物への設置が必要な場合はOutposts、AWSの専用施設で主権要件を満たしたい場合はDLZを検討してください。

2-5. 容量管理 — Outposts固有の運用上の注意

Outpostsの運用でリージョンと最も異なる点が容量管理です。リージョンでは弾力的にキャパシティを追加できますが、Outpostsはオンプレ設置済みのハードウェアが物理上限となります。

容量が枯渇するリスクと対策

• キャパシティの固定性: 設置ラック・サーバーに搭載されたコンピュート・ストレージが物理上限です。追加にはAWSへ発注し設置工事が必要となり、数週間〜数ヶ月のリードタイムが発生します
• 枯渇監視: CloudWatchメトリクスでOutpostsの残余キャパシティをモニタリングします。アラームを設定して枯渇前に対処することが重要です
• 予約インスタンス: Reserved InstancesをOutpostsキャパシティに適用することでコストを最適化しつつ確実なキャパシティを確保できます
• キャパシティリザベーション: EC2 On-Demand Capacity Reservationを活用し、重要なワークロード用のキャパシティを事前確保します

2-6. 主要ユースケース — どの業種・シナリオでOutpostsが選ばれるか

Outpostsが選ばれる典型的なシナリオを業種別に整理します。

製造・OT（オペレーショナルテクノロジー）

工場フロアでの製造機械の制御・センサデータのリアルタイム処理にOutpostsを活用するケースです。工場内のPLC（プログラマブルロジックコントローラ）や産業IoTデバイスとオンプレLAN経由で接続し、インターネット非依存でリアルタイム処理を実現します。クラウドへの接続遅延や障害でも工場ラインを止めないことが最優先要件です。

金融・規制業種

データが国内の自社管理施設から出てはならないという金融規制・データレジデンシー要件を満たすためのOutposts活用です。取引処理・リスク計算・顧客データの処理をオンプレ内のOutpostsで実行しつつ、AWSのマネージドサービス（EKS/RDS等）の運用効率を享受します。

医療・ヘルスケア

患者データをリージョンのパブリッククラウドに送れない医療規制（HIPAA等）への対応です。診断画像処理・電子カルテシステムをOutposts上で動作させ、AWSの機械学習サービス（SageMaker等）と連携する際はオンプレ内で完結するAPIのみを使うアーキテクチャが採用されます。

公共・政府

政府系情報システムのクラウド移行において、機密性の高い情報を自前の政府系データセンターから出さない要件に対応するOutposts活用です。AWSのGovernment Cloud（GovCloud）との組み合わせでハイブリッド主権設計が実現できます。

小売・店舗

全国に展開する店舗での在庫管理・POSシステム・顧客行動分析をOutposts servers（1U/2U）で分散配置するケースです。インターネット接続が不安定な店舗環境でもローカルで処理を継続し、接続回復時にクラウドと同期するアーキテクチャが採用されます。

2-7. Outpostsのマネジメントコンソール体験 — リージョンとの違い

Outpostsの管理はAWS Management Console・CLI・SDK経由で行います。リージョンとの操作上の違いを把握しておくことで、運用時の戸惑いを減らせます。

コンソールでのOutposts選択

EC2インスタンスをOutpostsに起動する際は、サブネット選択でOutpostsに紐付いたサブネットを選択します。Outpostsのサブネットは通常のAZサブネットと同じVPCに属しますが、「Outposts ARN」が紐付いているため、コンソール上でOutpostsサブネットとして識別できます。

EC2インスタンスの配置確認

起動済みEC2インスタンスの詳細画面でOutposts ARNが表示されることで、そのインスタンスがOutposts上で動作していることを確認できます。AWS CLIでも aws ec2 describe-instances --filters Name=outpost-arn,Values=<outpost-arn> でOutposts上のインスタンス一覧を取得できます。

Outpostsダッシュボード

コンソールの「Outposts」サービスダッシュボードでは、設置済みのOutposts一覧・各Outpostsの容量使用状況・service link状態・設置場所情報を確認できます。残余キャパシティの確認やアラート設定は、このダッシュボードとCloudWatchを組み合わせて行います。

3. AWS Local Zones — 大都市メトロへAWSを近接配置する

3-1. Local Zonesの概念と仕組み

AWS Local Zonesは、親リージョンの拡張インフラとして大都市近郊のメトロエリアに設置されるAWS管理のコンピュート・ストレージ施設です。独立したリージョンではなく、親リージョンのAZ（アベイラビリティーゾーン）として扱われます。これにより、AZを指定するだけで都市近傍のインフラを活用できます。

コントロールプレーンは親リージョン側で管理されますが、EC2インスタンスやEBSボリュームなどのデータプレーンは物理的にLocal Zone内に存在します。ユーザーにとってはVPCのサブネットをLocal Zoneへ拡張するだけで使い始められます。既存のVPC設計、セキュリティグループ、ルートテーブルをそのまま活用できる点がLocal Zonesの大きな特徴です。

ネットワーク構成の特徴として、Local Zonesは独自のローカルインターネット出口（Local Internet Breakout）を持ちます。Local Zoneに配置されたリソースからのインターネット向けトラフィックが、親リージョンのNAT GatewayやIGWを経由せず直接インターネットへ出るため、往復遅延をさらに削減できます。Direct Connect専用線の接続にも対応しており、企業網やオンプレミスからLocal Zoneへの低遅延な専用線アクセスも実現できます。接続の構築手順については既存のネットワークシリーズで詳しく解説していますので、そちらをご参照ください。

Direct Connect/VPN接続の構築手順はこちら（Hybrid Connectivity）

3-2. 提供都市・展開状況（公開時に最新情報を要確認）

★ Local Zonesの提供都市リストは拡張ペースが速く、本記事の公開後も継続的に変動します。実際の設計・導入時は必ずAWSの公式ドキュメントおよびマネジメントコンソールで最新の提供状況をご確認ください。

2025〜2026年時点では、北米を中心に世界30以上のメトロエリアへ展開が進んでいます。北米の主要Local Zone都市としてはAtlanta（ジョージア州）、Boston（マサチューセッツ州）、Chicago（イリノイ州）、Dallas（テキサス州）、Denver（コロラド州）、Houston（テキサス州）、Las Vegas（ネバダ州）、Los Angeles（カリフォルニア州）、Miami（フロリダ州）、New York（ニューヨーク州）、Philadelphia（ペンシルバニア州）、Phoenix（アリゾナ州）、Seattle（ワシントン州）などが挙げられます。

アジアパシフィックでは、Auckland（ニュージーランド）、Bangkok（タイ）、Delhi（インド）、Kolkata（インド）、Manila（フィリピン）などに展開が進んでいます。欧州ではHelsinki（フィンランド）、Warsaw（ポーランド）、Berlin（ドイツ）などにも展開されています。南米やアフリカでの展開も継続的に発表されており、グローバルなメトロカバレッジは着実に広がっています。

日本については、東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）が複数のAZを持つフルリージョンとして提供されています。現状、日本国内にLocal Zone都市は設置されていません。国内で低遅延要件を満たすには、通常は東京・大阪リージョンのいずれかのAZを活用します。日本企業が北米拠点でLocal Zonesを活用するシナリオなどでは、改めて提供状況を確認してください。

「Dedicated Local Zones」は、通常のLocal Zonesとは別に、特定の政府機関や厳格なデータ主権要件を持つ顧客向けに専用インフラとして提供される形態です。汎用的なLocal Zonesとは提供プロセスや契約が異なりますが、超高度なデータ主権要件（Sovereignty）に対応する選択肢として覚えておくと役立ちます。

3-3. 対応サービスの特徴（リージョンのサブセット）

Local Zonesで利用できるサービスは、親リージョンで提供される全サービスのサブセットです。主要なサービスとしては、Amazon EC2（各種インスタンスタイプ）、Amazon EBS（Elastic Block Store）、Amazon VPC、Elastic Load Balancing（Application Load Balancer / Network Load Balancer）、Amazon RDS（一部インスタンスタイプ・エンジン）、Amazon ECS、Amazon EKS、Amazon FSx for Lustre（一部Local Zone）などが提供されています。

Outposts racksと比較すると、Local Zonesが提供するサービス幅はより限定的です。Outposts racksではS3 on Outposts、ElastiCache、EMR、RDS、ALBなど広範なサービスをオンプレミス上で実行できますが、Local Zonesで利用できないサービスも少なくありません。アーキテクチャ設計の段階で「対象Local Zoneで必要なサービスが提供されているか」を確認することが不可欠です。

提供サービスはLocal Zoneごとに異なる場合があります。あるLocal ZoneではRDSが提供されていても、別のLocal Zoneでは未提供という状況も起こり得ます。サービス提供状況はAWSコンソールの「EC2 > Availability Zones」から確認できます。また、AWS CLIでaws ec2 describe-availability-zones --filters "Name=state,Values=available" を実行することでプログラマティックに確認できます。

このサブセット制約があるため、多くのアーキテクチャでは「レイテンシに敏感なフロントエンド層のみLocal Zoneに配置し、データベースやバッチ処理は親リージョンで実行する」という設計が一般的です。§7の実戦統合パターンで具体例を解説します。

3-4. 主要ユースケース

Local Zonesが本領を発揮するユースケースの共通点は「特定都市内のエンドユーザーやクライアントシステムに対して数ミリ秒単位の低遅延で応答する必要がある」という点です。

メディア編集・映像制作（Media & Entertainment）は代表的なユースケースです。映像編集ワークステーションやカラーグレーディングシステムでは、ストレージとコンピュートへのラウンドトリップ遅延が作業品質に直結します。Local Zonesを活用することで、撮影拠点近くの都市に仮想ワークステーション（EC2 GPU / Amazon WorkSpaces）を配置し、クリエイターが低遅延で作業できる環境を実現できます。ハリウッドではLos Angeles Local Zoneを活用した映像制作パイプラインの事例が複数報告されています。

仮想デスクトップ（VDI）も有効なユースケースです。リモートワーカーやコールセンターの仮想デスクトップ環境をLocal Zoneに配置することで、ユーザーの所在都市から低遅延でアクセスできます。Amazon WorkSpaces、Amazon AppStreamとの組み合わせで、従来オンプレミスのVDIで実現していた応答性をクラウドで提供できます。都市部の拠点を複数持つ企業において、各拠点ユーザーへのデスクトップ配信品質を一元管理しながら向上させる手段として有効です。

リアルタイムゲーム・eスポーツは、プレイヤーレイテンシがゲーム体験の品質を直接左右するユースケースです。ゲームサーバーをLocal Zoneに配置することで、特定メトロの大規模プレイヤーベースに対して低遅延サービスを提供できます。格闘ゲームやFPSなど反応速度が重要なタイトルや、eスポーツ大会のオンライン予選では特に有効です。複数都市のLocal Zoneに並列展開することで、各都市のプレイヤーに均一の低遅延体験を提供する構成も可能です。

金融取引・アルゴリズム取引では、注文処理や価格フィードの処理速度が収益に直結します。ニューヨーク、シカゴなど主要金融センターのLocal Zoneにシステムを配置することで、コロケーション施設に近いレイテンシをクラウドで実現できます。通信費用や物理機器の管理コストを削減しながら低遅延を維持できる点が、クラウドファーストを志向する金融機関に評価されています。

AR/VR・インタラクティブ体験もLocal Zonesの恩恵を受けやすいユースケースです。没入型コンテンツでは20〜30ms以上の遅延が酔いや違和感を生じさせるため、処理をLocal Zoneに近づけることが品質維持に不可欠です。クラウドレンダリングやストリーミング型XRアプリケーションでも同様の原則が適用されます。

3-5. Capacity Reservationと容量制約

Local Zonesはリージョンとは異なり、物理的にインフラ規模が限定されています。特定のLocal Zoneで需要が集中した場合、リージョンのような無制限なキャパシティ拡張は期待できません。本番環境では「InsufficientInstanceCapacity」エラーの発生リスクがあります。

本番ワークロードをLocal Zonesで運用する際は、On-Demand Capacity Reservations（ODCRs）を事前に確保することを強く推奨します。Capacity Reservationを確保しておくことで、需要が高い時間帯でも指定したインスタンスタイプの起動が保証されます。

Capacity Reservationの課金は、予約した瞬間からインスタンスの実際の使用有無にかかわらず発生します。本番の需要予測に基づいた適切な予約規模の設定が重要です。過剰な予約はコストの無駄につながり、不足するとキャパシティ不足のリスクが残ります。

Local Zoneごとに提供されているインスタンスタイプは異なります。最新世代のインスタンスタイプや特殊なアクセラレータ付きインスタンス（GPU、Inferentiaなど）が全てのLocal Zoneで展開されているわけではないため、設計時に対象Local Zoneで必要なインスタンスタイプが利用可能かを確認する必要があります。

容量制約の観点から、Local Zonesを使ったアーキテクチャではオートスケーリングの設計にも注意が必要です。Auto Scaling GroupのサブネットにLocal Zoneのみを指定すると、キャパシティ不足でスケールアウトが失敗します。親リージョンのAZサブネットとLocal ZoneサブネットをAuto Scaling Groupに混在させ、フォールバック先を用意するか、優先度付きで設定する設計が安全です。

3-6. VPC拡張設計パターン

Local ZonesはVPCの拡張として機能します。既存のVPCにLocal Zoneのサブネットを追加するだけで、同一VPCのリソースとして統合されます。セキュリティグループ、Network ACLs、ルートテーブルなどの既存設計を大きく変えることなく、Local Zoneリソースを組み込めます。

標準的な設計パターンは「レイテンシ敏感なフロントエンド層をLocal Zone・ステートフルなバックエンドを親リージョン」という分割構成です。たとえば、ゲームセッション処理やメディアエンコードのフロントエンドサーバーをLocal Zoneに配置し、ユーザーデータベースや課金システムは親リージョンで稼働させるという構成が典型的です。Local ZoneのEC2インスタンスと親リージョンのRDSが同一VPC内で通信する設計では、Local Zone→親リージョン間の帯域と遅延も設計要素として把握しておく必要があります。

「Availability Zone as Code（AZをコードで管理）」もLocal Zones活用の重要な視点です。AWS CloudFormationやTerraformでAZを動的に解決する実装パターンでは、aws_availability_zones データソースやAvailabilityZones組み込み関数を用いてデプロイ先を動的に決定できます。Local Zoneへの展開も環境変数やパラメータストアの値で切り替え可能にしておくことで、運用の一貫性を保ちながら本番・ステージング・Local Zone展開を統一したIaCコードで管理できます。

サブネット設計では、Local ZoneにもプライベートサブネットとパブリックサブネットをVPCの標準設計と同様に分けることを推奨します。ローカルインターネット出口をパブリックサブネット側のIGW経由で使用するか、親リージョンのNAT Gatewayを経由するかは、遅延要件とセキュリティポリシーのバランスで判断します。遅延を最優先する場合は、Local Zoneのローカルインターネット出口を活用します。

VPCの設計詳細や接続パターンについては、既存のネットワーク設計記事で体系的に解説しています。Local Zones固有のVPC拡張設定の詳細は§5でもまとめています。

3-7. Local Zonesのコスト構造

Local Zonesのコストはリージョンのコストと比較して割高になる傾向があります。主な理由は、Local Zoneのインフラ規模がリージョンより小さく、運用コストが規模の経済の恩恵を受けにくい点です。

EC2インスタンスコスト

同一インスタンスタイプで比較すると、Local Zoneはリージョンよりも時間単位の料金が高めに設定されています。コスト算出時は必ずAWSの料金ページで対象Local Zone固有の価格を確認してください。

データ転送コスト

Local ZoneとリージョンAZ間のデータ転送にはデータ転送料金が発生します。遅延敏感なフロントエンドをLocal Zoneに置き、バックエンドをリージョンに置く2層構成では、両者間の頻繁なデータ転送がコストに影響します。アーキテクチャ設計時にデータ転送量を試算しておくことを推奨します。

Capacity ReservationとSavings Plans

Local ZoneのCapacity Reservationには料金が発生します。また、Savings Plansの適用範囲とLocal Zoneの適合関係については最新の料金ドキュメントで確認が必要です。リージョンと同様にReserved Instancesを活用できる場合もありますが、Local Zone固有の制約事項を事前に確認してください。

コスト最適化の基本方針

Local Zones上で常時稼働させるリソースと、需要に応じてスケールするリソースを区別し、常時稼働のもの（Capacity Reservation済み）はSavings Plansや予約購入で割引を狙います。一方、スパイク対応のリソースはOn-Demandで調達し、必要な期間だけ起動する設計がコスト効率を高めます。

3-8. 監視・アラート設計のポイント

Local Zones上のリソースは、通常のリージョンAZ上のリソースと同じくCloudWatchでメトリクスを収集できます。ただし、Local Zones固有の注意点がいくつかあります。

CloudWatchメトリクスの取り回し

Local Zone内のEC2インスタンスのCloudWatchメトリクスは、親リージョンのCloudWatchエンドポイントへ送信されます。service link（Outpostsの場合）やVPC内のネットワーク接続を通じてメトリクスが転送されます。接続断時はメトリクスの収集遅延・欠落リスクがあります。本番では接続状態そのものをモニタリングするアラームを設定し、接続断を早期に検知できる体制を整えることが重要です。

Local Zone固有の監視項目

• 接続遅延: Local Zone→親リージョン間のラウンドトリップ遅延をCloudWatchカスタムメトリクスや合成モニタリング（CloudWatch Synthetics）で継続的に計測します。これにより、バックエンドRDS/S3呼び出しに影響するレイテンシの増大を事前に検知できます。
• Capacity Reservation使用率: 確保済みのCapacity Reservationに対するインスタンス起動数の比率を定期的に確認します。使用率が常時低い場合は予約規模を見直し、常時100%に近い場合は追加予約を検討します。
• インスタンス起動失敗: CloudTrailでRunInstancesのAPIコールをモニタリングし、InsufficientInstanceCapacityエラーをアラートで通知する設定を推奨します。
• ローカルインターネット出口の状態: ローカルインターネット出口経由のエグレスを使用している場合、出口帯域の使用状況とエラーレートを監視します。

可観測性の詳細な設計手法については既存の可観測性記事をご参照ください。ここでは配置特有の監視点に集中しています。

ネットワーク可観測性の詳細設計はこちら（ネットワーク可観測性 Vol1）

3-9. Local Zones活用の判断基準まとめ

Local Zonesを採用すべきかどうかの判断は、以下の3軸で評価することを推奨します。

軸1: レイテンシ要件

エンドユーザーへの応答遅延がアプリケーションの価値に直接影響するか確認します。リージョンのAZから対象都市への遅延を計測し（例: EC2へのping測定や合成モニタリング）、その遅延がアプリケーション要件（SLAやUXベンチマーク）を満たすかどうかを定量的に評価します。リージョンで十分なら、Local Zonesの追加コストと管理複雑性を避ける判断も合理的です。

軸2: データレジデンシー要件

データを特定のメトロエリアに留めることが規制や契約上求められているかを確認します。AWSのLocal Zonesは特定都市のAWS施設内にデータを留めることに対応しますが、自社建物内へのデータ所在要件がある場合はOutpostsを検討します。Dedicated Local Zonesは国家安全保障や政府機関向けの特殊なケースです。

軸3: 対応サービスの充足度

アーキテクチャに必要なAWSサービスが対象Local Zoneで提供されているかを確認します。サービス不足のまま設計を進めると、代替サービスや2層構成への設計変更が必要になります。対象Local Zoneのサービスカタログを事前に精査し、不足があれば「Local Zoneで動かすコンポーネント」と「リージョンで動かすコンポーネント」を明確に分割した設計を先行して完成させてから導入を進めます。

この3軸の評価が全て「採用を正当化する水準を満たす」場合に導入を進め、いずれかの軸でリスクが残る場合は小規模PoCで検証してから判断することを推奨します。Local Zonesは通常リージョンと比べてコストが高く、運用の複雑さも増します。要件がリージョンで十分に満たせるなら、シンプルなリージョン構成を維持する判断も正しい設計です。低遅延・データレジデンシー・サービス充足の3軸全てで明確なメリットがある場合に、Local Zonesは最大の価値を発揮します。

なお、Local Zonesの展開状況・提供サービス・料金は継続的に更新されています。定期的にAWSのWhat’s Newページやリリースノートを確認し、自社アーキテクチャの見直し機会を持つことを推奨します。特に対応サービスの追加（新サービスがLocal Zoneに展開された場合）は、それまで親リージョンに置いていたコンポーネントをLocal Zoneへ移す最適化の機会になります。アーキテクチャを固定して終わりにするのではなく、サービス展開状況の変化に合わせて定期的に見直すことが、Local Zonesを長期的に活用する上での重要な運用習慣です。

また、Local Zones上のリソース管理には、通常のリージョンと同じIaCコード・CI/CDパイプラインをそのまま適用できる場合が多くあります。Local ZoneのサブネットIDを変数化してTerraform moduleへ渡す設計にしておくと、複数都市のLocal Zoneへの展開をコードの修正なしに実行できます。このようなIaCの設計パターンは、Local Zonesを複数のメトロに展開するスケールアウト計画がある場合に特に重要です。展開先の都市が増えるほど、手作業オペレーションよりもIaC化のメリットが大きくなります。

Local Zonesの採用は、一度検討して終わりではなく、ユーザーの所在地変化・新規Local Zone追加・提供サービス拡充などの外部変化に合わせて継続的に評価し直すものです。初回導入後も四半期ごとに提供状況を確認し、アーキテクチャの最適化機会を逃さないようにすることが、クラウドネイティブな運用姿勢として重要です。

4. AWS Wavelength — 通信事業者の5Gエッジへ配置する

AWS Wavelengthは、通信事業者（Mobile Network Operator、MNO）の5Gコアネットワーク内データセンターへAWSのコンピューティング・ストレージリソースを配置するサービスです。モバイル端末からのトラフィックがリージョンへ折り返すことなく、通信事業者ネットワーク内で処理されるため、5G対応端末とアプリケーション間の往復遅延を大幅に短縮できます。

4-1. Wavelengthの概念と5G MECの位置付け

クラウドサービスはAWSリージョンのデータセンターにインフラを置き、インターネット経由でユーザーに提供するのが基本です。しかし5Gネットワークの登場により、通信事業者が自社のコアネットワーク内にエッジコンピューティング基盤（MEC：Multi-access Edge Computing）を設置できるようになりました。

AWS Wavelengthは、このMECの概念をAWSのサービスモデルと統合しています。通信事業者のMEC拠点（Wavelength Zone）にAWSのEC2インスタンスやEBSボリュームを配置することで、モバイル端末（UE：User Equipment）からアプリケーションまでの往復遅延を10ミリ秒未満に近づけることが目標とされています。

OutpostsがオンプレミスのデータセンターへのAWS配置、Local Zonesが大都市メトロへの近接配置であるのに対して、Wavelengthは通信事業者の5G網という独自のインフラ基盤にAWSを統合するアプローチです。インフラの「置き場所」が異なるため、設計上の考え方もほかの2サービスと大きく異なります。

4-2. アーキテクチャ — Wavelength ZoneとCarrier Gatewayの仕組み

Wavelengthのアーキテクチャは3つのコンポーネントで構成されます。

Wavelength Zone

Wavelength Zoneは、通信事業者のデータセンター内に設置されるAWS管理のインフラ区画です。親リージョン（例：ap-northeast-1）のAZとは別に、ap-northeast-1-wl1-nrt-wlz-1 のような識別子でVPCに拡張されます。Wavelength Zone内に起動したEC2インスタンスは、AWS Management ConsoleやCLIから通常のEC2と同様に管理できます。

Carrier Gateway

Carrier Gatewayは、Wavelength ZoneとMNOの5Gコアネットワークをつなぐゲートウェイコンポーネントです。インターネットゲートウェイ（IGW）のMNO版に相当するコンポーネントといえば分かりやすいです。UEからのトラフィックは「5G基地局 → MNOコアネットワーク → Carrier Gateway → Wavelength Zone内EC2」という経路をたどります。このパスはMNOのプライベートネットワーク内で完結するため、パブリックインターネットを経由しません。

親リージョンとの接続

Wavelength Zoneは親リージョンと内部的に接続されています。データ量が大きいバッチ処理やストレージ集約はリージョン側に配置し、レイテンシ敏感なリアルタイム処理のみをWavelength Zone側で実行する2層アーキテクチャが標準的な設計です。

4-3. Carrier IPとElastic IPの使い分け

Wavelength ZoneのEC2インスタンスには、通常のElastic IP（EIP）とは別にCarrier IPと呼ばれるIPアドレスが存在します。この2種類のIPを正しく理解することが、Wavelengthの設計においてとても重要です。

Carrier IP

MNOネットワーク経由でモバイル端末からアクセスされるIPアドレスです。各MNOが管理するIPレンジから割り当てられます。Carrier IPはインターネットからは直接到達できず、当該MNOの5Gネットワークからのみ到達可能な設計です。インスタンスにCarrier IPを割り当てることで、UEからのモバイルトラフィックをWavelength Zone内で終端できます。

Elastic IP（EIP）

Wavelength Zone内のEC2インスタンスに通常のEIPも付与できます。EIPはパブリックインターネット経由のアクセスや管理用途に使用します。ただし、Carrier IPとEIPの共存可否はMNO依存の実装詳細があるため、設計時は各MNOのドキュメントと合わせて確認が必要です。

設計判断のポイント

• モバイル端末からの低遅延アクセスが主目的 → Carrier IPを使用
• 管理用途や非5G端末からのアクセスも必要 → EIPを別途付与（セキュリティグループで制御）
• 両方必要な場合 → ロードバランサーを挟むか、用途別にインスタンスを分ける設計を検討することを推奨します

4-4. 対応キャリアと提供状況（2025-2026時点）

Wavelengthは特定のMNOと提携して提供されます。以下は2025-2026時点での主な提携キャリアです。ただし、対応キャリアおよびWavelength Zoneの提供状況は変動が速いため、導入前には必ずAWSの公式ドキュメント（「AWS Wavelength locations」ページ）で最新情報を確認してください。

北米

Verizon（米国）は最初期から提供を開始しており、ボストン・ダラス・ワシントンDC・シカゴ・サンフランシスコ・ニューヨーク・ロサンゼルスなどの主要都市でWavelength Zoneを展開しています。カナダではBell Canadaが提携キャリアとしてWavelength Zoneを提供しています。

欧州

Vodafoneは英国・ドイツ・スペイン等で展開しており、欧州主要都市への提供を推進しています。BT（英国）は英国内でWavelength Zoneを提供しています。

アジア

KDDI（日本）は国内でのWavelength Zone提供実績を持ち、東京・大阪エリアでの活用が進んでいます。SK Telecom（韓国）はソウル等の韓国主要都市で提供しています。提供キャリア・都市は変動するため、日本国内での利用可否は導入前に必ず最新の公式情報で確認してください。

その他・新興市場

2025年以降、北アフリカ（モロッコ等）や西アフリカ（セネガル等）への展開も発表されており、グローバルなカバレッジは継続して拡大中です。

4-5. 対応サービス — リージョンのサブセットとその特徴

Wavelength Zoneで利用できるAWSサービスはリージョンのサブセットです。設計段階で必要サービスが提供されているかを確認することが不可欠です。

コンピューティング

Amazon EC2は多くのインスタンスタイプが利用可能で、GPU系（G4dn等）もサポートしているためML推論ユースケースに対応できます。Amazon ECSによるコンテナワークロードの実行や、Amazon EKSによるKubernetesノードのWavelength Zone内サブネットへの配置も可能です。

ストレージ

Amazon EBS（Elastic Block Store）を使用したブロックストレージが利用できます。gp2/gp3/io1等の標準ボリュームタイプを用途に応じて選択できます。

ネットワーキング

AWS App Meshによるサービスメッシュ機能をWavelength Zone内のコンテナやEC2インスタンスに適用できます。Carrier Gatewayが前述のようにMNOネットワークとの接続を担います。

注意：Wavelength Zoneで利用できない主要サービス

RDS/Aurora・S3・Lambda・API Gatewayなどのマネージドサービスは、Wavelength Zoneでは直接利用できません。これらは親リージョンに配置し、Wavelength Zone内EC2からリージョン経由で呼び出す設計が必要です。対応サービスの詳細は導入前にAWSの最新ドキュメントで確認してください。

4-6. 主要ユースケース — 5G MECで何ができるか

Wavelengthが力を発揮するのは、モバイル端末から処理ポイントまでの往復遅延が10〜20ミリ秒以内でなければ体験が損なわれるアプリケーションです。

自動運転・コネクテッドカー

車両が周辺環境センサのデータをリアルタイムで送信し、クラウド側が危険検知・走行支援を即時に返すシナリオです。数百ミリ秒の遅延すら許容されないため、Wavelength Zoneがエッジ推論基盤として機能します。センサフュージョンや物体検知のML推論をWavelength Zone内のGPU搭載EC2で処理し、結果だけをリージョンのデータレイクへ非同期転送するパターンが典型的です。

ARとVR（拡張・仮想現実）

ARグラスやVRヘッドセットをモバイル回線と組み合わせると、映像レンダリングをクラウドにオフロードできます。クラウドレンダリングは端末の処理能力に依存しないため、軽量な端末でも高品質なAR/VR体験を提供できます。映像エンコードの往復遅延が20ミリ秒を超えると乗り物酔いに似た不快感が生じるため、Wavelength ZoneによるMEC配置が有効です。

スマート工場とIoT

工場フロアの製造機械や検査カメラが生成するセンサデータをリアルタイムで処理する用途です。有線ネットワークを敷設しにくいフロアで5Gを活用し、Wavelength Zoneで機械学習による異常検知・品質管理をエッジで実行します。生産ラインの停止を防ぐために遅延が厳しく制限される環境で、このアーキテクチャは大きな価値を発揮します。

ライブストリーミングとクラウドゲーミング

ライブ映像のトランスコードやゲームのサーバーサイド処理を5Gエッジで実行し、視聴者・プレイヤーへの配信遅延を最小化します。eスポーツや操作レスポンスが重要なクラウドゲーミングでは、このアーキテクチャによって体験品質を大幅に向上できます。

インタラクティブメディア

AR広告・ライブコマース・インタラクティブコンテンツのように視聴者がリアルタイムで操作・参加するメディア体験も対象です。5G高帯域×低遅延の組み合わせで、これまでローカル処理に頼っていたインタラクション処理をエッジクラウドに移せます。

4-7. 設計パターン — 超低遅延処理のみをWavelength Zoneへ

Wavelengthを導入する際の基本設計方針は「遅延に最も敏感な処理だけをWavelength Zoneに置き、残りは親リージョンに置く」です。理由は3点あります。

第一に、対応サービスがサブセットであるため、RDS・S3・Lambdaなどの主要サービスをWavelength Zoneで使えません。すべてをWavelength Zoneに移すことは実質不可能な設計制約です。

第二に、コスト面では、Wavelength ZoneのEC2は通常のリージョンEC2より割高になる傾向があります。遅延要件のない処理はリージョンに残す設計でコスト効率を高められます。

第三に、Wavelength Zoneはキャリアデータセンター内に限定されるため、リージョンのような弾力的なスケールアウトは期待できません。遅延要件のないバックエンド処理はリージョンの弾力性を活用します。

2層アーキテクチャの例（5G推論エッジ）

UE(5G端末) → Carrier Gateway → WZ内EC2(ML推論) → 親リージョン(非同期)

推論処理はWavelength Zone、学習・バッチ処理・永続ストレージはリージョンという分担です。WavelengthゾーンとリージョンをつなぐTGWやPrivateLinkの詳細な設定方法については、既存のネットワーク関連記事を参照してください。

WavelengthとリージョンをつなぐTGW・PrivateLinkの設計はこちら（ネットワーク本番運用 Vol2）

5. ネットワーキング&データ設計 — VPC拡張・Direct Connect・データレジデンシー

§5 では、Outposts・Local Zones・Wavelength の3サービスに共通するネットワーク設計とデータレジデンシー設計の考え方を整理します。接続構築（Direct Connect/VPN/TGW/PrivateLink）の手順詳細は既存のネットワーク記事に委ね、ここでは「配置先ごとにVPCをどう設計するか」「データをどこに留めるか」の設計判断軸に集中します。

5-1. VPC拡張設計 — 3サービスのサブネット配置モデル

3サービスはいずれも「既存のVPCにサブネットを追加して、物理的に遠い場所にあるインフラへ拡張する」という共通のモデルを採用しています。アカウントやVPCを新たに分割する必要はなく、既存のVPC設計の延長線上で導入できます。

Outposts のサブネット配置

Outposts racksの場合、オンプレミスのデータセンターに設置したOutpostsハードウェアは、親VPCのサブネットとして登録されます。Outpostsサブネットには outpost-arn 属性が付与されており、通常のAZサブネットと同じVPCに属しながらも、物理的にオンプレ建物内に存在します。EC2インスタンスを起動する際に「Outpostsサブネット」を選択するだけで、オンプレ上のハードウェアへ配置できます。

Outpostsサブネットの設計では以下の点を押さえてください。

• プライベートサブネットとして設計し、インターネット直接到達は原則遮断します
• Local Gateway（LGW）経由でオンプレLANと接続するサブネットと、service link専用のサブネットを分けて管理する構成が明快です
• VPCのCIDRブロックはオンプレの既存IPアドレス計画と重複しないよう注意が必要です

Local Zones のサブネット配置

Local Zonesは、親リージョンのVPCにAZの一種として追加されます。アカウントのマネジメントコンソールから対象のLocal Zoneを「有効化」した後、通常のAZと同様にVPCサブネットを作成するだけで利用できます。

Local Zonesサブネットのパターンには2種類あります。

• ローカルインターネット出口を使う構成: Local Zone内に独立したIGWまたはNAT Gatewayを配置し、インターネット向けトラフィックをLocal Zone内で終端します。親リージョンのNAT Gatewayを経由しないため、往復遅延を最小化できます
• 親リージョン経由を使う構成: Local ZoneサブネットのデフォルトルートをVPCのTGWまたは親リージョンのNAT Gatewayへ向けます。セキュリティポリシー上、インターネット出口を親リージョンで一元管理したい場合に選択します

Local Zonesのサブネット設計で注意すべき点は「Auto Scalingのサブネット設定」です。Local Zoneのみをサブネット対象にするとキャパシティ不足時にスケールアウト失敗が起きます。親リージョンのAZサブネットをフォールバック先として含める設計が安全です（§3-5参照）。

Wavelength Zones のサブネット配置

Wavelength ZoneもVPCの拡張として動作します。Wavelength Zoneを有効化すると、ap-northeast-1-wl1-nrt-wlz-1 のような識別子のAZとして見えるようになり、VPCサブネットを作成できます。Wavelength Zoneサブネットには通常のElastic IPとは別にCarrier IPが割り当てられます。

Carrier GatewayはMNOの5Gネットワーク側の出入り口として機能します。Wavelength Zoneサブネットのルートテーブルには、5G端末向けトラフィックのデフォルトルートをCarrier Gatewayへ向けます（設定手順は既存ネットワーク記事参照）。

3サービス共通のVPC設計注意点

いずれも「VPCの既存設計を崩さず、サブネットを追加拡張する」という思想です。セキュリティグループ・Network ACL・VPCフローログなどの既存設定はサブネット追加後もそのまま適用されます。

5-2. Local Gateway（LGW）詳説 — オンプレ直接ルーティングと縮退動作

Outposts racksの特徴的なコンポーネントが Local Gateway（LGW） です。LGWはOutpostsハードウェアに内蔵されており、オンプレミスのルーター・スイッチとBGPで接続することで、Outposts上のインスタンスとオンプレホストが直接通信できます。

LGWの役割

LGWは「Outposts上のVPCサブネット」と「オンプレLAN」をつなぐゲートウェイです。データパスとしては次の流れになります。

• Outposts EC2インスタンス → LGW → オンプレルーター → オンプレDB/ストレージ
• オンプレホスト → LGW → Outposts EC2インスタンス

この通信パスはインターネットもservice linkも経由しません。オンプレデータセンター内のプライベートネットワークで完結するため、低遅延かつデータが建物内に留まります。

LGWとservice linkの役割分担

Outpostsには2つのネットワーク出口があります。

設計上はこの2つを明確に分離します。オンプレ内の処理（DB読み書き・ローカルストレージアクセス）はLGW経由、クラウドサービス（CloudWatch・S3・SNS等）への呼び出しはservice link経由です。

service link断時のLGW動作

service linkが切断した場合でも、LGW経由のオンプレ通信は継続可能です。これがOutpostsの「縮退動作」の根拠になります。

• 継続できる処理: オンプレLAN内のDB・ストレージへのRead/Write、Outposts EC2とオンプレサーバー間の通信
• 停止する処理: 親リージョンAPIの呼び出し（CloudWatch・SSM・EC2 API・DynamoDB等）、新規インスタンス起動
• 不確実な処理: RDS on Outpostsは secure connectivity（ストレージレプリケーション用接続）が断絶するとインスタンス停止の可能性があります

この特性を活かすため、本番アーキテクチャでは「オンプレ内だけで完結できる処理」を必要最小限の形で設計し、service link断でも業務継続できるコアフローを確保することが重要です。

5-3. Direct Connect連携パターンの概観

3サービスとDirect Connect（DX）の連携パターンは、サービスごとに異なります。設定手順の詳細は既存のネットワーク接続記事に委ね、ここでは「どのサービスとDXがどう組み合わさるか」の概観を整理します。

Outposts とDirect Connect

Outposts racksのservice linkは、DX private VIF経由で親リージョンへ接続するのが本番推奨構成です。DX public VIFまたはインターネット経由も利用可能ですが、帯域保証とレイテンシ安定性の観点からprivate VIF専用線接続が望ましいです。

オンプレLANとの接続（LGW側）はDX経由ではなく、Outpostsハードウェアをラッキングしたデータセンターの内部ネットワークに直結します。DXはあくまでservice link（Outposts→親リージョン）のための接続であり、オンプレLAN接続はDXを必要としません。

Local Zones とDirect Connect

Local ZonesはDirect Connect接続に対応しています。企業ネットワークやオンプレミスからLocal Zoneへの低遅延な専用線接続を実現できます。DX Virtual Interfaceの設定で、Local ZoneのサブネットをBGP経路として受け取ることで、企業拠点からLocal Zoneへの直接接続が確立されます。

ただし、全てのLocal Zoneでの提供状況は変動することがあるため、対象Local ZoneでのDX接続可否を事前に確認してください。

Wavelength とDirect Connect

WavelengthはMNOの5Gネットワーク内に位置するため、接続の性質がOutpostsやLocal Zonesとは異なります。モバイル端末からのトラフィックはCarrier Gateway経由（MNOプライベートネットワーク）を通ります。企業向けの固定線（DX）からWavelength Zoneへのアクセスは、親リージョンVPC経由または別途のDX接続を検討してください。

接続構築の詳細な手順・設定方法は以下の記事をご参照ください。

Direct Connect / VPN / TGWの構築手順はこちら（Hybrid Connectivity Vol1）

TGW・PrivateLink・VPC Peeringの設計はこちら（ネットワーク本番運用 Vol2）

5-4. データレジデンシー設計 — fig05判断フローを軸に

fig05は「データレジデンシー要件と接続方式」から配置先（Outposts/Local Zones/Wavelength/リージョン）を選ぶ判断フローを示しています。ここでは、そのフローを構成する設計判断の根拠を解説します。

判断軸①: データを物理的にどこに留めるか

最初の分岐は「データが自社施設・特定建物の外に出てはいけない要件があるか」です。

• 建物内固定（オンプレ建物必須）: Outpostsを選択します。EBSボリューム・S3 on Outpostsのデータは物理的にOutpostsハードウェア（＝自社建物内）に存在します。処理結果がservice link経由で親リージョンへ送出されないよう、アプリケーションの設計でデータの流れを制御します
• 国内のAWS施設内に留める: Local Zones（または国内リージョン）を選択します。Local ZoneのEBSデータはAWS管理のLocal Zone施設内に存在します
• 通信事業者網内で処理し外部リージョンへ出さない: Wavelengthを選択します。ただし完全なデータ所在制御はOutpostsより限定的です
• 上記要件がない: 通常のリージョンで要件を満たします

データ主権要件別の配置先マッピング

規制・法域ごとの要件と推奨配置先を整理します。

Outpostsでデータを建物内に留める設計パターン

Outpostsを活用してデータレジデンシーを担保する場合、以下の設計パターンが有効です。

1. 処理データはOutposts EBSに保存: EBSはOutpostsハードウェア上のみに存在し、親リージョンのS3等へ自動複製されません。アプリケーションが生成するデータを意図的にリージョンへ送出しない設計が必要です
2. S3 on Outpostsを活用: S3 APIを使いながらデータをオンプレに留めます。リージョンのS3バケットとは別管理であり、データがオンプレ外へ出ません
3. LGW経由でオンプレDBを直接参照: Outposts EC2がLGW経由でオンプレのDBに読み書きするパターンです。データはオンプレ内を流れるのみで、インターネットを通過しません
4. 暗号化の徹底: 保存データはAWS KMS（カスタマーマネージドキー推奨）で暗号化します。CMKをオンプレのHSMやKMSと統合することで、鍵管理もオンプレ内に閉じることができます

Dedicated Local Zones（DLZ）の位置付け

Dedicated Local Zonesは、政府機関・金融機関・厳格なデータ主権要件を持つ企業向けに、AWSのデータセンター施設内で専用インフラを提供する選択肢です。汎用Local Zonesと異なり、物理テナント分離と高い主権要件への対応が設計思想に含まれています。自社建物への設置が不要な場合でもデータ主権要件を満たしたいケースで検討してください。

5-5. VPC Endpoint / PrivateLink のエッジ適用

Outposts・Local Zones・Wavelength Zoneに配置されたインスタンスから、AWSのマネージドサービス（S3・SQS・KMS等）へアクセスする場合、VPC Endpoint（PrivateLink）を活用することでトラフィックをAWSバックボーン内に留められます。

エッジ配置でのVPC Endpoint適用の考え方

• OutpostsのインスタンスからリージョンのS3やSQSへアクセスする場合、service link経由でリージョンAPIに到達します。VPC Interface Endpointをリージョン側に配置し、Outpostsサブネットからのアクセスをプライベートアドレスで解決することで、インターネット経由を回避できます
• Local Zones・Wavelength Zoneのインスタンスも、親リージョンのVPC Endpointを参照できます。これによりインターネットを経由せずAWSサービスに接続でき、セキュリティポリシーを満たしやすくなります

設計上の制約点

• Outpostsサブネット内への直接VPC Gateway Endpoint作成は不可です（S3のGateway Endpointはリージョン側に配置します）
• Interface EndpointはOutpostsサブネット自体には設置できず、リージョンのAZサブネットへ配置し、Outpostsからservice link経由で参照します
• 設定手順の詳細は既存のネットワーク記事（PrivateLink/VPC Endpoint）を参照してください

5-6. セキュリティグループとNACLのエッジ拡張における考慮点

Outposts・Local Zones・Wavelength Zoneのサブネットにも、通常のVPCと同様にセキュリティグループとNetwork ACL（NACL）を適用できます。ただし、エッジ配置特有の考慮点があります。

セキュリティグループの設計ポイント

セキュリティグループはステートフルであり、許可したインバウンドに対するアウトバウンドは自動的に許可されます。エッジ配置での設計上の注意点は以下の通りです。

• Outpostsの場合: オンプレLANからLGW経由でアクセスするホストのCIDRレンジをインバウンドルールに明示します。オンプレのIPアドレス計画と整合させることが重要です。service link接続元（リージョン側）のアクセスも適切に制御します
• Local Zonesの場合: ローカルインターネット出口経由でのインターネットアクセスを許可する場合、パブリックサブネット側のセキュリティグループを適切に制限します。Local ZoneとリージョンAZのリソース間の通信ルールも明示的に定義します
• Wavelengthの場合: Carrier GatewayからのCarrier IP宛てトラフィックを受け取るインバウンドルールが必要です。キャリアIPの帯域（CIDR）はMNOごとに異なるため、適用前にキャリアのドキュメントで確認します

NACLの設計ポイント

NACLはステートレスであり、インバウンドとアウトバウンドを別々に定義する必要があります。エッジ配置では以下の点を考慮してください。

• Outpostsサブネット向けNACLに、LGW経由のオンプレCIDRからのトラフィックを明示的に許可するルールを追加します
• エフェメラルポート（通常49152-65535）の戻り通信を許可するルールが抜けると、TCPセッションを確立できず通信障害となります
• Local Zone・Wavelength ZoneのサブネットNACLは、対応するリージョンAZのNACLと同一ポリシーを適用することで運用の一貫性を保てます

エッジ配置でのセキュリティ設計まとめ

セキュリティ設計はエッジ固有の接続経路（LGW・Carrier Gateway）を把握したうえで、既存のVPCセキュリティポリシーを拡張する形で構成することを推奨します。

Direct Connect / PrivateLink / TGWの構築はこちら（ネットワーク本番運用 Vol2）

6. 運用・監視・コスト — 容量管理とコスト構造

リージョン外への物理配置拡張は、リージョンとは異なる運用設計が必要です。リージョンでは需要に応じて動的にスケールアウト・インできますが、Outposts・Local Zones・Wavelengthはいずれも物理的な容量上限を持ちます。容量管理・監視・コスト構造という3つの観点から、エッジ/ハイブリッド配置に固有の運用上の勘所を整理します。

6-1. 容量管理 — リージョン弾力性のない配置先での設計

リージョンとの最大の違い: 容量の弾力性がない

AWSリージョンではAuto Scalingが需要増加に応じて自動でインスタンスを追加しますが、Outposts・Local Zones・Wavelengthは物理設備の容量が上限です。それを超えたリソースの追加は即座にはできません。

Outposts の容量設計

Outpostsで設置したracks・serversは固定容量です。同じハードウェア上でEC2・EBS・RDS・ElastiCacheなどが容量を共有するため、長期的な容量計画が必要です。

容量設計のポイントは以下の通りです。

• 現在のワークロード使用率と将来の成長率を見込んだサイジングを初期段階で行います。リージョンのように「後から容量追加」が容易ではないため、設計時に余裕を持たせることが重要です
• EC2インスタンスの最大同時起動数・EBSボリュームの合計容量・メモリ使用量の上限をCloudWatchで継続的に監視します。使用率が閾値（例: 80%）に達したらアラートを上げる設計にします
• 追加のracks・serversを発注してから設置完了まで数週間〜数ヶ月のリードタイムがあります。アラートから発注・設置完了までの期間を見越した閾値と監視設計が必要です
• 季節変動・キャンペーン需要などの予測可能なピーク時には、事前のキャパシティ計画と必要なら追加発注の検討が必要です

Local Zones / Wavelength の容量

Local ZonesとWavelengthはAWSが管理する施設であり、AWSが段階的にキャパシティを拡張します。ただし利用可能なインスタンスタイプの種類がリージョンより限定的であり、一部のインスタンスタイプは特定のZoneで提供されていない場合があります。

• 使いたいインスタンスタイプが希望のZoneで提供されているか、事前に最新のAWSドキュメントを確認します
• 容量不足でインスタンス起動が失敗する場合は、複数のZoneへのスプレッドや親リージョンへのフォールバックを設計します

容量枯渇の監視と閾値設定

CloudWatchのOutpostsカスタムメトリクスでキャパシティ使用率を監視します。使用率80%到達で警告、90%到達で緊急アラートを発するような2段階の閾値を設定し、発注・設置のリードタイムを考慮した余裕期間を確保します。容量監視の詳細な設定手順は既存の可観測性記事を参照してください。

6-2. 監視 — CloudWatchとservice link断時の挙動

Outpostsの監視ポイント

Outposts上のリソースはCloudWatchに標準メトリクスを送信します。リージョンのEC2監視と同様の設定が基本ですが、Outposts固有の監視ポイントが追加されます。

最も重要なのはservice link（Outposts〜親リージョン間の接続）の状態監視です。

• service link正常時: コントロールプレーン操作（インスタンス起動・停止・設定変更）が正常に機能します。CloudWatchメトリクスはservice link経由でリアルタイムに親リージョンへ送信されます
• service link断時: コントロールプレーン操作は停止しますが、すでに起動済みのEC2インスタンスはデータプレーン処理（アプリケーションの実行・ネットワーク通信）を継続できます。「動いているものは動き続ける」という縮退動作になります
• heartbeat監視: AWSがservice linkのheartbeatを自動監視しており、断が検知されるとAWSサポートへ通知されます。自社の監視としても、service linkの疎通確認アラームを設定することを推奨します
• メトリクス送信遅延: service link帯域が逼迫するとメトリクスの送信遅延が発生します。Outpostsから親リージョンへのメトリクス・ログのトラフィック量がservice link帯域内に収まるよう設計します

Local Zones / Wavelength の監視

Local ZonesとWavelengthにはOutpostsのようなservice linkの概念はなく、AWSが管理する接続を通じて親リージョンと通信します。監視の中心はワークロードの遅延とヘルス状態です。

• ターゲットグループのヘルスチェックをLocal Zones・Wavelength Zoneのターゲットに設定します
• エンドユーザーから計測した実際の遅延をCloudWatchカスタムメトリクスに記録し、サービスレベル目標に対する達成状況を監視します
• CloudWatch Syntheticsでエッジ配置エンドポイントへの定期的な外形監視を設定します

可観測性ツールの詳細な設定操作は既存の可観測性記事を参照してください。

可観測性の詳細設計はこちら（ネットワーク可観測性 Vol1）

ログ収集の設計

Outposts上のEC2インスタンスからCloudWatch Logsへの送信はservice link経由となります。service link帯域を圧迫しないよう、ログの送信頻度・フィルタリング・バッファリング設定を最適化します。Local Zones・Wavelengthからのログ送信は通常の親リージョンへのルーティングを経由します。

6-3. コスト構造 — キャパシティ課金と使用量課金の違い

AWS Outposts のコスト構造（キャパシティ課金）

AWSリージョンは「使った分だけ課金」する使用量課金が基本ですが、Outpostsは「キャパシティ課金」モデルを採用しています。

• Outposts racks: 1年または3年の「Outpost料金」を前払いまたは月払いで支払います。この料金にはハードウェア設置・維持管理・リージョンへのservice link接続コストが含まれます
• Outposts servers: 1U/2Uサーバー単位で同様のキャパシティ課金となります。racksより低コストですが対応サービスが限定されます
• 遊休リソース＝即コスト: リージョンではインスタンスを停止すれば課金が止まりますが、Outpostsではキャパシティ確保分のコストは常に発生します。使っていない容量もコストになるため、ワークロードを密集させてキャパシティ使用率を高める設計が重要です
• サービス追加料金: Outposts上でS3・RDS・ElastiCacheなどのマネージドサービスを動かす場合、サービスごとの追加料金が発生します

AWS Local Zones のコスト構造

• EC2インスタンスは時間課金ですが、同スペックでもリージョンより料金が高くなります
• Local Zones〜親リージョン間のデータ転送料金が別途発生します。データ転送量が増えるとコストが積み上がります
• 遅延要件がある処理のみLocal Zonesに置き、バックエンド処理は親リージョンで実行することで、Local Zonesのコストを最小化します

AWS Wavelength のコスト構造

• Wavelength Zoneのインスタンス料金はリージョンより高くなります
• Carrier Gateway経由のデータ転送料金が追加で発生します
• 5Gモバイル端末への超低遅延が必要な処理のみWavelengthで処理し、その他は親リージョンで実行するアーキテクチャがコスト最適です

コスト最適化の整理

コスト管理にはAWS Cost ExplorerでZone・サービスごとのコストを分析します。Outpostsのキャパシティ使用率を定期的にレビューし、過剰なキャパシティを確保していないかを確認します。

★ 公開時確認事項: Local Zonesの提供メトロ都市一覧・Wavelengthの対応通信事業者一覧は変動が速いため、本記事公開時にAWS公式ドキュメントの最新情報を確認してください。

6-4. 障害時の縮退動作設計

エッジ/ハイブリッド配置では、親リージョンとの接続が断絶した場合の縮退動作を事前に設計することが重要です。

Outposts: service link断時の縮退動作

service linkが切断された場合、以下の動作変化が発生します。

• 起動済みのEC2インスタンスはデータプレーン処理（アプリケーション実行・ネットワーク通信）を継続します
• コントロールプレーン操作（インスタンス新規起動・停止・AMI取得・設定変更）は停止します
• CloudWatchへのメトリクス・ログ送信は停滞する可能性があります
• RDS on Outpostsはsecure connectivity（storage replication用接続）が断絶するとインスタンスが停止します

縮退動作設計のポイントは以下の通りです。

• 「service link断でも継続すべき処理」と「断したら停止してよい処理」を明確に定義します
• 最小動作モードとして「起動済みインスタンスで動き続けられる機能の範囲」を把握します
• service link回復後の再接続・コントロールプレーン状態同期の手順を事前にドキュメント化し、定期的にテストします

Local Zones / Wavelength: 親リージョン接続障害時

Local ZonesとWavelengthは親リージョンへの接続を前提とした構成です。接続障害時のフォールバック設計として以下を検討します。

• 親リージョンとのアクティブ-アクティブ構成で、Local Zones/Wavelengthが利用不可となった場合、親リージョンへ自動フォールバックします
• ALB/Route 53のヘルスチェックを活用して、Local Zones/Wavelengthゾーンが異常となった場合、親リージョンへトラフィックを切り替えます
• 「エッジが落ちたらリージョンへフォールバックする」か「エッジが落ちたらサービス停止を許容する」かを要件に基づいて事前に決定します

縮退設計はシステムの可用性要件に応じて判断しますが、「エッジ配置だけに依存しない」設計の原則を持っておくことが本番運用では重要です。

6-5. 運用チェックリスト — エッジ/ハイブリッド配置の定期確認事項

本番運用を安定させるために、以下のチェックリストを定期的に確認することを推奨します。

月次確認事項

• Outpostsのキャパシティ使用率（EC2・EBS・メモリ）が警告閾値（80%）を超えていないか
• service linkのheartbeatアラームが正常状態にあるか
• Local Zones・Wavelength Zoneへのデータ転送コストが予算範囲内に収まっているか
• Outpostsのキャパシティ課金コストとワークロード密度のバランスが最適か

四半期確認事項

• Outpostsの対応サービスリストに追加があり、活用できるサービスが増えていないか
• Local Zonesで新しい提供都市や対応インスタンスタイプが追加されていないか
• Wavelengthで新しいキャリアやZoneが追加されていないか
• 縮退動作の手順書が現在の構成に合致しているか（手順書の定期レビュー）
• service link断シナリオの模擬訓練・フォールバック動作の確認

年次または構成変更時の確認事項

• 現在のキャパシティが今後1〜2年の成長率を考慮した容量計画に合致しているか
• Outpostsのracks・serversの追加発注が必要か（リードタイムを考慮）
• Local Zones・WavelengthゾーンのCapacity Reservationの期限と見直し
• コスト構造の変更（料金改定・Savings Plansの有効期限）への対応

7. 実戦統合パターン — 3サービス選定と既存記事との連携

7-1. fig06選定フローの詳細解説

fig06の選定フローチャートは、4つの判断軸で3サービスとリージョンを選び分けるプロセスを示しています。ここではそのフローを言語で補足します。

最初の問い「データを自社施設・建物内に物理的に留める必要があるか？」

この問いに「はい」と答えるケースは、データレジデンシー規制によりデータが自社所有の物理設備から出ることを禁止されている場合、またはオンプレミス機器と処理ポイントを物理的に近接させる必要がある場合です。この場合の答えはAWS Outpostsです。OutpostsはオンプレミスのデータセンターにAWSハードウェアを設置するため、データが自社建物内に留まります。

「いいえ」の場合の第2の問い「大都市内のエンドユーザー向けに数ミリ秒の低遅延が必要で、かつリージョン拠点では遅延が足りないか？」

この問いに「はい」の場合はAWS Local Zonesが候補です。ユーザーが集積する都市のLocal Zoneにコンピューティングを配置することで、リージョンへの往復を省いた低遅延を実現できます。メトロエリアのデータレジデンシー要件（国ではなく都市単位でのデータ所在制約）にも対応できます。

「いいえ」の場合の第3の問い「5Gモバイル端末からの超低遅延（10ms以下）が必要か？」

この問いに「はい」の場合はAWS Wavelengthです。通信事業者の5Gネットワーク内でトラフィックを処理するため、モバイル端末から処理点までの遅延を最小化できます。コネクテッドカー、AR/VR、スマート工場のような超低遅延モバイルユースケースが対象です。

いずれの問いも「いいえ」の場合 → 通常リージョン

特定の物理配置要件がなければ、既存のリージョンアーキテクチャで要件を満たします。既存のCompute・ネットワーク・CDN記事を参照してください。

7-2. 実戦複合パターン

単一サービスだけでなく、複数サービスを組み合わせることで要件を満たすアーキテクチャが実際の導入では多くあります。代表的な3パターンを解説します。

パターンa) Outposts + Local Zones — オンプレ本番 + メトロDR構成

本番システムを自社データセンターのOutpostsで運用し、メトロエリアのLocal ZoneをDR（ディザスタリカバリ）用として使う構成です。Outpostsで発生したデータはDirect Connectを経由して親リージョンへレプリケートされ、Local ZoneのDRサイトへもフェイルオーバー可能な状態を保ちます。

この構成のメリットは「通常時はデータを自社建物に留め（Outpostsによるデータレジデンシー）、障害時はメトロエリアのAWSインフラへ迅速に切り替える（Local ZonesのDR活用）」というリスク管理の柔軟性にあります。Outpostsとリージョン・Local Zonesの接続ではDirect Connectの帯域計画が重要になります。

パターンb) Wavelength + CloudFront Edge — モバイル超低遅延配信

5Gモバイル端末への配信をWavelength Zone内で処理し、静的コンテンツやグローバルユーザー向けの配信はCloudFront Edgeを使う構成です。動的コンテンツ（リアルタイム処理・ML推論）をWavelengthで処理し、静的アセット（画像・動画・JS）はCloudFrontのグローバルエッジキャッシュから配信します。

この構成では「5G端末ユーザー向けのインタラクティブ体験をWavelengthで最適化しつつ、非5Gユーザーや帯域の大きいコンテンツはCloudFrontで効率配信する」というハイブリッドエッジ戦略を実現できます。CDN設計の詳細については既存のEdge/CDN記事をご参照ください。

パターンc) マルチリージョン + Outposts — グローバル企業のデータレジデンシー対応

グローバル展開する企業において、国ごとのデータ主権規制に対応しながらグローバルサービスを提供するアーキテクチャです。各国のデータレジデンシー要件を持つ拠点にはOutpostsを設置し、規制のないグローバル処理は複数リージョンで提供します。

たとえば、欧州ではGDPRに対応するためドイツ法人のデータセンターにOutpostsを配置し、アジア太平洋のユーザー向けには東京・シンガポールリージョンを使い、北米ではバージニアリージョンとChicago Local Zoneを組み合わせるような構成です。AWS Organizationsとマルチアカウント設計を組み合わせることで、各Outposts・リージョン・Local Zoneをガバナンス下で統合管理できます。マルチアカウント設計については既存のガバナンス記事をご参照ください。

7-3. 既存記事との連携アーキテクチャ

本記事が扱う「物理配置レイヤー」は、既存記事が扱う「接続・配信・コンピュート・可観測性」の各レイヤーの上に成り立っています。

接続レイヤー（ネットワークシリーズ）

Outpostsのservice link、Local ZonesへのDirect Connect、WavelengthのTGW接続など、本記事の配置先とオンプレミスやリージョンをつなぐ接続構築手順は既存のネットワーク記事で詳説しています。

オンプレ接続（Direct Connect/VPN/TGW）の構築はこちら

TGW・PrivateLink・VPC Peeringの設計はこちら（ネットワーク本番運用 Vol2）

コンピュートレイヤー（Computeシリーズ）

Outposts・Local Zones・Wavelength Zone内で実際にEC2インスタンスやECSタスクを運用する場合のコンピュート設計（インスタンスタイプ選定・Auto Scaling・Graviton活用・Spot活用）は既存のCompute記事で解説しています。

EC2・Auto Scaling・Graviton・Spot設計はこちら（Compute本番運用 Vol1）

可観測性レイヤー（Observabilityシリーズ）

Outposts・Local Zones・Wavelength Zoneに配置されたリソースの監視はCloudWatchで実施します。CloudWatchへのメトリクス送信やログ収集はリージョンと同様のAPIで行えますが、service link断時の挙動やエッジ配置固有の監視点については§6で整理しています。監視設計の詳細手法は既存の可観測性記事をご参照ください。

ネットワーク可観測性設計はこちら（ネットワーク可観測性 Vol1）

ガバナンス・コストレイヤー

複数のOutpostsやLocal ZonesをマルチアカウントのAWS Organization配下で運用する場合、アカウント・OU設計やSCP（Service Control Policy）によるガバナンス、コスト配賦タグ戦略が重要になります。Outpostsのキャパシティ課金をコストエクスプローラーで可視化する場合もマルチアカウントのコスト管理記事が参考になります。

7-4. 導入判断チェックリスト

3サービスの導入を検討する際に確認すべき事項をまとめます。設計着手前にこのチェックリストを参照することで、後工程の手戻りを防ぐことができます。

Outposts導入前の確認事項

• [ ] データレジデンシー規制の範囲と対象データを特定したか（法務・コンプライアンスとの合意）
• [ ] 設置場所（自社データセンター）の電源・空調・ラッキングスペースを確認したか
• [ ] 必要なサービス（EC2/EKS/S3 on Outpostsなど）がOutposts racks/serversで提供されているか
• [ ] service linkの接続方式（Direct Connect推奨）とその帯域を計画したか
• [ ] 容量上限（物理ハードウェアの範囲）と容量計画サイクルを決めたか
• [ ] service link断時の縮退動作（ローカル継続範囲）を設計したか

Local Zones導入前の確認事項

• [ ] 対象の都市にLocal Zoneが存在するか（公式ドキュメントで最新確認）
• [ ] 必要なインスタンスタイプとサービスが対象Local Zoneで提供されているか
• [ ] Capacity Reservationを確保するか、またはキャパシティ不足時のフォールバックを設計したか
• [ ] VPCサブネットのLocal Zone拡張設計（プライベート・パブリック分離）を完了したか
• [ ] Local Zone→親リージョン間の遅延・帯域がバックエンド連携に問題ないか確認したか
• [ ] ローカルインターネット出口を使うか、親リージョン経由にするか（セキュリティポリシーと照合）

Wavelength導入前の確認事項

• [ ] 利用する通信事業者のネットワーク内にWavelength Zoneが存在するか（公式ドキュメントで最新確認）
• [ ] Carrier IPとEIPの設計を完了したか（用途別の使い分け）
• [ ] Wavelength Zoneで利用できないサービス（RDS/S3/Lambdaなど）を親リージョンに分離設計したか
• [ ] 2層アーキテクチャ（Wavelength Zone処理 + 親リージョンバックエンド）の連携設計を完了したか
• [ ] 本番前の検証環境（Wavelength Zone）でAMI・インスタンスタイプの動作を確認したか
• [ ] キャリア依存の仕様（Carrier IP動作・SLA）を当該キャリアのドキュメントで確認したか

7-5. 既存Computeシリーズ・ネットワークシリーズとの接続マップ

本記事の「物理配置レイヤー」は、既存記事が扱う各レイヤーを基盤として成り立っています。以下に各記事との接続関係を整理します。

この構造により、本記事は「どこへ配置するか」の設計判断に集中し、「どう運用するか」の手順詳細は各専門記事へ委ねています。記事間を参照しながら読むことで、Outposts・Local Zones・Wavelengthを使ったエンドツーエンドのアーキテクチャ設計を体系的に習得できます。

7-6. 選定の落とし穴と決断のタイミング

3サービスの選定で見落とされやすい落とし穴と、導入判断のタイミングについて補足します。

「低遅延が欲しい」だけでLocal Zonesを選ばない

遅延改善を目的にLocal Zonesを検討する際、まず「どのくらいの遅延改善が必要か」を定量化することが重要です。現状のリージョンからユーザーまでのレイテンシが20msであれば、Local Zonesで5msに改善されたとしても、アプリケーションのユーザー体験に実感できる差が生まれるかどうか検証する必要があります。Locust・JMeter等の負荷ツールやCloudWatch Syntheticsで現状の遅延を計測し、Local Zones導入のROIを明確にしてから判断します。

概念実証（PoC）の進め方

3サービスのいずれも、初めて導入する際は小規模なPoCから始めることを推奨します。PoCでは「最小限のVPCサブネット拡張 → EC2インスタンス1台 → レイテンシ計測 → サービス可用性確認」というシンプルな手順で、実環境での遅延改善効果とコストを検証できます。PoCで期待した改善が得られなかった場合は、アーキテクチャを見直してから本番展開に進みます。

マルチアカウント構成での管理

AWS Organizations配下で複数アカウントを管理している場合、Outposts・Local Zones・Wavelength Zoneのリソースは各アカウントのVPC拡張として管理されます。Service Control Policy（SCP）による操作制限やコスト配賦タグの一貫した適用、AWS Cost Explorer・AWS Budgetsによる配置先別のコスト可視化が、マルチアカウント環境での健全な運用を支えます。

リージョン内コンピュート設計はこちら（Compute本番運用 Vol1）

ネットワーク可観測性はこちら（ネットワーク可観測性 Vol1）

8. つまずきポイント・アンチパターン・まとめ

Outposts・Local Zones・Wavelengthの3サービスを本番利用する際に、実際の現場で発生するつまずきポイントとアンチパターンをまとめます。設計・構築・運用フェーズにわたる実例を整理します。

つまずきポイント一覧（概要）

8-1. 本番で発生するつまずきポイント

つまずき①: Outpostsの対応サービス・インスタンスタイプを未確認で設計を進める

本番設計時に「EC2/EKSが使えれば十分」と前提を置き、必要なインスタンスタイプやRDS等のサービスがOutpostsの特定ラック構成で提供されていないことを後から発見するケースです。AWSのOutposts対応サービスリストは、ラック容量・世代・Outpostsが設置される親リージョンによって異なります。特にRDSのMulti-AZ構成やEMR、S3 on Outpostsは要件に含まれる場合、個別に対応可否を確認することが必須です。

対処: 設計フェーズ初期に必要サービスとインスタンスファミリーのリストを作成し、AWSの最新ドキュメント（Outposts対応サービスリスト）と照合します。Outpostsのセールスチームへの事前確認も有効です。

つまずき②: 容量上限を見落とし、スケールアウト不能に陥る

リージョンと同じ感覚でAuto Scalingを設定したところ、Outpostsの物理キャパシティが限界に達し、スケールアウト失敗（InsufficientCapacityException）となるケースです。CloudWatchアラームを設定していなかったため、枯渇の検知が遅れます。

対処: §2-5に記載のキャパシティ計画を徹底し、CloudWatchで残余キャパシティを監視します。Auto Scalingの最大インスタンス数をOutpostsの実際のキャパシティ上限以下に設定することが重要です。

つまずき③: service link断を想定せずに縮退設計を省略する

Direct Connect回線メンテナンス等でservice link断絶が発生した際、Outposts上で稼働中のアプリの「AWS APIを呼ぶ処理」（例: DynamoDB書き込み・SNS通知・SSMセッション）が失敗し始め、オンプレ業務に影響が出るケースです。service link断の発生頻度は低いものの、定期メンテナンスや障害時に起きます。

対処: アーキテクチャレビュー時に「service link断でもオンプレ業務を継続できるか」を必ず確認します。AWS外部依存（親リージョンのAPI呼び出し）を最小化した設計か、キューイング（SQS + ローカルキャッシュ）による非同期化を採用することを推奨します。

つまずき④: Local ZonesとAZの対応サービスサブセットを誤認する

Local Zonesは親リージョンのAZ（アベイラビリティーゾーン）と同じVPC上に展開できますが、提供されるサービスはリージョンのサブセットです。特定のRDSエンジン、特定のEC2インスタンスファミリー、ElastiCacheなどが提供されていないLocal Zoneが存在します。「リージョンで使えるからLocal Zonesでも使える」という誤認が設計後半のやり直しを招きます。

対処: 対象のLocal Zone名を明確にした上で、AWSドキュメントのLocal Zones対応サービスリストを確認します。リリース時期によって対応サービスが拡張されているため、常に最新情報を参照してください。

つまずき⑤: Local ZonesでCapacityErrorが発生してインスタンス起動できない

Local Zonesは都市インフラ上に設置された限られたキャパシティです。特定のインスタンスファミリーが当該Local Zoneで提供されていても、実際のキャパシティが枯渇してInsufficientCapacityErrorとなるケースがあります。これはGPUインスタンス（g4dn等）や大型インスタンスで発生しやすいです。

対処: On-Demand Capacity Reservation（ODCR）で事前のキャパシティ予約をするか、複数のインスタンスタイプをフォールバック候補とする設計にします。

つまずき⑥: Wavelengthの端末IPルーティングを誤設計する

Wavelength ZoneのEC2インスタンスはCarrier IPアドレスを持ちます。このCarrier IPは通信事業者の5Gネットワーク内でのみ直接ルーティング可能であり、インターネットやリージョンVPC側からはElastic IP経由のルーティングが必要です。Carrier IPを直接インターネットから到達可能と思い込んでいると、設計が機能しません。

対処: Wavelength Zoneインスタンスへのアクセスパスを「5G端末 → Carrier Gateway → Carrier IP」と「インターネット/VPC → Elastic IP → インスタンス」の2ルートに分けて設計します。

つまずき⑦: Wavelengthキャリアの提供状況を古い情報のまま計画する

Wavelengthゾーンは通信事業者との提携により、新規ゾーンの追加・撤退・提供エリアの変更が比較的頻繁に起きます。2024-2025年の情報を元に設計を進めたが、実際の提供ゾーンが変わっていた、というケースは現場で実際に起きています。

対処: 設計フェーズ・調達フェーズそれぞれで最新のWavelength Zones一覧をAWSドキュメントから確認します。特定キャリア（日本ではKDDI）との提携ゾーンについては、AWS担当者への事前確認を必ず行ってください。

つまずきポイント共通のまとめ

7件のつまずきポイントを振り返ると、以下の共通パターンが見えます。

• 情報の鮮度リスク: Outpostsの対応サービス・Local Zones/Wavelengthの提供状況は変動が速く、公式ドキュメントの最新確認が常に必要です。過去に調べた情報を更新せずに設計・調達を進めることが最大のリスクです
• リージョン思考の持ち込み: 弾力的なスケーリング・豊富なマネージドサービス・使用量課金というリージョンの常識は通用せず、エッジ固有の制約が多くあります。「エッジはリージョンとは別のゲーム」という認識転換が重要です
• 縮退設計の後回し: 可用性要件の確認は早期に行い、service link断・Zone障害時の縮退動作を設計フェーズで定義します。本番化後に縮退設計を追加するのは大幅なアーキテクチャ変更を伴います

これら3パターンを意識するだけで、本番インシデントの大半を事前に防止できます。

8-2. アンチパターン → 正解

3サービスでよく見られる誤設計と、それに対する正解パターンを整理します。

アンチパターンの共通根拠

上記アンチパターンの多くは「リージョンと同じ前提でエッジを設計する」ことから発生します。Outposts・Local Zones・WavelengthはリージョンのAZとは異なる制約（容量・サービスサブセット・課金モデル・接続依存性）を持ちます。設計レビュー時に「これはリージョンと同じ前提で設計していないか」を確認することがアンチパターン防止の第一歩です。

8-3. まとめ — 3サービスの本番活用指針

AWS Outposts・Local Zones・Wavelengthの3サービスは、いずれも「AWSのインフラをリージョン外へ物理的に配置・拡張する」という共通テーマを持ちながら、それぞれ異なる要件と制約を持つサービスです。

本記事で解説した内容を3点に整理します。

1. 要件起点で選ぶ

§7のフローチャートを起点に、データレジデンシー（自社建物内保持はOutposts）・都市内低遅延（メトロユーザー向けLocal Zones）・5G超低遅延（モバイル端末向けWavelength）から選定します。複数要件がある場合は組み合わせ利用も検討してください。

2. 容量と対応サービスは常に最新確認

Outpostsの物理キャパシティは追加に数週間〜数ヶ月かかります。Local ZonesとWavelengthの対応サービス・提供ゾーンは拡張が続いており、設計フェーズ・調達フェーズ双方で最新情報の確認が必要です。

3. 縮退設計を外せない

service link断、Local Zone障害、Wavelength Zoneの瞬断を前提とした縮退設計は、本番化前に必ず実施します。§8-1のつまずきポイントで整理したように、縮退設計の欠如は本番インシデント直結です。

3サービスを組み合わせる複合設計パターン

現実の要件では、1つのシステムがOutposts・Local Zones・Wavelengthのうち複数を組み合わせるケースがあります。代表的な組み合わせパターンを整理します。

• Outposts + リージョンDR: オンプレのOutpostsでプライマリ処理を行いつつ、親リージョンをディザスタリカバリ先にするパターン。service link断・Outposts障害時に親リージョンへフェイルオーバーします
• Local Zonesフロント + リージョンバックエンド: 都市内ユーザー向けWebフロントエンドをLocal Zones、API・DBを親リージョンに配置するパターン。フロントエンドの低遅延を実現しつつ、バックエンドはリージョンの弾力性を活用します
• Wavelength 推論 + リージョン学習: 5Gエッジでリアルタイムのモデル推論をWavelengthで実行しつつ、モデルの学習・更新は親リージョンのSageMakerで行うパターン。推論モデルをS3→Wavelength Zone EC2へ定期的に更新します
• Outposts + Local Zones (国内規制対応): 機密データはOutpostsに留め、非機密の都市内ユーザー向けサービスはLocal Zonesで提供するパターン。規制と低遅延の両立が要件の場合に検討します

複合設計では「どのデータがどの配置先を通るか」のデータフローと、「どの配置先が障害時にどこへフォールバックするか」の縮退フローを2軸で整理することが重要です。

3サービスが向かないシナリオ

選定の精度を高めるために、各サービスが向かないシナリオも明示します。

• Outposts が向かない: スタートアップ・SMBのように物理設備管理の負担が取れない場合、急激なスケールアップが必要な場合（物理上限の壁）、設置物理スペースが確保できない場合
• Local Zones が向かない: 対象都市にLocal Zoneが存在しない場合（日本国内は現状東京・大阪フルリージョンがあるためLocal Zone都市は少ない）、対応サービスのサブセット制限でアーキテクチャが成立しない場合
• Wavelength が向かない: 対象地域でWavelength未提供のキャリアを利用している場合、5G端末以外のクライアントを主要とする場合、必要なサービス（RDS/S3/Lambda等）のWavelength Zone利用が不可の場合

Vol2予告: より深いネットワーク・セキュリティ・マルチアカウント統合へ

本記事Vol1では3サービスの全体像と配置設計の基本を扱いました。次回Vol2では、マルチアカウント環境でのOutposts管理（AWS Organizations/Control Towerとの統合）、Outpostsのセキュリティ設計（SCP/IAM/VPC境界の制御）、Local ZonesとWavelengthの本番セキュリティパターンを扱う予定です。ネットワーク設計の深掘りも予定していますので、ぜひVol2もご参照ください。

Outposts service linkに使うDirect Connect/VPN — Network本番運用 Vol1

TGW / PrivateLink / VPC Peeringの設計 — Network本番運用 Vol2

Cloud WAN / VPC Latticeによる大規模ネットワーク — Network本番運用 Vol3

エッジ配置リソースの可観測性設計 — Network可観測性 Vol1

リージョン内EC2/Auto Scalingの設計 — Compute本番運用 Vol1

8-4. 本番化前のプレランチェックリスト

3サービスを本番化する前に確認すべき項目を整理したチェックリストです。設計・調達・構築の各フェーズで活用してください。

Outposts 本番化前チェック

• [ ] 必要サービス・インスタンスタイプを公式ドキュメント（Outposts対応サービスリスト）で最新確認済みか
• [ ] Outpostsの物理キャパシティが12〜24か月のワークロード増加予測に対して余裕を持った設計か
• [ ] service link接続がDirect Connect private VIFで確立されているか（インターネット依存は本番非推奨）
• [ ] service link断時の縮退動作が定義・テスト済みか（テスト方法: service linkのsimulated断絶テスト）
• [ ] CloudWatchでOutpostsキャパシティ使用率・service link状態の監視アラームが設定済みか
• [ ] Local Gatewayの設定が正確で、オンプレLANとのBGP経路交換が確認済みか
• [ ] データレジデンシー要件（どのデータがオンプレ外に出てよいか）が書面で定義済みか
• [ ] 発注からOutposts設置完了までのリードタイム（数週間〜数ヶ月）を計画に組み込んでいるか

Local Zones 本番化前チェック

• [ ] 対象のLocal Zone（具体的なZone名）が確定済みか
• [ ] そのLocal Zoneで必要なサービス・インスタンスタイプが最新ドキュメントで提供確認済みか
• [ ] Local Zone内のキャパシティが不足する可能性を考慮し、On-Demand Capacity Reservationを設定済みか
• [ ] 遅延敏感な処理のみLocal Zones配置、残りは親リージョン配置のハイブリッドアーキテクチャが設計済みか
• [ ] Local Zones固有のローカルインターネット出口（Local Internet Breakout）の利用可否を確認済みか
• [ ] Local Zoneが障害時に親リージョンへ自動フォールバックする構成が確認済みか

Wavelength 本番化前チェック

• [ ] 利用予定のキャリアとWavelength ZoneがAWS公式ページ（「AWS Wavelength locations」）で現在提供中であることを確認済みか
• [ ] Carrier IPとElastic IPの使い分けをアーキテクチャ設計に明示済みか
• [ ] UE（モバイル端末）からCarrier Gateway経由での疎通テストを実施済みか
• [ ] Wavelength Zone単独障害時に親リージョンへフォールバックする設計が確認済みか
• [ ] コスト見積もりにWavelength Zone固有のEC2料金・データ転送費（キャリアネットワーク経由分）が含まれているか

共通チェック（3サービス共通）

• [ ] 本記事§7の選定フローチャートに従い、要件に合ったサービスが選定されていることを再確認済みか
• [ ] 接続構成（Direct Connect・VPN・TGW）は既存ネットワーク設計を流用し、重複設計になっていないか
• [ ] 監視・可観測性の設定に既存の可観測性設計（§6参照）を拡張して対応しているか

8-5. 3サービス選定でよくある誤解

最後に、Outposts・Local Zones・Wavelengthの選定で現場が陥りやすい誤解を整理します。設計の初期段階でこれらを正しておくと、後戻りを防げます。

• 「エッジ＝すべて低遅延だから何でも置ける」という誤解。実際には各サービスで対応サービスが大きく異なり、Outposts serversやWavelengthは限定的です。置きたいワークロードが対応しているかを最初に確認します。
• 「Local Zonesがあれば日本のどの都市でも低遅延化できる」という誤解。提供メトロは限られ、日本国内は東京・大阪のフルリージョンが基本です。提供有無は必ず最新の公式ページで確認します。
• 「Wavelengthはモバイル以外でも汎用的に使える」という誤解。Wavelengthはキャリアの5G網に紐づくため、モバイル端末からの超低遅延が主目的です。一般的なWeb配信ならLocal ZonesやCDNが適します。
• 「オンプレに置けばコストが下がる」という誤解。Outpostsはキャパシティ課金で、遊休リソースもコストになります。コスト削減ではなく、データ所在・遅延・オンプレ近接といった要件充足が選定理由です。

関連: Edge/CDN本番運用 Vol1（CloudFront/Lambda@Edge）