亚马逊AWS官方博客

Amazon IoT Core 设备接入指南

摘要:设备接入 Amazon IoT Core,核心是完成两件事:身份认证(设备如何证明”我是谁”)与设备预置/注册(在 IoT Core 中创建 Thing、X.509 证书、IoT Policy 等资源)。不同客户的产品形态、产线能力、安装方式差异很大:有的能在出厂前把唯一证书烧录进设备,有的做不到;有的现场有安装人员可用 App 激活,有的要求零接触全自动上线。因此 IoT Core 提供了多种预置方式。官方按”能否在出厂前安装唯一证书”将其分为两大类、共五种具体方式,本文逐一展开,为每种给出适用场景、架构图与关键代码/模板,帮助为客户选择最合适的上云路径。


一、引言:为什么”上云方式”因客户而异

设备接入 Amazon IoT Core,核心是完成两件事:身份认证(设备如何证明”我是谁”)与设备预置/注册(在 IoT Core 中创建 Thing、X.509 证书、IoT Policy 等资源)。

不同客户的产品形态、产线能力、安装方式差异很大:有的能在出厂前把唯一证书烧录进设备,有的做不到;有的现场有安装人员可用 App 激活,有的要求零接触全自动上线。因此 IoT Core 提供了多种预置方式。官方按”能否在出厂前安装唯一证书”将其分为两大类、共五种具体方式,本文逐一展开,为每种给出适用场景、架构图与关键代码/模板,帮助为客户选择最合适的上云路径。

二、认证方式与核心资源

2.1 三种认证方式

预置解决的是”如何建资源、如何上线”,而认证解决的是”设备连接时如何证明身份”。IoT Core 目前支持三类认证方式:

认证方式 说明 典型场景
X.509 证书(双向 TLS) 设备持证书+私钥与 IoT Core 双向认证 绝大多数 MQTT 设备,端口 8883/443
IAM / SigV4 用 Amazon 凭证签名请求 移动/Web 应用、后端服务,WebSocket
自定义授权 Custom Authorizer Lambda 自定义鉴权(token/用户名密码等) 非证书设备、遗留协议接入
说明: 本文聚焦最主流的 X.509 证书接入,五种预置方式均围绕”如何为设备获得并注册唯一证书”展开。

2.2 预置会创建哪些资源

无论采用哪种方式,预置过程通常会创建以下三类核心资源:

  • IoT Thing:设备注册表条目,有唯一名称和属性,可用 Thing Type / Thing Group 组织,便于舰队索引(Fleet Indexing)。建议 Thing 名与连接时的 client ID 一致,以便索引连接状态。
  • X.509 证书:设备用于与 IoT Core 双向认证;可注册已有证书或由 IoT Core 生成,需与代表设备的 Thing 关联。
  • IoT Policy:定义设备可执行的操作(connect/publish/subscribe/receive 等),附加到设备证书上。

规模化场景通过 Provisioning Template(预置模板)用变量复用同一套模板批量创建资源——这是 JITP、批量注册和舰队预置共同的机制。

三、五种方式速览

先用一张表把握全局,再逐一深入:

方式 证书前提 典型适用场景 特点
单个 Thing 手动注册 已具备唯一证书 设备量少 / PoC / 需先定义设备 逐台手动,直观可控
JITP / JITR 已具备唯一证书 量大、出厂能装证书、无清单 首连自动注册
批量注册 已具备唯一证书 已知一大批、可整理成清单 S3 清单批处理
可信用户预置 出厂无唯一证书 现场有安装人员用 App 激活 临时证书 5 分钟
按声明预置 出厂无唯一证书 零接触全自动量产上线 共享 claim 换证

四、设备已具备唯一证书

如果你能在设备交付前,安全地把唯一客户端证书安装到设备上,则属于 A 组。有三种方式可选。

4.1 方式一:单个 Thing 手动注册(Single-thing Provisioning)

[图 1:单个 Thing 手动注册流程]

通过控制台、CLI 或 API 逐台完成:创建 Thing、注册或生成 X.509 证书、创建并绑定 IoT Policy,再把证书和私钥拷贝到设备。

关键步骤(CLI 示例)

# 1) 创建 Thing
aws iot create-thing --thing-name building-sensor-01 --region cn-northwest-1
# 2) 生成并激活证书(返回证书 ARN 与密钥)
aws iot create-keys-and-certificate --set-as-active \
    --certificate-pem-outfile device.pem.crt \
    --public-key-outfile public.key \
    --private-key-outfile private.key --region cn-northwest-1
# 3) 创建策略并附加到证书
aws iot create-policy --policy-name SensorPolicy \
    --policy-document file://policy.json --region cn-northwest-1
aws iot attach-policy --policy-name SensorPolicy --target <certificateArn>
# 4) 把证书绑定到 Thing
aws iot attach-thing-principal --thing-name building-sensor-01 \
    --principal <certificateArn> --region cn-northwest-1

适用场景:设备数量少、概念验证(PoC)、或需要在设备上线前就先在 IoT Core 中明确定义每台设备。

优缺点:流程直观、完全可控;但纯人工逐台操作,不适合规模化生产。

4.2 方式二:即时预置 / 即时注册(JITP / JITR)

[图 2:JITP / JITR:设备首次连接时自动注册]

把签发设备证书的 CA 注册到 IoT Core,设备在首次连接时被自动识别并根据预置模板创建资源、完成上线,无需逐台人工注册。

  • JITP(Just-in-Time Provisioning):把预置模板附加到 CA 上,IoT Core 在设备首连时自动完成预置。
  • JITR(Just-in-Time Registration):设备首连触发注册事件,由 IoT 规则调用 Lambda 执行自定义注册逻辑,灵活度更高。

注册 CA 并附加预置模板(示例)

# 将 CA 证书注册到 IoT Core 并开启自动注册
aws iot register-ca-certificate \
    --ca-certificate file://rootCA.pem \
    --verification-cert file://verificationCert.pem \
    --set-as-active --allow-auto-registration \
    --registration-config file://template.json \
    --region cn-northwest-1

适用场景:出厂前能安全安装唯一证书、设备量大,但无法预先把设备信息整理成批量清单。设备一上电连接即自动注册,非常适合分批、持续投产的量产设备。

4.3 方式三:批量注册(Bulk Registration)

[图 3:批量注册:基于 S3 清单一次性预置]

把一份包含设备属性的清单文件(每行一个 JSON)放到 Amazon S3,通过 StartThingRegistrationTask 按单 Thing 预置模板批量创建 Thing、证书与策略。

清单与启动任务(示例)

# devices.json (每行一个设备的模板参数)
{"ThingName":"sensor-1001","SerialNumber":"SN1001","Building":"A"}
{"ThingName":"sensor-1002","SerialNumber":"SN1002","Building":"A"}
# 启动批量注册任务
aws iot start-thing-registration-task \
    --template-body file://bulk-template.json \
    --input-file-bucket my-provisioning-bucket \
    --input-file-key devices.json \
    --role-arn arn:aws-cn:iam::ACCOUNT:role/IoTProvisioningRole \
    --region cn-northwest-1

适用场景:已经掌握一大批已知设备、且能把它们的期望特征整理成清单(例如产线一次性投产的一批设备)。

优缺点:批处理效率高;前提是能预先整理出准确的设备信息清单。

五、出厂前无法安装唯一证书(舰队预置)

如果无法在交付前给每台设备装唯一证书,则采用舰队预置(Fleet Provisioning)。设备先用一张临时/共享凭证连接,再由 IoT Core 换发长期唯一证书。根据”现场是否有人用 App 激活”分两种。

5.1 舰队预置模板结构(简化示例)

{
  "Parameters": {
    "SerialNumber": {"Type": "String"},
    "AWS::IoT::Certificate::Id": {"Type": "String"}
  },
  "Resources": {
    "thing": {"Type": "AWS::IoT::Thing",
      "Properties": {"ThingName": {"Ref": "SerialNumber"}}},
    "cert": {"Type": "AWS::IoT::Certificate",
      "Properties": {"CertificateId": {"Ref": "AWS::IoT::Certificate::Id"},
                     "Status": "ACTIVE"}},
    "policy": {"Type": "AWS::IoT::Policy",
      "Properties": {"PolicyName": "FleetDevicePolicy"}}
  }
}

5.2 方式四:可信用户预置(Provisioning by Trusted User)

[图 4:可信用户预置:安装人员用 App 现场激活]

由可信用户(如终端用户或安装人员,使用已知账号)通过 App 触发 CreateProvisioningClaim 获取一个仅 5 分钟有效的临时证书;设备在这 5 分钟窗口内连接 IoT Core,换取一张长期唯一证书并安装,正式上线。

生成临时预置声明(示例)

# 可信用户后端调用,拿到 5 分钟有效的临时证书与密钥
aws iot create-provisioning-claim \
    --template-name TrustedUserTemplate \
    --region cn-northwest-1
# 返回 certificatePem / keyPair / expiration(约 5 分钟)
# App 将其下发给设备,设备在窗口期内连接并换取长期证书

适用场景:出厂前无法装唯一证书,但现场有安装人员或终端用户可用 App 完成激活(如智能家居、商用设备安装)。

优缺点:临时证书生命周期极短(5 分钟),显著降低证书泄露风险;需要人工参与激活环节。

5.3 方式五:按声明预置(Provisioning by Claim)

[图 5:按声明预置:零接触全自动上线]

设备出厂时内置一张由整批设备共享的 claim 证书。设备首次连接时用 claim 证书触发舰队预置模板(可选配 Pre-provisioning Hook 做 Lambda 校验),IoT Core 为其签发唯一证书并创建资源,之后设备改用唯一证书通信。

设备侧预置流程(MQTT API)

  1. 设备用内置 claim 证书连接 IoT Core;
  2. 订阅并调用 CreateKeysAndCertificate 主题,获取唯一证书与密钥;
  3. 调用 RegisterThing 主题,携带模板参数(如序列号);
  4. IoT Core 执行 Pre-provisioning Hook 校验(可选),创建资源并激活证书;
  5. 设备保存唯一证书,断开后改用唯一证书重连正式上线。

适用场景:出厂前无法装唯一证书,且现场无人可用 App 激活——需要零接触、全自动的量产上线。

优缺点:全自动、零接触;但 claim 证书为共享凭证,泄露风险相对更高。

安全提示: 建议为 claim 证书配置最小权限策略(仅允许调用预置相关主题),并启用 Pre-provisioning Hook 校验设备合法性;一旦 claim 泄露可停用该证书——阻止后续设备注册,但不影响已上线设备。

六、选型建议(决策路径)

可按以下问题顺序为客户快速定位合适的方式:

  • 能否在出厂前安全安装唯一证书? → 不能,进入舰队预置(方式四/五)。
  • 能装证书,设备很少或需先定义? → 单个 Thing 手动注册(方式一)。
  • 能装证书、量大、有完整设备清单? → 批量注册(方式三)。
  • 能装证书、量大、无清单、持续投产? → JITP / JITR(方式二)。
  • 不能装证书,现场有人用 App 激活? → 可信用户预置(方式四)。
  • 不能装证书,要求零接触全自动? → 按声明预置(方式五)。

七、安全与运维注意事项

  • 最小权限策略:为不同阶段(claim 证书 vs 正式证书)配置不同的 IoT Policy,claim 证书仅授予预置相关权限。
  • 模板与 Hook 校验:舰队预置建议启用 Pre-provisioning Hook(Lambda),校验设备序列号是否在允许清单内,防止未授权设备注册。
  • 证书轮换:规划证书到期与轮换机制,避免大批设备证书同时过期。
  • 舰队索引与分组:用 Thing Group / Thing Type 组织设备,配合 Fleet Indexing 便于批量管理与检索连接状态。
  • 凭证泄露应急:claim 证书泄露可立即停用;正式证书可吊销并解绑策略。
  • 配额与限流:批量/舰队预置存在 API 速率与并发注册限制,大规模投产前评估配额,必要时申请提升。

八、总结与参考

设备接入 Amazon IoT Core 的本质,是在”身份认证”与”设备预置/注册”两件事上,为不同的产品形态和产线能力选择最合适的落地路径。认证层面以 X.509 证书(双向 TLS)为主流,并辅以 IAM/SigV4 和自定义授权;预置层面则以”能否在出厂前为设备安装唯一证书”为分水岭,划分为两大类共五种方式。

五种方式各有适用边界:设备量少或需先行定义,用单个 Thing 手动注册;量大、出厂能装证书但无清单,用 JITP/JITR 让设备首连自动注册;量大且有完整设备清单,用基于 S3 的批量注册;出厂无法装唯一证书但现场有人用 App 激活,用可信用户预置(临时证书仅 5 分钟有效,安全性高);出厂无唯一证书且要求零接触全自动量产上线,用按声明预置(共享 claim 证书换发唯一证书)。选型时可按”能否出厂前安装唯一证书、设备规模、是否有清单、现场是否有人激活”的决策顺序快速定位。

➡️ 下一步行动:

相关产品:

相关文章:

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。

本篇作者

路万华

解决方案架构师,15+的技术研发和架构经验,在电力、新能源和楼宇自控行业的物联网领域有丰富的经验。


AWS 架构师中心:云端创新的引领者

探索 AWS 架构师中心,获取经实战验证的最佳实践与架构指南,助您高效构建安全、可靠的云上应用