让 Amazon Bedrock AgentCore 网关可访问（仅通过 CloudFront）
Source: Dev.to
Tags: aws, architecture, genai, cloud, security
Amazon Bedrock AgentCore Gateway 使得公开基于 GenAI 的 API 变得非常简单。
AWS 提供了一个官方模式，用于通过 CloudFront 附加自定义域名：
Client → CloudFront → AgentCore Gateway官方文档：
对于许多使用场景，这种方式已经足够。
但如果需求更严格呢？
此端点只能通过特定的 CloudFront 分配访问。
这正是架构边界发挥作用的地方。
隐蔽的暴露问题
即使在：
- CloudFront 位于前端
- 附加了 AWS WAF
- 配置了自定义域名
的情况下，底层的 AgentCore Gateway 服务端点仍然 公开可访问。CloudFront 充当的是反向代理，而不是严格的隔离边界。
AgentCore 支持 基于资源的策略，主要控制 谁 可以调用网关（IAM 主体、AWS 账户以及受支持的条件键）。这种模型非常适合内部服务间的通信，但对于面向公众的 API：
- 外部消费者 不 使用 IAM 进行身份验证。
- 身份验证通常依赖 OAuth、JWT、API 密钥或自定义 Header。
- 为了合法用户的使用，端点必须保持可被互联网访问。
因此，即使合法流量通过 CloudFront，底层的 Gateway 端点仍可能直接从互联网访问，除非引入额外的控制措施。基于 IAM 的限制并不能消除这种暴露，因为服务端点本身仍然是公开的。对于需要严格入口隔离的环境，这就是一个关键缺口。
将其与 S3 + CloudFront（OAI / OAC）进行比较
Amazon S3 提供了一种原生的强制访问机制：只有 CloudFront 可以访问该存储桶。通过 源访问身份（OAI） 或 源访问控制（OAC），可以将 S3 存储桶设为私有，并仅限特定的 CloudFront 分配访问。
示例 S3 存储桶策略：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFrontAccessOnly",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E123ABC456XYZ"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-private-bucket/*"
}
]
}在此模型中：
- 存储桶 不是 公共的。
- 直接的互联网访问会失败。
- 仅允许 CloudFront 身份访问。
AgentCore 目前 不 提供等价的隔离构造，因此需要引入额外的边界。
Source: …
强制仅通过 CloudFront 访问的架构
示例：
- 公共入口点:
ext-clients-api-57x9abc.mycompany.com - 下游所需的 Host 头部:
gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com
在网络层强制仅使用 CloudFront
Application Load Balancer (ALB) 可以被公开访问，但它并不需要直接对开放的互联网可达。可以使用 AWS Managed Prefix Lists for CloudFront 来限制入站流量：
AWS 维护一个包含 CloudFront origin‑facing IP 范围的托管前缀列表。将此托管前缀列表附加到 ALB 的安全组，并仅允许来自以下来源的入站 HTTPS：
com.amazonaws.global.cloudfront.origin-facing实现效果
- 只有 CloudFront 边缘位置能够与 ALB 建立 TCP 连接。
- 直接的互联网流量在安全组层面被阻断。
- IP 欺骗无法绕过此限制。
如果没有 CloudFront，ALB 将不可达，从而在网络层形成真正的强制边界。
AWS WAF 与 DDoS 防护的定位
CloudFront（边缘层）
CloudFront 自动受到 AWS Shield Standard 保护，在边缘提供 DDoS 缓解。附加到 CloudFront 的 AWS WAF 可以提供：
- 基于速率的规则（防滥用和抓取保护）
- IP 信誉过滤
- 地理位置限制
- AWS 托管规则组
- AWS Bot Control
- 账户接管防护（ATP）
- 身份验证字段检查
- 请求头验证
- 负载大小限制
恶意流量在到达基础设施之前被过滤。
ALB（入口层）
AWS WAF 也可以附加到 ALB，以实施：
- 验证必需的自定义请求头（例如由 CloudFront 注入的秘密请求头）
- 更靠近服务的额外速率限制或 Bot 控制
- 防御绕过 CloudFront 规则的应用层攻击
这些层共同提供深度防御姿态，满足“仅 CloudFront” 的要求，同时仍向合法用户公开面向公众的 API。
由 CloudFront 注入的秘密请求头
- 严格的 Host 请求头验证
- 额外的托管规则组
- 身份验证流程检查
即使 ALB DNS 名称被发现：
- 直接连接尝试因托管前缀列表限制而失败。
- 伪造请求因请求头验证和 WAF 规则而失败。
强制执行层
- 边缘 – Shield + WAF
- 网络 – 托管前缀列表限制
- 应用 – ALB WAF + 监听器规则
技术挑战：TLS 与 Host Header
在 AgentCore 前放置 ALB 时：
-
ALB 必须使用 自定义域名 的证书终止 TLS，例如：
ext-clients-api-57x9abc.mycompany.com -
下游路由可能需要不同的 HTTP Host 头，例如：
gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com
它们属于不同的协议层：
| 层 | 目的 |
|---|---|
| TLS (SNI) | 控制证书验证 |
| HTTP | Host 头控制路由逻辑 |
AgentCore 不 支持接受任意自定义域名的入站请求，因此必须在流量到达 AgentCore 之前解决此不匹配。
解决方案：CloudFront 源修改
CloudFront Functions 可以修改：
domainName– 用于 TLS/SNI 的源连接主机名hostHeader– 发送到源的 HTTP Host 头
示例函数
import cf from 'cloudfront';
const ORIGIN_DOMAIN_NAME = 'ext-clients-api-57x9abc.mycompany.com';
const OVERRIDE_HOST_HEADER = 'gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com';
function handler(event) {
const request = event.request;
cf.updateRequestOrigin({
domainName: ORIGIN_DOMAIN_NAME,
hostHeader: OVERRIDE_HOST_HEADER
});
return request;
}这使得：
- 对 ALB 证书进行 TLS 验证。
- 根据所需的 Host 头对 ALB 进行路由。
- 外部客户端仅与自定义域交互。
- AgentCore 只能通过受控的 CloudFront → ALB → PrivateLink 路径访问。
最终结果
架构提供：
- 自定义域名支持
- 边缘级 DDoS 防护（Shield Standard）
- 高级 WAF 防护（速率限制、ATP、机器人控制、托管规则）
- 网络级仅 CloudFront 强制执行
- ALB 的入口验证
- 通过 VPC 端点（PrivateLink）的私有连接
- 对 GenAI 工作负载的强入口隔离
默认的 AWS 模式非常适合标准部署。
当需要严格的仅 CloudFront 可达性时，需要设置架构边界。
CloudFront + 托管前缀列表 + ALB + PrivateLink + 分层 WAF 提供了该边界。