物联网的世界就像一座灯火通明的物流城市：几百万台传感器、摄像头、智能电表像一个个忙碌的寄件人，每天产生海量“快递”——这些快递就是设备上报的数据。如果没有一个统一的中转枢纽，每台设备都要自己找到收件人，整个城市就会交通瘫痪。AWS IoT Core 就是这座物联网城市的“全球物流中台”：它提供托管式的 MQTT 快递通道（消息代理）、一本随时可查的“寄存登记簿”（设备影子）、一套严格的“门禁安检”（认证与策略），还有一群自动分拣员（规则引擎），能把每一件“数据快递”准确送到 Lambda 函数、S3 存储等“处理车间”。这篇教程，我们就用快递物流的故事，把 AWS IoT Core 的架构讲明白。

岗位关联

理解 AWS IoT Core 是物联网工程师的必修课：它贯穿设备接入、消息路由、云端处理的完整链路，掌握它能让你从“只会写代码”进阶为“能设计物联网系统”。

目录
  1. 可视化演示
  2. IoT 平台全景
  3. MQTT 通信协议
  4. 设备影子
  5. 设备认证与策略
  6. 规则引擎
  7. 服务集成
  8. 多区域部署
  9. 安全基石
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示设备MQTT接入规则引擎SQL路由Lambda S3服务架构、设备影子reported desired状态同步、SELECT WHERE规则路由多目标及多区域设备就近接入跨区域复制数据流转，含粒子场背景动画。

本节配有交互动效（进入视口后自动加载，约 3KB）。

IoT 平台全景

一座城市如果同时有上万家快递公司各自跑腿，街面一定会乱成一锅粥。物联网也是同样的道理——路灯、水表、工厂的机械臂来自不同厂商，通信方式五花八门，如果让每一台设备都直接跟云端“各聊各的”，工程量将彻底失控。所以我们需要一个统一的中转站，把所有设备的“快递”汇聚起来统一调度。AWS IoT Core 就是这样一个角色。

在 AWS IoT 的语境里，接入平台的每台设备都有一个身份，叫作 Thing（事物）。你可以把 Thing 理解为“快递寄件人在中台的会员卡”，有了它，设备才能被识别、被管理。平台本身则负责接收设备通过 MQTT 等轻量协议发来的消息，让设备不用关心消息最终去向——这正是“托管式消息代理”的含义。

AWS IoT Core 的核心能力正是托管式 MQTT 代理（Broker）。它相当于物流中台里自动运转的传输带：设备把消息发布到某个“主题”（Topic），平台负责把消息推送给订阅了该主题的应用。整个过程无需自建服务器，AWS 帮你管理连接、负载和可用性。一个典型的 IoT 平台全景包含三层：设备层（Thing）、接入层（MQTT Broker）、业务层（规则引擎与云服务）。

有了 AWS IoT Core 这个“物流中台”，设备就像拿着统一会员卡的寄件人，无论来自哪家厂商、用哪种通信方式，都能把快递放进同一条传送带。你不再需要自建服务器来收发消息，只需专注处理快递内容——这就是平台的价值。

Throughput=NmsgΔt\text{Throughput} = \frac{N_{\text{msg}}}{\Delta t}
这条公式描述 IoT 平台每秒能处理多少条消息，也就是“物流中台的传送带运力”。
  1. 吞吐量左侧 $\text{Throughput}$ 表示平台每秒处理的消息条数，是衡量 IoT 中台运力的核心指标。
    Throughput=NmsgΔt\text{Throughput} = \frac{N_{\text{msg}}}{\Delta t}
  2. 消息计数分子 $N_{\text{msg}}$ 是统计窗口内的消息总数，分母 $\Delta t$ 是这组数据的时间跨度。
    Δt=tend−tstart\Delta t = t_{\text{end}} - t_{\text{start}}

MQTT 通信协议

快递要顺利流转，必须有一套大家都遵守的面单规则。MQTT 就是物联网世界的“快递面单规范”：它是一种极轻量的发布/订阅消息协议，专为带宽有限、电量宝贵的设备设计，在 AWS IoT Core 中扮演着设备与云端之间“标准快递通道”的角色。

在 MQTT 的世界里，设备不再直接告诉某台服务器自己的数据，而是把消息发布（Publish）到一个主题（Topic），比如 things/demo001/telemetry。对主题感兴趣的应用只需订阅（Subscribe）这个主题，就能收到所有发给它的消息。发布方和订阅方互不认识，就像寄件人不需要认识收件人一样。

AWS IoT Core 作为 MQTT Broker，还支持 QoS 等级、遗嘱消息（LWT）和持久会话。QoS 决定消息投递的可靠性：QoS 0 是“最多一次”，丢了就丢了；QoS 1 是“至少一次”，可能重复；QoS 2 是“恰好一次”，开销最大。设备通常用 QoS 0 或 1 上报遥测，用 QoS 1 下发控制指令。

有了统一的面单规则，任何设备都能把“快递”贴上主题标签丢进 AWS 的传送带；任何应用只要订阅了对应主题，就能稳定收到包裹。至于中间有几条传输带、会不会丢失，都由 AWS 的代理机制帮你兜底。

Stopic={d∣d∈Sub(t)}S_{\text{topic}} = \{ d \mid d \in \text{Sub}(t) \}
这表示“订阅了某个主题的设备集合”，平台每收到一条消息，就把它推给集合里所有设备，类似快递面单上的收件清单。
  1. 订阅集合$S_{\text{topic}}$ 表示订阅了主题 $t$ 的设备集合，平台收到发布消息后会向这个集合里所有设备推送副本。
    Stopic={d∣d∈Sub(t)}S_{\text{topic}} = \{ d \mid d \in \text{Sub}(t) \}
  2. 成员判断竖线右侧 $d \in \text{Sub}(t)$ 是筛选条件，含义是“设备 $d$ 出现在主题 $t$ 的订阅者名单中”。
    Sub(t)={d1,d2,…,dk}\text{Sub}(t) = \{ d_1, d_2, \dots, d_k \}

设备影子

快递员送货时常遇到收件人不在家的情况，小区里的快递柜就解决了这个问题——快递员把包裹存进柜子，收件人回家后再取。设备在物联网世界的“快递柜”，在 AWS IoT Core 中被称为设备影子（Device Shadow）。

设备影子本质上是 AWS 为每台设备维护的一份 JSON 文档，缓存设备的最新状态。它有两个关键字段：reported（设备实际上报的状态）和 desired（应用期望设备达到的状态）。设备离线时，应用写入的 desired 状态会被保存，等设备重新上线时，平台再把期望状态同步给它。

影子的价值在于解耦。应用不关心设备在不在线，只管读取或写入影子的 desired；设备也不关心应用怎么读取，只管上报 reported。这个模型天然适合“设置-执行-确认”的闭环。比如智能家居 App 调整空调温度：App 写入 desired: 26°C，空调上线后读到新目标并执行，再上报 reported: 26°C。整个过程中双方不需要同时在线。

设备影子就像每个寄件人的专属快递柜：即使收件人出差了，包裹也能先存进去；等收件人回到小区，柜门一开，消息一次性送达。这套“先寄存再同步”的机制，是设备经常离线、网络不稳定的物联网场景中最重要的设计之一。

Sshadow={reported,desired,metadata}S_{\text{shadow}} = \{ \text{reported}, \text{desired}, \text{metadata} \}
一个影子文档由“实际状态、期望状态、元数据”三部分组成，相当于快递柜里同时记录了包裹位置、取件要求和存取时间。
  1. 影子文档$S_{\text{shadow}}$ 指设备影子的完整状态，大括号表示由多个字段组成的 JSON 文档。
    Sshadow={reported,desired,metadata}S_{\text{shadow}} = \{ \text{reported}, \text{desired}, \text{metadata} \}
  2. 字段含义reported 记录设备“实际在哪”，desired 记录应用“要它去哪”，metadata 保存每个字段的更新时间戳。
    reported={temp:26},desired={temp:26}\text{reported} = \{ \text{temp}: 26 \}, \quad \text{desired} = \{ \text{temp}: 26 \}

设备认证与策略

物流中台不是随便什么人都能进出的，每个快递员都有一张门禁卡和一套授权范围——只能进自己负责的分区，不能进入财务室。AWS IoT Core 用同样的思路管理设备。

你首先需要在 AWS IoT Core 中创建 Thing，这相当于给设备建一份“员工档案”。然后为它签发 X.509 证书（门禁卡），最后配置 IoT 策略（Policy），规定这张证书能对哪些主题执行哪些操作。三个环节缺一不可：没有 Thing，设备没有身份；没有证书，设备无法证明身份；没有策略，设备即使能连接也无法收发消息。

AWS IoT 的策略以 JSON 格式编写，核心是 Effect（Allow/Deny）、Action（iot:Connect、iot:Publish 等）和 Resource（主题 ARN）。策略支持通配符，但出于安全考虑，应尽量把 Resource 限定到具体设备的前缀，例如 arn:aws:iot:...:topic/things/demo001/*。生产环境还应启用自定义认证或 Amazon Cognito，满足多样化的身份体系。

每台设备拿着专属“门禁卡”进出物流中台，刷卡后只能进入自己授权的那几条传送带，既不能偷看别人的快递，也不能向无关仓库塞货。认证与策略这套组合拳，保证了“快递”不会被人冒领。

Access(op,res)={1,if ∃p:pAllow(op,res)0,otherwise\text{Access}(op, res) = \begin{cases} 1, & \text{if } \exists p: p_{\text{Allow}}(op, res) \\ 0, & \text{otherwise} \end{cases}
访问是否放行，取决于是否存在一条策略允许该操作。默认拒绝是 IoT 安全的第一原则，相当于没有门禁卡就进不了园区。
  1. 权限判定函数$\text{Access}(op, res)$ 表示对操作 $op$、资源 $res$ 的访问最终是否放行，返回 1 表示允许，0 表示拒绝。
    Access(op,res)={1,if ∃p:pAllow(op,res)0,otherwise\text{Access}(op, res) = \begin{cases} 1, & \text{if } \exists p: p_{\text{Allow}}(op, res) \\ 0, & \text{otherwise} \end{cases}
  2. 存在性检查$\exists p: p_{\text{Allow}}(op, res)$ 表示“存在一条策略 $p$ 明确允许该操作”时才放行，这与“默认拒绝”的安全准则一致。
    pAllow(op,res)  ⟺  policy allows op on resp_{\text{Allow}}(op, res) \iff \text{policy allows } op \text{ on } res

规则引擎

快递送到中台后，分拣员要根据面单上的目的地，把包裹送上正确的运输带。AWS IoT Core 的规则引擎就是一群不知疲倦的“自动分拣员”。

规则引擎允许你用一条类似 SQL 的语句，对 MQTT 消息做筛选和转换，然后把符合条件的消息转发到 AWS 其他服务。比如筛选温度大于 60°C 的传感器报警消息，再转发给 Lambda 函数处理——这就是“数据流转”。

一条规则由 SELECT（选取字段）、FROM（监听的主题）、WHERE（过滤条件）和 Action（转发目标）组成。例如：

这条规则监听所有设备上报的遥测消息，只让温度超过 60°C 的消息继续流向动作目标（如 Lambda、S3）。规则引擎还支持函数调用（如 avg()、json()）和嵌套字段提取，但复杂计算应交给下游专业服务，它更适合做轻量分拣而不是重计算。

有了自动分拣员，设备产生的每一条消息都会被快速检视一遍，该去报警中心的去报警中心，该去仓库的去仓库。你不需要写复杂代码去轮询消息队列，一条 SQL 就完成了数据路由。

Result=πcols(σcondition(Msg))\text{Result} = \pi_{\text{cols}} \left( \sigma_{\text{condition}} (\text{Msg}) \right)
规则引擎的本质是“先过滤、再投影”，就像分拣员先看面单是否符合要求，再决定把包裹放到哪条运输带。
  1. 选择字段$\pi_{\text{cols}}$ 对应 SQL 中的 SELECT，从原始消息中投影出我们关心的列，比如温度和设备号。
    πcols(Msg)→{temp,id}\pi_{\text{cols}}(\text{Msg}) \to \{ \text{temp}, \text{id} \}
  2. 过滤条件$\sigma_{\text{condition}}$ 对应 SQL 中的 WHERE，只有满足条件的消息才能继续流转，比如温度大于 60。
    σtemp>60(Msg)⊆Msg\sigma_{\text{temp} > 60}(\text{Msg}) \subseteq \text{Msg}
sql1 行
SELECT temperature, device_id FROM 'things/+/telemetry' WHERE temperature > 60

服务集成

快递经过分拣后，有的被送往客服中心，有的被送进仓库堆存，还有的被送去财务系统记账。AWS IoT Core 的规则引擎同样可以把数据快递送到下游的各类 AWS 服务。

最常见的集成是“规则引擎 + Lambda + S3”：规则引擎把符合条件的消息转发给 Lambda 函数，Lambda 在事件驱动下执行业务逻辑，例如解析消息、计算告警、写入数据库；原始或处理后的数据则落到 S3 存储桶，用于长期归档和数据分析。你还可以把数据流转到 DynamoDB 做键值存储，或写入 Kinesis 做实时流处理。

这种“接入-路由-处理-存储”的管道是 serverless 架构的典型用法。AWS IoT Core 负责设备接入和消息路由，Lambda 负责无服务器计算，S3 负责低成本持久化，DynamoDB 负责低延迟查询。开发者无需管理任何服务器，只需把服务像乐高积木一样拼起来。要注意的是，规则引擎在转发失败时支持重试，但需要配置错误处理动作（如把失败消息写入 S3）避免数据丢失。

规则引擎是分拣员，Lambda 是客服专员，S3 是仓库管理员——整个快递处理链各司其职。你在 AWS 控制台里把它们串联起来，一条完整的物联网数据流水线就诞生了。

Device→MQTTIoT Core→ruleLambda→writeS3\text{Device} \xrightarrow{\text{MQTT}} \text{IoT Core} \xrightarrow{\text{rule}} \text{Lambda} \xrightarrow{\text{write}} \text{S3}
这条链路描述了数据从设备出发，经过中台、处理车间，最终归档入库的完整旅程。
  1. 设备上报设备通过 MQTT 协议把遥测消息发布到 IoT Core 的主题，进入物流中台。
    Device→MQTTIoT Core\text{Device} \xrightarrow{\text{MQTT}} \text{IoT Core}
  2. 路由转发规则引擎把符合条件的数据转发给 Lambda 函数，并携带原始消息上下文。
    IoT Core→ruleLambda\text{IoT Core} \xrightarrow{\text{rule}} \text{Lambda}
  3. 落盘存储Lambda 完成计算后把结果写入 S3，形成可追溯的数据资产。
    Lambda→writeS3\text{Lambda} \xrightarrow{\text{write}} \text{S3}

多区域部署

一家全国连锁的快递公司，如果在每个城市都有分拨中心，包裹就不必都绕到总部。AWS 在全球有数十个区域（Region），IoT 平台天然可以采用“就近接入”的多区域架构。

在多区域部署中，每个区域都部署一套 AWS IoT Core 及配套服务，设备接入距离自己最近的区域，从而降低网络延迟、提升容灾能力。比如部署在德国的设备连接法兰克福区域，部署在日本的设备连接东京区域。这就像快递包裹进入城市本地的分拨中心，而不是绕到地球另一端。

多区域架构的关键设计点有三个：一是设备注册表的区域隔离，Thing 属于某个区域，设备连接时要指定对应区域的终端节点（Endpoint）；二是状态同步，设备影子和数据在不同区域之间可以通过跨区域复制（如 S3 跨区域复制、DynamoDB 全局表）汇聚；三是设备迁移策略，当设备物理位置变化或某区域访问异常时，需要通过域名解析或配置下发引导设备切换到新的区域端点。

全球布局的分拨中心让每个包裹都走最近的路，IoT 平台的区域部署也是同样逻辑：就近接入降低延迟，多区域冗余提高可用性。架构师的任务，就是为你的设备规划一张“全球物流地图”。

RTTbest=min⁡r∈Regions(RTTr)RTT_{\text{best}} = \min_{r \in \text{Regions}} \left( RTT_r \right)
多区域部署追求的目标，是让每台设备都能选到网络延迟最小的“最近分拨中心”。
  1. 最优延迟$RTT_{\text{best}}$ 表示设备选路后的最优往返延迟，目标是让每个设备都获得最小的网络等待。
    RTTbest=min⁡r∈Regions(RTTr)RTT_{\text{best}} = \min_{r \in \text{Regions}} \left( RTT_r \right)
  2. 候选区域$\text{Regions}$ 是可选区域集合，$RTT_r$ 是设备到区域 $r$ 的实测往返时间，通常结合 DNS 路由和配置下发决定最终选择。
    r=arg⁡min⁡kRTTk,k∈Regionsr = \arg\min_k RTT_k, \quad k \in \text{Regions}

安全基石

押运快递的装甲车如果只是一辆普通面包车，途中被拦截就麻烦了。AWS IoT Core 把安全贯穿在每一层，从传输通道到访问权限再到审计监控，构成一套纵深防御体系。

首先是传输加密：设备与平台之间必须通过 TLS 加密连接，避免消息在路上被窃听——这相当于给快递运输车加装装甲。其次是设备隔离：每台设备使用独立的证书和策略，默认只能访问自己的主题，一台设备被攻破也不会影响整个系统。最后是审计监控：AWS CloudTrail 和 CloudWatch 可以记录设备的连接、发布、策略变更等事件，供安全分析使用。

安全设计中最容易忽略的是“最小权限原则”。给设备签发策略时，应只授予它完成业务所必需的操作和主题范围。例如，温控器只需要发布 things/tc001/telemetry 和订阅 things/tc001/commands，就不应授予它删除 IoT 策略的权限。生产环境还应该定期轮换证书、启用 IoT 策略变量（iot:Connection.Thing），并对异常连接行为设置告警。

每台设备都开着装甲车、拿着限定区域的门禁卡，护送自己的快递安全抵达目的地。安全不是功能列表上的一个勾选框，而是从身份、通道、权限到审计的层层设防。

Pgranted=⋂i=1nPrequired(i)P_{\text{granted}} = \bigcap_{i=1}^{n} P_{\text{required}}^{(i)}
最终授权的权限集合，等于所有业务最小需求权限的交集——只给“够用”的那部分权限，绝不多给。
  1. 交集授权$P_{\text{granted}}$ 表示最终实际被授予的权限集合，是多个必需权限集合的交集，即“只给必要项”。
    Pgranted=⋂i=1nPrequired(i)P_{\text{granted}} = \bigcap_{i=1}^{n} P_{\text{required}}^{(i)}
  2. 必要权限$P_{\text{required}}^{(i)}$ 是第 $i$ 个业务操作的最小权限需求，交集运算确保权限不会超过任何一项业务的实际所需。
    Prequired(i)={iot:Publish on topic i}P_{\text{required}}^{(i)} = \{ \text{iot:Publish on topic } i \}

AI 应用场景

工业设备预测性维护

阶段：数据接入与特征工程

解决的问题：工厂设备每天产生大量传感器数据，传统方式依赖人工巡检，无法及时发现异常。通过 AWS IoT Core 接入设备、规则引擎实时筛选异常特征、Lambda 触发已训练好的预测模型，把“被动维修”变成“主动维护”。

具体案例：某工厂在 200 台注塑机上安装温度、振动传感器，MQTT 消息通过 IoT Core 进入规则引擎，当温度超过阈值时触发 Lambda 调用预测模型，结果写入 S3 并推送工单告警。

车联网远程诊断

阶段：状态同步与数据闭环

解决的问题：车辆在移动网络下经常离线，传统方式难以保证指令可靠下发。借助 IoT Core 的设备影子，车企 App 可以随时写入“需要执行的诊断指令”，车辆重新上线后自动获取并执行，再把结果写回影子，形成闭环。

具体案例：某新能源车企为每辆车创建 Thing，App 下发“预热电池”指令到影子 desired，车辆启动后读取并执行，reported 上报执行状态，全程无需车辆在线。

Python 演示

python49 行
import paho.mqtt.client as mqttimport jsonimport timeimport random shadow = {    "state": {        "reported": {"temperature": 25.0},        "desired": {"temperature": 25.0}    }} def on_connect(client, userdata, flags, rc):    if rc == 0:        print("设备已接入 IoT Core")        client.subscribe("things/demo001/shadow/update")    else:        print("连接失败，错误码：", rc) def on_message(client, userdata, msg):    payload = json.loads(msg.payload.decode())    desired = payload.get("state", {}).get("desired", {})    shadow["state"]["desired"].update(desired)    shadow["state"]["reported"].update(desired)    report = json.dumps({"state": {"reported": shadow["state"]["reported"]}})    client.publish("things/demo001/shadow/report", report)    print("已执行云端指令：", desired) def publish_telemetry(client):    temp = round(random.uniform(20.0, 30.0), 2)    humidity = round(random.uniform(40.0, 70.0), 2)    telemetry = json.dumps({"temperature": temp, "humidity": humidity})    client.publish("things/demo001/telemetry", telemetry)    print("上报遥测数据：", telemetry) client = mqtt.Client(client_id="demo001")client.on_connect = on_connectclient.on_message = on_messageclient.connect("localhost", 1883, 60)client.loop_start() try:    while True:        publish_telemetry(client)        time.sleep(3)except KeyboardInterrupt:    print("设备下线")    client.disconnect()    client.loop_stop()
目的：用 paho-mqtt 模拟一台接入 AWS IoT Core 风格的设备，演示 MQTT 发布/订阅订阅模型，以及设备影子的 desired/reported 状态同步闭环。
  1. client.subscribe("things/demo001/shadow/update")订阅影子更新主题，云端下发指令时触发回调。
  2. payload.get("state", {}).get("desired", {})从影子 JSON 中提取云端期望状态，类似快递柜里取出的“新包裹”。
  3. shadow["state"]["reported"].update(desired)把云端期望同步到设备实际状态，模拟设备执行指令。
  4. client.publish("things/demo001/telemetry", telemetry)发布遥测数据，对应设备上报温度湿度给 IoT Core。
  5. client.loop_start()启动后台网络循环，让 MQTT 收发在后台不断处理。

常见误区

误区初学者以为 AWS IoT Core 只支持 MQTT，实际上除了 MQTT，它还支持 HTTPS、WebSocket 和 LoRaWAN 等多种协议接入。

正解AWS IoT Core 是“以 MQTT 为核心但不止 MQTT”的多协议平台。MQTT 适合低功耗、低带宽场景；HTTPS 适合一次性上报的场景，比如设备很少通信；WebSocket 与 MQTT-over-WebSocket 适合浏览器端应用；LoRaWAN 用于远距离低功耗无线设备。选协议要看设备能力和业务需要，就像寄包裹有时选快递、有时选航空件。

为何常见：教程和示例代码大多展示 MQTT，且“托管式 MQTT 代理”是产品的核心卖点，导致学习者误以为它是唯一协议。

误区有人以为影子存储的 `reported` 状态是实时的、和真实值完全一致，于是把它当成高速缓存或数据库来设计业务。

正解设备影子本质是“设备状态的一份快照缓存”，只有设备主动上报 reported 或应用写入 desired 时才会更新。它不保证实时性，也不提供查询历史状态的能力。影子设计的初衷是解耦离线/在线，适合配置下发和状态回执，不适合作为事件日志或实时队列。

为何常见：“影子”这个词容易让人联想到“镜像”“实时副本”，加上 AWS 文档常描述影子能“在线/离线统一读取”，初学者自然会往实时数据库方向理解。

误区规则引擎的 SQL 语法让初学者误以为它能像数据库一样做聚合、联表、复杂窗口计算。

正解规则引擎的 SQL 本质是一条“过滤-投影-转发”管道，通常一条规则只针对一条消息做处理，没有数据库的多表关联能力。虽然支持 avg() 等函数，但规则引擎应专注于轻量分拣和路由。真正需要复杂分析时，应该把数据转发到 Lambda、Athena 或 Kinesis Analytics 等专门的计算服务。

为何常见：因为规则引擎确实用 SQL 语法，且支持函数和 WHERE 条件，初学者容易把“长得像 SQL”理解为“功能像数据库”。

误区许多开发者创建证书后以为可以一直用下去，忽略了证书过期、泄露或权限扩散的风险。

正解X.509 证书有有效期，且 AWS 支持证书吊销；生产环境应该建立证书轮换机制。更安全的做法是为设备启用自定义认证，或用 IoT 策略绑定设备身份（iot:Connection.Thing），让证书与具体设备绑定，防止一张证书被多台设备共用。审计日志要持续监控异常连接。

为何常见：本地开发时证书长期有效、调试顺利，加上 AWS 免费层不会主动提醒替换，让开发者放松了警惕。

面试题

Q1. AWS IoT Core 设备接入的核心协议是？

单选题 · easy

  • A.HTTP 与 FTP 协议
  • B.MQTT 与 HTTPS 协议← 正确答案
  • C.SMTP 与 SNMP 协议
  • D.WebRTC 与 SSH 协议

答案：B。AWS IoT Core 的托管代理核心是 MQTT Broker，同时兼容 HTTPS。就像快递中台的主干路线是公路运输（MQTT），也支持少数航空件（HTTPS）。FTP、SMTP、SSH 等都不是物联网设备接入的主流协议。

Q2. 设备影子在设备离线时的主要作用是？

单选题 · easy

  • A.自动删除全部历史状态
  • B.缓存状态并在恢复后同步← 正确答案
  • C.持续向平台上报实时数据
  • D.替代设备执行全部计算逻辑

答案：B。设备影子像快递柜，设备离线时先把状态缓存起来，重新上线后再同步。它不会删除历史数据，也不会替设备做计算，更不可能在离线时继续上报实时数据。

Q3. 规则引擎使用什么语言筛选转发消息？

单选题 · mid

  • A.Python 脚本语言
  • B.SQL 类查询语法← 正确答案
  • C.JavaScript 表达式
  • D.Shell 命令行语法

答案：B。规则引擎使用类似 SQL 的语法（SELECT/FROM/WHERE）来做消息的过滤和字段提取。这不是 Python 或 Shell，规则引擎也不提供通用编程能力。

Q4. 在 AWS IoT 中创建 Thing 的首要目的是？

单选题 · mid

  • A.为每台设备分配唯一身份← 正确答案
  • B.为设备建立数据库存储索引
  • C.为云端设置计费还款账户
  • D.为平台生成图形化运营报表

答案：A。Thing 是 AWS IoT 中设备的身份档案，相当于物流中台的会员卡。它让每台设备有唯一可识别的名字，便于后续关联证书、策略和影子。它不负责存储索引、计费或报表。

Q5. MQTT 的 QoS 等级 1 保证消息？

单选题 · mid

  • A.最多被成功送达一次
  • B.至少被成功送达一次← 正确答案
  • C.恰好被成功送达一次
  • D.一定会被即时处理完成

答案：B。QoS 1 是“至少一次”，消息可能重复但不会丢失；QoS 0 是“最多一次”，可能丢；QoS 2 才是“恰好一次”。就像快递可能送两次上门，但不会丢件。

Q6. IoT 设备策略应遵循的根本原则是？

单选题 · hard

  • A.默认开放所有操作权限
  • B.按照最小权限原则授权← 正确答案
  • C.将权限全部绑定到网络 IP
  • D.所有设备使用同一个共享密钥

答案：B。最小权限原则要求每台设备只拥有完成业务所必需的操作和主题范围。默认开放或共享密钥会让一台设备被攻破时影响全局。IP 绑定不适合移动设备，共享密钥更违背设备隔离理念。

Q7. 设备影子文档中 "desired" 字段的含义是？

单选题 · extreme

  • A.应用期望设备达到的目标状态← 正确答案
  • B.设备实际上报运行的当前状态
  • C.设备历史记录中的完整操作日志
  • D.云端系统分配给设备的唯一标识

答案：A。desired 是应用希望设备达到的目标状态，reported 才是设备实际状态。影子文档把这两个字段分开，让应用和设备不必同时在线也能完成配置闭环。

Q8. MQTT 协议具备哪些核心特点？

多选题 · mid

  • A.轻量级适合嵌入式设备← 正确答案
  • B.基于发布订阅双向消息模型← 正确答案
  • C.要求高带宽低延迟大流量网速
  • D.支持带宽低时可靠网络通信← 正确答案

答案：ABD。MQTT 是专为低带宽、弱网络设计的轻量协议，基于发布/订阅模型，能在资源受限设备上运行。它恰恰是为了在低带宽下可靠通信，而不是要求高带宽。

Q9. 规则引擎可以将消息转发到哪些 AWS 服务？

多选题 · hard

  • A.Lambda 无服务器函数← 正确答案
  • B.S3 对象存储服务← 正确答案
  • C.DynamoDB 键值数据库← 正确答案
  • D.EC2 弹性计算云

答案：ABC。规则引擎的常见转发目标包括 Lambda、S3、DynamoDB、Kinesis 等托管服务。EC2 虽然也是 AWS 服务，但作为虚拟机需要自行运维，并不是规则引擎直接对接的典型目标。

Q10. 多区域部署 IoT 平台能带来哪些收益？

多选题 · hard

  • A.降低设备接入的网络延迟← 正确答案
  • B.提升整体系统的可用性← 正确答案
  • C.自动修改设备端的固件逻辑
  • D.减轻单区域故障造成的影响← 正确答案

答案：ABD。多区域让设备就近接入，降低延迟；多个区域互为冗余，单区域故障时其他区域仍可服务。但它不会自动修改设备固件逻辑，那需要在设备端做配置管理。