AWS Outposts

解決する課題

すべてをクラウドへ移せれば理想ですが、現実には拠点側に残したい要件があります。AWS Outposts は、AWS が運用するインフラを自社のデータセンターや工場・店舗に物理的に設置し、リージョンと同じ API・ツール・運用モデルで使えるようにするサービスです。これにより次のような課題に応えます。

• 低レイテンシ: 生産設備や取引システムなど、数ミリ秒の遅延も許されない処理を現地で実行
• データの所在地・主権: 規制や社内ポリシーで、特定データを拠点内に留めたい
• ローカルなデータ処理: 大量データを生成する現場で前処理し、ネットワーク負荷を抑える
• 既存システム連携: オンプレのメインフレームやデータベースと低遅延で接続

主要概念と用語

• Outposts ラック: フルサイズのラック単位で設置する形態。多数のサーバーやストレージを収容する大規模向け
• Outposts サーバー: 1U/2U の単体サーバー形態。支店や店舗など省スペースの拠点向け
• コントロールプレーン: 管理・制御を担う層。Outposts では親となる AWS リージョンに存在する
• データプレーン: 実際にワークロードを実行する層。これがオンプレの Outposts 上で動く
• サービスリンク: Outposts とリージョンを結ぶ暗号化された接続。制御通信が常時行き来する
• ローカルゲートウェイ（LGW）: Outposts ラックとオンプレ・ネットワークを結ぶ経路（ラック形態の概念）
• アンカー: Outposts が紐づく特定の AZ。論理的には親リージョンの一部として扱われる

仕様・制限・クォータ

• 設置には電源・冷却・スペース・ネットワーク帯域などの施設要件を満たす必要がある
• ハードウェアは AWS が所有・保守し、容量はあらかじめ選んだ構成の範囲に限られる
• 利用できるサービスは限定的。一般に EC2 や EBS、一部のコンテナやデータベースなど現地実行が意味を持つものが中心で、フルマネージドな上位サービスはリージョン側に置く
• ラック形態とサーバー形態で利用可能な機能や搭載できるインスタンスタイプが異なる
• 容量を超える需要にはオンデマンドで即時拡張できず、事前のキャパシティ計画が前提
• 具体的な対応リージョン・インスタンスタイプ・上限値は変動するため、設計時に最新情報を確認する

内部の仕組み

Outposts の要点は、コントロールプレーンとデータプレーンの分離にあります。ワークロードを動かすデータプレーンは現地の機材上で動作しますが、その管理・制御は親リージョンのコントロールプレーンが担います。両者はサービスリンクという暗号化トンネルで常時つながっています。

• 利用者はリージョンと同じ AWS コンソール・API・CLI から Outposts 上のリソースを操作する
• Outposts は親リージョンの特定 AZ に論理的にアンカーされ、その延長として扱われる
• ラック形態ではローカルゲートウェイを介してオンプレ・ネットワークと低遅延で通信できる

設計パターン / ベストプラクティス

• 現地でやるべき処理だけを置く: 低遅延・データ所在地が要件のものに絞り、それ以外はリージョンへ
• 回線の冗長化: サービスリンク用のネットワーク経路を複数確保し、制御断を避ける
• キャパシティ計画: 容量は固定なので、ピークを見越して余裕を持った構成を選ぶ
• ハイブリッド前提の構成: バックアップやログ集約、分析はリージョン側のマネージドサービスに集約する
• 高可用性: 単一の Outposts は単一拠点の障害に弱いため、可用性要件が高い場合は複数拠点やリージョン併用を検討

運用・監視

• CloudWatch で Outposts の容量やインスタンスのメトリクスを監視し、容量逼迫を早期に検知
• サービスリンクの接続状態を監視し、制御断を即座に把握する仕組みを用意する
• ハードウェア障害時の交換は AWS が実施するが、設置場所へのアクセス手配は利用者側の責任
• パッチや更新は AWS がリモートで管理するが、施設側の電源・冷却・物理セキュリティは利用者が維持する

コスト

Outposts は使った分だけの従量課金とは性質が異なり、事前に選んだ構成のキャパシティに対する支払いが基本です。EC2 のオンデマンドのように瞬時にゼロまで縮めることはできません。

• 支払い方式は一括前払いや期間契約など複数あり、契約期間にわたってキャパシティ費用が発生する
• 設置・撤去に伴う施設コスト（電源・スペース・回線）は利用者側の負担
• リージョン側で連携するサービスの利用料は別途発生する

具体的な金額や課金体系は変動するため、見積もり時に最新の料金情報で試算してください。

セキュリティ

• 責任共有モデルが拡張される。ハードの保守は AWS だが、設置場所の物理セキュリティは利用者の責任
• サービスリンクは暗号化され、保存データの暗号化（EBS 暗号化や KMS）もリージョンと同様に利用できる
• IAM による最小権限のアクセス制御がリージョンと同じく適用される

Well-Architected の観点

• 信頼性: サービスリンクの冗長化と容量の余裕で、制御断やキャパシティ枯渇に備える
• 運用上の優秀性: リージョンと同一のツール・API で運用を統一し、学習コストと操作ミスを減らす
• セキュリティ: 物理・ネットワーク・IAM の各層で責任範囲を明確にする
• コスト最適化: 現地に置く対象を真に必要なものに絞り、過剰なキャパシティを避ける

試験で問われるポイント

関連サービス・比較

完全オフライン環境やポータブルなエッジ用途では AWS Snow ファミリーと比較されます。

ハンズオン / CLI例

# 自アカウントに割り当てられた Outposts の一覧を確認
aws outposts list-outposts \
  --query "Outposts[].{Name:Name,Id:OutpostId,AZ:AvailabilityZone}"

# 特定 Outpost で利用可能なインスタンスタイプを確認
aws outposts get-outpost-instance-types \
  --outpost-id op-0123456789abcdef0

# Outpost 上に EC2 インスタンスを起動（対象のサブネットを指定）
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=outpost-demo}]'