AWS 認定資格 ラボ
コンピューティング ・

AWS Outposts とは？オンプレに AWS インフラを設置するハイブリッドサービス完全ガイド

AWS Outposts は AWS のハードウェア（ラック／サーバー）を顧客データセンターに物理設置し、AWS リージョンと同じ EC2 / EBS / S3 / RDS / ECS / EKS を「オンプレで」動かせるフルマネージドハイブリッドサービス。設置から運用・パッチ・故障交換まで AWS が担い、API・CLI・IaC（Terraform/CDK）も統一。低レイテンシ要件・データ主権・規制対応・既存基幹連携といった「クラウドに全部寄せられない理由」がある現場での唯一解になりやすい。本記事では仕組み（Service Link／Anchor／論理 AZ）、ラックとサーバーの 2 形態、対応／非対応サービス、Local Zones / Wavelength / Snow ファミリーとの使い分け、料金構造（3 年契約・容量設計）、運用ベストプラクティスまで一気に整理する。

#AWS #Outposts #ハイブリッドクラウド #エッジコンピューティング #データ主権 #コンピューティング

「クラウドに全部寄せたい、でも法務・物理的レイテンシ・既存基幹システムの都合でどうしてもオンプレを残すしかない」— その狭間で出てくる選択肢が AWS Outposts。AWS のラックを自社 DC に置き、リージョンと同じ API で運用できる「AWS をオンプレに持ち込む」逆転発想のサービスを、選定基準から料金構造まで一気に整理する。

📑 目次

  1. 概要（端的に）
  2. 何ができるか（提供価値）
  3. 仕組み：物理ラック + Service Link + 論理 AZ
  4. Outposts ラック vs Outposts サーバーの 2 形態
  5. 対応サービスと非対応サービス
  6. ハイブリッド系サービスとの使い分け
  7. ユースケース別の選定パターン
  8. メリット・デメリット
  9. 料金構造とコスト設計の勘所
  10. 導入から運用までの流れ
  11. 運用ベストプラクティス
  12. 選定フロー（フローチャート）
  13. 関連用語
  14. 関連サイト
  15. 🎓 試験での出題傾向

1. 概要（端的に）

AWS Outposts は AWS のインフラ（サーバー・ストレージ・ネットワーク機器一式）を物理ラックまたは 1U/2U サーバーの形でオンプレに設置するサービス。リージョンと同じ EC2 / EBS / S3 / RDS / ECS / EKS / ALB を 自社データセンター（DC）やコロケーション施設で動かせる のが本質的な価値である。

設置・運用・パッチ適用・ハードウェア故障時の交換まで AWS 側がフルマネージドで責任を持つため、ユーザーは「クラウドと同じ API・同じ IaC で、ローカルにあるリソースを操作する」だけで済む。マネジメントコンソール・CLI・SDK・Terraform / CDK もそのまま使える。

2. 何ができるか（提供価値）

Outposts が提供する価値は、ざっくり以下の 5 つに整理できる。

  • オンプレで EC2 を起動 — リージョンと同じインスタンスタイプ（m5/c5/r5/g4dn 等）が使える
  • ローカル EBS / S3 — データを Outposts 内部に保存し、リージョンへ出さない構成が可能
  • マネージド DB / コンテナ — RDS（一部エンジン）/ ECS / EKS をローカル稼働
  • AWS API / IaC で統一 — リージョンと同じコード／同じパイプラインでデプロイ
  • AWS による完全運用 — ファームウェア更新・ハードウェア交換・モニタリングを AWS が実施

つまり Outposts は「プライベートクラウド製品を買って自社運用する」ことの対極にあり、“物理的にオンプレに置かれた AWS リージョンの一部” として振る舞う。これが従来のオンプレ仮想化基盤や Azure Stack HCI といった製品との決定的な違いになる。

3. 仕組み：物理ラック + Service Link + 論理 AZ

Outposts は「ハードウェア + AWS リージョンへの常時接続」が必須要件で、両者がセットで初めて成り立つ。

3-1. 主要構成要素

  • Outposts ラック / サーバー — 顧客 DC に設置される物理機器。AWS が独自設計した Nitro System ベースのコンピュート・ストレージ・ネットワーク機器一式
  • Service Link — Outposts と親 AWS リージョンを繋ぐ 暗号化された専用論理接続。Direct Connect / VPN / 専用線経由で確立する
  • Anchor インスタンス — リージョン側に存在する、Outposts の制御プレーンを担う管理ノード（ユーザーから見えない）
  • 論理 AZ（Outpost AZ） — Outposts は AWS の論理構造上「特殊な AZ」として扱われる。サブネットや ALB 等のリソースはこの AZ に紐付ける
  • Local Gateway（LGW / ローカルゲートウェイ） — Outposts と顧客オンプレネットワークを直結する経路。リージョン経由でないトラフィックをここで折り返す

3-2. 動作の流れ

  1. 発注 → 製造 → 設置 — 顧客 DC のサイト調査 → ラック搬入 → 設置（数週間〜数ヶ月）
  2. 電源・空調・物理ネットワーク提供 — 顧客側で 5〜15 kW 級の電源と十分な冷却を用意
  3. Service Link 確立 — 親リージョンへの常時接続を Direct Connect / 専用線で構築
  4. AWS マネコンから操作開始 — 通常の EC2 起動とまったく同じ操作で Outposts 上にリソースを作成
  5. AWS が継続運用 — モニタリング・パッチ・故障部品の現地交換まで AWS が実施

4. Outposts ラック vs Outposts サーバーの 2 形態

導入規模・設置場所に応じて 2 つの形態が選べる。

Outposts ラック vs Outposts サーバー
評価項目
Outposts ラック 推奨
Outposts サーバー
物理サイズ 42U フルラック 1U または 2U の単体サーバー
想定電力 5〜15 kW 級 一般的なサーバーラックの 1 ユニット分
対応サービス EC2 / EBS / S3 / RDS / ECS / EKS / ALB EC2 / EBS / ECS（限定的）
想定設置場所 本社 DC / 大型コロケーション 工場・店舗・ブランチオフィス・船舶
スケーラビリティ ラック単位で増設 サーバー単位で増設
冗長性 ラック内で冗長化済み 単体構成（多重化は顧客側で）
料金感（参考） 月数百万円〜（3 年契約） 月数十万円〜（3 年契約）
ラックは「DC に AWS リージョンを持ち込む」、サーバーは「店舗・工場の片隅にエッジを置く」イメージ

選び方の目安：

  • 本社 DC / 大型コロケーションに置く → ラック（規制対応・データ主権・基幹連携）
  • 店舗 / 工場 / 倉庫 / 船舶に置く → サーバー（オフライン耐性・現場リアルタイム処理）

5. 対応サービスと非対応サービス

Outposts は「リージョンと同じすべてが動く」わけではない。動くものと動かないものを正確に把握しておかないと、設計時に大事故になる。

5-1. Outposts 上でローカル動作するサービス

  • コンピュート — EC2（多くのインスタンスタイプ）/ ECS / EKS / Lambda（一部リージョンの一部機能）
  • ストレージ — EBS gp2 / S3 on Outposts
  • DB — RDS（MySQL / PostgreSQL — 限定的）
  • ネットワーク — VPC / Subnet / Security Group / Route Table / ALB（Application Load Balancer）

5-2. リージョン側のみ・Outposts 内では動かないサービス

  • グローバルサービス — Route 53 / CloudFront / IAM / Organizations
  • 多くのマネージドサービス — DynamoDB / SQS / SNS / Lambda の多くの機能 / Step Functions / EventBridge 等
  • 大半の分析・AI サービス — Athena / Redshift / SageMaker（注：エッジ推論は別途オプションあり）

6. ハイブリッド系サービスとの使い分け

AWS には Outposts 以外にも「オンプレ／エッジに AWS を持ち込む」系サービスが複数あり、しばしば試験・現場で混同される。「誰の場所に・どんなレイテンシで・どの規模のサービスを動かしたいか」 で切り分ける。

Outposts vs Local Zones vs Wavelength vs Snow Family
評価項目
Outposts
Local Zones
Wavelength
Snowball Edge
設置場所 顧客 DC 主要都市の AWS エッジ 通信事業者の 5G 拠点 顧客拠点（一時持込）
所有者 顧客 AWS 通信事業者 顧客（リース）
常時オンライン 必須 必須 必須 不要（オフライン可）
主用途 データ主権・低遅延 都市部の超低遅延 モバイル超低遅延 データ移行・現場処理
対応サービス幅 広い 中 限定的 限定的（EC2 中心）
コスト感 超高（3 年契約） リージョンと同じ従量 リージョンと同じ従量 中（時間／月単位レンタル）
「自社の場所にずっと置く」のが Outposts、「AWS / 通信事業者の場所を借りる」のが Local Zones / Wavelength、「現場に一時的に持ち込む」のが Snow

7. ユースケース別の選定パターン

実案件で Outposts が刺さる典型シーンを 5 つ整理する。

ユースケース 1：金融・公共のデータ主権要件

個人情報・取引データを 国外リージョンや自社 DC 外に出せない 銀行・保険・自治体システム。リージョン側 API を使いたいが物理データはローカル必須、というケース。

ユースケース 2：工場・医療など低レイテンシ要件

製造ラインの制御・医療画像処理・自動運転シミュレーションなど、1〜数ミリ秒以内の応答 が必要なワークロード。リージョン往復（10〜数十 ms）では到底間に合わない。

ユースケース 3：レガシー基幹システムとの密結合

メインフレームや既存 ERP と L2 / L3 で直結 する新サービスを AWS 流で開発したいケース。基幹側を動かせない代わりに AWS 流の周辺システムを 物理的に隣 に置く。

ユースケース 4：帯域制約のある拠点

衛星回線・離島・海底ケーブル容量に制約がある拠点で、リージョン往復を最小化 したい場合。ローカル処理 → 結果のみ広域回線で送る構成。

ユースケース 5：店舗・倉庫・船舶のエッジ拠点

リテール POS データのリアルタイム集計、倉庫の RFID 在庫管理、外洋船舶での AI 推論など、オフライン耐性 + AWS エコシステム を両立したい場面（多くは Outposts サーバー）。

8. メリット・デメリット

9. 料金構造とコスト設計の勘所

Outposts は AWS の中で最も独特な料金体系 を持つ。リージョンと同じ「使った分だけ」の従量課金 ではない。

9-1. 料金の組み立て

  • 3 年契約のキャパシティ料金 — ラックに搭載する CPU / メモリ / ストレージの総容量を選び、3 年分まとめて支払い（または月次分割）
  • データ転送料金 — Outposts ⇔ 親リージョン間の通信料金（Service Link 経由）
  • 特定マネージドサービスの追加料金 — Outposts 上の RDS / EKS など、リージョンと別建ての料金体系を持つものがある
  • 物理側コスト（自社負担） — 電源・空調・物理スペース・ラックネットワーク機器

9-2. コスト最適化のポイント

  • キャパシティ計画は厳密に — 3 年契約のため後から増やすと割高。ピーク時負荷の 70〜80% で見積もり、残りはリージョン側にバースト
  • データ転送料金を抑える — ローカルで処理してからリージョンへ送り、Service Link を「制御チャネルとサマリだけ」に絞る
  • 不要時は止める — 開発・検証用インスタンスは夜間・休日に停止して EBS 課金だけにする

10. 導入から運用までの流れ

導入は他の AWS サービスと比較して 格段に長期 になる。

  1. 要件整理 — レイテンシ・データ主権・対応サービス・将来計画
  2. サイト調査（Site Survey） — AWS スタッフが現地で電源・空調・床荷重・物理ネットワーク・搬入経路を確認
  3. 発注・契約締結 — 3 年契約。容量・構成・配送先を確定
  4. 製造・配送（数週間〜数ヶ月） — AWS 工場で組み立て → 顧客 DC へ搬入
  5. 設置・配線 — AWS スタッフが現地で物理設置・電源接続・初期構成
  6. Service Link 確立 — Direct Connect / 専用線経由でリージョンと接続
  7. 論理リソース作成 — Outpost AZ にサブネットを作り、EC2 等をデプロイ
  8. 継続運用 — AWS がパッチ・故障交換、顧客はワークロード運用
  9. 3 年後 — 契約更新（新世代 HW へ入替）or 撤去

11. 運用ベストプラクティス

  • 冗長な Service Link を必ず確保 — Direct Connect を 2 本以上、可能なら 2 拠点接続
  • ローカル AZ にしか作れないリソースを把握 — 例：Outposts 上の EBS は そのラック内でしか使えない ため、可用性設計は本物の Multi-AZ にならない点に注意
  • モニタリング集約 — CloudWatch メトリクス・ログは親リージョンへ集約。Outposts 単体での監視ダッシュボードを別途持たない
  • 障害時の運用フロー文書化 — Service Link 断、Outposts ハードウェア故障、AWS スタッフ現地対応の各シナリオを RUNBOOK 化
  • コスト棚卸しを四半期ごと — 容量利用率・データ転送量・夜間停止運用の効果を継続レビュー
  • 撤去計画を初日から検討 — 3 年後の出口（更新 / リージョンへ移行 / 別ベンダー）を意思決定する材料を最初から残す

12. 選定フロー（フローチャート）

[Q1] ミリ秒〜数 ms のレイテンシが必須？
  └ NO → リージョン or Local Zones 等で十分。Outposts は不要
  └ YES ↓

[Q2] データを顧客 DC / 国内に留める法的・契約要件がある？
  └ NO → Local Zones / Wavelength を先に検討（運用負荷が小さい）
  └ YES ↓

[Q3] 既存オンプレ基幹システムとの L2 / L3 直結が必要？
  └ NO → Local Zones で要件を満たせるか再評価
  └ YES ↓

[Q4] 3 年契約・初期コスト数千万円〜 を稟議できる予算規模？
  └ NO → Snow Family / 部分的にオンプレ + リージョン構成を検討
  └ YES ↓

[Q5] 設置場所は本社 DC / 大型コロケーション？
  └ YES → Outposts ラック
  └ NO（工場 / 店舗 / 倉庫 / 船舶） → Outposts サーバー

13. 関連用語

  • EC2 — Outposts 上で起動できる主要コンピュート
  • EBS / S3 — Outposts のローカルストレージとして提供
  • ECS / EKS — Outposts 上で動くコンテナオーケストレーション
  • Direct-Connect / VPN — Service Link 用の広域接続
  • Local-Zones — AWS が運営する都市部エッジ
  • Wavelength — 5G キャリア網に設置されたエッジ
  • Route 53 / CloudFront — Outposts では動かないグローバルサービス例

14. 関連サイト

AWS 公式

参考

🎓 試験での出題傾向

試験重要度主な出題パターン
CLF低「ハイブリッドクラウドの選択肢として Outposts を挙げる」レベル
SAA中「データ主権 × 低レイテンシ → Outposts」「オンプレ + AWS の統合管理」「Local Zones / Wavelength との切り分け」
DVA低出題はほぼなし。API 統一性が問われる程度
SOA中Service Link 障害時の挙動、モニタリング集約、容量計画とコスト管理

頻出キーワード：データ主権 / 低レイテンシ / ハイブリッド / Service Link / Local Gateway / 論理 AZ