Amazon Web Services ブログ

ガバメントクラウド活用のヒント『共同利用方式におけるコスト・ セキュリティ管理について』

ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。
「ガバメントクラウド活用のヒント」シリーズでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめています。過去の記事はこちらになります。

ガバメントクラウドの基本的な情報を知りたい方はガバメントクラウドの道案内『自治体職員編』をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。

本ブログでは、共同利用方式におけるコスト・セキュリティ管理について扱っていきます。
共同利用方式になったのでコスト・セキュリティについて把握できなくなり困っている自治体の方や、共同利用方式でアプリケーションを提供するベンダーの方にお役立ていただける内容となっています。

共同利用方式の場合にコスト・セキュリティ状態をどのように管理できるか？

共同利用方式では、自治体は AWS アカウントの運用管理を個別に行わない前提となっており、 AWS アカウントのユーザーが払い出されないため、自治体職員はコストなどの情報を確認できません。
共同利用方式を SaaS と捉え、インフラのコスト・セキュリティの管理をパッケージベンダーへ一任するという考え方もあります。
一方で、従来通りインフラのコスト・セキュリティの情報を確認したい自治体の方もいらっしゃると思います。
AWS では、一部のコスト・セキュリティの情報に関しては、専用のダッシュボードを Amazon QuickSight で作成することで、AWSアカウントのユーザーを作成することなく自治体職員の方が確認できます。※
ここでは上記のニーズに対応できるよう、インフラのコスト・セキュリティの情報を Amazon QuickSight で可視化する方法について説明します。

※ ダッシュボードの項目が多ければ多いほど実装コストも増えるため、ダッシュボードに載せる項目は情報の重要度と実装コストのバランスを取りながら考える必要があります。

コスト

ここでは、以下の 2 つのケースについてコストを可視化する方法について説明します。

  • 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 (アカウント分離方式)
  • 1 つの AWS アカウントが複数団体のリソースを含む場合 (ネットワーク分離・アプリケーション分離方式)

1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合

1 つの AWS アカウントに 1 つの団体のリソースしか含まれないアカウント分離方式の場合、Cost and Usage Dashboard (CUD) , Cost and Usage Dashboards Operations Solution Dashboard (CUDOS) を利用すれば容易にコストに関する情報をダッシュボードに表示できます。
詳しい情報は 簡単に構築できる AWS コスト可視化ダッシュボードのユースケース – Cost and Usage Dashboard (CUD) と CUDOS – をご覧ください。

CUD はセットアップが簡単な分 CUDOS に比べ表示できる情報量が少なく、CUDOS は表示できる情報量が多い分セットアップに AWS CloudFormation 等の利用が必要という特徴があるため、用途に合わせてご選択ください。
以下の URL に CUDOS のダッシュボードのサンプルが公開されています。

CUDOS サンプルダッシュボード: https://cid.workshops.aws.dev/demo?dashboard=cudos
例えば、Compute のタブでは月毎の Amazon EC2 の利用料の推移を確認できます。

図 1) CUDOS の Compute ダッシュボードの例

1 つのAWSアカウントが複数団体のリソースを含む場合

ネットワーク分離・アプリケーション分離の方式を採用する場合や、共用リソースがある場合は費用按分について考える必要があります。

費用按分の戦略

費用按分の方法の考え方の一例として「リソースの Owner が明確なものはコスト配分タグで費用を按分し、タグ付け不可の場合・複数の団体で同じリソースを共用する場合は利用量・団体の人口規模等の指標で按分する」という考え方があります。
ここでは、上記の方法で費用按分を実施する方法の概要について説明します。

なお、ガバメントクラウドにおいて、自治体が利用する AWS アカウントは AWS Organizations のメンバーアカウントにあたるため、コスト配分タグコストタグを有効化できません。
そのため、管理アカウントで既に有効化されているタグを利用してコスト按分を行う必要があります。
既に有効化されているコストタグについては GCAS (Government Cloud Assistant Service) の記載をご参照ください。

タグ付け戦略

団体名のタグ

タグ付け可能なリソースは団体ごとにタグ付けを行います。
タグ付け可能なリソース一覧は AWS Resource Groups とタグエディタで使用できるリソースタイプ や リソースタグの API リファレンス をご参照ください。

AWS CloudFormation・AWS CDK 等の IaC ツールを利用している場合、スタック単位でタグ付けが可能なため、簡単にタグ付けを行うことができます。

具体的には Owner=<団体名> といったタグを付けておきます。
タグ付け可能ではあるものの、複数の団体で同じリソースを共用する場合は按分方法ごとにタグを付けていきます。

按分方法ごとのタグ

複数の団体で共有するリソースは按分方法ごとにタグを付けます。
例えば、VPC FlowLog・API Gateway・ELB 等のアクセスログから各団体がどの程度システムを利用しているか計算し、費用按分する方法があります。
「API Gateway のアクセスログから団体ごとの利用料を算出するリソース」は Owner=divideByApi というタグを付けます。

他の按分の方法として、利用団体の人口で按分する方法が考えられます。例えば、更新サーバー (WSUS) などは団体規模が大きいほど更新対象のサーバー台数が多くなります。
その場合、団体規模とシステムの利用比率がおおよそ同じになることが多いため、団体の人口比で利用料を割ることを考えます。
この場合、Owner=divideByPopulation というタグを付けます。

集計・可視化

ここではタグ付けしたリソースのコストを集計・可視化する方法について説明します。
AWS Data Exports を利用すると請求データを Amazon S3 へエクスポートできます。
Amazon Athena の データベースとテーブルの作成 の手順に従うと、Amazon S3 に配置してあるデータに対し、Athena SQL を利用した処理ができるようになります。
以下の計算を Amazon Athena で行い、新しいテーブルとして保存します。

  1. 団体名のタグ ごとにコストを集計
  2. 按分方法ごとのタグ で集計したコストをタグの値ごと合計し、按分方法に沿って計算・1 で計算した各団体のコストに加算
  3. タグ付けできないコストはあらかじめ決めておいた按分方法で費用を按分し、2 のコストへ加算

図 2) 特定のタグがついたコストのみ集計して QuickSight で可視化した例

その後、Amazon Athena データを使用したデータセットの作成 に従って、Amazon QuickSight から Amazon Athena のデータを参照します。
最後は Amazon QuickSight でのデータの視覚化 の手順に従い各自治体向けのダッシュボードを構築します。
Amazon QuickSight はダッシュボード単位で認可の制御ができるため、各自治体のユーザーごとに閲覧可能なダッシュボードの設定ができます。
以下の画像は上記と同様の方法で AWS Deta Exports により出力したデータから、特定のタグがついている料金のみ集計し、ダッシュボードを作成したものです。

セキュリティ

ここでは、以下の 2 つのケースについてセキュリティを可視化する方法について説明します。

  • 1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合 (アカウント分離方式)
  • 1 つの AWS アカウントが複数団体のリソースを含む場合 (ネットワーク分離・アプリケーション分離方式)

例として以下のようなダッシュボードを構築できます。（例は簡素なものとなっておりますが、簡単に表やグラフを追加することができます）

図 3) Security Hub の検出結果を QuickSight で可視化した例

図 4) Trusted Advisor の検出結果を QuickSight で可視化した例

S-1. Security Hub の結果を QuickSight で可視化する方法 (1 つの AWS アカウントが 1 つの団体のリソースのみ含む場合)

以下の手順を踏むことによって、 Security Hub の検出結果を QuickSight で可視化することができます。


1. GitHub 上にある aws-security-hub-findings-export のソリューションを利用して Security Hub の検出結果をリアルタイムに S3 にエクスポートします。
2. Security Hub のエクスポート結果の json ファイルでは、キーに Amazon Athena で処理できない記号が含まれています。詳しくは、ドキュメントをご参照ください。このため、AWS Glue で Glue ETL Job をセットしてスキーマを変更する必要があります。具体的には、DynamicFrame.apply_mapping() メソッドを使用して、フィールドの名前やフィールドタイプを変更しましょう。コードの例はドキュメントに存在するので、ご参照ください。
3. AWS Glue Data Catalog Table を作成します。クローラーを使ってテーブルを構築し、スキーマを変更した後の S3 上のファイルからデータを読み込む方法が便利です。アカウントや日付でパーティション分割されているため、[Create a single schema for each S3 path (各 S3 パスの単一のスキーマを作成する)][Update all new and existing partitions with metadata from the table (すべての新規および既存のパーティションをテーブルからのメタデータで更新します)]にチェックを入れて単一のスキーマで読み込むことを推奨します。
4. QuickSight の Athena データソースを選択し、Athena ワークグループと Glue カタログ、データベースを指定してデータを読み込みます。
5. QuickSight を利用して、必要なデータを表やグラフで表示します。

S3 のクロスアカウントレプリケーション機能を使って、 S-1. の手順 1 で S3 にエクスポートしたデータをアカウントを跨いでレプリケーションすることもできます。詳しくはドキュメントをご覧ください。

1 つのAWSアカウントが複数団体のリソースを含む場合

Security Hub の検出結果がリソースに紐づいている場合、Secuirty Hub のエクスポートされた検出結果にはそのリソースにつけられたタグの情報も含まれているため、リソースに対して自治体ごとにタグをつけておけば、その情報を用いて QuickSight 上でフィルタリングすることができます。タグの情報は、Resources フィールドの中の Tags フィールドに含まれています。

タグ付け戦略に関しては、コストの章をご覧ください。

ガバメントクラウド上のTrusted Advisor の検出結果を QuickSight で閲覧する方法

AWS Organizations 上のアカウントの Trusted Advisor の検出結果を QuickSight 上に集約する方法として、一般的には Trusted Advisor の組織ビューや、Cloud Intelligence Dashboard の一つである Trusted Advisor Organizational (TAO) Dashboard があります。
しかし、ガバメントクラウド上では、AWS Organizations のマネジメントアカウントにアクセスできないため、これらの方法が使えません。

今回は、以下の条件下で AWS Organizations 配下にある特定のメンバー AWS アカウント上の QuickSight に、Trusted Advisor のデータを集約し可視化を行うことを考えます。

  • AWS Organizations のマネジメントアカウントにはアクセスできず、さらに、デジタル庁が適用していサービスコントロールポリシーの範囲内の権限しか使ってはいけない。
  • Organizations 配下にある対象ではないアカウントのデータにアクセスしない。
  • 各メンバーアカウントにはビジネスプラン以上のサポートプランが設定されている。

なお、Trusted Advisor の検出結果はアカウント全体の状態を表すものでありリソースに紐づけられたタグの情報が含まれないため、同じアカウントに異なる自治体のリソースが含まれている場合 (ネットワーク分離方式・アカウント分離方式) もアカウント単位の情報を確認することになります。

以下の手順で、これを実現することができます。

  1. 集約元となるアカウント（QuickSight を構築するアカウントを含む）の北部バージニア (us-east-1) リージョンでこちらの yaml ファイルを用いて CloudFormation スタックを作成します。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にして、他は 「no」または未記入にします。
  2. QuickSight を構築するアカウントの、サービスコントロールポリシーで使用が認められているリージョンでこちらの yaml ファイルを用いて CloudFormation スタックを作成します。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にして、他は 「no」または未記入にします。
  3. Accounts-Collector-Function-<スタック名>という名前の Lambda 関数において、AWS Organizations から対象となるアカウント ID やアカウント名を取得している部分を、直接指定するように書き換えます。環境変数に記載してそれを取り込むことをお勧めします。
  4. EventBridge が定期的に発火して、Trusted Advisor のデータを収集します。すぐに発火させたい場合は、Scheduler-For-Accounts という EventBridge ルールを無効化して有効化してみてください。
  5. QuickSight Enterprise Editionを有効にします。 Amazon QuickSight にアクセスして、管理者ユーザーを作成し、ユーザー名とアカウント名をメモします。
  6. 集約先となるアカウントのサービスコントロールポリシーで使用が認められているリージョンで、こちらの yaml ファイルを用いて CloudFormation スタックを作成します。上二つの確認事項には「yes」と回答し、先ほどメモしたユーザー名をUser name of QuickSight userに、Trusted Advisor のデータが入っている S3 バケット名を Path to Optimization Data Collection S3 bucket に記入します。Deploy TAO Dashboard を「yes」にして、スタックを作成します。
  7. スタックが作成されると、TAODashboardURL が出力されます。ここにアクセスし、有効な QuickSight ユーザーでログインすると、ダッシュボードを見ることができます。

まとめ

本ブログでは、共同利用のセキュリティ・コスト のダッシュボードについて取り扱っていきました。ダッシュボードの項目が多ければ多いほど実装コストも増えるため、ダッシュボードに載せる項目は情報の重要度と実装コストのバランスを取りながら考える必要があります。
共同利用方式において、自治体の方へどんな情報を提供するか・実装方法はどうしようか迷われていた方の参考になっていれば幸いです。
自治体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へご連絡ください。

免責事項

  • 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。
  • 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。
  • 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。
  • 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。

ガバメントクラウドに関するお問い合わせ

AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。
本記事で紹介した内容に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。
https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

著者について

押川令（Ray Oshikawa）

パブリックセクターの自治体担当ソリューションアーキテクトです。
最近は自治体関連システムを担当されている企業様のサポートや、自治体業務システムのガバメントクラウドへの移行支援を中心に活動しています。

 

松本 侑也 (Yuya Matsumoto)

パブリックセクターの自治体担当ソリューションアーキテクトです。
最近ではガバメントクラウドへの基幹システムの移行や、生成系AIの活用支援を中心に活動しています。