Amplify Hosting 是 AWS 的"连接 git 仓库即可获得已部署站点"服务。它封装了 S3、CloudFront、ACM 和 CodeBuild——与手动配置所用的基础组件相同,但打包成了单一控制台。结果比原始 S3 + CloudFront 更接近 Vercel,同时带有 AWS 的账单和相应的生态集成。
"Amplify" 这个名字指代两个不同的东西,常被混淆。Amplify Hosting 是本教程的主角:一个 git 驱动的 Web 托管服务,它构建你的站点、部署到 CloudFront 支持的 CDN、提供免费 TLS 证书,并在每次推送时自动重新部署。Amplify Studio(以及 Amplify 库)则是另一个产品——一个完整的后端平台,包含生成式 DataStore API、认证流程和 React 组件。两者有关联(Amplify Hosting 可以与 Amplify Studio 配合使用),但 Amplify Hosting 单独也能与任何后端或无后端场景配合工作。本教程只讲 Hosting 部分。
说实话:Amplify Hosting 是 AWS 注意到 Vercel 和 Netlify 后的产物。它做的是同样的事——git 连接、分支部署、环境变量、预览 URL、自定义域名。用户体验明显落后于 Vercel;构建日志密密麻麻;CLI 虽然存在,但大多数操作都假设你用控制台。你换来的是:一切都在你的 AWS 账户里——同样的 IAM、同样的账单、同样的 VPC(如果需要的话)、同样的支持合同。对于有"必须在 AWS 上"政策的团队来说,Amplify Hosting 是阻力最小的路径。
本教程将介绍"把仓库连接到上线 URL"的完整流程,指出 Amplify 的默认设置会让你意外的地方,并展示第二次部署(也就是你日后反复经历的部署循环)是什么样的。我们还会讲清楚何时应该完全跳过 Amplify Hosting——有几种情况下,手动 S3 + CloudFront 管道反而更干净。
amplify.yml*.amplifyapp.com URL)。
Amplify 会在首次连接时尝试检测你的框架。对于常见框架,无需干预即可正常工作——Next.js、Nuxt、Vite、Create React App、Hugo、纯 HTML 都没问题。对于不太常见的框架(SvelteKit edge runtime、Remix、带适配器的 Astro),自动检测选取的默认值未必符合你的配置。
连接之前,请确认以下几点:
npm run build、pnpm build、hugo 等)。./dist、./out、./public、./.next)。在 AWS 控制台,打开 Amplify → 创建新应用 → 托管 Web 应用。选择你的 git 提供商:
授权后,选择仓库和分支(生产环境通常是 main)。点击"下一步"。
amplify.yml 文件Amplify 会展示一个描述构建过程的 YAML 文件。对于自动检测到的 Vite 项目,它看起来像这样:
version: 1
frontend:
phases:
preBuild:
commands:
- npm ci
build:
commands:
- npm run build
artifacts:
baseDirectory: dist
files:
- '**/*'
cache:
paths:
- node_modules/**/*
如果检测结果看起来正确,直接接受并继续。如果输出目录有误(最常见的错误——Amplify 猜测是 dist,但你的实际是 build,或者反过来),在这里修改 baseDirectory。你也可以将此文件以 amplify.yml 的形式提交到仓库根目录,以便将构建配置纳入源码管理。
API_KEY、DATABASE_URL 等变量。它们在构建时(以及对于 SSR 应用,在请求时)都可以使用。永远不要把密钥写进 amplify.yml。
点击保存并部署。Amplify 会执行以下流水线:
耗时:小项目 2–5 分钟,依赖包较多时更长。当 Deploy 变绿后,Amplify 会显示上线 URL——https://main.d1234abcde.amplifyapp.com。点击它,你的站点应该可以正常访问。这个 URL 已启用 HTTPS,由 CloudFront 边缘节点缓存,在你绑定自定义域名之前就已经可以用了。
App → 域名管理 → 添加域名。输入 mybrand.com。Amplify 会展示子域名映射关系:
mybrand.com → main 分支www.mybrand.com → main 分支(可设置重定向到顶级域名,或反过来——选择你的规范域名)点击保存。Amplify 会申请 ACM 证书(在 us-east-1 内部处理,你无需操心)并请求 DNS 验证:
在应用概览页,点击连接分支。选择一个功能分支——Amplify 会在 https://<branch-name>.d1234abcde.amplifyapp.com 创建一个独立的部署。向该分支推送代码会触发预览部署,main 分支不受影响。
基于 PR 的预览:应用设置 → 预览 → 启用。Amplify 会监听连接的 GitHub/GitLab 仓库中的未关闭 PR,并为每个 PR 创建临时预览 URL。便于代码评审;PR 关闭后 URL 自动消失。
git push 就是部署命令就这么简单。推送到 main → Amplify 构建 → 部署 → 使 CloudFront 缓存失效 → 几分钟内你就能在 mybrand.com 看到新版本。CLI 虽然存在(amplify push 用于 Amplify Studio 侧;amplify pull 用于同步配置),但仅做托管的话你很少会用到它。
构建日志在 App → 分支 → 构建编号处查看。构建失败默认会发邮件通知;如需更丰富的告警,可通过应用设置 → 通知接入 Slack / Discord。
你原本没有在用 AWS。Vercel 和 Netlify 的用户体验明显更好,构建冷启动更快(Amplify 的 CodeBuild 容器预热较慢),免费套餐也更友好。Amplify 唯一的优势是 AWS 账户集成——没有这个前提,这笔交易就不划算。
你的项目有 Amplify CodeBuild 镜像支持不好的特殊构建步骤。CodeBuild Linux 镜像是通用型的,但并不全面。如果你的构建需要系统级依赖、自定义 apt-get 包,或者 Amplify 尚未更新支持的特定 Node 版本,你会花大量时间与镜像较劲。使用自有 CI 的手动 S3 + CloudFront 方案可以完全掌控构建环境。
每月不足 1 美元的静态站点。Amplify Hosting 从第一分钟构建开始计费——通常为每构建分钟 1 美分,加上 CDN 数据传输和请求费用。部署频率低的静态站点在原始 S3 + CloudFront 上会更便宜,因为省去了构建分钟费用。大约以每月 50 次部署为分界线;低于这个频率,手动 S3 更划算。