AWS Outposts racks と Outposts servers は別物として評価すべき

AWS Outposts は、AWS のインフラストラクチャ、サービス、API、ツールをオンプレミス環境へ拡張するためのサービスです。ただし、同じ Outposts という名前でも、Outposts racks と Outposts servers は別物として評価した方がよいと思います。

特に、オンプレミスでネットワークアプライアンスや NF 基盤を動かす可能性を考える場合、racks と servers を同じ縮尺の製品として扱うと設計を誤ります。フォームファクター、ネットワーク接続、ストレージ、障害時の考え方がかなり違うからです。

Outposts racks と Outposts servers の基本的な違い

AWS 公式ドキュメントでは、Outposts servers は標準ラックに搭載できる 1U / 2U サーバー形状、Outposts racks はラック型の Outposts として説明されています。どちらも AWS 管理の基盤ですが、設計上の性格は大きく異なります。

種別	位置づけ	設計上の見方
Outposts racks	ラック型の Outposts	オンプレミスに AWS 基盤を延伸するモデル
Outposts servers	1U / 2U のサーバー型 Outposts	小規模拠点やエッジへ EC2 実行環境を置くモデル
自前ベアメタル	自社管理の物理基盤	NIC、ストレージ、仮想化、運用を自由に設計するモデル

Outposts racks は、AWS 基盤をオンプレミスへ持ち込む色が強いです。一方、Outposts servers は、AWS 管理の Nitro ベース EC2 実行環境を小型サーバーとして配置するものとして見た方が分かりやすいです。

ネットワーク接続方式が違う

Outposts racks と Outposts servers の違いで特に重要なのが、オンプレミスネットワークへの接続方式です。racks では Local Gateway が中心になりますが、servers では Local Network Interface、つまり LNI が重要になります。

項目	Outposts racks	Outposts servers
ローカル接続	Local Gateway / LGW	Local Network Interface / LNI
VPC 側	ENI、VPC、Security Group、route table	ENI、VPC、Security Group
オンプレミス側	LGW 経由で設計	LNI から customer LAN へ接続
主な設計対象	LGW、VLAN、BGP、VIF、ラック内基盤	LNI、customer LAN、OS firewall、上位 switch / router

Outposts servers の LNI は、EC2 インスタンスをオンプレミスネットワークへ接続するための論理ネットワークコンポーネントです。LNI 側には Security Group、NACL、VPC route table、VPC flow logs のような VPC ネットワーク制御は適用されません。

そのため、Outposts servers でローカルデータプレーンを設計する場合、AWS VPC 側の ENI ではなく、LNI と customer LAN 側の設計が中心になります。

Outposts servers をラックの小型版として見ない

Outposts servers を複数台並べても、それだけで Outposts racks のような共通のラック内ファブリックができるわけではありません。異なる Outposts servers 上の EC2 インスタンス同士のローカル通信は、LNI から customer LAN、switch、router を経由する前提で考える必要があります。

• 同一 Outposts server 内の EC2 同士は、同じサーバー内の通信として考えられる
• 異なる Outposts servers 上の EC2 同士は、サーバー内だけでは完結しない
• ローカル通信は LNI から customer LAN を経由する設計になる
• ENI は VPC / AWS サービス連携 / 管理側の意味が強い
• LNI はオンプレミス LAN 側のデータプレーンとして見る方が自然である

つまり、Outposts servers における ENI は control plane / management plane 寄り、LNI は data plane 寄りとして評価するのが自然です。ここを誤ると、Outposts servers をラック型 Outposts の小型版として誤解してしまいます。

LNI 1 本という制約

Outposts servers でネットワークアプライアンスを考える場合、LNI の制約がかなり重要です。LNI は 1 EC2 インスタンスにつき 1 つであり、primary network interface としては使えません。

項目	Outposts servers の整理
LNI 数	1 EC2 インスタンスにつき 1 つ
primary network interface	LNI は primary network interface にはできない
VPC 制御	LNI 側には Security Group や NACL は適用されない
制御方法	OS firewall、オンプレ firewall、switch、router 側で制御する
多 NIC 構成	一般的な多 NIC firewall のような構成は取りにくい

このため、Outposts servers は L3 router、proxy、VPN gateway のように LNI 1 本で成立する範囲なら検討できます。一方で、多 NIC firewall、L2 bridge、packet capture、NFV 的な自由度を求める用途には向きにくいです。

ストレージの違い

Outposts servers と Outposts racks は、ストレージの考え方も違います。Outposts servers 上のインスタンスは instance store volumes を含みますが、EBS volumes は含まないと AWS 公式ドキュメントで説明されています。

項目	Outposts racks	Outposts servers
EBS	利用可能	Outposts servers 上のインスタンスは EBS volumes を含まない
instance store	構成により利用	instance store volumes を含む
reboot 時	通常の再起動として扱いやすい	instance store のデータは保持される
terminate 時	EBS に残せる設計が可能	instance store のデータは保持されない
設計方針	EBS や外部ストレージを含めて設計	AMI、IaC、外部設定、外部データストアで再生成できる実行体として扱う

Outposts servers では、ローカルディスクを正本にする VM のように扱うより、AMI、user-data、IaC、外部設定、外部ログ、外部データストアから再生成できる実行体として扱う方が適しています。

障害時と保守の考え方

Outposts racks は、ラック型の AWS 管理基盤として、容量、EBS、アプリケーション側の冗長化を組み合わせて可用性を考えます。一方、Outposts servers は単体サーバー型なので、サーバー障害時には外部化と再作成の考え方が重要になります。

項目	Outposts racks	Outposts servers
障害時	Outpost 内の容量とアプリケーション冗長化を組み合わせる	単体サーバー障害を前提に外部化と再作成で復旧する
データ保護	EBS や外部ストレージを利用しやすい	instance store の正本化は避ける
物理保守	AWS installation team が現地対応するモデル	AWS が交換機と返送ラベルを提供し、利用者側で交換作業を行う
運用上の性格	AWS 現地保守モデル	AWS 管理機器のセンドバック運用に近い

Outposts servers は通常の AWS Region の EC2 と同じ感覚では扱えません。オンプレミス機器としての設置、交換、返送、保守窓、現地作業者の手順まで含めて考える必要があります。

OCI Dedicated Region との粒度の違い

前回整理した OCI Dedicated Region は、顧客データセンター内に専用の OCI リージョンを持ち込む発想です。Outposts と似た「クラウドを顧客側に持ち込む」文脈ではありますが、粒度が違います。

OCI Dedicated Region はリージョン単位の専用クラウドに近く、AWS Outposts racks は AWS 基盤をオンプレミスへ延伸するラック型基盤、Outposts servers は 1U / 2U の小型 EC2 実行環境です。同じ分散クラウドでも、どの単位を持ち込むのかで評価は変わります。

クラウドの本質から見る

クラウドという言葉の本質 で書いた通り、クラウドは場所ではなく、運用モデルと責任分界で見るべきだと思います。Outposts はこの考え方をよく示しています。

物理的にはオンプレミスに置かれます。しかし、API、管理、監視、更新、責任分界は AWS のモデルに寄ります。だからこそ、オンプレ機器としての自由度と、AWS 管理サービスとしての制約を同時に見なければなりません。

ベアメタルとの比較

ネットワーク自由度や NF 適性を重視するなら、自前の KVM / libvirt 基盤 やベアメタル構成との比較も必要です。Outposts servers は EC2 API、AMI、IAM、CloudWatch、AWS Health を利用できる点が強みです。一方で、NIC、ストレージ、L2 / L3 制御の自由度は自前ベアメタルの方が高くなります。

評価軸	Outposts servers	ベアメタル
API	EC2 API / AWS 管理	自前 API、libvirt、管理ツール
イメージ	AMI	PXE、テンプレート、自前イメージ
権限管理	IAM	自前の認証・認可
監視	CloudWatch / AWS Health	自前監視基盤
NIC 自由度	LNI 1 本の制約	物理 NIC、bond、VLAN、SR-IOV などを自由設計
NF 適性	限定的	高い

まとめ

AWS Outposts racks と Outposts servers は、同じ Outposts という名前を持ちますが、設計上は別物として評価すべきです。

Outposts racks は、オンプレミスに AWS 基盤を配置する選択肢です。Outposts servers は、小規模拠点やエッジに AWS 管理の EC2 / Nitro 実行環境を置く選択肢です。

特にネットワークアプライアンスや NF 基盤として評価する場合は、Outposts servers の LNI 1 本、EBS なし、サーバー間内部ファブリックなし、物理交換・返送作業あり、という前提を明確にする必要があります。ここを誤ると、ラック型 Outposts の小型版として過大評価してしまいます。