2026.06.02

LZA UCとは何か：LZAの設計・導入はどう変わるのか

yoshi

シリーズ： Control Tower経験者のためのLZA入門（第2回）
対象読者： 前回の記事を読んだ方、またはAWS Control Tower/LZAの概要を理解しているAWSエンジニア
この記事のゴール： LZAのアーキテクチャを少し掘り下げたうえで、Universal Configuration（UC）がLZAの設計・導入をどう変えるのかを理解する

Contents

1. はじめに ― 前回のおさらい
2. LZAのアーキテクチャをもう少し見る
3. LZAだけでは「何を設定すべきか」は決めてくれない
4. サンプル構成からUCへ
5. UCとは何か
6. LZAとUCで何が変わるのか
7. UCが定義する主なベースライン
8. UCを使うときの導入イメージ
9. まとめ ― UCはLZAの設計済みスタート地点
参考リンク

1. はじめに ― 前回のおさらい

前回の記事では、AWS Control Towerだけでは対応しきれない本番運用向けの設定を、LZA（Landing Zone Accelerator on AWS）でどのように拡張できるのかを紹介しました。

LZAは、Landing Zone全体の設定をYAML設定ファイルで定義し、パイプラインを通じてマルチアカウント・マルチリージョンに展開するソリューションです。

Control Towerがマルチアカウント環境のベースラインを整えるサービスだとすると、LZAはその上に、SCP、セキュリティサービス、ネットワーク、ログ、IAMなどの追加設定をコードとして適用する仕組みです。

ただし、LZAを使うには大きな課題もあります。

それは、設定ファイルをどのように設計すべきかを自分たちで判断する必要がある という点です。

LZAでは多くの設定を柔軟に定義できますが、その分、OU・アカウント構成、SCP、セキュリティサービス、ネットワーク、ログ、IAMなどについて、どのようなベースラインにすべきかを決めなければなりません。

そこで登場するのが Universal Configuration（UC：共通ベースライン構成） です。

本記事では、前回詳しく触れなかったLZAのアーキテクチャを補足したうえで、UCによってLZAの設計・導入がどう変わるのかを見ていきます。

2. LZAのアーキテクチャをもう少し見る

前回の記事では、LZAを「YAML設定ファイルをもとに、パイプラインでAWS環境へ設定を展開する仕組み」と説明しました。

ここでは、そのパイプラインの構成をもう少しだけ掘り下げます。

LZAはCloudFormationテンプレートからデプロイでき、デプロイ後は主に2つのパイプラインで構成されます。

パイプライン	役割
Installer Pipeline	LZA本体とCore Pipelineをデプロイ・更新するためのパイプライン
Core Pipeline	YAML設定ファイルを読み込み、Landing Zoneの設定を各アカウント・各リージョンへ展開するパイプライン

Installer Pipelineは、LZAのバージョン管理やCore Pipelineの再デプロイを担います。

一方、普段の運用で中心になるのはCore Pipelineです。Core Pipelineは、設定ファイルを読み込み、検証し、CDK/CloudFormationを通じて各AWSアカウント・各リージョンへリソースを展開します。

Landing Zone Accelerator on AWS のアーキテクチャ図

出所：Landing Zone Accelerator on AWS - Architecture overview
https://docs.aws.amazon.com/ja_jp/solutions/latest/landing-zone-accelerator-on-aws/architecture-overview.html

この図では、LZAが設定ファイルをもとに、パイプラインを通じて複数アカウント・複数リージョンへCloudFormationスタックを展開する流れを確認できます。

Core Pipelineでは、概ね以下のような処理が行われます。

設定ファイルとLZAのソースコードを取得する
設定ファイルを検証する
設定ファイルに定義されたアカウントを作成・検証する
SCPなどのOrganizations関連設定を適用する
CDKでデプロイするための事前準備（CDK bootstrap）を行う
設定内容に応じて、セキュリティ、ログ、ネットワークなどのリソースを展開する

ここで重要なのは、利用者が主に編集するのはYAML設定ファイルであり、CDKアプリケーションを直接実装するわけではないという点です。

LZAは、設定ファイルに書かれた内容をもとに、AWS環境へ継続的に変更を適用するための実行基盤と捉えると理解しやすいです。

3. LZAだけでは「何を設定すべきか」は決めてくれない

LZAは非常に強力ですが、自由度が高い分、利用者側で多くの設計判断が必要になります。

たとえば、次のようなことを決める必要があります。

OUとアカウントをどのように分けるか
どのSCPを、どのOUやアカウントに適用するか
GuardDuty、Security Hub、AWS Config、Macieなどをどの範囲で有効化するか
IAM Identity CenterやPermission Setをどのように設計するか
ログをどのアカウントに集約し、どの期間保持するか
ネットワークをHub & Spoke型にするか、Shared VPC型にするか
どのリージョンを有効化するか
どのコンプライアンス要件をどこまで満たすか

つまり、LZAはLanding Zoneをコードで展開する仕組みを提供しますが、どのようなLanding Zoneを作るべきかは自分たちで設計する必要があります。

この設計判断は、大規模なマルチアカウント環境や、セキュリティ・コンプライアンス要件が厳しい環境では特に難しくなります。

そこで、LZAの設定ファイルにAWSのベストプラクティスをあらかじめ反映した共通ベースラインとして提供されているのがUCです。

4. サンプル構成からUCへ

以前のLZAでは、業種・リージョンごとのサンプル設定が reference/sample-configurations 配下に提供されていました。

しかし、LZA v1.13.1の reference/sample-configurations では、このフォルダにあったサンプル構成は LZA Universal Configuration（UC）に統合された 旨が案内されています。

参考：LZA v1.13.1 reference/sample-configurations
https://github.com/awslabs/landing-zone-accelerator-on-aws/tree/release/v1.13.1/reference/sample-configurations

これは、LZAの使い方が「個別のサンプル設定を探して修正する」形から、「UCという共通ベースラインを出発点にする」形へ整理されてきた、と捉えると分かりやすいです。

ここで注意したいのは、LZA自体はControl Towerなしでも利用できる一方で、UCを利用する場合はControl Towerが前提になる という点です。

つまりUCは、単なる設定ファイル集ではなく、Control Towerを基盤としたマルチアカウント環境の上に、LZAでAWSのベストプラクティス設定を適用するための共通ベースラインと考えるのが自然です。

5. UCとは何か

Universal Configuration（UC：共通ベースライン構成） は、LZAで利用できる設定ファイル群に、AWSのベストプラクティスに基づくベースラインをあらかじめ定義したものです。

LZA本体でも、SCP、セキュリティサービス、ネットワーク、ログ、IAMなどはすべて設定できます。

しかし、LZAだけでは「何をどの水準で設定すべきか」は利用者が判断する必要があります。

UCでは、その判断の出発点となる構成があらかじめ用意されています。

参考：LZA Universal Configuration - GitHub
https://github.com/aws/lza-universal-configuration

UCのポイントは、以下の3つです。

AWSのベストプラクティスに基づく共通ベースラインを提供する
SCP、セキュリティサービス、ネットワーク、ログ、IAMなどのベースライン設定をLZAの設定ファイルとして提供する
組織固有の要件に合わせて、YAML設定ファイルの値を変更しながらカスタマイズする前提で利用する

ここでいうカスタマイズは、CDKやCloudFormationのコードを直接変更するというより、LZAの設定ファイルに定義された値を組織要件に合わせて調整するイメージです。

重要なのは、UCは完成済みの最終形ではなく、本番向けLanding Zoneを設計するための出発点 だという点です。

UCをそのまま使えば、すべての組織要件を満たせるわけではありません。UCの設計意図を理解したうえで、自社のセキュリティ要件、ネットワーク要件、運用要件に合わせて調整していく必要があります。

6. LZAとUCで何が変わるのか

LZAとUCの関係は、次のように整理できます。

観点	LZAのみ	LZA + UC
出発点	空の設定ファイル、または個別サンプル	AWSのベストプラクティスを反映した共通ベースライン
設計判断	利用者が多くを決める	UCの設計を理解し、必要に応じてカスタマイズ
Control Tower	LZA単体では必須ではない	UC利用時はControl Towerが前提
OU・アカウント構成	個別に設計	Security / Infrastructure / Workloads / Suspended などの構成を提供
セキュリティ統制	個別に設計	SCP、GuardDuty、Security Hub、AWS Config、Macieなどを定義済み
IAM・アクセス管理	個別に設計	IAM Identity Center、Permission Set、標準IAMロールなどを定義
ネットワーク	個別に設計	Hub & Spoke / Shared VPC などの構成パターンを提供
コンプライアンス	利用者側で整理	UCの設定内容とLZA Compliance Workbookをあわせて確認しやすい

一言で言えば、LZAは Landing Zoneをコードで展開する仕組み です。

一方、UCはそのLZAに対して、AWSのベストプラクティスに基づく初期設計を与えるもの です。

これにより、利用者はゼロからすべてを設計するのではなく、UCの構成を出発点として、自社要件に合わせたカスタマイズに集中しやすくなります。

7. UCが定義する主なベースライン

UCでは、Landing Zoneに必要となる多くの設定があらかじめ定義されています。

ここでは、代表的な領域に絞って紹介します。

7.1 OU・アカウント構成

UCでは、Control Towerの標準構成をベースにしつつ、より実践的なOU・アカウント構成が定義されています。

出所：LZA Universal Configuration - Management and Governance
https://github.com/aws/lza-universal-configuration/blob/main/docs/03-Management-Governance/index.adoc

代表的なOUは以下です。

OU	役割
Security OU	Auditアカウント、Log Archiveアカウントなどを配置するセキュリティ・ログ管理の中枢
Infrastructure OU	Network、Shared Services、Perimeterなどの共通インフラ系アカウントを配置
Workloads OU	アプリケーションや業務ワークロード用のアカウントを管理
Suspended OU	廃止済み、または一時停止したアカウントを配置

Control TowerだけでもSecurity OUやAuditアカウント、Log Archiveアカウントは構成されます。

UCではそれに加えて、共通インフラを管理するInfrastructure OU、ワークロードを管理するWorkloads OU、停止・廃止したアカウントを配置するSuspended OUなどがあらかじめ用意されています。

7.2 セキュリティ統制

UCでは、複数のセキュリティ統制があらかじめ定義されています。

代表的なものは以下です。

OUやアカウントに適用するSCP
新規アカウントを一時的に制限するQuarantine policy
GuardDuty
Security Hub
AWS Config
Macie
ログ集約

特にQuarantine policyは、新しく作成されたアカウントに対して、ベースライン設定が完了するまで利用を制限するための仕組みです。

これにより、セキュリティ設定が適用される前のアカウントが利用されるリスクを減らしやすくなります。

7.3 IAM・アクセス管理

UCでは、IAMやアクセス管理に関するベースラインも定義されています。

たとえば、以下のような領域です。

IAM Identity Center
Permission Set
Permission Boundary
標準IAMロール

マルチアカウント環境では、アカウントごとに個別のIAMロールや権限設定を作り込むと、権限のばらつきや過剰権限、設定漏れが発生しやすくなります。

UCを利用すると、IAM Identity Center、Permission Set、IAMロール、Permission BoundaryなどをLZAの設定ファイルとして管理し、複数アカウントへ一貫して展開しやすくなります。

つまり、アクセス管理の標準形を最初から持てること、そしてアカウントごとの権限設定のばらつきを減らしやすいことが、IAM・アクセス管理面での大きなメリットです。

7.4 ネットワーク

UCでは、ネットワーク構成についてもベースラインが提供されています。

代表的には、以下のような構成要素があります。

Hub & Spoke構成
Shared VPC構成
Transit Gateway
Network Firewall
VPC Flow Logs
デフォルトVPCの削除

Hub & Spoke構成では、Transit Gatewayを中心に各ワークロードVPCを接続し、Network Firewallなどを用いてトラフィックを集中的に検査する構成を取りやすくなります。

一方、Shared VPC構成では、VPCを共通アカウント側で管理し、サブネットをワークロードアカウントと共有する形になります。

どちらが適しているかは、組織のネットワーク運用体制、セキュリティ境界、IPアドレス設計、コスト要件によって変わります。

8. UCを使うときの導入イメージ

UCを使う流れは、大きく以下のように整理できます。

Management Accountで、AWS提供のCloudFormationテンプレートからLZAのInstaller Stackを起動する
Installer Stackのパラメータで、Control Tower Landing Zoneを新規作成するか、既存のControl Tower環境と連携するかを指定する
LZAの初期デプロイが完了し、Core Pipelineが利用できる状態になるまで待つ
UCの設定ファイルを取得する
メールアドレス、アカウント名、リージョン、ネットワーク設定など、環境固有の値を更新する
設定ファイルをリポジトリへ反映する
LZAのCore Pipelineを実行する

Control Tower連携は、LZAのInstaller Stack作成時に指定するパラメータで制御します。

新規環境ではLZAからControl Tower Landing Zoneを作成できますが、既存のAWS Organizationsや既存アカウントがある場合は前提条件に注意が必要です。

そのため、既存環境に導入する場合は、事前にControl Towerの状態やOrganizations構成を確認したうえで、LZAと連携させる構成を検討します。

ここで重要なのは、UCを利用する場合でも、何も考えずにそのまま適用すればよいわけではないという点です。

特に、以下のような項目は組織ごとに確認・調整が必要です。