REST API资源策略中IpAddress条件的正确配置方式

这是API Gateway非常经典的配置坑，核心逻辑和你观察到的现象完全对应：

• 你创建的REST API默认是**边缘优化（Edge-Optimized）**类型，这类API的公网请求会先经过CloudFront全球边缘节点，再由CloudFront通过AWS内部私网链路转发给API Gateway服务。
• API Gateway的资源策略是在传输层做权限校验，这时候它读取到的aws:SourceIp是CloudFront节点的内部转发地址，根本不是客户端的真实出口IP；你在Lambda日志里拿到的RequestContext.Identity.SourceIp，是API Gateway从X-Forwarded-For请求头里解析出来的客户端真实IP，两个值来源完全不同，所以你写的IP匹配条件永远不会命中。
• 你把IP段改成0.0.0.0/0还是报403的原因也很简单：CloudFront到API Gateway的内部流量走的是AWS私网地址段，0.0.0.0/0覆盖的是所有公网IP，根本匹配不到这些内部私网IP，所有请求自然会被策略拦截。
• 移除Condition配置后，策略不再校验源IP，不管是内部转发IP还是其他来源的请求都会命中Allow规则，所以接口可以正常访问。

根据你的需求二选一即可：

方案1：改用区域端点（配置最简单，无需额外付费） #

1. 进入API Gateway控制台，打开对应API的设置页
2. 把端点类型从「边缘优化」改成「区域（Regional）」，保存变更
3. 资源策略不需要改逻辑，保留你原来的IP限制写法即可，参考配置如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:eu-west-1:你的账号ID:你的API ID/*/*/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "你的公网出口IP/32"
                }
            }
        }
    ]
}

4. 选择你要发布的阶段重新部署API，等1-2分钟配置同步完成后，IP白名单规则就会正常生效。

方案2：保留边缘优化端点，通过WAF做IP限制 #

如果你需要边缘优化节点带来的全球低延迟访问能力，就不要在API Gateway资源策略里做IP校验：

1. 给绑定该API的CloudFront分发实例关联AWS WAF
2. 在WAF中创建IP集，配置规则仅放通你需要的公网IP段
3. API Gateway侧的资源策略移除IP相关Condition，保持全Allow即可，IP拦截逻辑直接由WAF在边缘节点完成。

所有涉及API Gateway资源策略、端点类型的变更，必须重新部署对应API阶段才会生效，只在控制台保存配置但不部署的话，线上运行的API会一直使用旧版本配置。

内容的提问来源于stack exchange，提问作者Jesús López