AWS マルチアカウント管理を実現するベストプラクティスとは ?

2020-07-02
ビジネスxクラウド

Author : 柳 嘉起

みなさんこんにちは。builders.flash ビジネス×クラウド担当 ソリューションアーキテクトの柳です。

ビジネス×クラウドでは "ビジネス課題をクラウドで解決する" ことをテーマに、複雑に入り組んだ現代社会に鋭いメスを入れ、さまざまな謎や疑問を究明していきます。取り上げるトピックは、働き方改革、クラウドマイグレーション、デジタルトランスフォーメーション、システム開発方法論などを予定しており、エンタープライズでよくご相談頂く内容や、これからクラウドを使いたいと思っていらっしゃる方にも役立つような情報をご紹介します。

さて、私は普段 SA としてエンタープライズのお客様をサポートさせて頂く傍ら、マネジメント & ガバナンスサービスにスペシャリティを持ち活動をしています。マネジメント & ガバナンスサービスとはビジネス俊敏性とガバナンスコントロールという従来は相反していた 2 つの要求を実現する AWS の運用系サービス群を指します。この領域で最近よく頂くのが、下記のような複数の AWS アカウントを管理する方法についてのご相談です。

  • 社内では AWS 環境を払い出す組織とシステムを開発する組織が分かれているが、案件が増えるに従い共通のセキュリティ/監査設定などの環境構築に時間がかかるようになり、スピード感が無くなってきた
  • ログサーバーや AD など同じような共通機能を持ったアカウントがシステムの分だけつくられているが、最適化の観点から問題を感じており、複数の環境を効率よく利用するベストプラクティスや他社の事例を知りたい
  • 今後のマイグレーションや運用を円滑に進めていくために、大規模に AWS を使うにあたって、あらかじめスケーラビリティのあるアカウント構成をデザインしたい

そこで今回は、これらのご相談の際にお話ししている「AWS アカウント管理」のベストプラクティスについてご紹介します !

環境の分割と AWS アカウント

AWS 上にシステム環境を展開する際に、環境をどの単位で分割するか。これは様々な方法や考え方がありますが、大きく分類すると、単一のアカウントを VPC 単位で分割させるのか、それともアカウント単位で分割 (マルチアカウント構成) させるのかの 2 パターンです。本記事では AWS アカウント分割によって実現できることと、マルチアカウントを管理するベストプラクティスについて、ご紹介したいと思います。

早速本題に入りたいところですが、まずは AWS アカウント分割によって実現できることについて考える前に、AWS アカウントが何を分けるかを考えてみましょう。

AWS アカウントとは AWS 環境のリソース管理単位であり、セキュリティ上の境界、AWS 課金の分離単位です。これらを踏まえたうえで、AWS アカウントを分けることにより何が実現できるかを具体的に見ていきます。

1 番目は環境の分離です。VPC 分割ではネットワークレベルで分離し、IAM を用いて権限管理をしていきます。IAM を使った場合、ロールベースのアクセス制御 (RBAC) や属性ベースのアクセス制御 (ABAC) で権限管理は可能ですが、複数の環境、複数の管理主体の管理は煩雑になりがちです。アカウントを分割することによってマネージドコンソール、API 単位での分離が容易に実現できます。

内部統制のため、開発者が追加の認証なく本番環境にアクセスしてはいけないことを求められるケースが多くあります。また、本番環境と開発環境のコンソールが明示的に分かれることによって、オペレーションミスなどのリスクへの対策にもなります。

2 番目に課金です。同一アカウント内で VPC を分割して運用している各システムにおいてコストの可視化をする場合、コスト配分タグを設定し集計していく必要があります。アカウントを分割すれば、割り振られたアカウント単位で AWS のコストが表示されますので、管理がシンプルになります。また、課金に対する責任やコントロールも持たせることができます。

3 番目にビジネス推進です。全社で統一の管理基準で運用すると、個別部門・システムの要件を満たすことができず、結果的に IT がビジネス推進を阻害してしまうことがあります。アカウントをビジネス部門ごとに払い出して完全に分離された環境をつくり、ガードレール (実施してはいけない操作を禁止したり、危険な設定を監視したりする仕組み) で管理された環境を提供することで、他部門に影響することなく、独自のポリシーで IT 環境を運用できます。また、スピードを高めるために特定のアカウントに権限を委譲することができます。

最後にワークロードです。アカウントを分割することで、セキュリティレベル、サービスレベルが異なるワークロードを明確に分離できます。認証や認定などを取得する場合は、アカウント単位で監査及びアセスメントが実施できます。また、AWS サービスクォータアカウントごとに管理されるため、サービス上限値のプランニングが行いやすくなります。

アカウント分割によって上記に述べた 4 点を実現することができますが、アカウントを必要のつど手作業でつくっていては、ガバナンスやセキュリティの設定に抜けモレが生じたり、構築作業自体がボトルネック化する可能性があります。次章では、スケーラブルなマルチアカウント構成の実現に向けてチャレンジしなければいけない課題と、解決方法についてご説明します。

マルチアカウント構成でのチャレンジ

マルチアカウント構成を運用していくと、成長に従い下記の課題が見えてきます。

  • アカウント間の設定の整合性が維持できない
  • 各アカウントに行う設定・構築作業が複雑になる
  • 継続的にコンプライアンスを遵守しているか管理しなければいけない
     

これらの課題を解決し、スケーラブルなマルチアカウント構成としていくには、そのための管理環境構築にチャレンジする必要があります。以前は手作業での設計 / 構築 / 運用が必要となり、マルチアカウント構成はコスト効率の面で必ずしも最適とは言えませんでした。しかし近年のサービス拡充や、この後述べる Landing Zone という概念の登場により、マルチアカウント構成の設計構築や運用に伴う作業負荷が軽減/自動化されてきています。具体的なご説明はこの後述べますが、現時点ではマルチアカウント構成を積極的に利用していくことがベストプラクティスとなってきています。では次章では、マルチアカウント環境における最適な構成について考えていきましょう。

マルチアカウント環境の最適な構成を考える

AWS において「最適な構成を考える」時、ぜひお使い頂きたいものがクラウド設計・運用のベストプラクティス集である "AWS Well-Architected Framework” です。

これは、AWS がこれまで 10 年以上にわたり多くのお客様をサポートさせて頂いた経験から作ったもので、お客様と共に作り上げた知見の集大成といえます。このベストプラクティスに則った設計・構築・運用をしていただくことで、様々なリスクを低減させて、コスト効率を高めて、お客様ビジネス成功の確率を高めることができます。

“AWS Well-Architected Framework” についてご説明したところで、続いて Landing Zone という概念をご紹介します。Landing Zone は、Well-Architected Framework を始めとした「AWS のベストプラクティス」に基づいて構成したアカウントを、スケーラブルに展開していくための仕組みの総称です。これにより、ガバナンスを効かせた形でアカウントを自動展開することができます。

Landing Zoneは、下記機能から構成されます。

  1. アカウントの発行
    ・必要な初期設定の済んだアカウントを作成
  2. 管理用権限の発行
    ・対象アカウントを管理するための権限を作成
  3. 共有サービスへのアクセス (ユーザー環境に合わせて個別に実装する)
    ・AD やファイルサーバー等の共有サービスや運用拠点への接続経路の確保
  4. AWS ログの集約
    ・監査用ログをセキュアに一元保存
  5. ガードレールの設置 
    ・実施してはいけない操作の禁止 (必須のガードレール)
    ・危険な設定の監視 (強く推奨されるガードレール、推奨のガードレール)

ここでポイントとなるのは、Landing Zone はマルチアカウント戦略を実現する仕組みの総称であり、AWS サービスの名称では無いということです。では Landing Zone を適用するにはどうすればよいでしょうか。方法は 2 つあります。

Landing Zone を適用する 2 つの方法

1 つはマネージドサービスである AWS ControlTower を利用して迅速かつ簡易に Landing Zone を実現する方法。もう 1 つは独自に同様の仕組みを構築して、柔軟性の高い Landing Zone を実現する方法です。順番にご紹介します。

実装 1: AWS Control Tower

AWS Control Tower では、ID、フェデレーティッドアクセス、マルチアカウント構成のベストプラクティスを使用して、Landing Zone をセットアップします。

ControlTower により提供される機能は、以下が挙げられます。

  • AWS Organizations を使用してマルチアカウント環境を作成する
  • AWS Single Sign-On (SSO) を使用して ID 管理を提供する
  • AWS SSO を使用してアカウントにフェデレーティッドアクセスを提供する
  • AWS CloudTrail のログや、Amazon S3 に保存される AWS Config のログを集中管理する
  • AWS IAM および AWS SSO を使用してクロスアカウントセキュリティ監査を有効化する

これらをマネージドで構成できるサービスが、AWS Control Tower です。なお、2020 年 7 月 1 日時点において AWS Control Tower はまだ東京リージョンで利用することはできません。また、同時点において「必須のガードレール」の解除や、ガードレールの追加やカスタマイズに対応しておらず、より柔軟な構成が必要となる場合は、独自に Landing Zone を実装することが推奨されます。

実装 2 : 独自実装の Landing Zone

もうひとつの手段として、Landing Zone の各機能を独自実装する、という方法をご紹介します。AWS Control Tower も実装は上記の通り AWS サービスの組み合わせになっていますので、これを自ら構築していくというアプローチです。

独自で実装する場合、(5) ガードレールの設置において、個別のルールを多数設定していく必要がありました。こちらについては、2020 年 4 月に AWS Config の適合パック(コンフォーマンスパック)が発表されたことにより負荷が軽減しました。適合パックを使うことで、AWS Control Tower の AWS Config ルールに基づくガードレール (発見的ガードレール) をまとめて導入することが可能です。また、独自実装することによって、自社に最適な形でアカウント構成やガードレールをカスタマイズできるというメリットもあります

なお、AWS Contorl Tower を使って既存アカウントを組み込む機能が 2020 年 4 月に発表されました。これにより、独自実装で Landing Zone を構成しておき、将来的に AWS Control Tower が東京リージョンで利用可能になったあとで、AWS Control Tower に既存アカウントをインポートするという戦略も考えられます。

既存の AWS アカウントを AWS Control Tower へ登録する »

まとめ

今回は、「AWS アカウント管理」のベストプラクティスについてご紹介致しました。ポイントをもう一度おさらいさせて頂きます。

  • Landing Zone は AWS のベストプラクティスに基づいて構成したアカウントを、スケーラブルに展開していくための仕組みで、マルチアカウント戦略を実現するものです
  • Landing Zone の実現方式として、AWS Control Tower を使用するか、独自実装するか

の 2 つの選択肢があります

次回は独自実装する場合の具体的な方法や、構成についてお話していきます。引き続きよろしくお願いします !


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

柳 嘉起 (やなぎ よしき)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト

AWS 入社前は IT アーキテクトとして、システムのインフラ全体について、方針策定や最適化、設計を行っていました。開発と運用を同じくらいの期間、何度も繰り返し経験してきたため、上流工程から実運用を意識して開発を行うこと、また運用で得たことを確実に開発にインプットとしていくことを大切にしています。
好きな AWS サービスは マネジメント & ガバナンスサービス全般。好きな言語はPython。趣味はボウリングと庭いじり (ビオトープの構築 / 運用含む) です。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する