2026 AWS 国际版物联网 IoT 全家桶实战教程：IoT Core 从 0 接入、免费套餐额度与六项计费避坑指南

Meta Description: 讲透 AWS 国际版物联网全家桶：IoT Core 从 0 接入、Greengrass 边缘部署、设备影子与规则引擎实战，六大服务真实单价与免费套餐额度复算，附 IoT Analytics、IoT Events、FleetWise 停服排雷表。

30 秒结论：如果你要在 AWS 国际版上做物联网，2026 年的最小可用组合是 IoT Core（接入）+ Device Defender（安全）+ Device Management（运维） 三件套，边缘侧按需加 Greengrass，工业/可视化场景才上 SiteWise + TwinMaker。IoT Core 本身有 12 个月的免费套餐（225 万分钟连接、50 万条消息），跑通一个 50 台设备的小项目基本可以做到前几个月 $0；真正的钱不在接入，而在按 5KB 分档的消息计量和按月计费的边缘软件包上。

决策口诀：接入用 Core、边缘用 Greengrass、安全用 Defender、运维用 Management、工业数据用 SiteWise、可视化用 TwinMaker；先看生命周期表，再动手写代码 —— 别照着 2023 年的老教程去开通 IoT Analytics 和 IoT Events，这两个服务已经宣布停止支持。

关键词：AWS IoT、AWS IoT Core、AWS IoT Greengrass、AWS IoT SiteWise、AWS IoT TwinMaker、AWS IoT Device Defender、AWS IoT Device Management、MQTT、设备影子、物联网平台、免费套餐、AWS 国际版

一、结论先行：2026 年 AWS 物联网全家桶该用哪几个服务

AWS IoT 不是一个服务，而是十几个服务的集合。新手最容易踩的坑，是把"IoT Core" 当成"IoT 全部"，等到要批量升级固件、要查设备在线率、要做产线看板时，才发现手里缺了一半的拼图。下面这张表是本文的骨架，后面每一节都是它对某个单元格的展开。

一句话选型：先 Core，再 Defender + Management，边缘有需求才 Greengrass，最后才考虑 SiteWise / TwinMaker。顺序反了，钱会花在还没用起来的高级功能上。

二、先排雷：AWS IoT 家族里哪些服务已经停服或停止对新客户开放

这是本文最重要的一节。物联网类教程的生命周期很长，网上大量内容写于 2022–2023 年，那些文章里教你去开通 IoT Analytics 做数据管道、用 IoT Events 做告警联动的步骤，在 2026 年已经跑不通了。动手之前，先对照这张表。

为什么这件事值钱：IoT Analytics 的官方定价页和开发指南在 2026 年已经打不开（会跳转到 IoT 总览页），但中文技术社区里"用 IoT Analytics 建 IoT 数据管道"的文章仍然排在前列。如果你按老教程规划架构，做到一半才发现服务没了，迁移成本远高于一开始就用对方案 —— 这也是我们把它单列一节的唯一原因。

替代路线很清晰：原始数据落地用 IoT Core 规则引擎直接写 S3，实时流走 Kinesis（见 https://3.chengzicloud.cloud/blog.php?post=aws-kinesis-realtime-streaming-practical-guide），聚合与查询用 Timestream 或 Athena，告警联动用 EventBridge + SNS/SQS（见 https://3.chengzicloud.cloud/blog.php?post=aws-sns-sqs-message-queue-guide）。

三、AWS IoT Core 是什么：一条链讲清 MQTT 接入 → 影子 → 规则引擎

IoT Core 的定位是"设备的云端网关"。一台设备从物理世界走到你的业务系统，中间经过四个组件，理解它们的分工，后面计费那一节就会一眼看懂。

两个新手常混淆的概念：

• MQTT 主题（Topic） 是数据通道，Thing 是设备身份。一台设备可以订阅多个主题，主题本身不产生计费，产生计费的是连接和消息。
• 设备影子 解决的是"设备掉线时 App 还想显示状态"的问题；它不是数据库，官方限制 JSON 状态文档最大 8KB、深度最多 8 层，别拿它存历史数据。

四、从 0 接入第一台设备：CLI 全流程

下面这套命令用 AWS CLI v2 实际操作，从创建 Thing 到收到第一条消息，一共八步。注意：本文所有代码块里的注释统一用 //，不是 #——这是本站的排版约定，避免注释被渲染成标题。

第一步到第四步，创建设备身份和证书策略：

// 1. 建 Thing 类型和 Thing（建议加分组，便于后面批量运维）
aws iot create-thing-type --thing-type-name sensor-v1
aws iot create-thing --thing-name sensor-0001 --thing-type-name sensor-v1
aws iot create-thing-group --thing-group-name factory-a --parent-group-name all-sensors

// 2. 生成设备证书与私钥（返回的 certificateId 要记下来）
aws iot create-keys-and-certificate --set-as-active \
  --certificate-pem-outfile sensor-0001.crt \
  --public-key-outfile sensor-0001.pub \
  --private-key-outfile sensor-0001.key

// 3. 写一个最小权限策略（千万别用 Resource: "*"）
// 策略内容见下表，先用 write_file 写成 policy.json 再执行下面这条
aws iot create-policy --policy-name sensor-policy \
  --policy-document file://policy.json

// 4. 把策略和证书挂到 Thing 上
aws iot attach-policy --policy-name sensor-policy --target <certificate-arn>
aws iot attach-thing-principal --thing-name sensor-0001 --principal <certificate-arn>

最小权限策略的写法（只允许设备上报自己的主题、并读写自己的影子）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:ap-southeast-1:123456789012:client/${iot:Connection.Thing.ThingName}"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": "arn:aws:iot:ap-southeast-1:123456789012:topic/sensors/${iot:Connection.Thing.ThingName}/data"
    },
    {
      "Effect": "Allow",
      "Action": ["iot:GetThingShadow", "iot:UpdateThingShadow"],
      "Resource": "arn:aws:iot:ap-southeast-1:123456789012:thing/${iot:Connection.Thing.ThingName}"
    }
  ]
}

第五步到第八步，打通数据链路：

// 5. 取设备接入端点（IoT Core 的 ATS 端点，每个账号每个区域唯一）
aws iot describe-endpoint --endpoint-type iot:Data-ATS

// 6. 建一条规则：把温度超过阈值的消息转发到 Lambda
// 规则 SQL 与动作定义写成 rule.json 后用下面这条创建
aws iot create-topic-rule --rule-name high-temp-alert \
  --topic-rule-payload file://rule.json

// 7. 用 mosquitto 客户端模拟设备上报（8883 端口）
mosquitto_pub --cafile AmazonRootCA1.pem \
  --cert sensor-0001.crt --key sensor-0001.key \
  -h <your-endpoint>.iot.ap-southeast-1.amazonaws.com -p 8883 \
  -t sensors/sensor-0001/data -m '{"temp":42.5}'

// 8. 验证影子与规则是否生效
aws iot-data update-thing-shadow --thing-name sensor-0001 \
  --payload '{"state":{"reported":{"temp":42.5}}}' shadow.json
aws iot-data get-thing-shadow --thing-name sensor-0001 shadow-out.json

规则引擎的 SQL 写法（阈值判断 + 转发）：

{
  "sql": "SELECT temp, timestamp() AS ts FROM 'sensors/+/data' WHERE temp > 40",
  "actions": [
    { "lambda": { "functionArn": "arn:aws:lambda:ap-southeast-1:123456789012:function:highTemp" } }
  ]
}

CLI 命令速查：

五、IoT Core 计费口径与单价：四个维度分开算

IoT Core 的账单是"四个维度相加"，每个维度的计量单位都不一样，这是它比 EC2 更容易算错的地方。

几个容易漏掉的细分口径：

免费套餐（12 个月）：

官方给的免费套餐示例正是"50 台设备"：每台每天在线 24 小时、交换 300 条 5KB 以内消息、130 次影子操作、150 次规则执行 —— 全部落在免费额度内，这就是"前几个月基本 $0"的由来。另外，2025-07-15 之后注册的新账号还能拿到最高 $200 的 Free Tier 抵扣额度（详见 https://3.chengzicloud.cloud/blog.php?post=aws-free-tier-registration-guide 与 https://3.chengzicloud.cloud/blog.php?post=2026-10-09-aws-activate-credits-free-plan-startup-guide）。

官方算例复算（100,000 台设备 / 30 天）——建议你拿计算器跟我过一遍：

注意这个 $1 的差异：AWS 官方定价页在该算例的合计行写的是 $346.60 + $975.00 + $375.00 + $180.00 = $1,876.60。但连接那一行的推导结果明明是 $345.60，四项正确相加是 $1,875.60。也就是说官方文案里同时存在一个笔误（$346.60 应为 $345.60）和一个合计错误（应为 $1,875.60）。金额不大，但说明一件事：算 IoT 账单时不要抄别人的合计，一定要自己按维度复算。

六、AWS IoT Greengrass：边缘端从 0 部署与计费

Greengrass 解决"设备不能一直联网、但本地还要跑逻辑"的问题。它在边缘设备上提供本地 Lambda、本地消息、本地影子，断网时照常工作，恢复后与云端同步。

两个必须记住的判定规则：

• "活跃"的定义是"当月有没有和 AWS 完成认证"，不是"设备有没有在跑"。设备离线但本地继续工作 → 这个月不算活跃，不计费。
• 不用的 Core 必须走完整卸载流程：停止 nucleus 进程 并且 从 Greengrass 服务里删除设备。只停进程不删设备，账单会继续产生 —— 这是官方文档专门用"Important"标出来的坑。

部署一个自定义组件到设备车队：

// 1. 创建组件版本（把产物打到 S3，再用 recipe 定义）
aws greengrassv2 create-component-version --inline-recipe fileb://recipe.yaml

// 2. 给目标设备组创建部署
aws greengrassv2 create-deployment \
  --target-arn "arn:aws:iot:ap-southeast-1:123456789012:thinggroup/factory-a" \
  --deployment-name rollout-v1 \
  --components '{"com.example.SensorAggregator":{"componentVersion":"1.0.0"}}'

// 3. 查看部署状态（list-effective-deployments 是排查"部署没生效"的关键命令）
aws greengrassv2 list-effective-deployments \
  --core-device-thing-name sensor-0001

七、设备运维与安全：Device Management + Device Defender

AWS IoT Device Management 负责"车队级操作"：

按量级估算：10,000 台设备批量注册一次 = $1.00；每月 300 次索引更新 × 2 档 × 10,000 台 ≈ $13.50；查 50 万次索引 ≈ $2.50。索引相关的钱远比接入便宜，做设备搜索与分组时不用太心疼。

AWS IoT Device Defender 负责"安全审计 + 异常检测"：

官方算例：100 台设备各上报 4 个指标、每小时 2 个数据点 → 0.576M 数据点 → 规则检测 $0.14/月；同样设备数改用 ML 检测、每台 6 个指标 → 864K 数据点 → $10.23/月。审计便宜（$0.11/月/百台），ML 检测才是花钱的地方，建议先开审计 + 规则检测，确认价值后再逐步上 ML。

八、工业数据与数字孪生：SiteWise + TwinMaker

AWS IoT SiteWise 面向产线设备数据，计费三项：

官方算例：10 台设备、每台每秒 1 条测量消息、30 天 → 25.92M 条消息。消息 $25.92 + 计算 $12.96 + 存储 $0.60 = $39.48/月。注意 SiteWise Edge 的 $200/网关/月是整篇里最容易被忽视的大额项 —— 只要网关当月连回 AWS 拿配置就算"活跃"，一套产线三台网关就是 $600/月，比云端数据费还贵十倍。

AWS IoT TwinMaker 做数字孪生看板，三档定价：

Tiered Bundle 的档位：Tier 1（1–1,000 实体）、Tier 2（1,001–5,000）、Tier 3（5,001–10,000）、Tier 4（10,001–20,000）。切到 Tiered Bundle 有 3 个月承诺期，中途不能立刻切回 —— 用量不稳定时先留在 Standard。

官方算例：800 实体的产线孪生 → Standard 档 $19.18（数据访问）+ $40（实体）+ $138.35（查询）= $197.53/月；同一负载若选 Tiered Bundle（Tier 1）则是 $220/月 固定价。可见实体数少、查询多时 Standard 更划算，实体多、查询稳定时 Bundle 更省心。

想让孪生看板跑在云端桌面上给工程师用，可以配合 https://3.chengzicloud.cloud/blog.php?post=2026-10-05-aws-workspaces-cloud-desktop-family-guide 里的 WorkSpaces 方案。

九、区域可用性与选型：香港、新加坡、东京 vs 中国大陆

IoT Core 的数据端点（ATS）覆盖区域远少于 EC2，选错区域会导致"能开 EC2、开不了 IoT"。

三条选型纪律：

• 设备在哪儿，区域就选哪儿。MQTT 是长连接，跨境链路抖动会直接变成设备频繁重连，而重连照样计连接分钟。
• 面向中国大陆设备要老实选香港或新加坡，并从设备侧做好断线重连退避。别指望国际版能"就近接入大陆"。
• 免费套餐跨区域合并计算（GovCloud 除外），且当月未用完不累积 —— 所以不要为了薅免费额度把设备分散到多个区域，那不会让额度变多。

十、避坑清单：十个最常见的坑

再补一条安全侧的：设备证书策略绝不要用 Resource: "*"。IoT 的策略支持按 iot:Connection.Thing.ThingName 做变量替换，做到"每台设备只能上报自己的主题、只能读写自己的影子"，一次配好，后面接入新设备直接复用。IAM 侧的最小权限思路可参考 https://3.chengzicloud.cloud/blog.php?post=aws-iam-permissions-practical-guide。