Datadog の AWS Integration for Multi-Accounts (AWS CloudFormation StackSets) 徹底解説

## はじめに
こんにちは、Datadog Japan で Sales Engineer をしている AoTo(@AoTo0330) です。


先日、Datadog の AWS Integration で Multi-Accounts のサポートが開始されたので、その裏側の AWS CloudFormation StackSets についてまとめてみました🐶　AWS Integration と AWS CloudFormation StackSets の基本からも振り返っているので、情報の整理としてもご活用ください。

また、以前に AWS Integration を含む[３大クラウドの Datadog Integrations のアーキテクチャ](https://qiita.com/AoTo0330/items/545a229fd33d92c01562)についてもまとめていますので、ご興味があればご覧ください。

https://qiita.com/AoTo0330/items/545a229fd33d92c01562

## AWS Integration の概要
AWS Integration では監視対象の AWS 環境に必要最低限のリソースのみを作成し、主に CloudWatch Metrics などから情報を取得できるようにする機能です。

:::note info
Cloud Cost Management、Logs Archive、Workflows(Public beta)などでも、追加の設定を行うことで同じリソースを利用できます。
:::

AWS Integration は CloudFormation 等を用いた自動セットアップと、自ら AWS 上でリソースを作成し Datadog Organization 上で登録を行う手動セットアップの大きく2つの方法がサポートされています。
どちらも作成されるリソースは同じなので、今回は手動セットアップの手順を見ながら、AWS 上に作成されるリソースについて見てみましょう。
- [AWS Integration - セットアップ](https://docs.datadoghq.com/ja/integrations/amazon_web_services/#%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97)
- [AWS マニュアルセットアップガイド](https://docs.datadoghq.com/ja/integrations/guide/aws-manual-setup/?tab=roledelegation)

以上を参照すると、AWS で作成が必要なリソースは以下の IAM リソースであることがわかります。
- IAM policy
- IAM role

記載の方法では、カスタマー管理ポリシーを作成することになります。インラインポリシーでも同様のことが実現可能ですが、[AWS のドキュメント](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html "管理ポリシーとインラインポリシーの比較")からもカスタマー管理ポリシーが推奨されていることがわかります。特に、このインテグレーションの場合は **バージョニングとロールバック** の観点から、設定変更を追跡できることがメリットです。
> **バージョニングとロールバック**
カスタマー管理ポリシーを変更しても、変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。IAM は、最大 5 つのバージョンのカスタマー管理ポリシーを保存します。ポリシーバージョンを使用し、必要に応じてポリシーを以前のバージョンに戻すことができます。

では、なぜ IAM リソースの作成のみで Datadog と情報を連携することができるのでしょうか？

これは、Datadog がクローラーを利用して監視対象の AWS アカウントの CloudWatch Metrics API に定期的にアクセスをする仕組みを取っているためです。そのため、これらの情報は Datadog 側からアカウント毎に Pull 型での情報取得をすることになります。

この際、監視対象の AWS アカウントでは Datadog の **AWS Account ID (464622532012)** と[**External ID**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html "How to use an external ID when granting access to your AWS resources to a third party")の設定が必要となります。[^1]
[^1]:この内容から、 Datadog のクローラーは AWS 上で動いていることがわかります。

これらの情報を元に、**IAM role trust policy** を定義し、クローラーのアクセスに対し **Assume role** するという動きをするのですが…これだけだと何を言っているかわかりませんね…
これらの内容についてはそれだけで1つの記事が書けてしまうため、先人方の素晴らしい記事と図解をご参考いただけると幸いです。
- [IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた](https://dev.classmethod.jp/articles/iam-role-passrole-assumerole/)
- [AssumeRole について DiveDeep する](https://blog.serverworks.co.jp/assume-role-divedeep)

## AWS CloudFormation StackSets の概要
AWS Integration の自動セットアップでは、以上のリソースを [AWS CloudFormation](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/Welcome.html "AWS CloudFormation の概要")(以下、CFn) を利用して、簡単にデプロイすることができます。CFn を利用する理由としては、**インフラストラクチャをすばやく複製** できることが主な理由として挙げられます。
> **インフラストラクチャをすばやく複製**
> -中略- 
> CloudFormation テンプレートを再利用して、一貫性のある繰り返し可能な方法でリソースを作成します。テンプレートを再利用するには、一度だけリソースを記述します。これにより、複数のリージョンで同じリソースを何度でもプロビジョニングできます。

ここで、[CFn StackSets](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html "StackSets の概念") について確認しておきましょう。CFn StackSets は単一の CFn テンプレートを使用して、マルチリージョン・アカウントで同一リソースを作成するための機能です。この時、ターゲットアカウントへのスタックのリファレンスとして、Stack Instance が用意され、StackSets が更新されるとその内容が反映されます。[^2]
[^2]:CFn StackSets はリージョンリソースですが、Datadog Integration からはリージョンを選択することができません。遷移先の AWS Management Console 上での設定を確認の上作成するように注意してください。
> スタックセットでは、1 つの CloudFormation テンプレートを使用して、複数のリージョンの AWS アカウント にスタックを作成できます。スタックセットの CloudFormation テンプレートは、各スタック内のすべてのリソースを定義します。スタックセットを作成する際、使用するテンプレートに加え、そのテンプレートで必要なパラメータや機能を指定します。

マルチアカウントにスタックのリソースをデプロイするには、「サービス管理のアクセス許可」を選択する必要があります。これによって、AWS Organizations によって管理されている複数のアカウント上で Stack Instance をデプロイすることができます。
> サービスマネージド型のアクセス許可を使用する場合、AWS Organizations が管理するアカウントにスタックインスタンスをデプロイできます。このアクセス許可モデルを使用すると、必要な IAM ロールを作成する必要はありません。ユーザーに代わって StackSets が IAM ロールを作成します。このモデルでは、将来組織に追加するアカウントへの自動デプロイをオンにすることもできます。 

## Multi-Accounts のサポートでできるようになったこと
AWS Integration の CFn Template は Datadog が提供・管理しており、作成されるリソースの詳細を意識せずに監視したい AWS 環境に必要最低限のリソースを作成することができます。[^3]
[^3]:　実は、Datadog が管理している CFn Template はインテグレーションの他に　Datadog の設定関連で複数あります。ご興味があれば、[Datadog-Amazon CloudFormation](https://docs.datadoghq.com/ja/integrations/guide/amazon_cloudformation/) をご参照ください。

Datadog のアプリケーションから AWS Integration タイルを選択すると、[+ Add AWS Account(s)]ボタンが表示され、シングル・マルチアカウントで AWS Integration に必要なリソースを CFn を用いてデプロイすることができます。
この時、シングルアカウントでは CFn Stack を特定リージョンで作成し、デプロイすることになります。
一方、マルチアカウントの場合は CFn StackSets を作成し、複数アカウントで同時にデプロイすることができます。
- [AWS 組織向け AWS インテグレーションマルチアカウント設定](https://docs.datadoghq.com/ja/integrations/guide/aws-organizations-setup/)
:::note warn
Add Multiple AWS Accounts を選択し、[Launch CloudFormation StackSet]ボタンを選択すると、CFn StackSets の設定ページに遷移します。この時、テンプレートURLやその他のパラメータは AWS　Management　Console で手動でパラメータを追加する必要があります。
(Single AWS Account の場合はパラメータが反映された状態の画面に遷移します)
:::

仕組みとしては、以下の図のようになります。
![AWS Integration for Multi-Accounts Architecture.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/9c3f590d-94df-53a6-9ef1-1c862362c1d2.png)


Datadog　が　Multi-Accounts(CFn StackSets)をサポートしたことにより、AWS　Organization　上で管理されているマルチアカウント上で、すぐに　AWS　Integration　を有効化することができます。[^4]
[^4]:サポート前も、公開されている CFn Template を用いて CFn StackSets を作成することは可能でしたが、Datadog 側で Integration を認識するためには、アカウント毎に作成された IAM role を手動で登録する必要がありました。

さらに、公式に AWS Integration で Multi-Account がサポートされたことにより、 お困りの場合は [Datadog の技術サポート](https://www.datadoghq.com/ja/support/)を利用できるので安心です。

## おわりに
この記事では、Datadog の AWS Integration と CloudFormation の概要から振り返り、AWS Integration の　Multi-Account サポートによってできるようになったことをまとめました。

それぞれの内容について、何か皆さんの気づきになる点があれば幸いです。