Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
メインコンテンツまでスキップ

AWS Landing Zone の拡張

AWS がグローバルなフットプリントを拡大するにつれ、組織は新しいリージョンへのクラウドプレゼンスを拡張するための体系的なアプローチを必要としています。AWS が新しいリージョンを立ち上げるにつれ、組織はフットプリントの拡大を検討しています。このガイダンスでは、AWS Organization または Landing Zone を新しいリージョンに拡張するための主要な考慮事項とベストプラクティスについて説明します。

基盤の構築​

包括的なガバナンスコントロールを備えた堅牢なクラウド基盤を構築することは、単なるベストプラクティスではなく、今日のダイナミックなクラウド環境において不可欠な要件です。最初から強固なガバナンスフレームワークの確立に時間を投資した組織は、成長に伴うスケール、適応、セキュリティ維持においてより有利な立場に置かれます。これは家を建てることに例えられます。しっかりとした基盤がなければ、増築や改修はますますリスクが高く複雑になります。Service Control Policies (SCPs)、ガードレール、コンプライアンスフレームワークなどのクラウドガバナンスコントロールは、クラウドインフラストラクチャのセキュリティ、コンプライアンス、管理性を確保するための設計図や建築基準として機能します。新しいリージョンへの展開時に、これらのコントロールが整備されていることで、拡張プロセスがよりスムーズかつセキュアになります。多くの組織が、事後にガバナンスコントロールを後付けすることは、初期設定時に実装するよりも大幅に困難でリソースを要することを実感しています。このようなガバナンスへのプロアクティブなアプローチは、セキュリティインシデントやコンプライアンス違反の防止に役立つだけでなく、運用上の卓越性を維持しながら変化するビジネスニーズへの適応を可能にする柔軟性も提供します。

Organization-First アプローチと Control Tower の比較：主な違い​

新しいリージョンへの展開にあたり、お客様は既存のセットアップに応じて 2 つの主要なパスを選択できます。AWS Organizations は手動ながら高い柔軟性を持つアプローチを提供し、実装の詳細をきめ細かく制御できます。このパスでは各サービスの実践的な設定と Service Control Policies のカスタム実装が必要ですが、特定の要件に対して最大限の柔軟性を提供します。一方、AWS Control Tower は Account Factory を通じたより合理化された自動化アプローチを提供し、事前構築されたガバナンスコントロールと標準化されたガードレールを備えています。Control Tower はマルチアカウントのセットアッププロセスを大幅に簡素化しますが、純粋な Organizations アプローチと比較して柔軟性が低い場合があります。これらのパスの選択は、多くの場合、既存のインフラストラクチャと特定のガバナンス要件によって決まります。

ガバナンスとセキュリティコントロール​

新しい AWS リージョンへの拡張における一つの明るい側面は、CloudTrail や AWS Billing などの特定の基盤サービスが、新しいリージョンを既存の設定に自動的に組み込むことです。CloudTrail は、すべてのリージョンに対して設定されている場合、アカウントで利用可能になった新しいリージョンでの API アクティビティのログ記録を自動的に開始し、追加のセットアップは不要です。同様に、AWS Billing はすべてのアクティブなリージョンのコストを自動的に統合し、AWS Cost Explorer および AWS Bills を通じて統一されたコスト管理とレポートを提供します。

ただし、これらのサービスは自動的に適応しますが、Service Control Policies、GuardDuty、Security Hub、AWS Config などのその他のセキュリティおよび運用サービスは、拡張されたフットプリントを包括的にカバーするために、引き続き明示的なリージョンの有効化が必要である点に注意することが重要です。

アクセスコントロール​

AWS Identity and Access Management (IAM) は、AWS 全体で機能する「設定したら後は任せる」グローバルサービスの代表格です。新しいリージョンに展開する際、既存の IAM ユーザー、ロール、およびポリシーはすでに準備が整っており、追加の設定は不要です！まるでセキュリティチームが到着前から新しい拠点に配置されているようなものです。既存の IAM プリンシパルは、他のリージョンと同じ権限を自動的に持つことになります（ポリシーにリージョン固有の制限が含まれていない場合）。IAM のこのグローバルな特性は、時間を大幅に節約し、拡大する AWS 環境全体で一貫したアクセス制御を維持するのに役立ちます。ただし、IAM はグローバルですが、一部のリソースベースのポリシーやサービスにリンクされたロールはリージョンごとの考慮が必要な場合があるため、拡張チェックリストに含めておくことをお勧めします。

Service Control Policies​

AWS Control Tower を使用している場合、朗報があります。組み込みのガードレールとそれに関連する Service Control Policies (SCPs) は、Control Tower で新しいリージョンが有効化されると、自動的にそのリージョンへの保護を拡張します。まるで自動的に展開されるセキュリティ部隊のようなものです！ただし、カスタム SCP を使用している場合（Control Tower または AWS Organizations のいずれかで）、袖をまくり上げて、新しいリージョンを含めるようにそれらのポリシーを手動で更新する必要があります。これは、リージョン固有のコントロールや許可リージョンのステートメントを使用するポリシーにとって特に重要です。たとえば、許可されたリージョンを明示的にリストアップした SCP がある場合、そのリストに新しいリージョンを追加する必要があります。例を示します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowedRegions",
            "Effect": "Deny",
            "NotAction": [
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:RequestedRegion": [
                        "ap-southeast-2",
                        "ap-southeast-4"  // Adding Asia Pacific (Melbourne) region
                    ]
                }
            }
        }
    ]
}

これらの変更を行わないと、チームはなぜリソースを起動できないのか疑問に思うことになるかもしれません。これらのポリシーの更新は、まず非本番環境でテストすることを忘れないでください。常にお客様への影響を最小限に抑えることが重要です。

AWS Config​

Service Control Policies と同様に、AWS Control Tower を使用している場合、AWS Config は VIP 待遇を受けます。Control Tower がサポートする新しいリージョンでは、自動的に有効化および設定されます。Config が新しいリージョンへのファーストクラスチケットを手に入れるようなイメージです！ルール、アグリゲーター、レコーダーが魔法のように出現します（まあ、魔法ではありませんが、おわかりいただけるかと思います）。ただし、Control Tower を使用せずに Organizations を通じて AWS Config を実行している場合は、手動でその道を整備する必要があります。つまり、新しいリージョンで Config を有効化し、ルールをデプロイし（カスタムルールも忘れずに！）、アグリゲーターを使用している場合はそれも設定するという作業が必要です。多くのお客様は、このプロセスを自動化するために CloudFormation StackSets を使用しています。自動化か手動かにかかわらず、ガバナンスとコンプライアンスのニーズに対応するために、一貫した AWS Config のカバレッジを維持することが重要です。

その他のセキュリティサービス​

AWS セキュリティサービスの世界と、新しいリージョンに展開する際に知っておくべきことについて詳しく見ていきましょう。グローバルスコープの IAM とは異なり、ほとんどの AWS セキュリティサービスはリージョンごとのロールアウト戦略が必要です。これは、事業を展開する各拠点に新しいセキュリティオフィスを開設するようなものです。

まず、セキュリティの最強チームについて話しましょう：GuardDuty、Security Hub、Macie、そして Detective です。これらのサービスはそれぞれ、新しいリージョンで明示的に有効化する必要があります。「そのまま移行」できる状況ではなく、各サービスを意図的に有効化する必要があります。しかし、Organizations を使用する場合に興味深い点があります。委任管理者アカウントの設定は実際にはグローバルです。あるアカウントをセキュリティサービスの委任管理者として指定すると、そのアカウントはすべてのリージョンにわたって特別な権限を維持します。

ただし、まだ対応が必要な作業があります。委任管理者アカウントがあっても、新しいリージョンで各セキュリティサービスを有効にする必要があります。たとえば、Security Hub の場合、委任管理者アカウントは新しいリージョンでサービスを有効にし、メンバーアカウントからの検出結果の集約を設定する必要があります。GuardDuty についても同様で、委任管理者の指定は引き継がれますが、新しいリージョンで脅威検出を有効にし、メンバーアカウントを適切に設定する必要があります。

プロのヒントをご紹介します。多くのビルダーは、AWS CloudFormation StackSets やその他のツールを使用して、このリージョン有効化プロセスを自動化しています。自動化は、リージョン間で一貫したセキュリティコントロールを維持するための鍵であることがわかっています。必要なすべてのセキュリティサービスを有効化および設定する「新しいリージョンセキュリティブートストラップ」テンプレートの作成を検討してみてください。将来の自分がきっと感謝するでしょう！

リージョン集約についても忘れないでください！Security Hub や GuardDuty を中央セキュリティ監視ツールとして使用している場合は、単一ビューを維持するためにクロスリージョン集約を設定することをお勧めします。朗報として、委任管理者アカウントを設定し、新しいリージョンでサービスを有効化すれば、集約設定への追加は通常数クリックで完了します。

可視性の確保​

新しいリージョンへの展開時に見落とされがちですが、非常に重要なサービスについてお話しましょう。リージョン展開を計画する際には、運用可視化ツールのことも忘れないでください。これらのツールにも適切なケアが必要です。Resource Explorer は便利な統合検索サービスですが、すべての AWS リソースの統合ビューを維持したい場合は、アグリゲーター設定に新しいリージョンを追加する必要があります。同様に、パーミッションの守護者である IAM Access Analyzer も、包括的なパーミッションインサイトを維持するために、新しいリージョンで有効化し、アグリゲーション設定に追加する必要があります。そして CloudWatch Logs も忘れずに！クロスアカウント・クロスリージョンの集中ログ管理を使用している場合は、新しいリージョンを含めるようにログルーティングとレプリケーション設定を更新する必要があります。プロのヒントとして、多くのビルダーは集中ログ管理アカウントを作成し、CloudWatch Logs のクロスリージョンオブザーバビリティシンクを使用して、単一の信頼できる情報源を維持しています。これらのアグリゲーション設定をリージョン展開のランブックに記録しておくことをお勧めします。後で振り返ったとき、すべての手順が一か所にまとまっていることに感謝するでしょう！

不足しているものは何ですか？​

その輝かしい新しいリージョンに飛び込む前に、AWS サービスのインベントリについて話しましょう。これは聞こえるよりもずっと重要です。リージョン展開の成功から逆算して考えると、AWS サービスのフットプリントを包括的に評価したいと思うでしょう。明らかなサービスだけでなく、その先まで考えてみてください。組織サービス、セキュリティとコンプライアンスツール、モニタリングとロギングの設定、そして EC2 や S3 については既にご存知でしょう。しかし、数ヶ月前に設定した Route 53 ヘルスチェック、AWS Backup プラン、または AWS Private Certificate Authorities についてはどうでしょうか？コアインフラストラクチャとサポートサービスを含むサービスチェックリストを作成してください。プロのヒント：AWS Resource Explorer または AWS Config を使用して、現在使用しているすべてのサービスを検出しましょう。忘れていた宝物が見つかるかもしれません！各サービスについて、グローバルなのか、リージョナルなのか、または特定のリージョン設定が必要なのかを文書化してください。この評価はリージョン展開のプレイブックとなり、「あのサービスのことを忘れていた」という事態を避けながら、リージョン間で一貫した機能を維持できるようにします。よく計画されたリージョン展開こそが、成功するリージョン展開です！

ランディングゾーンについて​

AWS ランディングゾーンの概念と、ホームリージョンの重要な役割について詳しく見ていきましょう。これは、マルチリージョンデプロイメントを管理するすべての方にとって重要な知識です！

AWS Landing Zone をクラウドの本社と考えてみてください。ホームリージョンはその本社のメインオフィスに相当します。AWS Control Tower を初めてセットアップするとき、またはカスタム Landing Zone ソリューションを実装するとき、ホームリージョンを選択します。この決定は、多くの人が思っている以上に重要です。まるで「ここに私たちのコア設定が存在する！」という旗を立てるようなものです。

ホームリージョンには、Control Tower とその管理コンポーネントなどの重要なサービスが配置されます。これには、Account Factory の設定、監査ログアーカイブ、デプロイパイプライン、およびその他の基盤となるサービスが含まれます。Landing Zone を新しいリージョンに拡張する場合、元のホームリージョンに本社を維持しながら、支店を開設するようなイメージです。新しいリージョンはガバナンスコントロールを継承し、完全に活用できますが、主要な設定と管理コンポーネントはホームリージョンに留まります。

ここが興味深い点です。そして「興味深い」とは、つまり「難しい」ということです！ Landing Zone のホームリージョンを変更することは、AWS コンソールのデフォルトリージョンを変更するようなものではありません。むしろ、ビジネスをスムーズに運営しながら、会社の本社を新しい都市に移転しようとするようなものです。コアサービスの廃止と再デプロイ、ログ集約の再設定、組織設定の再構築、そして自動化パイプラインの再構築が必要になる場合があります。Control Tower の設定データ、監査ログ、AWS Organizations の管理など、これらのサービスの多くはホームリージョンと密接に結合しています。

ホームリージョンの移行が一般的にどのような作業を伴うかを具体的に説明します。

  • 現在のホームリージョンでの Control Tower の廃止
  • コアアカウント構造の再設定
  • IAM Identity Center 設定の廃止と再デプロイ
  • ログおよび監査アーキテクチャの再構築
  • 自動化およびパイプライン設定の再デプロイ
  • クロスアカウントおよびクロスリージョンサービス設定の再構成
  • 過去のデータとアーカイブの移行

ホームリージョンの選択は、「二度測って一度切る」という判断の一つです。長期的な地理的戦略とコンプライアンス要件に合致したホームリージョンを選択することをお勧めします。新しいリージョンへの拡張は簡単ですが、Landing Zone のホームを移動することは、慎重な計画と実行が必要な重大な作業です。

プロのヒント：ランディングゾーンを設計する際は、ホームリージョンの依存関係を徹底的に文書化してください。移行する予定がない場合でも、これらの関係を理解することで、新しいリージョンへの展開時により良いアーキテクチャ上の意思決定ができるようになります。ホームリージョンの選択は、他のリージョンでの運用能力を制限するものではなく、AWS 環境のコントロールセンターとして機能するものです。

まとめ​

結論として、AWS Landing Zone または Organization を新しいリージョンに拡張するには、慎重な計画と AWS サービスのリージョン動作に関する包括的な理解が必要です。ガバナンスの基盤となるコントロールやセキュリティサービスから、運用可視化ツールや Landing Zone の考慮事項まで、重要な側面を網羅しました。IAM や CloudTrail などの一部のサービスは新しいリージョンを自動的に受け入れる一方で、明示的な有効化と設定が必要なサービスもあることを覚えておいてください。拡張の取り組みは、十分に文書化されたサービスインベントリと、Landing Zone のホームリージョンへの影響に関する明確な理解によって導かれるべきです。これらのベストプラクティスと考慮事項に従うことで、拡大する AWS フットプリント全体にわたって、一貫したセキュリティ、コンプライアンス、および運用上の卓越性を維持するための十分な準備が整います。成功の鍵は、徹底的な準備、サービス固有の要件の理解、そして強固なガバナンス基盤の維持にあります。AWS がグローバルインフラストラクチャの拡大を続ける中、これらの原則は将来のリージョン拡張における羅針盤となるでしょう。