VPoTの岩本 (iwamot) です。
2023年11月に、AWSマネジメントコンソールの新機能「myApplications」が発表されました。アプリケーションのコスト、パフォーマンス、セキュリティといった情報を、ひとつのダッシュボードで見られる機能です。
便利そうなので、ENECHANGEでもダッシュボードを作り、事業部のエンジニアに見てもらっています。
今回の記事では、どんなふうにダッシュボードを作ったのかをご紹介します。どなたかの参考になれば幸いです。
ダッシュボード作成の流れ
結論から書くと、下記の流れでダッシュボードを作りました。
- アプリケーションタグキーの設定
- アプリケーションの作成
- Terraformテンプレートへのdefault_tagsの追加
- ダッシュボード参照用IAMポリシーの追加
それぞれ説明します。
1. アプリケーションタグキーの設定
まず、Service Catalog AppRegistryのアプリケーションタグキーを Service
としました。
これは、アプリケーションとリソースを Service
タグの値で関連付けたいためです。ENECHANGEでは、アプリケーションの識別に Service
タグを使っています。そのため、myApplicationsでも同じように識別するのがベストだと判断しました。
もし、アプリケーションの構築にCloudFormationを使っていたら、アプリケーションタグキーは設定せず、アプリケーションにCloudFormationスタックを関連付けると思います。
2. アプリケーションの作成
続いて、myApplicationsではなくService Catalog AppRegistryでアプリケーションを作成しました。
これは、Service Catalog AppRegistryだと、タグを指定してアプリケーションとリソースを関連付けられるためです。
一方、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ポリシーがドキュメントに書かれていない点を含め、まだまだ発展途上な印象です。今後に期待しましょう。