re:Invent 2024: AWSのデータレジデンシー対応ソリューションと実装例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Well-architected for data residency with hybrid cloud services (HYB309)
この動画では、データレジデンシーとデジタルソブリンティに関するAWSのソリューションについて詳しく解説しています。AWS Well-Architected Frameworkを活用したセキュアなクラウドアプリケーションの構築方法や、AWS Regions、Local Zones、Dedicated Local Zones、Outpostsなどのインフラストラクチャソリューションの使い分けを説明します。具体的な事例として、Singapore GovTechによるDedicated Local Zonesを活用した政府システムの移行プロジェクトが紹介され、41機関213システムの移行実績が共有されています。また、AWS Control TowerとService Control Policyを用いたデータレジデンシーのガードレール実装方法についても、具体的なデモを交えながら解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
データレジデンシーとAWS Well-Architected Frameworkの概要
皆様、こんにちは。AWS Dedicated Local Zonesのプリンシパルプロダクトマネージャーを務めておりますSherry Linと申します。本日は、データレジデンシー、AWS Well-Architected Framework、そしてHybridクラウドソリューションについてお話しできることを大変嬉しく思います。今回のre:Inventには約6万人もの方々が参加されているのをご存知でしょうか？すごい数字ですよね。そして、Kevinさんはシンガポール政府機関のGovTechの代表としてシンガポールからお越しいただいています。
会場の皆様にお聞きしたいのですが、どのような業界からいらっしゃっているでしょうか？政府機関や公共セクターの方はいらっしゃいますか？はい、お見かけしました。金融サービスや銀行業界の方は？かなりいらっしゃいますね。素晴らしい。通信サービス業界の方は？医療サービス業界の方は？会場にいらっしゃいますね。手を挙げていない方々も、本日ご紹介できなかった他の業界からお越しの方々だと思います。世界中のお客様にとって、データレジデンシーという話題がいかに重要であるかを実感できて、いつも感慨深いものがあります。また、お客様それぞれ、業界ごと、国ごと、州ごと、さらには管轄区域ごとに、データレジデンシーの要件が異なっているのも興味深い点です。
本日は、皆様それぞれの特定のデータレジデンシー要件を念頭に置きながら、クラウドのアーキテクチャを設計するためのツールをいくつかご紹介させていただきたいと思います。まず、お客様が安全なクラウドアプリケーションを構築するためのベストプラクティスを提供するAWS Well-Architected Frameworkについてご紹介します。その後、AWS Regions、AWS Local Zones、AWS Dedicated Local Zones、そしてAWS Outpostsを含むAWSインフラストラクチャソリューションとサービスについてお話しします。これらは、お客様のデータレジデンシーの目標達成を支援するため、世界中のより多くの地理的位置にAWSクラウドを拡張するものです。本日は特別ゲストとして、Singapore GovTechのKevin Ngさんにもご登壇いただき、シンガポール政府がクラウドでのデータレジデンシーに対応したアプリケーションを設計するまでの道のりについてお話しいただきます。そして最後に、Lakshmiによるデモンストレーションで、サービスとAWSインフラストラクチャソリューションがどのように連携してデータレジデンシーのガードレールを作成し、コンプライアンスを確保するかをご紹介します。
データレジデンシーの多様なユースケースとデジタルソブリンティ
まず、データレジデンシーとは何かについてお話ししましょう。広義には、特定の地理的位置でデータを保存または処理する要件のことを指します。この話題は、金融サービスや医療サービス、公共セクターや政府機関、あるいは世界中に拠点を持つ多国籍組織のような規制産業のお客様によく見られます。これらのお客様が、従来のオンプレミスデータセンターからクラウドへワークロードを移行することを検討する際に、よく話題に上がります。また、世界中のAWS Regionsやハイブリッドクラウドソリューションなど、様々な場所でデータを保存できるインフラストラクチャソリューションの選択肢を検討する際に、これまで自社のデータセンターで運用していたアプリケーションをクラウド上のどこに配置できるのかという根本的な疑問が生じてきます。
これらの考慮事項は、様々なユースケースから生まれています。規制要件に準拠するためにデータレジデンシーが必要なお客様もいます。例えば、ゲーミング企業のFanDuelは、オンライン賭博システムをクラウドに移行する際、米国法で賭博やギャンブルが特定の州内でのみ許可されているため、アプリケーションが特定の州境界内に留まることを確実にする必要がありました。また、レイテンシー目標を達成するためにデータレジデンシーが必要なケースもあります。例えば、NASDAQは米国のオプションと株式市場をクラウドに移行する際、注文から取引までのプロセスにおいてオンプレミスシステムとのマイクロ秒単位のレイテンシーを確保する必要があり、AWS Outpostsを活用してそのレイテンシー目標を達成しました。また、相互に依存する多くのアプリケーションと大規模なデータセットを含む複数年にわたる移行が必要なため、データレジデンシーの要件があるお客様もいます。例えば、ある大手医療サービスプロバイダーは、エンドユーザーの顧客の健康記録をオンプレミスデータベースに保持しながら、SaaSアプリケーションをクラウドに移行する必要があり、AWSと協力してこの課題に取り組みました。
このお客様は、オンプレミスデータベースの近くにある Local Zones にワークロードを移行するため、AWSと協力しました。これにより、SaaSアプリケーションを通じて健康記録を閲覧・管理するエンドユーザーに対して、オンプレミスデータベースに保存されているデータへの高品質なカスタマーエクスペリエンスを維持し続けることができました。まだ触れていない様々なユースケースが存在しますが、データレジデンシーのユースケースは非常に多様であるため、クラウドにおけるデータレジデンシーには、万能なソリューションは存在しないと私たちは確信しています。
デジタルソブリンティの観点からデータレジデンシーを考えると、この状況はさらに複雑になります。なぜなら、お客様はデータの保存場所だけでなく、その保護についても関心を持っているからです。データレジデンシーについて、お客様は常にデータの所在を把握し、データの保存先や転送先を管理できる必要があります。同時に、権限のない人やアカウントからのデータアクセスを防止する必要もあります。お客様は、自然災害や停電などによる障害に対して耐性のあるインフラストラクチャソリューションを確保しながら、データレジデンシー要件を満たすため、特定の場所にインフラストラクチャソリューションを必要としています。
デジタルソブリンティとデータレジデンシーの要件全体にわたって、お客様が達成する必要のある要件の組み合わせは、クラウドのアーキテクチャ戦略に大きな影響を与える可能性があります。私たちは、データレジデンシーとデジタルソブリンティの要件から逆算して考え、ニーズを満たすためのインフラストラクチャソリューションの選択肢を幅広く理解することが非常に重要だと考えています。では、それぞれのお客様のデータレジデンシー要件が異なる中で、どのようにしてクラウドのベストプラクティスに基づいた構築を行いながら、独自のデータレジデンシーニーズを満たすことができるのでしょうか？
AWS Well-Architected Frameworkを活用したデータレジデンシー設計
AWS Well-Architected Frameworkは、クラウドの設計原則に基づいて、セキュアなクラウドアプリケーションを構築できるようお客様をサポートするために設計されました。AWSのお客様のベストプラクティスから得られた知見を長年かけて集約して開発された情報とツールを提供し、このツールで利用可能な情報としてメリットとリスクを理解しながら、データレジデンシー要件に対応するための設計を柔軟に決定できるよう支援します。
基本的に、AWS Well-Architected Frameworkは、6つの異なるピラーにわたる一連の質問と設計原則です。これらのピラーは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、持続可能性、そしてコスト最適化です。AWS Well-Architected Frameworkは、これらの設計原則に関連するベストプラクティスと、チームがリスクを低減し、より迅速に構築できるよう、アーキテクチャについて考えるための質問を提供します。
クラウド上のアプリケーション設計において、データレジデンシーの目標達成のためにAWS Well-Architected Frameworkをどのように活用できるかを説明するために、セキュリティピラーの例を見ていきましょう。このピラーには、データレジデンシーに直接関連する複数の設計原則があります。例えば、ネットワーキング層、VPC、Load Balancer、すべてのコンピューティングサービスアプリケーション、コード、OSなど、あらゆる層でセキュリティを適用するという設計原則があります。また、暗号化、トークン化、マスキング、アクセス制御などのメカニズムを使用して、転送中および保存時のデータを保護するという設計原則もあります。さらに、セキュリティイベントへの準備という設計原則では、問題を素早く発見し迅速に解決できるよう、独自のインシデント対応シミュレーションを実施することが推奨されています。
AWS Well-Architected Frameworkには、先ほど見た設計原則に関連する一連の質問が各ピラーに用意されており、これらの質問をチームに投げかけることで、アーキテクチャの状態を評価することができます。例えば、セキュリティピラーのデータ保護の領域には、「どのようにデータを分類していますか？」という質問があり、これをチームに投げかけてアーキテクチャを評価することができます。各質問には、その目的、範囲、考慮事項、そしてAWSのお客様のベストプラクティスから学べる推奨事項のリストが含まれています。これらの質問をチームに投げかける前に、AWS Well-Architected Frameworkを使用して、目指すべき成果の合意形成、一般的なアンチパターンの特定、そしてメリットとリスクの評価を行うことが重要です。
AWS Well-Architected Frameworkは、アプリケーションアーキテクチャのセキュリティ状態を評価する強力なツールとなります。このフレームワークには、 データレジデンシーに直接関連する多くの考慮事項が含まれており、今日は特に重要なトピックをいくつか見ていきたいと思います。
Singapore GovTechのGCC+プロジェクト：背景と要件
まず、対象となるデータ分類と適用される規制を特定することに十分な時間を費やすことをお勧めします。各データ分類に適用される規制を理解することで、データレジデンシー要件を満たすために必要なインフラストラクチャソリューションの種類が大きく変わってきます。Singapore GovTechは、異なるデータ分類に対応したデータレジデンシーのアーキテクチャ設計の過程で、シンガポールのAWSリージョンに配置できるデータ分類もあれば、より機密性の高い規制対象のデータ分類には、GovTechに専用のインフラストラクチャを提供するDedicated Local Zonesの強化されたセキュリティとガバナンス機能が必要となるなど、様々な要件に対応してきました。この点については、後ほどKevinが詳しく説明します。
ユースケースも重要です。なぜなら、インフラストラクチャソリューションでサポートする必要のあるサービスの種類に直接影響するからです。データ分析に必要なサービスは、機械学習に必要なサービスとは異なり、さらにHigh Performance Computingに必要なサービスとも異なります。また、 データを配置できる許容場所についても慎重に検討することをお勧めします。この点について、2つの重要な考慮事項を提案したいと思います。1つ目は、オンプレミスシステムやエンドユーザーへのレイテンシー目標を考慮することです。これらの目標を特定することで、データとアプリケーションを配置できる場所の範囲を絞り込むことができます。2つ目は、暗号化、マスキング、トークン化などのデータ保護メカニズムについて検討することです。これらのメカニズムを使用することで、アプリケーションを配置できる場所の範囲を潜在的に広げることができます。
規制要件への準拠が必要なユースケースがある場合、規制は変更される可能性があるため、規制変更の影響を最小限に抑えるために、機密データと非機密データの分類に応じて、ストレージと処理をどのように分離するかについて十分な検討を行うことをお勧めします。また、データ分類やインフラストラクチャソリューションにまたがる変更が必要になった際、共通の基盤上に構築されているため作業を最小限に抑えられるよう、一貫性のあるサービス、API、ツールの使用をお勧めします。データレジデンシー要件に対応するアーキテクチャの設計と構築には、多くの考慮事項があります。
ユースケース、アプリケーションを実行できる場所、データ分類の決定という重要な作業を終えたら、次は選択肢を把握する必要があります。次のセクションでは、お客様固有のデータレジデンシー要件に対応するため、より多くの地理的場所にAWS Cloudをもたらすための、様々なAWSインフラストラクチャソリューションとオプションをご紹介します。まずはAWS Regionsから始めましょう。私たちは世界中に34のAWS Regionsと108のAvailability Zonesを展開し、お客様がデータを保存する場所の選択肢と柔軟性を提供しています。AWS Regionsは設計上主権性を備えており、お客様はデータの保存場所、保存方法、アクセス権限を完全にコントロールできるため、現在、大多数のお客様がデジタル主権とデータレジデンシー要件への対応にAWS Regionsを活用しています。
では、現在AWS Regionsが存在しない場所でアプリケーションを実行する必要がある場合はどうでしょうか？ AWSハイブリッドクラウドソリューションは、お客様のデータレジデンシー要件を満たすために、より多くの地理的場所にAWS Cloudを拡張します。 ここでは、AWS Cloudを拡張するAWSハイブリッドクラウドソリューションのいくつかをご紹介します。まずはAWS Local Zonesからです。これは、コンピューティング、ストレージ、データベース、その他のサービスを人口密集地や産業の中心地の近くに配置するAWSインフラストラクチャの一つです。最近、フィリピンのマニラにAWS Local Zoneの開設を発表し、現在米国外に17か所を含む合計34のLocal Zonesを展開しています。Local Zonesにより、お客様は低レイテンシーのアプリケーション要件を満たし、規制に準拠するために、より多くの地理的場所、国、州、管轄区域でワークロードを実行できるようになります。では、自社のデータセンター内でアプリケーションを実行する必要がある場合はどうでしょうか？
AWS Outpostsは、事実上あらゆるデータセンターにAWSインフラストラクチャとサービスをもたらします。Outpostsはフルサイズの42Uラックまたは支社の場所に展開できる小型サーバーの形態で提供され、75か国以上で利用可能です。これにより、お客様は自社のオンプレミスデータセンターでワークロードを実行するためのインフラストラクチャオプションを効果的に拡大できます。
広範なデジタル主権やデータレジデンシーのニーズを持ち、ユーザーコミュニティのニーズに応えるための専用インフラストラクチャを必要とするお客様向けに、AWS Dedicated Local Zonesを提供しています。これはAWSサイトまたはお客様のデータセンター内に柔軟に展開でき、現地のAWS担当者が運用を行います。お客様はDedicated Local Zones内でリソースを作成できるアカウントを制御でき、また、お客様コミュニティによる導入を促進するために、弾力性、スケーラビリティ、従量課金制のマルチテナンシー機能を提供しています。
GCC+の実装：AWS Dedicated Local Zonesの活用
AWS Local Zones、Dedicated Local Zones、そしてOutpostsは、より多くのロケーションを提供し、お客様にデータの保管場所についてより大きな柔軟性をもたらします。しかし、場所に基づいてインフラストラクチャソリューションを選択することは、データレジデンシーの要件を満たすための一部に過ぎません。それらの場所でユースケースをサポートするサービスについてはどうでしょうか？AWS Local Zones、Dedicated Local Zones、およびOutpostsは、ローカルでの処理とデータストレージのための基本的なサービスセットをサポートしています。コンピューティングについては、お客様はハイブリッドクラウドソリューションにおいて、汎用またはメモリストレージに最適化されたインスタンスタイプを選択できます。AI/MLユースケースについては、一部のLocal ZonesとDedicated Local Zonesで高性能コンピューティングや機械学習ワークロードを実行できる、アクセラレーテッドコンピューティングが利用可能です。
ストレージについては、永続的なブロックストレージとしてAmazon EBSが利用可能で、一部のLocal ZonesとDedicated Local ZonesではローカルファイルサービスとしてのアマゾンFSxも利用できます。Amazon RDSすなわちRelational Database Serviceは、OutpostsおよびLocal Zonesの一部で利用可能で、Amazon S3はOutpostsで利用可能です。また最近、デジタル主権とデータレジデンシー要件を満たすために特別に設計された、AWS Dedicated Local ZonesでのAmazon S3ストレージクラスの一般提供開始を発表したことをご存知かもしれません。
セキュリティとガバナンスサービスに関して、AWSには50以上のセキュリティおよびガバナンスサービスがあり、これらはAWS Local Zones、Dedicated Local Zones、およびOutpostsと連携して動作します。後ほど、Lakshmiが、これらのセキュリティサービスがインフラストラクチャソリューション、コンピューティング、ストレージ、データベースサービスと連携して、データレジデンシーのガードレールを実施する方法をデモンストレーションします。
ここまでで、データレジデンシー要件を満たすインフラストラクチャソリューションとサービスについてご理解いただけたと思います。しかし、すべてのデータがクラウドにある場合、そのデータが安全で確実に保護されていることをどのように確認できるのでしょうか？ここで、お客様のデータの機密性と完全性を確保するためのAWS Nitro Systemの出番です。AWS Regions、Local Zones、Dedicated Local Zones、およびOutpostsは、AWS Nitro Systemによって動作しています。10年以上にわたり、私たちはEC2の仮想化機能をより多く専用のファームウェアとハードウェアに組み込むために、EC2仮想化スタックを再構築してきました。AWS Nitro Systemは、その継続的なイノベーションの成果です。
AWS Nitro Systemは、強力な物理的および論理的なセキュリティ境界を実施することで、AWSの社員を含む誰もがEC2上で実行されているお客様のワークロードにアクセスできないように制限を設けています。AWS Nitro Systemのセキュリティ設計は、グローバルなサイバーセキュリティ企業であるNCC Groupによる独立した公開レポートで検証されています。したがって、AWS Regions、Local Zones、Dedicated Local Zones、またはOutpostsのいずれを使用する場合でも、AWSのお客様は、物理的に誰もお客様のデータにアクセスできないようにするNitroテクノロジー上でアプリケーションを実行する際のセキュリティを確信できます。私たちには、データ目標を達成するためにこれらのソリューションを活用している多様なお客様がいます。
これらの顧客は、それぞれのニーズに応じて、私たちのハイブリッドソリューション、エッジサービス、そしてAWS Nitro Systemを活用しています。ここで、データレジデンシーに対応したワークロードの設計について、シンガポール政府の取り組みをお話しいただくため、特別ゲストスピーカーのCore Engineering Products担当Senior DirectorのKevin Ngさんをお迎えしたいと思います。
GCC+プロジェクトの成果と今後の展望
ありがとうございます、Sherry。私はKevin Ngと申します。シンガポール出身で、GovTechのCore Engineering Products担当Senior Directorを務めています。私の役割について詳しくお話しする前に、GovTechについてご説明させていただきます。多くの政府と同様に、シンガポール政府も複数の機関で構成されています。シンガポールはアメリカほど大きくありませんが、約100の機関があります。これらの機関は、市民やビジネスに向けて、それぞれ異なる機能と目的を持っています。例えば、シンガポールの経済成長を推進するEconomic Development Board、労働法を管理するMinistry of Manpower、そして市民や企業から税金を徴収する税務署に相当する機関などがあります。私たちの使命は、デジタル政府を構築し、より良い生活を実現することです。
GovTechは他の政府機関とは異なる特徴を持っています。多くの政府機関は外部から技術を調達しますが、GovTechは内部に技術力を持っており、技術ソリューションの設計、開発、運用が可能です。もちろんAWSなどの外部ベンダーやパートナーも活用していますが、技術ソリューションを独自に提供できる能力を持っています。これにより、私のようなプラットフォームエンジニアリングリーダーとして、Singapore Government Tech Stack全体を運営する役割が生まれました。私の目標は、開発者の生産性向上、システムの回復力とセキュリティの強化を図りながら、コストパフォーマンスを維持することで、シンガポールのデジタルトランスフォーメーションを加速することです。
Singapore Government Tech Stackは3つの層で構成されています。最下層には、Government on Commercial Cloud（GCC）と呼ばれるホスティング層があります。このプレゼンテーションでは、Government on Commercial Cloudを指すGCCという用語が頻繁に出てきます。次に、ベース層があります。クラウド開発には、システム開発者やビルダーがクラウドアーキテクチャに合わせて一貫して開発できるツールが必要です。例えば、APIゲートウェイとマーケットプレイスシステムであるAPEXがあります。これにより、ゲートウェイシステムの標準化、セキュリティの向上、政府機関全体で発生する様々なトランザクションの動作の可視化が可能になります。また、継続的インテグレーションと継続的デリバリーのソリューションであるSHIP-HATSがあり、セキュリティチェックを含む高品質なソリューションをクラウド環境に一貫して展開する方法を提供しています。
最上層のサービス層について少しお話しさせていただきます。NDIという用語が出てきますが、これはNational Digital Identityの略です。多くの国と同様に、シンガポールでも身分証明書があり、政府の実際の窓口で本人確認をしてサービスを受けることができます。今日では、デジタルの世界に移行する中で、ウェブ上で市民や企業を認証できることが非常に重要になっています。National Digital Identityは、そのための基盤となるプラットフォームです。このサービス層は、より大規模なアプリケーションやシステムを構築できる再利用可能なソフトウェアコンポーネントの集合体であり、これがSingapore Government Tech Stackです。
次に、Government on Commercial Cloudについて詳しく見ていきましょう。まず中心的なポイントとして、これは単にデータセンターの片隅に置かれているクラウドではないということを理解することが重要です。もちろん、クラウドはデータセンター内にありますが、これは皆さんが使用している一般的なパブリッククラウドと同じもので、ただしシンガポールリージョンに存在するものです。Government on Commercial Cloudと言う場合、それは様々な政府機関向けに一元的な管理を行うために構築した機能を指します。ここで言及しておくべき重要な点は、これらの異なる機関がそれぞれ独自のITチームとプラットフォームチームを持っているということです。つまり、私たちはプラットフォームのプラットフォームとして機能しており、これらの機関が容易に参加できる十分に汎用的なプラットフォームを作成しているのです。
サポートが必要な小規模な機関もあり、そのような場合は私たちのプラットフォームを直接活用しています。基本的な機能について簡単に説明させていただきます。右下にあるのは、ワークロードのシステム制御をどのように設定するかを管理するためのベースラインセキュリティコントロールです。これには、先ほど言及された非常に重要なポイントであるデータレジデンシーが含まれています。データと必要なサービスをシンガポールリージョン内に確実に配置するための制御が可能で、これによってワークロードのガードレールを提供するポリシーを簡素化できます。
左側では、オンボーディングを簡素化しています。Commercial Cloudを導入する前は、すべてがデータセンターにありました。これはDevOps以前の時代で、開発者がバイナリのビルドを完了すると、別のプロセスとして運用部門にデプロイしていました。より良いDevSecOpsコラボレーションでこれらを統合し始めたとき、この簡素化されたオンボーディングシステムが必要でした。実際、これは開発者のための、システムビルダーのために構築されたシステムです。複数の機関があるため、コストの再配分が必要で、そのため請求を一元化しています。
上部は、主にシステム管理者向けの機能です。これには、集中型の可観測性のような最新の機能と、より従来型の管理機能が含まれています。つまり、慎重なプロセスを通じてワークロード自体へのSecure Shellアクセスといった従来型の機能です。この部分が重要なのは、シンガポール政府の技術力が均一ではないためです。私たちは異なる成熟度を持つユーザーや機関をサポートするソリューションを提供する必要があります。
オンプレミスとの接続ポイントを効率化する必要があります。これにより、政府ネットワークや異なるホスティングインフラストラクチャーへの接続が可能になるためです。現在、多くのワークロードがクラウドにありますが、依然として相当な部分がオンプレミスにあります。これは、特にデータとユーザーに関して、オンプレミスからクラウドへの相互運用性を確保する必要があることを意味します。Government on Commercial Cloud（GCC）のフェーズ1は非常に成功を収めています。昨年のこのカンファレンスでは70%がクラウドに移行したと報告され、今年は80%に近づいています。100%には到達しないかもしれませんが、これが現在の状況です。
すべては順調でしたが、約2年前に課題に直面し、ここでGCC+というアイデアを思いついたのです。ネーミングにはあまり創造性がありませんが、GCC+はGCCの機能を拡張したものを意味します。これは、先ほど触れたデータ分類に起因しています。私たちには異なる分類のワークロードがあり、最も高度な分類のワークロードは「機密」と呼ばれています。従来、機密ワークロードは完全なコントロールと物理的な分離が可能なオンプレミス環境でのみ運用されると考えられていました。
約2年前、私たちは問題に直面しました。オンプレミスソリューションであるGovernment Private Cloudが2024年6月にEnd of Lifeを迎えることになったのです。私たちは難しい決断を迫られました - オンプレミスソリューションを継続して新しいライセンスやテクノロジーを導入し、多額の設備投資を行うか、それともワークロードをクラウドに移行できるように再構築するか。私たちには、追加のセキュリティ保証と物理的な分離、そして専用のリソースを提供できるクラウド環境内のソリューションが必要でした。
4つの大きな要件があり、その1つがセキュリティ要件です。私たちのクラウド環境では、100の政府機関全てをホストしており、各機関は通常CognizantやAccentureなどのサードパーティプロバイダーに業務を委託しています。これらの企業は文字通りシンガポール政府のワークロードを実装する企業です。ある機関やワークロードから侵害が発生した場合、その影響範囲が非常に大きくなる可能性が常にあります。そのため、セキュリティの観点から、機関レベルだけでなく、ワークロードレベルでの分離が重要なのです。
Sovereigntyも私たちにとって非常に重要です。先ほどSherryが複雑さについて言及したように、クラウドがシンガポール国内でホストされているため、データのResidencyとSovereigntyの要件はすでに満たされています。しかし、欠けているのは、コンピューティングとストレージのリソースがシンガポール政府専用になっていないことです。この新しい環境では、これらのリソースをシンガポール政府が所有し、より直接的にコントロールできるようにしたいと考えています。また、シンガポール政府によってクリアランスを受けた現地の信頼できる人材によって運用されることを望んでいます。
プラットフォームのバックグラウンドを持つ者として、開発者を支援するクラウドプラットフォームを作ることが重要であり、開発者体験は可能な限り高い水準を目指しています。もちろん、コストはすべての政府にとって非常に重要な問題であり、予算目標を達成する必要があります。この環境を構築する中で、既存のGCCで構築されたDevOps機能をGCC+に拡張できることを確認する必要があります。技術的には、CI/CDソリューションが統合されている必要があり、すでに構築済みのCI/CDパイプラインを通じてGCC+に直接デプロイできる必要があります。
私たちのソリューションには、いくつかの政府機関とケイパビリティがあり、そのためKubernetesの実装にはAmazon EKSのようなソリューションが必要です。他のAWSユーザーとは異なり、私たちはインフラストラクチャをコードとして提供するためにTerraformベースのパイプラインを使用することを選択しており、これを継続することは非常に重要です。AWSが、AWS Nitro Systemのような独自技術とオープンアーキテクチャを組み合わせて提供し、既存のテクノロジーを統合できるようにしてくれていることに、大変感謝しています。
長い検討と議論を重ねた結果、最終的にAWSとのパートナーシップにより、社内でGCC+として知られる専用Local Zoneという概念を共同で創り上げることになりました。この協力関係は非常に強固で、AWS Nitro Systemの監視方法やセキュリティ確保について、AWSの技術者との詳細な検討セッションを行ってきました。私たちの専用Local Zoneに必要なローカルサービスの優先順位付けを共同で行い、パブリッククラウドを活用して追加のサービスをどのように構築できるかについても検討してきました。
先ほど述べたように、私たちは複数の政府機関をサポートしているため、各機関が組織単位内で独自のクラウドプラットフォームを管理できるようにマルチテナンシーをサポートする提供方法を開発することが非常に重要です。レジリエンシーは政府にとって重要なトピックであり、フェイルオーバー機能のために複数の専用Local Zoneを構築する能力が必要です。 2022年に開始した非常にアグレッシブなスケジュールでしたが、1年以内にAWSは私たちに専用Local Zoneを提供することができました。まだ作業は完了していません。オンプレミスのワークロードをクラウドに移行するのに約1年かかり、政府機関やベンダーコミュニティへの追加トレーニングも必要です。
先ほど触れたように、簡略化したレベルでこのアーキテクチャについて説明させていただきます。専用Local Zoneには必要なすべてのサービス、特にセキュリティサービスが揃っていないため、Government on Commercial Cloudであるパブリッククラウドからサービスを拡張する作業を行っています。ファイアウォールやWeb Application Firewallなど、多くのセキュリティサービスがこれに依存しています。フェイルオーバーによるレジリエンシーのために、2つの専用Local Zoneを構築する必要があります。これらの専用Local Zone内では、物理的に隔離されて文字通り檻で囲まれており、クリアランスを受けた担当者のみが檻内の機器やリソースに物理的にアクセスできます。最後に、このGCC plusシステムを政府のネットワークに接続する方法が必要で、GCCだけでなく、一部のオンプレミスワークロードとも連携できるようにする必要があります。
この檻で囲まれたエリアはデータセンター内にあります。このセットアップにより、システムはGCCやオンプレミスワークロードとの接続を維持しながら、セキュアに運用することができます。
このにおける課題の1つは、AWS Edgeソリューションがローカルでサポートするサービスが限定的であることです。私たちはAWSと優先順位付けを行っており、このプロセスを通じてAWSと緊密に連携できていることに大変感謝しています。Dedicated Local Zoneで一般提供されているサービスと言っても、必ずしもすべての機能が利用可能というわけではありません。Dedicated Local Zoneに必要な優先機能を決定するため、引き続きAWSと綿密に協力していく必要があります。適切な機能セットを構築するためのこのパートナーシップに、私たちは大変感謝しています。
データ移行に関しては、クラウド移行を経験された方なら誰でもご存知の通り、大量のデータと限られた帯域幅での作業は常に課題となります。私たちは、並列データ転送の実装や、利用可能な帯域幅を最大限活用するための段階的なデータ移行スケジューリングなど、創造的な解決策を考える必要がありました。また、セキュリティポリシーに関する課題にも直面しました。多くの政府機関と同様に、私たちもワークロードを保護するための包括的なセキュリティポリシーを策定してきました。数年前にクラウドへ移行した際、私たちは独立したクラウドポリシーを作成することを決定しました。
この特殊な環境は完全なパブリッククラウドではないため、オンプレミスのポリシーとクラウドポリシーのどちらを適用するか決断を迫られました。最終的に、将来を見据えてクラウドポリシーを適用することを選択しました。ただし、クラウドポリシーに完全には適合しない領域について検討し、必要な例外や変更を加える必要がありました。これらのポリシーが整理されると、各機関の移行作業がスムーズに進むようになりました。規制環境下の機関は、適切なポリシーの整合性がなければワークロードの移行に踏み切れないからです。
嬉しいことに、このミッションは成功を収めました。全体として41の機関から213のシステムがあり、そのうち68システムがDedicated Local Zoneをベースとしたこの新しい環境であるGCC plusへ移行しました。92システムは適切に分類されてパブリッククラウドへ移行し、一部のシステムは実際に再利用できることが分かりました。GovTechは中央機関として、来訪者管理システムのような全機関で利用可能な汎用システムを提供することができます。これらのシステム数がそれほど多くないのは、主に機密性の高いワークロードを扱っているためです。依然としてオンプレミスで継続しなければならないシステムも存在します。重要なのは、43のシステムが廃止されたことです。すべてのクラウド移行において、単純にリフト＆シフトするのではなく、システムの廃止時期を見極めることが重要です。
GCC plusを利用することで得られたメリットは、GCCと非常によく似ています。確実に俊敏性とイノベーションが向上しました。オンプレミスのワークロードでは、必要な書類作成、予算確保を経て実際に開始できるまでに最大1年かかっていました。現在はGCC plusにより、Dedicated Local Zoneはクラウドほど即時的ではないものの、この期間を大幅に短縮することができます。クラウドサードパーティプロバイダーを活用することで、彼らが私たちに代わってイノベーションを推進してくれるため、ホスティング層のすべての側面で私たちが革新を起こす必要はありません。これにより、システム開発者にとって、より迅速なオンボーディングと開発能力の向上が実現されています。
2つの専用Local Zonesを持つことで、それらの間でフェイルオーバーが可能となり、耐障害性が向上しました。これはRegionalクラウドと同様の設計思想に基づいており、そのためサービスレベルの保証の一部はパブリッククラウドと非常に似通っています。具体的なコスト削減の詳細についてはお話しできませんが、共通のアプローチを取ることでアーキテクチャをシンプル化できることをお伝えできます。
この共通のアプローチにより、大幅なコスト削減を実現できています。一貫したAWSインフラストラクチャのツールとAPIを実装することで、シンプルな方法で作業を行えるようになりました。また、セキュリティも向上しました。以前のオンプレミス環境では、サードパーティプロバイダーから購入した様々なアプライアンスやツールを使用しており、標準的な実装方法がありませんでした。現在はAWSを利用することで、標準化されたアプローチを持つだけでなく、セキュリティ運用作業を支援するマネージドサービスも利用できるため、セキュリティ設定のエラーが減少しています。
最後に、今後の計画についてお話しします。 GCC+環境へのテクノロジースタックの統合について考える必要があります。これは非常に重要です。なぜなら、開発コントロールプレーンと私が考える共通のコントロールプレーンを持つことで、より一貫性のある方法でソリューションを迅速に展開でき、可用性とセキュリティポスチャーの両方を向上させることができるからです。プラットフォームプロバイダーとして、私たちは継続的に開発者体験を改善していく必要があります。AWSは基盤となるプラットフォームを提供しますが、政府のプラットフォームプロバイダーとして、政府ドメインにより適したサービスを構築することが重要です。
2つの専用Local Zones間でのフェイルオーバー機能を考慮し、耐障害性の改善に注力する必要があります。ワークロードについて考える際は、先ほど説明したWell-Architected Frameworkに従う必要があります。このようにして、教育と基本的な機能を通じて耐障害性を向上させることができます。最後に、AIケイパビリティなどの追加サービスをGCC+環境に統合するため、AWSとより緊密に協力する必要があります。これを考える際、すべてをGCC+に入れるのではなく、GCCとGCC+を組み合わせてワークロードの要件に応えることが重要です。
AWS Control TowerとService Control Policyによるデータレジデンシー管理のデモンストレーション
では、システムの詳細な説明とデモを行うLakshmiに引き継ぎたいと思います。Kevin、Singapore GovTechのユースケースを共有していただき、ありがとうございました。私はLakshmi VPと申します。Hybrid Cloudチームのスペシャリストサーキテクトを務めています。ここにいられることを嬉しく思い、すぐにデモに入りたいと思います。Well-Architected Frameworkとデータレジデンシーの考慮事項、そしてHybrid Cloudサービスの使用方法について説明を聞きました。
ハイブリッドクラウドソリューションを活用して Well-Architected なソリューションを構築する方法を簡単にご説明します。まず最初の重要なステップは、コンプライアンスの状況と、データレジデンシーコンプライアンスの対象となるデータを特定することです。次に、特定のデータレジデンシー要件に適合する場所に基づいて、AWS のインフラストラクチャオプション（リージョンやOutposts、Local Zones 、Dedicated Local Zones などのハイブリッドクラウドソリューション）を検討します。そして、Well-Architected Framework を使用して、Control Tower とランディングゾーン、Organizations と Service Control Policy、IAM などの AWS サービスやツールを活用し、コンプライアンスを確保するためのデータレジデンシーのガードレールを設計・実装します。
AWS はコンプライアンスソリューションを構築するための様々なサービスを提供しています。本日のセッションでは、これらのサービスのうち、ランディングゾーンを備えた Control Tower と、Service Control Policy を備えた AWS Organizations という2つのサービスについて詳しく説明し、実際の使用例をご紹介します。最初に見ていくのは Control Tower です。これは、マルチアカウントAWS環境のセットアップとガバナンスを支援し、データレジデンシーの状況を自動化・監視するのに役立ちます。Control Tower には3種類のガードレールがあります。 予防的コントロールは望ましくないアクションの発生を防ぎ、事前対策的コントロールはすべての CloudFormation デプロイメントにポリシーを自動的に適用し、発見的コントロールは特定のアクションが発生した際にそれを検出してガードレールに記録します。 では最初のデモとして、
20個の予防的コントロールと5個の発見的コントロールが既に有効化されたマルチアカウントのランディングゾーンを見ていきましょう。NIST 800-53 や PCI DSS などのフレームワークに準拠する必要があるお客様は、このカテゴリーで関連するポリシーをグループ化して見つけることができます。 また、先ほど Sherry が説明したデジタルソブリンティのカテゴリーに属するコントロールも AWS Control Tower で確認できます。 例えば、先ほど言及した事前対策的、予防的、発見的というラベルについて、 これらのサービスそれぞれに対してこのカテゴリーで利用可能なラベルを確認できます。
ここでは、EC2 インスタンスがパブリック IPv4 アドレスに関連付けられた場合に即座に検出する発見的ポリシーをフィルタリングしています。ワークロードにパブリック IPv4 アドレスが割り当てられないようにする必要があるユースケースを考えてみましょう。特定のポリシーを選択し、詳細を確認して、このデータレジデンシーガードレールを有効化または強制適用したいアカウントを選択できます。このように AWS Control Tower は、データレジデンシー設計の構築を始める際に、すぐに使えるベストプラクティスに基づいたコンプライアンスポリシーを提供します。
本日ご紹介する2つ目のサービスは、AWS Service Control Policy です。これは AWS Organizations 内の権限管理を支援し、カスタムガードレールの構築も可能な組織ポリシーの一種です。では、なぜカスタムガードレールが必要なのでしょうか？先ほど説明したように、万能なソリューションは存在しません。データレジデンシーは、国や用途、境界によって様々に異なります。お客様が Service Control Policy（SCP）をよく使用するシナリオとしては、ある場所から別の場所へのデータ移動を制限する場合や、ユースケースに関係のない AWS サービスの使用を防止する場合、あるいはデータの分離や分割を維持する場合などがあります。政府や公共部門、その他の規制産業において、機密データと非機密データの処理や保存を分離する必要がある場合を考えてみてください。
2番目のデモでは、再びAWS Organizations内のマルチアカウント設定を見ていきましょう。ご覧のように、Management Account、Sandbox Account、Security Accountなど、複数のアカウントがあります。 Policiesの下に、データレジデンシーのためのカスタムガードレールを構築するService Control Policiesがあります。 これらのSCPポリシーを使用して、データの移動の防止、ユースケースに関係のないAWSサービスの制限、データの分離と隔離などを実施します。
これらのSCPポリシーの1つを詳しく見て、実際にどのように機能するか確認してみましょう。金融系のお客様が支払いカード情報と処理の詳細を特定のコンプライアンス対応場所内に保持する必要がある、というローカルデータ処理のユースケースを考えてみましょう。あるいは、先ほどKevinが話したGovTechの例のように、機密性の高いワークロードを専用のLocal Zone内で実行する必要がある場合です。この例では、コンプライアンス対応のハイブリッドエッジロケーションとしてDedicated Local Zonesを使用していますが、これはAWS Local ZonesやAWS Outposts、さらにはRegionにも適用できます。 このSCPの内容を見てみましょう。詳細を見ると、このSCPは02a02で終わるサブネット以外のすべてのサブネットでのEC2インスタンスの起動をブロックまたは拒否します。この例では、そのサブネットはDedicated Local Zone内にあります。 では、Launch Templateを使用してEC2インスタンスを起動してみましょう。AWSリージョン内で2つのインスタンスを起動しようとします。
ご覧のように、選択したサブネットは02a02ではありません。これを実行しようとすると、SCPがすぐにブロックします。 このアクションは、Service Control Policiesでアローリストに登録されていないサブネットであるため拒否されました。同じ2つのインスタンスを再度起動してみましょう。 今度は、Service Control Policyでアローリストに登録されているサブネットを選択します。 ご覧のように、 Service Control Policyでアローリストに登録されている02a02で終わるサブネットを選択しています。今回、インスタンスの起動をクリックすると、アクションは許可されます。 このように、お客様はリソースがコンプライアンス境界外で起動されないようにデータレジデンシーを強制することができます。
コンプライアンス境界内でリソースの起動を制限または強制できることがわかりましたが、処理後にデータがそれらの境界外に移動されないようにするにはどうすればよいでしょうか？例えば、ヘルスケアのお客様は、エンドユーザーの特定の機密個人情報は、処理後も必ず特定の境界内に保存されるべきだと言います。データ分離の ユースケースを考えて、この特定のSCPを見てみましょう。これは、Dedicated Local Zone以外の場所でのEBSボリュームのスナップショットの保存を拒否します。先ほど起動した2つのインスタンスに接続されているEBSボリュームのスナップショットを素早く作成してみましょう。 これをAWSリージョンに保存しようとすると、再びSCPがアクションを拒否します。 スナップショットの保存とDedicated Local Zonesからリージョンへの移動が防止されています。
朗報として、Outpostsではローカルデータストレージ用のS3ストレージクラスが利用可能で、先ほどSherryが説明したように、Dedicated Local Zones向けのストレージクラスも新しくリリースされました。これにより、データの保存場所を決定し、ワークロードとユースケースに準拠することができます。今日見たのは、データレジデンシーのためのWell-Architectedソリューションを設計し始めるための氷山の一角に過ぎません。ハンズオン演習や ラボ演習をご希望の方は、このQRコードからWell-Architected Toolをご確認ください。
まとめと追加リソースの紹介
データの保管場所を決めるのは皆様自身であり、AWSは適切なアーキテクチャのソリューションを構築するために必要なサービスとツールを提供しています。このセッションが、AWSのハイブリッドクラウドサービスを活用してデータレジデンシーのソリューションを適切に設計する方法について、皆様のご参考になれば幸いです。このトピックについてさらに詳しく知りたい方のために、こちらに追加のリソースをご用意しました。本日は、お時間をいただき、誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion