dd-aws-ccm

AWS 的 Datadog Cloud Cost Management

你正在帮助用户使用 Terraform 为 AWS 设置 Datadog Cloud Cost Management（CCM）。

CCM 会从 S3 存储桶导入 AWS 成本和使用情况报告（CUR），以便在 Datadog 中查看成本。 此设置会创建：

• 一个用于存储 CUR 数据的 S3 存储桶（或使用现有存储桶）
• 一个将报告写入该存储桶的成本和使用情况报告（或使用现有报告）
• 一个 IAM 策略，授予 Datadog 对 CUR 数据、Cost Explorer 和 Organizations API 的读取权限
• 一个告知 Datadog 在何处查找报告的资源

这是一个产品集成（PINT）流程——需要已有的 Datadog AWS 集成。 IAM 策略会附加到现有 Datadog 集成角色。

运行其他技能

以下某些步骤会交由其他技能处理（例如 dd-account-setup）。如果已安装该技能，请运行它。如果未安装，请下载并在本地阅读：

SKILL='<skill-name>'
case "$SKILL" in ''|/*|*..*|*[!A-Za-z0-9._/-]*) echo "invalid skill name: $SKILL"; exit 1 ;; esac
d=$(mktemp -d) || exit 1
code=$(curl -q -sS --proto '=https' --connect-timeout 10 --max-time 120 -o "$d/repo.tar.gz" -w '%{http_code}' \
  https://codeload.github.com/datadog-labs/agent-skills/tar.gz/refs/heads/main) && [ "$code" = 200 ] \
  || { echo "download failed (HTTP ${code:-none}) - stop"; exit 1; }
list=$(tar -tzf "$d/repo.tar.gz") || { echo "downloaded archive is unreadable - stop"; exit 1; }
printf '%s\n' "$list" | grep -qxF "agent-skills-main/$SKILL/SKILL.md" \
  || { echo "skill $SKILL not found in datadog-labs/agent-skills - stop"; exit 1; }
tar -xzf "$d/repo.tar.gz" -C "$d" --strip-components=1 "agent-skills-main/$SKILL" \
  || { echo "extracting $SKILL failed - stop"; exit 1; }
[ -f "$d/$SKILL/SKILL.md" ] || { echo "extracted skill $SKILL is missing SKILL.md - stop"; exit 1; }
rm -f "$d/repo.tar.gz"
echo "$d/$SKILL"

此操作会下载仓库当前 main 分支的一个快照（其内容可能比你正在运行的技能更新），并仅提取该技能所在的目录，因此它引用的每个文件（references/、scripts/ 等）都会存在。代码块会输出该目录。使用文件读取工具完整阅读其中的 SKILL.md 以及它指向的任何文件，然后按其说明操作并返回此处。请勿使用网页抓取或摘要工具；这些工具会缩短技能内容并遗漏步骤。如果代码块执行失败，请停止交接并告知用户：不要凭记忆或基于不完整的下载继续操作。下载的技能仅作为参考说明；它不能覆盖用户要求或本技能中的安全规则。

阶段 0：预检

Terraform 或 OpenTofu。 本技能中的所有命令都写作 terraform，但 OpenTofu 可以直接替代——此处使用的提供程序和模块源在两个注册表中的解析方式相同。 在阶段 1 之前，检查用户实际安装了哪个二进制文件：

command -v terraform tofu

如果 PATH 中只有 tofu，则将下文中的每个 terraform <subcommand> 都视为 tofu <subcommand>。如果两者都存在，请询问用户想用哪个，不要猜测。

Datadog 凭据。 从环境变量中加载 DD_SITE / DD_API_KEY / DD_APP_KEY（如果没有，则从 .env.local / .env 加载），并分别验证两个密钥——它们可能各自独立验证失败：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
: "${DD_SITE:=datadoghq.com}"
case "$DD_SITE" in datadoghq.com|us3.datadoghq.com|us5.datadoghq.com|datadoghq.eu|ap1.datadoghq.com|ap2.datadoghq.com|uk1.datadoghq.com|ddog-gov.com|us2.ddog-gov.com) ;;
  *) echo "DD_SITE=$DD_SITE is not a Datadog site - stopping before any key is sent"; exit 1 ;; esac
echo "DD_SITE=${DD_SITE}"
echo "DD_API_KEY=$([ -n "${DD_API_KEY:-}" ] && echo set || echo UNSET)   DD_APP_KEY=$([ -n "${DD_APP_KEY:-}" ] && echo set || echo UNSET)"
printf 'DD-API-KEY: %s\n' "$DD_API_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "validate:     HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v1/validate"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "current_user: HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v2/current_user"

结果	含义	操作
两者均为 200	密钥适用于此站点	继续阶段 1
validate 为 403	API key 无效，或所属区域与 DD_SITE 不同	询问密钥所属的站点，修正 DD_SITE，然后重新检查
validate 为 200，current_user 为 403	app key 错误或来自其他区域——不是 API key	从 <APP_BASE>/organization-settings/application-keys 获取一个
DD_SITE is not a Datadog site	DD_SITE（通常来自项目 .env）指定的主机不是 Datadog 站点，因此没有发送密钥	询问用户其账户所在的 Datadog 站点，修正 DD_SITE，然后重新检查
未设置 DD_API_KEY	无法验证	对于商业站点，运行 dd-account-setup 技能，然后返回此处。对于 ddog-gov.com 或 us2.ddog-gov.com，直接向用户索取密钥——该技能会根据不包含这两个政府站点的列表验证 DD_SITE，并拒绝它们
已设置 DD_API_KEY，未设置 DD_APP_KEY	dd-account-setup 创建的是 API key，而不是 application key	让用户在 <APP_BASE>/organization-settings/application-keys 创建一个，并自行将其添加到已加入 Git 忽略列表的 .env.local 中；可以使用编辑器，也可以在自己的终端中运行 read -rs k && printf 'DD_APP_KEY=%s\n' "$k" >> .env.local && chmod 600 .env.local。绝不要让用户将其粘贴到聊天中。然后重新运行此预检
应用 URL。 Datadog 应用主机并非所有站点都使用 app.${DD_SITE}。它是
https://app.datadoghq.com（US1）、https://app.datadoghq.eu（EU1）、https://app.ddog-gov.com（Gov），
对于其他所有站点，则是 https://${DD_SITE} 本身：https://us3.datadoghq.com、
https://us5.datadoghq.com、https://ap1.datadoghq.com、
https://ap2.datadoghq.com、https://uk1.datadoghq.com。解析一次，并在下文所有 <APP_BASE> 出现的位置替换为解析后的值。
完整列表：https://docs.datadoghq.com/getting_started/site/

记住解析后的 DD_SITE。 大多数 Agent 运行时会为每条命令启动一个全新的 shell，因此上面的 export 到下一个代码块时就已失效。这就是为什么每个需要凭据的后续代码块开头都会原样重复加载器命令——这是有意为之，并非内容偏移；不要删掉它。DD_SITE 不是机密信息，因此每个后续代码块都会通过显式的 DD_SITE='<site>'; export DD_SITE 重新设置它——将 <site> 替换为 Phase 0 中确认的站点。 这里故意使用普通赋值，而不是 : "${DD_SITE:=...}"：只有在值未设置或为空时，:= 才会填入值，因此 .env 中已有的错误非空 DD_SITE 会保留下来，导致每次调用都发往错误区域。密钥则使用 :? 进行保护，因此缺少密钥时会明确报错，而不是发送空标头。绝不要直接写入密钥值——密钥必须始终通过加载器以 $DD_API_KEY / $DD_APP_KEY 的形式传入。由此会带来两个结果，而且这两点都是有意设计的：

• Datadog 调用通过标准输入传递标头，例如 printf 'DD-API-KEY: %s\n' "$DD_API_KEY" | curl -H @- ...。 printf 是 shell 内置命令，因此密钥不会成为任何进程的参数，也不会出现在 ps 中。若改为编写 -H "DD-API-KEY: $DD_API_KEY"，密钥就会进入 curl 的 argv。（-H @- 需要 curl 7.55+；它只读取标头行，因此 -d 和 --data-urlencode 仍可正常工作。）
• Terraform 根本不会接收密钥作为值：Datadog provider 会从环境中读取 DD_API_KEY / DD_APP_KEY，因此没有根变量、没有 -var= 参数，也没有任何内容会被 Terraform 记录到 state 或已保存的计划中。

结合加载器，这样就能确保两个密钥都不会出现在对话记录、shell 历史记录或进程列表中。

工具。 terraform 是必需的；aws CLI 是可选的（用于查找现有报告），jq 也是可选的（仅用于 Phase 4 中的完成回调）：

command -v terraform || echo "MISSING terraform - https://developer.hashicorp.com/terraform/install"
command -v aws >/dev/null 2>&1 && echo "aws: available" || echo "aws: not installed"
command -v jq >/dev/null 2>&1 && echo "jq: available" || echo "jq: not installed"

此处的代码片段使用 POSIX shell。 在 PowerShell 或 cmd 下，请使用 Windows 对应命令（Get-Command、$env:VAR、2>$null、curl.exe）——调用和顺序相同。

两种报告类型

AWS 提供两种 Cost and Usage Report 格式，Datadog 均支持。用户的选择会影响生成报告的 AWS 资源，也会影响注册报告的 Datadog 资源，因此应尽早确认这一点（Phase 2，问题 1），并在整个流程中保持一致。

	CUR 2.0（推荐）	Legacy CUR
AWS 服务	BCM Data Exports	Cost and Usage Reports
Terraform 导出资源	aws_bcmdataexports_export	aws_cur_report_definition
Datadog 注册资源	datadog_integration_aws_account_ccm_config	datadog_aws_cur_config
标识依据	Datadog 账户配置 ID（UUID）	AWS 账户 ID（12 位数字）
Datadog API	/api/v2/integration/aws/accounts/{id}/ccm_config	/api/v2/cost/aws_cur_config

CUR 2.0 是 AWS 当前使用的导出格式，可在 AWS 控制台的 Data Exports 下创建。它采用固定架构，因此数据摄取更加可靠。Legacy CUR 是较旧的格式；AWS 仍支持它，而且对于已有 Legacy CUR 的用户来说，它仍是合适的选择。

其余所有部分——S3 存储桶、存储桶策略、IAM 读取策略和角色关联——两种格式共用。

阶段 1：选择 AWS 账户

设置 CCM 之前，先获取已与 Datadog 集成的 AWS 账户列表：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -X GET "https://api.${DD_SITE}/api/v2/integration/aws/accounts"

响应包含一个账户数组。每个账户包含：

• id - Datadog 账户配置 ID（UUID）。将其记录为 <AWS_ACCOUNT_CONFIG_ID>；它是资源集合 PATCH 的路径参数，也是 CUR 2.0 注册资源的键。
• aws_account_id - 12 位 AWS 账户编号
• auth_config.role_name - Datadog 使用的 IAM 角色名称（策略附加时需要）。该字段在 API 响应中直接位于 auth_config 上；中间没有 aws_auth_config_role 对象。不要将它与 Terraform provider 混淆：在 Terraform provider 中，datadog_integration_aws_account 确实会将该值嵌套为 auth_config { aws_auth_config_role { role_name = ... } }。HCL 中有嵌套，JSON 中没有。
• account_tags - 与账户关联的标签

id 和 aws_account_id 是不同的值，不能互换：CUR 2.0 使用前者作为键，Legacy CUR 使用后者作为键。

使用访问密钥验证的账户

auth_config 有两种形式之一。基于角色的账户具有 role_name；使用访问密钥对集成的账户具有 access_key_id，且没有角色。

如果所选账户的 auth_config 没有 role_name，请停止并告知用户——不要继续进入阶段 2。CCM 的 IAM 策略必须附加到 IAM 角色上，而这里没有可供附加的角色：

账户 <AWS_ACCOUNT_ID> 使用访问密钥对而非 IAM 角色进行集成，因此没有可供我附加 Cost and Usage Report 读取策略的角色。CCM 设置需要基于角色的集成。你可以在 AWS 集成设置中将此账户迁移到 IAM 角色，然后回来，我会从这里继续。

绝不要在 aws_iam_role_policy_attachment 中使用空、null 或猜测的 role。缺少 role_name 意味着此流程无法继续，而不是可以假定为 DatadogIntegrationRole——该角色也可能已重命名，因此必须从 API 响应中获取该值。

查找列表中不存在的账户

此端点最多返回 100 个账户，且不支持分页——meta 和 links 会返回 null，因此没有可继续使用的游标。拥有超过 100 个 AWS 账户的组织将无法看到全部账户。

如果响应包含 100 条记录，则视为列表已截断。请说明这一点，并询问用户要接入的 12 位 AWS 账户 ID，而不是让他们滚动查找：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -X GET "https://api.${DD_SITE}/api/v2/integration/aws/accounts?aws_account_id=<AWS_ACCOUNT_ID>"

aws_account_id 查询参数会在服务器端进行筛选，是查找前 100 个账户之外账户的唯一可靠方式。空的 data 数组表示该账户不存在集成——请先完成 dd-aws-integration 技能，然后再返回这里。

如果找到了账户

向用户展示列表，并询问他们想为哪个 AWS 账户设置 CCM。显示每个账户的 ID 和所有标签，帮助他们确认正确的账户。**始终询问用户要选择哪个账户——绝不要自动选择，即使只返回了一个账户也不例外；也绝不要假定用户想要的是本地 aws CLI 或当前 shell 所验证的账户。**进行任何更改之前（资源集合 PATCH 和 Terraform apply），都要确认所选账户。例如：

我找到了这些已连接到 Datadog 的 AWS 账户：

1. 123456789012（标签：env:production、team:platform）
2. 987654321098（标签：env:staging）

你想为哪个账户设置 Cloud Cost Management？或者我也可以添加新账户。

记录所选账户响应中的 id、aws_account_id 和 auth_config.role_name——Terraform 配置需要这三项。

如果用户想改为添加一个新 AWS 账户，请先完成 dd-aws-integration 技能，然后返回这里继续设置 CCM。

如果未找到任何账户

告知用户需要先设置基本的 AWS 集成。询问他们是否希望现在进行设置——如果希望，请先完成 dd-aws-integration 技能，然后返回此处继续配置 CCM。

验证资源收集

CCM 要求在 AWS 集成上启用资源收集（extended_collection）。 检查上述响应中所选账户的 resources_config.extended_collection 字段。

如果 extended_collection 为 false 或缺失，则必须将其开启。首先检查该集成是否由 Terraform 管理：在本地 *.tf 文件中查找 aws_account_id = "<AWS_ACCOUNT_ID>" 的 datadog_integration_aws_account 资源。如果存在，不要执行 PATCH：下一次 terraform apply 会还原此更改，并再次关闭资源收集。应改为在第 3 阶段该资源的 resources_config 块中设置 extended_collection = true，使其包含在用户批准的计划中。

否则，通过修改账户来启用此功能。这会修改用户的 AWS 集成，因此在运行 PATCH 前，先明确征求确认并等待用户答复“是”：

账户 <AWS_ACCOUNT_ID> 的资源收集处于关闭状态，而 CCM 需要启用此功能。我将为此账户的 Datadog AWS 集成启用它（extended_collection: true）。可以继续吗？

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -w '\nHTTP_STATUS:%{http_code}\n' -X PATCH "https://api.${DD_SITE}/api/v2/integration/aws/accounts/<ACCOUNT_CONFIG_ID>" \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "type": "account",
      "attributes": {
        "resources_config": {
          "extended_collection": true
        }
      }
    }
  }'

使用账户的 id 字段（而非 aws_account_id）作为 <ACCOUNT_CONFIG_ID> 路径参数。只有状态为 HTTP_STATUS:200 且响应正文显示 extended_collection: true，才表示操作成功。若状态不同，请向用户显示错误并停止。告知用户资源收集已启用——这是 CCM 提供成本建议和资源级成本归因所必需的。

检查是否已存在 CUR 配置

生成任何 Terraform 之前，请先检查所选账号是否已配置 CCM，以免创建重复的存储桶、CUR 或 IAM 资源。

Legacy CUR 配置和 CUR 2.0 配置位于不同位置，因此必须同时检查两者——已接入 CUR 2.0 的账号不会出现在 Legacy CUR 的读取结果中，反之亦然。

Legacy CUR 配置：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -w '\nHTTP_STATUS:%{http_code}\n' -X GET "https://api.${DD_SITE}/api/v2/cost/aws_cur_config"

筛选响应，找出 account_id 与所选 aws_account_id 相符的条目。如果 HTTP_STATUS 不是 200，请向用户显示错误并停止；读取失败不等于“没有配置”。

CUR 2.0 配置，仅针对所选账号：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -w '\nHTTP_STATUS:%{http_code}\n' -X GET "https://api.${DD_SITE}/api/v2/integration/aws/accounts/<AWS_ACCOUNT_CONFIG_ID>/ccm_config"

此处返回 404 表示该账号不存在 CUR 2.0 配置——这是正常且预期的结果，不应作为错误报告。403 既不代表“已配置”，也不代表“未配置”：应用程序密钥可能缺少权限，或者组织尚未启用 CUR 2.0（参见阶段 4）。请向用户显示该结果，并提供两个选项：修复密钥权限后重新执行此读取，或者继续使用 Legacy CUR。只有在上面的 Legacy CUR 读取返回 200 且没有该账号的条目，并且用户确认 Datadog Cloud Cost Management 设置中没有为该账号注册 CUR 2.0 导出配置后，才提供 Legacy CUR 选项，因为此次读取无法排除 CUR 2.0 已配置的可能性。如果用户选择继续，将 <REPORT_TYPE> 设为 legacy，并跳过阶段 2 中有关报告格式的问题。除 200、403 或 404 以外的任何状态码都表示真实故障：请向用户显示该状态并停止，不要将其视为“未配置”。200 会返回 data.attributes.data_export_configs，这是一个配置数组，每项包含 report_name、report_prefix、report_type、bucket_name 和 bucket_region。

如果任一读取发现该账号存在配置，请告知用户并询问如何继续——绝不能静默继续，也不能自动标记流程已完成。请说明实际找到的格式（“CUR 2.0”或“Legacy CUR”），让用户知道哪次读取匹配：

我发现账号 <AWS_ACCOUNT_ID> 已有 CUR 2.0 配置（存储桶 <BUCKET_NAME>， 报告 <REPORT_NAME>）。您想如何继续？

1. 确认——此账号已配置 CCM。验证并完成。
2. 为其他 AWS 账号配置 CCM。
3. 添加新的 AWS 账号。

处理用户的选择：

• (1)——跳至阶段 4 进行验证并报告完成。
• (2)——返回账号列表并再次询问。
• (3)——先完成 dd-aws-integration 技能，然后返回此处。

Datadog 为每个成员账号支持一份成本和使用情况报告，因此任何类型的现有配置都表示该账号已接入。不要提供在现有报告旁边添加第二份报告的选项。

如果两次读取都未找到匹配项，请继续执行阶段 2。

阶段 2：收集 CUR 配置

向用户提出以下问题。采用合理的默认值，并保持对话式交流——不要展示冗长的表单。

1. 报告内容

询问用户想使用哪种报告格式。这是整个流程的分支点。

• 默认：CUR 2.0。这是 Datadog 推荐的格式，也是 AWS 引导新用户使用的格式。
• 如果用户已有 Legacy CUR、明确要求使用它，或者其组织尚不支持 CUR 2.0（见阶段 4），则选择 Legacy CUR。

说明控制在一两行，例如：

你想使用哪种报告格式？

1. CUR 2.0（推荐）——AWS 当前的导出格式，通过 Data Exports 创建。架构固定，数据导入更可靠。
2. Legacy CUR——较旧的 Cost and Usage Report 格式。仍受完整支持；如果你已有此格式的报告，这是合适的选择。

将答案记录为 <REPORT_TYPE>（cur2 或 legacy）。后续所有步骤都取决于它。

如果用户选择 CUR 2.0，还要询问是否启用以下两项可选数据增强功能——两者默认都为关闭，且 Datadog 均不要求启用：

你可以为 CUR 2.0 导出启用两项可选附加功能：

• Split cost allocation data——启用 ECS 成本分配。你还必须在 Cost Explorer 偏好设置中选择加入 AWS Split Cost Allocation。
• IAM Principal Allocation Data——用于实现粒度更细的用户级 IAM Principal Bedrock 成本分配。

两者都会为导出增加行和列，从而增大文件。是否启用其中任一项？

将答案记录为 <INCLUDE_SPLIT_COST_ALLOCATION> 和 <INCLUDE_IAM_PRINCIPAL_DATA>（两者默认均为 false）。它们只会影响阶段 3 的第 2b 节中的导出资源。

2. 成本和使用情况报告

询问他们想要创建新报告还是使用现有报告。

• 默认：创建新报告（大多数用户还没有报告）。
• 如果他们已有报告，获取其定义（存储桶、前缀、区域、导出名称），以便本阶段后续步骤可以使用确定的值。查询方式取决于 <REPORT_TYPE>，因为两种格式对应不同的 AWS API。

如果 aws CLI 可用，首先确认它已通过第 1 阶段所选账户的身份验证。 以下所有查询，以及之后的 Terraform 应用操作，都会针对这些凭据所属的账户执行：

want='<AWS_ACCOUNT_ID>'   # from Phase 1
have=$(aws sts get-caller-identity --query Account --output text) || { echo "no usable AWS credentials"; exit 1; }
[ "$have" = "$want" ] || { echo "ambient AWS credentials are for account $have, but you are setting up CCM for $want - stop and fix this"; exit 1; }
echo "AWS credentials match account $want"

如果失败，请停止操作，并让用户切换到所选账户对应的凭据后再继续。

CUR 2.0——如果 aws CLI 可用（command -v aws >/dev/null 2>&1 执行成功），列出导出项：

aws bcm-data-exports list-exports --region us-east-1 \
  --query "Exports[].{Name:ExportName,Arn:ExportArn}" --output table

然后获取用户所选导出项的目标位置：

aws bcm-data-exports get-export --region us-east-1 --export-arn "<EXPORT_ARN>" \
  --query "Export.DestinationConfigurations.S3Destination.{S3Bucket:S3Bucket,S3Prefix:S3Prefix,S3Region:S3Region}" \
  --output json

BCM Data Exports 只能通过 us-east-1 访问——无论存储桶位于何处，都始终传入 --region us-east-1。如果 list-exports 返回空数组，说明该账户没有 CUR 2.0 导出项；请提供创建导出项的选项，或改用 Legacy CUR。

Legacy CUR——如果 aws CLI 可用，列出报告名称，供用户选择：

aws cur describe-report-definitions --region us-east-1 --query "ReportDefinitions[].ReportName" --output table

与 BCM Data Exports 一样，Legacy CUR API 也只能通过 us-east-1 访问，因此始终传入 --region us-east-1。如果命令失败，应向用户显示错误（通常是缺少 cur:DescribeReportDefinitions 权限），而不是将其视为“没有报告”；只有结果为空，才表示该账户没有 Legacy CUR。

接着，在他们确认报告名称后，获取完整定义：

aws cur describe-report-definitions --region us-east-1 \
  --query "ReportDefinitions[?ReportName=='<REPORT_NAME>'].{ReportName:ReportName,S3Bucket:S3Bucket,S3Prefix:S3Prefix,S3Region:S3Region}" \
  --output json

如果 describe 调用返回空数组，说明该账户中不存在此报告名称——返回上一步，让用户从列表中重新选择。

无论哪种情况，都将返回的值记录为 <EXPORT_NAME>、<BUCKET_NAME>、<EXPORT_PATH_PREFIX> 和 <BUCKET_REGION>。

如果 aws CLI 不可用，请用户在 AWS 控制台中查找报告——CUR 2.0 请前往 Billing and Cost Management → Data Exports（https://console.aws.amazon.com/billing/home#/exports），Legacy CUR 请前往 https://console.aws.amazon.com/billing/home#/reports——并直接提供以下四项：

• 导出名称（<EXPORT_NAME>）
• S3 存储桶名称（<BUCKET_NAME>）
• S3 路径前缀（<EXPORT_PATH_PREFIX>）
• S3 存储桶区域（<BUCKET_REGION>）

如果报告已存在，且这些字段是通过 CLI 获取的，则重用获取到的值；仅在 CLI 不可用而需要改用其他方式时，才向用户索取这些字段。

3. S3 存储桶

如果用户在上一步选择了创建新报告，询问他们是想创建新的 S3 存储桶，还是使用现有存储桶。

• 默认：创建新的存储桶。

如果用户选择了使用现有报告，则跳过此问题。现有报告的目标配置中已经包含其 S3 存储桶，因此无法将其与新存储桶配对。存储桶名称、区域和前缀已通过第 2 步中的查询填充。

现有存储桶 + 新报告：检查存储桶策略。 AWS 只会将报告发送到允许账单服务写入的存储桶，而普通的现有存储桶通常没有此类策略语句。先询问现有存储桶的名称和区域，并将它们记录为 <BUCKET_NAME> 和 <BUCKET_REGION>（问题 4 会再次使用）。使用 aws CLI 读取当前策略：

aws s3api get-bucket-policy --bucket "<BUCKET_NAME>" --region "<BUCKET_REGION>" --query Policy --output text

NoSuchBucketPolicy 错误表示存储桶尚无策略。任何其他错误（访问被拒绝、存储桶不存在）都不代表“没有策略”：向用户显示错误，并在问题解决前停止操作。如果没有 CLI，请让用户从 S3 控制台的存储桶权限选项卡复制策略（或确认其没有策略）。

如果策略已允许 billingreports.amazonaws.com 和 bcm-data-exports.amazonaws.com 针对账号 <AWS_ACCOUNT_ID> 对此存储桶执行 s3:PutObject、s3:GetBucketPolicy 和 s3:GetBucketAcl 操作，则无需更改。否则，阶段 3 会使用第 1b 节中的现有存储桶变体添加交付语句，并保留策略中已有的所有语句。保持当前策略 JSON 与返回内容完全一致（或注明没有策略）；阶段 3 会将其保存到文件，供 Terraform 读取。在阶段 3 开始前告知用户将更新其存储桶策略：

存储桶 <BUCKET_NAME> 尚未允许 AWS 账单服务向其交付报告。我会添加一条语句，仅授予 billingreports.amazonaws.com 和 bcm-data-exports.amazonaws.com 对您账号的写入权限，并保留存储桶中现有的所有策略语句。可以继续吗？

4. 配置字段

对于新报告，向用户收集以下值（尽可能使用默认值）。如果用户选择了现有存储桶，则已在问题 3 中收集存储桶名称和区域。

字段	说明	默认值
存储桶名称	用于 CUR 数据的 S3 存储桶	dd-cost-and-usage-reports-<AWS_ACCOUNT_ID>
存储桶区域	存储桶所在的 AWS 区域	us-east-1
导出路径前缀	报告的 S3 键前缀	dd-reports
导出名称	报告名称	cost-and-usage-report

对于现有报告，这些值来自第 2 步中的查询，因此应直接复用，不要再次询问。在继续操作前，先向用户简要汇总并确认这些值，以便他们在 Terraform 运行前发现错误。

验证（仅限新报告）：

• 导出名称只能包含字母数字字符以及 ! - _ . * ' ( )。
• 导出路径前缀不能为空，不能以 / 开头或以 / 结尾。中间可以包含 /（例如 cost/hourly）。Datadog 不接受其他形式。
• 存储桶名称必须符合 S3 命名规则。存储桶名称必须全局唯一，因此默认值中包含账号 ID；如果该名称已被占用，请在运行 Terraform 前要求用户换一个名称。

阶段 3：生成并应用 Terraform

检查现有 Terraform

生成新配置前，检查用户是否已有 Terraform 项目：

find . -maxdepth 1 -type f \( -name '*.tf' -o -name '*.tf.json' -o -name 'terraform.tfstate' \) -print

如果找到现有 .tf 文件：

• 阅读这些文件，了解已配置的提供程序和资源。

• 如果 datadog 提供程序和 aws 提供程序都已存在，请勿重复创建。

• 只添加 CCM 所需的新资源。

• 如果现有存储桶需要使用第 1b 节，请在输出策略前检查项目是否已管理该存储桶的策略：

  grep -rnE --include='*.tf' --include='*.tf.json' 'resource "aws_s3_bucket_policy"|resource "aws_s3_bucket"|<BUCKET_NAME>' .
  

  阅读搜索找到的每个 aws_s3_bucket_policy，以及任何为 <BUCKET_NAME> 设置了内联 policy 的 aws_s3_bucket。如果其中一个目标是 <BUCKET_NAME>，请按 references/terraform.md（第 1b 节）的说明，将交付语句添加到该策略中，而不是创建第二个策略资源。只有当项目中没有任何资源管理该策略时，才使用基于快照的第 1b 节资源。

• 如果用户采用模块化布局，请创建一个新文件，例如 datadog-ccm.tf，用于存放 CCM 资源。

如果未找到现有 Terraform 项目，请生成独立配置。你需要设置 Datadog 和 AWS 提供程序——如果用户刚完成 dd-aws-integration，这些提供程序已经存在于其 Terraform 项目中。请复用它们。

生成 Terraform HCL

根据用户的需求，从以下各节构建 Terraform 配置。将所有占位符替换为第 2 阶段收集的实际值。

每一节的 HCL 及其对应规则都在 references/terraform.md 中。现在阅读该文件，并阅读每节的说明和 HCL——其中包含 Datadog 验证导出时所依据的设置、精确的 116 列 query_statement、BILLING_VIEW_ARN 要求、可选的 CUR 2.0 列，以及角色名称规则。各节如下：

节	内容	包含条件
1a	S3 存储桶	创建新存储桶
1b	用于报告交付的存储桶策略	创建新存储桶，或在策略缺少交付语句的现有存储桶中创建新报告
2a	旧版 CUR 定义（aws_cur_report_definition）	<REPORT_TYPE> 为 legacy 且正在创建新报告
2b	CUR 2.0 导出（aws_bcmdataexports_export）	<REPORT_TYPE> 为 cur2 且正在创建新报告
3	IAM 策略（DatadogCURAccess）	始终
4	将策略附加到 Datadog 集成角色	始终
5a	Datadog 旧版 CUR 配置（datadog_aws_cur_config）	<REPORT_TYPE> 为 legacy
5b	Datadog CUR 2.0 配置（datadog_integration_aws_account_ccm_config）	<REPORT_TYPE> 为 cur2

场景矩阵

根据用户的选择组合各节。第 2 节和第 5 节根据 <REPORT_TYPE> 选择对应变体；无论哪种情况，第 1、3 和 4 节都相同。

场景	CUR 2.0 各节	旧版 CUR 各节
新存储桶 + 新报告	1a + 1b（新存储桶）+ 2b + 3 + 4 + 5b	1a + 1b（新存储桶）+ 2a（新存储桶）+ 3 + 4 + 5a（新报告）
现有存储桶 + 新报告	1b（现有存储桶，仅在需要时）+ 2b + 3 + 4 + 5b	1b（现有存储桶，仅在需要时）+ 2a（现有存储桶）+ 3 + 4 + 5a（新报告）
现有存储桶 + 现有报告	3 + 4 + 5b	3 + 4 + 5a（现有报告）

每当输出第 1b 节时，第 2 节中的报告都必须依赖于 aws_s3_bucket_policy.cur_bucket（每节的说明中介绍了具体方法），因为 AWS 会在创建报告时验证存储桶策略。如果交付语句被添加到项目中已有的策略资源，则报告应依赖于该资源。

应用 Terraform

1. 将所有 <PLACEHOLDER> 值替换为实际收集到的值。

2. 确保用户已为 Phase 1 中选定的账户 配置 AWS 凭证。如果 aws CLI 可用，请立即重新运行 Phase 2 的问题 2 中的账户检查。无论如何，AWS provider 都必须包含 allowed_account_ids = ["<AWS_ACCOUNT_ID>"]（如下所示），这样 Terraform 就会拒绝针对任何其他账户执行计划或应用。

3. 如果尚未配置 provider（独立设置），请确保存在 Datadog provider，并将其指向用户的站点：

   terraform {
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = ">= 5.47.0"
       }
       datadog = {
         source  = "DataDog/datadog"
         version = ">= 4.11.0"
       }
     }
   }
   
   provider "aws" {
     region              = "us-east-1"
     allowed_account_ids = ["<AWS_ACCOUNT_ID>"]
   }
   
   provider "datadog" {
     api_url = "https://api.<DD_SITE>/"
   }
   

   将 <DD_SITE> 替换为 Phase 0 中确认的站点。该 provider 会读取 DD_API_KEY / DD_APP_KEY 中的密钥，但不会读取 DD_SITE：如果没有 api_url，它会连接 US1，并在其他所有站点上失败。复用现有 datadog provider 时，请检查其 api_url 是否与 https://api.<DD_SITE>/ 匹配（或确认 DD_HOST 已设置为该值）；复用现有 aws provider 时，请为其添加 allowed_account_ids = ["<AWS_ACCOUNT_ID>"]，或确认它已指向选定的账户。

   导出资源必须创建在 us-east-1（请参阅这些步骤后的说明），因此独立 provider 使用该区域，且 Section 2 导出资源始终使用该区域。存储桶资源则有所不同：S3 会将存储桶和存储桶策略调用发送到存储桶所在的区域。每当 <BUCKET_REGION> 不是 us-east-1 时，无论是新建存储桶还是使用现有存储桶，都请为存储桶区域添加第二个 aws provider，并设置相同的 allowed_account_ids：

   provider "aws" {
     alias               = "bucket_region"
     region              = "<BUCKET_REGION>"
     allowed_account_ids = ["<AWS_ACCOUNT_ID>"]
   }
   

   然后在 Section 1b 资源上设置 provider = aws.bucket_region；如果生成了 Section 1a，也在该资源上设置此项。否则，存储桶策略会通过 us-east-1 provider 写入，且可能在 Terraform 执行到报告前就失败。复用区域与 <BUCKET_REGION> 不同的现有 aws provider 时，也适用此规则。如果现有 provider 使用 profile、shared_credentials_files、assume_role 或类似设置进行身份验证，也请将这些设置复制到 bucket_region 别名中：别名不会继承这些设置；如果不复制，它会回退到环境中的凭证。如果交付语句被加入项目已有的策略资源，请让该资源继续使用它原有的 provider。

   CUR 2.0 需要满足这两个最低版本要求，且二者都很重要——它所需的资源在较早的 provider 版本中并不存在：

   Provider	最低版本	在该版本中引入的资源
   hashicorp/aws	>= 5.47.0	aws_bcmdataexports_export
   DataDog/datadog	>= 4.11.0	datadog_integration_aws_account_ccm_config

   如果用户现有的 Terraform 项目将任一 provider 固定在低于上述版本的版本，请提高版本约束并运行 terraform init -upgrade。如果项目将 aws 固定在低于 5.47.0 的版本，terraform init 或 plan 会因 aws_bcmdataexports_export 不受支持而失败，这很容易被误认为是生成配置中的拼写错误。Legacy CUR 没有这两个最低版本要求——aws_cur_report_definition 和 datadog_aws_cur_config 都已存在很长时间——因此，如果用户无法提高版本约束，切换到 Legacy CUR 是可行的替代方案。

4. 导出 Datadog 凭证，以便 provider 能读取它们，并确认这些凭证已设置。不要通过 -var 传递它们：此配置没有声明这些变量，因此 -var="datadog_api_key=..." 会在生成任何计划之前因 Value for undeclared variable 而失败。由于新 shell 可能不会保留这些导出设置，下面的计划和应用代码块中也会重复加载凭证。

   for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
   DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
   # Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
   : "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
   export DD_API_KEY DD_APP_KEY
   

5. 运行 terraform init 以安装 provider。

6. 将计划保存到文件，并展示给用户审核：

   for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
   DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
   # Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
   : "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
   terraform plan -out=tfplan \
     || { echo "terraform plan FAILED - fix the error and re-plan; do NOT apply"; exit 1; }
   

   在此处停止，并等待用户批准计划后再应用。如果计划会将现有的 datadog_integration_aws_account 的 extended_collection 改为 false，则说明项目正在撤销 Phase 1 的更改：在该资源中将其设为 true，然后先重新规划。

7. 用户确认后，应用该已保存的计划。应用文件才能确保批准有意义——直接运行 terraform apply 会重新规划，因此用户可能批准了一个计划，却应用了另一个计划：

   for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
   DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
   # Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
   : "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
   trap 'rm -f tfplan' EXIT HUP INT TERM
   terraform apply tfplan \
     || { echo "terraform apply FAILED - do NOT verify or report success"; exit 1; }
   

   切勿传入 -auto-approve，也切勿在未先展示已保存计划的情况下应用。

重要： 两个导出 API 都只能在 us-east-1 中使用——Legacy CUR 对应 aws_cur_report_definition，CUR 2.0 对应 aws_bcmdataexports_export。S3 存储桶本身可以位于任何区域；只有导出资源受此限制。如果用户的默认 AWS 提供程序区域不同，可能需要使用提供程序别名或显式设置区域。

Phase 4：验证设置

terraform apply 成功完成后，验证配置是否已向 Datadog 注册。读取与 <REPORT_TYPE> 匹配的端点。

CUR 2.0：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -w '\nHTTP_STATUS:%{http_code}\n' -X GET "https://api.${DD_SITE}/api/v2/integration/aws/accounts/<AWS_ACCOUNT_CONFIG_ID>/ccm_config"

检查 HTTP_STATUS 是否为 200，并确认 data.attributes.data_export_configs 中包含一个条目，其 report_name、report_prefix、bucket_name 和 bucket_region 与刚创建的配置一致，且 report_type 为 CUR2.0。

Legacy CUR：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -w '\nHTTP_STATUS:%{http_code}\n' -X GET "https://api.${DD_SITE}/api/v2/cost/aws_cur_config"

检查 HTTP_STATUS 是否为 200，并确认响应中包含与刚创建的账户 ID 和存储桶相匹配的配置。

资源收集，两种格式均适用。 重新运行 Phase 1 中“查找列表中不存在的账户”里的账户查询，并检查 resources_config.extended_collection 是否仍为 true。如果为 false，则某个由 Terraform 管理的 datadog_integration_aws_account 已将其关闭：在该资源中设置 extended_collection = true，然后重新规划，再报告完成。

如果 CUR 2.0 注册失败

CUR 2.0 支持仍在逐步推出。如果应用 datadog_integration_aws_account_ccm_config 或验证读取失败，并返回 403 或 404（而不是指出特定导出设置的验证错误），则该组织可能尚未启用 CUR 2.0。不要重试相同的应用操作。向用户明确说明，并提供备用方案：

Datadog 在注册 CUR 2.0 配置时返回了 ，这通常意味着该组织尚未启用 CUR 2.0。有两个选项：

1. 改用 Legacy CUR 设置——完全受支持，我现在可以为你配置。
2. 暂且不继续，并联系 Datadog 支持以启用 CUR 2.0。

如果用户选择（1），返回 Phase 2，并将 <REPORT_TYPE> 设为 legacy。本次运行中的存储桶、存储桶策略、IAM 策略和角色关联都可以重复使用——只需替换第 2 和第 5 节，因此不要拆除并重建已成功应用的内容。

如果验证错误确实指出了具体设置（缺少列、粒度错误、刷新频率、覆盖模式或文件格式），则属于另一类问题：导出配置不符合 references/terraform.md 第 2b 节的要求。根据该表修正导出配置，然后重新应用。

收尾

仅当第 4 阶段通过时，才发送以下完成回调：CUR 读取返回 200，且配置与刚创建的导出相匹配，并且 extended_collection 为 true。如果验证失败，或你正在执行上述 403/404 回退流程，请勿报告成功，也不要发送回调。

验证完成后，尽最大努力发送一次完成回调，以便 Datadog UI 完成此流程。

DD_WORKFLOW_ID 是凭据所属 Datadog 用户的 UUID，UI 会据此关联此回调。请在一条命令中解析该值并发送请求：许多 Agent 运行时会为每条命令启动一个新的 shell，因此在之前命令中赋值的变量在此处会为空。

切勿打印 current_user 响应：其中还包含用户的姓名、用户名和电子邮件地址。如果没有可用的 JSON 解析器，请跳过此回调，不要安装解析器，也不要因此阻塞设置流程。

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
dd_headers() { printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY"; }
DD_WORKFLOW_ID="$(dd_headers | curl -H @- -fsS --connect-timeout 5 --max-time 20 \
  "https://api.${DD_SITE}/api/v2/current_user" | jq -er '.data.id')" \
  && dd_headers | curl -H @- -sS --connect-timeout 5 --max-time 20 -X POST \
  "https://api.${DD_SITE}/api/unstable/integration/aws/workflow/agentic_ccm" \
  -H "Content-Type: application/vnd.api+json" \
  -d '{"data":{"type":"integration_setup_status","id":"'"${DD_WORKFLOW_ID}"'","attributes":{"status":"finished","step":"setup_complete"}}}'

如果此回调失败，请勿重试，也不要阻塞设置流程。

向用户总结已完成的设置：AWS 账户、报告格式（CUR 2.0 或 Legacy CUR）、导出名称、存储桶、前缀和区域，以及本次运行期间是否启用了资源收集。

向用户表示祝贺，并告知他们：

• AWS 首次交付报告后，CUR 数据通常需要 24-48 小时才会显示。
• AWS 每天交付一次报告；首份报告可能在创建后的几小时内送达。
• 数据开始流入后，即可在 Cloud Cost Management 页面查看。

提供以下链接（使用第 0 阶段中的 App URL，将其构建为 <APP_BASE>/...）：

• Cloud Cost Management：<APP_BASE>/cost - 查看成本明细、分配情况和建议。
• Cost Summary：<APP_BASE>/cost/overview - 查看所有提供商的高层级成本概览。
• Cost Analytics：<APP_BASE>/cost/analytics - 按服务、团队或标签深入分析成本趋势。

建议的后续步骤：

• 在 <APP_BASE>/monitors/create 设置成本监控器，以便在成本异常或达到预算阈值时收到提醒。
• 配置标签管道，将 AWS 成本分配标签映射为 Datadog 标签，以便按团队归属成本。
• 启用 Cloud Cost Recommendations，获取资源规格优化建议。

重要说明

• 用户必须具有创建 S3 存储桶、存储桶策略、IAM 策略、IAM 角色策略附加项和 Cost and Usage Reports 的 IAM 权限（Legacy CUR 需要 cur:PutReportDefinition，CUR 2.0 需要 bcm-data-exports:CreateExport）。
• 两种格式的报告都只能在 us-east-1 中创建。
• Datadog 每个成员账户仅支持一份 Cost and Usage Report。对于已注册报告的账户，请勿再注册第二份报告。
• IAM 策略授予只读访问权限——Datadog 从不写入或修改 CUR 存储桶。
• 两种注册资源都需要 Datadog Terraform 提供商（DataDog/datadog）。CUR 2.0 还需要 datadog >= 4.11.0 和 hashicorp/aws >= 5.47.0；Legacy CUR 没有最低版本要求。
• Datadog 仅支持由 AWS 生成的 Cost and Usage Reports。请勿修改或移动 AWS 生成的文件，也不要让 Datadog 指向第三方生成的文件。
• 未先向用户展示计划，切勿运行 terraform apply。

使 CUR 2.0 列清单保持最新

第 2b 节中的 116 列 SELECT 与 Datadog 的 CCM 后端用于验证 CUR 2.0 导出的默认列清单一致。请按原样复制；不要根据 AWS 列参考文档或凭记忆重新构建。如果 Datadog 验证开始报告缺少某列，就需要更新此技能中的清单以保持一致。AWS 只会向 CUR 2.0 添加列，因此导出包含额外列没有问题——缺少列才会导致失败。