re:Invent 2025: AWS Hybrid and Edgeサービスによるデジタルソブリンティとデータレジデンシー
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Digital sovereignty and data residency w/ AWS Hybrid and Edge services (HMC310)
この動画では、AWS Hybrid and Edge servicesを活用したデジタルソブリンティの実現方法について解説しています。Ben LavasaniとMallory Gershenfeldが、データレジデンシー、オペレータアクセス制限、運用上の独立性といったソブリンティの要件に対応するため、AWS Local Zones、Dedicated Local Zones、AWS Outpostsなどのサービスを紹介します。Nitroシステムによる暗号化とセキュリティ、AWS Control Towerを使った大規模なガバナンス実装、S3 on Outpostsでのローカルレプリケーション、CloudTrailやCloudWatchによる監査機能など、具体的な実装方法が詳述されています。サウジアラビアのGeidea社の事例を通じて、厳格な規制環境下でのクラウド活用の実践例も紹介されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
デジタルソブリンティの重要性とセッション概要
こんにちは、皆さん、お疲れ様です。ヘッドセットをつけてください。そうすれば私の声が聞こえますよ。私の声が聞こえたら、親指を立ててもらえますか？クリアに聞こえています、素晴らしい。本日はご参加いただきありがとうございます。皆さんがここにいてくれて、本当に嬉しいです。
明日目覚めたら、自分たちの組織の重要なデータが、同意したことのない法律の対象になっていることに気づいた、そんなことを想像してみてください。これは仮定の話ではなく、今日、相互に接続されたデジタル世界において、多くの組織が直面している現実です。だからこそ、デジタルソブリンティは、クラウドコンピューティングにおいて最も重要な議論の一つになっているのです。
実際、82%の企業がソブリン・ソリューションの導入を検討しています。これは、組織がクラウドの変革的な力と、自分たちのデータに対する完全なコントロールを維持する能力の両方を必要としているという、根本的な真実に対応しているのです。しかし、デジタルソブリンティは単にデータがどこに存在するかについてだけではありません。誰がそれにアクセスできるのか、どのように処理されるのか、そしてクラウドのペースで革新を続けながら運用上の自律性を維持することについてなのです。
ヨーロッパの GDPR 標準から業界固有の規制まで、要件は日々強化されています。ですから、本日は、私の友人の Mallory と一緒に、AWS Hybrid and Edge services がどのようにしてソブリンティを維持しながら革新を犠牲にしないようにできるかをお見せします。AWS の全力を活用しながら、データの場所、アクセス、処理に対する絶対的なコントロールを保つことができる実践的なソリューションを探っていきます。
私の名前は Ben Lavasani です。AWS Hybrid Cloud のシニア Go-To-Market Specialist をしています。さあ、始めましょう。まず、デジタルソブリンティと規制上の課題についてもう少し詳しくお話しして、その後、ハイブリッドおよびエッジサービスをいくつかご紹介します。
本日は、サウジアラビアを拠点とする Geidea の顧客を代表してお話しさせていただきます。その後、Mallory Gershenfeld にバトンタッチして、エッジでの構築に関する具体的な実装のベストプラクティスとコントロールについて、さらに詳しく説明してもらいます。
デジタルソブリンティの定義と企業が直面する規制・運用上の課題
デジタルソブリンティは、組織がデジタルフットプリント、データ操作、およびテクノロジースタックに対して完全なコントロールを維持する能力を表しています。この広いトピックの中には2つの概念があります。まず1つ目は、左側の柱であるデータソブリンティです。その中では、データレジデンシーを考慮する必要があります。これはデータが保存および処理される場所の地理的なコントロール、そしてデプロイしている管轄区域内のローカルデータ保護法および規制への準拠です。
また、オペレータアクセス制限についても考える必要があります。これは、誰がデータとシステムにアクセスできるかについての細粒度のコントロール、ロールベースのアクセスコントロールポリシーの実装、監査ログ、および暗号化などのことです。これらすべてがこの柱の中で考慮される必要があります。右側では、オペレーショナルソブリンティについて考えると、システムは復旧力があり、障害や災害に耐える必要があります。重要なシステムの冗長性、そしてデプロイメント内の単一障害点から保護されていることを確認するための災害復旧ソリューションも必要です。
最後に、独立性と透明性があります。テクノロジースタックとその中の依存関係に対する明確な可視性は本当に重要です。システムを独立して保守および変更する能力も非常に重要です。AWS では、顧客がデジタルソブリンティに関してどのような課題を抱えており、市場での準拠を試みているのかについて、より深く理解するために顧客と密接に協力してきました。
特にコンプライアンスに関しては、規制環境は常に進化しています。新しい法律と要件が世界中で出現しており、組織は GDPR などの複雑なクロスボーダーデータ転送制限に対応する必要があります。それに加えて、考慮する必要のある業界固有の規制も多くあります。テレコム、ヘルスケア、金融サービスなどの規制対象業界にいるかどうかにかかわらず、その市場でその特定の規制に準拠する方法についての非常に複雑なランドスケープがあることが多く、それが多くの複雑性を生み出しています。
次に、セキュリティはもう一つの課題です。お客様は堅牢なセキュリティとデータアクセス制御の実装と、ユーザビリティの維持のバランスを取る必要があります。非常にセキュアなシステムを構築することは良いことですが、誰もそれを利用できず、生産性を上げられないのであれば、時間の無駄になる可能性があります。
さらに、暗号化標準がますます複雑になってきており、それに関連した課題もあります。監査ログとモニタリングもこのカテゴリに入ります。アクセスをどのようにチェックし、環境内で何が起こっているかをモニタリングするのか、ということです。最後に、運用上の課題も見られます。IT環境全体で一貫した管理を維持することは非常に難しいことがあります。オンプレミスで実行しているか、クラウドで実行しているか、あるいはニアエッジのどこかで実行しているかに関わらずです。特にワークロードが世界中の異なる市場に広く分散している場合、これは特に課題になる可能性があります。
もちろん、ビジネス継続性を確保しながら、主権も保持する必要があります。一部の市場では、すべてのデータをローカルに保存する必要があるという状況が見られます。プライマリコピーはローカルにあり、バックアップは国外のリージョンにあるというケースもあります。あるいはポリシーがなく、より自由度が高い場合もあります。このような状況を運用面で把握することは、お客様にとって非常に難しいことがあります。ですから AWS では、クラウドを必要な場所に持ってくることができるサービスの継続体を構築するよう努力してきました。
AWSハイブリッドインフラストラクチャの継続体とGartnerによる評価
その考え方は、リージョンで実行しているか、遠くのエッジまで実行しているかに関わらず、同じインフラストラクチャ、サービス、API、ツールを提供することで、一貫した開発者体験を実現できるということです。すべては region から始まり、私たちは引き続き region を革新し、構築していきます。また、発表されている European Sovereign Cloud のような新しい region も構築していきます。しかし、一部のお客様はより近い場所が必要で、ワークロードをより近くで実行する必要があります。ですから、私たちは local zones と CloudFront を拡張して、エッジロケーションと世界中の新しいメトロを提供しています。そして、Outposts のようなサービスで AWS サービスをオンプレミスに持ってくることができます。さらに遠いエッジでは IoT サービス、EKS、ECS Anywhere を使用できます。その考え方は、クラウドで実行しているか、エッジで実行しているかに関わらず、非常に一貫した方法で AWS の生産性を活用できるようにしたいということです。
このアプローチは第三者からも高く評価されています。Gartner の 2025 Magic Quadrant レポートで、AWS がエッジコンピューティング、コンテナデプロイメント、AI ワークロードの重要なユースケースにおいて、分散ハイブリッドインフラストラクチャのリーダーとして認識されたことをお知らせできて、本当に嬉しいです。Gartner からのこの認識は、お客様の進化するニーズに対応する包括的なハイブリッドインフラストラクチャを提供するという私たちのコミットメントを本当に検証してくれています。
AWS Local ZonesとOutpostsによるエッジコンピューティングの実現
では、具体的なサービスをいくつか見てみましょう。いくつか触れましたが、今日はそのうちのいくつかについて詳しく説明します。AWS Local Zones は、AWS が大都市圏に構築・運営しているインフラストラクチャです。例えば、ここラスベガスにもあり、Oregon リージョンをこの都市に拡張しています。 Local Zones を使えば、オンデマンドの弾力的なサービスに従量課金制でアクセスできます。これは、今クラウドで既に使い慣れているのと同じ方法で、同じ開発者体験で行うことができます。EC2 のようなサービスが利用可能で、リージョンで EC2 上のワークロードを実行している場合、ラスベガスにデプロイするときの体験はまったく同じです。
これは私たちのバックボーンを通じてリージョンのサービスと統合されているため、ハイブリッドワークロードも実行できます。ワークロードの特定の部分をリージョンの 1 つにプッシュしたい場合があります。多くのお客様がそうしています。ここは Local Zones ローンチの状況を示すレイアウトです。 私たちは米国から始まり、マップ上の紫色のすべての場所は既に一般提供されています。白色のすべてのものは発表済みで計画中です。また、ヨーロッパ、中東、アフリカ、アジア太平洋、オーストラリア、ニュージーランド、南米にも拡大しました。今、私たちは皆さんからのフィードバックを聞きたいと思っています。データソブリンティやデジタルソブリンティの観点から関心のある特定の場所があれば、私たちはそれについて学び、それらの場所でお客様をサポートできるかどうかを確認することに非常に興奮しています。
Dedicated Local Zones は、私が触れたもう 1 つのサービスです。 これはより厳格なソブリンティ要件を持つ組織向けです。私たちは Dedicated Local Zone、つまり DLZ を提供することができます。これらはお客様または顧客コミュニティの排他的な使用のために構築され、お客様が指定したデータセンターに配置されます。それはお客様自身の場所または地元の AWS データセンターかもしれません。それはそのお客様の特定の使用のために専用です。その特定のソブリン領土に位置する AWS 担当者によって運営されることさえ可能です。
Dedicated Local Zones には多テナント機能が組み込まれているため、例えば地方自治体が複数の機関またはエンティティを持っている場合、同じ共通の専用インフラストラクチャを共有したいが、それらの間に多テナント性とセグメンテーションのレベルを持ちたいということがあります。このようなことは DLZ 環境で可能です。Dedicated Local Zones を使えば、機密ワークロードを専用クラウドインフラストラクチャに分離できます。フォールトトレランスを構築し、複数の場所を持つことが可能で、最終的には運用の複雑さを軽減し、イノベーションの速度を向上させることができます。私たちはお客様に代わってこのインフラストラクチャの管理を行い、ソブリンワークロードをローカルにデプロイできます。
3 番目に触れたいサービスは AWS Outposts で、これはオンプレミスの AWS Cloud の拡張です。この場合、お客様のデータセンターまたはローカルコロケーション環境でこれを実行でき、クラウドをオンプレミス環境に拡張して、一貫した体験を提供できます。リージョン、Local Zone、Dedicated Local Zone、または Outpost で運営しているかどうかに関わらず、単一の管理ペインがあります。Outposts を使えば、実質的にはリージョン内の容量プールが専用で、異なる識別子を持っています。
Outposts ファミリーの中には、ラックと Outpost サーバーの両方があります。Outpost ラックは 42U のデータセンターラックで、同じサービスと API をオンプレミスにもたらします。EC2、EKS、EBS、S3、RDS といった多くのコアサービスが、すべて Outpost でローカルに利用可能です。ラックが 1 つ見えるかもしれませんが、それが 1 つのラックだけに限定されていると考えないでください。複数のラックにまたがる論理的な Outposts を持つことができ、ラック内およびラック間のネットワーキングは私たちが代わりに処理します。コンソールではこれを容量のプールとして見ることができ、そこにワークロードをプッシュするだけなので、非常にシンプルで抽象的です。
より小規模なデプロイメントの場合、2U と 1U の両方のフォームファクターで Outpost サーバーを提供できます。これらは AWS クラウドのサブセットをより小さな場所に拡張できます。これらの上では Intel ベースのインスタンスと、1U では Graviton の両方を実行しています。Nitro システムについて少し時間をかけて説明したいのですが、プレゼンテーションの私のセクションでは基盤となるインフラストラクチャについて多く話しており、これはクラウドでの構築方法の本当に基礎的な要素です。
Nitroシステムによるセキュリティとパフォーマンスの革新
Nitro システムは 2018 年以来、すべての最新の EC2 インスタンスで利用可能であり、ハイブリッドエッジでの私たちのすべての取り組みを支えています。私が話したすべてのもの、ローカルゾーン、Dedicated Local Zones、Outposts から、すべてが基本的に Nitro の上に構築されています。Nitro システムはクラウドインフラストラクチャの提供方法を再考し、セキュリティ、パフォーマンス、イノベーションにわたって前例のない利点を提供します。スタックの下部には Nitro ハードウェアレイヤーがあり、これは通常ソフトウェアハイパーバイザーで実行する仮想化機能を専用ハードウェアにオフロードします。これらは AWS によって設計されたカスタムチップであり、システムにはハードウェアの整合性を継続的に検証するセキュリティチップ、およびネットワーキング、ストレージ、セキュリティ機能用の特定の Nitro カードが含まれています。
この上には Nitro Hypervisor ソフトウェアレイヤーがあり、これは非常に軽量な仮想化レイヤーで、ベアメタルに近いパフォーマンスを提供します。多くのお客様は、仮想化のすべての利点を備えたベアメタルでの実行と区別できるパフォーマンスを見ることになります。その理由は、コアハイパーバイザー機能を Nitro ハードウェアレイヤーにオフロードしているからです。その上には、インスタンス OS レイヤーとアプリケーションレイヤーがあり、ここにデプロイします。Nitro システムは、インフラストラクチャレベルでの継続的なイノベーションを通じてお客様により良い成果をもたらす方法の本当に良い例です。業界で最高のセキュリティ標準を提供でき、ベアメタルでの実行と区別できるパフォーマンスを提供できます。
もう 1 つのメリットは、Nitro を使用して新しいインスタンスファミリーを非常に迅速に反復できることです。今週、より多くのインスタンスが起動されようとしており、それらはすべて Nitro の上に構築され、AWS および私たちのパートナーからの最新世代ハードウェアを備えています。セキュリティ内でより詳細に見ると、
暗号化は本当に Nitro システムの基盤となっています。 Nitro 内のあらゆる通信チャネルが暗号化されているため、コンポーネント間を流れるデータはすべて潜在的な脅威から保護されています。次に、Nitro にはセキュアブートプロセスがあり、ブートシーケンス中にシステム全体のセキュリティキーをハードウェアで暗号学的に検証します。3 番目に、Nitro のセキュリティを実行時に継続的にパッチできるため、EC2 フリートを Nitro で保守している間、ワークロードを中断させることがありません。オンプレミスの Outpost でも他の場所でも、Nitro セキュリティレイヤーを保守する際にダウンタイムは発生しません。
最後のポイントは、これへのリモートアクセスがないということです。これが当てはまることは非常に重要であり、Nitro がどのように構築されているかの根本的な設計原則です。私たちはあなたの環境の内部を見ることはできません。AWS または組織外の誰からも、クラウドで実行されるあなたの環境へのオペレータアクセスはありません。セキュリティは本当に私たちの最優先事項であり、Nitro セキュリティのこれら 4 つの柱は、お客様に最も安全なクラウドインフラストラクチャを提供するという私たちのコミットメントを示しています。
第三者が Nitro システムを検証しています。グローバルサイバーセキュリティコンサルティング企業の NCC は、Nitro のセキュリティ設計に関する独立したレポートを公開し、設計上、Nitro へのオペレータアクセスがないことを確認しています。 これらのいくつかで何が起こっているかの内部を見せましょう。これは Outpost で実行されている可能性のある EC2 サーバーの 1 つです。これらのオンプレミス環境でのフィールド運用をどのように行うかについて本当に興味深いことの 1 つは、Nitro Security Key、つまり NSK という概念があることです。右上隅にあります。Nitro 内のすべてが転送中に暗号化されることについて話しました。また、保存時にも暗号化します。Nitro Security Key は、Outpost 上の保存されているすべてのものの信頼の根です。
セキュリティキーを引き抜くと、Outpost は暗号学的に破棄されます。Outpost 上のものにはアクセスできません。お客様がメンテナンスやアップグレード、またはコンポーネントの交換を行っている状況では、お客様にセキュリティキーを渡すことができます。そのキーを破壊すると、Nitro サーバー上のすべてがサニタイズされます。それを持ち去って、キーはあなたに残すことができます。これは NIST メディアサニタイゼーション標準 800-88 に準拠しています。歴史的には、このハードウェアを物理的に破砕する必要がありましたが、暗号学的に行うことができます。これは運用上、本当に素晴らしいことです。
私は 5 年以上 AWS でハイブリッドに取り組んでいますが、お客様と関わることで学んだことは、彼らが同じ経験を望んでいるということです。これは本当に重要であり、私たちが継続して提供する目標は、同じ信頼性の高いインフラストラクチャ、同じパフォーマンス、同じ運用上の一貫性、API とツールをもたらすことであり、最終的には、リージョンで実行しているかどうかにかかわらず、クラウドの同じペースのイノベーションを活用できるようにすることです。エッジまで。
Geidea：サウジアラビアにおけるAWS Outpostsを活用した決済ソリューション
イノベーションについて話すなら、顧客事例に触れたいと思います。これは私が非常に密接に協力してきた顧客です。私はイギリスを拠点としており、エミール地域をカバーしていて、Geidea はサウジアラビアを拠点としています。残念ながら、彼らは参加できなかったので、私が彼らに代わってできる限りプレゼンテーションをさせていただきます。来たる re:Invent で彼らをステージに上げることができればと本当に願っています。彼らは本当に素晴らしいチームであり、この地域での素晴らしいパートナーとなっています。
Geidea は AWS 上に構築されたクラウドでの支払いソリューションを提供しています。彼らはサウジアラビアの POS ビジネスで 75 パーセントの市場シェアを持っており、エジプトとアラブ首長国連邦にも拡大しています。彼らは 150,000 を超えるマーチャントにサービスを提供しており、また 700,000 を超える支払いターミナルを提供しています。Geidea のミッションの 1 つは、基本的にあらゆる規模のビジネスに、ビジネスを開始、管理、成長させるためのツールを提供することです。それは単純な予約システムや EPOS システムを望んでいるばかりのスタートアップレストランかもしれません。彼らはこれを提供することができます。この地域で私たちが直面する課題の 1 つは、財務規制が特に厳しいということです。
例えばサウジアラビアでは、Saudi Arabian Monetary Authority、つまり SAMA があり、みんなそれを Central Bank と呼んでいます。彼らはどのようなデータがサウジアラビアを離れることができるかについて厳しいです。そして Geidea は先に立ち上げるために革新する必要がありました。私たちはその地域に地域を発表しましたが、彼らは迅速に動きたかったのです。私たちは彼らが構築している異なる環境全体で共通スタックを構築するのをサポートしてきました。これは UAE 地域とサウジアラビアおよびエジプトの outposts の組み合わせであり、彼らは共通スタックを構築してデプロイすることができます。彼らはフェーズアプローチを採用しており、現在、システムのバックエンドの一部をその地域に移動させており、その後、その全体のフリート全体でより多くのクラウドネイティブアーキテクチャにスケーリングして移動し始めています。この地域での素晴らしいパートナーであり、チームに本当に感謝しています。うまくいけば、今後の re:Invent で彼らを見ることができるでしょう。
AWS Digital Sovereignty Pledgeとデータペリメータの概念
この段階で Mallory に引き継ぎますが、ご注目ありがとうございました。最後に周りにいますので、皆さんにお会いできるのを楽しみにしています。Geidea が AWS Outposts でどのようにイノベーションを起こしているかを見るのは素晴らしいことです。今日のところ、AWS がエッジでお客様に対応するためにどのように設計されているかを学びました。次に、これらのツールとサービスを使用してセキュリティの目標を達成するための実践的な方法について詳しく説明します。
では、セキュリティの目標とは何でしょうか。それらを簡潔に要約させてください。規制業界のお客様は、ネットワークとデータ暗号化要件を完全にコントロールする必要があることを聞きます。最終的には、特定のソブリン位置、つまり多くの場合、AWS リージョンが近くにない位置にデータを保存したいと考えています。AWS では、常にお客様から逆算して作業しており、それは AWS Digital Sovereignty Pledge で正確に行ったことです。このプレッジは、クラウドで最も高度なデジタルソブリンコントロールのセットを提供するというコミットメントを表しています。AWS の全力を持つか、ソブリンな限定的なソリューションを持つかの選択をする必要はないと私たちは完全に信じています。このプレッジにより、お客様のデータを保護するための新しいツールとサービスでイノベーションを起こすことにコミットしています。
これは4つの約束からなるもので、まずはあなたのデータの場所をコントロールする能力を与えることから始まります。AWSではいつでもこれができてきました。特定のリージョンで、単一のアベイラビリティゾーンで、ローカルゾーンのあるメトロエリアで、またはAWS Outpostsを使ってオンプレミスで、アプリケーションを実行する選択肢があります。2番目は、データアクセスに対する検証可能なコントロールを与えることです。私たちは設計し、提供しました。Benが先ほど話したAWS Nitroシステムは、これが初めてのもので、私たちのコンピューティングサービスの基盤となっています。これは専門的なハードウェアとソフトウェアで設計されており、データ標準を強制するようになっています。Benが言及したように、管理者アクセスがないため、これは人的エラーと改ざんの可能性を排除します。
3番目は、どこでもすべてを暗号化する能力を与えることです。保存時、転送中、またはメモリ内で暗号化したいかどうかにかかわらず、です。私たちはそれを行うためのツールとサービスを提供しています。すべてのAWSサービスは既に今日暗号化をサポートしています。そして最後に、クラウドのレジリエンスに対する私たちのコミットメントです。デジタルソブリンティは、レジリエンスを持つことなしには単純に達成することはできません。顧客はネットワーキングをコントロールする必要があり、それは自然災害と接続の中断のようなイベント中にテーブルステークスになります。だからこそ、すべてのAWSリージョンは完全に隔離された複数のアベイラビリティゾーンで構築されています。顧客は複数のアベイラビリティゾーン全体とリージョン全体でアプリケーションをパーティション化することができ、エッジではAWS Outpostを同じ親リージョン内の異なるアベイラビリティゾーンにホームすることができます。または、異なるリージョン全体にホームすることもできます。
セキュリティの目的を達成するための構築は、多くの場合、あなたのデータペリメータが何であるかを理解することから始まります。re:Inventセッションでなければ、オーディエンスをポーリングすることはないので、私は気になります。データペリメータが何であるか知っている人は誰ですか？データペリメータは、あなたのAWS環境内の許可ガードレールのセットで、信頼できるアイデンティティのみが信頼できるリソースに期待されるネットワークからアクセスすることを確保するものです。
データペリメータは、広範なAWSアカウントとリソース全体でデータを保護するのに役立つ常時オンの境界として機能します。これらは既存のきめ細かいアクセスコントロールに置き換わるものではありません。むしろ、すべてのIAMユーザー、ロール、およびリソースが定義されたセキュリティ標準を満たすことを確保するために機能します。また、AWS Well-Architected Frameworkの設計原則と一緒に機能して、全体的なセキュリティ態勢を強化します。
AWS Control Towerによる大規模ガバナンスとカスタムポリシーの実装
データペリメータは、3つのポリシーの組み合わせを通じて実装します。VPCエンドポイントポリシー、リソースコントロールポリシー（RCP）、およびサービスコントロールポリシー（SCP）です。これらについては今日お話しします。完全に自動化された方法について話しましょう。データペリメータとガバナンスの目的を大規模に実装できる方法です。それはAWS Control Towerです。マルチAWSアカウント環境を統治し、確立するための完全マネージドAWSサービスです。
Control Tower はクラウドであれ、オンプレミスの自分たちの環境であれ、セキュリティガードレールとガバナンスを大規模に実装するためのコマンドセンターのようなものだと考えることができます。Control Tower は AWS のベストプラクティスに基づいて、アイデンティティガバナンスとすべてのアカウントのログを設定する安全なランディングゾーンを確立します。また、コントロールカタログから選択した事前構築されたコントロールを使用してガバナンスを実現します。
そのカタログの中身を見てみましょう。コントロールカタログは、可用性、コスト、セキュリティ、その他のアプリケーション運用にわたる一般的なユースケースに基づいた、1,000 以上の AWS 作成コントロールの一元化されたインベントリです。これらのコントロールは平文で書かれた事前設定されたガバナンスルールで、エンタープライズ全体に適用することも、グループ内の選択されたアカウントに適用することもできます。各コントロールも平文で書かれており、予防的、検出的、または積極的なポリシーを実施でき、これらを必須にすることも、オプションにすることもできます。
このコンセプトをもっと詳しく掘り下げてみましょう。予防的コントロールは IAM サービスとリソースコントロールポリシーを使用して、非準拠のアクションが発生する前にそれをブロックします。例えば、CloudTrail ログがオフにされるのを防ぎたいとします。ユーザーが CloudTrail ログをオフにしようとすると、IAM SCP ポリシーによって自動的にブロックされます。これは、ログの有効化が必須条件であり、たとえ一瞬でもオフにするリスクを負えない交渉の余地のないコンプライアンス要件がある場合に適した選択肢です。
検出的コントロールは、AWS Config ルールを使用して、発生した後に非準拠のアクションを特定します。これは、コンプライアンスステータスの可視性が必要だが、そのリソースがどのように作成されるかについてより柔軟性を提供したい場合に適した選択肢です。この場合、すべての EC2 キャパシティリザベーションにタグが付いているかどうかを検出したい場合、AWS Config ルールはタグのないリザベーションを特定し、フラグを立てて、通知とアラートを送信します。
最後に、積極的コントロールは AWS CloudFormation フックを使用して、リソースのデプロイ時にコンプライアンスを検証します。これは CI/CD パイプラインでコンプライアンスを左にシフトするのに役立つため、検出的コントロールより前に問題を特定するのに役立ちますが、予防的コントロールほど制限的ではありません。この場合、EC2 キャパシティリザベーション中にタグが適用されることを積極的に要求したい場合、開発者が CloudFormation テンプレートをデプロイしていて、デプロイ時にタグが不足していると、それは失敗します。
では、Outposts ラックではどのようになるかを見てみましょう。左側には、Outposts ラックが属する親リージョンがあります。ランディングゾーンはリージョン内のすべてのアセットとオンプレミスのデータセンターの両方にデプロイされています。クライアントがサービスコントロールポリシーをオフにしようとした場合、Control Tower によって自動的にブロックされます。
このコントロールが何をしているのかを見てみましょう。ここでは、コントロールカタログから選択されたガバナンスが表示されています。この予防的なコントロールにより、CloudTrail ログが変更されないようになります。Control Tower の強力で簡単な点は、プレーンテキストで記述されていることです。つまり、複雑な構文を読んだり、ポリシーの基盤となる構造を知ったりすることなく、すべてのユーザーが正確に何が適用されているかを理解できます。
しかし、私たちは常に選択の力を信じているので、ポリシーは Control Tower の artifacts セクションからも利用できます。それを見てみましょう。これは、ランディングゾーン全体のオンプレミスとクラウドの両方にわたって、組織単位に適用されている Service Control Policy です。Control Tower は完全に管理されたガバナンスアプローチであり、1,000 以上のポリシーのインベントリから選択できることについて説明しました。しかし、多くのお客様は独自のカスタムルールを実装したいと考えています。
別の特定のガバナンス目標のためのカスタム Service Control Policy の例を見てみましょう。その Outpost に戻って、それが国 1 に位置し、異なる物理的な場所の異なる国にある AWS 親リージョンの本拠地であると言いましょう。Outpost から親リージョンへのコピーを防ぎたいとします。ここは、その地域のコピーを拒否する Service Control Policy のスニペットです。右上隅に QR コードがあり、完全なブログ投稿と完全な Service Control Policy にリンクしています。
ステートメントの最初の部分では、各サービス名に基づいてさまざまな拒否があります。最初に、イメージ、ボリューム、スナップショットがリージョンにコピーされるのが拒否される方法が表示されます。ポリシーが進むにつれて、このパターンはすべてのサービス名に対して繰り返されます。では、S3 セクションにズームインしてみましょう。ズームインすると、すべての S3 put が拒否されていることがわかります。「実は、Outposts 上の S3 へのローカル put は大丈夫なので、すべての S3 put を拒否したくないのです。地域のものだけを拒否したいのです。どうすればいいでしょうか？」と思っているかもしれません。
S3 on Outposts を設計する際に、まさにこの理由から、リージョナル S3 とは別の IAM namespace を持つようにしたんです。 その利点について説明しましょう。別々の IAM namespace を持つことで、クラウドベースの S3 とオンプレミスの S3 の間に明確なサービス境界が生まれます。 S3 on Outposts を見たら、これは S3 on Outposts の権限だとすぐにわかりますし、その逆も然りです。これにより、最小権限の原則に基づいたモジュール化されたポリシーを書くことができ、バケット名を分割するような複雑な下位レベルの関係を管理する心配がなくなります。
Outposts上のサービス群：EC2、S3、EMRによる統合的なオンプレミス環境の構築
EC2 も同様の設計パターンを採用していて、EC2 Outposts 用に別のアクション名を持っています。 ここまで、信頼できるアイデンティティのためのガードレールを確立し、データペリメータを作成する方法について説明してきました。次は、ギアを切り替えて、これらのアプリケーションをどのように構築・実行するかについて話していきます。先ほど Ben が、顧客がエッジで構築する際に同じ体験を求めていることについて話しました。 その約束をどのように実現しているのか、詳しく見ていきましょう。Outposts では、コンピュート、 ストレージ、ネットワークにわたって 14 のサービスがローカルで実行されています。さらに、Outposts は AWS サービスリンクを通じて AWS の親リージョンのホームとなっているため、柔軟性が加わり、親リージョンのすべての AWS サービスに簡単に接続し直すことができます。
コンピュートから始めると、リージョンで知っている同じ EC2 インスタンスを使ってローカルでコンピュートワークロードを実行できます。 汎用インスタンスが必要な場合でも、コンピュート集約的なものでも、メモリ集約的なものでも、すべて Outpost ラックで利用可能なので、データが存在する場所で処理することができます。また Amazon EBS もあり、 これらの EC2 インスタンスの永続ストレージに必要なボリュームを提供します。すべての Outpost タイプで GP2 ボリュームを使用でき、今年の初めにリリースされた第 2 世代インスタンスラックの Outposts では GP3 ボリュームも使用できます。
リージョンと同じように、ボリュームをインスタンスにアタッチ・デタッチできますし、リージョンから Outposts に AMI（Amazon Machine Images）をコピーして、リージョンで完成させた同じ設定を使ってローカルインスタンスを起動することもできます。こうすることで、AMI を一度作成して、必要な場所にデプロイできます。これにより、デプロイ全体の一貫性が確保されます。これらの EBS ボリュームはブートボリュームとしてもデータボリュームとしても機能し、パフォーマンスに影響を与えることなくボリュームサイズをその場で増やすことができます。ローカルでスナップショットを取得することもでき、ローカルスナップショットまたはローカルスナップショットに基づいた AMI を使って新しいボリュームを素早くプロビジョニングできます。
つまり、Outpost を離れることなく、スナップショットの作成、管理、復元をすべてローカルで行うことができるということです。セキュリティはデフォルトで組み込まれているため、これらのボリュームとスナップショットはすべてデフォルトで暗号化されます。
では、これらのスナップショットをどこに保存しているかについて説明しましょう。それらは S3 on Outposts に保存されており、これはローカルオブジェクトストレージをオンプレミス環境にもたらします。S3 on Outposts は S3 API を使用することで、Outpost 上のオブジェクトを簡単に保存、取得、バージョン管理、タグ付け、アクセス制御できるようにしています。
S3 on Outposts を設計する際、私たちはオンプレミスのデジタルソブリンティ顧客にとって重要だと分かっていた主要なセキュリティと管理機能の提供に焦点を当てました。データへのアクセス制御については、先ほど説明した独立した IAM namespace から始まります。また、デフォルトで暗号化が有効になっているため、Outpost 上のすべてのオブジェクトが暗号化されます。セキュリティ要件に基づいて柔軟性を提供する SSE-S3 または SSE-KMS から暗号化タイプを選択できます。
Outpost 上のこれらすべてのオブジェクトは VPC ベースのエンドポイントを通じてのみアクセス可能なため、アクセスはネットワークペリメータに限定されます。VPC からまたはオンプレミスネットワークエンドポイントを通じてアクセス可能ですが、それ以外の場所からはアクセスできません。ブロックパブリックアクセスはデフォルトで常に有効になっており、変更することはできません。監査とコンプライアンスについては、CloudTrail を使用してオブジェクトレベルとバケットレベルの両方で、すべての S3 API の可視性が得られます。これについては後で詳しく説明します。また、CloudFormation と統合されており、これはすぐに説明します。
親リージョンに戻すものと、データペリメータの目的を達成するためにローカルに保持するものをどのように分離しているかについて説明しましょう。親リージョンに戻すと、すべての非オブジェクトデータを保存します。これはバケットの作成と管理、バケットメタデータ、および IAM ポリシー、アクセスポイントポリシー、バケットポリシーを含むすべてのポリシーです。これには CloudWatch メトリクスや CloudTrail ログなどのテレメトリデータも含まれます。ローカルでは、常にオブジェクトデータとオブジェクトタグ情報を保持します。デフォルトでは、明示的に移動しない限り、オブジェクトは Outpost から出ることはありません。オプションで、ローカルにコピーしたり、リージョンに戻してコピーしたり、別の Outpost に移動したりすることを選択できます。
親リージョンへのリクエストをどのようにルーティングするか、またはリクエストをローカルに保つかについて、どのように区別しているかについて説明しましょう。ここでは、オンプレミス環境の VPC の Outpost サブネット上のインスタンスにあるクライアントがある状況が見えます。ターコイズ色の新しいバケットを作成したい場合、そのバケット作成リクエストは自動的に親リージョンの S3 Outposts コントロールプレーンにルーティングされ、バケットを作成してバケットメタデータを保存します。では、同じクライアントを見てみましょう。put 操作、get、またはその他のオブジェクト操作を実行するときはいつでも、それは常にオレンジ色でローカルに保持され、アクセスポイント ARN またはエイリアスを使用してローカルに自動的にルーティングされます。このエンドポイントルーティングは AWS SDK と CLI によって自動的に行われるため、このエンドポイントルーティングを管理したり、認識したりする必要はありません。これは、汎用バケットタイプ、ディレクトリバケットタイプなど、すべての S3 バケットタイプ全体で使用されます。エンドポイントルーティングは自動的に行われるため、この場合、アクセスポイント Outpost ID エンドポイントに自動的にルーティングされます。
これは単一の Outpost ビューです。デジタルソブリンティのお客様にとって、レジリエンスと高可用性が最優先事項であることを私たちは認識しています。だからこそ、私たちは Outposts での S3 レプリケーションをサポートしています。これにより、完全マネージド型の S3 レプリケーションをオンプレミス環境内のリージョン内にもたらし、ソブリン拠点でのデータ冗長性とレジリエンス要件を満たすのに役立ちます。 レプリケーションを設定すると、オブジェクトは別の Outpost に、または同じ Outpost 上の別のバケットに自動的にレプリケートされます。 最も重要なことに、すべてのレプリケーショントラフィックは、顧客所有のローカルゲートウェイ（LGW）を通じてローカルに留まり、リージョンに戻ることはありません。これにより、定義されたデータペリメータ内での柔軟なディザスタリカバリが実現します。
ローカルレプリケーションは、リージョナルレプリケーションと同様の柔軟な体験を提供するように設計されており、何をレプリケートするかはあなたが制御できます。バケット内のすべてのアイテムをレプリケートすることも、プレフィックス、タグ、またはその両方の組み合わせに基づいてフィルタリングすることもできます。また、オブジェクトを 1 つのデスティネーションバケット、複数のデスティネーションバケットにレプリケートでき、同じ Outpost 上で、同じアカウントの異なる Outposts から、またはクロスアカウントで実行できます。
また、包括的なモニタリングも構築しました。AWS CloudWatch メトリクスでレプリケーションの進捗を追跡でき、Amazon EventBridge で障害をトリアージできます。この両方について詳しく説明させてください。 CloudWatch では、リージョナルレプリケーションと同じメトリクスを公開しており、レプリケーション保留中バイト数、保留中の総操作数、レプリケーションレイテンシーが含まれます。これらは他のストレージ容量メトリクスと一緒に公開されるため、Outpost オーナーはどのアカウントとバケットがストレージを消費しているかを理解できます。AWS CloudTrail アラートとこれらのメトリクスのアラームを設定して、アクションを実行できるようにすることをお勧めします。
また、Amazon EventBridge を設定して障害イベントを受け取り、発生する可能性のあるレプリケーション問題を迅速に診断して修正することもできます。デフォルトでは、レプリケーション設定からメトリクスを有効にすると、デフォルトの Amazon EventBridge バスに送られます。これはサーバーレスイベントバスシステムです。ただし、 新しいイベントルールを作成して、S3 on Outposts イベントのみを自動的にフィルタリングできます。EventBridge のルールを使用すると、イベントをターゲットデスティネーションに自動的に送信でき、Amazon EventBridge は 25 以上の異なるサービスをサポートしており、組み込みの認識と是正措置のためにこれらのイベントを送信できます。
お客様が対応を選択する最も一般的なサービスの一部は、Amazon SNS、SQS、Lambda、Glue などです。Amazon EventBridge で作成するルールには、組み込みモニタリングも付属しています。このようにして、レプリケーションルールがトリガーされた回数と失敗したかどうかを自動的に確認できます。
レプリケーション設定の各失敗には、レプリケーション設定で何が問題だったのかを理解するための失敗理由が付いています。例えば、私たちが見かける最も一般的な失敗シナリオの1つは、宛先バケットがバージョン管理されていない場合です。ソースバケットと宛先バケットの両方でバージョン管理を有効にする必要があります。ただし、ここにリストされていない失敗理由の1つは、service link接続がダウンしているというものです。
オンプレミス環境でのネットワーク接続が一時的に問題が発生している場合、レプリケーションは失敗しません。レプリケーション対象のオブジェクトはpendingステータスでキューに入り、親リージョンへのservice link接続が復旧すると、レプリケーションも再開されます。これにより、組み込みのネットワーク復元力が提供されます。Outposts上のサービスは、CloudTrailとも統合されており、すべてのAWSアカウントのガバナンスと運用監査が可能になります。ユーザー、ロール、またはAWSサービスによって実行されたアクションはすべて、CloudTrailのイベントとして記録されます。
例えば、このCloudTrailエントリでは、S3 on Outpostsバケットに対するput操作が表示されています。トレイルには記録されたすべてのコンテキストが含まれているため、呼び出し元の識別情報、呼び出しの時刻、送信元IPアドレス、リクエストパラメータ、およびサービスによって返されたレスポンス要素を確認できます。さらに、数分前にレプリケーションで見たように、Outposts上のサービスはCloudWatchにメトリクスを送信するため、ワークロードを監視および最適化できます。エッジにあるか、クラウドにあるかに関わらず、同じCloudWatchメトリクスを送信することで、一貫した運用体験を実現しています。
Outpostsはプロビジョニングされているため、これはキャパシティ管理に役立ちます。EC2はメトリクスを送信するため、保有している各インスタンスタイプについて、利用可能な容量、その使用率、キャパシティ予約、およびOutpostデバイスの接続ステータスを確認できます。service linkについて前に説明しましたが、service link接続がダウンしたときを追跡および監視し、CloudWatchアラームを通じてネットワークチームに自動的に通知することができます。同様に、EBSはボリュームタイプ別に、利用可能な容量と使用率についてのメトリクスを送信します。
さらに、S3 on Outpostsは、バケットとアカウントの両方の可視性を提供し、誰がキャパシティを消費しているかを確認できます。コンピュート、ブロック、オブジェクトストレージのニーズについて説明しましたが、オンプレミスの分析ユースケースはどうでしょうか。そのため、Amazon EMR on Outpostsをサポートしており、EMR on Outpostsでローカルに大規模データ分析を実行できます。EMRは、Apache HadoopやApache Sparkなどの大規模データフレームワークの実行を簡素化するマネージドクラスタープラットフォームです。
これはアナリティクスのユースケース、ビジネスインテリジェンス、機械学習など、様々な用途に使用できます。 EMR は EKS 上でも、Outposts 上の EC2 でも実行できます。クラスターをデプロイして、Outposts 上のローカル S3 にアクセスする方法を見てみましょう。Outpost ラック上の EC2 インスタンスに EMR をデプロイすると、コンピュートとストレージの両方の処理パイプライン全体を、オンプレミスの特定のソブリン拠点で実行することになります。
EMR クラスターは Outpost 上の VPC サブネット内で実行され、S3A コネクタを通じて VPC アクセスポイントを使用して Outposts 上の S3 にアクセスします。これはリージョン内と同じセットアップです。CloudTrail や CloudWatch と同様に、EMR ログは親リージョンに配置されます。EMR では、ETL パイプライン、インタラクティブアナリティクスなど、Apache Spark を実行できます。Apache Hive や Apache Flink などの他のフレームワークから選択することもできます。
また、Mountpoint for Amazon S3 は Outposts バケットと統合されています。 Mountpoint はオープンソースのファイルクライアントで、コンピュートインスタンス上に S3 バケットをマウントして、ローカルファイルシステムのようにアクセスできます。 ローカルファイルシステムの API 呼び出しを S3 オブジェクトへの REST API 呼び出しに自動的に変換します。Mountpoint は高スループットパフォーマンスに最適化されており、Amazon Common Runtime Library（CRT）に基づいており、パフォーマンスのベストプラクティスを実装しています。
Mountpoint はオープンソースですが、AWS サポートが付属しており、AWS によって完全に保守されているため、本番ワークロードで自信を持って使用できます。Outposts バケットをマウントする場合でも、ディレクトリまたは汎用バケットをマウントする場合でも、方法は同じです。アクセスポイントのエイリアスまたは ARN を指定するだけです。これはバケット名の代わりにいつでも使用できます。 他に必要なアクションはありません。Mountpoint でバケットへのアクセスを開始できます。
Outposts 上のサービスは AWS CloudFormation とも統合されており、これはインフラストラクチャアズコードサービスで、環境全体のリソースをモデル化、プロビジョニング、管理できます。CloudFormation では、JSON または YAML のいずれかでテンプレート内にインフラストラクチャを定義し、プロビジョニングは自動的に処理されます。これにより、手動設定が不要になり、環境全体で一貫性が確保されます。 先ほど説明したように、Outposts バケットを作成できます。CloudFormation でも EC2 の容量予約でも同じです。
最後に、本日ご紹介した内容はすべて AWS Management Console でご利用いただけます。このコンソールは、クラウドでもオンプレミスでも、資産を管理する際に一貫した運用体験を提供します。EC2 や EBS などのサービスをコンソールで開くと、すべてのリソースが 1 つの場所に統一されたビューで表示されます。重要な差別化要因は Outposts ARN 列です。このシンプルながら強力な要素により、資産がクラウドにあるのか、それともオンプレミスにあるのか、物理的にどこに位置しているのかを簡単に把握できます。ですから、US-C1 で EC2 インスタンスをプロビジョニングしても、数千マイル離れた場所でプロビジョニングしても、同じ場所に表示されます。
EBS ボリュームでも同じ Outposts ARN 列を使用して、この設計パターンが繰り返されています。さらに、異なる S3 バケットタイプを確認すると、ナビゲーションの左側にすべて表示されます。本日のセッションは以上です。AWS がオンプレミスでのソブリンティ目標の達成にコミットしていることを探索するために、ご参加いただきありがとうございました。これらの機能を使って何を構築されるのか、楽しみにしています。本日はお時間をいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion