AWS Outposts入門｜オンプレデータセンターにAWSを持ち込むハイブリッドクラウド設計と料金ガイド

「クラウド移行したいが、レイテンシーや規制の壁でどうしても一部のシステムを社内に残さざるを得ない」——そんな悩みを抱えるインフラエンジニアは少なくありません。AWSをフル活用しながら、特定のワークロードはオンプレミスに置き続けなければならない、という制約はよく聞く話です。

そこで選択肢に入るのが AWS Outposts です。AWSのハードウェアを自社データセンターに設置し、AWS本体と同じAPIや管理ツールでそのまま使えるハイブリッドクラウド基盤です。「クラウド化できない」と諦めていた領域にも、AWSの体験をそのまま持ち込めます。

この記事では、AWS Outpostsの仕組み・フォームファクターの選び方・ネットワーク設計・対応サービス・料金体系・よくあるハマりポイントまでを、オンプレ経験者の視点で体系的に解説します。

AWS Outpostsとは？クラウドをオンプレに”延伸”する仕組み

AWS Outpostsは、AWSが物理ラックやサーバー機器をお客様のデータセンターに搬入・設置し、AWSクラウドと同一のインフラ・API・サービスをオンプレミスで提供するフルマネージドサービスです（2026年時点）。

オンプレ経験者が特に注目すべき点は次のとおりです。

・ハードウェアはAWS所有: ラックや機器はAWSの資産です。お客様はスペース・電力・冷却・ネットワークを用意するだけで、機器の調達・保守・障害対応はAWSが担います。
・APIはクラウドと同じ: EC2のインスタンス起動、EBSのボリューム操作、コンソール操作まで、AWSリージョンと同一のAPIが使えます。運用スクリプトやIaCコードをそのまま流用できます。
・管理はAWSコンソールから: オンプレミスに設置されていても、管理はAWSマネジメントコンソールから一元的に行います。オンプレ側に専用の管理ツールを用意する必要はありません。

「クラウドの外にある、もう一つのAWSリージョンの出張所」とイメージすると掴みやすいでしょう。

なお、パブリッククラウドとプライベートクラウドの使い分け方針については、パブリッククラウド vs プライベートクラウド vs ハイブリッドクラウドの選び方ガイドも合わせて参照してください。

2つのフォームファクター：RackとServers

AWS Outpostsには大きく2種類のフォームファクターがあります。

1. Outposts Rack（42Uフルラック）

データセンター規模の大型導入向けです。AWSが42Uのフルラックを搬入します。

・電力要件: 高電圧（200V系）回路と十分なアンペア数が必要
・空調要件: ラック1台分の熱排出に対応できるフロア設計が必要
・収容容量: EC2インスタンス、EBS、さらにはS3 on Outpostsも搭載可能なモデルが選択可能
・向いている用途: 大規模データ処理、データレジデンシー要件の厳しいシステム、複数サービスを組み合わせた本格的なハイブリッド構成

2. Outposts Servers（1U / 2U）

工場の現場・小規模拠点・エッジロケーション向けの小型フォームファクターです。

・設置スペース: 1Uまたは2Uのラックマウント。スタンドアロン設置も可
・電力要件: 標準的な100V/200Vコンセントで動作
・収容容量: EC2とEBSのみ対応（S3 on OutpostsはRackのみ）
・向いている用途: 工場の生産ラインそば、店舗バックヤード、病院施設内など「データセンター規模の設備がない場所」

現場でよく迷うのは「小さな拠点にRackは過剰か？」という点ですが、将来的な拡張要件と運用コストを見据えて選定するのが基本です。将来S3 on Outpostsが必要になる可能性があるならRack一択です。

動作原理とネットワーク設計

AWS Outpostsが動作するためには、2つの重要な接続を理解しておく必要があります。

Service Link（サービスリンク）

Outpostsからホームリージョン（例: 東京リージョン ap-northeast-1）に向けて張る、アウトバウンドのHTTPS/TLS接続です。

・マネジメントプレーン（コントロールプレーン）の通信に使われます
・インスタンス管理・AMI配信・API呼び出しの受け渡しなどがここを通ります
・接続方式: AWS Direct ConnectまたはインターネットVPN。安定した帯域が必要なため、レイテンシーが安定しない低品質な回線は避けてください
・Service Linkが切れても既存インスタンスは継続稼働しますが、新規インスタンスの起動やAPI操作ができなくなります

オンプレとAWSの接続方式の詳細は、AWS Direct Connect vs Site-to-Site VPNの比較ガイドも参考にしてください。

Local Gateway（ローカルゲートウェイ）

Outposts上のEC2インスタンスとオンプレミスの既存ネットワーク（社内LAN・業務システム・オンプレDBなど）を繋ぐ接続です。

・VPCの延長として機能し、Outposts内のサブネットを社内IPアドレス空間と直接通信可能にします
・本番環境の業務システムやデータベースをオンプレに置いたまま、Outposts上のアプリから1ms未満のレイテンシーでアクセスできます
・BGPルーティングで経路情報を交換するため、既存のルーター設定に組み込むことができます

設計上のポイント: Service LinkとLocal Gatewayは用途が全く異なります。前者はAWSコントロールプレーンへの経路、後者はオンプレ社内ネットワークへの経路です。混同すると設計が崩れるため、最初に明確に分離して整理してください。

Outpostsで利用できる主なAWSサービス（2026年時点）

注意点として、サービスの追加や制約は随時更新されます。実際の導入前にAWSの公式ドキュメントで最新情報を確認することを推奨します。

主な3つのユースケース

1. 低レイテンシーが必要な業務系システム

製造業の生産ラインを制御するSCADA/MESシステム、金融の超低遅延取引システム、病院の画像診断AIなど、「クラウド往復の数十msすら許容できない」用途が典型例です。

Outpostsを使えば、EC2インスタンスとオンプレの制御機器が同一ネットワーク内に存在するため、往復レイテンシーを1ms未満に抑えることができます。クラウドのAPIや認証基盤はそのまま使えるため、開発・運用のやり方を変えずに低レイテンシーを実現できる点が大きな差別化です。

2. データレジデンシー（保存場所規制）への対応

金融規制、医療情報保護法（HIPAA）、GDPR、国内の業界ガイドラインなどにより「特定のデータを国内または自社設備内に保管しなければならない」というケースがあります。

S3 on Outpostsを使えば、データはAWSリージョンに転送されずOutpostsのラック内だけに保存されます。S3の標準APIをそのまま使いながら、物理的なデータ所在を自社設備内に限定できるのは、規制対応の観点で非常に強力なオプションです。

3. クラウド移行の「テスト場」として段階的に活用する

一気にリージョンへ移行することへの抵抗感が強い組織では、まずOutpostsをオンプレに設置し、「AWSの環境で動くことを確認しながら移行を進める」段階を踏むことができます。

アプリケーションをそのままEC2に載せ、問題がなければ次のフェーズでリージョンにLift & Shiftする——という段階的な移行シナリオに適しています。ITILやISMSの変更管理プロセスが厳格な組織でも、この段階論が受け入れられやすい傾向があります。

料金の考え方（2026年時点）

AWS Outpostsの料金は、クラウドサービスとは異なる仕組みです。

容量予約型の料金モデルが基本です。特定のEC2インスタンス構成（インスタンスタイプとその台数）をまとめたパッケージ（「Outpost設定」と呼ぶ）を、1年または3年の期間でコミットします。

・初期費用: 設置・設定費用（インフラ搬入に伴う実費）
・月額料金: 確保した容量に対して毎月定額で発生。インスタンスの起動・停止にかかわらず課金されます
・追加費用: データ転送費、S3 on Outpostsは容量に応じた別途料金
・3年コミットの割引: 1年より大幅に割引されます（AWS Reservedと同様の考え方）

オンプレと比較した場合のコスト感: 自前でサーバーを購入・保守する場合に比べると、ハードウェア保守コストやエンジニア工数を含めたTCO（総所有コスト）では競争力がある場合があります。ただし、CapEx（資本支出）ではなくOpEx（運用支出）への転換という側面も考慮に入れてください。TCOの詳しい考え方はCapExとOpExの違いとTCO計算ガイドを参照してください。

料金の見積もりはAWS担当者を通じて行うのが一般的です。Outposts専用のオンラインPrice Calculatorが用意されており、インスタンスファミリー・構成・利用期間を入力して概算が出せます。

設計上の注意点とよくあるハマりポイント

Outpostsを導入するプロジェクトでよく挙がる落とし穴を整理します。

① Service Linkの品質が全体の信頼性を左右する
既述のとおり、Service LinkはAWSコントロールプレーンへの経路です。インターネット経由の場合、帯域不足や遅延スパイクが起きると、インスタンスの起動・停止・オートスケーリング応答などに影響します。本番利用にはAWS Direct Connectの使用を強く推奨します。

② VPC CIDRとオンプレIPアドレスの重複
OutpostsはVPCの延長として機能するため、VPCのCIDRブロックがオンプレの既存IPアドレス帯と重複すると通信が成立しません。導入前に自社のIPアドレス管理台帳を棚卸しし、重複のないCIDRを設計してください。AWS VPC CIDRブロック設計ガイドも参照してください。

③ AMI（マシンイメージ）の同期
Outpostsで使うAMIはホームリージョンから配信されます。Service Linkが切断した状態では新しいAMIを取り込めないため、あらかじめ必要なAMIをOutpostsにキャッシュしておく設計が必要です。

④ EKS on Outpostsのモード選択
EKSには「接続クラスター（コントロールプレーンをリージョンに置く）」と「ローカルクラスター（コントロールプレーンもOutpostsに置く）」の2つのモードがあります。Service Link断絶時もKubernetesの制御を継続したい場合はローカルクラスターを選ぶ必要があります。運用の複雑さも増すため、要件に応じて慎重に選定してください。

⑤ スケーラビリティの限界を意識する
クラウドリージョンと異なり、Outpostsの容量は物理ラックの収容能力に上限があります。急激なトラフィック増加に対してAutoScalingでスケールアウトするとすぐに容量上限に達します。ピーク想定のキャパシティプランニングを十分に行い、オーバーフロー分はリージョン側にバーストできるアーキテクチャを検討してください。

本記事のまとめ

AWS Outpostsは「すべてをクラウドに移せない」現実的な制約に応えるハイブリッドソリューションです。主なポイントをまとめます。

・フォームファクターはRackとServersの2種類。S3 on OutpostsやRDSが必要ならRack必須
・Service Link（AWSコントロールプレーンへの接続）とLocal Gateway（社内LAN接続）の役割を明確に分けて設計する
・主なユースケースは「低レイテンシー」「データレジデンシー規制対応」「段階的移行の橋頭堡」の3つ
・料金は容量予約型。1年または3年コミットで月額定額払い
・導入前にService Linkの品質・VPC CIDRの重複・AMIキャッシュ・容量上限を必ず確認する

「クラウドに行けない理由」を一つひとつ潰していくためのピースとして、Outpostsは非常に有効な選択肢です。特にレイテンシーと規制の両方を抱えているプロジェクトでは、真っ先に検討リストに入れる価値があります。