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

AWS Outposts は、AWS のインフラストラクチャ、サービス、API、ツールをオンプレミス環境へ拡張するためのサービスである。AWS 公式ドキュメントでは、Outposts は 1U / 2U の Outposts servers から 42U の Outposts racks まで、複数のフォームファクターで提供されると説明されている。

ただし、同じ AWS Outposts という名前であっても、ラックタイプとサーバータイプは設計上の性格が大きく異なる。特にネットワークアプライアンスや NF 基盤として評価する場合、ネットワーク接続方式、ストレージ、可用性、保守運用の違いを明確に分ける必要がある。

本記事では、ラックタイプについては第 2 世代 Outposts racks を前提に整理する。

基本的な位置づけ

種別	一次情報に基づく整理	設計上の読み取り
第 2 世代 Outposts racks	42U ラック型の Outposts。第 2 世代では compute rack と network rack を組み合わせる構成	オンプレミスに AWS 基盤を配置するモデル
Outposts servers	1U / 2U のサーバー型 Outposts	AWS 管理の EC2 実行環境を小型サーバーとして配置するモデル
ベアメタル	AWS Outposts ではない自前の物理基盤	ネットワーク、ストレージ、仮想化基盤を自由に設計するモデル

第 2 世代 Outposts racks は、Local Gateway、EBS、VPC、EC2、EKS、network rack などを含めて、オンプレミス AWS 基盤として扱いやすい。一方、Outposts servers は、AWS 管理の Nitro ベース EC2 実行環境を小型サーバーとしてオンプレミスに置くものとして捉える方が実態に近い。

ネットワーク接続方式の違い

Outposts racks と Outposts servers では、オンプレミスネットワークへの接続方式が異なる。

項目	第 2 世代 Outposts racks	Outposts servers
ローカル接続方式	Local Gateway / LGW	Local Network Interface / LNI
VPC 側インターフェイス	ENI	ENI
オンプレミス側接続	LGW を経由	LNI を使用
ネットワーク設計の中心	LGW、VIF、VLAN、BGP、network rack	LNI、customer LAN、OS firewall、upstream switch / router
AWS 側ネットワーク制御	VPC、route table、Security Group、LGW	ENI 側は VPC 制御、LNI 側は VPC 制御の対象外

AWS 公式ドキュメントでは、Outposts servers の LNI は、Outpost subnet 内の EC2 インスタンスをオンプレミスネットワークへ接続する論理ネットワークコンポーネントと説明されている。LNI は 1 EC2 インスタンスにつき 1 つであり、primary network interface としては使用できない。

このため、Outposts servers 上の EC2 インスタンスは、概念的には以下のように整理できる。

IF	接続先	主な用途
ENI	VPC 側	AWS 管理、AWS サービス連携、VPC 通信、Security Group 対象通信
LNI	オンプレミス LAN 側	ローカル通信、オンプレ機器接続、ネットワークアプライアンスのデータプレーン

設計上の読み取りとして、Outposts servers の ENI は、EC2 / VPC として成立させるためには重要である。しかし、オンプレミス側のローカルデータプレーンや、異なる Outposts servers 間のローカル通信の主役にはなりにくい。ネットワークアプライアンス用途では、主経路は LNI 側になる。

Outposts servers の LNI 制約

Outposts servers の LNI には、ネットワークアプライアンス設計上重要な制約がある。

項目	内容
LNI の数	1 EC2 インスタンスにつき 1 つ
primary network interface	LNI は primary network interface として使用できない
quota	LNI の quota は network interface quota から消費される
VPC networking components	LNI 側には Security Group、NACL、VPC route table、VPC flow logs などは適用されない
制御方法	OS firewall、オンプレミス側 firewall、switch、router 側で制御する

このため、Outposts servers では、オンプレミス側に複数 NIC を直接アタッチするネットワークアプライアンス構成は取りにくい。外部接続は LNI 1 本に集約されるため、複数セグメントを扱う場合は、LNI の先で VLAN、subinterface、VRF、ルーティング、OS 側 firewall などを組み合わせる設計になる。

Outposts servers 間の通信

Outposts servers を複数台配置した場合、異なる物理サーバー上の EC2 インスタンス間通信をどう扱うかが重要になる。

AWS 公式ドキュメントでは、Outposts servers の物理接続として、service link traffic と LNI link traffic が説明されている。service link は Outpost registration endpoints や AWS Region との通信に使われ、LNI link は EC2 インスタンスがオンプレミスネットワークと通信するために使われる。

したがって、Outposts servers 間のローカル通信は、次のように整理するのが自然である。

通信パターン	整理
同一 Outposts server 内の EC2 同士	同一サーバー内で直接通信できる
異なる Outposts servers 上の EC2 同士	サーバー内では完結しない
異なる Outposts servers 上の EC2 同士のローカル通信	LNI から customer LAN / switch / router を経由して通信する
ENI の役割	VPC 側、AWS Region 側、AWS サービス連携、管理通信
LNI の役割	オンプレミス LAN 側、ローカルデータ通信

図にすると以下のようになる。

Outposts server A
  EC2-A
    ENI -> VPC / AWS Region side
    LNI -> customer LAN

Outposts server B
  EC2-B
    ENI -> VPC / AWS Region side
    LNI -> customer LAN

EC2-A と EC2-B のローカル通信:
  EC2-A
    -> LNI
    -> customer LAN / switch / router
    -> LNI
    -> EC2-B

ここで重要なのは、異なる Outposts servers 上の EC2 同士を、ラックタイプのような内部ファブリック上の VM 間通信として扱わないことだ。Outposts servers を複数台並べても、それだけで 1 つのラック型 Outpost のような共通内部ネットワーク基盤が形成されるわけではない。

設計上の読み取りとして、Outposts servers の ENI は、AWS VPC 側に接続するためのインターフェイスである。ローカルネットワークやネットワークアプライアンスのデータプレーンを考える場合、実質的な出口は LNI になる。

Outposts servers における ENI の評価

Outposts servers の ENI は、仕様上重要である。EC2 として VPC に所属し、Security Group、AWS サービス連携、管理通信を扱うために必要である。

一方で、ネットワークアプライアンスや NF のデータプレーンという観点では、ENI の意味は限定的になる。

観点	ENI の意味
EC2 として VPC に所属する	重要
AWS 管理プレーンと連携する	重要
AWS サービス、Regional endpoints、PrivateLink 等へ接続する	重要
Security Group による制御	重要
オンプレミス LAN へ直接出る	主役ではない
異なる Outposts servers 間のローカル通信	主役ではない
NF / ネットワークアプライアンスのデータプレーン	基本的には LNI 側が主役

したがって、Outposts servers では、ENI を「内部ネットワーク用の主インターフェイス」と見るより、VPC / AWS 管理 / AWS サービス連携用のインターフェイスと見る方がよい。

ネットワークアプライアンス視点では、以下の整理が自然である。

AWS / VPC / 管理側
  |
  | ENI
  |
EC2 appliance
  |
  | LNI
  |
オンプレミス LAN / 外部ネットワーク

つまり、Outposts servers のネットワークアプライアンス設計では、ENI は control plane / management plane、LNI は data plane として評価するのが自然である。

ストレージの違い

Outposts servers と Outposts racks では、ストレージ面にも重要な違いがある。

項目	第 2 世代 Outposts racks	Outposts servers
EBS	利用可能	Outposts servers 上のインスタンスは EBS volumes を含まない
instance store	利用可能	Outposts servers 上のインスタンスは instance store volumes を含む
reboot 時	通常の再起動として扱いやすい	instance store のデータは保持される
terminate 時	EBS に残せる	instance store のデータは保持されない
長期データ	EBS、S3 on Outposts、外部ストレージ等	S3、オンプレミスネットワークストレージ、外部設定管理等へ退避

AWS 公式ドキュメントでは、Outposts servers 上のインスタンスは instance store volumes を含むが、EBS volumes は含まないと説明されている。また、instance store 上のデータは reboot 後は保持されるが、instance termination 後は保持されない。

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

障害時の考え方

第 2 世代 Outposts racks は、Outpost 内の compute / storage capacity を持つ基盤として扱われる。Outposts racks では、容量設計、EBS、配置戦略、アプリケーション側の冗長化を組み合わせて可用性を設計する。

一方、Outposts servers は単体サーバー型のフォームファクターである。サーバー障害や退役が発生した場合、AWS から通知され、影響を受けるインスタンスや instance store 上のデータを外部へ退避し、交換サーバーへ移行する運用になる。

項目	第 2 世代 Outposts racks	Outposts servers
障害時の考え方	Outpost 内の容量、EBS、アプリケーション冗長化を組み合わせる	単体サーバー障害を前提に、外部化と再作成で復旧する
データ保護	EBS や外部ストレージを利用可能	instance store の正本化は避ける
ネットワークアプライアンス	基盤側の容量・ストレージ・LGW を使った設計が可能	appliance OS 層と上位ネットワーク側の切替で冗長化する
復旧単位	インスタンス、EBS、Outpost 内容量	AMI、IaC、外部設定、外部データ

Outposts servers でネットワークアプライアンスを動かす場合、仮想 MAC や L2 依存の HA より、BGP、static route、health check、DNS、LB など、L3 以上の切替方式を中心に検討する方がよい。

保守・運用

AWS Outposts は AWS が管理するサービスである。ただし、ラックタイプとサーバータイプでは、物理保守時の作業主体が異なる。

項目	第 2 世代 Outposts racks	Outposts servers
AWS が管理する範囲	Outposts equipment、software patch、firmware、性能・ヘルス・メトリクス監視など	Outposts equipment、software patch、firmware、性能・ヘルス・メトリクス監視など
物理交換	AWS installation team が現地で対応するモデル	AWS が交換プロセスを開始し、交換機と返送ラベルを提供する
利用者側作業	施設、電源、ネットワーク要件の維持	サーバーの取り外し、交換機の設置、梱包、返送など
運用上の性格	AWS 現地保守モデル	AWS 管理機器のセンドバック運用に近い

Outposts servers では、AWS が交換サーバーを送付し、返送ラベルを提供する。利用者側では、対象サーバーの取り外し、交換機の設置、故障機の梱包、返送を行う必要がある。

このため、Outposts servers を採用する場合は、通常の AWS Region の EC2 と同じ運用感覚ではなく、オンプレミス機器としての設置、交換、返送、保守窓、現地作業者の手順を含めて設計する必要がある。

ネットワークアプライアンスとしての評価

一次情報に基づく制約を踏まえると、Outposts servers はネットワークアプライアンス用途で使えないわけではない。ただし、用途は限定される。

用途	Outposts servers での評価
L3 router	LNI 1 本で成立する範囲では検討可能
Proxy	ステートを外部化しやすいため比較的扱いやすい
VPN gateway	証明書、鍵、設定を外部管理する前提で検討可能
Firewall	小規模・L3 前提では検討可能
多 NIC firewall	LNI 1 本の制約により不向き
L2 bridge	LNI の性質上、不向き
IDS / packet capture	L2 / promiscuous 的な用途には不向き
本格 NFV	NIC、ストレージ、冗長化の制約が大きい

設計上の読み取りとして、Outposts servers は「AWS 管理の Nitro ベース EC2 実行環境をオンプレミスに置く」ことに価値がある。一方、ネットワーク自由度、多 NIC、ストレージ自由度、L2 制御を重視する場合は、ベアメタル構成との比較が必要になる。

ベアメタルとの比較

Outposts servers をネットワーク基盤として検討すると、ベアメタルとの比較が必要になる。

評価軸	Outposts servers	ベアメタル
仮想化基盤	AWS 管理の EC2 実行環境	自前で KVM、VMware、その他基盤を設計
API	EC2 API	自前 API、libvirt、OpenStack、管理ツール等
イメージ	AMI	自前イメージ、PXE、テンプレート等
権限管理	IAM	自前の認証・認可
監視	CloudWatch、AWS Health 等	自前監視基盤
NIC 自由度	LNI 1 本の制約	物理 NIC、bond、VLAN、SR-IOV 等を自由設計
ストレージ自由度	instance store 中心	local disk、RAID、SAN、Ceph 等を自由設計
NF 適性	限定的	高い
保守	AWS 管理 + 利用者交換・返送	自社またはベンダー保守

Outposts servers の利点は、EC2 API、AMI、IAM、CloudWatch、AWS Health、Nitro ベースの実行環境を利用できる点である。これは、単なるベアメタル + KVM にはない利点である。

一方で、ネットワークアプライアンスや NF のように、NIC 構成、ストレージ、L2 / L3 制御、冗長構成の自由度を重視する場合、ベアメタルの方が設計しやすい場合がある。

最終整理

種別	採用理由
第 2 世代 Outposts racks	オンプレミスに AWS 基盤を配置し、EC2、EBS、LGW、EKS などを統合的に使いたい場合
Outposts servers	小規模拠点やエッジで、AWS 管理の EC2 / Nitro 実行環境を使いたい場合
ベアメタル	ネットワーク自由度、ストレージ自由度、多 NIC、NF 適性を重視する場合

Outposts racks と Outposts servers は、同じ AWS Outposts という名前を持つが、設計上の性格は大きく異なる。

第 2 世代 Outposts racks は、オンプレミスに AWS 基盤を配置する選択肢である。Outposts servers は、AWS 管理の EC2 実行環境を小型サーバーとしてオンプレミスに配置する選択肢である。

特にネットワークアプライアンスや NF 基盤として評価する場合は、LNI 1 本、EBS なし、サーバー間内部ファブリックなし、物理交換・返送作業あり、という Outposts servers の前提を明確にした上で、ベアメタルや第 2 世代 Outposts racks と比較する必要がある。

Outposts servers の ENI は、EC2 / VPC としての接続、AWS 管理、AWS サービス連携には意味がある。一方、ローカルデータプレーンや異なる Outposts servers 間のローカル通信では、LNI と customer LAN が主役になる。ここを誤ると、Outposts servers をラックタイプの小型版として誤解してしまう。