LASSIC Media らしくメディア
クラウド基盤のランディングゾーン構築を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- クラウドのランディングゾーンは、マルチアカウント設計・ネットワーク・IAM・ガードレール・ログ監査を最初にまとめて整える基盤設計です。
- AWS Control Tower・Azure landing zones・Google Cloudのlanding zoneは、それぞれ異なる仕組みで同じ考え方を実装しています。
- 設計フェーズで必要な知識領域は広く、内製と外注の切り分けが検討材料になります。
目次
クラウドのランディングゾーンとは、拡張前提で整える基盤設計
クラウドのランディングゾーンとは、マルチアカウント設計・ネットワーク・IAM(Identity and Access Management。利用者やシステムの権限を管理する仕組み)・ガードレール・ログ監査といった基盤要素を、拡張しても破綻しない形であらかじめ整える初期設計を指します*1。AWSはこの環境を、セキュリティとコンプライアンスのベストプラクティスに基づくwell-architectedなマルチアカウント環境と定義しています*1。
ランディングゾーンという言葉はAWS・Azure・Google Cloudの3社がそれぞれ用いる用語です。呼び方や実装方法は異なりますが、指し示す範囲は共通しています*1*3*5。組織構造・権限・ネットワーク・統制の土台を、個別システムを載せる前に用意しておくという考え方です。
クラウド移行そのものの進め方や移行時のセキュリティ設計とは、扱う工程が異なります。ランディングゾーンは移行やシステム構築に着手する前の、基盤そのものを整える段階に位置づけられます。
AWS Control Tower——マルチアカウント環境を短時間で構築する仕組み
AWSにおけるランディングゾーンの構築は、AWS Control Towerというサービスが担う仕組みです。Control TowerはAWS Organizations・AWS Service Catalog・IAM Identity Centerなど複数のサービスを連携させ、1時間程度でランディングゾーンを構築できると案内されています*1。
ランディングゾーンを作成すると、Control Towerは管理アカウントの配下にSecurity OU(Organizational Unit。組織単位)とSandbox OUを自動で作成します*2。Security OUにはLog ArchiveアカウントとAuditアカウントという共有アカウントが含まれ、ログの保管と監査の役割を最初から分離できます*2。
加えてControl Towerは「コントロール」と呼ばれるガードレールを適用します。予防的・検出的・積極的の3種類に分かれ、必須・強く推奨・任意の3段階のガイダンスが付いています*1。これは設定のドリフト(ベストプラクティスからの逸脱)を防ぐための仕組みとして機能します*1。
Azure landing zones——プラットフォームとアプリケーションの2層構造
Microsoftが提供するCAF(Cloud Adoption Framework。Azure導入の標準的な手法体系)では、Azure landing zoneを「Azureを利用するすべての組織に推奨される標準的なアプローチ」と位置づけています*3。
Azure landing zoneは、1つのプラットフォームランディングゾーンと1つ以上のアプリケーションランディングゾーンで構成されます*3。プラットフォーム側はID・接続・管理といった共有サービスを提供し、中央のチームが運用にあたります*3。アプリケーション側は個々のワークロード専用の環境で、開発・テスト・本番の各環境ごとに用意する形が基本です*3。
設計にあたってCAFは8つの設計領域を定義しています。課金とMicrosoft Entraテナント、ID・アクセス管理、管理グループとサブスクリプション構成、ネットワークトポロジ、セキュリティ、管理、ガバナンス、プラットフォーム自動化とDevOpsの8領域です*4。この順序で検討を進める設計プロセスが推奨されており、順を追って評価すれば複雑な環境でも設計を進めやすくなります*4。
Google Cloudのlanding zone——ID・階層・ネットワークの4要素
Google Cloudはランディングゾーンを「クラウド基盤(cloud foundation)」とも呼びます。企業がGoogle Cloudを業務要件に合わせて導入するための、モジュール式でスケーラブルな構成と説明されています*5。
設計の中核となるのはID管理・リソース階層・ネットワーク・セキュリティの4要素です*5。ID管理ではCloud Identityとオンプレミスの認証基盤を同期し、リソース階層ではResource Managerが組織ポリシーとともに階層構造を定義します*5。
ネットワークは共有VPC・ファイアウォールルール・Cloud NAT・Cloud Interconnectなど複数の要素で構成します*5。セキュリティ面では、VPC Service Controlsによる境界分離でデータ流出のリスクを抑える設計が採用されています*5。設計に入る前には業種・組織構造・セキュリティ要件を確認し、単一か複数のランディングゾーンが必要かを判断する工程も欠かせません*5。
ガードレールと権限統制——後から直すコストを避ける設計
ランディングゾーンの核心は、個別システムを載せる前に統制の枠組みを決めておく点にあります。AWSのガードレール、Azureのポリシー、Google CloudのVPC Service Controlsは、いずれも事後の是正より事前の予防を重視した仕組みです*1*5。
権限設計を後回しにして個別にIAMロールやアカウントを増やしていくと、ワークロードが増えるたびに権限の棚卸しが必要になります。最小権限の原則(必要な操作だけを許可する設計方針)を組織単位・アカウント単位で最初に組み込んでおけば、追加のワークロードは既存の枠組みに従うだけで済みます。
権限設計を後から見直す場合、稼働中の全アカウントを止められない環境でIAMロールを一つずつ棚卸しし、影響範囲を確認しながら修正する作業が発生するでしょう。SCP(Service Control Policy。AWS Organizationsで複数アカウントに一括適用する制御ポリシー)のような仕組みも、ランディングゾーンの設計段階に組み込んでおくほうが、個別アカウントへの手作業の追加設定を減らせます。
ログ集約・監査とコスト管理——運用フェーズを見据えた初期設計
ランディングゾーンにはログ集約と監査の設計も含まれます。AWS Control TowerはLog Archiveアカウントを標準で用意し、各メンバーアカウントのログを一元的に集約する構成をとります*2。Azure・Google Cloudも、管理用のサブスクリプションやプロジェクトにログとモニタリング機能を集約する構成が一般的です*3*5。
コスト管理の仕組みも、初期段階で組み込んでおきたい対象です。請求の一括管理やタグによるコスト配分、サブスクリプション単位の予算設定など、課金の可視化方法をランディングゾーンの設計時に決めておくと、アカウント数が増えた後の混乱を避けられます。
内製と外注の分かれ目——ランディングゾーン構築を外部委託する判断軸
ランディングゾーン構築を内製で担うには、複数領域の知識が同時に必要です。AWSであればOrganizations・IAM Identity Center・Control Towerの仕組み、Azureであれば管理グループとポリシーの設計、Google CloudであればResource ManagerとVPC Service Controlsの設定などです*1*3*5。
加えてネットワーク設計(VPC・サブネット・接続方式)とセキュリティ設計(暗号化・ログ監査)の両方に精通した人材を、初期構築の期間だけ確保する必要があります。設計フェーズのみ外部の専門知見を借り、運用フェーズは内製に戻すという分担を選ぶ企業も見られます。
専門パートナーに依頼する場合と内製で対応する場合の違いは、設計を見直す際の判断スピードに表れやすい点です。専門パートナーは複数の企業でランディングゾーン構築を手がけた経験を踏まえ、判断ポイントを把握したうえで着手できます。一方で内製の場合は、自社にとって最初の設計を手探りで進めることになり、試行錯誤の分だけ構築期間が延びかねません。
。組織のアカウント数や利用するクラウド事業者の数によって、必要な設計工数は変わってきます。現状の利用計画を診断したうえで、内製と外注の切り分けを検討することが実務的です。
まとめ：ランディングゾーン構築で押さえる3つの判断軸
本稿ではクラウド基盤のランディングゾーン構築について、AWS・Azure・Google Cloudの公式情報をもとに整理しました。要点は3つに集約できます。第一に、ランディングゾーンとはマルチアカウント設計・ネットワーク・IAM・ガードレール・ログ監査を拡張前提で整える初期設計です*1。第二に、AWS Control Tower・Azure landing zones・Google Cloudのlanding zoneは、統制の枠組みを個別システムより先に用意するという考え方を共有しています*1*3*5。第三に、設計フェーズで必要な知識領域は広く、内製と外注の判断は組織のアカウント数や利用するクラウド事業者の数によって変わってきます。
よくある質問
ランディングゾーンの構築にはどのくらいの期間がかかりますか。
AWS Control Towerはサービス連携によって、最短1時間程度でランディングゾーンを構築できると案内されています*1。ただし実際の構築期間は、対象アカウント数やネットワーク要件、ガードレールの設計内容によって変わります。複数クラウドを併用する場合は、各社の設計領域を個別に検討する時間も必要になります*3*5。
ランディングゾーンとAWS Control Towerは同じものですか。
同じではありません。ランディングゾーンはマルチアカウント環境の基盤そのものを指す概念で、AWS Control Towerはそのランディングゾーンを構築・管理するためのサービスです*1。Azure・Google Cloudにも、それぞれ別の実装方法が用意されています*3*5。
既にクラウドを利用している場合でも、後からランディングゾーンを整備できますか。
既存環境でも、AWS Organizationsに登録済みのアカウントをControl Towerに組み込む方法が用意されています*1。ただし既存の権限設定やネットワーク構成との整合を確認する作業が加わるため、新規構築より検討事項が増える点に留意が必要です。
マルチクラウドの場合、複数のランディングゾーンを用意する必要はありますか。
クラウド事業者ごとに管理の仕組みが異なるため、AWS・Azure・Google Cloudを併用する場合は原則としてそれぞれにランディングゾーンを用意します*1*3*5。事業者間で設計思想が異なる点を踏まえ、共通のガバナンス方針を別途整理しておくと運用の混乱を抑えやすくなります。
ランディングゾーン構築を外部に委託する場合、何を確認すればよいですか。
対象のクラウド事業者ごとの設計領域を把握しているか、既存環境の移行を伴う場合の影響範囲をどう検証するかをまず確認します。加えてログ集約・コスト管理の運用設計まで一括して依頼できるかどうかも、契約前にすり合わせておくことが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「What Is AWS Control Tower?」（AWS Control Tower User Guide）（https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html）
- *2 出典：AWS「How AWS Control Tower works」（AWS Control Tower User Guide）（https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html）
- *3 出典：Microsoft「What is an Azure landing zone?」（Cloud Adoption Framework）（https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/）
- *4 出典：Microsoft「Azure landing zone design areas」（Cloud Adoption Framework）（https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas）
- *5 出典：Google Cloud「Landing zone design in Google Cloud」（Cloud Architecture Center）（https://docs.cloud.google.com/architecture/landing-zones）
