AWS Channel Partner How to Setup AWS CloudFront for Global Reach
Chapter 1: 先弄清 CloudFront 在全球做了什么
很多人第一次接触 CloudFront，会把它理解成“把网站放到 CDN 上就行”。但真正用起来，你会发现 CloudFront 的价值在于：它把你内容的交付路径从“用户直接连源站”改成“用户就近连边缘节点”，再由边缘节点从源站取回内容或在本地缓存复用。
简单说，你需要完成三件事：
- 选源站：你的网站内容原本从哪里来（S3、ALB/NLB、EC2、HTTP 端点等）。
- 设定分发策略：让边缘节点如何缓存、如何转发请求、怎么处理查询参数和头信息。
- 把安全和域名接上：证书、HTTPS、重定向、WAF（如需要）与日志监控。
当这三件事做对，你的全球访问体验会明显变好：首包更快、跨地域延迟更低、源站压力更小。
Chapter 2: 准备工作清单（在开始创建前）
为了避免反复改配置，建议你在动手前把下面信息准备好。即使你是新手，按这份清单走也会省很多时间。
2.1 明确内容类型与回源模式
你提供的内容主要是什么？静态文件（图片、JS、CSS、视频切片）还是动态页面（需要鉴权、频繁变化）？
这会直接影响你应该采用什么缓存策略、TTL（缓存时间）、以及是否开启“按需刷新”。
2.2 准备一个可用的源站
CloudFront 必须有一个“源站”。常见选择：
- Amazon S3：适合静态网站、媒体文件。
- Application Load Balancer (ALB)：适合 Web 应用、需要与应用逻辑交互。
- 自建 HTTP(S) 服务器：通过自定义源站接入。
确保源站在内网或公网能被 CloudFront 访问，尤其是当你使用了 OAI/OAC 或源站安全策略时。
AWS Channel Partner 2.3 确认域名与证书
你希望用什么域名提供服务？比如 cdn.example.com。
并且你需要一张面向该域名的证书。通常会在 ACM（AWS Certificate Manager）里申请或导入。CloudFront 使用 ACM 时，证书需要在对应的区域可用（常见做法是让证书在可用于 CloudFront 的区域准备好）。
2.4 规划缓存策略（别凭感觉设 TTL）
缓存策略看似复杂，但核心问题只有一个：内容多久需要更新一次。
如果你的静态资源有文件名指纹（例如 app.3f2a1c.js），那么可以把它们设为更长缓存，更新时用新文件名即可。动态页面则通常需要更短 TTL 或者直接绕开缓存。
Chapter 3: 创建 CloudFront 分配（Distribution）
现在开始实际搭建。以下以“最常见的静态站点场景”为例讲清楚思路；动态应用场景也会在后面对应补充。
3.1 登录 CloudFront 控制台并新建分配
进入 CloudFront 控制台，点击创建分配（Create distribution）。你会看到两大类：Web 和其他类型。通常网站是选择 Web。
3.2 选择源站类型
在“源站（Origin）”配置里选择你要的源站类型：
- 选择 S3：把桶（bucket）选出来。
- 选择 ALB：填入 ALB 的域名。
- 自定义源站：填入源站地址与协议。
这一步的关键是要确认源站协议（HTTP/HTTPS）和端口是否与你的实际部署一致。
3.3 设置默认缓存行为（Default cache behavior）
默认缓存行为决定了 CloudFront 如何处理“绝大多数请求”。你通常需要设置：
- Viewer protocol policy：用户用 HTTP 还是 HTTPS 访问？你想强制 HTTPS 吗？
- 允许的 HTTP 方法：静态资源一般只需要 GET/HEAD；如果是动态 API 可能要允许更多方法。
- 缓存策略：包含 TTL、是否按查询字符串缓存等。
建议你对网站默认开启 HTTPS，并将所有 HTTP 重定向到 HTTPS（在安全和体验上更可靠）。
3.4 关注“查询参数与头信息”
AWS Channel Partner CloudFront 的缓存命中很依赖缓存键（cache key）。缓存键包含哪些元素，就决定了相同请求是否会命中缓存。
常见误区是：你的网站带有查询参数（例如 ?v= 或 ?lang=），却没有让缓存策略正确识别它们。结果就是：
- 要么不同参数共享同一份缓存导致内容错乱；
- 要么参数都被纳入缓存键导致缓存碎片化，命中率下降。
解决思路是：对确实会影响内容的参数纳入缓存键；对只是用于追踪或无关显示的参数，可以选择不纳入。
Chapter 4: 为源站授权与访问控制（尤其是 S3）
当你使用 S3 作为源站，最重要的问题往往不是 CloudFront 怎么加速，而是“源站到底允许谁访问”。如果你把 S3 暴露成公开读，虽然能跑起来，但从安全角度不推荐。
4.1 S3 + CloudFront 的常见授权方式
常见做法是让 CloudFront 通过专用机制读取 S3 对象，而不是让整个桶公开。
你通常需要在 CloudFront 配置中选择对应的访问控制方式，并在 S3 里设置允许访问的主体。完成后，CloudFront 在回源时才能顺利拿到内容。
4.2 检查 S3 桶策略与对象权限
授权后仍然报 403/AccessDenied，最常见的原因有：
- 桶策略允许不对（主体、资源 ARN、条件不匹配）。
- 对象权限没有继承/不一致（例如某些对象是私有、某些是 public）。
- 默认索引文件配置不完整（你请求根路径，桶里却没有
index.html）。
建议你用几条确定的请求路径验证：根路径、一个已存在的静态文件、一个不存在文件（看返回是 403 还是 404）。
Chapter 5: HTTPS、域名与证书（让全球访问“看起来很专业”）
如果你不配置 HTTPS，哪怕 CDN 加速很快，用户体验也可能直接受影响。下面讲清楚从零到能用。
5.1 设置 Alternate Domain Names（CNAME）
在分配里添加你的自定义域名，比如：
cdn.example.com
注意：如果你的 DNS 还没有指向 CloudFront，先别急着判断证书是否生效；证书验证通常会在后续步骤完成。
5.2 选择 ACM 证书并绑定
在分配设置里选择对应域名的 ACM 证书。绑定正确后，CloudFront 将在边缘节点提供 HTTPS。
如果你遇到证书报错，通常是以下几类：
- 域名不在证书覆盖范围内。
- 证书状态不是“已签发”。
- 你选错了证书或区域/导入方式不符合要求。
5.3 配置重定向与默认根路径
很多网站希望访问 https://cdn.example.com 自动显示 index.html。
这需要你在 CloudFront 的“默认根对象（Default root object）”填入 index.html（或你实际的文件名）。
同时要确认“视图协议策略”设置为把 HTTP 重定向到 HTTPS。这样用户不会因为浏览器提示或中间跳转而失去信任。
Chapter 6: 让缓存真正发挥作用（缓存策略与无效化）
CloudFront 的核心不是“部署了就行”，而是“缓存命中率是否足够好、缓存是否更新得足够快”。这两点决定了延迟与成本。
6.1 为静态资源采用更长缓存时间
推荐做法是：
- 对 JS/CSS/图片等静态资源开启较长 TTL。
- 用构建工具生成带哈希的文件名。
- 当内容更新时，文件名变化，自然就用新对象。
这样你通常不需要频繁做无效化请求，因为缓存可以长时间保留。
6.2 对动态内容设更短 TTL，或根据规则绕开缓存
如果页面内容依赖登录状态、用户个性化信息，或者会频繁变化，那么：
- 不要把它当作可长缓存内容。
- 可能需要更短 TTL。
- 甚至可以直接不缓存（或只缓存很小一段时间）。
如果你做的是 API，通常还会加上“按路径区分缓存行为”。例如：
- AWS Channel Partner
/api/*使用更短 TTL。 /*静态资源使用更长 TTL。
6.3 使用路径匹配创建多个缓存行为
CloudFront 允许你为不同路径定义不同缓存行为（Behaviors）。例如：
- 默认行为：静态站点。
- 特定行为：
/api/*或/auth/*。
这样你可以把缓存策略与内容逻辑更精确地绑定，而不是一刀切。
6.4 何时使用无效化（Invalidation）
当你更新了“缓存中已存在的对象”，但文件名没有变化（例如你直接覆盖 app.js），就需要无效化让边缘节点拉取最新版本。
更推荐的工程策略是：静态资源不覆盖，只用新文件名发布；而“必经更新的固定文件”才用无效化，比如：
index.html- 某些需要即时生效的配置文件
无效化会消耗请求额度，并且需要时间传播，所以要把它用在刀刃上。
Chapter 7: 处理错误页面与回源失败（让体验更稳定）
全球加速的一个现实是：并不是所有请求都能成功回源。你需要预先设计错误响应的策略。
7.1 设置自定义错误响应
常见的需求是：
- 返回 404 时展示自定义页面。
- 返回 403 或回源失败时展示提示信息或跳转。
对于单页应用（SPA），你可能希望把 404/403 都转成 index.html，让前端路由接管。
7.2 区分“文件不存在”和“权限不足”
如果你把所有错误都统一成一个页面，排障会更困难。建议在开发/测试阶段保留更多可观察信息。
Chapter 8: 地理与访问控制（真正的全球“到达”）
“全球可达”并不只是开了分配就结束。你需要确认：
- 哪些地区用户能访问（按需做地理限制）。
- 是否存在合规要求（例如特定国家/地区禁用）。
- 是否需要限流或防护（WAF、速率限制）。
8.1 使用地理限制（Geo Restriction）
如果你的业务有地区策略，CloudFront 能够在边缘层做限制。你可以设置允许或拒绝某些地区访问。
注意：地理限制会影响用户体验和可能的 SEO/爬虫行为，建议在上线前验证日志与测试请求。
8.2 与 WAF 搭配提升安全性
当你面对大流量或恶意请求时，WAF 能在边缘层进行规则拦截。它比你在源站处理请求更高效，因为可以在更靠近用户的位置就阻断。
AWS Channel Partner Chapter 9: 日志、指标与可观测性（别只看是否能打开网页）
做全球加速，最怕的是“上线后才发现性能和错误比例不可控”。要把观测做好。
AWS Channel Partner 9.1 打开标准日志与访问日志（按需）
你需要知道发生了什么：哪些路径命中缓存、回源次数多不多、有哪些 4xx/5xx。
CloudFront 提供访问日志能力。你可以把日志导入到你现有的分析体系中，或用简单的方式观察主要趋势。
9.2 重点关注的指标
- 缓存命中率：命中越高，源站压力越低，延迟通常越好。
- 回源失败率：一旦升高，用户会受到影响。
- 4xx/5xx 分布：看错误是否集中在某些路径或地区。
- 响应时间：包含边缘到用户与回源的综合表现。
9.3 建立常用排障路径
当用户反馈“某地区加载慢”或“某些页面打不开”，你可以按顺序检查：
- 源站是否健康（ALB/EC2/S3 是否异常）。
- CloudFront 的错误统计是否上升。
- 是否存在缓存配置错误（路径行为不匹配、缓存键不正确）。
- 是否发生了权限问题（S3 回源 403）。
- 域名解析是否正确（DNS 记录是否指向正确的分配域名）。
Chapter 10: 常见部署场景的配置要点
不同源站与内容形态，配置重点也会不同。下面把最常见的几类场景总结成“你需要特别注意什么”。
10.1 S3 静态站点（带前端路由）
- Default root object 设置为
index.html。 - 将 403/404 映射到
index.html，让 SPA 路由工作。 - 静态资源用更长缓存；
index.html用较短缓存或用无效化策略更新。
10.2 ALB 承载的 Web 应用
- 缓存行为更要小心：动态页面不要让缓存键和 TTL 搞错。
- AWS Channel Partner 如果需要区分 API 与页面，建议用路径匹配拆分 behaviors。
- 回源超时、错误响应映射要与应用行为一致。
10.3 API（GET/HEAD 缓存，其他方法尽量不缓存）
- 允许的方法只放你需要的集合。
- GET/HEAD 可以考虑缓存，POST/PUT/PATCH 通常不缓存。
- 如果 API 响应与查询参数相关，把查询参数策略设准确，避免错误命中。
Chapter 11: 上线前的验证（建议不要跳过）
AWS Channel Partner 配置完成后，你可以做一轮“可操作的验证”。这比单纯刷新页面更可靠。
11.1 DNS 与证书验证
- 确保域名解析到 CloudFront 分配。
- 确认 HTTPS 正常，证书链没有报错。
AWS Channel Partner 11.2 缓存行为验证
- 访问一个静态文件多次，确认是否命中缓存（根据日志或响应头判断）。
- 修改源站内容但不更改文件名，确认缓存更新策略是否符合预期。
- 验证查询参数行为：同参数命中，不同参数是否正确区分。
11.3 压测或区域测试（至少做最小验证）
如果你能模拟不同地区的访问，优先做。否则也要至少用不同网络环境测试加载速度，观察是否存在明显的回源瓶颈。
Chapter 12: 结束后如何持续优化（让全球体验越做越好）
CloudFront 不是一次性配置完成就永远不管。你上线后可以逐步优化。
12.1 用数据驱动缓存策略
当你观察到某些路径缓存命中率很低，通常原因是：
- 缓存键过细，碎片化严重。
- TTL 设置过短。
- AWS Channel Partner 应用响应头或返回内容导致缓存不可用。
你可以从最常访问的路径开始调整，收益最大。
12.2 降低回源压力
回源频繁会提高延迟，也会增加源站资源消耗。通过更合理的缓存和按需无效化，让回源发生在“必须发生的时候”。
12.3 安全策略持续迭代
如果你加了 WAF 或限制策略，上线后仍要关注规则命中与误杀情况，确保真实用户不会因为规则而被挡在门外。
Chapter 13: 一份最简“落地步骤”总结
如果你想把前面的内容压缩成可执行步骤，可以按这个顺序做：
- 准备源站（S3/ALB/自定义 HTTP），确保 CloudFront 能回源。
- 创建 CloudFront 分配，选择源站并配置默认缓存行为（HTTPS、方法、缓存键、TTL）。
- 添加自定义域名（CNAME），绑定 ACM 证书。
- AWS Channel Partner 针对不同路径设置缓存行为（静态资源长缓存，动态/API 短缓存或不缓存）。
- 为 S3 配置访问授权，避免回源 403。
- 设置默认根对象与错误响应，尤其是 SPA 场景。
- 上线前验证 DNS、HTTPS、缓存命中与错误行为。
- 使用日志与指标持续观察，按数据调整缓存策略与安全策略。
Chapter 14: 你真正需要关心的“关键点”
最终你会发现，CloudFront 的配置是否成功，通常取决于几个关键点：
- 源站访问是否可靠：回源 403/超时会让你以为是 CDN 的问题。
- AWS Channel Partner 缓存策略是否贴合内容更新频率：缓存太短浪费加速，太长又可能展示旧内容。
- 缓存键是否正确：查询参数和头信息策略不对，命中率与内容一致性都会出问题。
- HTTPS 与域名绑定是否严谨：少一步就会让用户看到证书警告。
- 监控与日志是否足够：没有可观测性，优化就只能靠猜。
把这些做扎实，你的 CloudFront 就能稳定地为全球用户提供更快、更安全的内容交付。
