AWS Outposts によるハイブリッドクラウド - オンプレミスへの AWS 拡張
ラック型とサーバー型の選択基準を整理し、オンプレミスで EC2・ECS・RDS を実行するハイブリッドクラウドの設計を紹介します。
Outposts の形態と対応サービス
Outposts Rack は AWS が設計した 42U ラックをオンプレミスのデータセンターに設置する形態です。EC2 インスタンス、EBS ボリューム、S3 on Outposts、RDS、ECS、EKS などの AWS サービスをオンプレミスで実行できます。AWS がハードウェアの設置、保守、ソフトウェアの更新を担当します。Outposts Servers は 1U または 2U のサーバー単位で提供され、小売店舗、工場、病院などの小規模拠点に AWS コンピュートを配置するユースケースに適しています。EC2 と EBS のサブセットが利用可能です。
ネットワーク接続と運用
Outposts は親リージョンとのサービスリンク接続を必要とし、Direct Connect または VPN で接続します。コントロールプレーン (インスタンスの起動・停止、CloudWatch メトリクス送信など) はリージョン経由で管理されるため、サービスリンクの可用性が重要です。ローカルゲートウェイ (LGW) はオンプレミスネットワークと Outposts サブネット間のルーティングを制御し、オンプレミスのアプリケーションから Outposts 上のリソースにアクセスする経路を提供します。Outposts の VPC サブネットはリージョンの VPC を拡張する形で作成され、リージョンのサブネットと同じ VPC 内で通信できます。
ローカルゲートウェイとデータレジデンシー
ローカルゲートウェイ (LGW) は Outposts とオンプレミスネットワーク間のルーティングを制御します。 LGW のルートテーブルで、オンプレミスの CIDR ブロックへのルートを定義し、 Outposts 上の EC2 インスタンスとオンプレミスシステム間の通信を確立します。 CoIP (Customer-Owned IP) プールを使うと、既存のオンプレミス IP アドレス体系を Outposts 上のインスタンスに割り当てでき、ファイアウォールルールの変更を最小化できます。データレジデンシー要件では、 S3 on Outposts でデータをオンプレミスに保持しつつ、 S3 API で操作できます。 EBS のローカルスナップショットで Outposts 上にバックアップを保持し、データが AWS リージョンに転送されない構成を実現します。 ハイブリッドに関する詳しい解説はAmazon の関連書籍でも確認できます。
Outposts のコスト構造
Outposts は 3 年間のサブスクリプションで、全額前払い、一部前払い、前払いなしの支払いオプションがあります。ラック型は EC2 と EBS のキャパシティを含む月額固定料金で、リージョンの同等リソースと同じ単価が適用されます。サーバー型 (1U/2U) は小規模なエッジ環境向けで、ラック型より低コストで導入できます。電力、冷却、物理セキュリティ、ネットワーク接続はユーザー側の負担です。サービスリンク接続の帯域幅要件 (最低 1 Gbps、推奨 10 Gbps) を満たす Direct Connect または VPN の費用も考慮が必要です。Outposts 上のリソース使用率を CloudWatch で監視し、キャパシティの過不足を定期的に評価します。
採用が向く場面
Outposts が選ばれるのは、クラウドの利便性とオンプレミスの必要性を両立させたい場合です。工場の生産設備や店舗のシステムなど、現地の機器と低遅延で通信する必要があるワークロードでは、データセンターが遠いクラウドだけでは要件を満たせません。法規制やポリシーでデータを特定の場所に置く必要がある場合も、Outposts なら手元に AWS の環境を持てます。大量のデータを現地で処理し、結果だけをクラウドへ送る構成にも適します。クラウドへの全面移行が難しい事情がある中で、AWS の運用体験を現地で得たい、というニーズに応えます。
容量計画とキャパシティ管理
Outposts は手元に設置する物理的な機器であるため、容量は有限です。クラウドのように無制限に拡張できるわけではないので、稼働させるワークロードに見合った構成をあらかじめ見積もって発注します。運用開始後は、コンピュートやストレージの使用状況を監視し、容量が逼迫していないかを継続的に確認します。割り当てを調整して、限られたリソースを効率よく使います。需要の増加が見込まれる場合は、早めに増設を計画します。クラウドの感覚で青天井に使うのではなく、物理的な制約を前提にした容量管理が、Outposts を安定運用する要点になります。
可用性と接続障害時の挙動
Outposts は AWS リージョンと専用の接続を通じて管理されます。この接続が途切れると、新しいリソースの作成や管理操作はできなくなりますが、すでに稼働している多くのワークロードは現地で動作を継続します。現場の業務が、リージョンとの通信状況に過度に依存しないよう、ローカルで完結できる設計にしておくことが重要です。重要なシステムは Outposts 内で冗長化し、単一障害点を避けます。接続が回復したときに、クラウド側と整合が取れるよう、データの同期方針も定めておきます。障害時にどこまで動き続けられるかを理解した設計が求められます。
運用と更新
Outposts の物理的な保守やソフトウェアの更新は AWS が担うため、利用者はハードウェアの管理から解放されます。一方で、現地に設置されているという性質上、電源やネットワークなど、設置環境の条件は利用者側で整える必要があります。リソースの監視やデプロイは、クラウドの AWS と同じ操作体系で行えるため、運用チームは慣れた手順をそのまま使えます。リージョン上のサービスと連携させ、バックアップや監視を統合的に管理することも可能です。オンプレミスにありながらクラウドと同じ運用ができる点が、ハイブリッド環境の管理負荷を下げる利点になります。
まとめ
Outposts はオンプレミスに AWS のインフラとサービスを拡張し、データレジデンシーやレイテンシ要件に対応します。ローカルゲートウェイでオンプレミスネットワークとの接続を制御し、S3 on Outposts でデータをオンプレミスに保持しつつ S3 API で操作できます。ラック型とサーバー型の選択で、データセンターからエッジ環境まで幅広い規模に対応します。