Web 托管、域名与 HTTPS
# Web 托管、域名与 HTTPS
Amplify Hosting 负责构建和托管应用，Route 53 负责域名解析，CloudFront 负责边缘分发与缓存，ACM 管证书，ALB 把请求分给应用实例。它们解决不同问题，不需要每个网站都手动配齐一套。
# 先看两种部署方式
| 方式 | 请求与发布路径 | 适合什么情况 |
|---|---|---|
| 托管前端 | Git 提交 → Amplify 构建发布；用户 → Amplify 托管入口 | 希望快速部署静态站点或受支持的 Next.js 应用，减少托管与发布维护 |
| 自己组合入口 | 用户 → CloudFront → ALB → ECS；静态对象可由 S3 提供 | 应用已容器化，需要控制运行时、私网访问、路由和各服务发布节奏 |
第二种方式里，Route 53 先帮助浏览器找到入口地址，ACM 给入口提供证书；DNS 和证书不是接力转发 HTTP 请求的两台服务器。CloudFront 不执行源站里的 Next.js SSR，真正渲染页面的是 ECS 等运行环境。
# Amplify Hosting：托管构建与发布
Amplify Hosting (opens new window) 是 AWS 的 Web 应用构建与托管服务，支持静态网站和受支持框架的服务端渲染。它能连接 Git 仓库，自动安装依赖、构建、发布，并提供 CDN、自定义域名、重定向、分支环境和拉取请求预览。
常见使用顺序：
- 连接仓库与发布分支，配置构建命令、产物位置和环境变量。
- 提交代码后由 Amplify 自身触发构建，不需要额外写 GitHub Actions 才能发布；团队也可以自行设计外部流水线。
- 用分支预览验证页面、API 地址与认证配置，再发布生产分支。
- 版本出问题时重新部署已验证版本，或回退提交后重建；数据库和合约变更需要单独考虑兼容性。
优点是前端交付集中、维护少；代价是受托管平台的框架支持范围、构建和运行限制约束。Next.js 的某项能力能本地运行，不代表托管环境一定支持，应按应用实际用到的 SSR、ISR、图片优化等能力验收。
原子发布指切换到完整的新部署，避免用户拿到只上传了一半的版本，不保证新版本业务没有缺陷，也不会同步回滚外部 API 或数据库。
# Amplify Hosting 与 Gen 2 Backend 的区别
Amplify Gen 2 Backend (opens new window) 是用 TypeScript 定义认证、数据、存储和函数等后端资源的开发方式。Hosting 负责构建与托管，Backend 负责后端资源；可以一起使用，但使用 Hosting 不代表必须使用 Amplify Backend。前端可以调用独立的 API Gateway、Lambda 或 ECS API。
# Route 53：让域名找到入口
Route 53 (opens new window) 是 AWS 的托管 DNS 服务。浏览器访问 app.example.com 前，先通过 DNS 查询入口地址，再连接 CloudFront 或 ALB；Route 53 不缓存页面，也不执行应用代码。
在 Hosted Zone（托管区）中维护域名记录，常用 Alias 记录指向 CloudFront、ALB 等支持的 AWS 资源。Alias 可以用于根域名，普通 CNAME 不能直接放在 DNS 区域根节点。域名注册商与 DNS 托管商可以不同，但需要正确设置域名的 NS 委派。
切换入口要考虑 DNS 缓存与 TTL（记录缓存时间），不能认为修改记录后全球请求立即切换。DNS 也不一定非用 Route 53，已有 DNS 服务只要能按要求配置记录即可。
# CloudFront：缓存与回源
CloudFront (opens new window) 是 CDN（内容分发网络）与边缘入口。命中缓存时在边缘返回内容；未命中或不能缓存时，把请求发给 Origin（源站），例如 S3 或 ALB。
配置时重点看四件事：
- 哪些请求走哪个源站。用 Behavior（行为规则）按路径选择源站和缓存策略，例如静态资源与业务 API 分开。
- 什么可以共享缓存。带内容哈希的 JS/CSS 适合长缓存；登录状态、用户信息和购买结果不能仅因为是 GET 就共享缓存。SSR 是否可缓存取决于响应是否公开、是否个性化及可接受的陈旧时间。
- 缓存键与转发参数。Cache Key 决定哪些请求共用缓存；Origin Request Policy 决定向源站转发哪些 header、cookie 和 query。转发了某参数，不代表它自动参与缓存区分；会影响个性化响应时尤其要小心。
- 怎样保护回源。CloudFront 到 ALB 使用 HTTPS，并防止用户绕过 CloudFront 直连源站。对于公网 ALB，可结合受控源站请求头、ALB 规则和网络限制；符合条件时也可使用 VPC Origin。
优点是降低就近访问延迟与源站压力；风险是错误缓存导致内容陈旧甚至跨用户数据泄露。接入 CDN 不等于自动隐藏源站或完成鉴权。静态文件更新优先用带哈希的新文件名，必要时再做缓存失效。
# ACM：管理 HTTPS 证书
ACM（AWS Certificate Manager） (opens new window) 管理 TLS 证书的申请、验证与续期。把证书绑定到 CloudFront、ALB 等支持的服务后，由这些服务处理 HTTPS 连接，ACM 本身不转发流量。
- 验证域名：DNS 验证通常要求添加 CNAME，证明你控制域名；保留正确记录以支持后续托管续期。
- 选择证书区域：CloudFront 用户侧使用的 ACM 证书位于
us-east-1；ALB 证书与 ALB 位于同一 Region。两段 HTTPS 要分别配置，不能只配用户侧。 - 检查续期条件：受支持且符合条件的 ACM 签发证书可托管续期；导入证书不能假定由 ACM 自动向原签发机构续期。
- 排查签发失败：检查 DNS 验证记录与 CAA。CAA 用来约束哪些证书颁发机构可以签发该域名的证书，不是域名解析目标。
优点是证书管理与应用发布分离，不必把私钥放进 Docker 镜像、续期后再重建容器。边界是它只管理证书：CloudFront 回源协议、ALB HTTPS listener 和数据库 TLS 仍要分别配置。
# ALB：把请求分给应用实例
ALB（Application Load Balancer） (opens new window) 是应用负载均衡器，按 HTTP 主机名或路径把请求交给目标组，例如页面交给 Next.js，/api 交给 Hono。它可以是公网或内部负载均衡器，不等于必须暴露公网。
Listener（监听器）接收指定端口的连接，规则选择 Target Group（目标组），目标组登记 ECS Task 等应用实例并执行健康检查。HTTPS listener 可绑定 ACM 证书；HTTP listener 可配置为跳转 HTTPS。
CloudFront 面向边缘分发与缓存，ALB 面向区域内路由与负载均衡，两者可以串联。ALB 不负责运行容器，运行与扩缩容由 ECS/Fargate 等承担。实例发布与健康检查的详细边界见 ECS 部署笔记。
# 安全与上线检查
WAF 根据 HTTP 请求特征过滤流量，安全组控制网络访问，应用负责身份与业务权限。只在 CloudFront 上配置 WAF，却允许任意人直接访问源站，会留下绕过路径。
上线至少验证：域名解析正确，两段 HTTPS 正常，动态响应不会串缓存，源站访问受控，ALB 目标健康，登录与一次关键业务读写能完成。服务入口正常不代表数据库、上传和链上任务也正常；运行指标与告警见 可观测性笔记。
# 面试时可以这样回答
为什么有的项目用 Amplify，有的用 CloudFront 加 ECS？参考答案
我主要看运行方式和运维控制需求。前端适配托管平台、希望快速获得 Git 发布和预览环境时，用 Amplify Hosting 更省维护；应用已经容器化，需要统一 Node 运行时、私网数据库和多个独立服务时，用 CloudFront、ALB 加 ECS 更容易控制整条链路。前者减少平台维护，后者增加控制能力，也需要自己负责镜像、网络、健康检查和回滚。
Route 53、CloudFront、ACM、ALB 分别做什么？参考答案
Route 53 让域名找到入口，CloudFront 在边缘分发和缓存内容，ACM 管理 HTTPS 证书，ALB 把到达源站的请求分给应用实例。比如浏览器解析域名后连接 CloudFront，缓存未命中再通过 HTTPS 回源 ALB，最后由 ECS 里的 Next.js 或 API 处理。DNS 不转发网页，证书服务不运行代码，CDN 也不能替代应用鉴权。