如何跨AWS组织共享SES身份？权限配置异常求助

咱们来拆解一下这里可能遗漏的配置——既然你用了AWS Organizations，哪怕已经给Operations组附加了FullAWSAccess策略，也有几个很容易踩坑的关键点：

1. 检查组织单元（OU）的服务控制策略（SCP） #

AWS Organizations里的SCP是优先级更高的权限边界，哪怕用户组有FullAWSAccess，如果同事所在的OU或者根组织有SCP限制了S3或SES的访问，那FullAWSAccess会被直接覆盖。

• 操作步骤：进入AWS Organizations控制台 → 找到同事所在的OU → 查看附加的SCP。确保没有包含Deny语句限制s3:*或ses:*动作的策略，也确认根组织的SCP没有被修改（默认根SCP是FullAWSAccess，如果自定义过就可能出问题）。

2. 确认资源所在账号是否在组织内，且用户归属正确 #

你最初是用单个账号开通的SES——如果这个账号没有加入AWS Organizations作为成员账号，那组织内的用户哪怕有FullAWSAccess，默认也无法访问这个外部账号的S3和SES资源。
另外还要确认：同事的IAM用户是创建在哪个账号？如果你的S3和SES资源在管理账号，而同事的用户在成员账号，那即使有FullAWSAccess，也需要配置跨账号访问的信任策略才能访问管理账号的资源。

3. 检查IAM用户的权限边界（Permission Boundary） #

有时候创建用户时会不小心设置了权限边界，哪怕用户组有FullAWSAccess，权限边界也会限制实际能使用的权限范围。

• 操作步骤：进入IAM控制台 → 找到同事的用户 → 查看「权限」标签下的「权限边界」。如果有设置，确保该边界允许S3和SES的所有操作。

4. 检查SES Identities的资源策略（如果有自定义） #

虽然FullAWSAccess策略通常会覆盖资源级权限，但如果你之前给SES Identities（比如验证的域名/邮箱）设置了自定义资源策略，也有可能限制了访问。

• 操作步骤：进入SES控制台 → 找到对应的Identity → 查看「Identity policy」。确保里面没有阻止同事用户/Operations组访问的Deny语句。

5. 确认组织内S3和SES服务的启用状态 #

有些AWS服务需要在Organizations中手动启用，才能让组织内的用户访问对应账号的资源。

• 操作步骤：进入AWS Organizations控制台 → 点击「Services」 → 找到S3和SES，确认它们在你存放资源的账号上是启用状态。

建议先从检查SCP开始排查——这是AWS Organizations环境下权限不生效最常见的原因。如果有哪个点命中了你的情况，欢迎再交流！

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