Landing Zone を使ったAWSのマルチアカウントアーキテクチャへの移行 ~ インフラリビルド Part1
*本記事は、こちらの英語の記事の翻訳です
はじめに
WealthPark でシニアリードSREマネージャーをしている@ryok6tです。
このブログシリーズでは、弊社の "Rebuild" というプロジェクトについて詳しく説明します。このプロジェクトは、弊社のインフラ全体を再構築する大規模なプロジェクトです。
このプロジェクトでは、社内で長きにわたって課題となっており、様々な問題を引き起こしていたインフラの改善に取り組みました。
その中でも、特にAWS関連のインフラは大規模な改善が行われました。
AWSのマルチアカウントのフレームワークである Landing Zone や、ベストプラクティスに従って、過度に複雑化したアカウント構成、そしてインフラ全体をゼロから再構築しました。これにより、セキュリティの向上、運用の最適化、将来の拡張性など、様々な観点からの最適化を図りました。
このブログシリーズでは、私たちが直面した課題、採用した戦略、そして学んだ教訓について説明します。私たちの経験/知見を共有することで、AWSのマルチアカウントアーキテクチャを設計する人に少しでも役立つことを願っています。
このプロジェクトでは Kubernetes関連のリアーキテクチャなど他にも多くの改善を行ってきましたが、このブログ記事では AWSのマルチアカウント構成に焦点を当てています。
プロジェクト全体をカバーするため、他の領域については別のブログ記事で取り上げる予定です。
旧アーキテクチャの課題
今回のアカウント構造の全面改善の重要性を把握するためには、以前のアーキテクチャとその問題点を理解することが重要です。
図は複雑に見えるかもしれませんが、これでもかなり簡略化して描かれています。
既存のアカウント構造は、3つのAWSアカウントで構成されており、本番環境はそのうちの2つに分散していました。これは戦略的な理由に基づいているわけではなく、歴史的経緯によるものです。
図の中には、いくつかの一般的でない構成があることが分かります。 たとえば、図中の赤文字の部分です:
トラフィックは ALB -> NGINX -> ALB を経由して、やっとアプリケーションに到達します
ミドルウェアや依存コンポーネントはインターネット経由で接続されています
この構成により多くの問題が生じました。少し詳しく見ていきましょう:
1. 認知負荷
複雑で分散したアーキテクチャにより、エンジニア組織全体に重い認知負荷が生じていました。
変に分割された本番アカウントや、所々に存在するワークアラウンド的な要素の存在により、アーキテクチャは標準的なプラクティスから逸脱していました。
この複雑さにより、インフラに詳しいメンバーであっても全体を把握することが非常に難しく、アプリケーション開発チームなどインフラに詳しくないメンバーにはほとんど理解ができないものになっていました。
2. セキュリティ（ネットワーク構成）
セキュリティ面でも多くの課題が存在しましたが、主要な課題の一つは、一貫性がなく、一般的ではないネットワーク構成によるものでした。
本番環境は2つのアカウントに分散しており、2つのアカウントのネットワークは完全に分離されていました。
この分離は特にデータベースなどの依存コンポーネントがアカウント間で通信する必要がある場合に問題を引き起こしました。
一部のコンポーネントはインターネット経由で接続されており、脆弱性を引き起こしていました。
さらに、一部のAPIにはIP制限がありましたが、VPCが分離されてしまっていたため、KubernetesノードのIPアドレスをセキュリティグループに追加することで設定されていました（これはかなり衝撃的でした）。
そのため、新しいノードを追加した際に、そのノードのIPアドレスを許可リストに追加するのを忘れてインシデントになったケースもありました。
3. セキュリティ（IAM管理）
IAMユーザーの管理も重大なセキュリティリスクを引き起こしていました。
IAMユーザーは各アカウントに直接作成されていました。
権限はまともに管理されておらず、多くのユーザーは必要以上の権限を持っていました。
また、パスワードやアクセスキーは当然のように更新されておらず、それどころか色々な場所で再利用されていました。
4. 運用コスト
弊社では Kubernetes を使用していますが、古いインフラでの使い方にはかなり問題がありました。
このブログでは詳細には触れませんが、将来のブログではこれらの課題を詳細について掘り下げて、新しいKubernetes周りのインフラがどのようになっているかを説明します。
ここで取り上げた課題は、あくまで一部であり、巨大な氷山の一角にすぎません。
既存のアカウント構造は、運用を妨げ、インフラ全体の効率とセキュリティを損なうさまざまな問題を抱えていました。
AWSマルチアカウントのベストプラクティス
AWSのアカウント構造を0から作り替えるにあたっては、AWSのマルチアカウントのベストプラクティスを大いに活用しました。
これらのベストプラクティスは、AWS環境内のセキュリティ、ガバナンス、スケーラビリティを担保する上で非常に重要な指針となります。
これらのガイドラインに加え、AWS Control Towerを活用することで、最適なアカウント構造を確立することを目指しました。
1. アカウント間の明確な境界線
重要なベストプラクティスの一つは、AWSアカウント間に明確な境界線を設定することです。
これには、AWS Control Towerのアカウントファクトリー機能を活用しました。このアプローチにより、各アカウントに明確な目的と範囲が定義され、セキュリティが向上しました。
2. IAMの集中管理
アカウント間でIAMの管理を集中化することも、AWSのマルチアカウントのベストプラクティスの重要な側面です。
AWS Identity Centerと権限管理機能を活用することで、複数のアカウントにまたがるアクセスと権限の管理が容易になります。
このアプローチにより、設定ミスのリスクが低減し、一貫性が向上し、効率的なIAMガバナンスが可能となりました。
3. ネットワークの分離と接続性
セキュリティの強化とネットワークトラフィックの制御のために、AWS Control Tower のガードレールや、ネットワーク関連のサービスを使用して、ネットワークの分離と適切な接続性を実装しました。
異なるアカウントにそれぞれ別々のVPCを配置し、Transit Gateway などの通信チャネルを確立することで、アカウント間の明確な分離と制御されたアクセスを確保しました。
4. セキュリティとコンプライアンスの自動化
セキュリティとコンプライアンス対策の自動化は、安全なAWS環境の維持において重要です。
AWS Control Towerを活用し、AWS Configルール、AWS CloudTrailのロギング、AWS Security Hubの統合など、組み込みのガードレールを使用して、複数のアカウント間でセキュリティとコンプライアンスのチェックを自動化しました。
このプロジェクトでは、AWSのマルチアカウントのベストプラクティスを実現するために、AWS Control Towerを大いに活用しました。
これらのガイドラインに従い、AWS Control Towerの機能を活用することで、より安全で適切なガバナンスが行われ、スケーラブルなAWS環境を確立することができました。
次のセクションでは、これらのベストプラクティスを設計フェーズにおいてどのように適用したか、そしてそのポジティブな影響について詳しく説明します。
アーキテクチャの再設計
このセクションでは、インフラの再設計に取り組む際に行ったアーキテクチャ上の決定や考慮事項について紹介します。
1. 組織単位とアカウント構成
アカウント構造の改革の一環として、一貫性があり、コントロールしやすく、かつセキュアなアカウント構造を導入しました。
新しい構造は5つのOU（Organizational Unit）からなり、それぞれが違った目的を果たします。
以下に、実際のOU構成と、各OUに含まれるアカウントの概要を示します。
インフラストラクチャOU:
ネットワークアカウント:
このアカウントは、ネットワーク関連のリソースを集約するというベストプラクティスに従います（https://docs.aws.amazon.com/ja_jp/whitepapers/latest/organizing-your-aws-environment/infrastructure-ou-and-accounts.html#network-account）。
VPCやサブネットなどのネットワーキングコンポーネントを中央集権化することで、ネットワークインフラの管理/制御がしやすくなり、可視性も向上しました。共有サービスアカウント:
共有サービスアカウントは、特定の環境や製品に属さないリソースを保持します。例えば、複数のアプリケーションや環境で共有されるElastic Container Registry（ECR）やArgo CDなどのサービスはこのアカウントに配置されます
ワークロードOU:
各環境固有のワークロードアカウント:
ワークロードOUでは、開発、ステージング、本番など、異なる環境ごとに個別のアカウントを持っています。これにより、環境間の分離を確保し、細かいアクセス制御なども可能になります。
ワークロード（Fintechプロダクト）OU:
各環境固有のワークロードアカウント:
ワークロード（Fintechプロダクト）OUは、上記のワークロードOUと似た構造を持っていますが、Fintechプロダクト専用のOUとなっています。Fintechプロダクトにはより高い分離とセキュリティの要件があるため、厳格なアクセス制御と機密データの保護を確保するために、別のOUを設けました。
セキュリティOU:
監査アカウント:
このアカウントは、セキュリティの監査目的に専用のアカウントを持つというベストプラクティスに従って、Control Towerによって自動的に作成されます。AWSインフラストラクチャの集中的なモニタリング、ログ記録、監査を可能にし、セキュリティとコンプライアンスの向上に貢献しています。
セキュリティチームは、日々このアカウントを使って、ログの分析や脅威検知など、様々な監視や分析を行っています。ログアーカイブアカウント:
ログアーカイブアカウントも、AWS Control Towerによって自動的に作成されます。さまざまなアカウントからのログを集約的に保管する場所として機能し、監査、分析、コンプライアンスの目的で統合的なビューを提供します。
セキュリティチームは、このアカウントを使用して、セキュリティインシデントの検出や、怪しい挙動の検知などを行っています。
サンドボックスOU:
開発者サンドボックスアカウント:
サンドボックスOUは、開発者のためのプレイグラウンドとして機能します。本番環境や他の重要なワークロードに影響を与えることなく、実験、プロトタイピングに専用の環境を提供します。開発者はこの隔離されたアカウント内で新しいAWSサービスを試したり、新しいアイデアをテストすることができます。
このOU構造を設計する際には、公式の Landing Zone や他のAWSドキュメントを参考にしました。
私たちは、少なくとも3つのOU（セキュリティ、インフラストラクチャ、ワークロード）を持つことが効率的なマルチアカウント構成においてはほぼ必須だと考えています。
複数のアカウントを管理することは難しく見えるかもしれませんが、各アカウントとOUに明確な役割と責任が割り当てられているため、かえって運用は簡単です。
この洗練されたアカウント構造を採用することで、AWSのインフラにおいてより良い統制、セキュリティ、スケーラビリティの基盤を確立しました。
2. ネットワークアーキテクチャ
次は、新しいネットワークアーキテクチャについてです。
新しいネットワークアーキテクチャの主要な要素は次の通りです。
ネットワークアカウントとリソースの集約
VPCや Transit Gateway などのネットワーク関連リソースは、専用のネットワークアカウントに集約されています。これにより、ネットワークの管理と可視性が向上しました。
RAMによるVPCの共有
ワークロードアカウントなどの個々のアカウントで使用されるVPCは、AWS Resource Access Manager (RAM) を使用してネットワークアカウントから共有されています。
Centralized Egress アーキテクチャ
"Centralized Egress" アーキテクチャを採用しました。これにより、VPCからの外向きのトラフィックは Transit Gateway 経由で、Egress VPCを通ってインターネットに出ます。この設計には、ネットワークセキュリティの向上、アウトバウンドトラフィックの集中的なモニタリングとログ記録、組織全体での一貫した Egress ポリシーなど、いくつかの利点があります。
また、副次的な利点として、IP制限への対応が挙げられます。外部のAPIや、他のサービスに接続する際に、セキュリティ上の理由から接続元のIPアドレスを固定することが必要になるケースがあります。しかし、動的な環境ではIPアドレスが頻繁に変更されるため、NGINXなどの追加のプロキシをデプロイするなどの回避策が必要となる場合があります。
Centralized Egress では、すべての外向きのトラフィックが Egress VPC を経由するため、接続元のIPアドレスは必ず Egress VPC の NATゲートウェイに紐づいた EIP になります。これにより、IPベースのセキュリティ要件への対応が簡素化され、追加のプロキシ等のデプロイが不要となります。
"Centralized Ingress" の検討
"Centralized Ingress" についてもいくつかの記事で言及されています。
しかし、私たちは採用しませんでした。この決定にはいくつかの要因が影響しました。
まず第一に、ワークロードアカウントのEKSで使用される AWS Load Balancer Controller はパブリックサブネットが必要であるため、構成が複雑になります。
また、弊社では Cloudflare を使用しており、内向きのトラフィックのセキュリティについては、そちらである程度担保できると考えました。
社内アプリケーション用のプライベートネットワーク
Argo CD や HashiCorp Vault などの社内でホストされているアプリケーションは、プライベートネットワークに配置されています。
これらのアプリケーションは、プライベートな Route53 ゾーン内のドメインが割り当てられ、AWS Certificate Manager（ACM）のプライベート証明書で保護されています。
これらのアプリケーションは、VPC内部から、あるいはAWSクライアントVPNを介してのみアクセスできるようになっており、高いセキュリティレベルで不正アクセスを制限しています。
VPC間の接続性の確立のための Transit Gateway
VPC間の接続性を確立し、制御された通信を可能にするために、AWS Transit Gateway を利用しました。前述のように、すべてのVPCからの外向きのトラフィックは Transit Gateway を経由して、Egress VPC を通るように構成されています。
また、共有サービスアカウントの VPC からは、他の VPC へのアクセスが可能になるように構成されていますが、それ以外のVPC間の直接通信（ステージングと本番環境間など）はできないようになっています。
これにより、セキュリティが向上し、ネットワークトラフィックに対する詳細な制御が可能となります。
Terraform を使用したリソース作成
このネットワークアーキテクチャの実装では、新しいアカウントや VPC をセットアップする際に多数のリソースの作成が必要となります。このプロセスを簡素化するために、再利用可能な Terraform モジュールを開発しました。
このモジュールは、使用したいCIDRを指定するだけで、VPC、サブネット、RAM、Transit Gateway のアタッチメント、VPC/Transit Gateway の Route など、必要なすべてのコンポーネントをセットアップしてくれます。これにより、手作業を削減し、インフラ全体での一貫性を確保します。
新しいネットワークアーキテクチャは、私たちのAWS環境に堅牢で安全な基盤を提供します。効率的なリソース管理、制御されたトラフィックフロー、強化されたセキュリティ対策により、アプリケーションとワークロードの安定性と拡張性が確保されます。
3. IAM管理の構成
新しいインフラでは、IAM は AWS Identity Center を使用して管理されます。これにより、IAM の管理が簡素化され、組織全体でのセキュリティの向上と効率的なアクセス制御が実現されます。
アイデンティティ管理とアクセス制御の向上のために、弊社では Okta を活用しています。AWS の権限は Okta と統合されており、Okta の特定のグループに所属するユーザーのみが IAM Role を assume し、それぞれのAWSアカウントにアクセスできるようになっています。
IAM 管理構造の重要な変更の一つは、以前のように個々の IAMユーザーを発行することを完全に辞め、静的なパスワードとアクセスキーの必要性を排除したことです。ユーザーは TTL が設定された一時トークンを受け取ります。これにより、クレデンシャルの漏洩リスクを減らすだけでなく、ユーザー管理を簡素化し、パスワードの変更やアクセスキーの変更の手間を排除することができます。
4. ドキュメンテーションと知識の伝達
アーキテクチャと直接的には関係がありませんが、私たちのSREチームは、ドキュメンテーションを知識共有と情報伝達の観点において非常に重視しています。
包括的なドキュメンテーションを作成することは、マルチアカウント環境でのアカウントおよびネットワーク構造を理解し、新しいチームメンバーのスムーズなオンボーディングを確保し、開発チーム間の効率的なコラボレーションのために不可欠です。
このため、私たちは新しいインフラのさまざまな側面をカバーする包括的なドキュメンテーション作成に多大な努力を注いでいます。以下にいくつかの例を示します:
マルチアカウントドキュメンテーション:
このドキュメントでは、AWS Landing Zone、Control Tower、OUの詳細と、それらがインフラストラクチャ内で果たす役割について説明しています。実際に存在するOUやアカウント、そしてそれぞれの機能/責務について概説しています。ログインドキュメンテーション:
各開発者がローカル環境から AWS にログインする方法を詳細に説明したドキュメントです。セットアップのプロセスや、簡単にログインしたりアカウントを切り替えたりするためのコマンドなどについて説明しています。AWS Client VPN ドキュメンテーション:
AWS Client VPNのセットアッププロセスに関するドキュメンテーションを作成しています。このドキュメントには、必要な構成手順（例: プライベート Route53 ゾーンを使用した名前解決を有効にする手順）や、必要な自己署名証明書を信頼する方法が含まれています。
私たちのドキュメントは主に Confluence に存在し、一元的なナレッジベースとして機能しています。一方で、適材適所ということも意識しています。
たとえば、AWSリソースの管理にはTerraformを使用し、再利用可能なモジュールが数多く存在しますが、Standard Module Structure に従い、READMEを書くようにしています。これらの README は、モジュールの使用方法や使用例、および各モジュールの作られた背景などを提供します。
ドキュメンテーションを重視することで、私たちは効果的なコミュニケーションと協力の文化を醸成しています。これにより、新しいメンバーのスムーズなオンボーディングだけでなく、エンジニア組織全体がアカウントおよびネットワーク構造を容易に把握できるようになっています。
得られた成果
AWSアーキテクチャの再構築により、多くの成果や運用上のメリットを得ることができました。以下では、このプロジェクトを通じて達成したいくつかの主要な利点とポジティブな成果を説明します。
1. 強化されたセキュリティ
AWS のベストプラクティスに基づく新しいアカウント構造により、インフラ全体のセキュリティを大幅に向上させました。一貫したネットワーク構成の実装、適切な IAM管理プラクティスの導入、Centralized Egress アーキテクチャ等の採用により、セキュリティが大幅に改善しました。
2. 最適化された運用/金銭コスト
このプロジェクトにより、AWS のサービスと機能をうまく活用することで、運用コストを最適化しました。AWS Control Towerと AWS Identify Center の採用により、IAMの管理の複雑さとオーバーヘッドが削減されました。
また、本記事では触れられていないコスト最適化対策（Savings Plans や Spot Instancesの使用など）を実施することで、インフラストラクチャの運用のコストを最適化しました。
3. 効率とスケーラビリティの向上
新しいアカウント構造とネットワークアーキテクチャにより、運用の効率とスケーラビリティが向上しました。アカウントの明確な分離と組織単位の使用により、認知負荷が軽減され、リソースの管理とプロビジョニングが簡素化されました。さらに、再利用可能な Terraform モジュールの使用により、新しいアカウントや VPC の作成の工数を最小限に抑えることができました。
4. 強化されたドキュメンテーションと知識の伝達
ドキュメンテーションに重点を置き、アカウント構造、ネットワークアーキテクチャ、およびインフラのさまざまな側面をカバーするドキュメントを作成しました。これらのドキュメンテーションは、新しいチームメンバーのオンボーディング、知識の伝達、およびインフラ構成の理解に非常に役立っています。
5. 未来を見据えた基盤
このプロジェクトにより、将来の変化、スケールに対応した基盤が構築されました。AWSのベストプラクティスに準拠し、AWS Control Tower などのサービスを活用することで、スケーラブルで柔軟なアーキテクチャが確立されました。
全体として、このプロジェクトは、セキュリティの強化、運用コストの最適化、効率とスケーラビリティの向上、包括的なドキュメンテーション、および将来に対応した基盤などの重要な利点をもたらしました。
学んだこと
以下に、このプロジェクトを通しての学びを共有します。
1. 適切な計画と設計
徹底した計画と設計は、インフラの再構築を成功させるためには不可欠です。既存のインフラを注意深く分析し、課題を特定し、明確な目標を定義することは、効果的な再構築において非常に重要です。
特に、アカウント構造とネットワークアーキテクチャについては、一度構築されてしまうと、それらを後から変更することは非常に困難です。新しいアーキテクチャが組織の要件や将来の拡張性などのニーズと一致するよう、計画フェーズにおいて関係者を積極的に巻き込んでいくことが重要です。
2. ベストプラクティスの活用
AWSのベストプラクティスを取り入れて実施することは、マルチアカウント環境の適切な管理と、セキュリティを担保する上で非常に有益です。
AWSはマルチアカウントの推奨事項に関する多くのドキュメントを提供しています。このようなドキュメントや Landing Zone に関するガイド、その他関連するリソースなど、常に最新情報を把握することで、情報に基づいた意思決定が行えます。
3. 全てを文書化する
複雑なインフラを管理する上で、ドキュメンテーションは重要な要素です。
マルチアカウント構成は、慣れれば簡単ですが、シングルアカウントの経験しかない人にとっては、最初のうちは理解しにくいことがよくあります。
ネットワークアーキテクチャ図やアカウント構造など、包括的なドキュメントを維持/更新し続けることは、効果的な知識の伝達や新しいチームメンバーのオンボーディングに不可欠です。ドキュメンテーションの文化を醸成し、ドキュメントの定期的な更新/見直しをすることが重要です。
まとめ
この "Rebuild" プロジェクトは、既存のアーキテクチャの課題を解決するため、インフラ全体をゼロから再構築するという野心的な試みでした。
私たちのチームの主な目標の1つは、各開発チームが自身のアプリケーションのインフラを自律的に管理できるようにすることです。しかし、以前のインフラは複雑で、一般的でない構成やさまざまな課題があり、その理想に近づく妨げとなっていました。このプロジェクトの完了により、私たちは重要なマイルストーンを達成し、その理想に近づくための強固な基盤を整えたことになります。
このプロジェクトに関わった、チームと関係者全員に心から感謝したいと思います。
結論として、"Rebuild" プロジェクトは、弊社のインフラ全体を0から刷新するため取り組みです。この改革により、セキュアで拡張性が高く、効率的なインフラを構築し、今後の成功のための土台を築くことができました。
次回のブログでは、この移行プロセスについて詳しく説明します。本番環境への影響を最小限に抑えながら、この大改革をシームレスに実施するために採用した技術や戦略を明らかにしたいと思います。