AWS 新加坡区 Aurora 指南：MySQL/PostgreSQL 选型与 Serverless v2（2026）
目录
在 AWS 新加坡区选 Aurora，先定引擎再定形态：MySQL 还是 PostgreSQL 看数据形态和团队，Serverless v2 还是预置实例看流量曲线，跨 region 灾备开不开看你能丢多少数据。 这三个决策的顺序不能乱，选错了要迁移，代价比一开始想清楚大得多。
上个月一家做东南亚 SaaS 的团队找我们。他们在 AWS ap-southeast-1 上线了产品，数据库随手开了一个 Aurora MySQL 预置实例，db.r6g.large 常年跑着。问题是他们的后台是给企业客户用的，工作日白天有量、晚上和周末几乎没人访问，一个月里大概 60% 的时间数据库在空转。账单出来数据库那块每月三百多 SGD，其中一大半是没人用的时候烧掉的。他们问能不能省。这就是典型的选型没做够。引擎选得没问题，形态选错了。间歇负载本该用 Serverless v2 的 scale-to-zero，空闲自动暂停，能砍掉七成上下的空转成本。
Aurora 在新加坡区不难开，难的是开之前那几个决策。这篇按你会遇到的顺序讲：先选引擎，再选形态，再决定要不要跨 region 灾备，最后算新加坡区的实际账单和采购路径。
新加坡区 Aurora 第一步：选 MySQL 还是 PostgreSQL？
先定引擎，因为引擎决定后面所有事：扩展生态、JSON 能力、团队学习曲线都跟引擎绑死，换引擎等于重做迁移。 判断标准就三条：数据形态、扩展需求、团队现状。
数据形态是第一条分水岭。如果你的业务有海量半结构化数据（用户配置、事件日志、商品的可变属性），而且要在数据库里对这些 JSON 做查询和索引，PostgreSQL 的 JSONB 加 GIN 索引是明显更强的选择，能当半个文档数据库用还保留 ACID 事务。标准的关系型 OLTP（订单、账户、库存），MySQL 和 PostgreSQL 跑起来差别不大，两家都成熟。
扩展需求是第二条。如果你要地理位置计算（PostGIS）、向量检索（pgvector，做 AI 应用的越来越常用）、或者复杂的全文搜索，这些能力 PostgreSQL 有成熟扩展，MySQL 要么没有要么支持有限。反过来，如果你完全不碰这些，这条对你不构成约束。
第三条是团队，也是最容易被忽略的一条。我见过团队为了”PostgreSQL 更现代”把跑得好好的 MySQL 库迁过去，结果运维踩了一堆 PG 特有的坑（VACUUM、连接数模型、复制机制都不一样），迁移成本远超收益。一个有十年 MySQL 经验、又用不上 PG 特有能力的团队，留在 MySQL 是理性选择。数据库选型的一条老实话：怎么运维它，比选哪个更重要。
方向性的参考是，2023 年 PostgreSQL 首次在 Stack Overflow 开发者调查里超越 MySQL 成为最常用数据库，此后连续居首。新项目、没有历史包袱、又说不准以后要不要上 JSON 和扩展的，默认从 PostgreSQL 起步是当下更稳的押注。
数据来源: Stack Overflow Developer Survey（PostgreSQL 2023 首次居首、2024 蝉联） + AWS Database Blog: PostgreSQL as a JSON database，2026-07-20 调研。
| 你的情况 | 建议引擎 | 理由 |
|---|---|---|
| 海量 JSON、库内复杂查询 | Aurora PostgreSQL | JSONB + GIN 索引，文档能力强 |
| 要 PostGIS / pgvector / 高级全文搜索 | Aurora PostgreSQL | 扩展生态只有 PG 有 |
| 标准 OLTP、团队 MySQL 底子深 | Aurora MySQL | 换引擎徒增迁移成本 |
| 全新项目、没历史包袱 | Aurora PostgreSQL | 顺应生态趋势，扩展性留余地 |
| 从阿里云 PolarDB MySQL 版迁来 | Aurora MySQL | 同引擎迁移最省事 |
Aurora Serverless v2 还是预置实例？scale-to-zero 怎么用
引擎定了之后选形态：负载稳定选预置实例，负载间歇选 Serverless v2；Serverless v2 现在能 scale-to-zero，但要接受冷启动。 这是新加坡区 Aurora 最容易省下钱、也最容易踩坑的一个决策。
预置实例就是传统模式：你定一个规格，它 7×24 常驻，不管有没有流量都按小时计费。生产级规格（比如 db.r6g.large，2vCPU/16GB）在新加坡区月成本大约 200+ SGD 起；对预算敏感或开发测试库，可以先用突发型 db.t4g.medium 这类规格起步，比 r 系列便宜不少。预置实例适合负载稳定、随时有请求的核心库，延迟可预测，没有冷启动。
Serverless v2 不一样，它按 ACU（Aurora Capacity Unit）秒级计费，容量在你设的最小值和最大值之间自动伸缩，最大能到 256 ACU。真正的变化在 2024 年底：v2 现在能把最小容量设到 0 ACU，空闲超过你设定的时长后自动缩容归零、暂停计算，暂停期间只收存储费、不收计算费。这解决了开头那家 SaaS 团队的问题。夜里没人用，库自动睡，不烧钱。
代价是冷启动。从 0 ACU 暂停态被唤醒、恢复第一个连接，最多约 15 秒。这 15 秒对不同业务意味着完全不同的东西：
- 开发库、测试库、内部工具、夜间无访问的后台 → scale-to-zero 很划算，15 秒没人在意
- 面向 C 端、随时可能来一个真实用户请求的核心交易库 → 15 秒冷启动会直接打到用户脸上，别用 0 ACU，设个非零最小值（比如 0.5 ACU）保持热态，或者干脆上预置实例
还有个容易漏的点：Serverless v2 之前不支持 0 ACU 时，最小 0.5 ACU 是持续计费的，一个月空转也要几十美金。现在能到 0，才真正做到”不用不花钱”。这是选 v2 时值得知道的时间线。
数据来源: AWS Database Blog: Scaling to 0 capacity with Aurora Serverless v2，2026-07-20 调研；冷启动 15 秒为社区实测区间，实际以你的库大小和配置为准。
一个避坑提醒：Aurora Serverless v1 已经在 2025 年 3 月 31 日 EOL 下线了，不再受支持。网上还有大批教 v1 自动暂停的老文章，别照着配。现在新建 Serverless 库只有 v2 一条路，v1 和 v2 的架构、计费、扩缩容逻辑完全不同。
数据来源: AWS Database Blog: Aurora Serverless v1 End of Life (2025-03-31)，2026-07-20 调研。
跨 region 灾备要不要做？Aurora Global Database 的账怎么算
灾备开不开，取决于你能丢多少数据、能停多久。Aurora Global Database 给你秒级 RPO，但成本接近翻倍。 别默认所有库都要跨 region，也别默认核心库不用。
Aurora Global Database 的机制是：主集群在新加坡（ap-southeast-1），在另一个 region（比如东京 ap-northeast-1 或雅加达 ap-southeast-3）放一个只读的备用集群，主区域的数据通过专用链路持续复制过去。RPO（能容忍丢多少数据）通常是秒级，RTO（多久能恢复服务）取决于你切换的自动化程度。主区域整体故障时，把备区域提升为主，业务接着跑。
这跟”跨 region 快照定期备份”是两个成本档次：
| 灾备方案 | RPO | RTO | 成本 | 适合谁 |
|---|---|---|---|---|
| 无跨 region（仅 Multi-AZ） | 单 region 内秒级 | 分钟级 | 基础 | 内部系统、可容忍单 region 风险 |
| 跨 region 快照 + 恢复 | 数小时 | 数十分钟到小时 | 低（存储 + 少量传输） | 能容忍小时级恢复的业务 |
| Aurora Global Database | 秒级 | 分钟级 | 接近翻倍（备集群 + 跨 region 流量） | 金融、支付、订单等丢数据即出事 |
成本坑主要在两处：备用集群要长期运行（哪怕只读，也在计费）、主备之间的跨 region 数据传输费按量收。想省的话，备区域可以用 Serverless v2 起步（平时低容量待命，切换时再扩），或者用”headless”最小配置的备集群压低常驻成本。但只要开了 Global Database，就要有”数据库成本大约翻倍”的心理准备。
我的建议是分层做：把库按”丢数据的代价”分级，支付/订单/账户这种上 Global Database，日志/报表/内部工具用跨 region 快照就够。别一刀切给所有库上最贵的方案。
数据来源: AWS Aurora Global Database Documentation，2026-07-20 调研；跨 region 传输与集群费用以 AWS ap-southeast-1 最新定价为准。
新加坡区 Aurora 一个月到底多少钱？
Aurora 的账单是四块拼出来的：计算、存储、I/O、跨区流量。不少人只算了计算那块，上线才发现另外三块加起来也不小。 在 ap-southeast-1 尤其要把 I/O 和跨区流量看清楚。
四块分别是：
- 计算：预置实例按规格×小时，Serverless v2 按 ACU×秒。这是大头，也是唯一能靠 scale-to-zero 砍到 0 的部分。
- 存储：按实际用量 GB 计费，Aurora 存储自动扩，不用预配。跨三个 AZ 的六副本是内置的，这块不额外加价。另有备份存储，超过库容量的部分按量计。
- I/O：Aurora 标准配置按 I/O 请求量计费，高频读写的库这块可能超出预期。如果你的库 I/O 极密集，Aurora I/O-Optimized 配置（计算贵一点、I/O 不单独收费）可能更划算，值得对比。
- 跨区流量：这块要拆开看。Aurora 存储层跨 AZ 的六副本复制不额外收费，但你的应用服务器和 DB 实例如果分在不同 AZ，两者之间的数据传输按 AWS 跨 AZ 流量计费，应用与库放同一 AZ 能省这块。开了 Global Database 之后，跨 region 复制的数据传输再按量计一笔。
拿开头那家 SaaS 团队举例：他们原来 db.r6g.large 预置实例常驻，月成本三百多 SGD，60% 时间空转。切到 Serverless v2、最小设 0 ACU、空闲 10 分钟自动缩容归零后，工作日白天正常伸缩、晚上和周末自动睡，空转时段的计算成本几乎砍到零、整月计算账单省下约七成。前提是他们的后台是 B 端、晚上确实没人访问、也能接受早上第一个请求有十几秒冷启动。这套账不是对谁都成立，得先确认你的负载曲线长这样。
数据来源: AWS Aurora Pricing (ap-southeast-1)，2026-07-20 调研；上述客户成本为实测抽样，具体金额随负载浮动，仅作量级参考。
阿里云 PolarDB 这里点一句：低配起步 PolarDB 按需价低于 Aurora，两家的存储副本模型和 Serverless 实现各不相同，具体能力差异以两家官方文档为准。如果你其他业务已经在 AWS 新加坡，Aurora 省掉跨云割裂；如果数据库独立选型、负载稳定又预算敏感，PolarDB 值得放进对比。想看两家在新加坡的延迟和成本实测，可以参考站内的阿里云新加坡服务器完整评测。
新加坡公司怎么买 Aurora？付款与合规
技术选型定完，最后一关是付款和做账。这一关卡住的新加坡公司比卡在技术上的多。 Aurora 作为 RDS 的一部分，采购路径跟 AWS 其他服务一样。
AWS 官方支持信用卡（SGD 结算）和电汇。问题是部分新加坡中小公司没有国际信用卡，只能对公转账。这时候走代理商代付：代理商用 PayNow/UEN 收 SGD，出一张含 GST（当前税率 9%，以 IRAS 最新公布为准）的 Tax Invoice，这张发票可以对 IRAS 做进项税抵扣，代理商再统一付 AWS 账单。这是新加坡公司最实用的本地付款路径。
选代理商别只看网站。上 AWS Partner Directory 用 “Singapore” 筛，查 APN 等级，Select 以下拿不到企业级折扣。本地注册的代理商必须在 ACRA BizFile+ 上有 UEN 可查。最实的一招：让代理商发一份近期的 Tax Invoice 样本，把上面的 GST 注册号拿到 IRAS 官网验一下是否有效。合规上，把 Aurora 数据放在 ap-southeast-1 就省去了 PDPA 跨境传输的合规评估（PDPA 管的是跨境传输义务，不是强制数据必须留在本地），公司侧记得指定 DPO、别不小心开了跨 region 复制把数据同步出去（除非那正是你要的灾备）。
采购和折扣叠加的细节，可以看AWS RDS 代理采购页，或站内AWS 新加坡区完整指南里 PayNow 和 Tax Invoice 那部分的完整拆解。
常见问题
AWS 新加坡区 Aurora 选 MySQL 还是 PostgreSQL？
看三件事。一是数据形态：海量半结构化 JSON、要在库内做复杂查询选 PostgreSQL（JSONB + GIN 索引），标准 OLTP 两家都行。二是扩展需求：要 PostGIS 地理、向量检索、pgvector 这类扩展只有 PostgreSQL 有。三是团队：团队十年 MySQL 运维经验、不用 PG 特有能力就留 MySQL，别为选型本身徒增迁移成本。2023 年 PostgreSQL 首次在 Stack Overflow 开发者调查中超越 MySQL 成为最常用数据库、此后连续居首，新项目默认可优先考虑 PostgreSQL。
Aurora Serverless v2 的 scale-to-zero 适合生产库吗？
适合流量间歇的库，不适合要求稳定低延迟的核心库。Serverless v2 现在能把最小容量设到 0 ACU、空闲一段时间后自动暂停，暂停期间只收存储费不收计算费。代价是从暂停态恢复第一个连接最多约 15 秒冷启动。开发/测试库、内部工具、夜间无访问的 SaaS 后台很划算；面向 C 端用户、随时可能来请求的核心交易库建议用预置实例或给 v2 设非零最小容量，避免冷启动打到真实用户。
Aurora Serverless v1 还能用吗？
不能。Aurora Serverless v1 已于 2025 年 3 月 31 日达到 End of Life，不再受支持。现在新建 Serverless 库只有 v2 一个选项。网上大批老教程还在教 v1 的自动暂停配置，别照着做。v1 和 v2 的架构、计费、扩缩容机制完全不同，v2 才是现役版本。
Aurora Global Database 跨 region 灾备值不值得开？
看 RPO 要求。Aurora Global Database 跨 region 复制的 RPO 多在秒级，主区域整体故障时可提升备区域接管，比跨 region 快照恢复快得多。代价是要长期运行第二个集群、加上跨 region 数据传输费，成本接近翻倍。金融、支付、订单这类丢几分钟数据就出事的业务值得开；内部系统或能容忍小时级恢复的业务，用跨 region 快照定期备份更省。
AWS 新加坡区 Aurora 比阿里云 PolarDB 贵吗？
按需价格 PolarDB 在低配起步多半比 Aurora 便宜一点，Aurora 的优势在 Serverless v2 的 scale-to-zero（间歇负载能到 0）和跨三 AZ 六副本的存储可靠性。如果你的其他业务已经在 AWS ap-southeast-1，Aurora 省掉跨云网络和运维割裂；如果数据库是独立选型、负载稳定且预算敏感，PolarDB 值得对比。长期采购叠加代理商折扣后，两家总成本差距会缩小。
新加坡公司买 Aurora 怎么付款和做账？
AWS 官方走信用卡（SGD 结算）或电汇。没有国际信用卡的新加坡公司走代理商代付：代理商用 PayNow/UEN 收 SGD，出含 GST 9% 的 Tax Invoice，可对 IRAS 做进项税抵扣，再统一付 AWS 账单。选代理商先在 AWS Partner Directory 查 APN 等级，要求出一份 Tax Invoice 样本，核对上面的 GST 注册号在 IRAS 官网是否有效。
关于 SevenColorYun
SevenColorYun 是 AWS 认证合作伙伴，专注帮中国大陆出海企业在新加坡等海外区域落地云基础设施。数据库这块，我们做三件事：Aurora / RDS 引擎与形态选型评估（按你的负载曲线算该用 Serverless v2 还是预置实例）、跨 region 灾备架构设计（按业务分级决定哪些库上 Global Database）、以及新加坡本地采购代付：用 PayNow 收款、出含 GST 9% 的 Tax Invoice，可对 IRAS 做账，充值返赠 5% 起（具体比例以当期政策为准），免信用卡开通。
如果你正在纠结新加坡区的数据库怎么选，把近 30 天的 RDS/Aurora 用量（Cost Explorer 导出）和公司 UEN 发给我们，48 小时内给一份含引擎选型、形态建议、灾备方案和 TCO 对比的完整评估。
相关阅读
- AWS 新加坡区完整指南：EC2 选型、PDPA 合规、PayNow 代理采购 — 本文的上游，数据库之外的新加坡区 EC2、存储、支付合规全景。
- 阿里云新加坡服务器完整评测 — 想把 Aurora 和 PolarDB、AWS 和阿里云在新加坡放一起比时看这篇。
- EKS/GKE/AKS 成本对比完整指南 — 如果你的 Aurora 是给 K8s 集群做后端，配套看托管集群的真实账单。
- 云服务器隐性成本拆解：出网流量、对象存储与真实账单 — Aurora 跨区流量、I/O 费用这类容易漏算的成本，这篇讲得更全。
