企業内AWS運営におけるマルチアカウント管理

企業内の1つのAWS運営チーム(AWSを利用するプロジェクトを支援する事務局ポジション)が複数のプロジェクトチームをゆるく統制していく観点で、AWSアカウント管理を考えてみます。

AWS利用時に作成するAWSアカウント(12桁)の管理単位は、下記考慮事項から複数のアカウントに分割することが多いです。

分割時の考慮事項

管理区分 管理要望 実装例
課金管理 請求書はAWSアカウント単位となるので請求書を用途により分離したい プロジェクト単位、環境単位、管理部門単位等にアカウントを作成する
環境管理 アカウント内に本番・開発サーバ等の全リソースが混在、表示されるのは望ましくない 各環境用アカウントを作成し、開発作業範囲から本番リソースを完全に分離する
サイバーセキュリティ対策 インターネット公開リソースはサイバーアタックの対策管理を行う DMZ用アカウントを作成し、セキュリティ投資集中やイントラリソース分離/ダメージコントロール等を可能にする
ソーシング管理 専門職作業や外注が頻繁に発生するリソースはAWSアカウント管理を委託したい アウトソーシングが可能な単位にAWSアカウントを分離する(例:エンタープライズサポートを契約する基幹系や、24/365サポートを契約するアカウント等)
サービス開発/PoC セキュリティは重要だが柔軟にAWSを活用、トレーニングする環境は必要 自由に作業できるが企業リソースとは分離されたサンドボックス用アカウントを作成する
特権アカウント管理 AWSアカウント情報の流出は大障害につながるので特権管理は必須 rootアカウントは金庫に保管し、AWSアカウント内の操作はIAMユーザーを用いる
運用省力化 運用コストは削減したい 管理の複雑化を防ぐため、AWSアカウントの払い出しは慎重に行う。(例:社員/個人ユーザー単位でのアカウントの作成は行わない)

上記を考慮したマルチアカウント管理例(省エネ型)

アカウント名 用途 分割理由
ログイン/監査アカウント IAMユーザー集約先、アカウント間共有データ管理用 アカウント分割において各アカウントにIAMユーザーを作成するのは管理上好ましくありません。ログイン用IAMユーザーを作成し、ログイン後、各アカウントにスイッチします。(rootアカウントは封印します)また、AWS監査機能ログ(CloudTrail、Config)等のアカウント共通管理データを監査目的で本アカウントに集約します。
サンドボックス AWSトレーニング用 他アカウントはセキュリティ要件で固めますが、本アカウントは自由なAWS操作を許します。
汎用開発環境 インターネットからのInboud通信のない開発用途 イントラ開発環境を分離します。開発環境コストも可視化します。
汎用本番環境 インターネットからのInboud通信のない本番用途 イントラ本番環境を分離します。コスト可視化に加え、開発作業から完全に分離します。
DMZ インターネット公開するサービス用途 DMZを分離します。インターネット公開サービスは24/365インターネット経由のメンテや脆弱性対応等、イントラ内環境メンテとはスピードが異なります。セキュリティ強化とアウトソーシングの観点から分離します。
基幹本番環境 基幹システム用途 規模によっては、汎用本番環境と共用で問題ありません。ただ、他システム連携や運用設備、AWSエンタープライズサポート(契約はアカウント単位)等、安定最優先の性質があるため、フットワークの軽さが要求される汎用本番環境との分離も選択肢のひとつです。
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.