AWS Amplify

Posted on Edited on Views:

最近第一次用，当然是有点手生，还不清楚是干嘛的，写下当前的理解。
貌似是方便开发和部署的，集成了 aws 的很多服务，比如 cognito, s3, lambda, api gateway, cloudfront, cloudwatch, cloudformation, etc.如果你是开始一个全新的项目，用这个全包了相当于。
不用构建配置环境什么的都要在网页上操作很多地方。
目前也就这两点体会。

一句话总结

  • 能用 amplify 就用
  • 不能用的情况下也要遵循 iac 原则，把配置写到代码里
  • 最不提倡的就是网页上直接改配置，不可以追溯

amplify 的 cli

// install
npm install -g @aws-amplify/cli

// init
amplify init

// add auth
amplify add auth

// add function 也就是 lambda
amplify add function

// push 部署
amplify push -y // -y 是自动确认

// pull 拉取，比如使用了amplify生成lamda和dynamo，如果在网页上修改了一些配置，会同步到amplify么，如何同步
amplify pull --appId xxx --envName dev

网页配置对比 amplify 的本地配置冲突

比如使用了 amplify 生成 lamda 和 dynamo，如果在网页上修改了一些配置，会同步到 amplify 么，如何同步

r1 解释

在使用 AWS Amplify 生成 Lambda 和 DynamoDB 资源后，如果在 AWS 控制台（网页）直接修改了这些资源的配置，这些更改不会自动同步回本地的 Amplify 项目。Amplify 的核心理念是“基础设施即代码”（IaC），即云端的资源状态由本地配置文件定义。以下是关键点说明和同步方法：

为什么不同步？

  1. 单向同步机制
    Amplify CLI 通过 amplify push 将本地配置推送到云端，但反向同步（云端修改同步到本地）需要手动操作。直接在控制台的修改会被视为“漂移”（Drift），可能导致本地配置与云端状态不一致。

  2. 底层依赖 CloudFormation
    Amplify 使用 CloudFormation 模板管理资源。手动修改资源会导致 CloudFormation 堆栈的实际状态与模板不匹配，后续部署可能失败或覆盖更改。

如何手动同步更改？

方法 1：通过 Amplify CLI 更新本地配置

  1. 修改本地配置文件

    • 找到 Amplify 项目的 amplify/backend 目录，定位到对应资源（如 Lambda 函数或 DynamoDB 表）的配置。
    • 更新 JSON 或 GraphQL 文件（如 template.json、parameters.json 或 schema.graphql）。

  2. 推送更改到云端

    amplify push

    CLI 会将本地变更部署到云端，覆盖之前的控制台修改。

方法 2：保留控制台修改并同步到本地

  1. 手动记录控制台的更改
    例如，如果修改了 Lambda 的环境变量，需在本地找到对应的配置路径（如 amplify/backend/function/<function-name>/parameters.json），更新相应字段。

  2. 解决状态冲突
    运行以下命令检查差异：

    amplify status

    如果显示差异，需手动合并配置后再次 push。

方法 3：重新关联资源（谨慎使用）

对于已存在的资源（如 DynamoDB 表），可通过 amplify import 重新关联：

amplify import

但此操作可能不适用于所有场景，需确保资源未被 Amplify 初始创建，否则可能引发冲突。

最佳实践

  1. 优先使用 Amplify CLI
    始终通过 CLI 修改配置（如 amplify update function 或 amplify update storage），避免直接操作控制台。

  2. DynamoDB 的特殊注意

    • 如果通过控制台修改了表结构（如新增全局二级索引），必须在本地更新 GraphQL Schema（schema.graphql）并重新生成配置：
      amplify api gql-compile && amplify push
    • 否则下次 push 时可能覆盖控制台更改。

  3. 紧急修复的临时方案
    若必须在控制台紧急修改（如修复生产问题），事后需立即同步回本地配置，避免后续部署丢失变更。

总结

  • 控制台修改不会自动同步到 Amplify，需手动更新本地配置并 push。
  • 遵循 IaC 原则，通过 CLI 管理资源，减少手动干预。
  • 若发生配置漂移，需通过 amplify status 检查差异并解决冲突。

通过这种方式，可以确保本地代码与云端资源的一致性，避免部署时的意外问题。

最佳实践是什么

aws 的 inflation 构建，是用 amplify 还是手动在网页构建，最佳实践是什么

下面我会结合实际经验，从项目特性、团队规模、持续迭代需求等角度，详细阐述在 AWS 上构建并部署前端或全栈应用时，是使用 Amplify，还是**手动在控制台（或自定义 CI/CD）**上进行部署更好，并给出一些最佳实践和注意事项。

1. 背景：为什么会有两种选择？

  1. Amplify

    • Amplify 是 AWS 提供的一整套前后端开发与托管工具，包括：
      • Amplify CLI：可在本地快速创建/更新云端资源（Auth, API, Storage, Function 等）。
      • Amplify Hosting / Amplify Console：支持将前端应用一键托管到 AWS，并与 Git 仓库自动集成实现 CI/CD。
    • 优势：对前端开发者非常友好；能快速搭建原型和 MVP；“所见即所得”，配置简洁，自动化程度高。

  2. 手动部署或自定义部署（“非 Amplify 方案”）

    • 手动或自定义部署通常指：
      • 在 AWS 控制台上点击创建资源（Lambda、S3、CloudFront、API Gateway 等）。
      • 使用 AWS CodeBuild / CodePipeline / Jenkins / GitHub Actions / Terraform / AWS CDK 等工具链，自己编排构建流程和基础设施即代码（IaC）。
    • 优势：灵活度与可定制性更高，可以适应大型项目或复杂环境、跨账号、多 Region 部署等；对已有 DevOps 流水线的团队更可控。

2. 适用场景：Amplify vs. 自定义部署

  1. 初创项目 / 中小规模团队 / 快速迭代

    • Amplify 更适合
    • 场景特点：
      • 开发周期紧、要快速验证想法或上线 MVP。
      • 对运维与 DevOps 的资源比较有限。
      • 前端 + 后端一体化管理，团队大多是前端开发者或全栈初级开发者。
    • Amplify 可以帮你省掉大量配置、运维工作：
      • 直接 amplify add auth / amplify add storage 就能生成 CloudFormation 配置。
      • Amplify Console 关联 Git 仓库后，一提交代码就触发自动构建与部署。

  2. 中大型团队 / 多服务架构 / 自定义需求多

    • 自定义部署可能更合适
    • 场景特点：
      • 需要多环境、多账户、多 Region，或者对构建流程和资源管理有更精细的要求（如微服务、复杂网络配置、专有 VPC 规划等）。
      • 团队具备较成熟的 DevOps 流程或基础设施管理经验（Terraform、AWS CDK、Kubernetes、CodePipeline 等）。
    • 可能会使用自定义脚本、Terraform/CDK 来管理资源，或已有一套 CI/CD（Jenkins/GitLab CI/GitHub Actions 等）。此时让 Amplify“接管”所有资源不太现实，冲突较多。

  3. 纯静态网站

    • 如果你只想托管一个纯静态前端（无后端或后端另行管理），有两种常见做法：
      1. Amplify Hosting：开箱即用，对前端而言只需将代码推到主分支，就能自动构建并生成访问域名。
      2. S3 + CloudFront：自己配置存储桶、CDN、HTTPS 证书等，如果已有一套 CI/CD，也可直接把前端产物上传到 S3，然后由 CloudFront 分发。
    • Amplify Hosting 在简单易用方面胜出，而自定义 S3 + CloudFront 在灵活可控方面更好。

3. 常见做法与最佳实践

3.1 使用 Amplify 的最佳实践

  1. 统一管理前端与后端

    • 使用 Amplify CLI 在本地“管理后端”，例如 amplify add auth / api / storage 等，这些操作会生成 CloudFormation 模板并存放在 amplify/backend 目录。
    • 统一通过 amplify push 部署，保证云端与本地状态一致。

  2. Amplify Console（Hosting）自动化部署

    • 在 Amplify Console 上，连接你的 Git 仓库（GitHub、GitLab、CodeCommit 等），一旦仓库代码有新提交，就会自动触发构建与部署。
    • 这样前端包会自动构建并托管到 Amplify Hosting，无需你手动上传。

  3. 多环境管理

    • Amplify 提供多环境概念（如 dev, test, prod），可以在本地切换不同环境，再 amplify push 部署到对应的云端堆栈中，避免相互干扰。
    • 也可以在 Amplify Console 中分别配置不同分支对应不同环境，达到“每个分支一个环境”的效果。

  4. 谨慎直接在控制台修改

    • 如果你手动在 AWS 控制台修改已被 Amplify 管理的资源，Amplify 本地并不知道这些改动，下一次 amplify push 可能会覆盖冲突。
    • 若必须在控制台改动，可尝试 amplify pull 同步；但最好还是在本地 Amplify CLI 中进行更新，避免冲突。
3.2 不用 Amplify，自己在 AWS 控制台或其他工具中构建的最佳实践

  1. 基础设施即代码 (IaC) 优先

    • 无论是 Terraform、AWS CDK、Serverless Framework 还是 CloudFormation，都把资源配置写在代码里进行版本管理，保证可追溯、可回滚。
    • 手动点击的方式适合做小规模试验，但不可重复、易出错，不适合持续迭代。

  2. CI/CD 流程

    • 可用 AWS CodePipeline + CodeBuild 组合，也可以用 GitLab CI / Jenkins / GitHub Actions 等第三方工具。
    • 最常见的流程：
      1. 代码提交到仓库 -> 触发 Pipeline
      2. 执行构建脚本（安装依赖、打包前端）
      3. 部署产物到 S3 / CloudFront（或 ECS / EKS / Lambda）
    • 配合 IaC 工具来做资源变更管理。

  3. S3 + CloudFront 托管静态资源

    • 将前端构建好的静态文件上传到 S3，并配置 CloudFront 进行全局缓存与 HTTPS 加速。
    • 要注意设置合适的缓存策略、错误重定向（对 SPA 而言要处理好index.html路由等）。

  4. 分环境 / 蓝绿部署 / 滚动更新

    • 对大中型项目而言，需要多环境（dev/test/prod）或更高级的部署策略（蓝绿/金丝雀发布）。
    • 这些场景下，你可以使用 CodeDeploy + Lambda + API Gateway 等更灵活的方式，而不是被 Amplify 的默认配置束缚。

4. 对比 & 选择建议

  1. 团队规模和专业度

    • 如果团队小或缺乏 AWS 深度运维经验，想快速上线：用 Amplify。
    • 如果团队 DevOps 经验丰富，需要深度定制：自定义 IaC + CI/CD。

  2. 应用复杂度

    • 前端 + 轻量后端（Serverless）：Amplify 十分合适。
    • 大型微服务 / 多组件交互：更倾向自行编排，Amplify 只能当辅助或局部使用。

  3. 未来可维护性

    • Amplify 将大部分配置抽象化了，升级或自定义时，可能要和 Amplify CLI 生成的 CloudFormation 模板合并，带来一些限制。
    • 自定义方式开发门槛更高，但长期更灵活，可以与多种工具集成。

5. 总结

  • Amplify 更倾向“全家桶”理念：提供从后端资源管理、用户认证、API、存储、函数，到前端托管与 CI/CD 的“一站式”体验，极大降低了上手门槛，适合中小团队快速开发或以前端为主的项目。
  • 手动或自定义部署：使用 AWS 控制台或其他 CI/CD + IaC 工具，对有较高 DevOps 要求的中大型项目或多团队协作更友好，弹性和灵活度更高，但需要更多运维成本和经验。

最佳实践通常是：

  • 如果你主要是做 Serverless 前后端一体化，项目规模不算大，团队希望快速迭代、简化运维，那就优先使用 Amplify。
  • 如果你已经有一套完善的CI/CD 流程、多账户/多环境需求，或者需要对资源进行深度自定义，则可以考虑手动或自定义方案（CodePipeline / Terraform / CDK / Jenkins / GitHub Actions 等），将资源管理与部署融为更复杂的 DevOps 流水线。

希望以上内容能帮助你在“Amplify or not Amplify”的问题上做出更合适的抉择。祝你部署顺利，应用早日上线！