Terraform AWS Provider 数据源aws_elb_service_account精准获取 ELB Classic 服务账户 ID 以配置 S3 访问日志桶策略【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-awsaws_elb_service_account是 Terraform AWS Provider 提供的一个经典数据源Data Source用于按区域返回 AWS Elastic Load BalancingELB Classic写入访问日志所用的 AWS 服务账户 ID 与 ARN。本文以 elb_service_account 数据源文档 为主线结合 provider 内部源码与验收测试完整讲解该数据源的参数、导出属性、实战用法含完整可运行的访问日志配置并深入其底层实现原理帮助你在为 ELB Classic 访问日志桶编写 S3 桶策略时做到零硬编码、跨区域可移植。背景为什么需要“ELB 服务账户”这个数据源ELB Classic传统型负载均衡器开启访问日志Access Logs后会将日志写入你指定的 S3 桶。为了让 ELB 具备写入权限你必须在目标 S3 桶的策略中显式授权给AWS ELB 服务账户——即 AWS 为 ELB 服务在每个区域单独分配的 AWS 账户 ID。这些账户 ID 由 AWS 官方维护、按区域分布数量多且容易记错。若在 Terraform 配置里手写账户 ID会造成跨区域复用困难、易出错。aws_elb_service_account数据源的价值正是根据所选区域自动返回对应的服务账户 ID 和 ARN直接注入 IAM 策略无需硬编码任何数字。从源码看该数据源属于 ELB Classic 服务包internal/service/elb/service_package_gen.go注册的 TypeName 为aws_elb_service_account实现文件位于 internal/service/elb/service_account_data_source.go。基本用法一分钟获取当前区域的服务账户最简单的调用方式是不传任何参数此时数据源使用provider 配置中设置的区域data aws_elb_service_account main {}随后即可通过data.aws_elb_service_account.main.arn或.id引用结果。显式指定区域当你的 ELB 与 provider 默认区域不一致或需要为多个区域的桶生成策略时可通过region参数显式指定data aws_elb_service_account regional { region ap-southeast-1 }也可以在配置中动态获取当前区域data aws_region current {} data aws_elb_service_account regional { region data.aws_region.current.region }这种“显式 region 动态引用”的写法正是官方验收测试 service_account_data_source_test.go 中使用的模式确保数据源在任意区域下都可验证。参数参考Argument Reference参数类型必填说明regionstring可选需要查询 AWS ELB 服务账户 ID 的区域名称。默认取 provider 配置 中设置的区域从实现细节看region属性并非手写在 Schema 中而是通过Region(validateOverrideInPartitionfalse)注解由 provider 的框架层自动注入见 service_account_data_source.go 与框架层的 region 注入拦截器。validateOverrideInPartitionfalse意味着允许将区域覆盖到非当前分区的区域例如在aws分区查询 GovCloud 区域账户这也是它能灵活支持跨分区查询的原因。属性参考Attribute Reference数据源在参数之外导出以下属性属性类型说明idstring所选区域对应的 AWS ELB 服务账户 ID纯数字账户 IDarnstring所选区域对应的 AWS ELB 服务账户 ARNid与arn的底层生成逻辑阅读 service_account_data_source.go 的读取函数可知先用c.Region(ctx)取出生效区域即你传入的region缺省为 provider 区域在区域映射表serviceAccountPerRegionMap中查表命中后调用d.SetId(v)将账户 ID 写入idarn则通过c.GlobalARNWithAccount(ctx, iam, v, root)生成即形如arn:aws:iam::账户ID:root的全局 IAM ARNGlobalARNWithAccount定义在 internal/conns/awsclient.goARIN 的 partition 部分取自 provider 当前分区分区配置。这就是为什么在桶策略中可以用.arn作为 Principal 的 identifiers而.id可用于需要纯账户 ID 的场景。完整实战为 ELB Classic 访问日志配置 S3 桶与桶策略下面是从数据源文档完整继承、可直接复制运行的端到端示例创建日志桶、生成授权 ELB 写入的桶策略、创建开启访问日志的 ELB。data aws_elb_service_account main {} resource aws_s3_bucket elb_logs { bucket my-elb-tf-test-bucket } resource aws_s3_bucket_acl elb_logs_acl { bucket aws_s3_bucket.elb_logs.id acl private } data aws_iam_policy_document allow_elb_logging { statement { effect Allow principals { type AWS identifiers [data.aws_elb_service_account.main.arn] } actions [s3:PutObject] resources [${aws_s3_bucket.elb_logs.arn}/AWSLogs/*] } } resource aws_s3_bucket_policy allow_elb_logging { bucket aws_s3_bucket.elb_logs.id policy data.aws_iam_policy_document.allow_elb_logging.json } resource aws_elb bar { name my-foobar-terraform-elb availability_zones [us-west-2a] access_logs { bucket aws_s3_bucket.elb_logs.id interval 5 } listener { instance_port 8000 instance_protocol http lb_port 80 lb_protocol http } }要点拆解Principal 用.arn而非.id策略的principals.identifiers使用data.aws_elb_service_account.main.arn即arn:aws:iam::账户ID:rootIAM 策略接受该 ARN 格式的 Principal资源限定在AWSLogs/*ELB 访问日志默认写入s3://bucket/AWSLogs/前缀策略resources需限定到该前缀避免桶级全量授权动作s3:PutObjectELB 只需要写入日志对象的权限依赖关系aws_elb.bar通过access_logs.bucket引用日志桶实际落地时通常需保证桶策略先于 ELB 创建可参考官方测试中depends_on [aws_s3_bucket_policy.test]的写法见 load_balancer_test.go。使用原生 JSON 策略的等价写法如果你更习惯直接编写 JSON 策略官方 ELB 访问日志验收测试即采用此方式见 load_balancer_test.go等效配置如下data aws_elb_service_account current {} resource aws_s3_bucket accesslogs_bucket { bucket my-elb-access-logs-bucket force_destroy true } resource aws_s3_bucket_policy test { bucket aws_s3_bucket.accesslogs_bucket.id policy EOF { Id: PolicyForELBAccessLogs, Statement: [ { Action: s3:PutObject, Effect: Allow, Principal: { AWS: ${data.aws_elb_service_account.current.arn} }, Resource: ${aws_s3_bucket.accesslogs_bucket.arn}/*, Sid: StmtForELBAccessLogs } ], Version: 2012-10-17 } EOF }两种方式效果一致aws_iam_policy_document更符合 Terraform 风格且便于复用变量。源码级实现区域 → 服务账户 ID 映射表该数据源的“灵魂”是源码中的serviceAccountPerRegionMapinternal/service/elb/service_account_data_source.go。它是一张按 AWS 区域常量映射到服务账户 ID的静态表完整内容如下区域服务账户 IDaf-south-1098369216593ap-east-1754344448648ap-northeast-1582318560864ap-northeast-2600734575887ap-northeast-3383597477331ap-south-1718504428378ap-southeast-1114774131450ap-southeast-2783225319266ap-southeast-3589379963580ca-central-1985666609251cn-north-1638102146993cn-northwest-1037604701340eu-central-1054676820928eu-north-1897822967062eu-south-1635631232127eu-west-1156460612806eu-west-2652711504416eu-west-3009996457667me-south-1076674570225sa-east-1507241528517us-east-1127311923021us-east-2033677994240us-gov-east-1190560391635us-gov-west-1048591011584us-west-1027434742980us-west-2797873946194从表中可以观察出几个重要事实中国区域cn-north-1、cn-northwest-1与 GovCloudus-gov-east-1、us-gov-west-1也分别拥有独立账户与商用分区互不相同me-central-1中东巴林在表中被注释为空// endpoints.MeCentral1RegionID: 意味着该区域目前不提供可用的 ELB 服务账户 ID该映射覆盖了截至当前仓库版本的 27 个区域条目26 个有效值 1 个被注释的空值。查询与错误处理逻辑dataSourceServiceAccountRead的完整流程service_account_data_source.go从 provider 客户端取出生效区域region : c.Region(ctx)在serviceAccountPerRegionMap中按 key 查找命中设置id v、arn arn:aws:iam::v:root返回成功未命中返回unsupported ELB Service Account Region (region)错误。因此如果你传入表中不存在的区域例如新开放的 me-central-1Terraform 会在读取阶段直接报错提示而不是静默产生错误账户。这也是该数据源“宁可报错、不可误导”的设计态度。测试验证数据源行为由验收测试背书仓库为aws_elb_service_account提供了两个 acceptance testinternal/service/elb/service_account_data_source_test.go可视为数据源行为的官方契约TestAccELBServiceAccountDataSource_basic第 15-34 行无参数调用data aws_elb_service_account main {}断言id等于当前测试区域在ServiceAccountPerRegionMap中对应的账户 ID同时用CheckResourceAttrGlobalARNAccountID验证arn的账户 ID 部分与id一致资源路径为iam/rootTestAccELBServiceAccountDataSource_region第 36-55 行显式传入region data.aws_region.current.region验证“显式 region 覆盖”路径与默认路径返回一致的结果。测试中直接引用tfelb.ServiceAccountPerRegionMap[acctest.Region()]作为期望值说明测试与实现共享同一张映射表——若某天新增区域测试可自动跟随更新。注意事项与最佳实践2021 年 12 月Jakarta 区域之后开通的 AWS 区域不再提供独立的 ELB 服务账户 ID。官方文档原数据源文档 elb_service_account.html.markdown 中的 Note明确建议对于ap-southeast-3Jakarta之后开通的区域应在相关 IAM 策略中改用service principal name代替 AWS 账户 ID 作为 Principal。这解释了为何该数据源并未覆盖全部区域——表中缺失的区域正是需要改用 service principal 的区域查询不存在的区域会直接报错unsupported ELB Service Account Region。请先确认目标区域在映射表范围内region是唯一参数且可选默认跟随 provider 区域跨区域场景务必显式传入避免“看似成功实则用了错误账户”的隐患优先使用.arn作为 PrincipalIAM 策略的 Principal 接受arn:aws:iam::账户ID:root形式直接引用.arn最稳妥.id适合需要纯数字账户 ID 的场景如组合 ARN 或审计。小结aws_elb_service_account是一个“小而美”的数据源参数仅一个可选的region导出id与arn两个属性背后却是一张覆盖 26 个有效区域的官方账户映射表并辅以完整的验收测试背书。在配置 ELB Classic 访问日志桶策略时用它替代硬编码账户 ID能让配置自动适配不同区域与分区既准确又易维护。若需继续深入可以阅读数据源实现internal/service/elb/service_account_data_source.go服务包注册internal/service/elb/service_package_gen.go验收测试internal/service/elb/service_account_data_source_test.goELB 访问日志完整测试配置internal/service/elb/load_balancer_test.go官方数据源文档website/docs/d/elb_service_account.html.markdown【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Terraform AWS Provider 数据源 `aws_elb_service_account`：精准获取 ELB Classic 服务账户 ID 以配置 S3 访问日志桶策略
Terraform AWS Provider 数据源aws_elb_service_account精准获取 ELB Classic 服务账户 ID 以配置 S3 访问日志桶策略【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-awsaws_elb_service_account是 Terraform AWS Provider 提供的一个经典数据源Data Source用于按区域返回 AWS Elastic Load BalancingELB Classic写入访问日志所用的 AWS 服务账户 ID 与 ARN。本文以 elb_service_account 数据源文档 为主线结合 provider 内部源码与验收测试完整讲解该数据源的参数、导出属性、实战用法含完整可运行的访问日志配置并深入其底层实现原理帮助你在为 ELB Classic 访问日志桶编写 S3 桶策略时做到零硬编码、跨区域可移植。背景为什么需要“ELB 服务账户”这个数据源ELB Classic传统型负载均衡器开启访问日志Access Logs后会将日志写入你指定的 S3 桶。为了让 ELB 具备写入权限你必须在目标 S3 桶的策略中显式授权给AWS ELB 服务账户——即 AWS 为 ELB 服务在每个区域单独分配的 AWS 账户 ID。这些账户 ID 由 AWS 官方维护、按区域分布数量多且容易记错。若在 Terraform 配置里手写账户 ID会造成跨区域复用困难、易出错。aws_elb_service_account数据源的价值正是根据所选区域自动返回对应的服务账户 ID 和 ARN直接注入 IAM 策略无需硬编码任何数字。从源码看该数据源属于 ELB Classic 服务包internal/service/elb/service_package_gen.go注册的 TypeName 为aws_elb_service_account实现文件位于 internal/service/elb/service_account_data_source.go。基本用法一分钟获取当前区域的服务账户最简单的调用方式是不传任何参数此时数据源使用provider 配置中设置的区域data aws_elb_service_account main {}随后即可通过data.aws_elb_service_account.main.arn或.id引用结果。显式指定区域当你的 ELB 与 provider 默认区域不一致或需要为多个区域的桶生成策略时可通过region参数显式指定data aws_elb_service_account regional { region ap-southeast-1 }也可以在配置中动态获取当前区域data aws_region current {} data aws_elb_service_account regional { region data.aws_region.current.region }这种“显式 region 动态引用”的写法正是官方验收测试 service_account_data_source_test.go 中使用的模式确保数据源在任意区域下都可验证。参数参考Argument Reference参数类型必填说明regionstring可选需要查询 AWS ELB 服务账户 ID 的区域名称。默认取 provider 配置 中设置的区域从实现细节看region属性并非手写在 Schema 中而是通过Region(validateOverrideInPartitionfalse)注解由 provider 的框架层自动注入见 service_account_data_source.go 与框架层的 region 注入拦截器。validateOverrideInPartitionfalse意味着允许将区域覆盖到非当前分区的区域例如在aws分区查询 GovCloud 区域账户这也是它能灵活支持跨分区查询的原因。属性参考Attribute Reference数据源在参数之外导出以下属性属性类型说明idstring所选区域对应的 AWS ELB 服务账户 ID纯数字账户 IDarnstring所选区域对应的 AWS ELB 服务账户 ARNid与arn的底层生成逻辑阅读 service_account_data_source.go 的读取函数可知先用c.Region(ctx)取出生效区域即你传入的region缺省为 provider 区域在区域映射表serviceAccountPerRegionMap中查表命中后调用d.SetId(v)将账户 ID 写入idarn则通过c.GlobalARNWithAccount(ctx, iam, v, root)生成即形如arn:aws:iam::账户ID:root的全局 IAM ARNGlobalARNWithAccount定义在 internal/conns/awsclient.goARIN 的 partition 部分取自 provider 当前分区分区配置。这就是为什么在桶策略中可以用.arn作为 Principal 的 identifiers而.id可用于需要纯账户 ID 的场景。完整实战为 ELB Classic 访问日志配置 S3 桶与桶策略下面是从数据源文档完整继承、可直接复制运行的端到端示例创建日志桶、生成授权 ELB 写入的桶策略、创建开启访问日志的 ELB。data aws_elb_service_account main {} resource aws_s3_bucket elb_logs { bucket my-elb-tf-test-bucket } resource aws_s3_bucket_acl elb_logs_acl { bucket aws_s3_bucket.elb_logs.id acl private } data aws_iam_policy_document allow_elb_logging { statement { effect Allow principals { type AWS identifiers [data.aws_elb_service_account.main.arn] } actions [s3:PutObject] resources [${aws_s3_bucket.elb_logs.arn}/AWSLogs/*] } } resource aws_s3_bucket_policy allow_elb_logging { bucket aws_s3_bucket.elb_logs.id policy data.aws_iam_policy_document.allow_elb_logging.json } resource aws_elb bar { name my-foobar-terraform-elb availability_zones [us-west-2a] access_logs { bucket aws_s3_bucket.elb_logs.id interval 5 } listener { instance_port 8000 instance_protocol http lb_port 80 lb_protocol http } }要点拆解Principal 用.arn而非.id策略的principals.identifiers使用data.aws_elb_service_account.main.arn即arn:aws:iam::账户ID:rootIAM 策略接受该 ARN 格式的 Principal资源限定在AWSLogs/*ELB 访问日志默认写入s3://bucket/AWSLogs/前缀策略resources需限定到该前缀避免桶级全量授权动作s3:PutObjectELB 只需要写入日志对象的权限依赖关系aws_elb.bar通过access_logs.bucket引用日志桶实际落地时通常需保证桶策略先于 ELB 创建可参考官方测试中depends_on [aws_s3_bucket_policy.test]的写法见 load_balancer_test.go。使用原生 JSON 策略的等价写法如果你更习惯直接编写 JSON 策略官方 ELB 访问日志验收测试即采用此方式见 load_balancer_test.go等效配置如下data aws_elb_service_account current {} resource aws_s3_bucket accesslogs_bucket { bucket my-elb-access-logs-bucket force_destroy true } resource aws_s3_bucket_policy test { bucket aws_s3_bucket.accesslogs_bucket.id policy EOF { Id: PolicyForELBAccessLogs, Statement: [ { Action: s3:PutObject, Effect: Allow, Principal: { AWS: ${data.aws_elb_service_account.current.arn} }, Resource: ${aws_s3_bucket.accesslogs_bucket.arn}/*, Sid: StmtForELBAccessLogs } ], Version: 2012-10-17 } EOF }两种方式效果一致aws_iam_policy_document更符合 Terraform 风格且便于复用变量。源码级实现区域 → 服务账户 ID 映射表该数据源的“灵魂”是源码中的serviceAccountPerRegionMapinternal/service/elb/service_account_data_source.go。它是一张按 AWS 区域常量映射到服务账户 ID的静态表完整内容如下区域服务账户 IDaf-south-1098369216593ap-east-1754344448648ap-northeast-1582318560864ap-northeast-2600734575887ap-northeast-3383597477331ap-south-1718504428378ap-southeast-1114774131450ap-southeast-2783225319266ap-southeast-3589379963580ca-central-1985666609251cn-north-1638102146993cn-northwest-1037604701340eu-central-1054676820928eu-north-1897822967062eu-south-1635631232127eu-west-1156460612806eu-west-2652711504416eu-west-3009996457667me-south-1076674570225sa-east-1507241528517us-east-1127311923021us-east-2033677994240us-gov-east-1190560391635us-gov-west-1048591011584us-west-1027434742980us-west-2797873946194从表中可以观察出几个重要事实中国区域cn-north-1、cn-northwest-1与 GovCloudus-gov-east-1、us-gov-west-1也分别拥有独立账户与商用分区互不相同me-central-1中东巴林在表中被注释为空// endpoints.MeCentral1RegionID: 意味着该区域目前不提供可用的 ELB 服务账户 ID该映射覆盖了截至当前仓库版本的 27 个区域条目26 个有效值 1 个被注释的空值。查询与错误处理逻辑dataSourceServiceAccountRead的完整流程service_account_data_source.go从 provider 客户端取出生效区域region : c.Region(ctx)在serviceAccountPerRegionMap中按 key 查找命中设置id v、arn arn:aws:iam::v:root返回成功未命中返回unsupported ELB Service Account Region (region)错误。因此如果你传入表中不存在的区域例如新开放的 me-central-1Terraform 会在读取阶段直接报错提示而不是静默产生错误账户。这也是该数据源“宁可报错、不可误导”的设计态度。测试验证数据源行为由验收测试背书仓库为aws_elb_service_account提供了两个 acceptance testinternal/service/elb/service_account_data_source_test.go可视为数据源行为的官方契约TestAccELBServiceAccountDataSource_basic第 15-34 行无参数调用data aws_elb_service_account main {}断言id等于当前测试区域在ServiceAccountPerRegionMap中对应的账户 ID同时用CheckResourceAttrGlobalARNAccountID验证arn的账户 ID 部分与id一致资源路径为iam/rootTestAccELBServiceAccountDataSource_region第 36-55 行显式传入region data.aws_region.current.region验证“显式 region 覆盖”路径与默认路径返回一致的结果。测试中直接引用tfelb.ServiceAccountPerRegionMap[acctest.Region()]作为期望值说明测试与实现共享同一张映射表——若某天新增区域测试可自动跟随更新。注意事项与最佳实践2021 年 12 月Jakarta 区域之后开通的 AWS 区域不再提供独立的 ELB 服务账户 ID。官方文档原数据源文档 elb_service_account.html.markdown 中的 Note明确建议对于ap-southeast-3Jakarta之后开通的区域应在相关 IAM 策略中改用service principal name代替 AWS 账户 ID 作为 Principal。这解释了为何该数据源并未覆盖全部区域——表中缺失的区域正是需要改用 service principal 的区域查询不存在的区域会直接报错unsupported ELB Service Account Region。请先确认目标区域在映射表范围内region是唯一参数且可选默认跟随 provider 区域跨区域场景务必显式传入避免“看似成功实则用了错误账户”的隐患优先使用.arn作为 PrincipalIAM 策略的 Principal 接受arn:aws:iam::账户ID:root形式直接引用.arn最稳妥.id适合需要纯数字账户 ID 的场景如组合 ARN 或审计。小结aws_elb_service_account是一个“小而美”的数据源参数仅一个可选的region导出id与arn两个属性背后却是一张覆盖 26 个有效区域的官方账户映射表并辅以完整的验收测试背书。在配置 ELB Classic 访问日志桶策略时用它替代硬编码账户 ID能让配置自动适配不同区域与分区既准确又易维护。若需继续深入可以阅读数据源实现internal/service/elb/service_account_data_source.go服务包注册internal/service/elb/service_package_gen.go验收测试internal/service/elb/service_account_data_source_test.goELB 访问日志完整测试配置internal/service/elb/load_balancer_test.go官方数据源文档website/docs/d/elb_service_account.html.markdown【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
