AWS Outposts は、AWS のインフラ、サービス、API、運用ツールをオンプレミス環境に配置するためのマネージドサービスです。ラック型やサーバー型があり、ラック型では EC2、EBS、EKS、ECS、RDS、ALB など、一部の AWS サービスをローカル拠点で利用できます。AWS 公式ドキュメントでも、Outposts は低レイテンシ、ローカルデータ処理、データレジデンシー、既存オンプレシステムとの依存関係を持つワークロード向けと説明されています。
ただし、Outposts を単に「オンプレに AWS が来る」と理解すると、重要な論点を取り落とします。Outposts の本質は、オンプレミス基盤を AWS API、AWS 管理モデル、AWS の責任分界に寄せることにあります。
つまり、Outposts 導入で問われるのは「クラウドかオンプレか」ではなく、どの責任を AWS 側へ寄せ、どの責任を自社側に残すのかです。
1. Outposts は完全なスタンドアロン基盤ではない
Outposts はオンプレに設置されますが、AWS Region との継続的な接続を前提に設計されています。その中心になるのが Service Link です。
Service Link は Outposts と AWS Region を接続する暗号化された VPN 接続群で、Outposts の管理、監視、ソフトウェア更新、AWS Region との VPC 通信などに使われます。AWS ドキュメントでも、Outposts は AWS Region との constant and consistent connection を前提とすると説明されています。
ここが最初の重要点です。
Outposts 上の EC2 はローカルで動作します。しかし、Outposts 全体の管理プレーンは AWS Region との接続に依存します。そのため、Service Link は単なる外部接続ではなく、Outposts の成立条件です。
| 要素 | 意味 |
|---|---|
| Outposts 上の EC2 / EBS | ローカル拠点で動作 |
| Service Link | AWS Region との管理・制御経路 |
| AWS Region | Outposts の管理プレーン側 |
| WAN / Direct Connect / Internet | Service Link の物理・論理経路 |
| Firewall / NAT / BGP | Service Link 成立のための利用者側責任 |
したがって、Outposts を設計する場合、最初に見るべきものは EC2 ではなく、Service Link を成立させる WAN / BGP / FW / MTU / 冗長経路です。
2. Local Gateway はオンプレ接続の中心になる
Outposts rack では、オンプレネットワークとの接続に Local Gateway LGW を使います。LGW は、Outposts subnet とオンプレネットワークを接続するための論理的なルーターです。AWS ドキュメントでは、LGW は Outposts rack とオンプレネットワーク間の通信を可能にする logical interconnect virtual router と説明されています。
Outposts のネットワークは、大きく 2 つの経路に分かれます。
| 経路 | 役割 | 主な設計対象 |
|---|---|---|
| Service Link | AWS Region との管理・制御・VPC 通信 | WAN、DX、Internet、FW、VPN、BGP |
| Local Gateway | オンプレ LAN との通信 | LGW、VIF、VLAN、BGP、route table |
この分離を理解しないと、Outposts の設計は崩れます。
- Service Link は AWS Region 側との接続です。
- Local Gateway はオンプレネットワーク側との接続です。
この 2 つはどちらも BGP や VLAN を使いますが、役割が違います。Service Link は Outposts を AWS 管理下に置くための経路であり、LGW は Outposts 上のワークロードをオンプレネットワークへ接続するための経路です。
3. ネットワーク設計は軽くならない
Outposts は AWS のサービスですが、ネットワーク設計はかなり物理寄りです。
第二世代 Outposts rack では network rack が必須で、4 台の Outposts network device が upstream のスイッチまたはルーターに接続されます。接続には LACP、VLAN trunk、/31 の point-to-point、Service Link VLAN、Local Gateway VLAN、eBGP などが必要です。
つまり、Outposts は「AWS だからネットワークを考えなくてよい」サービスではありません。むしろ、既存オンプレネットワークとの境界が明確になるため、ネットワーク設計の重要性は上がります。
| 項目 | 設計ポイント |
|---|---|
| 物理接続 | 10 / 40 / 100Gbps、光ファイバー、LC、LACP |
| L2 | Service Link VLAN と LGW VLAN の分離 |
| L3 | 各 Outposts network device との /31 point-to-point |
| BGP | Service Link 用 eBGP、LGW 用 eBGP |
| FW | TCP / UDP 443、stateful firewall、NAT / PAT |
| MTU | Service Link 経路で 1500 bytes 必須 |
| 冗長性 | upstream device 2 台または 4 台 |
| 経路分離 | VRF による Service Link / LGW 分離 |
特に重要なのは、Service Link と LGW を同じ感覚で扱わないことです。
Service Link 側は AWS Region との管理・制御経路です。
LGW 側はワークロード通信のためのオンプレ接続です。
この 2 つを VRF や VLAN で分離して扱う設計が、Outposts の安定運用には重要になります。
4. Direct VPC Routing と CoIP の選択
LGW のルーティングには、大きく 2 つの考え方があります。
| モード | 内容 | 向くケース |
|---|---|---|
| Direct VPC Routing | Outposts subnet の private IP をそのままオンプレへ BGP 広告する | VPC CIDR とオンプレ CIDR が重複しない |
| CoIP | customer-owned IP を Elastic IP 的に割り当て、LGW 側で変換する | 既存オンプレ IP 設計に合わせたい、CIDR 重複がある |
Direct VPC Routing は構造が単純です。Outposts subnet の private IP がそのままオンプレネットワークから到達可能になります。ただし、VPC CIDR とオンプレネットワークの CIDR が重複していると使えません。
CoIP は、customer-owned IP address pool を使う方式です。オンプレ側で管理している IP アドレスを Outposts 上のインスタンスに割り当てる形にできるため、既存ネットワークに合わせやすくなります。一方で、Elastic IP、CoIP pool、BGP 広告、変換動作を含めた設計が必要になります。
この選択はかなり重要です。
Outposts を既存オンプレネットワークに自然に組み込む場合、IP アドレス設計が最初の分岐点になります。
5. Outposts の容量は有限である
AWS Region の EC2 は、利用者から見るとほぼ無限に近いリソースプールとして扱えます。一方、Outposts は違います。
Outposts の EC2 / EBS capacity は、設置されたラック、サーバー、注文した構成に依存する有限リソースです。AWS ドキュメントでも、Outposts の compute / storage capacity は、設置された資産のサイズと数によって決まると説明されています。
この点は、通常の AWS 利用と大きく違います。
| 観点 | AWS Region | AWS Outposts |
|---|---|---|
| EC2 capacity | 利用者から見ると大規模 | 設置構成に依存 |
| スケール | 比較的容易 | 物理容量・注文構成に制約 |
| 障害時余力 | AWS 側の大規模基盤に依存 | Outposts 内の空き容量が重要 |
| インスタンスタイプ | Region ごとの対応範囲 | Outposts rack 構成に依存 |
| 配置制御 | AZ / placement group | host / rack 単位の意識が重要 |
Outposts では、初期サイジング、インスタンスファミリー、障害時余力、メンテナンス時の退避先を明確に設計する必要があります。
この意味では、操作感は AWS でも、容量設計はオンプレに近いです。
6. Outposts で変わる責任分界
Outposts 導入で最も大きく変わるのは、技術要素そのものよりも責任分界です。
従来のベアメタル基盤では、サーバー側が物理サーバー、仮想化基盤、ストレージ、OS、管理サーバー、場合によっては NF 管理系まで持つことがあります。ネットワーク側は、物理接続、L2 / L3、FW、BGP、外部接続、NF の通信経路などを持ちます。
Outposts になると、この分界が変わります。
| 領域 | 主体 |
|---|---|
| Outposts 物理機器 | AWS |
| ハードウェア保守 | AWS |
| EC2 / EBS 基盤 | AWS |
| Outposts site / order / capacity | AWS アカウント側設計 |
| IAM / Organizations / RAM | AWS 設計側 |
| VPC / subnet / route table / SG | AWS 設計側 |
| Service Link 接続 | ネットワーク側 + AWS 側 |
| LGW / VLAN / BGP | ネットワーク側 + AWS 設計側 |
| EC2 上の OS / アプリ / NF | 利用者側 |
| 管理サーバー系 EC2 | 利用者側 |
この構造を見ると、Outposts はサーバー基盤の多くを AWS 管理に寄せます。一方で、ネットワーク側の責任は消えません。むしろ、Outposts が成立するかどうかは、Service Link と LGW の設計に強く依存します。
7. 導入後に残る設計タスク
Outposts にすると、サーバー基盤の物理管理や仮想化基盤管理は AWS 側に寄ります。しかし、利用者側の設計タスクがなくなるわけではありません。
AWS 側で設計するもの
| 分類 | 設計対象 |
|---|---|
| アカウント | Organizations、アカウント分離、所有者 / 利用者 |
| IAM | 管理権限、運用権限、最小権限 |
| VPC | CIDR、subnet、route table、security group |
| Outpost subnet | Outposts 上に作る subnet |
| Local Gateway | route table、VPC association、VIF group |
| Resource sharing | AWS RAM、共有 subnet、共有 LGW route table |
| Capacity | EC2 instance family、EBS、余力 |
| 運用 | CloudWatch、CloudTrail、Config、SSM |
ネットワーク側で設計するもの
| 分類 | 設計対象 |
|---|---|
| 物理 | uplink、光種別、LACP、冗長構成 |
| L2 | VLAN trunk、Service Link VLAN、LGW VLAN |
| L3 | /31 point-to-point、VRF、経路分離 |
| BGP | ASN、neighbor、経路広告、multipath |
| FW | TCP / UDP 443、stateful policy、NAT / PAT |
| WAN | Direct Connect、Internet backup、latency、bandwidth |
| 障害対応 | BGP down、Service Link down、非対称経路 |
サーバー / アプリ側で設計するもの
| 分類 | 設計対象 |
|---|---|
| EC2 | AMI、instance type、placement |
| OS | patch、設定管理、監視 |
| NF | 商用 NF / CNF / 管理サーバー |
| EBS | volume type、容量、snapshot |
| EKS / ECS | Outposts 上で使う場合の制約確認 |
| RDS / ALB | 対応 Region / 対応サービス確認 |
| バックアップ | Region 側連携、ローカル保護、復旧設計 |
8. ベアメタル基盤との比較
Outposts とベアメタル基盤は、単純な優劣では比較できません。見るべき軸は、自由度、責任分界、運用負荷、AWS との統合度です。
| 観点 | Outposts | ベアメタル基盤 |
|---|---|---|
| 物理保守 | AWS 側 | 自社 / ベンダー側 |
| 仮想化基盤 | AWS 管理 | VMware / KVM / OpenStack など |
| API | AWS API | 製品・構成依存 |
| ネットワーク自由度 | AWS 制約あり | 高い |
| 容量自由度 | 注文構成に依存 | 自由だが自前管理 |
| NF 収容 | EC2 / EKS 前提 | 任意構成にしやすい |
| 既存設備連携 | LGW / BGP 前提 | 自由度が高い |
| 運用モデル | AWS 管理モデル | オンプレ運用モデル |
| 導入障壁 | 契約・施設・NW 要件が重い | 構築・保守・運用が重い |
Outposts が向くのは、AWS API、AWS 運用モデル、IAM、VPC、EKS、CloudWatch などに寄せたいケースです。一方、特殊なネットワーク要件、独自ハードウェア要件、NF の特殊な収容方式、細かい物理制御が必要な場合は、ベアメタル基盤の方が扱いやすい場合があります。
9. Outposts 導入判断の軸
Outposts を採用するかどうかは、次の問いで整理できます。
| 問い | 判断ポイント |
|---|---|
| AWS API に統一する価値があるか | EC2 / EBS / EKS / IAM / CloudWatch などに寄せる意味 |
| Service Link を安定運用できるか | WAN、DX、FW、BGP、MTU、冗長性 |
| LGW 設計を既存ネットワークに統合できるか | CIDR、CoIP、DVR、VRF、経路制御 |
| 容量制約を受け入れられるか | finite capacity、余力、障害時退避 |
| AWS 側責任分界に寄せる価値があるか | 物理保守・基盤運用を AWS に寄せる効果 |
| ベアメタルの自由度を捨てられるか | NF、特殊構成、ネットワーク自由度 |
この整理で見ると、Outposts は「AWS をオンプレに置けるから便利」という単純な話ではありません。
Outposts は、オンプレ基盤のうち、物理・仮想化・AWS サービス基盤の責任を AWS 側に寄せる一方で、ネットワーク境界、WAN、BGP、IP 設計、Local Gateway、Service Link の設計責任を利用者側に強く残すサービスです。
結論
AWS Outposts は、オンプレミス環境に AWS サービスを持ち込むための強力な選択肢です。しかし、その本質は「オンプレに AWS が来る」ことではありません。
Outposts の本質は、オンプレ基盤の責任分界を再設計することです。
EC2 や EBS をローカルで動かせる一方で、Outposts は AWS Region との Service Link を前提に動作します。オンプレネットワークとの接続には Local Gateway、VIF、VLAN、BGP、route table の設計が必要です。さらに、Outposts 上の capacity は有限であり、通常の AWS Region と同じ感覚では扱えません。
したがって、Outposts の導入判断は次の一点に集約できます。
AWS 管理モデルをオンプレに持ち込む価値が、Service Link、Local Gateway、ネットワーク設計、容量制約、コストを上回るか。
この問いに明確に答えられる場合、Outposts は有力な選択肢になります。逆に、ネットワーク自由度、独自構成、特殊な NF 収容、物理レイヤーまで含む細かい制御を重視する場合は、ベアメタル基盤の方が適している可能性があります。
Outposts は、オンプレとクラウドの中間にある製品ではありません。
オンプレの場所に、AWS の責任分界と運用モデルを持ち込むためのインフラです。
