在上一篇《从 HTTP 轮询到 MQTT》中，我们成功搭建了一个基于 AWS IoT Core 的 PoC 架构，验证了 MQTT 通信的可行性。但那只是万里长征的第一步。一个"能用"的 PoC 和一个"好用"的生产环境之间，还隔着网络安全、全球访问延迟、以及最重要的------成本的鸿沟。
这篇文章，我们就来一起走完这'最后一公里'。我们将把 PoC 架构一步步演进为稳健的生产级架构，并深入探讨在功能日益强大的同时，如何精打细算，将每一分钱都花在刀刃上，实现功能与成本的双赢。
本文核心 (TL;DR)
- 架构演进四步曲 ：通过引入 VPC 与 EKS 实现安全隔离和容器化，利用 Global Accelerator 优化全球访问，最后借助 VPC Endpoint 将内部流量私有化，构建了一个安全、高效、高可用的生产级架构。
- 成本优化三大战役 ：
- 优化规则触发：合并监听同一 Topic 的规则，避免重复计费。
- 优化动作执行：精简规则后续动作，剔除非必要流程。
- 优化消息成本 ：善用几乎免费的 Basic Ingest 处理单向数据上报，釜底抽薪。
第一部分：架构的进化 ------ 从"能用"到"好用"
这个部分的核心是"问题驱动"，每引入一个新组件都是为了解决一个具体问题。
第一部分：架构的进化 ------ 从"能用"到"好用"
第一步：构建网络隔离与服务容器化
问题： 最初的 PoC (Proof of Concept) 架构将服务直接部署在公网上，缺乏必要的网络隔离，这在生产环境中带来了极大的安全风险。任何未经授权的访问都可能直接威胁到核心服务。
解决方案： 为了解决安全和管理上的挑战，我们采用了两项关键技术：VPC (Virtual Private Cloud) 和 EKS (Elastic Kubernetes Service)。
- VPC：我们首先创建了一个私有网络环境，将所有服务资源收归其中。通过配置精细化的安全组（Security Groups）和网络访问控制列表（NACLs），我们得以严格控制进出 VPC 的流量，仅放行来自可信源的请求，从而建立起第一道安全防线。
- EKS：我们将服务部署到 AWS 的托管 Kubernetes 服务 EKS 中。这不仅实现了服务的容器化部署，提高了部署效率和可伸缩性，也使得服务管理更加规范和自动化。
通过这两项改进，我们为服务构建了一个安全、隔离且易于管理的运行环境。
第二步：优化全球访问延迟
问题： 随着业务扩展至全球，我们收到了大量来自海外用户的反馈，普遍反映访问延迟高，服务响应慢。根本原因在于我们的服务部署在单一地理区域（Region），跨国网络传输距离长、链路复杂，导致了显著的性能瓶颈。
解决方案： 为应对跨地域网络延迟的挑战，我们引入了 AWS Global Accelerator。它通过 AWS 的全球骨干网络和边缘站点（Edge Locations）来优化流量路径。当用户发起请求时，流量会从距离用户最近的边缘站点进入 AWS 网络，然后通过低延迟、高可用的骨干网传输到我们的应用端点。这种方式有效绕过了拥堵的公共互联网，显著降低了数据传输时间，为全球用户提供了稳定、低延迟的访问体验。
第三步：实现内部流量私有化，降低成本与风险
问题背景：理解AWS的服务模型
在深入探讨具体问题之前，我们有必要先理解AWS中两种主要的服务部署模型：
- 用户VPC内部署的服务：例如我们部署在EKS上的EMQX集群。这些服务运行在我们自己创建和管理的虚拟私有云（VPC）中，其网络边界和访问策略由我们直接控制。
- AWS托管服务：例如AWS IoT Core、S3、DynamoDB等。这些服务由AWS在其庞大的基础设施上统一管理和运维，它们位于AWS的服务网络中，天然地存在于用户的VPC之外。
正是这种架构上的分离，导致了一个看似不合理但符合逻辑的现象：即使用户的VPC和AWS托管服务位于同一区域，它们之间的通信默认也需要通过公共互联网的端点进行。
问题：隐藏的成本与风险
基于以上背景，我们再来审视架构，便会发现一个隐藏的问题：位于EKS中的后端服务与AWS IoT Core之间的通信，正在通过公共互联网进行。这带来了两个直接的负面影响：
- 成本增加：数据离开VPC流向公共互联网会产生NAT网关费用和数据传出费用。对于物联网场景下海量的数据交互，这是一笔不小的开销。
- 安全风险：尽管流量经过加密，但将内部服务间的通信暴露在公共网络上，始终增加了攻击面，带来了潜在的安全隐患。
解决方案：使用VPC Endpoint建立私有连接
解决这个问题的关键是使用VPC Endpoint。它允许在用户的VPC和支持的AWS服务之间创建一个私有的、不经由公共互联网的连接。我们为IoT Core创建了一个接口类型的VPC Endpoint（Interface Endpoint），它会在我们的VPC内创建一个弹性网络接口（ENI），作为访问IoT Core服务的私有入口。
这样一来，EKS中的服务就可以通过这个私有入口直接访问IoT Core的API，所有通信流量都被严格限制在AWS的内部网络中。这不仅彻底消除了公网暴露的风险，也显著节省了相关的网络费用。
第二部分：成本优化三大战役
架构的稳定只是基础，在当前降本增效的大背景下，如何将每一分钱都花在刀刃上，是衡量一个系统是否"好用"的另一个关键指标。AWS IoT Core 的定价模型虽然灵活，但也暗藏着不少成本陷阱。如果使用不当，账单可能会像滚雪球一样，在不经意间就变得触目惊心。
在进入正题之前，让我们先通过一张真实的收费项，直观地感受一下 IoT 成本的主要构成。
从图中可以看到，Rules Triggered（规则触发）、Action Executed（动作执行）和 Messages（消息）是成本的三大巨头。因此，我们的优化战役，将围绕这三者展开。
战役一：规则触发（Rules Triggered）优化 ------ 精准打击，避免"火力浪费"
战场分析：
在 IoT Core 的世界里，"规则 (Rule)" 就像是自动化的哨兵，时刻监控着指定的 Topic。一旦有消息抵达，哨兵就会立刻"拉响警报"，触发一次计费。问题在于，如果我们部署了多个哨兵（规则）监听同一个阵地（Topic），那么一次敌情（消息）就会导致所有哨兵同时开火，造成巨大的"弹药"浪费。
实战案例：多环境下的重复计费陷阱
我们曾犯过这样的错误。为了在同一个 AWS 账号下区分开发、测试、生产等多个环境，我们为设备上下线事件的 Topic ($aws/events/presence/connected) 配置了三条功能完全相同、只是后续动作（Action）不同的规则。
这导致的结果是：任何一个环境的设备上线，都会同时触发三条规则，Rules Triggered 的费用直接翻了三倍！
作战方案：合并同类项，集中火力
解决方案的核心思想是：避免让多个规则监听同一个事件源。
- 最佳实践：环境隔离。最彻底的解决方案是通过拆分 AWS 账号，从物理上隔离不同环境，釜底抽薪。
- 折中方案：合并规则。如果必须在单账号下管理多环境，则应将多个功能类似的规则合并为一个，利用规则内的条件判断或将消息转发到统一的后端服务进行分发，从而确保一次事件只触发一次规则。
战役二：动作执行（Action Executed）优化 ------ 优化流程，减少"无效劳动"
战场分析：
"动作 (Action)"是规则被触发后的具体执行步骤。它同样按次计费。在上面那个"火力浪费"的案例中，既然规则被触发了三次，那么与之关联的动作自然也执行了三次，成本再次乘以三。
作战方案：保留核心，剔除冗余
Action Executed 的优化与 Rules Triggered 息息相关。一旦我们通过合并规则解决了"火力浪费"的问题，这部分的成本自然也就应声而落。优化的核心在于，仔细审视你的每一个 Action，确保它们都是业务流程中不可或缺的一环，剔除所有不必要的"无效劳动"。
战役三：消息（Messages）成本优化 ------ 釜底抽薪，善用"秘密通道"
战场分析：
消息成本是 IoT Core 中最核心、也最容易被忽视的成本来源。它就像是战场上的"军粮"，无时无刻不在消耗。常规的 MQTT 消息，需要经过 Message Broker 的路由和分发，每一次投递都会产生费用。
作战方案：启用 Basic Ingest，绕过"中间商"
AWS 提供了一个简单而强大的"秘密武器"------ Basic Ingest。
你可以把它理解为一条直达目的地的"秘密通道"。通过特定的 Topic 格式 ($aws/rules/rule-name)，设备可以将消息直接发送给指定的规则，完全绕过 Message Broker 的处理。
这就意味着，这部分消息的传输和处理，几乎是"免费"的！
适用场景：
Basic Ingest 特别适用于那些"只进不出"的单向数据上报场景，例如设备遥测数据、日志上报等。对于这些数据，我们只关心最终能否落到数据库或进行分析，而不需要 Broker 进行复杂的订阅与分发。
局限性：
需要注意的是，Basic Ingest 是一条"单行道"，它只能用于设备向云端推送数据。对于需要订阅消息或从云端向设备下发指令的双向通信场景，我们依然需要依赖传统的 MQTT 消息机制。此时，成本优化的重点就回到了合理设计 Topic 结构、控制消息的发送频率和 Payload 大小上。
总结：没有完美的架构，只有持续进化的系统
从最初基于 HTTP 轮询的简陋设计，到拥抱 VPC、EKS 和 Global Accelerator 构建起的全球化、高可用的 MQTT 网络；从"野蛮生长"带来的高昂账单，到通过"三大战役"对成本进行精细化控制------这趟旅程不仅是一次技术架构的升级，更是一场关于"取舍"与"平衡"的深度实践。
回望这条路，我们可以提炼出几个核心的经验：
- 安全与隔离是架构的基石：在系统设计之初，就应通过 VPC 等手段建立起稳固的"护城河"，这不仅关乎安全，也为后续的性能优化和成本控制打下基础。
- 善用云的原生能力：无论是 Global Accelerator 带来的全球加速，还是 Basic Ingest 提供的成本"秘密通道"，云平台本身已经为我们准备了大量的"武器"。深入理解并善用它们，往往能起到事半功倍的效果。
- 成本是设计的一部分：将成本意识贯穿于架构设计、功能开发和后期运维的全过程。每一次规则的创建、每一次消息的发送，都应在成本的天平上进行掂量。
当然，技术的世界里没有终点。我们的系统今天看似稳定，但明天可能就会因为业务的增长、技术的发展而面临新的挑战。或许我们可以进一步思考：
- 当设备规模从十万级跃升到百万级、千万级时，当前的架构是否依然适用？
- 除了文中提到的优化点，在你的业务场景中，是否还隐藏着其他的"成本刺客"？
- 面向未来，我们是否可以引入 AIoT 的能力，让设备和系统变得更加"智能"，从而在更高维度上实现效率和成本的平衡？
希望我们的这段探索之旅，能为您在构建自己的物联网应用时，提供一些有价值的参考和启发。
欢迎关注公众号：此方的手帐
参考资料
- 从 HTTP 轮询到 MQTT：我们在 AWS IoT Core 上的架构演进与实战复盘
- AWS IoT Core Pricing - AWS IoT Core 官方定价页面，包含了连接、消息、规则引擎等所有计费项的详细说明。
- Rules for AWS IoT - AWS IoT 规则引擎的官方文档，详细介绍了其工作原理和能力。
- AWS IoT rule actions - 官方文档，列出了规则引擎支持的所有目标动作（Actions）。