マルチアカウントによるクラウド共通基盤について紹介します
はじめに
エンタープライズ企業において、クラウドファースト/クラウド・バイ・デフォルトやクラウドシフトといった方針の元、業務システムをFUJITSU Hybrid IT Service FJcloud-OやAmazon Web Services (AWS)などのパブリッククラウドへ移行する動きが始まったのは皆様ご承知の通りかと存じます。
業務システムを実際に利用するユーザー部門が中心となって業務システムのクラウド移行が進んだ場合、その業務システムの運用/管理を行うシステム部門にとっては好ましくない以下のような状況が発生してしまうケースが散見されました。
① 共通機能の重複
企業内ネットワーク－パブリッククラウド間の閉域網接続や利用者の認証機能、細かい点で言えばDNSサーバ/NTPサーバなど、企業内で共通して持つべき機能を業務システムごとに構築/運用してしまい、 無駄なコストが発生した。
② ICTコストの不明確化
パブリッククラウドを業務システムごとに契約したため、システム部門がインフラ基盤にかかるコスト全体を把握できなくなってしまい、ICT投資の費用対効果評価や全体最適化が難しくなった。
③ セキュリティ/ガバナンスレベルの不均一化
オンプレミスではシステム部門が担っていたセキュリティ（不要なTCP/UDPポートのブロック、ウィルス対策ソフトの導入 など）およびガバナンス （各種ログの取得、ローテーション、バックアップ など）について、パブリッククラウドではクラウドベンダーではなくクラウド利用者自身が作り込む必要があるが、 ユーザー部門に詳しい者がいないケースもあって業務システムごとにレベルが不揃い（特に酷いところでは未実施！）になってしまった。
シングルアカウントによるクラウド共通基盤とその課題
このような状況を受け、グループ企業におけるパブリッククラウド利用のルール/ガイドラインを定めた「クラウド利用ポリシー」を策定するエンタープライズ企業のお客様が多数いらっしゃいました。その多くは元々お持ちであったプライベートクラウド向けの利用ポリシーを下敷きにパブリッククラウド向けのものを定めており、そのポリシーに則った運用が可能な共通基盤をパブリッククラウド上に構築/運用しました。 パブリッククラウドとしてAWSを選定されたあるお客様の場合、１つのAWSアカウントをシステム部門が契約し、各ユーザー部門からの申請に基づいてVPCやIAMユーザー/ロールを作成/割振するといった運用です。
１つのAWSアカウントに全ての業務システムを搭載する方針により、先ほど述べた３つの好ましくない状況（①共通機能の重複、②ICTコストの不明確化、③セキュリティ/ガバナンスレベルの不均一化）は改善することができました。
その一方、以下のような新たな課題が表面化しました。
④リードタイムの長期化
コンピュートリソース（EC2インスタンス、EBSボリューム、AMI など）の新規払出し（プロビジョニング）や既存リソース修正（リサイズ）にも申請書の提出やワークフローシステムでの回覧といったプライベートクラウド時代の申請/承認プロセスが引き継がれたため、申請～承認～変更に時間がかかる（よくあるケースで１～２週間）
⑤ IAMポリシーの複雑化
対象の業務システムだけを操作（起動、停止、再起動、バックアップ取得、リストア など）が可能な権限をIAMユーザーへ付与したいが、それを実現するためのIAMポリシーの設計/テスト/管理が複雑であった（業務システム間で連携が行われていると、さらに複雑に...）
⑥ 社内調整工数の増加
AWSアカウント全体に対して利用制限があるリソースがあるため、どの業務システムへ利用を許可するかをユーザー部門間で調整した。
このようにせっかくパブリッククラウドを導入したにもかかわらず、そのメリット（素早いプロビジョニング、柔軟なリサイズ、従量課金によるコスト最適化 など）を得られているとは必ずしも言えない状況となってしまったため、パブリッククラウド利用に適した新しいクラウド利用ポリシーとそれを実現する共通基盤の構築/運用が求められました。
マルチアカウントによるクラウド共通基盤とその実現方法
新しいクラウド利用ポリシーはお客様の業種/規模/開発スタイル/承認プロセスやパブリッククラウドへの要求事項/期待感によって最適解が異なるため、本稿では以下のようなクラウド利用ポリシーを定めたお客様を想定し、AWS上でこのポリシーに沿った運用を行える共通基盤を実現した例をご紹介します。・業務システムごとに独立したAWSアカウントを作成する
・AWSアカウントの作成/削除はユーザー部門ではなく、システム部門が実施する
・業務システムに必要なリソースのプロビジョニングやリサイズは利用部門へ権限委譲し、利用部門で実施する
共通基盤の流れは以下の通りです。
1．システム部門は全ての子アカウントの親となるAWSアカウント（以下、マスターアカウント）を作成する。
2．システム部門はマスターアカウントでログインし、AWS Organizations機能を使用して共通機能（閉域網接続、認証機能、DNSサーバ/NTPサーバ など）を構築/運用するためのAWSアカウント（共通機能アカウント）を作成する
3．システム部門は共通機能アカウントでログインし、共通機能を実装する
4．ユーザー部門はシステム部門へ業務システム用インフラ基盤の利用申請を行う。（本ステップは従来の申請/承認プロセスを踏襲する想定）
5．システム部門はマスターアカウントでログインし、AWS Organizations機能を使用して申請/承認されたユーザー部門向けのAWSアカウント（業務アカウント）を作成する
6．AWS Organizationsの一括請求 (Consolidated Billing) を使用し、業務アカウントの支払いをマスターアカウントに振り向ける
7．システム部門は業務アカウントでログインし、AWS CloudTrailのログ出力先をマスターアカウントのS3バケットを指定して有効にする。
AWS Configなど他のセキュリティ/ガバナンス施策も同様に実施する
8．システム部門はユーザー部門へAWSアカウント払い出しを連絡し、利用に必要な情報（ログイン方法、クレデンシャル など）を伝える
9．ユーザー部門は業務アカウントでログインし、業務システムの構築を始める
おわりに
パブリッククラウドを前提とした新しいクラウド利用ポリシーとそれを実現する共通基盤についてご紹介しましたが、いかがでしたでしょうか。
最後に、新しい共通基盤がどのように課題を解決しているのかをまとめます。
① 重複した共通機能の単一化
共通機能を共通機能アカウントに集約して各業務アカウントへサービス提供し、重複していた共通機能を単一化できました。
共通機能アカウントと業務アカウントの接続にはVPC PeeringやAWS Transit Gatewayを使用できます。
② AWSにかかるコストの明確化
AWS Organizationsの一括請求を使用し、業務アカウント単位でAWSにかかるコストを把握できました。本稿では触れていませんが、リソースへタグ付けを行うことでサービス単位/環境単位でのコスト把握も可能と考えております。
③ 最低限のセキュリティ/ガバナンスレベルの均一化
業務アカウント作成時、システム部門にて業務アカウントのAWS CloudTrail や AWS Config などのセキュリティ/ガバナンス施策を実施しました。
詳細は割愛しましたが、併せてAWS Organizations のService Control Policy (SCP) を利用し、業務部門が誤っておよび故意にAWS CloudTrail や AWS Configを無効化できないように設定しました。
④ リードタイムの短縮
リソースのプロビジョニングやリサイズをユーザー部門が業務アカウントを使用して自身で行えるようになったため、リードタイムが大幅に短縮しました。（数分～数時間）
⑤ IAMポリシーが不要
業務システム間のリソース区分をIAMポリシーからAWSアカウントへ移行したため、IAMポリシーの設計/テスト/管理が不要になりました。
なお、業務アカウント内での役割（アプリ開発、インフラ構築、システム運用 など）に応じた権限はIAMポリシーで記述でき、業務アカウント内と業務システム間のポリシーが混在する複雑化は回避できます。
⑥ 社内調整の減少
リソース制限はAWSアカウントごとかかるため、数少ないリソースを巡る社内調整は不要になりました。
最後までお読みいただき、ありがとうございました。
