AWS 到 DigitalOcean 迁移指南 2026
许多开发团队选择从 AWS 迁移其系统到 DigitalOcean，以降低定价结构的复杂性和日常系统维护。本指南是分步迁移指南，从服务比较和数据迁移规划到 DNS 切换和迁移后成本考虑。适合已决定迁移并需要明确行动计划的团队。
目录
为什么团队从 AWS 迁移到 DigitalOcean
AWS 是市场上最全面的云服务提供商，提供从计算、存储和数据库到机器学习和大规模企业特定服务的各种服务。然而，这种全面性伴随着复杂性：需要学习的服务数量众多，基于实际使用的定价结构包含多个行项目（计算、存储、IOPS、可用区之间的数据传输、NAT 网关成本和 API 请求费用），以及一个选项众多的控制台，甚至中等规模的团队也可能在设置和维护上花费大量时间。 决定迁移到 DigitalOcean 的团队通常引用类似的原因：他们想要更可预测的定价结构，因为 Droplet 按月固定收费，将 CPU、RAM、SSD 和传输额度捆绑为单一价格，而不是像 AWS 那样按行逐一计费，每月账单有数十行项目。另一个原因是没有专职云或财务工程师监控月度账单的团队发现 DigitalOcean 的仪表板更容易理解，而且文档（DigitalOcean 社区教程）是直接为开发者编写的，而不是仅为大型企业的架构师编写的。 还有一些情况是团队仅使用基本的 AWS 服务，如用于运行 Web 应用的 EC2、用于静态文件存储的 S3 和用于数据库的 RDS，而不使用与 AWS 生态系统内事件源相关联的 Lambda 等 AWS 特定服务、Redshift 或 SageMaker。在这种情况下，迁移到 DigitalOcean 通常很直接，因为工作负载遵循可在任何平台上运行的标准架构，而不是被锁定在 AWS 专有服务中。 值得注意的是，本文并不是说 AWS 更差或应该在所有情况下都被弃用，而是为已评估自己需求并决定迁移的团队提供指导，使迁移过程尽可能顺利。
- Droplet 定价是固定月费，不像 AWS 为每个服务组件单独收费
- 理想适用于没有专职云/财务工程师监控月度账单的团队
- 适用于未与 AWS 特定服务绑定的标准工作负载（Web 应用、API、数据库）
服务比较：EC2→Droplet、S3→Spaces、RDS→Managed DB
基于真实使用经验，比较 AWS 和 DigitalOcean 服务应理解为"概念级"比较，而不是"规格对规格"比较，因为定价模型和成本计算不同。
EC2 → Droplet：EC2 实例根据实例系列、地区、操作系统和单独计费的存储（EBS）以及单独收费的出站数据传输进行定价。相比之下，Droplet 使用固定费率模型，将 CPU、RAM、SSD 和带宽额度捆绑为单一价格。例如，基本 Droplet（共享 CPU）起价为 512 MiB RAM/1 vCPU/10 GB SSD/500 GiB 传输，每月 $4，最高可达 16 GiB RAM/8 vCPU/320 GB SSD/6,000 GiB 传输，每月 $96。如果需要稳定 CPU 性能的工作负载（与计算优化等专用 EC2 实例类型相当），DigitalOcean 提供通用 Droplet（专用 CPU）作为单独的层级，起价 $63/月（8GB RAM、2 vCPU、25GB SSD），最高可达 $1,260/月。这些价格区间与基本 Droplet 不同，因此需要选择与工作负载匹配的层级。
S3 → Spaces：Spaces 是一个对象存储服务，使用 S3 兼容 API，意味着为 S3 编写的 SDK 和工具（如 s3cmd 或 AWS SDK）只需更改端点即可与 Spaces 一起工作。例如，从 S3 迁移文件到 Spaces 涉及先用 aws s3 sync s3://bucket ./local/ 从 S3 下载，然后用 s3cmd sync ./local/ s3://new-space --host=sgp1.digitaloceanspaces.com 上传到 Spaces。Spaces 起价每月 $5，并包括内置 CDN，无需像 S3 那样需要单独设置 CloudFront。
RDS → Managed Database：RDS 定价基于实例类、预配存储和选定的 IOPS，每项分别计费。DigitalOcean 的 Managed Database 使用固定费率层级模型——例如，PostgreSQL 和 MySQL 基本层（1 vCPU/1 GiB RAM、10-30GiB 存储）起价 $15.15/月，MongoDB 基本层 $15.23/月。以前称为 Managed Redis 的服务已更名为 Valkey（一个兼容 API 的 Redis 分叉），起价 $15/月。对于超过层级额度的额外存储，按 $0.215/GiB/月计费。
此处的所有定价信息截至 2026 年 7 月；在预算前应与提供商核实最新定价。
- EC2 → Droplet：固定月费定价 CPU/RAM/SSD/传输，不像 EC2 为 EBS 和数据传输分别计费
- S3 → Spaces：使用 S3 兼容 API；只需更改端点
- RDS → Managed Database：PostgreSQL/MySQL 起价 $15.15/月，MongoDB $15.23/月，Valkey（前身 Managed Redis）$15/月
- 需要稳定 CPU 的重型计算工作负载应与 Droplet 通用版本（专用 CPU）对比，起价 $63/月，而非基本 Droplet
规划数据迁移和停机时间
在开始实际迁移前，先清点所有 AWS 资源：活跃的 EC2 实例、S3 存储桶、RDS 实例、安全组、与其他服务绑定的 IAM 角色以及环境变量或配置中任何硬编码的 AWS 端点。这确保在迁移过程中不会遗漏任何东西。
推荐的方法是首先在 DigitalOcean 上创建一个紧密镜像生产设置的暂存环境。例如，用 doctl compute droplet create staging-app --region sgp1 --size s-2vcpu-4gb --image ubuntu-24-04-x64 创建一个 Droplet，然后安装与 EC2 上相同的堆栈（例如 Nginx、PHP-FPM、Node.js），并在尝试实际数据迁移前测试在暂存环境上部署实际应用。
从 S3 迁移文件到 Spaces 涉及首先用 aws s3 sync s3://bucket ./local-backup/ 从 S3 下载，然后用 s3cmd sync ./local-backup/ s3://new-space 上传到 Spaces。对于非常大的文件，考虑分批进行传输以减少带宽压力。
数据库是需要最谨慎规划停机时间的地方，因为数据在系统运行时不断变化。基本方法是使用 pg_dump 或 mysqldump 从 RDS 导出，并通过 DigitalOcean 控制面板的连接字符串导入到 Managed Database，例如 mysqldump -h rds-endpoint -u user -p dbname > backup.sql 后跟 mysql -h managed-db-host -u user -p dbname < backup.sql。这种方法适用于合理大小的数据库和可接受的停机时间。对于非常大的数据库或持续流量，考虑在切换前设置临时复制以连续同步数据，将停机时间仅减少到连接字符串切换。
为实际切换选择最低流量时间，如果预期有任何可见停机时间，请提前通知用户。
- 首先清点所有 AWS 资源，包括代码中硬编码的端点
- 在 DigitalOcean 上创建暂存环境并在迁移数据前测试真实部署
- 分批迁移 S3 文件到 Spaces 以减少带宽负荷
- 对于大型数据库，考虑临时复制以最小化停机时间
迁移 DNS 并在完全切换前测试
DNS 切换是最后一步，将真实流量指向 DigitalOcean 而不是 AWS，因此在切换前务必充分测试。
首先，在切换前至少 24-48 小时降低 DNS 记录的 TTL 以加快切换时的传播。用 dig cloudpicked.com A +noall +answer 检查当前 TTL 并通过你的 DNS 提供商降低它（例如，降到 300 秒）。
在实际切换 DNS 前，验证新 Droplet 上的应用程序在不等待 DNS 传播的情况下使用你的真实域名工作正常。用 curl --resolve cloudpicked.com:443:167.99.x.x https://cloudpicked.com 强制 curl 直接连接到新 Droplet 的 IP，同时仍在 SNI/Host 标头中发送真实域名。这测试 SSL 证书、虚拟主机配置和重定向。或者，暂时编辑本机上的 /etc/hosts 通过浏览器测试。
测试完成后，更新 A 记录（或 IPv6 的 AAAA）指向新 Droplet 的 IP 或负载均衡器（如果有多个 Droplet 在其后）。对于需要在将来 Droplet 重建中保持一致 IP 的系统，考虑预留 IP（只要附加到活跃 Droplet 就免费；未附加时 $5/月），以便可以在不再次更新 DNS 的情况下将 IP 移到新 Droplet。
切换后，使用 dig +trace 或 DNS 传播检查器服务从多个地区验证 DNS 传播，并监控两侧日志 24-48 小时，以防任何流量仍在旧 AWS 端点的用户浏览器缓存中。仅在确信没有遗留流量后才终止 AWS 实例。
- 在实际切换前至少 24-48 小时降低 TTL
- 在切换 DNS 前先用 curl --resolve 或 /etc/hosts 测试
- 使用预留 IP 在 Droplet 间移动 IP，而无需重新编辑 DNS
- 在切换后 24-48 小时内监控两侧
迁移后的成本考虑
综合多次测试，AWS 以复杂的定价结构而闻名，有许多账单行项目，如可用区之间的数据传输、按小时和按 GB 的 NAT 网关费用、单独的 IOPS 计费、随时间累积的快照成本，以及 S3 的按 API 调用计费。这经常让团队在某些月份遭遇意外账单，这是他们寻求更简单定价结构的关键原因。 然而，迁移到 DigitalOcean 并不意味着完全放弃成本管理。仍有行项目需要监控：未附加的预留 IP 每个 $5/月，卷（块存储）$0.10/GiB/月，卷和 Droplet 快照 $0.06/GiB/月（如果忘记删除旧快照或未使用的卷，会累积），以及超过层级的 Managed Database 存储包括额外费用 $0.215/GiB/月。 另一个需要关注的点是将 Droplet 选择适配到实际工作负载。许多新团队因性能问题的担忧而过度配置 Droplet，而 Droplet 可以在流量增长时之后调整大小。从正确的大小开始并根据需要扩展更经济。 最佳实践是在迁移后立即通过 DigitalOcean 控制面板设置账单警报以在支出超过阈值时收到通知。还应定期每月审查未使用的资源（卷、快照、未附加的预留 IP）。本文中的所有定价信息截至 2026 年 7 月；在实际预算前检查提供商的当前定价。
- 未附加的预留 IP 每个 $5/月
- 卷费用 $0.10/GiB/月，快照费用 $0.06/GiB/月，若未删除会累积
- 超过层级的 Managed Database 存储额外费用 $0.215/GiB/月
- 将 Droplet 大小适配到实际工作负载，根据需要调整大小
- 迁移后立即设置账单警报
何时使用此方法（真实用例）
从 AWS 迁移到 DigitalOcean 在某些情况下比其他情况下效果更好。在决定前清楚评估你的需求会显著降低迁移风险。 理想场景包括主要工作负载是标准架构的团队——无论是 Web 应用、REST API、后台工作者还是典型关系数据库——运行在虚拟机或容器上，而不是被锁定在 Lambda（与 AWS 生态系统中多个事件源集成）、用于数据仓库的 Redshift 或用于机器学习管道的 SageMaker 等 AWS 特定服务。此外，没有专职云/财务工程师的小到中型团队通常从 DigitalOcean 更简单的定价中明显受益。 另一种情况是用户主要在东南亚的团队，因为 DigitalOcean 有新加坡（sgp1）和班加罗尔（blr1）地区对泰国用户有低延迟，可能与或超过团队之前使用的 AWS 地区延迟，具体取决于原始设置。 相反，在迁移深度集成了 AWS 特定服务的系统前要谨慎（紧密的 IAM 角色集成、复杂的 CloudFormation 堆栈或 DigitalOcean 不提供等效服务的服务）。这样的迁移可能需要重写整个服务模块，而不仅仅是更改端点。同样，如果你的行业有特定的仅与 AWS 相关的合规或认证要求，先验证 DigitalOcean 是否满足这些要求。 对于仍不确定的团队，首先迁移低风险工作负载，如暂存环境或不直接影响最终用户的内部服务，以评估团队就绪情况和工具，然后再处理生产。
- 适用于标准工作负载（Web 应用/API/数据库）且未与 AWS 特定服务绑定
- 适用于没有专职云/财务工程师的团队
- 东南亚用户受益于新加坡/班加罗尔地区
常见错误和修复
第一个常见错误是忘记代码中硬编码的 AWS 端点，如配置文件中嵌入的 S3 存储桶 URL 或应用中硬编码的 RDS 主机名而不是从环境变量读取。DNS 切换后，应用仍尝试连接到 AWS。修复方法是在实际迁移前在整个代码库中 grep amazonaws.com 并将所有配置移到环境变量。
第二个常见错误是在切换前没有在新 Droplet 上充分测试你的应用，特别是 SSL 证书，这些证书经常发放不正确或不覆盖所有子域，导致 DNS 切换后立即在浏览器中出现警告。修复方法是如前所述用 curl --resolve 测试，并在切换前验证 SSL 证书覆盖所有域/子域。
第三个常见错误是不在指向真实流量前设置云防火墙，因为来自 AWS 的安全组不会自动迁移；你必须在 DigitalOcean 上创建新的防火墙规则。例如，仅为 Web 服务器打开端口 80/443，SSH 仅来自你团队的 IP。忘记这一点可能会意外打开比预期更宽的端口。
第四个常见错误是低估数据库停机时间，特别是大型数据库，其中 pg_dump/mysqldump 导出/导入花费时间比预期长，导致停机时间比向用户宣布的更长。修复方法是在暂存上先测试实际持续时间，对于大型数据库考虑持续复制而不是一次性转储。
最后一个常见错误是在切换后流量仍在用户浏览器的旧 DNS 缓存中留存时太快关闭 AWS 实例。在终止 AWS 资源前，保持两侧监控至少 24-48 小时，确保没有流量留存，如果出现意外问题有回滚路径。
- 代码中硬编码的 AWS 端点 — 在迁移前 grep amazonaws.com
- 切换前没有测试 SSL/虚拟主机 — 总是先用 curl --resolve 测试
- 忘记配置云防火墙 — 安全组不会自动迁移
最佳实践
大规模迁移应分阶段进行（分阶段迁移）而不是一次性完成。从最低风险的部分开始：首先迁移来自 S3 的静态文件到 Spaces，因为它们不涉及实时读/写流量，然后从 EC2 迁移应用服务器到 Droplet（暂时并行运行两者以进行测试），最后迁移数据库作为最高风险的最后一步。
使用自动化工具如 doctl 或 DigitalOcean 的 Terraform 提供商构建基础设施，而不是一次一个项目地点击控制面板。这使重新运行或在出现问题时回滚更容易，并确保暂存和生产环境有可重现的、相同的配置。
在切换后一段时间内保持 AWS 资源处于"就绪但未接收流量"状态，而不是立即关闭。这为迁移后出现的意外问题提供回滚路径。一旦在预定时间内确信你的 DigitalOcean 系统稳定（例如 1-2 周），然后真正关闭 AWS 资源。
提前编写详细的切换手册，包括回滚步骤和每个阶段的清晰责任分配，以减少切换当天的混淆，特别是如果你的团队需要多人同时协调。
最后，在切换前而不是之后在 DigitalOcean 上设置监控和警报策略。DigitalOcean 提供免费监控和每个账户一次正常运行时间检查，因此可以在真实流量开始流向新基础设施时立即发现问题。
- 分阶段迁移（分阶段迁移），从最低风险到最高风险：静态文件 → 应用服务器 → 数据库
- 使用 doctl/Terraform 构建基础设施以实现可重现性，而不是点击控制面板
- 在终止前将 AWS 资源保持为 1-2 周的回滚路径