AWS SCP强制资源标签问题：未加标签仍可创建EC2资源

SCP附加到根层级本身不会导致策略失效——AWS组织的SCP是自上而下继承生效的，只要根层级的SCP处于启用状态，会自动作用到所有下级OU（包括你提到的DEV层级）和账号。你的策略没生效，大概率是其他原因，以下是常见排查方向：

1. SCP策略逻辑存在错误 #

这是最常见的原因，重点检查：

• 是否覆盖了正确的动作：EC2实例创建对应ec2:RunInstances，卷创建对应ec2:CreateVolume，别漏了其中一个。
• 条件键是否正确：创建资源时的标签校验要用aws:RequestTag/project（而非ec2:ResourceTag/project，后者用于已存在资源的标签校验），且条件要判断该标签是否为空。
• 示例正确的拒绝策略：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:CreateVolume"
      ],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/project": "true"
        }
      }
    }
  ]
}

2. 存在冲突的SCP或未启用目标策略 #

• 检查根层级或上级OU是否有其他SCP：如果有SCP明确允许ec2:RunInstances或ec2:CreateVolume动作，且你的拒绝条件未匹配（比如用户实际加了标签但你测试场景不对），会导致策略不触发；但只要你的拒绝条件匹配（确实没加project标签），SCP的拒绝语句优先级高于允许，应该生效。
• 确认你的SCP是否处于启用状态：添加SCP后默认是禁用的，需要手动开启才能生效。

3. 测试场景不符合条件 #

• 确认测试时确实未添加project标签：有些AWS控制台模板或自动化工具（比如CloudFormation）会自动添加默认标签，导致你的条件（标签为空）不触发。
• 检查是否测试了正确的资源：比如只测试了EC2实例，但没测试卷；或者反过来。

4. 组织层级覆盖范围问题 #

确认DEV层级的账号确实属于根组织的下级OU：如果DEV是独立的AWS账号未加入组织，根层级的SCP自然不会作用到它，但你提到“无法添加至最低层级DEV”，说明DEV是组织内的OU，这一点大概率没问题。

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