配置全量权限后部署AWS ACM证书仍报changeResourceRecordSets未授权错误

• 首先要澄清一个非常普遍的日志认知误区：你在报错里看到的certificatemanager:changeResourceRecordSets根本不是ACM服务本身的API权限校验动作。
  这个操作的实际归属是Route53的DNS记录修改接口，之所以会带上ACM的服务前缀，是因为CloudFormation在创建AWS::CertificateManager::Certificate资源、执行DNS验证流程时，会用你部署用户的凭证代为调用Route53接口写入验证用的CNAME记录。这类同流程触发的关联操作，在CloudFormation事件日志里会统一打上主资源的服务前缀，非常容易让人误判权限校验的目标服务，绕去反复调整ACM的权限配置。
• 你当前的权限策略其实已经覆盖了操作需要的权限范围（策略里明确放开了acm:*、route53:*的全量操作，且Resource为*），真正触发报错的诱因藏在你的CloudFormation模板参数里：
  模板里默认填写的HostedZoneId值Z1BKCTXD74EZPE，是AWS官方管理的eu-west-1区域S3公共网站端点对应的托管区ID，完全不属于你自己AWS账号下的Route53私有托管区。很多人误以为策略里写Resource: "*"就可以操作所有AWS全局资源，实际上IAM的权限边界仅覆盖当前账号下的所有资源，跨账号归属的资源无论策略怎么配，都无法获得访问权限。CloudFormation拿到这个错误ID后，会尝试往这个AWS所有的公共托管区里写入ACM验证记录，最终触发未授权报错。

你之前提到的同类changeResourceRecordSets未授权报错，和当前场景的触发逻辑完全一致：
只要是CloudFormation托管资源流程下触发的Route53记录修改操作，报错的Action标识都会被打上主资源的服务前缀——比如这次是ACM证书创建流程就打ACM前缀，如果是CloudFront自定义域名关联流程触发的记录修改，就会打CloudFront前缀，本质都是权限校验时访问的目标Route53托管区不属于当前调用账号，和对应主资源（ACM/CloudFront）的权限配置没有直接关系。

• 把模板里默认的HostedZoneId值，替换成你自有域名在Route53控制台中创建的私有托管区ID（托管区ID可在Route53托管区列表页对应域名条目右侧直接查看）。
• 避免手工硬编码出错的话，可以在模板里加内置动态查询逻辑，根据输入的域名自动匹配对应账号下的托管区ID。
• 额外校验：确认填写的HostedZoneId属于当前部署的AWS账号，没有跨账号引用其他归属的托管区。

内容的提问来源于stack exchange，提问作者Justin