AWS 专题学习 P9 (API Gateway、Cognito、Serverless SA)

专题总览

包含专题内容总览和系列博客目录
https://blog.csdn.net/weixin_40815218/article/details/135590291

API Gateway

AWS API Gateway 是一项 AWS 服务，它具有以下功能：

• AWS Lambda + API Gateway => 无需管理基础架构的API管理
• 支持 WebSocket 协议
• 处理 API 版本控制（如v1、v2等）
• 处理不同的环境（如开发、测试、生产等）
• 处理安全性（身份验证和授权）
• 创建 API 密钥，处理请求限流
• 支持 Swagger / Open API 导入，快速定义API
• 转换和验证请求和响应
• 生成 SDK 和 API 规范
• 缓存 API 响应

API Gateway – 高级集成

• Lambda 函数
  • 调用 Lambda 函数
  • 可以便捷地借助 AWS Lambda，暴露 REST API
• HTTP
  • 在后端暴露 HTTP 端点
  • 例子：内部 HTTP API，应用程序负载均衡器…
  • 为什么？添加速率限制、缓存、用户认证、API密钥等…
• AWS服务
  • 通过 API 网关暴露任何 AWS API
  • 例子：启动 AWS Step Function 工作流程，向 SQS 发布消息
  • 为什么？添加身份验证，公开部署，速率控制…

API Gateway – AWS 服务集成

Kinesis Data Streams示例

API Gateway - Endpoint Types

• Edge-Optimized（默认）：适用于全球客户
  • 请求通过 CloudFront 边缘位置路由（提高延迟）
  • API Gateway 仍位于一个区域中
• 区域：
  • 适用于同一区域内的客户
  • 可以手动与 CloudFront 结合使用（更多对缓存策略和分发的控制）
• 私有：
  • 只能通过 VPC 使用界面 VPC 端点（ENI）访问
  • 使用资源策略来定义访问

API Gateway – 安全

• 用户身份验证通过
  • IAM 角色（适用于内部应用程序）
  • Cognito（用于外部用户身份认证 - 例如移动用户）
  • 自定义授权者（您自己的逻辑）
• 通过与 AWS 证书管理器（ACM）集成实现自定义域名的HTTPS 安全性
  • 如果使用 Edge-Optimized 终端点，则证书必须位于us-east-1 区域
  • 如果使用Regional终端点，则证书必须位于 API Gateway 所在的区域
  • 必须在 Route 53 中设置 CNAME 或 A-别名记录

AWS Step Functions（AWS 步骤函数）

• 可以构建无服务器的可视化工作流程，用于编排 Lambda 函数
• 功能包括：顺序执行、并行执行、条件判断、超时处理、错误处理等
• 可以与 EC2、ECS、本地服务器、API Gateway、SQS 队列等进行集成
• 可以实现人工审批功能
• 应用场景：订单处理、数据处理、Web应用程序等任何工作流程
  

Amazon Cognito（认证服务）

• 为用户提供身份以与我们的Web或移动应用程序进行交互
• Cognito 用户池：
  • 为应用程序用户提供登录功能
  • 与API Gateway和应用程序负载均衡器集成
• Cognito 身份池（联合身份）：
  • 为用户提供AWS凭证，使他们可以直接访问AWS资源
  • 与 Cognito 用户池集成作为身份提供者
• Cognito 与 IAM 的比较：“数百个用户”，“移动用户”，“使用SAML进行身份验证”

Cognito User Pools (CUP) – 用户功能

• 为您的 Web 和移动应用程序创建无服务器用户数据库
• 简单登录：用户名（或电子邮件）/密码组合
• 密码重置
• 电子邮件和电话号码验证
• 多因素身份验证（MFA）
• 联合身份：来自 Facebook、Google、SAML 等的用户

Cognito User Pools (CUP) - 集成

• CUP 可以与 API Gateway 和应用程序负载均衡器进行集成
  

Cognito Identity Pools（联合身份）

• 为“用户”获取身份，以获取临时的 AWS 凭证
• 用户的来源可以是 Cognito 用户池、第三方登录等
• 用户可以直接访问 AWS 服务，或通过 API Gateway 访问
• 凭证所应用的 IAM 策略在 Cognito 中定义
• 可以根据 user_id 进行细粒度控制进行自定义
• 针对已验证和访客用户的默认 IAM 角色

Cognito Identity Pools（CIP）允许在 DynamoDB 中实现行级别的安全性

Serverless Architectures

移动应用程序：MyTodoList

我们希望创建一个具备以下要求的移动应用程序：

• 以HTTPS的方式暴露为REST API
• 采用无服务器架构
• 用户应能直接与其在S3中的文件夹进行交互
• 用户应通过托管的无服务器服务进行身份验证
• 用户可以编写和阅读待办事项，但他们主要是阅读它们
• 数据库应具备可伸缩性，并具备一定的高读取吞吐量

Mobile app: REST API layer

Mobile app: giving users access to S3

Mobile app: high read throughput, static data

Mobile app: caching at the API Gateway

总结

• 无服务器 REST API: HTTPS、API Gateway、Lambda、DynamoDB
• 使用 Cognito 通过 STS 生成临时凭证来访问带有受限策略的 S3 存储桶。应用程序用户可以通过这种方式直接访问 AWS 资源。这种模式可以应用于DynamoDB、Lambda 等。
• 使用 DAX 在 DynamoDB 上缓存读取操作
• 在 API Gateway 层级上缓存 REST 请求
• 使用 Cognito 和 STS 进行身份验证和授权的安全性

Serverless 托管网站：MyBlog.com

• 这个网站应该具备全球范围的可扩展性
• 博客很少写入，但经常被读取
• 网站的一部分是纯静态文件，另一部分是动态的 REST API
• 尽可能实现缓存
• 任何新订阅的用户都应该收到欢迎邮件
• 博客中上传的任何照片都应该生成缩略图

Serving static content, globally

Serving static content, globally, securely

Adding a public serverless REST API

Leveraging DynamoDB Global Tables

User Welcome email flow

Thumbnail Generation flow

总结

• 我们使用 CloudFront 和 S3 来分发静态内容。
• REST API 采用无服务器架构，不需要 Cognito，因为是公开的。
• 我们利用了全球 DynamoDB 表来全球提供数据服务。
• （我们也可以使用 Aurora 全球数据库）
• 我们启用了 DynamoDB Streams 来触发 Lambda 函数。
• Lambda 函数具有 IAM 角色，可以使用 SES。
• SES (Simple Email Service) 被用于以无服务器方式发送电子邮件。
• S3 可以触发 SQS / SNS / Lambda 来通知事件。

Micro Services 架构

• 我们希望转向微服务架构。
• 许多服务直接使用 REST API 进行交互。
• 每个微服务的架构可能因形式和结构而异。
• 我们希望采用微服务架构，以便每个服务都有更精简的开发生命周期。

Micro Services Environment

Discussions on Micro Services

• 可以自由设计每个微服务
• Synchronous patterns：API Gateway、负载均衡器
• Asynchronous patterns：SQS、Kinesis、SNS、Lambda 触发器（S3）
• 微服务面临的挑战：
  • 创建每个新微服务的重复开销。
  • 优化服务器密度/利用率的问题。
  • 同时运行多个版本的多个微服务的复杂性。
  • 客户端代码需求的增加，以与许多单独的服务集成。
• 一些挑战可以通过无服务器模式解决：
  • API Gateway 和 Lambda 可以自动扩展，并按使用量付费。
  • 可以轻松克隆 API，复制环境。
  • 通过 Swagger 集成为 API Gateway 生成客户端 SDK。

软件更新的 offloading (卸载)

• 我们在 EC2 上运行一个应用程序，偶尔会分发软件更新。
• 当有新的软件更新时，我们会收到大量请求，并且内容会在网络上大规模分发。这非常昂贵。
• 我们不想改变我们的应用程序，但希望优化成本和 CPU，我们该怎么做？

App 当前架构

为什么选择 CloudFront？

• 不需要更改架构。
• 它将在边缘缓存软件更新文件。
• 软件更新文件是静态的（永不更改）。
• 我们的 EC2 实例不是无服务器的，但 CloudFront 是，它会为我们扩展。
• 我们的 ASG 不会扩展那么多，我们将在 EC2 上大大节省成本。
• 我们还将在可用性、网络带宽成本等方面节省。
• 这是一种使现有应用程序更具可扩展性和更便宜的简单方法！