AWS Landing Zone Acceleratorとは
AWS Landing Zone Accelerator（LZA）とは、Amazon Web Services（AWS）の提供しているソリューションの１つです。AWSの"ソリューション"のため、AWSサポートも（Developer,Business,Enterprise相当であれば）利用できます。
LZAでは、YAMLの設定ファイル群を元に、マルチアカウントの"共通基盤"（Landing Zone）を作成する、IaCパイプライン（Core Pipeline）が提供されます。また、そのIaCパイプライン自体を更新するための管理用パイプライン（Installer Pipeline）も含まれます。AWS公式のLZA紹介ページはこちらです。
また、LZAでは様々な業界や規制（例えばISO/IEC 27001）のベースラインとなる設定ファイル例が公開されており、これらを利用することでセキュアなマルチアカウントAWS環境を素早く立ち上げることができます。（もちろん、LZAだけで100%準拠ではありませんが、ゼロから構築するよりは素早く立ち上げをすることができます）
LZAの開発の大半は、LZAの設定ファイルのドキュメントを確認することで進められますが、本記事ではさらに円滑に開発を進めるために役立つ、LZAの各パイプラインステージ・スタックで何が行われているかについて、ソースコードを少し追ってお伝えします。
本記事で取り上げるような処理がどの部分で記載されているか、概要を把握することで、より詳細に処理を知りたい場合のソースコードのあたりがつけられるようになります。
尚、LZAバージョンは、執筆時点で最新の1.13.1を対象としています。LZA自体も継続的に開発されているため、お使いのバージョンに合わせての確認が必要です。
LZAの開発での課題と各パイプラインステージ処理詳細を知るメリット
LZAは非常に便利なのですが、IaCかつ多機能なパイプラインという特性上以下の課題に直面する場合があります。
- デプロイに時間がかかる。
- トラブルシューティングが難しいケースがある。
1.についてはアカウントの作成からSCPの管理、NWの設定まで単一のパイプラインで実施するため、どうしてもリリース完了までに時間がかかります。（構成にもよりますが、30分以上要する場合もあります。）
開発環境など、環境の一貫性よりも開発速度が重要な場合においては、このサイクルの長さが課題となります。
1の課題の対応策として、開発者向けドキュメントに記載があるように、Code Pipeline中で実行される、特定のスタックに絞っての実行をすることができます。この場合は全体のパイプラインを待つことなく素早く部分的に適用ができるのですが、この場合各ステージ・スタックで何が行われているかを知らないと、どこを実行すればよいかわからないという課題があります。
各ステージやスタックでどのような処理が行われているかを理解していれば、適用すべきスタックをすぐに判断できます。
- NetworkVpcStackを実行して、ALB本体は作成されたが、リスナーが作成されていない⇒リスナー設定はNetworkAssociationsStackで行われる。
- NetworkAssociationsStackを実行したがルートテーブルが変更されない⇒ルートテーブルの変更はNetworkVpcStackで実施される。
このように各ステージやスタックの役割を把握しておくことで、どのスタックを実行すべきかを素早く判断でき、効率的に開発を進められます。
2については同じくアカウントの作成からSCPの管理、NWの設定まで実行する多機能なIaCということから、デプロイに失敗したときに原因特定に苦労するケースがどうしても発生しえます。
公式のトラブルシューティングガイドなどもありますが、こちらのケースについても各スタックで何が行われているかを知ることでより円滑にトラブルシューティングを行うことができます。
Coreパイプラインの構成
基本
Coreパイプラインのステージとスタック構成については、公式ドキュメントに記載があり、何を行ってるかの概要の把握であれば公式ドキュメントで十分です。一方で、名前の似ているスタックがあるなど、細かく各スタックで何が行われているかを確認するには、ソースコードを確認する必要がある場合があります。
Coreパイプラインの構成は、こちらのコードで定義されています。このディレクトリ近辺のコードを確認することで各スタックの処理詳細を知ることができます。
各ステージ・スタックの詳細
Prepare
開発者向けドキュメントに記載の通りアカウント作成が行われていますが、それに加えて、差分検知方式で利用されるDynamoDBの作成などがされています。
トラブルシューティング時はこのDynamoDBが関わってくることがあり、特にSCP回りでエラーが出た場合については、対処の仕方によっては、このDynamoDBに記録されているOUやアカウントとSCPの紐づけが、不整合となってしまう等の場合もあるため、『DynamoDBでも差分管理されている。』ということは頭に入れておくとトラブルシューティングがしやすくなります。
Accounts
ほぼ開発者向けドキュメントに記載の通りの処理のみ行われています。
加えると、Organizationレベルで設定するGuardDutyやConfig等のためのロールも作成されています。
留意点として、Quarantine（初期アカウント作成時にセットアップ完了まで、一時的にすべてをDenyするSCPを付与する処理）を行う場合は、ここでSCPが追加で１つアタッチされるため、SCP数のクォータはこのQuarantine分を勘定に入れておく必要があります。
Logging
このステージについては、開発者向けドキュメントの通りと認識してよいと思います。
ログ集約のためのKMSキーや、集約S3バケット、集約自体の設定が行われます。
Organization
こちらもほぼ開発者向けドキュメントの記載の通りと認識していいと思います。
CURやIAM Access Analyzer、またSCP以外のポリシー（バックアップポリシー等）のOrganizationで設定するような機能が設定されます。
Security_Audit
Security系は複数ステージにまたがっているためやや把握が難しいです。
開発者向けドキュメントの『Deployment of resource dependencies』の記載は、大枠機能の有効化と理解するとイメージが近いです。例えばSecurity Hubの有効化や、GuardDuty+GuardDutyの各種拡張の有効化が行われます。
また、自動修復用のSSM Automationはこのステージで配られています。
Network_Prepare
数が多く、それぞれのスタック何が行われているかの把握が難しいNetwork系スタックの１つです。
VPC自体は作られず、TransitGatewayの本体などが作成されます。
ドキュメント的には、AWS RAM sharesでまとめられているため見落としやすいですが、留意が必要なところとしては、AWS Network Firewallのルールグループなどはこのスタックで作られます。
AWS Network Firewallのエンドポイント実体は後続で作成されるのですが、ルール自体はこのスタック管理のため、ルールを更新する場合はこのスタックがターゲットになります。
Security
開発者向けドキュメントでは、各メンバアカウントでのセキュリティ系サービスの設定がされるとの記載ですが、具体的には、SecurityHubのStandardの有効化や、IAMのパスワードポリシーの更新などが行われます。
Operations
主には開発者向けドキュメントの通り、IAM Roleやポリシーの作成が実施されますが、特筆すべき点としてはほかにクォータの上限緩和申請がこのスタックで実行されます。
NetworkVpcStack
Network系の複数あるスタックの中で、比較的ネットワークと聞いてイメージがつきやすいリソースを作成するスタックです。VPCやSubnetの他、VPC側のルートテーブルの作成やLoadBalancer本体の作成が行われます。
凡そ１つのVPCに閉じるリソースについてはこのスタックで作成されます。
NetworkVpcEndpointsStack
こちらは名前の通りです。ドキュメントの通り、EndpointにはPrivateLink以外に、AWS Network Firewallのエンドポイントや、Route 53 Resolverのエンドポイントも含まれます。
NetworkVpcDnsStack
こちらも名前の通りです。Private Hosted Zoneの作成と、DNS Forward Ruleの作成などを行います。
Security_resources
セキュリティ系設定の最後の設定となります。
主だったところとしては、Configのルール設定はこのスタックで行われます。
また、CloudWatch Alarmの設定もここで実施されます。LZAにおけるCloudWatchアラームはCloudTrailのログを監視して発見的統制を実施する等に利用される等セキュリティとしての用途に利用されているため、Securityの名を冠したこのスタックで行われていると理解しています。
NetworkAssociationsStack
GWLBによるトラフィック検査を行わない場合、このスタックがほぼ最後のネットワーク関連処理となります。ここでは主にVPC間の接続（VPC Peeringや、TransitGatewayのルートテーブル等）が行われますが、留意点としてLoadBalancerのリスナーや、ターゲットグループはここで作成されます。
Load Balancer系については、本体はNetwork_VPCで作成されますが、リスナーなどはこのスタックまで来ないと設定が更新されません。
NetworkAssociationsGwlbStack
開発者向けドキュメントにある通りにGWLB関連の設定ですが、customizations-config.yamlで設定するアプライアンス用のインスタンスの作成もここで行われます。
Customizations
こちらは開発者向けドキュメントの通りです。customizations-config.yamlで定義されたStacksetsのデプロイや、サービスカタログの配布が行われます。
Finalize
こちらも開発者向けドキュメントの通りです。
Quarantine用のSCPがここまできてようやく解除されます。
configファイルについて
また、これらのソースを見ていると、configファイルパラメタに気になる点が出てくることがあります。
ドキュメントは随時アップデートされていますが、パラメタの型やパラメタの全量について、気になる点があった場合は、パラメタの型定義がされているソース（例：security-configの場合はこちら）を確認した方が良いケースもありますので、合わせて把握するとより役立ちます。
まとめ
開発者向けドキュメントの記載でもLZAの動作は大まかに把握することができますが、”設定する”といった際に、どの範囲が設定されるのか？というところまで把握することで、より効率的に開発をすることができます。
Landing Zone Accelerator自体も継続的に開発がされているため、各ステージやスタックでの実施内容は変更となる可能性はありますが、どのあたりに処理が書かれているかというのを把握しておくとアップデートにも追従しやすくなります。
仲間募集中です！
NTTデータ クラウド&データセンタ事業部では、以下の職種を募集しています。
- プライベートクラウドコンサル/エンジニア
- デジタルワークスペース構築／新規ソリューション開発におけるプロジェクトリーダー
- IT基盤(パブリッククラウド、プライベートクラウド)エンジニア
- パブリッククラウド/プライベートクラウドを用いた大規模プロジェクトをリードするインフラエンジニア
ソリューション紹介
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。