不少出海企业当初选择 AWS，是因为它在国内也能稳定访问、覆盖全球区域，比单一云厂商更适合面向海外用户的业务。如果你的出海 App 用 Amazon Pinpoint 做推送通知和应用内消息，现在需要正视一个硬性截止日期：2026 年 10 月 30 日，AWS 停止支持 Amazon Pinpoint。那之后，控制台以及你在里面搭建的一切——用户档案、分群、活动、旅程、数据分析——全部无法访问。
Pinpoint 早在 2025 年 5 月 20 日就已停止接受新注册，这次停服并不突然。AWS 在其官方停服指南里给出了完整时间线。
停服本身不难理解，难的是 AWS 把你导向哪里——因为并不存在单一的继任产品。根据你用 Pinpoint 做什么，你的工作负载会被拆分到 4 个不同的 AWS 服务里。而对大多数移动团队最在意的推送和应用内消息这两块，AWS 推荐的路径都不是无缝迁移。
这篇指南会讲清楚：哪些功能会停用、AWS 把每一块导向哪里、为什么这不是对等替换，以及一套把推送和应用内消息迁移到 Pushwoosh 这个海外推送平台的 4 步方案，附带真实价格，方便你做预算。
Amazon Pinpoint 到底关闭了什么
消息通道 API 本身不会消失，消失的是”运营层”——市场和产品团队登录操作的那一层。
2026 年 10 月 30 日之后，你会失去对 Pinpoint 资源的访问：终端节点（存储的用户和设备记录）、分群（动态受众）、活动（定时发送）、旅程（多步骤自动化编排器），以及追踪送达率、打开率和旅程互动的内置数据分析看板。
以另一个名字存活下来的，是底层的原始通道层。短信、语音、移动推送、一次性验证码（OTP）和号码校验，会继续通过 AWS End User Messaging 运行——这是 AWS 在 2024 年第三季度给 Pinpoint 通道 API 改的新名字。也就是说，如果你只是把 Pinpoint 当成一个”哑管道”——业务逻辑全在自己后端，调用 API 发一条交易类推送或短信——那你要处理的事情不多，重新指向新的 API 端点就行。
但如果你的团队是在 Pinpoint 控制台里搭建分群、活动和旅程，这套工作流就会断掉。在 AWS 内部重建它，才是真正费工夫的地方。
AWS 把你导向哪里，为什么不是一比一替代
AWS 自己的迁移指南没有给你一个替代品，而是给了 4 个，每种能力对应 1 个：
- 运营层（终端节点、分群、活动、旅程）→ Amazon Connect 外呼活动 + Customer Profiles
- 事件与移动数据分析 → Amazon Kinesis
- 邮件 → Amazon SES
- 短信、推送、语音、OTP → AWS End User Messaging
技术上仍然是同一个云厂商，但现在变成 4 个独立产品、4 个控制台、4 套文档，去顶替原来一套系统。对于没有专职平台工程团队的出海团队来说，这比”换一个工具”要重得多。
对移动团队而言，Amazon Connect 这个运营层落点才是真正麻烦的地方，一些坑要等你迁移到一半才会发现。
- 应用内消息在 Connect 里完全不存在。 AWS 官方文档白纸黑字把它列入”不支持的功能”。如果应用内引导流程、功能提示或付费墙是你 App 体验的一部分，推荐路径上没有它的原生落脚点。
- 推送不是 Connect 活动的原生通道。 推送（GCM/FCM、APNs、Baidu 等）在 Connect 的活动里不受原生支持。AWS 文档说你仍然可以发推送，但只能通过旅程，靠一个绑定 Connect 推送模板的 Lambda 动作来实现。实际操作意味着你要自己写代码、维护代码，才能复现 Pinpoint 原本开箱即用的能力。
- 自定义通道只支持一半场景。 它在旅程里可用，在活动里不可用。这是 Connect 留给你自己去补的又一个缺口。
- 模板引擎共用，语法不共用。 Connect 模板用的和 Pinpoint 一样的 Handlebars 渲染引擎，逻辑能复用，但属性占位符写法不同：在 Pinpoint 里写作
{{User.UserAttributes.PurchaseHistory}}的内容，到 Connect 里要写成{{Attributes.Customer.Attributes.PurchaseHistory}}。每一个模板都得手动取出来重写。 - 迁移终端节点是一项脚本工作。 为了迁移用户，AWS 让你先把一个无过滤条件的分群导出到 S3，再跑一个 Python 脚本把这些终端节点重塑成 Customer Profiles——单个档案最多只能挂 3 个邮箱和 4 个手机号。能用，但这是你要自己写、自己测、自己维护的代码。
这不代表 AWS 路径是错的。如果你本来就全面依赖 Connect 做呼叫中心业务，这条路可能正合适。但如果推送和应用内消息是你当初选 Pinpoint 的原因，官方推荐的迁移路径会把这两个通道原样甩给你的工程团队重建。这一点值得提前知道，而不是等 3 个 sprint 之后才发现。
四步把推送与应用内消息迁移到 Pushwoosh
Pushwoosh 是一个移动优先的出海推送平台：推送通知、应用内消息和 Web 推送是核心通道，原生支持 FCM 和 APNs，邮件和短信作为补充。与其把你的运营拆分到 4 个 AWS 服务里，不如一次性在一个地方重建。具体步骤如下：
-
导出 Pinpoint 数据
趁控制台还在，用 AWS 自己的 API 把终端节点、分群、活动和旅程定义拉出来。越接近截止日期，导出越难，无论你最终迁到哪里都用得上这份数据，越早做越好。
-
重新指向移动端 SDK
把 Pinpoint 或 Amplify SDK 换成 Pushwoosh SDK，确认设备注册和事件上报正常，再切换任何面向用户的功能。这一步让你的 App 重新连上一个活的消息后端。
-
重建分群与旅程
导入用户，把 Pinpoint 的属性映射到 Pushwoosh 的标签和分群模型，在可视化旅程编排器里重建自动化流程。这基本是对等工作：重新实现你已经懂的逻辑，而不是从零设计。这也正是在 Connect 路径下会落到你工程团队头上的那部分。
-
重新接入事件，再做试点
把自定义事件重新接好，让行为触发正常工作，先对小分群跑一次试点发送确认一致性，再切全量。给域名认证和发件人注册留出真实的日历时间，截止日期临近并不会让这些流程变快。
和 AWS 路径的差别，体现在那些容易被忽略的细节上。AWS 的指南要你写并运行一个 Python 脚本把终端节点重塑成 Customer Profiles，而 Pushwoosh 直接通过界面或 API 导入用户，不需要写脚本维护。Connect 要求你通过一个绑定 Lambda 的旅程来路由推送，而在 Pushwoosh 里推送只是一个可以直接选的通道。原本要在 AWS 那边预算的工程投入，大部分都省掉了。
迁移成本是多少
大多数迁移文章对价格都含糊其辞，这里直说。Pushwoosh 按月活跃用户数（MAU）计费——完整价格见定价页面——对于以推送和应用内消息为主的工作负载，入门门槛刻意压得很低：
- Push Only（纯推送）——每 1,000 MAU 7 美元。 如果推送和应用内消息就是你的全部需求，这个档位刚好匹配，不会为用不上的全渠道功能多付钱。
- Omnichannel（全渠道）——每 1,000 MAU 13 美元。 需要邮件、短信等更多渠道整合在一起时可以选择。
- Custom（定制）——每月 2,000 美元起。 面向更大发送量的阶梯定价、专属支持和企业条款。
对于主要是替换 Pinpoint 推送和应用内消息能力的团队，7 美元的入门价比直接签下一整套全渠道营销自动化平台的合同摩擦小得多——而这正是 Braze、Customer.io 和 Iterable 这一档产品会让你做的取舍。
不要拖到十月
迁移本身是一件确定的事：导出、重新指向、重建、测试。日历才是硬约束。2026 年 10 月 30 日是固定截止日期，而那些真正吃掉时间的环节——SDK 切换、事件映射、域名和发件人配置——不会因为日期临近就跑得更快。
你可以用免费的 1,000 MAU 额度拿真实数据先试：导入一个真实分群，重建一个旅程，跑一次试点发送，亲自看一遍效果对等再决定是否全量切换。见过太多迁移拖到最后才手忙脚乱的团队，我们的建议是：趁 Pinpoint 控制台还能导出数据，现在就对照自己的真实 MAU 和时间线做规划。把这件事拖到九月才动手的团队，往往是在停服前 3 周才发现问题。
