利用 Amazon Athena managed query results 让 AWS DevOps Agent 查询 Amazon S3 中的日志
内容提要
AWS DevOps Agent 查询 S3 日志时，因 guardrail 的 session policy 缺少 S3 写权限，Athena 将查询结果写入 S3 总是失败，即使为 role 添加 s3:PutObject 也无效。解决办法是新建启用 managed query results 的 Athena workgroup，由 Athena 托管查询结果；role 只需补充 Athena 查询权限和日志桶读权限，并事先建好表，同时在 agent instructions 中指定该 workgroup 且不传结果位置。该方案的限制是查询结果仅保留 24 小时，且不支持结果复用。
延伸解读
权限交集：为何补 s3:PutObject 无效
文章指出，DevOps Agent 的有效权限是 role 的 identity policy 与 guardrail 传入的 session policy 的交集。session policy 由 AWS 托管，不显示在 IAM 控制台，也不被策略模拟器考虑，因此 role 上添加 s3:PutObject 不会生效。排查时需到 CloudTrail 的 AssumeRole 事件中查看 session policy 内容，且要查 Agent Space 所在 Region。这解释了为何换桶、换前缀均无法解决写结
managed query results 的适用与配置要点
方案核心是新建启用 managed query results 的 Athena workgroup，让 Athena 托管查询结果，避免写 S3。配置时需注意：不要修改 primary workgroup，以免影响其他客户端；role 只需补 Athena 查询动作和日志桶读权限，不要加 s3:PutObject；表需事先建好，因为 session policy 无 glue:CreateTable；并在 agent instructions 中明确指定该 workgroup 且不传 ResultConfigur
方案限制与替代场景
托管查询结果仅保留 24 小时，过期需重跑并按扫描量计费；workgroup 不支持 result reuse，重复查询也会重新扫描。托管结果加密只能用 AWS owned key，客户托管密钥会因缺少 kms:GenerateDataKey 被拒。若日志在 CloudWatch Logs，则无需此方案，默认策略已含 Logs Insights 所需权限。此外，AWS 托管策略和 session policy 内容未来可能变化。
Q&A
为什么给 DevOps Agent 的 role 加上 s3:PutObject 权限后，Athena 查询结果还是写不进 S3？
因为 DevOps Agent 在 assume role 时会附带一份 session policy（guardrail），最终生效的权限是 role 上的 identity policy 和这份 session policy 的交集。session policy 里没有任何 S3 写权限，所以即使 role 上加了 s3:PutObject，交集里也没有它，写操作依然被拒绝。
如何配置 Athena workgroup 让 DevOps Agent 能查询 S3 日志而无需写权限？
新建一个启用 managed query results 的 Athena workgroup（例如命名为 devops-agent），不要修改 primary。创建命令示例：aws athena create-work-group --region <表所在 Region> --name devops-agent --configuration '{"ManagedQueryResultsConfiguration":{"Enabled":true},"PublishCloudWatchMetricsEnabled":true}'。这样查询结果由 Athena 托管，整个查询过程不需要往 S3 写任何东西。
DevOps Agent 查询 S3 日志时，role 上需要补充哪些权限？
需要给 Agent Space 的 role 添加一份自定义策略，包含：1) 针对该 workgroup 的 Athena 动作：athena:StartQueryExecution、StopQueryExecution、GetQueryExecution、BatchGetQueryExecution、GetQueryResults、GetQueryResultsStream；2) 日志桶的读权限：s3:GetObject、s3:ListBucket、s3:GetBucketLocation。不要加 s3:PutObject（加了也不生效）。如果日志桶用 KMS 客户托管密钥加密，还需增加该 key 的 kms:Decrypt 权限。
为什么必须事先在 Athena 中建好表，DevOps Agent 不能自己建表吗？
因为 DevOps Agent 的 session policy 里没有 glue:CreateTable 权限，所以它无法创建表。需要用 AWS CloudFormation、Glue crawler 等工具，或者用自己的凭证跑一次 CREATE EXTERNAL TABLE，先把表建好。
如何让 DevOps Agent 知道使用哪个 Athena workgroup 并且不传结果位置？
需要在 Agent Space 的 agent instructions（AGENTS.md）中明确指示：使用指定的 workgroup（如 devops-agent），并且永远不要传 ResultConfiguration 或 OutputLocation。可以通过 Operator Web App 编辑 Global instructions，或用 API 创建 agents_md 资产（agent_type 设为 GENERIC）。这样 chat 和 investigation 都能生效。
使用 managed query results 方案有哪些限制？
主要限制包括：1) 托管的查询结果只保留 24 小时，过期后需重新跑查询并按扫描量重新计费；2) 不支持 result reuse，24 小时内重复同一条查询也会重新扫描；3) 托管结果只能用默认的 AWS owned key 加密，不能用客户托管密钥（否则 StartQueryExecution 会被拒绝）；4) AIDevOpsAgentAccessPolicy 和 session policy 由 AWS 管理，内容可能变化。
如果日志存储在 CloudWatch Logs 而不是 S3，还需要这个规避方案吗？
不需要。logs:StartQuery、logs:GetQueryResults、logs:StopQuery 本来就在 AIDevOpsAgentAccessPolicy 里，CloudWatch Logs Insights 查询也不需要往 S3 写东西。只用默认策略，带上任意一种 session policy，实测 Logs Insights 查询都能跑完。
