re:Invent 2025: Landing Zone Acceleratorで実現するソブリンクラウド環境の構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Building Sovereign Cloud Environments (COP409)
この動画では、AWSのPrincipal EngineerであるBo LechangeurとSenior Software Delivery ManagerのRandy Domingoが、ソブリンクラウド環境の構築方法について解説しています。デジタルソブリンティの概念、規制コンプライアンスへの対応、そしてLanding Zone Accelerator on AWS(LZA)の技術的詳細が中心です。LZAはAWS CDKを活用したオープンソースソリューションで、NIST 800-53、GDPR、C5などの規制フレームワークに対応したセキュリティコントロールをマルチアカウント・マルチリージョン環境に展開します。YAMLファイルによる設定、TypeScriptベースのコード構造、Security Hubの自動セットアップなど、具体的な実装例とともに、Universal Configurationによる規範的なガイダンスが紹介されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
デジタルソブリンティとは何か：グローバルな規制環境における課題
皆さん、おはようございます。本日は、ソブリンクラウド環境の構築方法についてお話しするためにここに集まりました。自己紹介させていただきます。私の名前はBo Lechangeurです。Amazon Web Services内のPrincipal Engineerを務めております。私の左側にいるのは同僚のRandy Domingoです。彼はチームのSenior Software Delivery Managerです。本日は、デジタルソブリンティの概念をご紹介しますが、これは実際にはコードに関する講演です。 まず最初に、デジタルソブリンティとは何か、お客様がこれにどのように対処しなければならないか、そしてグローバルな観点から見た課題について、問題提起からお話ししたいと思います。これは、組織として採用可能なコントロールの選択肢とは何か、そして組織が何をしているのかということに関わってきます。そして、AWSがこのアプローチをどのように取っているか、ソブリンクラウドの観点からどのようにアプローチするかについて触れていきます。その後、Randyと私がチームで管理しているソリューションであるLanding Zone Accelerator on AWSと、AWS CDKを活用して私たちが取り入れてきた概念について、大規模なお客様向けにこれらの課題にどのように対処しているかを低レベルで掘り下げていきます。
デジタルソブリンティを理解するために、 非常に重要な点として、多くの場合、お客様や組織がAWSに参入する際、ビジネスをAWSに持ち込む際に、大量のデータを管理しなければならないということがあります。現代において、規制の観点から見た状況は、グローバルな視点で常に進化しています。特にヨーロッパなどの地域では、規制コンプライアンスが非常に速いペースで変化しているのを目にします。そのため、お客様は自社のビジネスニーズに適合する独自のセキュリティ基準を管理するだけでなく、規制コンプライアンスのニーズにも対応しなければなりません。そのような観点から、データを管理する際には、学習の観点から、どのようなコントロールが利用可能なのか、環境内の脅威モデルをどのように評価するか、どのようなコントロールがあるのかを理解する必要がありますが、同時に環境への可視性も必要です。そこで、お客様はデジタル資産に対するコントロールと、クラウド内でそのデータを実際にどのように管理するかを望んでいます。彼らは、データ流出などのさまざまなシナリオからそのデータを保護するために使用できる規範的なコントロールのコントロールと選択肢を求めていますが、同時に技術的な自律性も維持したいと考えています。つまり、クラウドでのイノベーションを制限することなく、です。
ソブリンクラウドについて話し始めると、お客様がさまざまな地域で運用していることに触れました。米国を拠点とするお客様もいれば、よりグローバルな存在感を持つ、よりスケーラブルなエンタープライズレベルのお客様もいます。そして、コントロールをどのように階層化するか、異なるセグメント間でどのように通信を許可するかという点で、エンタープライズ環境の観点から非常に興味深いものになります。同時に、責任共有モデルの一部として、お客様は自分のデータをコントロールし、クラウド内でそのデータをどのように保護し管理するかの選択肢を持つ必要があります。そのような観点から、予防的コントロール層をどのように階層化するか、AWSエコシステムへの監査と可視性を得るために検知コントロールをどのように処理するかを決定する柔軟性をお客様に提供したいと考えています。これにより、クラウド内で強固なセキュリティ態勢を確保できます。
AWSのデジタルソブリンティ誓約とプラットフォーム準備状況
規制環境が時間とともに進化する中で、お客様が懸念していることを私たちは目にしてきました。AWSとして、お客様にビジネスをクラウドに持ち込んでいただきたいと考えており、イノベーションを起こし、より速く動く能力を常に説いています。しかし、Randyと私が何度も目にしてきたように、お客様は強固なセキュリティ文化をどのように確保できるかも理解する必要があります。そこで、お客様は、AWSが提供するすべてのサービスと機能を最大限に活用できるAWSパーティション内で環境を運用できるのか、それともより制限的なソブリンクラウドの観点に移行する必要があるのかを検討しなければなりません。これについては少し後で話しますが、お客様には選択する能力があるべきだと考えています。そして、それがデジタルソブリンティの誓約について話すところです。AWSの状況は、私たちのサービスを追いかけていただければわかるように、急速にイノベーションを起こし、お客様により多くの選択肢を提供しています。例えば、時間の経過とともに、お客様にとっての大きな課題の1つはVPCであり、ネットワーク内でそのトラフィックがどのように見えるかを一元的に把握することでした。そして最近、VPC暗号化コントロールを有効にしたので、環境内でどのような平文通信が行われているかを一元的に確認できるようになりました。
お客様は、そのようなより規範的なコントロールを活用し、環境内の脅威がどこにあるかを理解できるようになりたいと考えています。それが誓約の一部であり、サービスを継続的に進化させ、お客様がソブリンクラウドパーティションで運用できるようにより強力なものにする能力です。そこでは、既存の機能を提供し、それを本当に拡張しています。そうすることで、ワークロードに適用できるアクセス制限に関係なく、お客様は構築を続けることができます。
また、生成AIについてもお話ししますが、これは皆さんご存知の通り、技術スタックとして今や導入されているものです。セキュリティの観点から見ると、CIOを含むビジネスリーダーが理解する必要のある、より多くの課題をもたらします。どうすればイノベーションのレベルを維持しながら、同時にAWSを使ってセキュリティ体制を強固に保つことができるのか？私は多くの業界にわたって数多くのお客様に提供してきましたし、Randyも同様に、非常に規制の厳しい業界を含む様々な業界で実績があります。
プラットフォームの準備状況についてお話しし始めると、ここに多くのAWSサービスが表示されていますが、これらはすべて重要な役割を果たしています。すべてを統括する単一のサービスというものはありません。ネットワーク制御を重ねたからといって、それがアイデンティティアクセス管理も提供してくれるわけではありません。ここでの考え方、そしてこれが私たちのLanding Zone Acceleratorソリューションが活躍する場面なのですが、これらすべての要素を結びつけることです。同時に、エコシステム内のセキュリティリスクを特定して軽減し、ネットワークを保護し、データを保護し、特に高度に規制されたデータを扱い始めるときには、データの流出のような様々なシナリオを防ぐことを確実にしています。様々な規制フレームワークで作業している場合、これは常に防がなければならない典型的な悪夢のシナリオです。
これは多くのコンプライアンス要件ですが、AWSの観点から見ると、AWSがサポートしているセキュリティ標準とコンプライアンス認証は143まで増えていると思います。皆さんがよくご存知かもしれない人気のあるものには、FedRAMP、GDPR、HIPAAなどがあり、これらは非常に一般的です。NIST 853も多くのお客様の間で広く使用されています。これは、LZA、つまりこのソリューションが、エコシステム内でこれらのスケーラブルな制御を展開しようとしている大きな範囲です、特に環境をスケールアウトし始めるときには。
Landing Zone Accelerator on AWSの概要とUniversal Configuration
ここからLanding Zone Accelerator自体についてお話ししていきます。 私はセキュリティコンプライアンスと、お客様が遵守しなければならない規制フレームワークについて何度も言及してきましたが、それはまた、お客様が多くのデジタル資産をより適切に保護するために、そのフレームワークに適合しない独自のセキュリティ制御を採用する必要がある基本層でもあります、特に高度に規制された環境で作業し始めるときには。そのような環境こそが、LZAソリューション自体が構築された場所であり、私たちはそれをオープンソースとして設計しました。これにより、可能な限り最も安全なソリューションを確保するという点で、全体的なコミュニティからより多くのフィードバックを得ることができました。通常のパーティションを超えて動作するだけでなく、深いセキュリティ要件を持つ本当に制限の厳しいお客様向けに、GovCloudや他のパーティションでも動作します。
LZAの背後にある考え方は、ソリューション内での拡張性、可視性、そしてモジュール性に焦点を当てた、本当にバランスの取れたアプローチを提供したかったということです。Randyがソリューション自体について本当に深く掘り下げ始めると、もう少し詳しく触れますが、これはDOD、NATSEC、多くの公共部門のお客様、さらにはグローバルな観点から民間部門にも進出している、多くのお客様が使用しているモデル構成です。私たちは、というよりLZAは、AWS Cloud Development Kit、AWS CDKに大きく依存しており、多くの動的なプロビジョニングに使用しています。これについては、私たちがその基盤技術をどのように活用しているかをご理解いただけると思います。
LZAソリューションはAWS Control Towerとかなり密接に結びついています。その観点から、
皆さんが独自のランディングゾーンを運用・構築し、これらのコントロールがビジネスニーズにどのように適合するかという観点で、独自の規範的なコントロールを重ねていく際に、LZAとControl Towerの組み合わせは、すべてのお客様に使用することを強くお勧めしているものです。ただし、AWS Control Towerは、ソブリンクラウドパーティションについて話し始めると、一部のリージョンでは利用できないことを理解しておく必要があります。そこでLZA側のモジュール性コンポーネントが活きてくるわけで、LZAと、お客様の環境にプロビジョニングできるすべてのガバナンスリソースを引き続き活用できるようになっています。
プラットフォームの準備について話し始めると、多くの設計上の選択肢が出てきます。例えば、Service Control PoliciesやResource Control Policiesのような組織ポリシーを活用して、予防的コントロールをどのように重ねていくか。データの流出をどのように防ぐか。分離されることを意図したこれらのワークロードが、VPCピアリングやインターネットゲートウェイのアタッチメントを行わないようにするか。ネットワークトラフィックが決して外部に出ないようにしたいか。インシデントレスポンスやアイデンティティアクセス管理のような、こうしたセキュリティの概念を数多く取り入れ始めると、それぞれのセキュリティピラーにあるこれらすべての要素が、AWS内でそのセキュリティポスチャを維持するためにどのように組み合わされているかが見えてきます。
そこで、Randyと私はLZA Universal Configurationを開発しました。ここで抽象化のレベルについて説明すると、LZAはCDKを利用するソリューションです。お客様の入力に基づいて、環境を動的にプロビジョニングしていきます。このコンフィギュレーションは規範的なガイダンスであり、さまざまなコンプライアンスフレームワークに対応するために私たちが開発したセキュリティワークブックについても触れていきます。これを最初に設計した際、私たちは本質的に、規制対象のお客様のグローバルな代表例を持ちたいと考えていました。
LZAはANZ、EMEA、北米で採用されているグローバルに採用されているソリューションであるため、GDPRやドイツのC5、そしてNIST 800-53のような、それぞれのフレームワークにマッピングされるセキュリティコンプライアンスワークブックを確実に用意する必要がありました。NIST 800-53も広く採用されているフレームワークです。私たちは、これを継続的に反復するサポートモデルを確実に持ちたいと考えており、Randyと私がそれらのリンクを提供できるようにします。Universal Configuration自体は、私たちのWell-Architected FrameworkとSecurity Reference Architectureに基づいており、強固なセキュリティポスチャを維持し、それらのコントロールを規制基準に整合させることを確実にしています。
LZAの拡張性とコンプライアンスワークブック：グローバル採用への道
また、ご覧いただくとわかるように、ネットワーキングも組み込まれており、これが重要になってきます。LZAではさまざまなWANパターンがサポートされており、お客様のユースケースに基づいたさまざまなネットワークおよびセキュリティプロファイルを用意しています。すべてのお客様が同じというわけではありません。お客様にはそれぞれ対処しなければならないビジネス上の課題やセキュリティ上の課題があります。そこで私たちは、お客様が業界や地域のガイダンスパッケージを活用できるようにするとともに、さまざまなISV製品について話すときにLZAが提供する拡張性レイヤーも活用できるように、お客様に選択肢を提供したいと考えました。
クラウドに移行するお客様は、クラウドで活用したい特定のテクノロジーに非常に強みを持っている場合があります。厳しい期限内に移行しなければならない場合、お客様はAWS内でセキュリティ体制を維持できるよう、そのサービス機能に引き続き依存したいと考えています。LZAは、私たちがお客様と接してきた中で、変革をもたらすものとなっています。私は2016年にAWSに入社し、2017年からお客様とランディングゾーンに取り組んできました。これは以前は非常に長いプロセスでしたが、ランディングゾーンがどのようなものになるかの全体像が見えてくると、開発フェーズに入っていました。LZAが本当に開発のタイムラインを短縮しているのはそこなんです。私たちがすべてのオーケストレーション要素をお客様に代わって処理しますので、お客様がそれをする必要はありません。
そのため、LZA自体のグローバルな採用が始まっているのを目にしています。高度に規制された業界のグリーンフィールドのお客様に対してLZAを活用し、本当に必要とされるマルチアカウント構造を提供できます。小規模な環境であっても、お客様は災害復旧やビジネス継続性計画の要件を念頭に置く必要があり、それによってマルチリージョン環境での運用が必要になります。そこで、スケーラブルなコントロールを導入する必要が出てくるのです。
それから、ワークブックについても触れました。これらのワークブックは、AWS ArtifactにUniversal Configurationの一部として掲載されており、私たちが設計・構築したUniversal Configも一般公開されています。しかし、これは監査担当者の観点から広く使用されているNIST 800-53のほんの一部です。監査担当者は、お客様の環境で特定のコントロールをどのように処理しているか、それが予防層なのか検知層なのか、インシデントへの対応方法を理解したいと考えます。そこでLZAが役立ちますし、同時に私たちはこれらのコントロールを重ねることで、少なくともお客様の環境内でコンプライアンスを維持する能力を加速させています。
C5は、規制の観点から、特にヨーロッパで見られるもう一つの例です。そのため、European Sovereign Cloudが登場しました。彼らの規制フレームワークは非常に速く変化しており、お客様がこれらの変化に追いつき、同時にこれらのコンプライアンス規制要件を遵守することは非常に困難です。それでは、ユーザビリティの観点から、LZAソリューションについてはRandyに引き継いでさらに詳しく話してもらいます。これはオープンソースですので、LZAソリューションを使用する際には、実装ガイドを参照して、お好きな環境にインストールできます。機能リクエストや問題、LZAソリューションに関連するあらゆることを報告していただければ、私たちのチームがそれを確認して対応します。デフォルトで、LZAソリューションにはYAML設定ファイルによる多くの拡張性と機能が用意されています。私たちは、お客様がAWS CloudFormationを深いレベルで理解する必要がないよう、ユーザーエクスペリエンスを非常にシームレスにしたいと考えました。YAML設定を提供し、お客様の入力を受け取り、それをCDKを使用するLZAエンジンに取り込みます。そこから、お客様の入力を受け取りながら、コントロールのマルチアカウント、マルチリージョンのスケーラビリティを処理します。それでは、ハイレベルでは以上です。Randy、お願いします。
Security Hubのセットアップ：LZAとCDKを活用したコード実装
ありがとうございます。さて、実は私はかなりワクワクしています。これはコードトークですので、LZAのコードに本当に深く入り込むことができます。まず高いレベルから始めて、LZAが可能にする設定オプションの一つの例を通して進めていきます。具体的には、LZAを通じてSecurity Hubをセットアップしていきます。通常どのように行われるのか、いくつかのオーケストレーションステップ、LZAを通じてどのように設定するのか、そしてコードベースに深く入り込んでいきます。
LZAは、Boが言っていたように、オープンソースですので、私たちがやっていることに明らかに秘密はありません。しかし、私たちがあまり頻繁にできないことの一つは、環境内のすべてのアカウントとリージョンに触れることができるようにCDKをどのように活用しているかを実際に説明することです。これはかなり標準的なセットアップです。これは私たちのUniversal Configuration内にあるアカウント構造で、標準的なセキュリティOUとワークロードOUがあります。一般的にはdev、test、prodのOUに分けますが、ここでは単に汎用的なワークロードOUとしています。そして管理アカウントがここではルートアカウントになります。
Security Hubをセットアップして、それを環境全体にセットアップしたい場合、 もちろんOrganizationsが有効になっていることを確認する必要があります。そしてその管理アカウント、つまり ルートアカウントから、 セキュリティ監査アカウントやセキュリティツーリングアカウントにSecurity Hubを委任して設定したい場合、そのアカウントで有効にして委任を渡す必要があります。そして最後に、その委任が完了したら、すべてのワークロードアカウントも設定されていることを確認して、それらのアカウントで何が起こっているかの状況認識を持てるようにします。
そして最後に、 Security Hubを使ったことがある方はご存知だと思いますが、いくつかのフレームワークでは、Configメトリクスとアラームが設定されている必要があり、CloudTrailのようなロギングイベントがそれに供給されることで、発見事項を特定して設定するのに役立ちます。つまり、これもまた、委任して別のアカウントに移し、環境全体、そして有効にしているすべてのリージョンで有効にしたいAWSセキュリティサービスの多くにとって、かなり標準的なアーキテクチャです。しかし、ご覧のとおり、コンソールを通じて進めていく場合、これを完了するには6つのステップがあります。
LZAでは、Boが話していたように、環境を記述するためにYAMLファイルを使用します。
このケースでは、ここにトップレベルが表示されています。委任された管理アカウントは、私たちの監査アカウントにしたいと考えています。これは単に1つの標準、つまり基盤となるセキュリティのベストプラクティスを設定しているだけで、その後、私たちが設定した一連のConfigルール、メトリクス、アラームが表示されます。もしLZAに精通していて以前使用したことがあれば、これは私たちのsecurity config YAMLの中にあります。これらはLZAに入力される情報で、それによってCDKエンジンを駆動することができます。
最終的な結果として、これらすべてのリソースをデプロイするCloudFormationテンプレートが得られます。以前の図にあったアーキテクチャ要素のすべてを有効にするためだけに、約14のリソースがあります。ただし、これはすべてのオーケストレーションステップを考慮していません。Landing Zone Acceleratorにはデプロイメントパイプラインも付属しており、A、次にB、次にCというオーケストレーションと依存関係を理解し、どのスタックをいつデプロイする必要があるかを把握しています。
では下に進んでいきますが、先ほど申し上げたように、LZAはオープンソースプロジェクトです。このQRコードは、コードを見たい場合に私たちのGitHubリポジトリに直接アクセスできます。そこに私たちのドキュメントがあり、そこで顧客からのフィードバックを受け取り、そこにさまざまなロードマップアイテムやイシュー、ソリューションのリリースノートを公開しています。私たちのmonorepoの構成ですが、これはTypeScriptプロジェクトです。TypeScriptを使用しているのは、CDKだからです。私たちはCDKを直接実行しているので、CDKプロジェクトの構築方法に非常に密接に沿っていきたかったのです。
私たちのmonorepoには4つの主要なモジュールまたはパッケージがあります。トップレベルのacceleratorプロジェクトがあり、これにはトップレベルのCDKアプリケーションと、LZAをデプロイする際に表現されるすべての異なるスタックが含まれています。コードベース全体で共有しているため、別のconfigパッケージがあります。そのため、コードに注力し、それを別のライブラリとして持つことにしました。それからライブラリアプローチと同様に、私たちが構築しているカスタムコンストラクトについても、CDKのパラダイムに非常に近い状態を保ちたいと考えています。つまり、スタックがあり、そのスタックがコンストラクトを利用します。これらのコンストラクトは、デプロイしたいCloudFormationオブジェクトやリソースのコレクションを表しています。LZA固有のものはすべて、constructsライブラリに保管しています。
最後に、CDKを少し超えて拡張し、moduleライブラリも構築しています。これらのモジュールはLZAの外部で使用できます。統合することもできますが、これによって可能になるのは、従来カスタムリソースで行っていた多くのことを、モジュールに移行し始めているということです。そうすることで、APIやサービスクライアントを直接呼び出すことができます。
それでは、コードに入っていきます。すべてのコードとデザインドキュメントはフローチャートから始まります。これが、先ほど構築していたSecurity Hubのユースケースのコールフローです。これはCDKアプリケーションで、すべては私たちのacceleratorプロジェクトから始まります。acceleratorパッケージから、設定を読み込みます。configライブラリに読み込みを依頼します。ライブラリは初期検証チェックを行い、構文が正しいことを確認します。読み込みが完了したら、ソリューションの一部として持っている各スタックの処理を開始します。
そして、それが私たちのモジュールに移ります。先ほど申し上げたように、カスタムリソースにあったアイテムの一部を移動し、今ではモジュールを直接呼び出すようにしています。その一つが、例えば、Security Hubフレームワークのセットアップと、Security Hubが動作していることを確認することです。そして最後に、CDKプロジェクト、つまりこの場合はCDKスタックの本質的な部分に入っていきます。ここでは、セキュリティリソーススタックを構築しています。セキュリティリソーススタックには、configルール、メトリクスとアラーム、その他デプロイされるセキュリティサービス関連のリソースが含まれています。これらのコンストラクトとライブラリは、カスタムコンストラクトライブラリからのものであればそこから取得しますが、通常のCDKプロジェクトに常駐しているものを使用できる場合は、それらも活用します。
LZAのコードベース詳細とマイグレーション戦略：質疑応答セッション
それでは、下に進んでいきましょう。コードを少し見ていきます。これが私たちのcreate security resources stackです。
ここで重要な点は、Landing Zone Acceleratorをすべての商用リージョンだけでなく、非商用リージョンやその他のパーティションでも動作するように構築したということです。初日から私たちのコードの大きな部分は、リージョンセーフでパーティションセーフなコードを書くことを確実にすることでした。ですので、GovCloudのようなパーティションやそのような他のリージョンにいる場合でも、LZAはそれらの環境で動作します。
この特定のスタックは、CDKの素晴らしさを示しています。それは、より高レベルのロジックを書くことができるということです。デプロイメントエンジンの一部として、スタックを含めるべきか、構築すべきかどうかを理解できます。パイプラインでは、あるステージで組織のステップを実行し、別のステージでセキュリティリソースを実行し、さらに別のステージでネットワーキングを実行するというオーケストレーションがあることがわかります。各ステージで、そこで必要とされる適切なスタックをデプロイしていることを検証します。そして最後に、CDKに精通している方ならご存知でしょうが、これは単純なセキュリティリソーススタックの呼び出しです。つまり、そのオブジェクトをインスタンス化し、説明を渡し、独自の特定のシンセサイザーを構築しています。これにより、一度に複数のスタックをデプロイおよび合成できます。私たちは、お客様が持つ可能性のある環境全体にデプロイする必要がある数百または数千のスタックすべてを生成できるように、実行しているコンピュートを最大限に活用しようとしています。
それでは、そのセキュリティスタックが実際にどのようなものかを詳しく見ていきましょう。私たちは最善を尽くしていますし、私たちのコードはオープンソースなので、お客様やパートナーの方々が見ていることを理解しています。ですから、できる限り読みやすく保つよう努めています。これはそのスタック内のコンストラクタコンストラクターの実際の抜粋です。ご覧のように、小さな部品を関数にカプセル化するようにしています。これにより、それぞれの関数をより小さなマイクロレベルでテストできるため、テストが容易になりました。そして、今年のre:Inventのテーマでもありますが、AIツールがそこにあるコードをより理解しやすくなります。ですから、私たちはAmazon Q Developerなどのツールを積極的に活用して、コードの評価や作成を支援しています。
もう少し詳しく見てみましょう。ここではAWS Configルールの設定を行っています。これはcreate AWS Config rules関数で、あのYAMLファイルにデプロイしたいルールのリストがあったのを覚えていると思いますが、これはCDK内にいるからこそ活用できる純粋なシリアルロジックです。繰り返しになりますが、CloudFormationのような他のソリューションも素晴らしいのですが、CDKがある理由は、スタックにどのリソースを配置するかを決定する際に、もう少しロジックベースの判断ができるようにするためです。CloudFormationもロジックをサポートしていますが、ご存知の方ならお分かりのように、コードとして書かれている方がはるかに表現しやすいです。
そのリストを処理していく中で、ルールがカスタムルールなのか、それとも通常のマネージドConfigルールの1つなのかを確認でき、それを私たちのコンストラクトライブラリまたは標準のCDKコンストラクトライブラリに渡して、それらのConfigルールをインスタンス化して構築します。そして、Configでサポートしている他の機能として、修復もサポートしています。ですから、マネージドルールに対するカスタム修復や、一般的に定義するルールに対する修復がある場合、そこでデプロイできるようになっています。
そして最後に、ここでの大きなポイントはこれがCDKプロジェクトであるということです。最終的には、最後にCloudFormationが生成されます。Landing Zone Acceleratorでは、その上にあるリソースで発生しているすべての依存関係を判断できます。この場合、Configレコーダーが有効になっていなければConfigルールを作成できないことがわかっており、Configレコーダーもスタック内、関数の上の方にデプロイされています。しかし、Configルールが作成される前にConfigレコーダーが生成されることを保証するために、それらの依存関係を設定する必要があります。
同じことがLanding Zone Accelerator内の多くのスタック全体に当てはまります。私たちが提供する付加価値の1つは、それらの依存関係を確実に処理できるようにすることです。そして最後に、ご覧いただけるのは生成されるCloudFormationです。これらはCDKによって生成されるCloudFormationテンプレートです。
環境の構築方法、環境における良い状態の定義、そしてこれらの安全な環境を構築する方法について、先ほど少しお話ししました。universal configurationのところで少し触れましたが、ここにあるリンクは2つのサイトへのリンクです。1つ目は、Landing Zone Acceleratorを活用したデジタル主権の観点から私たちが行っていることについて、より詳細に説明しているブログです。2つ目は、LZA用のuniversal configurationです。そのGitHubリポジトリの中には、設定そのものだけでなく、ドキュメントも含まれています。私たちは、なぜOU構造がこのようになっているのか、なぜ特定のConfigルールを選んだのかといった、合理性や理由について本当に詳しく説明するよう努めています。つまり、そのアーキテクチャに至った意思決定の背景にある多くの理由です。これにより、私たちのcompliance workbookという成果物を見て、なぜそのConfigルールが追加されたのか、なぜそのSCPが追加されたのかを、コントロールの観点からより理解するために必要な情報が得られます。
最後に、1つ前のスライドに戻りますね。というのも、質問があると思いますし、質問の時間を残しておきたいので、全部お伝えしたかったんです。今年はCloud Opsのトークトラックの一部として参加していますので、ぜひキオスクに来てください。ノベルティもあります。写真を撮っている方がいらっしゃったので、このスライドに戻りますが、何か質問があれば喜んでお答えします。LZA全般について、そして皆さんのユースケースにどのように適合するかについて、喜んで議論させていただきます。何か質問はありますか。
データに関する良い質問ですね。すみません、AWS European Sovereign Cloudのローンチについてですね。はい、ここで質問を繰り返してみます。sovereign cloudリージョンがローンチされたら、2つのLZAをデプロイする必要がありますか、1つはグローバルリージョン用で、もう1つはsovereignリージョン用ですか？正しく理解できていますか？はい、その答えですが、sovereignリージョンについて話すとき、あるいは商用リージョンについて話すときでも、そこで構築する場合、今日LZAをデプロイして、デプロイしたいリージョンを指定して構築することができます。拡張を始めて、商用リージョンの一部ではない別のパーティションについて話し始めると、それらのパーティション間には接続ポイントがありません。ですので、それは別のインスタンス化、つまり別のランディングゾーンを構築することになります。なぜなら、考え方としては、商用リージョンでこれを行う場合でも、2つの別々の組織、2つの別々の管理アカウントを持つことになるからです。そして、それによって決定する機会が得られます。sovereignリージョン内にとどまりたいというお客様もいれば、両方を利用するユースケースやコンプライアンス要件がある場合は、両方の環境を持つことになります。はい、わかりました。
他に質問はありますか？LZAがいつサポートするかということですが、質問はサポートがいつ来るかについてですね。Security Hubの機能について話しているのですか、それともSecurity Hubフレームワークについてですか？新しいサービス、CSPMですね。はい、お客様から確実に市場シグナルを受け取っています。私たちはオープンソースなので、フィードバックメカニズムの1つとして、内部と外部の両方で確認しています。ですので、そのサービスについては、現在のロードマップでは2026年の下半期ではなく、2026年の第2四半期を目指していると思います。
ああ、はい、そちらの方。モジュール入力については、基本的にすべてのYAMLファイルがどのようにレイアウトされるかを決定します。はい、そして私にとっては、AIの話題が盛んな中で、その入力をガイドするエージェントのようなものが必要だと思えます。そのようなものがロードマップにありますか？はい、そうだと思います。質問は、YAMLファイルとその編集について、そして確かにエージェントやAIツールの話題がたくさんある中で、それがどう関係するかということですね。私たちがAI分野に非常に力を入れていると言っても間違いないと思います。MCPについて話すとき、そしてYAMLファイルの構造がこれらのツールに適したものであることを確保するとき、私たちはその分野を非常に注視しています。ですので、はい、LZAは確実にその方向に進んでいます。うまくいけば、非常に近いうちにより多くの情報をお伝えできると思います。
いいですね。まず質問があります。ええ、クラウドマイグレーションまたは実装についてなんですが、おそらくここにいる組織の多くはグリーンフィールドではないと思います。すでに多くのものがあります。すでに導入されていることを願っています。この移行を行った顧客と接触したことはありますか？ええ、ええ、質問はマイグレーションについてですね。はい、既存のランディングゾーン、既存の組織、既にAWS内にデプロイされている既存のリソースを持っている多くの顧客を見てきました。そして、彼らがどのようにLanding Zone Acceleratorを活用できるかということです。いくつかのアプローチを見てきました。一方の端では、顧客がそれを、つぎはぎで作られた環境を廃止する機会として見ており、それらのワークロードを移行できるようにしています。つまり、グリーンフィールドとして扱うということです。また、顧客がLZAのセキュリティサービスを部分的に活用しているケースも見てきました。Service Control Policyの管理やそこにあるセキュリティサービスを活用できるようにするためです。そして、本番ワークロードがあり、ネットワーキングがかなり固定されていて、それらすべてがかなり静的である場合、それに触れたくないという傾向があります。
とはいえ、CDKとCloudFormationがリソースの引き受けと既存リソースの管理を可能にしているので、既存リソースをLZAにインポートできるようにして、それらと対話し、今後管理を開始できるようにすることを検討しています。また、Security Hubのような環境にすでにデプロイされているものを理解し、提供された設定を見て、そのマニフェストにシフトできるようにすることも、私たちのモジュールの焦点の一つです。つまり、明示的にこのように見えるようにしたいということですね。
もう一つ質問があります。もちろん、組織構造と独自の構造についてどれくらい厳格かということですね。ええ、Landing Zone Acceleratorは分かれています。質問は、顧客がLanding Zone Accelerator内の組織構造とアカウント構造にどれだけ厳密に従わなければならないかということでした。LZAは2つの部分に分かれています。1つはデプロイメントエンジンです。コードベースがどのように機能するかを少し説明しました。そして、それに供給する設定があります。これは、例えば、私たちのユニバーサル設定の中にあります。エンジン自体は、YAMLファイルを通じて指示したものを何でもデプロイします。つまり、この組織構造が欲しい、これらのアカウントをこれらの組織単位にデプロイしたいと指示できます。そこにあるものを非常にコントロールできます。
しかし、非常に規範的な環境や、私たちが行ってきたコンプライアンス作業の多くを本当に活用している環境について話すとき、それが私たちがユニバーサル設定を構築した理由です。つまり、コントロールが配置され、Service Control Policiesが配置された組織構造を構築する方法を、今日環境を迅速にハイドレートして立ち上げたい場合に、より多く提供するためです。つまり、長々とした答え方になりましたが、LZAに何でも好きなものをデプロイするよう依頼できます。しかし、私たちのWell-Architectedフレームワークとセキュリティリファレンスアーキテクチャに基づいて、おそらくデプロイすべきものについて意見を持っています。はい。
他に質問はありますか？わかりました。BoとI私は明らかにしばらくここにいます。Landing Zone Acceleratorに何が含まれているか、特にソブリンリージョン空間で私たちが何をしているかについて、より詳細に掘り下げることができます。他に質問があれば、気軽に来てください。外で待機しますし、明らかにここでも当面の間いますが、ええ、もし機会があれば、Cloud Opsキオスクがビレッジにあります。そこにはスワッグやデモや、ワークショップがありますが、ええ、来ていただいて、私たちがやっていることについて聞いていただいた時間に感謝します。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion