如何使用CloudFront实现反向代理式URL路径转发

CloudFront是实现你这个透明反向代理需求的最优方案之一，不需要额外维护反向代理服务器，自带全球边缘节点缓存能力，转发过程对终端用户完全透明，不会暴露后端api.example.com的真实地址，静态资源访问速度还能比直接回源快30%以上，运维成本极低。
如果你的业务后续还要加WAF防护、访问控制、缓存规则调整，都可以直接在CloudFront控制台配置，不需要改动源站。

• 前置检查：先确认api.example.com已经部署了合法的公网信任SSL证书，安全组/防火墙规则允许CloudFront回源IP段访问/static/brands/*、/static/products/*路径，不会出现403拦截。
• 新建CloudFront分配：进入CloudFront控制台创建新分配，在「源」配置栏填写源域名为api.example.com，回源协议选择「HTTPS only」（如果你的源站支持HTTP也可以选匹配查看器，优先推荐HTTPS回源保证传输安全），其余源配置保持默认即可。
• 配置路径匹配行为（核心步骤）：CloudFront按照行为列表从上到下的优先级匹配请求，一定要把精确路径的行为放在默认行为前面：
  1. 第一个行为：点击「创建行为」，路径模式填/brands/*，关联刚才创建的api.example.com源，缓存策略选择托管的CachingOptimized（适配静态资源缓存场景）。找到「函数关联」配置项，函数类型选CloudFront Functions，触发时机选「查看器请求」，绑定一个路径重写函数，函数代码如下：

function handler(event) {
  const request = event.request;
  // 把用户访问的/brands/前缀改写为回源需要的/static/brands/前缀
  request.uri = request.uri.replace(/^\/brands\//, '/static/brands/');
  return request;
}

2. 第二个行为：再次点击「创建行为」，路径模式填/products/*，源、缓存策略配置和上一个行为完全一致，同样绑定查看器请求阶段触发的CloudFront Functions，代码如下：

function handler(event) {
  const request = event.request;
  request.uri = request.uri.replace(/^\/products\//, '/static/products/');
  return request;
}

3. 默认行为配置：路径模式为*的默认行为，你可以根据自身业务需求配置，比如关联www主站的源站，或者直接配置返回404，注意必须拖到两个路径行为的下方，避免优先匹配拦截目标请求。

• 配置访问域名：在分配的「设置」栏，添加备用域名www.example.com，绑定你在ACM（美国东部us-east-1区域申请，否则CloudFront无法调用）为该域名申请的公有SSL证书，查看器协议策略选择「将HTTP重定向到HTTPS」。
• 切换DNS解析：等待CloudFront分配部署完成（通常需要5-10分钟，控制台显示状态为已部署即可），拿到分配对应的默认访问域名，到你的DNS服务商处将www.example.com的记录修改为CNAME类型，指向CloudFront分配的默认域名即可。

配置生效后，用户访问www.example.com/brands/xxx、www.example.com/products/xxx时，地址栏不会出现任何api.example.com相关的路径，CloudFront会在边缘节点自动完成路径改写和回源，静态资源会自动缓存到边缘节点，后续请求不需要每次都回源拉取。
不推荐用Lambda@Edge做这个简单路径改写，CloudFront Functions的请求处理成本只有Lambda@Edge的1/6，冷启动延迟几乎为0，完全适配这类简单路径重写场景。

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