Terraform の Data Source で複数の AWS リソースの情報を取得する方法まとめ

作成日: 2024/03/03, 更新日: 2024/03/03

Terraform の Data Source を構築案件で利用する機会があったのですが、対応していない AWS リソースが多かったので利用ケースと対応表をまとめてみました。
Data Source が対応していない場合、External Data Source を利用したワークアラウンドも記載しています。

そもそも、Data Srouce はどのようなユースケースで利用するか？
AWS リソース毎の Data Srouce 一覧
External Data Source を利用して複数 AWS リソースの情報を取得する方法

そもそも、Data Srouce はどのようなユースケースで利用するか？

手動作成した AWS リソースを参照したい場合
- 手動作成した AWS リソースを参照する場合、 Data Srouce を利用します。
  - よくあるのは VPC 関連の AWS リソースの参照です。VPC やサブネット、共通化したセキュリティグループは一度作成したら変更する可能性が低いため、手動作成する整理にしたケースがあります。
  - ステートフルな AWS リソースや、手動で変更運用したい AWS リソースを参照するケースもあります。

Terraform テンプレートの Git レポジトリを分割している、もしくは、 Module を利用している場合
- 別の Git レポジトリで定義している AWS リソースを参照する場合に利用します。
  - 例えば、KMS キーは KMS 管理者が管理するための Git レポジトリで管理し、システム側は AWS のリソースの暗号化設定に Data Srouce を利用して KMS キーを参照します。

1 つ Git レポジトリで全ての AWS リソースを管理すると後々になって分離したくなることもあるので、ルールを決めて分割することをお勧めします。
- 僕が分割を検討する際には、「AWS サービス名/機能名」「管理者」「ステートレス/ステートフル」「ライフサイクル」の観点で分割を検討します。

また、Module を利用してリソースを定義している場合、Module で生成した AWS リソースを参照する場合に Data Srouce を利用します。
- 例えば、VPC を Module で定義している場合、その VPC を参照する場合に Data Srouce を利用します。

AWS の設定や構成に合わせて動的に AWS リソースを展開したい場合
- 監視や運用、CI/CD などの目的で AWS の設定や構成に合わせて AWS リソースを展開したい場合、複数の AWS リソースの情報が取得可能な Data Srouce を利用して繰り返し処理を行います。
  - 例えば、複数のロググループに対して同じパターンのメトリクスフィルターを設定したい場合など。

アカウントやリージョン情報を取得したい場合
- AWS アカウントやリージョンに関する情報を取得する際に Data Source を利用します。これにより、Terraform のコード内で動的にリージョンやアカウント ID を参照でき、柔軟なインフラストラクチャの構築が可能になります。
  - 例えば、クロスアカウントのリソース参照や、リージョンに応じたリソースの展開を行いたい場合など。

AMI やイメージ情報を取得したい場合
- AWS の AMI (Amazon Machine Image) や他のイメージ情報を取得するために Data Source を利用します。最新の AMI や特定の条件にマッチするイメージを動的に検索し、インスタンスやオートスケーリンググループなどで使用することができます。
  - 例えば、特定の OS バージョンの最新の AMI を取得して EC2 インスタンスを起動したり、Docker イメージを取得して ECS タスク定義を作成する場合など。

AWS リソース毎の Data Srouce 一覧

個人的によく利用する AWS リソースを対象にリストアップしてみました。
Data Srouce が非対応なものもありますが、External Data Source を利用して AWS CLI で AWS リソースの情報を取得すれば同様の定義が可能です。
単一系 Data Srouce と複数形 Data Srouce がありますが、複数形 Data Srouce は複数の AWS リソースの情報を取得することが可能な Data Srouce です。
- 単一系 Data Srouce では、対象とした AWS リソースが存在しない場合にエラーが発生しますが、複数形 Data Srouce では、対象とした AWS リソースが存在しない場合に空のリストを返します。
- これを応用することで、リソースの存在チェックを行うことが可能です。

AWSサービス名 ➖➖➖➖➖➖➖➖➖➖➖➖➖	AWSリソースタイプ名 ➖➖➖➖➖➖➖➖➖➖➖➖➖➖	単一系 Data Srouce ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖	複数形 Data Srouce ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
AWS IAM	ユーザー	aws_iam_user	aws_iam_users
〃	グループ	aws_iam_group	非対応
〃	ロール	aws_iam_role	aws_iam_roles
〃	ポリシー	aws_iam_policy	非対応
AWS CloudTrail	証跡	非対応	非対応
AWS Config	レコーダー	非対応	非対応
〃	アグリゲータ	非対応	非対応
〃	ルール	非対応	非対応
Amazon GuardDuty	ディテクター	aws_guardduty_detector	非対応
Amazon VPC	VPC	aws_vpc	aws_vpcs
〃	サブネット	aws_subnet	aws_subnets
〃	ルートテーブル	aws_route_table	aws_route_tables
〃	ルート	aws_route	非対応
〃	セキュリティグループ	aws_security_group	aws_security_groups
Amazon Route 53	ゾーン	aws_route53_zone	非対応
〃	レコード	非対応	非対応
Elastic Load Balancing	ロードバランサー	aws_lb	aws_albs
〃	リスナー	aws_lb_listener	非対応
〃	ターゲットグループ	aws_lb_target_group	非対応
Amazon EC2	インスタンス	aws_instance	aws_instances
Amazon AutoScaling	オートスケーリンググループ	aws_autoscaling_group	aws_autoscaling_groups
Amazon ECS	クラスター	aws_ecs_cluster	非対応
AWS Lambda	関数	aws_lambda_function	aws_lambda_functions
Amazon SQS	キュー	aws_sqs_queue	aws_sqs_queues
Amazon SNS	トピック	aws_sns_topic	非対応
Amazon RDS	インスタンス	aws_db_instance	aws_db_instances
〃	クラスター	aws_rds_cluster	aws_rds_clusters
Amazon Dynamo DB	テーブル	aws_dynamodb_table	非対応
Amazon S3	S3バケット	aws_s3_bucket	非対応
Amazon ECR	レポジトリ	aws_ecr_repository	非対応
AWS CodeCommit	レポジトリ	aws_codecommit_repository	非対応
AWS CodePipeline	パイプライン	非対応	非対応
AWS CodeBuild	ビルドプロジェクト	非対応	非対応
Amazon Athena	ワークグループ	非対応	非対応
Amazon CloudWatch	ダッシュボード	非対応	非対応
〃	ロググループ	aws_cloudwatch_log_group	aws_cloudwatch_log_groups
〃	メトリクスフィルター	非対応	非対応
〃	サブスクリプションフィルター	非対応	非対応
〃	アラーム	非対応	非対応
Amazon EventBridge	ルール	非対応	非対応
〃	スケジュール	非対応	非対応
AWS Backup	ボールト	aws_backup_vault	非対応
〃	プラン	aws_backup_plan	非対応
〃	セレクション	aws_backup_selection	非対応
AWS Systems Manager	パラメータ	aws_ssm_parameter	非対応
〃	ドキュメント	aws_ssm_document	非対応

External Data Source を利用して複数 AWS リソースの情報を取得する方法

カスタムの Data Source を定義したい場合、 External Data Source を利用します。
- external_external | Data Sources | hashicorp/external | Terraform Registry
- Data Source として既存リソースの情報を取得するため、 program で Bash や Python などのスクリプトを呼び出し、実行結果として JSON 形式の文字列を出力します。

CodePipeline の Data Source が非対応なため、Shell Script を使って情報を取得していきます。

まず、シェルスクリプトについて解説します。


          # !/bin/bash
          eval "$(jq -r '@sh "codepipeline_name_prefix=\(.codepipeline_name_prefix)"')"

          pipelines=$(
              aws codepipeline \
              list-pipelines \
              --query "pipelines[?starts_with(name, '"${codepipeline_name_prefix}"')].name" \
              --region ap-northeast-1 \
              --output json
          )

          # ポイント
          result=$(cat << EOS
          {
            "names": $(echo "${pipelines}" | jq '@json')
          }
          EOS
          )

          jq -n "$result"

ポイントとなる箇所は # ポイント の部分のヒアドキュメントの処理です。
names 配列にパイプライン名を格納したい場合、 | jq '@json' を省いた処理で定義するのをはじめに考えると思います。


          # ポイントの変更前
          result=$(cat << EOS
          {
            "names": $(echo "${pipelines}")
          }
          EOS
          )

          # result 変数
          {
            "names": [
              "test-pipeline01",
              "test-pipeline02",
              "test-pipeline03",
              "test-pipeline04",
              "test-pipeline05"
            ]
          }

この出力結果を Terraform の External Data Source 側で呼び出すと以下のエラーが発生します。
- エラーの通り、出力はキー/バリューの両方とも文字列でなくてはなりません。



          % terraform plan
          data.external.aws_codepipelines: Reading...
          ╷
          │ Error: Unexpected External Program Results
          │
          │   with data.external.aws_codepipelines,
          │   on test.tf line 2, in data "external" "aws_codepipelines":
          │    2:   program = ["bash", "${path.module}/ListCodePipelineNames.sh"]
          │
          │ The data source received unexpected results after executing the program.
          │
          │ Program output must be a JSON encoded map of string keys and string values.
          │
          │ If the error is unclear, the output can be viewed by enabling Terraform's logging at TRACE level.
          │ Terraform documentation on logging: https://www.terraform.io/internals/debugging
          │
          │ Program: /bin/bash
          │ Result Error: json: cannot unmarshal array into Go value of type string

このエラーを解決するため、Shell Script では文字列へ変換した配列を出力し、Terraform 側で文字列を配列へ戻します。
# ポイント の部分を最初の例に戻した場合の出力は以下のようになります。
- 配列の出力が | jq '@json' により文字列へ変換されてます。



          # ポイントの変更前
          result=$(cat << EOS
          {
            "names": $(echo "${pipelines}" | jq '@json')
          }
          EOS
          )

          # result 変数
          {
            "names": "[\"test-pipeline01\",\"test-pipeline02\",\"test-pipeline03\",\"test-pipeline04\",\"test-pipeline05\"]"
          }

次に、Terraform のコードについて説明します。



          data "external" "aws_codepipelines" {
            program = ["bash", "${path.module}/scripts/ListCodePipelineNames.sh"]
            query = {
              codepipeline_name_prefix = "test-pipeline0"
            }
          }

          # ポイント
          output aws_codepipelines_names {
              value = jsondecode(data.external.aws_codepipelines.result["names"])
          }

Terraform のテンプレートファイルと同じディレクトリに scripts ディレクトリを作成し ListCodePipelineNames.sh というスクリプトを参照させています。
query で codepipeline_name_prefix を引数として指定できるようにしてます。
- codepipeline_name_prefix を指定した場合、指定した文字列から始まるパイプライン名のみ参照します。

ポイントとなるのは # ポイント の Output の部分です。Terraform の関数 jsondecode() により、External Data Source の出力結果の names キーを参照し配列へデコードしてます。
実際には、他のリソースなどで参照する際に同じように定義を行い配列へ変換後、繰り返し処理を実装するようになります。