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

AWS Outposts racks と Outposts servers は、同じ Outposts という名前でも設計上は別物として評価した方がよいです。違いはサイズだけではありません。Local Gateway を中心にオンプレミスネットワークへ接続する racks と、Local Network Interface を持つ小型 EC2 実行環境として見る servers では、ネットワーク、容量、ストレージ、保守、NF 適性が変わります。

特に、オンプレミスでネットワークアプライアンスや NF 基盤を動かす可能性を考える場合、Outposts servers を racks の小型版として扱うと設計を誤ります。フォームファクター、接続方式、障害時の扱い、local storage の前提が違うからです。

Outposts 全体の責任分界は、AWS Outposts の本質は責任分界を変えるインフラである、という観点で見る必要があります。この記事では、その中でも racks と servers の違いに絞って確認します。

この記事の結論

racks と servers はサイズ違いではない

Outposts racks と Outposts servers は、どちらも AWS の管理モデルを顧客拠点へ延長します。しかし、racks はより大きな拠点基盤として、servers は小規模拠点や edge に置く小型実行環境として見る方が自然です。

同じ API で扱える部分があっても、物理構成、ネットワーク接続、capacity、storage、保守、障害時の期待値が異なります。単純に racks を小さくしたものが servers だと考えると、設計判断を誤りやすくなります。

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

Outposts racks では、Local Gateway がオンプレミスネットワークとの接続の中心になります。VLAN、BGP、route table、Direct VPC Routing、CoIP などを通じて、VPC とオンプレミスネットワークの境界を設計します。

一方、Outposts servers では Local Network Interface、LNI が重要になります。LNI はオンプレミス側 network へ接続するための interface ですが、rack 型 Outposts の Local Gateway と同じ感覚で扱うものではありません。

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

Outposts servers は、AWS 管理の小型 EC2 実行環境を拠点に置く選択肢です。拠点や edge に AWS API で扱える compute を置ける点は魅力ですが、ネットワーク基盤や NF 基盤として自由に使える箱とは限りません。

特に NF、Firewall、Router、VPN、IDS / IPS のような network function を想定する場合、LNI、routing、帯域、interface 数、instance type、storage、障害時の再作成を含めて評価する必要があります。

LNI の制約を設計に入れる

Local Network Interface は、Outposts servers をオンプレミスネットワークへ接続する重要な要素です。ただし、LNI があるからといって、オンプレミスの物理サーバーと同じ network appliance として扱えるわけではありません。

LNI の数、接続先 subnet、security、routing、IP address、既存 LAN との責任分界を確認します。network function を動かす場合は、traffic をどの interface へ入れ、どこへ戻すのかを明確にします。

ストレージの違い

Outposts racks と Outposts servers では、storage の前提も変わります。racks では Outposts 上の EBS などを含めた基盤として設計できますが、servers では instance store の扱い、永続性、再作成、backup、local data の置き方を慎重に見る必要があります。

edge で小さく使う場合ほど、障害時に local data をどう扱うか、Region 側へ何を同期するか、再作成できる状態にしているかが重要になります。

障害時と保守の考え方

Outposts は AWS managed service ですが、設置場所は顧客拠点です。障害時には、AWS 側の service、Service Link、local network、電源、空調、物理機器、アプリケーションのどこに問題があるのかを分けて見ます。

racks と servers では保守や交換、capacity の考え方も異なります。servers は小型で導入しやすい一方、拠点側での障害影響や再作成前提の設計をより強く意識する必要があります。

ネットワークアプライアンスや NF には慎重に使う

Outposts servers は、拠点に AWS API で扱える compute を置く用途には向きます。しかし、network appliance や NF 基盤として使う場合は慎重に評価します。

• traffic をどの interface から入れてどこへ戻すのか
• LNI と VPC 側 interface の責任分界は明確か
• throughput、pps、latency、packet size を確認できるか
• 障害時に代替 server へ再作成できるか
• local storage に状態を持たせすぎていないか
• 既存 network policy と AWS 管理モデルが衝突しないか

OCI Dedicated Region との粒度の違い

Outposts と OCI Dedicated Region Cloud@Customer のような選択肢は、同じオンプレミス寄りのクラウドとして並べられることがあります。しかし、粒度は大きく違います。Outposts は AWS の一部 service を顧客拠点へ延長するモデルであり、Dedicated Region 型はより大きな cloud region を顧客拠点へ寄せる考え方です。

比較するときは、場所だけではなく、提供 service の範囲、control plane、責任分界、capacity、network integration、運用体制を分けて見ます。

クラウドの本質から見る

Outposts racks と Outposts servers の違いは、製品サイズの違いだけではありません。クラウドの API、運用モデル、責任分界を、どの粒度でオンプレミスへ持ち込むかの違いです。

racks は拠点基盤としての設計余地が大きく、servers は小規模拠点や edge の local compute として使いやすい一方、network appliance としての自由度を過大評価しないことが重要です。

確認に使う AWS CLI

Outposts の種類や状態を見るときは、site、Outpost、catalog、instance type、local gateway 関連を分けて確認します。

aws outposts list-sites
aws outposts list-outposts
aws outposts list-catalog-items
aws outposts get-outpost --outpost-id op-0123456789abcdef0
aws ec2 describe-local-gateways
aws ec2 describe-instance-types

まとめ

AWS Outposts racks と Outposts servers は、同じ Outposts という名前でも、設計上は別物として評価すべきです。racks は Local Gateway を中心にオンプレミスへ AWS 基盤を延長するモデルで、servers は Local Network Interface を持つ小型 EC2 実行環境として見る方が現実に合います。

特にネットワークアプライアンスや NF 基盤として評価する場合は、Outposts servers を rack 型 Outposts の小型版として見ないことが重要です。AWS API で扱えることと、ネットワーク機器として自由に扱えることは同じではありません。

関連記事

AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界 AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / single-flow と NFV 設計 AWS VPC に L2 はあるのか – VLAN / ARP / VIP をクラウドの到達性モデルへ翻訳する