ENECHANGE Developer Blog

ENECHANGE開発者ブログ

AWSマネジメントコンソールのmyApplicationsダッシュボード、こんなふうに作りました

VPoTの岩本 (iwamot) です。

2023年11月に、AWSマネジメントコンソールの新機能「myApplications」が発表されました。アプリケーションのコスト、パフォーマンス、セキュリティといった情報を、ひとつのダッシュボードで見られる機能です。

aws.amazon.com

便利そうなので、ENECHANGEでもダッシュボードを作り、事業部のエンジニアに見てもらっています。

今回の記事では、どんなふうにダッシュボードを作ったのかをご紹介します。どなたかの参考になれば幸いです。

ダッシュボード作成の流れ

結論から書くと、下記の流れでダッシュボードを作りました。

  1. アプリケーションタグキーの設定
  2. アプリケーションの作成
  3. Terraformテンプレートへのdefault_tagsの追加
  4. ダッシュボード参照用IAMポリシーの追加

それぞれ説明します。

1. アプリケーションタグキーの設定

まず、Service Catalog AppRegistryのアプリケーションタグキーを Service としました。

これは、アプリケーションとリソースを Service タグの値で関連付けたいためです。ENECHANGEでは、アプリケーションの識別に Service タグを使っています。そのため、myApplicationsでも同じように識別するのがベストだと判断しました。

もし、アプリケーションの構築にCloudFormationを使っていたら、アプリケーションタグキーは設定せず、アプリケーションにCloudFormationスタックを関連付けると思います。

2. アプリケーションの作成

続いて、myApplicationsではなくService Catalog AppRegistryでアプリケーションを作成しました。

これは、Service Catalog AppRegistryだと、タグを指定してアプリケーションとリソースを関連付けられるためです。

Service Catalog AppRegistryではタグでリソースを検索できる

一方、myApplicationsの作成フローでは、今のところタグに絞った検索ができません。関連付けたいリソースがすべて検索結果に含まれるのか不安です。

myApplicationsではタグに絞った検索ができない

そのため、Service Catalog AppRegistryでアプリケーションを作成するほうが、現時点ではスムーズに進められます。

3. Terraformテンプレートへのdefault_tagsの追加

アプリケーションを作成すると、関連付けられたリソースに awsApplication タグが追加されます。

ENECHANGEでは、アプリケーションの構築にTerraformを使っており、そのままではリソースとテンプレートの差分が生じるため、対処する必要がありました。

具体的には、下記のようにdefault_tagsを追加することで解決しています。

data "awscc_servicecatalogappregistry_application" "this" {
  id = "<アプリケーションID>"
}

provider "aws" {
  region = "ap-northeast-1"

  default_tags {
    tags = {
      "Service"        = "my-application"
      "awsApplication" = data.awscc_servicecatalogappregistry_application.this.tags["awsApplication"]
    }
  }
}

4. ダッシュボード参照用IAMポリシーの追加

最後に、事業部のエンジニアがダッシュボードを参照できるよう、IAMポリシーを追加しました。

CloudTrailでイベント履歴を確認したり、ダッシュボードの挙動から推測したりを経て、下記のポリシーを採用しています。

{
    "Statement": [
        {
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "ce:GetCostAndUsage",
                "ce:GetCostForecast",
                "cloudformation:DescribeStacks",
                "cloudformation:ListStackResources",
                "cloudformation:ListStacks",
                "cloudwatch:DescribeAlarms",
                "cloudwatch:EnableTopologyDiscovery",
                "cloudwatch:GetMetricData",
                "config:SelectResourceConfig",
                "ec2:DescribeInstances",
                "elasticloadbalancing:DescribeLoadBalancers",
                "lambda:ListFunctions",
                "securityhub:DescribeHub",
                "securityhub:GetAdhocInsightResults",
                "servicecatalog:GetApplication",
                "servicecatalog:ListApplications",
                "ssm:GetInventory",
                "ssm:GetOpsSummary",
                "ssm:GetServiceSetting",
                "ssm:ListAssociations",
                "synthetics:DescribeCanaries",
                "tag:GetResources"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "resource-groups:ListGroupResources",
                "servicecatalog:ListAssociatedResources",
                "servicecatalog:ListTagsForResource"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/aws:servicecatalog:applicationName": "my-application"
                }
            },
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}

ただし、ダッシュボードからのリンク先、たとえばCost ExplorerやSecurity Hubといったサービスの提供については、いったん無視しました。事業部からのリクエストがあれば、対応を検討するつもりです。

できたダッシュボード

これで、下図のようなダッシュボードを事業部のエンジニアに見てもらえるようになりました。小さくて見づらいかもしれません。

とくに便利そうなウィジェットは「コストと使用状況」と「Security」です。いずれもアプリケーションの状況が把握しやすくなりました。

一方で「DevOps」は、Systems Manager OpsCenterを使っていないため、ENECHANGEでは非表示にしてよさそうです。

また「コンピューティング」も、予定しているEC2からFargateへの移行が終われば、非表示でよさそうな気がします。EC2とLambdaだけでなく、Fargateもサポートしてくれるとよいですね。

おわりに

以上、ENECHANGEでのmyApplicationダッシュボード作成例をご紹介しました。

Service Catalog AppRegistryがいきなり出てきて、面食らった方もいらっしゃるかもしれません。ぼくもそうでした。試行錯誤のなかで「myApplicationsアプリケーション=Service Catalog AppRegistryアプリケーション」だと分かり、腑に落ちた感じです。

myApplications自体は、必要なIAMポリシーがドキュメントに書かれていない点を含め、まだまだ発展途上な印象です。今後に期待しましょう。