AWS介绍

以下所有内容在文档中均有描述，建议观看文档学习：

AWS IoT 能做什么 - AWS IoT Core

什么是 AWS？

AWS 是 Amazon(亚马逊) 提供的全球领先的云计算平台，涵盖了计算、存储、数据库、网络、安全等众多云服务，帮助开发者构建和部署高效的云端解决方案。

AWS 提供了强大的 IoT 服务生态，支持从设备连接到数据分析的全流程开发。通过学习和动手实践，你可以快速掌握这些工具并构建实际物联网项目。

IAM

IAM 作用

IAM（Identity and Access Management）是 AWS（亚马逊云）中的身份与访问管理服务。它是 AWS 安全体系的核心组件之一，主要目的就是让你可以安全地控制谁可以访问你的 AWS 资源，以及可以访问什么资源、能做哪些操作。

  • 身份管理：为人（用户）、系统（服务）、应用等分配身份（Identity），每个身份可以有唯一的认证信息（如用户名、密码、访问密钥等）。
  • 权限控制：通过权限策略（Policy）精细控制每个身份可以访问哪些 AWS 服务和资源，以及能做什么操作（如读、写、删除等）。

IAM主要概念

用户组（Group）

  • 用户的集合，方便批量分配权限。
  • 权限分配给组，组内成员继承这些权限。

image-20250520110135312

用户（User）

  • 属于 AWS 账号下的“云账户”，是 AWS 平台原生的身份，通常代表公司员工、长期自动化脚本等。
  • 有自己的用户名、密码、访问密钥，可以直接登录 AWS 控制台或使用 API。
  • 权限直接或通过组分配（Policy）。

image-20250520110150450

角色（Role）

  • 一种 AWS 资源的“临时身份”，不属于某个具体用户，没有用户名和密码，不能直接登录 AWS
  • 需要通过“扮演/切换角色（AssumeRole）”获得临时凭证。
  • 适合临时赋予权限给 AWS 服务、第三方服务、外部用户等。
  • Cognito 身份池分配的“已认证用户角色”和“访客用户角色”就是 IAM 角色的实际应用。

image-20250520110209711

策略（Policy）

  • 用 JSON 文档描述的权限规则。
  • 指定“允许/拒绝”哪些操作（Action）、哪些资源（Resource）、在什么条件（Condition）下生效。

image-20250520110222793

AWS IoT

AWS 提供了一系列物联网（IoT）相关服务，旨在帮助开发者连接、管理和分析 IoT 设备。

看文档学习:

设置 AWS 账户 - AWS IoT Core

AWS IoT Core

官方文档：

如何 AWS IoT 运作 - AWS IoT Core

核心功能

AWS IoT Core 是 AWS 的托管物联网平台，用于安全连接和管理海量设备，处理设备与云端的双向通信。

主要功能包括：

  • 设备连接与管理：支持 MQTT、HTTP、WebSockets 等协议，实现设备与云端的高效通信。

  • 设备影子（Device Shadow）：存储设备的当前状态（JSON 格式），即使设备离线，应用仍可读取或更新影子状态。

  • 规则引擎（Rules Engine）：实时处理设备数据，通过 SQL-like 语法将数据路由到 AWS 服务（如 Lambda、DynamoDB、S3）。

  • 安全机制：

    • X.509 证书认证设备身份。
    • IAM 策略控制设备权限。
    • 支持 TLS 加密传输。

典型应用场景

  • 远程监控与控制：如智能家居设备状态同步。
  • 预测性维护：通过传感器数据分析设备健康状态。
  • 数据集成：将设备数据转发到 AWS 服务（如 Kinesis 实时分析）。

关键组件：

  • 注册表（Registry）：记录设备元数据（如序列号、位置）。
  • 消息代理（Message Broker）：处理设备与云端间的消息传递。
  • 任务（Jobs）：批量向设备推送固件更新或配置变更。

AWS IoT Core 客户端身份验证

客户端身份验证 - AWS IoT Core

AWS IoT 支持三种类型的身份主体进行设备或客户端身份验证：

这些身份可与设备、移动、Web 或桌面应用程序结合使用。用户甚至可以键入 AWS IoT 命令行界面 (CLI) 命令来使用它们。通常情况下：

AWS IoT 设备：使用 X.509 证书验证

移动应用程序：使用 Amazon Cognito 身份验证

Web 应用程序和桌面应用程序：使用 IAM 或联合身份验证

AWS CLI 命令：使用 IAM。

AWS IoT Core使用

物品(Thing)

物品(Thing)介绍

  • **物品（Thing）**是 AWS IoT Core 中对每一个物理设备的数字化建模。每个物品代表你在现实世界中的一个具体设备（如传感器、网关、家电等）。

  • 通过物品，你可以对单个设备进行身份标识、配置管理、权限控制、远程监控和自动化运维。

物品的主要作用

  1. 唯一标识设备：每个物品有唯一名称，便于管理和追踪。
  2. 安全认证：为物品分配证书和密钥，实现设备级别安全认证。
  3. 权限管理：通过策略（Policy）对物品绑定的证书分配权限（如连接、发布、订阅等）。
  4. 设备影子（Device Shadow）：每个物品都可以有一个设备影子，云端虚拟状态副本，便于状态同步和离线控制。
  5. 分组与分类：物品可以分组，便于批量管理和分类操作。
  6. 监控与日志：通过物品可以监控单台或多台设备的连接、消息、告警等。

单个设备连接 AWS IoT 的基本流程

  1. 创建物品（Thing）
    • 在“管理”里的“物品”下创建一个新物品，为你的物理设备分配一个唯一名称。
  2. 创建并下载证书和私钥
    • 为物品生成新的证书和私钥（首次创建时下载，后续丢失只能新建），用于设备端 TLS/SSL 安全连接。
  3. 下载 CA 根证书
    • 下载并保存 Amazon Root CA 1，这是服务器端认证用的。
  4. 绑定策略（Policy）
    • 给物品的证书附加一个或多个策略，策略规定了此设备可以在 AWS IoT Core 上执行哪些操作（如连接、发布、订阅等）。
  5. 设备端配置
    • 把下载的设备证书、私钥、CA 根证书填入 MCU 或客户端代码。
    • 配置 MQTT 服务器地址（即 AWS IoT Core 的 endpoint）、端口（一般为8883），并使用正确的证书和私钥进行 SSL/TLS 连接。
  6. 连接测试
    • 可用控制台的“MQTT 测试客户端”功能测试设备与云端通信是否正常。

具体流程:见笔记MQTT常见连接流程的MCU连接至AWS部分！

策略

在AWS IoT中可以看到我们创建的对应的策略。每个策略中也可以看到该策略附加到了什么类型上：AWS IoT证书、Cognito身份

不同类型的身份认证方式，对应的策略附加类型也不同

image-20250519174612900

三种身份认证方式：

image-20250519174729945

AWS IoT证书对应的是X.509证书认证

Cognito身份对应的是Amazon Cognito身份验证方式

设备影子

AWS文档：

在设备中使用影子 - AWS IoT Core

什么是设备影子

设备影子是 AWS IoT Core 提供的一项云端服务，核心作用是：

为每个物理设备在云端保存一个“状态副本”（JSON 文档），让云端应用和设备本身都可以随时读写这个副本，实现设备状态的同步和管理。

可以使用该影子通过 MQTT 或 HTTP 获取和设置设备的状态，无论该设备是否连接到 Internet。每台设备的影子都由相应事物的名称唯一标识。

关键点：

  • 每个设备（Thing）都有自己的影子（Shadow）。
  • 影子存储在 AWS 云端，即使设备离线也能访问。
  • 设备和应用都可以通过影子读写设备状态。

为什么需要设备影子

  • 设备可能经常离线：比如断网、掉电、休眠等。
  • 云端和设备解耦：云端应用可以直接与影子交互，不必直接连设备。
  • 状态同步：云端可以“设定目标状态”，设备上线后自动获取并更新自己。
  • 持久性：状态保存在云端，不怕设备重启丢失

设备影子结构

设备影子的本质是一个JSON文档，主要有三部分：

1
2
3
4
5
6
7
8
9
10
{
  "state": {
    "desired": { ... },  //事物的预期状态。应用程序可以向本文档部分写入数据来更新事物的状态，且无需直接连接到该事物。
    "reported": { ... },  // 事物的报告状态。事物可以向本文档部分写入数据，以报告其新状态。应用程序可以读取本文档部分，以确定事物的状态
    "delta": { ... }      // 差异（desired 和 reported 的不同）
  },
  "metadata": { ... },
  "version": 12,
  "timestamp": 1716260000  //指明 AWS IoT 传输消息的时间。通过在消息中使用时间戳并对 desired 或 reported 部分中的不同属性使用时间戳，事物可以确定已更新项目的存在时间，即使它不具有内部时钟特性。
}
  • desired：云端设定的目标状态（如灯要开、温度调到25度）。
  • reported：设备自己上报的实际状态（如灯现在开着，温度23度）。
  • delta：目标和实际的差异（如果有），设备可以据此调整。

设备影子的操作和流程

云端操作：

  • 云端应用可以直接“写”影子的desired部分，设定希望设备达到的目标。
  • 云端应用可以“读”影子的reported部分，获知设备当前的实际状态。

设备操作：

  • 设备上线后，主动“读”影子的delta或desired部分，获取云端最新目标。
  • 设备调整自身状态后，“写”影子的reported部分，上报自己的实际状态。

状态同步流程示意：

  1. 云端设置desired（例如希望开灯）；
  2. 设备上线后获取到delta（发现云端期望开灯），于是开灯；
  3. 设备开灯后，上报reported（已开灯）；
  4. 云端看到reported和desired一致，delta消失，状态同步完成。

设备影子的常用 MQTT 主题(Topic)

主题 用途
$aws/things/{thingName}/shadow/update 发布影子状态更新（desired或reported）
$aws/things/{thingName}/shadow/get 获取影子文档
$aws/things/{thingName}/shadow/update/accepted 影子更新成功的反馈
$aws/things/{thingName}/shadow/update/rejected 影子更新失败的反馈
$aws/things/{thingName}/shadow/get/accepted 获取影子成功的反馈
$aws/things/{thingName}/shadow/get/rejected 获取影子失败的反馈
$aws/things/{thingName}/shadow/delete 删除影子文档

典型场景

1. 远程控制

云端App设定desired，设备感知并调整自身状态，然后上报reported。

2. 状态上报

设备定时/事件驱动发布reported，云端可以查询设备当前状态。

3. 离线同步

设备断网期间，云端依旧可修改desired。设备重新上线时，会收到delta，自动同步。

代码&消息示例

  • 云端设置目标状态
1
2
3
4
5
6
7
8
// 发布到 $aws/things/my_thing/shadow/update
{
  "state": {
    "desired": {
      "led": "on"
    }
  }
}
  • 设备上报实际状态
1
2
3
4
5
6
7
8
// 发布到 $aws/things/my_thing/shadow/update
{
  "state": {
    "reported": {
      "led": "on"
    }
  }
}
  • 设备收到云端下发的delta
1
2
3
4
5
6
7
{
  "state": {
    "led": "off"
  },
  "version": 12,
  "timestamp": 1716260000
}

Amazon Cognito

什么是 Amazon Cognito？ - Amazon Cognito

核心功能

Amazon Cognito 是面向应用的用户身份管理服务，提供用户注册、登录、访问控制等功能，支持移动端(APP)和 Web 应用。

用户池和身份池概念

用户池（User Pool）

作用：
用户池用于用户身份认证，即“你是谁”。

功能：

  • 提供注册、登录、找回密码、多因子认证（MFA）等用户管理功能。
  • 可以存储用户的用户名、邮箱、手机号、密码等信息。
  • 支持社交登录（如 Facebook、Google）和企业身份提供商（SAML、OIDC）。

应用场景：
适合需要自有用户账号体系的应用，比如 App、网站等。

用法示例：
你可以用 Cognito 用户池来让用户注册账号、登录、重置密码等。用户池会保存用户信息，并生成一个 JWT Token（ID Token/Access Token），应用通过 Token 识别和管理用户会话。

AWS用户池：

image-20250519161736438

Token

什么是 Token？

Token（令牌）是认证系统生成的字符串，用来代表用户的登录状态和身份信息

在 AWS Cognito 用户池中，这个 Token 实际上是JWT（JSON Web Token）格式的。

登录成功后，Cognito 用户池会返回三种 Token：

Token 名称 主要作用
ID Token 描述用户身份信息（如用户名、邮箱等）
Access Token 授权用户访问受保护的 API 资源
Refresh Token 用于刷新获取新的 ID Token 和 Access Token

ID Token：

  • 内容：包含用户的身份信息（比如用户名、邮箱、用户属性等）。
  • 用途：你的 App 可以读取 ID Token 里的信息，知道用户是谁。

Access Token：

  • 内容：包含用户权限和授权信息。
  • 用途：你的 App 或后端在访问受保护资源（比如 API 网关）时，把 Access Token 附上，服务端用它判断你是否有权限访问。

Refresh Token：

  • 内容：只用于换取新的 ID Token 和 Access Token。
  • 用途：Token 过期后，用户无需重新登录，可以用 Refresh Token 换新 Token（通常存储在本地）。

身份池（Identity Pool）

作用：
身份池用于授权和临时身份凭证管理，即“你可以访问什么”。

功能：

  • 允许用户“联合身份”登录（如用 Cognito 用户池、社交账号、SAML、匿名身份等）。
  • 通过身份池，应用可以为用户分配 AWS 资源的临时访问凭证（如 S3、DynamoDB、IoT 等），权限由身份池的角色策略控制
  • 身份池并不管理用户的用户名/密码，而是根据已认证的身份，发放临时 AWS 权限。

应用场景：
适合让用户访问 AWS 资源（如上传文件到 S3、与 IoT 设备通信等）。

用法示例(重要)：

用户登录后，应用会把用户池获得的 Token 传给身份池，身份池验证后，返回一组有权限的 AWS 临时凭证（AK/SK/SessionToken），应用再用这些凭证去访问 AWS 服务。

临时凭证

在 AWS 中，临时凭证（Temporary Credentials）指的是一组由 AWS 颁发的、有时效限制的安全密钥，包括三部分：

  • Access Key ID（访问密钥ID）
  • Secret Access Key（访问密钥秘钥）
  • Session Token（会话令牌）

作用：

1.访问 AWS 云服务

  • 拿到临时凭证后，App（或设备）可以用它来直接访问 AWS 的各类云资源与服务，如 S3、DynamoDB、IoT、Lambda、API Gateway等。
  • 可以把它理解为 AWS 给你的 App 一把临时钥匙，你能用它做什么、能访问哪些资源，取决于分配给你的权限策略（Policy）。

2.权限可控且更安全

  • 临时凭证由 Cognito 身份池根据你的身份（比如你用 JWT Token 换的）动态分配，权限范围和有效期都可控，有效期一般为1小时。
  • 即使凭证泄漏，风险也有限（过期自动失效，且权限受限）。
  • 不需要在 App 里硬编码长期的 AWS 密钥，安全性更高。

3.支持多种身份源统一授权

  • 不管你用邮箱/微信/QQ/匿名/企业账户登录，只要能获得 Cognito 用户池的 Token，都能通过身份池换取 AWS 临时凭证，实现统一的云端访问授权。

用户池和身份池区别

  • Cognito 用户池：管理应用用户的注册、登录——这些用户不是 IAM 用户。
  • Cognito 身份池：将应用用户（通过登录认证的或匿名用户）映射为 IAM 角色，获得 AWS 访问权限。
    • 已认证用户/访客用户都不是 IAM 用户，而是通过“角色”机制获得临时 AWS 权限。
项目 用户池（User Pool） 身份池（Identity Pool）
主要用途 用户身份认证 AWS 资源授权和临时凭证获取
用户管理 是（保存用户信息） 否（不保存用户信息）
签发对象 JWT Token（ID/Access/Refresh） AWS 临时凭证（AK/SK/Session）
支持身份 自注册、社交、企业 用户池、社交、SAML、匿名等
常见应用 登录注册、会话管理 S3/IoT 等 AWS 资源访问

通常先用用户池处理登录注册，再用身份池换取 AWS 资源访问权限。

IAM 与 Cognito区别

IAM 用户（User）

  • 属于 AWS 账号下的“云账户”，是 AWS 平台原生的身份，通常代表公司员工、长期自动化脚本等。
  • 有自己的用户名、密码、访问密钥，可以直接登录 AWS 控制台或使用 API。
  • 权限直接或通过组分配（Policy）。

IAM 角色（Role）

  • 一种“临时身份”，不属于某个具体用户，没有用户名和密码，不能直接登录 AWS。
  • 需要通过“扮演/切换角色（AssumeRole）”获得临时凭证。
  • 适合 AWS 服务之间、外部用户、临时授权等场景。
  • 权限通过策略分配。

Cognito 用户（User Pool User）

  • 存在于 Cognito 用户池（User Pool）中，是你应用的终端用户（比如手机APP、网站的注册用户）。
  • 负责用户注册、登录、找回密码、多因素认证等。
  • 只管理“应用层”的账号，不是 IAM 用户，没有 AWS 账号权限。

Cognito 身份（Identity Pool Identity）

  • 存在于 Cognito 身份池（Identity Pool）中，用于将“应用用户”映射为可访问 AWS 资源的临时身份。
  • Cognito 身份池会根据用户认证（已认证/未认证）分配不同的 IAM 角色，发放 AWS 临时凭证。
  • 可以支持多种身份源（Cognito 用户池、社交登录、匿名、SAML 等）。

image-20250520113206763

场景示例

  1. 用户打开 App 注册/登录（用 User Pool）。
  2. 登录成功后，获取到 Token。
  3. 用 Token 换取 Identity Pool 的 AWS 临时凭证。
  4. App 用临时凭证访问 S3 上传照片，或与 IoT 设备通信。

image-20250519171050852

创建用户池和身份池

创建用户池

应用程序类型：这里我们是移动端APP，所以使用移动应用程序

登录标识符选项：选择可以使用什么登录，图中勾选代表：可以使用电子邮箱、手机号码、用户名任意一种方式登录

注册必要属性：注册时的必填项，图中代表必填邮箱和电话

image-20250520100649118

点击创建即可，创建后可在用户池中看到对应的用户池，进入后可修改名称，以及用户管理等操作

image-20250520101740978

image-20250520101757768

用户登录和注册相关的设置可以在身份验证模块进行修改：

比如注册时的验证方式：手机还是邮箱等等

image-20250520164158065

image-20250520164120825

创建身份池

1.配置身份池信任

image-20250520102105060

  • 用户访问权限:两种

经过身份验证的访问权限：允许身份池管理的用户获取临时AWS凭证

访客访问权限：允许“没有登录、没有身份认证”的用户，通过身份池获得 AWS 颁发的临时凭证，从而访问你允许的云端资源

  • 经过身份验证的身份来源

Amazon Cognito 用户群体：通过Cognito的用户池进行身份验证(注册和登录应用的用户)

其它可选身份提供方：如 Apple、Facebook、Google、Amazon、Twitter、OpenID Connect (OIDC)、SAML、自定义开发人员身份提供者等。这些可以让你支持其它第三方账号登录。

2.配置权限

可以为我们的经过身份验证的角色和访客角色，分配对应的IAM角色，获取对应的凭证和权限

可以新建IAM角色，默认最低初始权限，创建完成身份池后，可以去IAM控制台，自定义IAM角色的策略。也可以使用已有IAM角色

这里使用新建IAM角色，可以看到默认的策略。这里图中应该对身份验证和访客进行不同的IAM角色管理(权限不同)，不应该使用相同角色。

应该新建 auth_test 和 unauth_test 两个角色

image-20250520113851990

image-20250520113919269

3.连接身份提供商(Amazon Cognito 用户群体 [用户池])

这里我们选择之前创建的用户池ID、以及应用程序客户端ID

image-20250520114127400

角色选择经过身份验证的默认角色、映射选择不活跃

image-20250520114219696

4.配置身份池属性

设置我们的身份池名称

不勾选 基本身份验证

image-20250520135317365

基本身份验证:

  • 启用后，应用可以通过较老的“基本身份验证”流程（Legacy/Classic Flow）来获取身份池的临时凭证。
  • 基本流程是：应用先用身份池的身份ID（IdentityId）和登录令牌，直接请求AWS服务分配给该身份的IAM角色权限。
  • 这种方式兼容老SDK/老代码，如果你的应用或SDK依赖于经典的 Cognito API 调用（如 GetCredentialsForIdentity），需要勾选。
  • 但这种方式有一定安全风险：因为IAM角色选择的逻辑会暴露给客户端，可能导致被恶意利用，造成不必要的权限暴露。

不启用的话，将不会使用经典流，使用增强流

  • 增强流会在服务端更安全地完成身份验证和角色分配，客户端不直接控制角色选择，安全性更高。
  • 新的 AWS SDK 默认推荐用增强流，适合新应用或强安全需求场景。

身份池用户访问权限

创建身份时如果使用的时新建IAM角色，创建完成后应该如图所示，活跃状态代表IAM角色创建成功(如果是不活跃，可以在右边编辑角色重新创建)

image-20250520153559641

来到我们的IAM控制台找到之前创建身份池时选择的auth_test和unauth_test角色： 可信实体必须是身份提供者: cognito-identity.amazor才能作为身份池的IAM角色选择

image-20250520154559654

经过身份验证的访问权限：角色 auth_test

点击进入auth_test角色后可以看到，目前只有一种客户托管策略。现在我们要为其添加对应IoT策略

image-20250520155059286

在右边添加权限中，进入附加策略，其中包含：

客户托管：我们自己创建的策略

AWS托管：AWS自带的一些策略

我们选择AWSIoTFullAccess允许所有的IoT服务添加

image-20250520155402375

image-20250520155508921

这里的AWSIoTFullAccess策略是允许所有的iot服务，实际使用是我们应该满足最小权限原则，创建自定义策略

还需要其他权限的话，也可以再添加对应的AWS托管策略或客户托管策略

这样就将经过身份验证的角色的IoT服务权限配置完成了 !!!

访客的权限：角色 unauth_test，访客没登录，我们不给其他权限保持默认即可

image-20250520155922787

创建自定义策略

客户托管：自定义策略

进入IAM的策略，创建策略

image-20250520151040192

选择IoT策略，然后勾选需要的权限，填写指定的资源区域、Topic限制等。勾选完成后可以选择json查看一下。点击下一步，然后填写策略名称、描述即可

image-20250520151149144

image-20250520151339307

最后在附加策略中搜索我们刚刚创建的自定义策略，然后将新建的auth_test添加即可

image-20250520151631676