AWS Outposts でオンプレミスに AWS を拡張 - ハイブリッドクラウドの設計と運用
データレジデンシーや低レイテンシ要件でオンプレミスに AWS を拡張する。Outposts のデプロイモデルとローカルゲートウェイの設計を紹介します。
Outposts のユースケース
Outposts はオンプレミスのデータセンターに AWS のインフラを物理的に設置するサービスです。主なユースケースは 3 つあります。第一に、データレジデンシー要件です。金融規制や政府の要件でデータを特定の国や施設内に保持する必要がある場合、Outposts でデータをオンプレミスに保持しつつ AWS のサービスを利用できます。第二に、低レイテンシ要件です。製造ラインの制御やリアルタイムのデータ処理で、クラウドへの往復レイテンシが許容できない場合に有効です。第三に、ローカルデータ処理です。大量のデータが生成される環境で、データをクラウドに転送する前にローカルで前処理する場合に使用します。具体的な業界例として、工場の製造装置からのセンサーデータをリアルタイムで分析する産業 IoT、MRI や CT スキャンの画像を施設内で処理する医療機関、取引の低レイテンシ処理が求められる金融機関のトレーディングシステムなどがあります。
利用可能なサービスとネットワーク設計
Outposts で利用可能な AWS サービスは EC2、EBS、S3 (Outposts 上の S3)、RDS、ECS、EKS、EMR、ElastiCache などです。これらのサービスはリージョンの AWS と同じ API で操作でき、CloudFormation や Terraform でプロビジョニングできます。ネットワークはサービスリンク接続でリージョンの AWS と通信し、ローカルゲートウェイ (LGW) でオンプレミスネットワークと通信します。サービスリンクは Outposts の管理トラフィック (コントロールプレーン通信、メトリクス送信、ソフトウェアアップデート) とリージョンサービスへのアクセスに使用され、最低 1 Gbps の帯域幅が推奨されます。LGW は VPC 内のサブネットに作成したルートテーブルエントリで制御し、オンプレミスの VLAN とのルーティングを設定します。CoIP (Customer-owned IP) アドレスプールを使えば、オンプレミスのアドレス空間をそのまま Outposts 上のインスタンスに割り当てることができ、既存のファイアウォールルールやアクセス制御を変更せずに済みます。VPC のサブネットを Outposts に拡張する形で構成するため、既存の VPC 設計との統合が容易です。
運用モデルとコスト
Outposts ラックは AWS が設置、保守、ハードウェア交換、ソフトウェアパッチ適用を担当します。顧客はデータセンターの電力、冷却、物理セキュリティ、ネットワーク接続を提供します。料金は 3 年間のサブスクリプションで、全額前払い、一部前払い、前払いなしの 3 つの支払いオプションがあります。EC2 インスタンスや EBS ボリュームの追加料金は発生せず、サブスクリプション料金にコンピュートとストレージのキャパシティが含まれます。Outposts の導入には数週間のリードタイムが必要で、サイトの電力・冷却・ネットワーク要件の事前確認が重要です。ラックの電力要件は構成により 5〜15 kVA 程度で、冷却は前面吸気・背面排気の標準ラック設計に対応している必要があります。物理的な設置スペースとして 42U ラックのフットプリントを確保し、搬入経路の幅と耐荷重も事前に確認します。 Outposts に関する詳しい解説はAmazon の関連書籍でも確認できます。
Outposts と Local Zones の使い分け
Outposts と Local Zones はどちらもエッジでのコンピューティングを提供しますが、運用モデルが根本的に異なります。Local Zones は AWS が運営する小規模データセンターで、顧客の施設ではなく AWS の施設にインフラが置かれます。レイテンシを低減したいが施設内にデータを保持する必要がないワークロード (ゲームサーバー、動画配信のエンコード、エンドユーザーに近い API サーバーなど) に適しています。一方 Outposts は物理的に顧客のデータセンターに設置されるため、データが施設外に出ないことが保証されます。判断基準として、データレジデンシー規制の有無が最も重要です。規制によりデータを施設内に保持する義務がある場合は Outposts 一択です。レイテンシのみが課題で規制要件がない場合は Local Zones のほうが導入が簡素で初期投資も不要です。Wavelength Zones はさらに通信キャリアの基地局内に配置するオプションで、5G ネットワーク上の超低レイテンシに特化しています。
設計上の注意点とサービスリンク断の影響
Outposts 設計で最も重要な考慮事項は、リージョンとの接続 (サービスリンク) が切断された場合の挙動です。サービスリンク断中もローカルで実行中のインスタンスとローカルゲートウェイ経由の通信は継続しますが、新規インスタンスの起動・停止やコントロールプレーン操作 (API コール) は実行できません。つまり断中はワークロードが維持されるものの、スケールアウトやリカバリ操作は不能になります。これを踏まえた設計として、クリティカルなワークロードには十分なキャパシティを事前にプロビジョニングし、Auto Scaling に頼らない静的な構成を検討します。S3 on Outposts のデータはローカルに保持されるためサービスリンク断中もアクセス可能ですが、S3 のコントロールプレーン操作 (バケット作成やポリシー変更) は実行できません。また、Outposts のキャパシティはリージョンと異なり弾力的に拡張できないため、ワークロードのピーク需要を見越したサイジングが必要です。キャパシティが不足した場合は追加ラックの調達に再びリードタイムが発生します。
まとめ
Outposts はオンプレミスに AWS のインフラを拡張し、クラウドと同一の運用モデルでハイブリッド環境を実現するサービスです。EC2、EBS、S3、RDS、ECS などの AWS サービスをオンプレミスで実行し、リージョンと同じ API と管理ツールで操作します。データレジデンシー要件や超低レイテンシ要件に対応しながら、クラウドネイティブな開発体験を維持します。Local Zones との使い分けやサービスリンク断時の影響を理解し、キャパシティの事前計画を行うことが導入成功の鍵です。