AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである

AWS Outposts は、AWS のインフラ、サービス、API、運用モデルを顧客拠点へ延長するためのマネージドサービスです。ただし、単に「オンプレミスに AWS が来る」と理解すると、重要な論点を見落とします。

Outposts の本質は、オンプレミス基盤を AWS API、AWS 管理モデル、AWS の責任分界に寄せることです。EC2 や EBS をローカルで使える一方で、Service Link、Local Gateway、物理環境、容量、ネットワーク接続、保守責任を新しく設計する必要があります。

つまり、Outposts 導入で問われるのは「クラウドかオンプレか」ではありません。どの責任を AWS 側へ寄せ、どの責任を自社側に残すのかです。

この記事の結論

Outposts はオンプレに置く AWS ではない

Outposts は、AWS の一部を顧客拠点に置くサービスです。しかし、オンプレミスに AWS Region が丸ごと来るわけではありません。使える service、capacity、networking、運用方法には Outposts 固有の制約があります。

Region と同じ API で扱える部分がある一方で、物理設置場所、電源、空調、rack、回線、オンプレミスネットワーク、現地保守は拠点側の現実に強く依存します。ここが通常の AWS Region との大きな違いです。

完全なスタンドアロン基盤ではない

Outposts は、AWS Region との Service Link を前提に動作します。control plane、管理、監視、更新、service 連携は AWS Region との接続に依存します。ローカルで compute を動かせることと、AWS から完全に独立した基盤であることは違います。

このため、Service Link の可用性、帯域、遅延、経路、障害時の挙動を設計対象に含める必要があります。Outposts を災害対策や閉域要件に使う場合も、Region との関係を切り離して考えることはできません。

Local Gateway はオンプレ接続の中心になる

Outposts とオンプレミスネットワークを接続するうえで重要になるのが Local Gateway です。Local Gateway は、Outposts 上の subnet とオンプレミス側ネットワークの到達性をつなぐ中心になります。

Local Gateway を使う場合、VLAN、BGP、route table、CIDR、オンプレミス側 routing、firewall、inspection、戻り経路を合わせて設計します。単に Outposts を設置すれば、オンプレミス LAN と自然に一体化するわけではありません。

ネットワーク設計は軽くならない

Outposts を導入しても、ネットワーク設計が軽くなるわけではありません。むしろ、AWS 側の VPC / subnet / route table と、オンプレミス側の VLAN / routing / firewall / BGP をつなぐ責任が増えます。

AWS の抽象化とオンプレミスの物理設計が同じ場所に現れるため、どちらのモデルで説明するのかを明確にしないと、障害時の切り分けが難しくなります。

Direct VPC Routing と CoIP の選択

Outposts では、オンプレミスとの接続方式として Direct VPC Routing や Customer-owned IP address、CoIP を考える場面があります。どちらを使うかは、オンプレミス側の routing、アドレス設計、既存 network policy、監視、security boundary に影響します。

ここで重要なのは、AWS 側の subnet とオンプレミス側の network を、どの IP と route で接続するかです。アドレスをどう見せるかによって、既存システムとの相性や障害時の説明が変わります。

容量は AWS Region のようには扱えない

Outposts の capacity は、拠点内に設置された物理リソースに依存します。通常の AWS Region のように、必要になったらすぐに別 instance type を大量に追加できる感覚では扱えません。

そのため、capacity planning、instance family、EBS、spare capacity、障害時の再配置、patch / maintenance 時の余力を事前に考える必要があります。クラウド API で扱えることと、capacity が無限に近いことは別です。

Outposts で変わる責任分界

導入後に残る設計タスク

• Service Link の経路、帯域、冗長化を決める
• Local Gateway とオンプレミス routing を接続する
• VLAN、BGP、route table、CIDR を合わせる
• Outposts capacity と spare を計画する
• Region 障害、回線障害、拠点障害時の挙動を確認する
• AWS 側と自社側の問い合わせ境界を決める

AWS 側で設計するもの

AWS 側では、VPC、Subnet、Route Table、Security Group、EBS、instance family、Service Link、Local Gateway 関連の構成を考えます。Region 側の service と Outposts 上の local resource の関係も設計対象です。

ネットワーク側で設計するもの

ネットワーク側では、Local Gateway、VLAN、BGP、routing、firewall、Direct Connect、WAN、既存拠点 LAN との接続を考えます。ここは AWS だけで完結しません。オンプレミス側の経路設計と運用手順が必要です。

サーバー / アプリ側で設計するもの

サーバーやアプリケーション側では、Outposts 上で動かす workload、Region 側に置く workload、local data access、latency、障害時の縮退、backup、patch、monitoring を考えます。Outposts に載せることで何が local になり、何が Region 依存のまま残るかを分けます。

ベアメタル基盤との比較

Outposts は、自社でベアメタル基盤を組む選択肢とは違います。ベアメタル基盤では hardware、hypervisor、network、storage、operations を自社で強く制御できます。Outposts では AWS API と managed model に寄せる代わりに、自由度の一部を手放します。

確認に使う AWS CLI

Outposts の状態を見るときは、Outposts 本体だけでなく、capacity、site、local gateway、route table も合わせて確認します。

aws outposts list-outposts
aws outposts list-sites
aws outposts list-catalog-items
aws ec2 describe-local-gateways
aws ec2 describe-local-gateway-route-tables
aws ec2 describe-local-gateway-virtual-interfaces

Outposts 導入判断の軸

まとめ

AWS Outposts は、オンプレミスに AWS Region をそのまま置くサービスではありません。AWS API、AWS 管理モデル、AWS の責任分界を顧客拠点へ持ち込み、ローカルの compute / storage を使えるようにするインフラです。

その代わり、Service Link、Local Gateway、物理環境、容量、オンプレミスネットワーク、運用責任を設計する必要があります。Outposts を選ぶときは、クラウドかオンプレかではなく、どの責任をどちら側に置くのかを決めることが出発点になります。

関連記事

AWS Outposts racks と Outposts servers は別物として評価すべき AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界 AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / single-flow と NFV 設計 AWS VPC に L2 はあるのか – VLAN / ARP / VIP をクラウドの到達性モデルへ翻訳する