极点宏观｜Financial Cloud Cloud · AWS 考试
AWS Solutions Architect Professional
| 文章 |
|---|
| 01 AWS Solutions Architect Professional SAP-C02 讲义 |
| 02 AWS DevOps Certified Professional DOP-C02 讲义 |
面向政府技术顾问、公益与教育主管、数据与安全负责人、心理健康服务网络及大型机构决策者的演讲内容稿。
删除堆栈后保留比赛数据
CloudFormation 删除策略应保留存储的对象并创建数据库备份，同时消除持续的数据库计算成本。
推荐配置
● 将 DeletionPolicy: Retain 应用到 S3 存储桶。
● 将 DeletionPolicy: Snapshot 应用到 RDS 资源。
● 在删除堆栈之前验证策略更改。
设计理由
● 技术可行性：CloudFormation 保持存储桶和对象完好无损，并在删除数据库之前创建最终的 RDS 快照。
● 需求匹配：竞赛图像和可恢复的数据库数据在堆栈终止后仍然存在。
● 场景匹配：应用程序不再处于活动状态，因此实时数据库不需要继续运行。
● 工程常识：在构建重复复制工作流程之前，通过本机生命周期控制保留数据。
应排除的备选方案
● S3 不支持 Snapshot 作为删除策略。
● 保留 RDS 会保留正在运行的实例及其费用。
● 删除这两个资源会破坏所需的数据。
● 跨区域复制可以创建另一个副本，但会添加未请求的存储和操作。
工作流：更新模板→检查变更→删除堆栈→验证保留桶→验证RDS快照→单独管理保留资产。
将 Route 53 DNS 查询转发到 Active Directory
VPC 工作负载可以使用 Amazon 提供的 DNS，同时将选定的 Active Directory 名称转发到域控制器。
推荐架构
● 创建 Route 53 解析器出站终端节点。
● 创建AD域的转发规则，如private.aws.com。
● 将两个域控制器 IP 地址配置为目标。
● 将规则与所需的 VPC 关联。
设计理由
● 技术可行性：出站终端节点将匹配的查询从 Route 53 解析程序发送到 AD DNS 服务器。
● 需求匹配：EC2 实例集中解析 AD 名称，无需更改每个主机的 DNS。
● 场景匹配：只有一个私有域需要转发。
● 工程常识：转发最窄的命名空间并提供多个 DNS 目标。
应排除的备选方案
● 每个客户端的拆分 DNS 设置会造成高度管理和偏差。
● 入站解析器端点接受对 VPC 的查询；它不会向外转发 VPC 查询。
● 另一个 DNS 服务器上的条件转发器不是此处所需的 Route 53 解析程序规则。
● 公共托管区域不应公开内部 AD 记录。
工作流：EC2 查询 → AmazonProvidedDNS → 转发规则匹配 → 出站终端节点 → AD DNS 响应。
医院应用程序的无状态扩展
高度可用的医院门户应该扩展应用程序容量和数据库读取，而不将用户状态保留在各个服务器上。
推荐架构
● 在跨可用区的 Auto Scaling 组中运行无状态 Web 和应用程序层。
● 使用 Elastic Load Balancing 进行请求分发。
● 将共享会话状态存储在 Amazon ElastiCache 中。
● 将 Amazon RDS 与只读副本结合使用以进行大量读取的数据库访问。
● 使用 CloudWatch 监控容量和运行状况。
设计理由
● 技术可行性：任何应用程序实例都可以服务请求，因为会话状态是外部化的。
● 需求匹配：Auto Scaling 增加了容量，而只读副本则减少了写入器负载。
● 场景匹配：医院信息中心在发展过程中需要持续可用性和可预测的响应。
● 工程常识：可替换计算不得拥有唯一的用户状态。
应排除的备选方案
● 有状态的应用程序服务器使负载平衡和替换变得不可靠。
● RDS 多可用区提高了数据库可用性，但不会扩展读取吞吐量。
● 增加一个实例大小会创建更大的故障域。
● 每台服务器上的本地缓存在替换过程中可能会出现分歧并消失。
工作流：请求→负载均衡器→无状态实例→共享缓存→写入器或读取副本。
在 EC2 上运行 Oracle RAC
当 Oracle RAC 必须保持自我管理时，请自动围绕集群进行基础架构备份和操作系统修补。
推荐架构
● 在 Amazon EC2 上部署支持的 Oracle 集群。
● 使用 Amazon Data Lifecycle Manager 进行计划的 EBS 快照。
● 使用 Systems Manager Patch Manager 获取已批准的操作系统补丁。
● 协调补丁波与集群故障转移和维护过程。
设计理由
● 技术可行性：DLM 自动化 EBS 快照策略，而补丁管理器则安装和报告操作系统更新。
● 需求匹配：该设计保留了 RAC，同时减少了重复的备份和修补操作。
● 场景匹配：托管 RDS 不提供所需的 RAC 架构。
● 工程常识：云自动化并不能消除了解数据库仲裁和节点顺序的需要。
应排除的备选方案
● RDS 多可用区提供托管可用性，但不是 Oracle RAC。
● AWS Backup 本身不会安装操作系统补丁。
● 手动快照和补丁脚本会增加错过的计划和不一致的节点。
● 用只读副本替换 RAC 会改变可用性和写入架构。
工作流：根据DLM策略进行快照→验证恢复点→排空一个节点→打补丁并测试→继续遍历集群节点。
用于本地和 Fargate 的一个 ECS 控制平面
当本地服务器参与生产所使用的相同 ECS 操作模型时，混合容器操作最简单。
推荐架构
● 使用 Amazon ECS Anywhere 将现有本地服务器注册为外部 ECS 实例。
● 通过 ECS 控制平面管理开发任务。
● 构建也可以在 AWS Fargate 上运行的任务定义和容器映像。
● 将经过验证的工作负载从本地开发提升到区域 Fargate 生产。
设计理由
● 技术可行性：ECS Anywhere 将 ECS 调度和 API 扩展到客户管理的服务器。
● 需求匹配：团队可以获得一致的工具和简单的工作负载迁移路径，同时重复使用现有的资本设备。
● 场景匹配：生产环境已使用 ECS Fargate，因此 ECS 是通用编排器。
● 工程常识：避免仅仅为了托管开发容器而引入 Kubernetes 或专用硬件。
应排除的备选方案
● EKS Anywhere 更改了编排平台，并且不创建一个 ECS 集群。
● AWS Outposts 需要额外的硬件投资，与节省成本的目标相冲突。
● Outposts 上的 ECS 不按请求的直接方式使用现有服务器。
工作流：注册外部实例→部署开发任务→测试镜像和任务定义→发布修订版→在Fargate上运行。
在有限带宽上批量 Redshift 迁移
60 TB 的初始传输无法满足 50 Mbps 分配的 30 天期限，因此批量数据和持续更改应使用不同的路径。
推荐架构
● 使用 AWS SCT 评估 Oracle 仓库并准备与 Redshift 兼容的提取和架构。
● 通过 AWS Snowball Edge 导入作业导出批量数据集。
● 将设备导入 Amazon S3。
● 将暂存数据加载到 Amazon Redshift 中。
● 使用 AWS DMS 复制持续的日常更改直至切换。
设计理由
● 技术可行性：Snowball 将初始数据集离线； DMS 通过网络承载小得多的变更流。
● 需求匹配：该方法可以在不消耗业务带宽或购买永久高容量链路的情况下满足截止日期。
● 场景匹配：日常变化很小，而初始仓库却非常大。
● 工程常识：将批量播种与增量同步分开。
应排除的备选方案
● 通过 RDS Oracle 暂存 60 TB 会增加成本，并且无法解决初始传输限制。
● 没有可靠的持续复制的 Snowball 工作流程可能会丢失每日更新。
● 配置 Direct Connect 和自我管理的 Oracle RAC 成本高昂、速度缓慢，而且超出了迁移需求。
工作流：转换→批量导出→发货→S3加载→DMS更改→协调→切换。
用于第三方白名单的稳定出站 IP
应用程序服务器可以通过 NAT 网关共享一个可预测的出站公共地址。
推荐架构
● 在公有子网中创建 NAT 网关。
● 关联弹性IP。
● 通过 NAT 网关路由专用应用程序子网。
● 将弹性 IP 提供给支付提供商以列入白名单。
设计理由
● 技术可行性：出站连接将转换为 NAT 网关的弹性 IP。
● 需求匹配：提供商看到稳定的源地址，而服务器保持私有。
● 场景匹配：该集成启动从应用程序服务器到第三方的连接。
● 工程常识：使用托管出口，而不是为每台服务器分配公共地址。
应排除的备选方案
● NAT 实例可以提供固定地址，但需要修补和故障转移管理。
● ELB 处理入站流量，并不集中服务器出口。
● Internet 网关不提供一个客户控制的共享源 IP。
● 客户网关是 VPN 端点，而不是正确的互联网出口服务。
工作流：私有服务器 → NAT 网关 → 弹性 IP 转换 → 支付端点 → 白名单接受连接。
使用 CloudFront 和 ALB 的端到端 HTTPS
CloudFront 和 ALB 源需要受信任的证书和策略来在两个连接上强制执行 HTTPS。
推荐架构
● 在 ACM 中为 ALB 导入或请求受信任的证书。
● 将 CloudFront 查看器协议策略配置为仅 HTTPS。
● 使用 CloudFront 自定义域支持的 ACM 或 IAM 证书。
● 将源协议设置为 HTTPS。
设计理由
● 技术可行性：CloudFront 验证受信任的原始证书并提供受信任的查看者证书。
● 需求匹配：传输链中的任何地方都不接受 HTTP。
● 场景匹配：零售应用程序在 ALB 之前使用 CloudFront。
● 工程常识：证书名称必须与查看者主机名和源主机名匹配。
应排除的备选方案
● CloudFront 不信任自签名源证书。
● 无法从 S3 导入查看者证书。
● 当查看器使用 HTTP 时，匹配查看器允许 HTTP。
● 仅在 CloudFront 处终止 TLS 会使源连接不受保护。
工作流：HTTPS 查看器 → CloudFront 证书 → HTTPS 源请求 → ALB 证书 → 应用程序。
服务多个 TLS 域
不同的客户端功能和不相关的域需要与每个端点匹配的证书传递方法。
推荐架构
● 当旧客户端不支持 SNI 时，请使用 CloudFront 专用 IP SSL。
● 为现代客户端使用具有多个证书和 SNI 的应用程序负载均衡器 HTTPS 侦听器。
设计理由
● 技术可行性：专用IP支持非SNI查看器； ALB 从请求的主机名中选择正确的证书。
● 需求匹配：单独的证书可以保护共享托管端点上的不相关域。
● 场景匹配：一些用户拥有旧版 TLS 客户端，而应用程序域仍然不同。
● 工程常识：仅在客户端兼容性需要时才支付专用 IP 交付费用。
应排除的备选方案
● 一份 SAN 证书可以涵盖已知名称，但不能直接保留单独的证书管理。
● Classic Load Balancer 不支持在一个侦听器上使用多个 SNI 证书。
● 通配符证书涵盖一个父域的子域，而不是不相关的域。
● 在每个后端安装证书会增加轮换和暴露工作。
工作流：查看器连接 → 端点确定 SNI 功能 → 专用 IP CloudFront 或 ALB 侦听器提供匹配的证书。
使用流响应 DynamoDB 更改
当应用程序行为必须遵循每个新的 DynamoDB 项目时，请使用表的本机更改流。
推荐架构
● 使用所需的图像视图启用 DynamoDB Streams。
● 将 AWS Lambda 配置为事件源使用者。
● 以幂等方式处理新条目记录。
● 监视迭代器寿命、错误、重试和死信处理。
设计理由
● 技术可行性：DynamoDB Streams 记录项目更改，Lambda 通过托管事件源映射轮询流。
● 需求匹配：每个表插入都可以触发下游处理，操作工作量较低。
● 场景匹配：感兴趣的事件是数据库突变，而不是 ECS 应用程序日志。
● 工程常识：在权威数据源捕获变化。
应排除的备选方案
● SNS 要求应用程序单独发布，并且可能会错过其他生产者的写入。
● Systems Manager 自动化适用于基础设施操作，而不是变更数据捕获。
● 迁移到 DocumentDB 无需更改数据库。
● 计划的表扫描会引入延迟和重复读取。
工作流：DynamoDB 写入 → 流记录 → Lambda 批处理 → 幂等操作 → 检查点和重试管理。
保护 RDS 免受闪购写入的影响
突然的销售可能会压垮关系数据库，除非对提交的内容进行持久缓冲并以受控的速率耗尽。
推荐架构
● 将销售提交放入 Amazon SQS。
● 从队列中调用 Lambda 消费者。
● 将并发限制在 RDS 可以维持的速率。
● 使用重试、幂等性和死信队列。
设计理由
● 技术可行性：SQS 吸收突发，Lambda 异步处理消息。
● 需求匹配：保留客户提交的内容，同时数据库负载保持受控。
● 场景匹配：该事件是暂时的，并不能证明数据库重新设计是合理的。
● 工程常识：持久队列保护写入；缓存则不然。
应排除的备选方案
● 垂直扩展需要有计划的更改，并且仍然将流量直接耦合到 RDS。
● Memcached 可能会逐出或丢失条目，并且不是持久的写入队列。
● 将 PostgreSQL 迁移到 DynamoDB 是一项重大范围变更。
● 同步重试会放大过载。
工作流：客户提交→消息进入SQS→Lambda在并发限制内消费→事务写入RDS→确认成功。
温备容灾
热备份可保持生产环境的功能性但规模缩小的副本，为快速扩展做好准备。
推荐架构
● 在恢复区域保持减少的应用程序群。
● 保持同步的备用数据库和当前应用程序工件。
● 持续监控复制和恢复运行状况。
● 在灾难期间，扩展备用环境并重定向流量。
设计理由
● 技术可行性：运行环境可以避免在事件发生期间构建每个组件。
● 需求匹配：热备用平衡了恢复速度和持续成本。
● 场景匹配：业务需要比备份和恢复更快的恢复速度，但无法证明完整的双活容量是合理的。
● 工程常识：恢复时间包括数据库升级、容量扩展、依赖性验证和 DNS 移动。
应排除的备选方案
● 完全重复的生产能力可以提供更快的恢复，但成本更高。
● 指示灯仅使核心组件保持运行，并且可能需要更长的时间来扩展和验证。
● 备份和恢复的稳定成本最低，但恢复时间最长。
● 多可用区本身可以防止可用区故障，但不能防止区域灾难。
工作流：持续复制→检测灾难→升级数据库→扩展应用程序→验证依赖关系→重定向流量→监控。
使用 S3 Sync 满足周末迁移截止日期
提前一周允许大多数数据在最后一个周末之前移动，只留下更改的文件进行切换。
推荐做法
● 在迁移前一周运行初始 S3 同步。
● 继续正常的源操作。
● 在周五运行最终的增量同步。
● 验证计数和校验和。
● 将 EC2 应用程序指向已完成的 S3 数据集。
设计理由
● 技术可行性：S3 同步仅传输最后一次丢失或更改的对象。
● 需求匹配：1 TB 迁移获得了进度裕度，可以在周日完成。
● 场景匹配：可以在源保持在线的情况下复制数据集。
● 工程常识：尽早播种并预留增量和验证的中断窗口。
应排除的备选方案
● 在周末复制完整的数据集几乎没有余地。
● 网关快照工作流程为此文件移动添加了不必要的步骤。
● 从周六开始，就有可能错过最后期限。
● Snowball 订购、运输、导入和恢复无法在一个周末内可靠地完成。
工作流：初始同步→源更改→最终增量同步→验证→应用程序切换。
SSE-S3 如何保护对象
使用 S3 托管密钥的 Amazon S3 服务器端加密使用单独的数据密钥对每个对象进行加密。
加密模型
● S3 为每个对象生成唯一的数据密钥。
● 该对象使用该数据密钥进行加密。
● 数据密钥在 S3 管理的根密钥或主密钥下进行加密。
● S3 定期轮换主密钥材料并管理整个密钥生命周期。
● 对于授权请求，解密是透明发生的。
设计理由
● 技术可行性：信封加密限制每个对象数据密钥的范围，同时集中保护这些密钥。
● 需求匹配：数据静态加密，无需客户存储或轮换加密密钥。
● 场景匹配：要求是托管 S3 加密，而不是客户控制的密钥策略或审计分离。
● 工程常识：加密不会取代 IAM、存储桶策略、版本控制或传输安全性。
应排除的错误假设
● 一个明文密钥不会直接为每个对象重用。
● 客户不下载 S3 主密钥。
● SSE-S3与SSE-KMS不同，SSE-S3客户可以控制KMS权限并审核密钥使用。
● 服务器端加密不会自动将公共存储桶设为私有。
工作流：授权 PUT → S3 创建数据密钥 → 加密对象 → 包装密钥 → 存储密文 → 在授权 GET 上解密。
公共 S3 对象的实时警报
当使用公共读取访问权限上传对象时，合规性可以立即收到通知。
推荐架构
● 为 PutObject 启用 CloudTrail S3 数据事件。
● 创建与公共读取 ACL 请求匹配的 EventBridge 规则。
● 将匹配事件发布到 SNS 主题。
设计理由
● 技术可行性：CloudTrail记录对象级API参数，EventBridge过滤事件，SNS推送警报。
● 需求匹配：检测是事件驱动的，而不是通过轮询延迟的。
● 场景匹配：该风险发生在对象上传过程中。
● 工程常识：针对与策略违规最接近的权威 API 事件发出警报。
应排除的备选方案
● 每小时轮询会延迟响应。
● Systems Manager 自动化对于直接通知来说是不必要的。
● Lex 是对话式人工智能。
● GuardDuty 和 Trusted Advisor 不会通过建议的工作流程识别此 ACL 事件。
● CDK 部署基础设施，而不是运行时检测器。
工作流：公开读取 PUT → CloudTrail 数据事件 → EventBridge 匹配 → SNS 合规警报。
移动应用程序的临时每用户 S3 访问
移动应用程序应该对用户进行身份验证并颁发短期的、限定范围的 AWS 角色凭证以进行直接 S3 访问。
推荐架构
● 通过应用程序的身份系统对用户进行身份验证。
● 将每个身份映射到 IAM 角色或范围会话。
● 使用 AWS STS 颁发临时凭证。
● 按用户上下文限制 S3 前缀和操作。
设计理由
● 技术可行性：移动 SDK 可以使用临时 STS 凭证来签署 S3 请求。
● 需求匹配：每个用户只能访问经过批准的对象，而无需共享一个永久密钥。
● 场景匹配：分布式客户端需要大规模的直接对象访问。
● 工程常识：不受信任设备上的凭证必须是短暂的且范围狭窄。
应排除的备选方案
● 嵌入 IAM 用户密钥会向每个安装公开相同的长期秘密。
● STS 不会颁发永久凭证，并且缓存的会话会过期。
● 静态手机钥匙难以旋转，无法安全隔离用户。
● 公共存储桶访问删除了用户级别的授权。
工作流：用户登录 → 身份验证 → STS 角色会话 → 限定范围的 S3 请求 → 凭证自动过期。
使用 S3 和 CloudFront 扩展每日分析报告
应从数据库生成经常读取的报告，然后将其用作持久的静态工件，而不是重复查询数据库。
推荐架构
● 维护多可用区 Amazon RDS for MySQL 中的源数据。
● 在适当的情况下，将只读副本用于报告生成工作负载。
● 在预定的批处理过程中生成报告。
● 将完成的报告存储在 Amazon S3 中。
● 使用每日 TTL 通过 CloudFront 缓存和分发它们。
设计理由
● 技术可行性：S3 持久存储报告文件，而 CloudFront 吸收数百万个全局读取请求。
● 需求匹配：每日刷新使缓存过期与报告生成保持一致，并降低数据库成本。
● 场景匹配：统计报告的阅读次数远多于其更改次数。
● 工程常识：计算一次，存储一次，分发多次。
应排除的备选方案
● 每天重建和删除 DynamoDB 表会增加不必要的操作。
● ElastiCache 不是持久的报告存储。
● 直接从 RDS 提供数千万个报表查询的可扩展性较差且成本较高。
● 只读副本可保护写入者免受报告生成的影响，但不应成为公共报告交付层。
工作流：更新源数据 → 生成报告 → 写入 S3 → 使缓存失效或过期 → 通过 CloudFront 提供服务。
CloudFront HTTPS 和缓存效率
自定义 CloudFront 域需要可信证书和缓存指令，以将可重用对象保留在边缘位置。
推荐架构
● 在 us-east-1 中为 CloudFront 主机名请求 ACM 证书。
● 将其附加到发行版中。
● 为安全的可缓存对象设置一个长实用的 Cache-Control: max-age 。
设计理由
● 技术可行性：CloudFront 使用来自 us-east-1 的 ACM 证书；原始缓存标头影响边缘保留。
● 需求匹配：托管 TLS 可保护自定义域，而较长的 TTL 可提高缓存命中率并减少源流量。
● 场景匹配：内容可以被缓存并且不需要每个请求处理。
● 工程常识：仅缓存新鲜度和隐私允许重复使用的内容。
应排除的备选方案
● 在 S3 中存储证书不会将其附加到 CloudFront 并创建私钥处理。
● OpenSearch 不是 CDN 缓存。
● Lambda@Edge 增加了成本和延迟，但没有解决基本的证书和 TTL 要求。
● 非常短的 TTL 会强制产生不必要的源请求。
工作流：查看器 HTTPS → CloudFront 验证证书 → 边缘检查新鲜度 → 提供缓存对象或请求源。
保留失败的 Auto Scaling 实例以供诊断
自动修复可以消除诊断失败部署所需的确切证据。
推荐流程
● 暂时暂停 Auto Scaling 组的 Terminate 进程。
● 允许不健康的实例保持可用。
● 通过 AWS Systems Manager 会话管理器进行连接。
● 检查进程状态、侦听端口、依赖项、配置和本地日志。
● 更正启动模板、AMI 或应用程序包，然后恢复终止。
设计理由
● 技术可行性：暂停该进程会阻止 Auto Scaling 删除不正常的实例，同时 Session Manager 会提供私有管理访问权限。
● 需求匹配：这是到达原始故障环境的最快途径。
● 场景匹配：这些实例已具有 SSM 代理，并且不需要 SSH 公开。
● 工程常识：短暂暂停修复，收集证据，修复不可变的源头，然后恢复正常愈合。
应排除的备选方案
● 单独创建的测试实例可能无法重现确切的故障并增加设置时间。
● 更详细的日志记录无法保留足够长的实例以供检查。
● EC2 终止保护不会阻止 Auto Scaling 终止其管理的实例。
工作流：暂停→检查→重现→纠正→启动替换→验证运行状况→恢复。
适用于 Python 和 TypeScript 团队的 AWS CDK
AWS CDK 允许团队使用熟悉的语言定义基础设施，同时标准化 CloudFormation 上的部署。
推荐架构
● 使用 Python 和 TypeScript 构建 CDK 应用程序。
● 合成 CloudFormation 模板。
● 在 CodeBuild 中运行验证和综合。
● 通过 CodePipeline 协调推广。
设计理由
● 技术可行性：CDK 支持这两种语言并生成本机 CloudFormation 部署。
● 需求匹配：团队在共享一个基础设施工作流程的同时保留了他们的编码技能。
● 场景匹配：现有的部署逻辑分为 Python 和 TypeScript。
● 工程常识：标准化部署引擎，而不强迫每个团队使用一种编程语言。
应排除的备选方案
● 将脚本手动重写到模板中会增加不必要的转换。
● EC2 用户数据不是基础设施配置引擎。
● OpsWorks 和 Chef 引入了不同的配置模型。
● 当 CDK 已经适合两种语言时，第三方工具会添加依赖项。
工作流：编写CDK→测试→综合→检查模板→通过管道部署。
通过 VPN 故障转移直接连接
注重成本的混合设计可以使用一个专用主电路和一个互联网 VPN 进行备份。
推荐架构
● 使用 Direct Connect 作为首选路径。
● 创建托管站点到站点 VPN 作为冗余连接。
● 配置路由首选项，使 Direct Connect 成为主要的。
● 测试退出和故障转移行为。
设计理由
● 技术可行性：当 Direct Connect 路由消失时，动态路由会选择 VPN。
● 需求匹配：主路径是可预测的，而备份成本仍然低于第二专用电路。
● 场景匹配：该公司接受故障期间较低的备份性能。
● 工程常识：备份不得依赖于同一个发生故障的物理电路。
应排除的备选方案
● 一个 Direct Connect 会留下物理单点故障。
● VPN CloudHub 加入 VPN 站点，不提供专用的主路径。
● 同一 Direct Connect 上承载的 VPN 在该电路上仍然失败。
● 静态路由可能会减慢自动故障转移速度或使其复杂化。
工作流：正常流量使用专线 → 电路路由撤销 → VPN 路由选择 → 服务继续。
使用 SQS 进行长时间运行的批处理
长时间的数据处理作业需要持久的队列、弹性的工作线程和持久的输出存储。
推荐架构
● 将工作项目放入 Amazon SQS 中。
● 根据队列长度扩展 EC2 工作线程。
● 将处理后的文件存储在 Amazon S3 中。
● 配置可见性超时、重试和死信队列。
设计理由
● 技术可行性：SQS 将生产者解耦，Auto Scaling 跟踪积压工作，S3 将输出存储在工作人员之外。
● 需求匹配：该设计能够经济高效地处理可变的长作业。
● 场景匹配：处理可能会超出 Lambda 持续时间或资源限制。
● 工程常识：切勿依赖手动服务器关闭来实现弹性。
应排除的备选方案
● Amazon MQ 和 EFS 可以工作，但会添加代理和文件系统操作。
● 将 MQ 队列与读取 SQS 的 Lambda 使用者混合在一起是不一致的。
● Lambda 可能会超出运行时限制。
● 对于已完成的对象输出，EFS 的操作不如 S3 简单。
工作流：提交作业 → SQS → 工作队列规模 → 处理 → 写入 S3 结果 → 删除消息。
将应用程序日志转化为即时警报
操作警报需要集中日志、可测量的错误信号、阈值和通知操作。
推荐架构
● 在本地服务器上安装 CloudWatch 代理。
● 将应用程序日志发送到 CloudWatch Logs。
● 为相关错误模式创建指标过滤器。
● 针对生成的指标创建 CloudWatch 警报。
● 通过配置的警报动作通知运营团队。
设计理由
● 技术可行性：指标过滤器将匹配的日志条目转换为警报可以评估的数字 CloudWatch 指标。
● 需求匹配：该设计会聚合日志、自动分析并在超出阈值后立即发出警报。
● 场景匹配：该公司需要从应用程序错误中获得可操作的见解，而不是一般的商业情报报告。
● 工程常识：对定义的服务症状发出警报并保留底层日志以供诊断。
应排除的备选方案
● Kinesis 代理和 QuickSight 添加了流媒体和可视化组件，但没有简化警报。
● CloudWatch Events 不是日志存储目标。
● Athena 基于查询，不会持续监视指标过滤器。
● Prometheus 的托管服务未作为通用日志代理安装，并且 Lambda 转换添加了不必要的自定义代码。
工作流：日志事件 → CloudWatch Logs → 指标过滤器 → 警报阈值 → 操作通知 → 调查。
一个 EC2 原型上的多个网络身份
单个原型实例可以通过单独的 IP 身份公开组件，而无需跨越可用区。
推荐架构
● 将多个弹性网络接口附加到 EC2 实例。
● 为 ENI 分配不同的私有 IP 地址。
● 在需要公共静态身份的地方关联弹性 IP 地址。
● 将合适的安全组应用于每个接口。
设计理由
● 技术可行性：多个 ENI 提供单独的网络身份，而实例保留在一个可用区中。
● 需求匹配：每个组件都可以绑定到一台原型主机上自己的地址。
● 场景匹配：该设计是原型，因此可能不需要单独的实例。
● 工程常识：独立的IP标识并不等于故障隔离；生产可能仍然需要独立主机。
应排除的备选方案
● 安全组会过滤流量，但不会创建额外的 IP 身份。
● NAT 提供地址转换，而不是多个入站组件身份。
● 一个 ENI 无法连接到两个可用区中的子网。
● EC2 实例不能跨可用区。
工作流：创建 ENI → 分配地址和安全组 → 附加到实例 → 绑定每个组件 → 测试路由。
OpsWorks 的蓝/绿交付
单独的 OpsWorks 堆栈提供隔离的蓝色和绿色环境，用于验证和快速回滚。
推荐架构
● 克隆当前 OpsWorks 堆栈。
● 将新的 Chef 和应用程序修订版部署到绿色堆栈。
● 独立验证。
● 使用现有路由层转移流量。
● 保留蓝色以供回滚。
设计理由
● 技术可行性：独立堆栈可防止更改服务实例。
● 需求匹配：该设计支持受控切换和快速恢复。
● 场景匹配：该应用程序已使用 OpsWorks 和 Chef。
● 工程常识：部署工具应与正在运行的平台相匹配。
应排除的备选方案
● Elastic Beanstalk 滚动部署改变了平台并修改了服务容量。
● CodePipeline 编排各个阶段，但本身并不提供建议的 EC2 滚动策略。
● CodeBuild 构建和测试工件；不是引流部署服务。
● 就地 Chef 更新削弱了回滚。
工作流：克隆蓝色 → 部署绿色 → 测试 → 转移流量 → 监控 → 如果需要，返回蓝色。
低成本照片处理和存档
照片处理是异步、并行的，并且可以容忍工作人员中断，因此适合排队的 Spot 容量。
推荐架构
● 将照片处理作业放置在 Amazon SQS 中。
● 根据队列深度扩展 EC2 Spot 工作线程。
● 将活动输入存储在适当的在线对象类中。
● 当不再需要立即访问时，将完成的照片存档到 S3 Glacier。
设计理由
● 技术可行性：SQS 保留作业并允许其他工作人员在中断后重试。
● 需求匹配：Spot 降低了计算成本，而 Glacier 则降低了长期归档成本。
● 场景匹配：工人们争夺独立摄影工作。
● 工程常识：将持久的输入和输出保留在一次性工人之外。
应排除的备选方案
● 将未处理的照片移至 Standard-IA 会在立即处理之前产生检索费用。
● SNS 不提供持久的竞争消费者积压或队列深度扩展信号。
● 手动终止工作线程比 Auto Scaling 弱。
● 对于很少检索的长期成品档案，Standard-IA 的经济性不如 Glacier。
工作流：上传→SQS作业→Spotworker→结果存储→归档转换→worker缩小规模。
可重复的高可用性问题跟踪
生产问题跟踪器需要可重复的基础设施、弹性应用程序容量、持久的内容交付和托管数据库故障转移。
推荐架构
● 在 AWS CloudFormation 中定义环境。
● 跨可用区在 Auto Scaling 组中运行应用程序实例。
● 在实例之前放置弹性负载均衡器。
● 使用 CloudFront 获取可缓存内容。
● 在 RDS 多可用区上运行 OLTP 数据库。
设计理由
● 技术可行性：CloudFormation 重现堆栈，Auto Scaling 取代不健康的计算，RDS 多可用区提供托管备用故障转移。
● 需求匹配：该服务可扩展并保持可用，只需很少的手动恢复工作。
● 场景匹配：问题跟踪是事务性的，需要关系型 OLTP 数据库。
● 工程常识：保持应用程序实例无状态并将持久状态存储在托管服务中。
应排除的备选方案
● 单个 EC2 实例或数据库会创建故障点。
● 仅读取副本不提供写入器故障转移。
● 在实例磁盘上托管持久上传会使替换变得复杂。
● 手动基础设施部署会导致配置漂移和恢复缓慢。
工作流：路由请求 → CloudFront 或负载均衡器 → Auto Scaling 实例 → RDS 主实例；故障时提升备用。
测试 CI/CD 中的 CloudFormation 更改
基础设施更改应在 CloudFormation 执行之前进行测试和预览。
推荐架构
● 从 GitHub 更改触发 CodePipeline。
● 使用 CodeBuild 进行测试和模板验证。
● 创建 CloudFormation 更改集。
● 使用 CloudFormation 操作查看或自动执行批准的更改集。
设计理由
● 技术可行性：CodePipeline 协调源、构建和 CloudFormation 部署阶段。
● 需求匹配：更改是可重复的，并且其资源影响在执行前可见。
● 场景匹配：源包含 CloudFormation 模板。
● 工程常识：拥有资源更改的服务应该执行它。
应排除的备选方案
● 正常模板部署不需要 Lambda 和 CodeArtifact。
● CodeArtifact 是一个包存储库，而不是自然的模板执行服务。
● CodeDeploy 部署应用程序修订版，无法执行 CloudFormation 更改集。
● 不经过测试直接更新会削弱安全性。
工作流：GitHub 提交 → CodePipeline → CodeBuild 测试 → 更改集 → 批准 → CloudFormation 执行。
两个基本的 EC2 IAM 角色策略
EC2 角色需要权限策略和信任策略。
所需策略
● 附加授予所需 S3 对象操作的权限策略。
● 配置角色信任策略，以便 EC2 服务主体可以代入该角色。
● 通过实例配置文件附加角色。
设计理由
● 技术可行性：信任策略确定谁可以担任该角色，权限策略定义会话可以执行哪些操作。
● 需求匹配：Node.js 应用程序接收临时 S3 访问权限。
● 场景匹配：EC2 是工作负载身份。
● 工程常识：信任和权限回答不同的授权问题。
应排除的备选方案
● 可能还需要存储桶策略，但它不会取代角色自己的权限和信任链。
● 该应用程序不是 IAM 服务主体。
● EC2 承担其实例角色；它并不首先承担单独的 S3 角色。
● 静态 IAM 用户密钥是不必要的。
工作流：EC2 承担角色 → 元数据提供临时凭证 → 角色权限授权 S3 请求。
加速小文件的雪球传输
数百万个小文件可能无法充分利用 Snowball 带宽，因为每个文件的加密和元数据工作成为瓶颈。
推荐做法
● 对 Snowball Edge 设备运行多个并行复制会话。
● 在工作人员之间分发源目录。
● 保持每个worker的文件列表独立以避免重复写入。
● 监控总吞吐量和设备利用率。
● 验证传输的文件计数和校验和。
设计理由
● 技术可行性：并行客户端重叠每个文件的处理并增加总吞吐量。
● 需求匹配：迁移可以更快地完成，无需更改数据集或购买其他传输方法。
● 场景匹配：问题是许多小文件，而不是原始设备容量不足。
● 工程常识：仅在源磁盘、网络、CPU 或设备限制达到饱和之前增加并发性。
应排除的备选方案
● 将所有内容压缩到一个存档中会改变处理方式，并且可能需要额外的临时空间和处理。
● 更快的 WAN 并不能改善设备的本地复制瓶颈。
● 按顺序复制文件可以避免每个文件的开销问题。
● 无需重新格式化设备，并且存在重新启动工作的风险。
工作流：分区文件列表→启动并行复制工作→监视吞吐量→重试失败→协调文件计数→返回设备。
从 EC2 安全访问 DynamoDB
EC2 应用程序应通过实例配置文件而不是嵌入式访问密钥来获取临时 DynamoDB 权限。
推荐架构
● 创建受 EC2 服务信任的 IAM 角色。
● 为所需的 DynamoDB 表操作附加最低权限策略。
● 将角色放置在实例配置文件中。
● 使用该配置文件启动或更新应用程序实例。
● 让 AWS 开发工具包自动检索临时凭证。
设计理由
● 技术可行性：EC2 通过实例元数据服务向授权本地软件公开轮换角色凭证。
● 需求匹配：应用程序访问 DynamoDB 时无需在代码或配置中存储静态密钥。
● 场景匹配：三层应用程序从其计算层执行 AWS API 调用。
● 工程常识：将权限绑定到工作负载身份并将其范围限制到确切的表和操作。
应排除的备选方案
● 硬编码的 API 密钥可能会泄漏并且需要手动轮换。
● IAM 用户不能像角色一样附加到 EC2 实例。
● 在此设计中，DynamoDB 资源策略并不是工作负载角色凭证的正常替代。
● 授予管理员访问权限违反了最低权限。
工作流：EC2 使用配置文件启动 → SDK 获取临时凭证 → 签署 DynamoDB 请求 → IAM 评估角色策略 → 凭证自动轮换。
通过备份和事务日志进行经济有效的恢复
恢复目标应确定备份频率、事务日志频率和存储层。
推荐架构
● 创建定期数据库备份并将其存储在 Amazon S3 中。
● 每五分钟将事务日志导出到单独的 S3 位置。
● 恢复期间恢复最新的备份和重播日志。
● 使用 Amazon Macie 发现 S3 中存储的敏感数据并对其进行分类。
设计理由
● 技术可行性：基础备份加上频繁的日志可以重建靠近故障点的数据库。
● 需求匹配：五分钟的日志适合 15 分钟的 RPO，而 S3 检索比归档存储更适合支持三小时以内的恢复目标。
● 场景匹配：该应用程序使用 RDS MySQL 并包含交付、交易和潜在的敏感数据。
● 工程常识：RPO控制数据采集频率； RTO 控制检索和恢复备份的速度。
应排除的备选方案
● AWS 托管的数据库备份路径不需要 Storage Gateway。
● 多可用区是高可用性，而不是单独的灾难恢复备份。
● AWS Shield 不会发现 PII。
● 冰川恢复可能会使短期恢复目标变得困难。
工作流：备份→捕获日志→安全存储→检测敏感对象→恢复基础→重放日志→验证服务。
SCP 允许列表必须允许所有操作
根据 SCP 允许列表策略，必须在每个适用的组织级别允许某个操作，然后 IAM 权限才能使用该操作。
关键行为
● SCP 定义成员帐户主体的最大权限。
● IAM 策略仅在该最大值内授予权限。
● S3 存储桶创建必须出现在从根到 OU 和帐户的适用允许列表 SCP 中。
设计理由
● 技术可行性：有效权限是 SCP 边界和 IAM 授权的交集。
● 需求匹配：添加缺少的 S3 允许可以解决拒绝问题，而无需更改不相关的权限。
● 场景匹配：IAM 身份已具有 S3 权限，但 SCP 对其进行限制。
● 工程常识：解决从外护栏向内授权的问题。
应排除的备选方案
● IAM 允许无法覆盖丢失的 SCP 允许。
● SCP 支持允许列表和拒绝列表策略。
● IAM 和 SCP 文档不必相同。
● 添加更多 IAM 策略无法扩展到 SCP 边界之外。
工作流：请求 → 根 SCP → OU SCP → 账户 SCP → IAM 策略 → 资源策略和条件。
跨环境推广操作系统补丁
关键补丁应在生产前经过开发和测试，并使用单独的基线来保留每个环境的策略。
推荐架构
● 按环境和操作系统标记每个实例。
● 为开发、测试和生产创建单独的 Systems Manager Patch Manager 基线。
● 使用这些标签将实例映射到补丁组。
● 立即进行补丁开发和测试。
● 仅在验证后才生产补丁。
设计理由
● 技术可行性：补丁组将标记的实例与批准的补丁基准相关联。
● 需求匹配：特定于环境的控制可防止未经验证的补丁进入生产。
● 场景匹配：每个环境都有不同的基线要求。
● 工程常识：在获得稳定性证据后，应在日益关键的环境中推广相同的工件。
应排除的备选方案
● 仅操作系统标签无法区分生产和非生产队列。
● 维护窗口控制时间，但不定义每个环境批准哪些补丁。
● 自定义 shell 脚本和 Run Command 重复托管修补功能，并且需要持续维护。
工作流：标记→定义基线→补丁开发→验证→补丁测试→验证→批准生产基线→补丁生产→审查合规性。
在 CloudFront 缓存查找之前规范化查询字符串
当参数顺序或字母大小写不改变响应时，等效查询字符串应映射到一个缓存键。
推荐架构
● 根据查看者请求使用 Lambda@Edge。
● 规范批准的参数名称、值、顺序和大小写。
● 将规范查询字符串转发到 CloudFront 缓存查找。
● 保留合法更改内容的参数。
设计理由
● 技术可行性：查看器请求边缘代码在缓存键评估之前运行，并且可以重写请求。
● 需求匹配：更多语义相同的请求成为缓存命中。
● 场景匹配：客户端以不一致的形式发送等效的查询字符串。
● 工程常识：规范化规则必须与应用程序语义相匹配。
应排除的备选方案
● 忽略所有查询参数可能会提供不正确的内容。
● CloudFront 没有简单的通用的不区分大小写的标准化开关。
● 源端标准化发生在缓存未命中之后，因此不能有效地改进初始缓存查找。
● 转发每个非标准化变体都会使缓存碎片化。
工作流：查看器请求 → Lambda@Edge 规范化 → CloudFront 计算缓存密钥 → 命中或原始获取。
停止与 CloudFront 的 S3 热链接
私有 S3 源访问和过期的 CloudFront 签名 URL 会阻止直接对象访问并限制链接重用。
推荐架构
● 从 S3 存储桶中删除公共访问权限。
● 仅允许 CloudFront 源身份或源访问控制。
● 要求签名 URL 具有较短且适当的过期时间。
● 仅向授权用户分发链接。
设计理由
● 技术可行性：用户无法绕过 CloudFront，并且过期的签名将停止以后的重用。
● 需求匹配：减少未经授权的盗链和直接 S3 下载。
● 场景匹配：内容通过 CloudFront 交付。
● 工程常识：查看者授权和来源保护必须同时存在。
应排除的备选方案
● S3 没有安全组。
● 阻止网站 IP 很脆弱，并且会影响合法用户。
● Web 服务器上的 EBS 会降低耐用性并产生瓶颈。
● 静态 IP 拒绝列表无法可靠地识别每个盗链站点。
工作流：授权应用程序发出签名 URL → 查看器请求 CloudFront → 检查签名 → 读取私有 S3 源 → URL 过期。
使用 CloudFront 立即卸载
与完整的应用程序和数据库迁移相比，较短的准备窗口更有利于边缘缓存。
推荐架构
● 将 CloudFront 放置在本地网站之前。
● 缓存静态且安全可重用的内容。
● 调整促销期间的 TTL。
● 在现有来源保留动态游戏商店交易。
设计理由
● 技术可行性：CloudFront 可以使用本地站点作为源并吸收重复的全局请求。
● 需求匹配：该解决方案以最少的应用程序更改快速减少源流量。
● 场景匹配：出售迫在眉睫，动态交易必须继续进行。
● 工程常识：解决眼前的瓶颈，而不是开始冒险的全面迁移。
应排除的备选方案
● S3 静态故障转移无法保留动态事务。
● 混合 ALB 设计需要专用连接和重复的服务器。
● 完整的虚拟机和 Oracle 迁移对于时间线来说太大了。
● 销售期间的数据库转换会带来可避免的风险。
工作流：用户 → CloudFront → 可缓存内容的边缘命中 → 仅在未命中或动态请求时进行本地源。
通过 Snowball 和 VPN Catch-Up 进行批量数据库迁移
超过 50 Mbps 的 25 TB 初始数据库传输需要离线批量移动，然后通过网络复制更改。
推荐架构
● 将初始数据库数据集导出到 Snowball。
● 将批量数据发送并导入到 AWS 中。
● 使用基于 VPN 的复制来处理运输过程中生成的更改。
● 同步后切换到 Aurora。
设计理由
● 技术可行性：Snowball 处理大型种子，而较小的变更流则适合 VPN。
● 需求匹配：该设计减少了网络使用量和应用程序停机时间。
● 场景匹配：源在迁移过程中持续增长。
● 工程常识：将大量播种与正在进行的三角洲分开。
应排除的备选方案
● 通过 50 Mbps 发送整个 25 TB 的时间太长。
● VM Import/Export 移动机器映像，而不是高效的实时数据库工作流程。
● 在 Snowball 运输周期中停止应用程序会导致过多的停机时间。
● 没有追赶的批量导入会丢失更改。
工作流：导出种子 → 滚雪球运输 → 加载目标 → 复制 VPN 增量 → 验证 → 切换。
HPC 网络和并行存储
紧密耦合的模拟需要低延迟的节点通信、紧密的物理布局和高吞吐量的共享文件系统。
推荐架构
● 在支持的 EC2 实例上使用 Elastic Fabric Adapter。
● 将计算节点放置在一个可用区内的集群置放群组中。
● 使用 Amazon FSx for Lustre 并行访问数千个大型模拟文件。
设计理由
● 技术可行性：EFA 支持 HPC 通信，集群布局可最大限度地减少网络延迟，FSx for Lustre 提供并行文件系统吞吐量。
● 需求匹配：组合设计加速了节点间通信和共享数据访问。
● 场景匹配：工作负载是紧密耦合的，而不是独立的批处理。
● 工程常识：优化整个工作流程；快速计算网络无法弥补串行存储。
应排除的备选方案
● RAID 0 EBS 是实例本地的，不是共享并行文件系统。
● 跨可用区分布节点会增加延迟。
● 多个 ENI 不会像 EFA 那样聚合带宽。
● 每个实例的磁盘使共享模拟数据和恢复变得复杂。
工作流：调度程序将节点放置在一起 → EFA 承载节点间流量 → FSx for Lustre 提供共享文件 → 结果保留。
将 Web 健康状况与数据库健康状况分开
Web 层健康检查应该测试 Web 进程，而不会导致数据库过载而触发实例更换风暴。
推荐架构
● 将 ALB 目标健康检查更改为简单的静态 HTTP 页面。
● 添加 Amazon ElastiCache 以应对频繁重复的数据库查询。
● 通过 Route 53 运行状况检查单独监控依赖于数据库的应用程序端点。
● 当端到端检查失败时提醒管理员。
设计理由
● 技术可行性：静态运行状况检查验证 Web 服务器，而 ElastiCache 则减少重复的 RDS 读取。
● 需求匹配：Auto Scaling 停止替换运行状况良好的 Web 实例，数据库可以处理更多流量。
● 场景匹配：RDS CPU 饱和而不是 Web 服务器故障导致了超时。
● 工程常识：用于更换的运行状况检查应隔离被更换的组件。
应排除的备选方案
● 重新启动过载的数据库并不能解决持续的需求。
● 如所述，建议的 RDS MySQL 单读取器端点无效。
● TCP 检查仅证明端口接受连接，并且比简单的 HTTP 页面弱。
工作流：ALB 检查静态页面 → Route 53 检查完整事务 → 缓存吸收读取 → 警报报告数据库路径故障。
将 TLS 密钥保存在 CloudHSM 中
敏感的 TLS 私钥应保留在硬件安全模块内，同时应用程序日志保持持久性和访问控制。
推荐架构
● 使用 TCP 负载平衡，以便 TLS 到达应用程序和 HSM 集成，而无需负载平衡器终止。
● 使用 AWS CloudHSM 进行私钥操作。
● 部署 HSM 容量以实现可用性。
● 将加密日志存储在私有 S3 存储桶中。
● 通过 IAM 和密钥策略限制日志解密。
设计理由
● 技术可行性：CloudHSM 执行加密操作而不导出私钥材料，并且 S3 提供持久的加密日志记录。
● 需求匹配：管理员不能随意复制 TLS 密钥，而授权用户可以访问日志。
● 场景匹配：混合应用程序具有严格的密钥保管和审计要求。
● 工程常识：密钥存储、TLS 执行和日志存储是独立的安全问题。
应排除的备选方案
● 将密钥上传到网络服务器使其可移动。
● 实例存储日志不持久。
● 单个 HSM 会产生可用性风险。
● 标准负载均衡器 TLS 卸载不满足客户控制的 HSM 托管要求。
工作流：客户端 TLS → TCP 负载均衡器 → HSM 支持的操作 → 应用程序 → 加密的 S3 日志 → 授权审核访问。
带弹性豆茎的蓝色/绿色版本
托管蓝/绿版本保持当前环境可用，同时独立验证新版本。
推荐架构
● 克隆或创建第二个 Elastic Beanstalk 环境。
● 在那里部署并测试新的应用程序版本。
● 验证成功时交换环境 CNAME。
● 暂时保留旧环境以进行回滚。
设计理由
● 技术可行性：两个环境同时运行，CNAME 交换会重定向用户而无需重建 URL。
● 需求匹配：部署没有计划停机，回滚速度很快。
● 场景匹配：该应用程序已使用 Elastic Beanstalk。
● 工程常识：在流量移动之前验证确切的生产工件。
应排除的备选方案
● 强制 Auto Scaling 替换缺乏干净的分阶段环境和即时 URL 交换。
● Lightsail 和加权 DNS 引入了不相关的基础设施。
● 立即替换所有实例会删除受控验证。
● 就地更新会增加回滚风险。
工作流：构建绿色 → 部署版本 → 测试 → 交换 CNAME → 监控 → 如果需要则交换回来 → 退出蓝色。
启用版本控制后了解 S3 版本 ID
在启用 S3 版本控制之前创建的对象的行为与之后创建的版本不同。
关键行为
● 在版本控制之前存在的对象具有 null 版本 ID。
● 在版本控制后更新该对象会创建一个带有生成的版本 ID 的新版本。
● 除非删除，否则原始 null 版本仍然可用。
● 版本控制后从未更新的对象仍然只有原始 null 版本。
设计理由
● 技术可行性：S3 使用相同的密钥维护早期的对象版本。
● 需求匹配：版本历史记录解释了哪些配置文件具有一个或两个可检索版本。
● 场景匹配：有些文件在版本控制后进行了更新，而另一些则没有。
● 工程常识：版本 ID 是不透明的标识符，而不是按时间顺序排列的序列号。
应排除的错误假设
● 启用版本控制不会将生成的 ID 追溯分配给现有对象。
● 版本 ID 不可预测或连续。
● 更新旧对象不会替换其原始 null 版本；它添加了一个新版本。
● 未更改的预版本控制对象不会自动获得第二个版本。
工作流：预版本控制对象→启用版本控制→更新密钥→保留空版本加上新生成的版本。
通过 PowerUserAccess 进行开发人员访问
应用程序开发人员通常需要广泛的服务创建权限，但无法管理 IAM 或组织。
推荐控制
● 当 AWS 托管 PowerUserAccess 策略的范围与开发角色匹配时，分配该策略。
● 为公司特定的护栏添加更窄的拒绝或权限边界。
● 与平台或安全团队一起进行 IAM 和组织管理。
设计理由
● 技术可行性：PowerUserAccess 允许使用大多数 AWS 服务，同时保留广泛的身份管理。
● 需求匹配：开发人员无需完全帐户控制即可构建和配置应用程序。
● 场景匹配：团队需要开发自主权，而不是运营或安全管理。
● 工程常识：管理政策是起点；在生产使用之前检查其当前权限。
应排除的备选方案
● AdministratorAccess 不受限制且权限过高。
● 将 AdministratorAccess 包装在角色中不会减少其权限。
● SystemAdministrator 面向运营管理，与应用程序开发不太一致。
● 授予临时 IAM 权限可以允许升级。
工作流：开发人员承担角色 → 创建应用程序资源 → IAM 管理仍被拒绝 → CloudTrail 记录操作。
监控 AWS Organizations 的更改
组织成员资格和政策变更需要权威的 API 历史记录和持续的合规性评估。
推荐架构
● 创建记录 AWS Organizations 控制台和 API 活动的 CloudTrail 跟踪。
● 使用 EventBridge 规则来匹配敏感事件，例如帐户邀请或策略更改。
● 通过 Amazon SNS 发布警报。
● 在适用的情况下，使用 AWS Config 进行组织相关的合规性监控。
设计理由
● 技术可行性：CloudTrail 记录谁执行了组织操作； EventBridge 对匹配事件做出反应； Config 评估配置合规性。
● 需求匹配：管理员及时收到通知并保留证据以供调查。
● 场景匹配：在未经批准的情况下添加了外部帐户，因此身份、时间和 API 操作至关重要。
● 工程常识：仪表板不是审计源；首先收集事件，然后可视化或发出警报。
应排除的备选方案
● Systems Manager 不提供权威的组织 API 历史记录。
● Inspector 评估工作负载漏洞，而不是帐户成员身份更改。
● Control Tower 增加了治理，但不会取代 CloudTrail 证据。
● 除非已存在适当的事件源和规则，否则 CloudWatch 控制面板无法检测更改。
工作流：组织操作 → CloudTrail 记录 → EventBridge 匹配 → SNS 通知 → 配置评估 → 调查和修复。
CloudFront 的私有 S3 起源
CloudFront 应通过源身份读取私有 S3 对象，同时直接公共 S3 访问仍处于禁用状态。
推荐架构
● 创建 CloudFront 源访问身份。
● 配置 S3 源以使用它。
● 在存储桶策略中授予OAI读取权限。
● 删除公共 ACL 和其他直接访问权限。
设计理由
● 技术可行性：CloudFront 使用 OAI 签署源请求，并且 S3 授权该身份。
● 需求匹配：用户通过 CloudFront 接收对象，但无法绕过分发。
● 场景匹配：S3 是私有 CloudFront 源。
● 工程常识：查看者授权和来源授权是单独的控制。
应排除的备选方案
● 字段级加密保护选定的请求字段，而不是保护 S3 源访问。
● TLS 证书不授权对象检索。
● 签名 URL 可以限制查看者，但源保护仍然需要删除直接 S3 权限。
● 公共读取访问击败了私有源设计。
工作流：查看器 → CloudFront → OAI 签名请求 → S3 存储桶策略 → 对象响应。
实时点击流处理
Web 点击流事件需要持续摄取和分析，而不是定期批量收集。
推荐架构
● 将点击事件发布到 Amazon Kinesis Data Streams。
● 使用均匀分配流量的密钥对记录进行分区。
● 与流消费者近乎实时地处理事件。
● 将原始或聚合结果保存到持久的分析存储中。
设计理由
● 技术可行性：Kinesis 接受每个分片的有序记录并支持多个低延迟消费者。
● 需求匹配：该平台可以在会话处于活动状态时评估用户行为。
● 场景匹配：网站点击形成了具有突发量的连续事件流。
● 工程常识：保持摄取持久并与下游分析速度脱钩。
应排除的备选方案
● Nightly S3 批处理作业不满足实时要求。
● SQS 对于工作队列很有用，但不提供相同的有序流和多消费者模型。
● 直接写入仓库和网站以获取分析可用性。
● CloudTrail 记录 AWS 账户活动，而不是应用程序点击流事件。
工作流：浏览器事件 → Kinesis 分区 → 流处理器 → 实时指标或操作 → 持久存档和后续分析。
防止意外的公共 S3 访问
S3 阻止公共访问是对公共 ACL 和策略的直接预防性控制。
推荐架构
● 在所需的组织、账户、存储桶或访问点范围内启用阻止公共访问。
● 保持存储桶策略最小特权。
● 使用 AWS Config 或 Security Hub 进行额外的检测和报告。
设计理由
● 技术可行性：S3 拒绝会创建阻塞公共访问路径的配置和请求。
● 需求匹配：用户不会意外暴露受保护的存储桶。
● 场景匹配：风险包括 ACL、存储桶策略和访问点。
● 工程常识：在构建自定义评估逻辑之前使用服务本机预防控制。
应排除的备选方案
● 私有固定 ACL 不涵盖公共存储桶策略或访问点。
● AWS Config 在更改后检测到不合规情况。
● SCP 可以拒绝 API，但无法完整评估每个生成的公共配置。
● 人工审核缓慢且不一致。
工作流：用户尝试公共设置 → S3 阻止公共访问评估 → 更改或请求被拒绝 → 监控记录事件。
跨区域加密 Redshift 快照副本
KMS 加密的 Redshift 集群需要目标密钥授权，然后本机跨区域快照副本才能对其进行保护。
推荐架构
● 在目标区域中为目标 KMS 密钥创建快照副本授权。
● 启用 Redshift 跨区域快照复制。
● 设置适合恢复目标的保留。
● 测试在恢复区域中恢复快照。
设计理由
● 技术可行性：复制授权允许 Redshift 使用目标密钥来加密复制的快照。
● 需求匹配：恢复快照不会丢失源区域。
● 场景匹配：仓库采用KMS加密。
● 工程常识：在测试恢复权限和时间之前，备份的存在是不够的。
应排除的备选方案
● 自定义 Lambda 复制逻辑复制本机功能，并且可能会省略密钥授权。
● 对于加密工作流程，在没有 KMS 授权的情况下启用复制会失败。
● S3 跨区域复制不是 Redshift 快照复制机制。
● CloudFormation 无法从 S3 中的任意复制快照文件恢复 Redshift。
工作流：Redshift快照→目标副本授予→加密的跨区域副本→保留→恢复恢复测试。
卸载 RDS 批量读取并发送完成警报
批处理报告应从副本中读取并在处理完成时直接通知订阅者。
推荐架构
● 添加 RDS 只读副本。
● 将批量分析查询定向到副本。
● 在多可用区主数据库上保留 OLTP 写入。
● 将完成结果发布到 Amazon SNS 供本地仪表板订阅者使用。
设计理由
● 技术可行性：只读副本减少主读负载，SNS 向订阅者推送通知。
● 需求匹配：CRM 在批量工作期间保持响应，并且仪表板会及时收到完成通知。
● 场景匹配：工作负载是针对操作数据库的大量读取分析。
● 工程常识：高可用性和读取扩展是不同的数据库功能。
应排除的备选方案
● 对于这种狭隘的需求，Redshift 不应取代 CRM OLTP 数据库。
● Redshift Spectrum 分析 S3 数据，而不是规定的 RDS 批次峰值。
● SQS 要求消费者进行轮询，对于广播通知来说不太直接。
● 在写入器上运行分析可以保留瓶颈。
工作流：批量开始→查询副本→报告完成→SNS发布→仪表板收到通知。
私有 MySQL 复制到本地
本地只读副本可以通过私有 VPN 上的本机外部复制来遵循 RDS MySQL。
推荐架构
● 建立专用 VPN 连接。
● 使用 mysqldump 为本地 MySQL 目标设定种子。
● 将 RDS 配置为外部复制源。
● 启动本机 MySQL 复制并监控延迟。
设计理由
● 技术可行性：RDS 支持在受支持的配置下复制到外部 MySQL 兼容目标。
● 需求匹配：本地数据库保持最新状态以供读取。
● 场景匹配：需要连续复制，而不是每晚批量导出。
● 工程常识：首先播种，然后从已知位置应用变更流。
应排除的备选方案
● EC2 中继添加了不必要的复制跃点。
● 每晚数据管道导出不是当前的只读副本。
● 通过开放互联网进行复制会增加曝光率。
● 重复完全导出会浪费带宽并延长延迟。
工作流：VPN → 初始转储 → 捕获复制坐标 → 启动外部副本 → 监控和修复延迟。
缓冲 DynamoDB 写入突发
当 DynamoDB 在突发期间进行限制时，持久队列会保护请求，直到消费者可以以可接受的速率写入。
推荐架构
● 将写入请求放入 Amazon SQS。
● 使用受控消费者处理消息。
● 使用批量写入、重试、幂等性和死信处理。
● 当持续需求证明合理时扩展 DynamoDB 容量。
设计理由
● 技术可行性：SQS 在限制或扩展延迟期间保留消息。
● 需求匹配：意外突发不会导致数据丢失。
● 场景匹配：写入峰值是可变的，而不是永久的数据模型变化。
● 工程常识：容量和缓冲解决不同的问题并且可以相辅相成。
应排除的备选方案
● 单独使用更多 WCU 并不能在突然爆发期间持久保护请求。
● 全局表提供区域复制，而不是本地写入缓冲。
● 附加表对数据模型和重试逻辑进行分段。
● 客户端立即重试可能会加剧限制。
工作流：生产者 → SQS → 消费者批次 → DynamoDB → 重试受限制的项目 → DLQ 持续失败。
虚拟机在线迁移与离线迁移相结合
受限的迁移窗口可能需要对关键系统进行连续复制，并对非常大的数据集进行离线传输。
推荐架构
● 将 AWS Application Migration Service 用于需要同步和短停机时间切换的关键虚拟机。
● 使用 AWS Snowball 处理无法及时通过可用网络移动的批量数据。
● 对于不需要连续复制的受支持的映像导入情况，请使用 VM 导入/导出。
● 通过一个迁移计划协调测试和最终切换。
设计理由
● 技术可行性：MGN 复制服务器磁盘，Snowball 离线传输批量字节，VM Import/Export 根据支持的格式创建 AWS 映像。
● 需求匹配：每个工作负载都使用与其大小和停机容忍度相匹配的迁移路径。
● 场景匹配：该资产包含关键虚拟机和大量数据。
● 工程常识：不要强制每个工作负载都通过一种传输方法。
应排除的备选方案
● 对于一次性迁移来说，配置新的 Direct Connect 可能会很慢且成本高昂。
● 重构每个应用程序都超出了迁移时间表。
● 带宽有限的 SFTP 不适合非常大的数据集。
● 重复的完整图像导入无法提供高效的持续同步。
工作流：对工作负载进行分类 → 复制关键虚拟机 → 传送批量数据 → 导入剩余映像 → 测试 → 切换。
通过 Route 53 故障转移进行区域灾难恢复
区域恢复设计需要独立的应用程序堆栈和基于健康的流量控制。
推荐架构
● 在主要区域中部署 ALB 和 Auto Scaling 组。
● 在次要区域中维护恢复 ALB 和 Auto Scaling 组。
● 根据RPO复制或恢复所需数据。
● 配置 Route 53 故障转移记录和运行状况检查。
● 定期测试故障转移和故障回复。
设计理由
● 技术可行性：每个区域都可以独立地提供流量，并且当主要终端节点运行状况不佳时，Route 53 会更改 DNS 答案。
● 需求匹配：主要区域完全中断后，应用程序仍然可用。
● 场景匹配：生产在一个区域运行，而另一区域需要灾难恢复。
● 工程常识：仅当恢复中也存在数据、机密、证书和依赖项时，应用程序故障转移才会成功。
应排除的备选方案
● 多可用区仅保护一个区域内部。
● 没有辅助计算的一个全局负载均衡器无法恢复工作负载。
● 手动 DNS 更改会增加 RTO。
● 没有可部署应用程序环境的备份会延迟恢复。
工作流：运行状况检查失败 → Route 53 返回辅助端点 → 恢复队列规模 → 数据提升或恢复 → 用户重新连接。
RDS 多可用区故障转移和 DNS
应用程序应连接到 RDS 端点而不是数据库实例 IP 地址。
故障转移行为
● RDS 在另一个可用区中维护同步备用。
● 当主数据库发生故障时，RDS 会提升备用数据库。
● 数据库端点的 CNAME 解析为新的主地址。
● DNS 和连接恢复后应用程序重新连接。
设计理由
● 技术可行性：RDS 控制托管部署的升级和 DNS 重新映射。
● 需求匹配：应用程序无需手动更改连接字符串即可恢复。
● 场景匹配：该设计使用多可用区来实现数据库可用性。
● 工程常识：连接池必须丢弃断开的连接并再次解析端点。
应排除的错误假设
● 应用程序不应固定旧数据库 IP。
● 多可用区备用实例不是正常的读取扩展端点。
● Route 53 记录不需要手动更改操作员即可进行标准 RDS 故障转移。
● 恢复快照不是正常的多可用区故障转移过程。
工作流：主要故障 → RDS 检测到 → 备用提升 → 端点 DNS 更改 → 应用程序重试并重新连接。
防篡改多区域 API 审核日志记录
合规性日志记录需要跨区域和全球服务的完整 API 历史记录，以及受保护的长期存储。
推荐架构
● 创建 AWS CloudTrail 多区域跟踪。
● 包括全局服务事件，例如 IAM 活动。
● 将日志传送到专用的 Amazon S3 存储桶。
● 使用 AWS KMS 加密日志文件。
● 使用最低权限策略限制存储桶和密钥访问。
● 在操作适当的情况下启用版本控制和 MFA 删除。
设计理由
● 技术可行性：CloudTrail 跨受支持的服务记录控制台、SDK、CLI 和 API 活动。
● 需求匹配：多区域覆盖和全球事件提供所需的审计历史记录； S3 和 KMS 保护持久性和机密性。
● 场景匹配：EC2、S3、CloudFront 和 IAM 活动跨越区域和全球服务边界。
● 工程常识：将审计证据与工作负载账户分开集中，并防止轻易删除或更改。
应排除的备选方案
● 排除全局服务事件会忽略所需的 IAM 活动。
● CloudWatch 不提供权威帐户 API 历史记录的“跟踪”资源。
● 单区域配置无法覆盖所有应用程序区域中的活动。
工作流：API 调用 → CloudTrail 事件 → 加密的 S3 对象 → 受控审核访问 → 保留和完整性监控。
实时物联网分析管道
宠物项圈遥测需要当前事件的流路径和用于原始或聚合分析的单独的持久存储。
推荐架构
● 通过 Amazon Kinesis 摄取设备事件。
● 近乎实时地处理或聚合记录。
● 将持久输出和聚合存储在 Amazon S3 中。
● 将精选的分析数据加载到 Amazon Redshift 中以进行更深入的查询。
设计理由
● 技术可行性：Kinesis 接受连续事件流，S3 提供持久对象存储，Redshift 支持分析 SQL。
● 需求匹配：该管道支持大规模的及时监控和历史分析。
● 场景匹配：物联网设备发出持续的遥测数据，而不是偶尔的交易记录。
● 工程常识：将流摄取与仓库查询分开，这样分析工作负载就不会阻止事件摄取。
应排除的备选方案
● 将每个设备直接发送到关系仓库将摄取可用性与仓库容量结合起来。
● 仅批量传输会延迟操作洞察力。
● 单独使用 S3 存储记录，但不提供实时流处理。
● 将队列视为完整的分析平台仍然需要消费者、持久的分析存储和查询服务。
工作流：设备事件 → Kinesis 流 → 实时处理 → S3 存档和聚合 → Redshift 加载 → 分析。
缓冲最终一致的本地写入
最终一致的 BASE 数据库可以通过持久队列异步接收云发起的写入。
推荐架构
● 将写入请求放入 Amazon SQS 中。
● 运行连接到本地数据库的使用者。
● 对消息进行幂等处理，持久化成功后才将其删除。
● 配置重试和死信队列。
设计理由
● 技术可行性：当数据库或网络速度缓慢或不可用时，SQS 会持久缓冲消息。
● 需求匹配：生产者保持响应并且数据库异步收敛。
● 场景匹配：不需要严格的立即一致性。
● 工程常识：仅在业务关键需要时保留排序；优先考虑持久性和幂等性。
应排除的备选方案
● EventBridge 本身不会复制任意数据库写入。
● Elastic Transcoder 与数据库无关。
● S3DistCp 复制 S3 和 HDFS 数据，而不是应用程序事务。
● DynamoDB 加上 EMR 批处理作业会增加不必要的存储和延迟。
工作流：应用程序提交写入→SQS保留→消费者在本地写入→确认成功→失败的消息重试或进入DLQ。
将静态路径路由到 S3 CloudFront 源
CloudFront 分配可以使用单独的源来处理动态应用程序请求和静态资产。
推荐架构
● 添加 S3 存储桶作为第二个 CloudFront 源。
● 为静态路径模式创建缓存行为。
● 将该行为路由到 S3。
● 将 ALB 保留为动态路径的默认来源。
设计理由
● 技术可行性：CloudFront 缓存行为从 URL 路径模式中选择源。
● 需求匹配：静态资产停止返回应用程序源 404 错误并获得边缘缓存。
● 场景匹配：一个域同时提供动态和静态内容。
● 工程常识：在知道两个源的 CDN 层执行源选择。
应排除的备选方案
● Global Accelerator 不会通过 HTTP 路径缓存内容或路由。
● ALB 无法使用 S3 存储桶作为目标。
● 标头条件不会使 S3 成为 ALB 目标。
● 在应用程序实例上复制静态文件会破坏 S3 源。
工作流：查看器请求→CloudFront路径匹配→静态资产的S3源或动态内容的ALB。
本地站点的快速全局卸载
CloudFront 可以使用现有的本地网站作为自定义源，并快速减少全球流量。
推荐架构
● 将本地站点配置为 CloudFront 自定义源。
● 缓存静态和安全可重用的动态 HTTP 响应。
● 调整缓存行为和 TTL。
● 将不可缓存的应用程序流量保留在源头。
设计理由
● 技术可行性：CloudFront 从可通过 Internet 访问的自定义源检索内容并在全球范围内提供缓存的响应。
● 需求匹配：该解决方案在短时间内提高了规模，无需完全迁移。
● 场景匹配：当前应用程序必须保留在本地。
● 工程常识：首先卸载占主导地位的重复流量。
应排除的备选方案
● 颠倒静态和动态服务角色会导致设计不可行。
● Transit Gateway 不提供公共 CDN 交付。
● App Runner 无法管理本地服务器。
● 复制完整的基础设施并转移一半的流量速度更慢，成本也更高。
工作流：查看器 → CloudFront → 边缘命中或自定义源请求 → 本地应用程序。
审核员对 AWS 活动的只读访问权限
外部审计员需要可验证的帐户活动和受控的读取访问权限，而不是管理权限。
推荐架构
● 为所需的区域和服务启用 AWS CloudTrail。
● 将跟踪日志存储在受保护的 Amazon S3 存储桶中。
● 创建专用 IAM 身份，对所需日志和资源具有只读访问权限。
● 通过组织批准的安全流程提供凭据。
设计理由
● 技术可行性：CloudTrail 记录控制台、CLI、SDK 和 API 活动； IAM 控制审核员可以检查的内容。
● 需求匹配：审核员收到的证据没有修改权。
● 场景匹配：任务是账户审计，而不是运营管理。
● 工程常识：将审计身份与员工账户分开，并仅授予所需的证据。
应排除的备选方案
● AWS 不会独立向外部审计员提供对客户账户的访问权限。
● 通过电子邮件发送日志会造成重复、访问控制薄弱以及可搜索性差。
● SNS 通知报告事件，但不提供完整的历史审计证据。
● 广泛的角色或管理员权限超出了审核员的需要。
工作流：帐户操作 → CloudTrail 日志 → 受保护的 S3 存储 → 只读审核员访问 → 审查和证据收集。
从批准的 EC2 实例进行私有 S3 访问
安全的 S3 访问需要网络路径限制和工作负载授权。
推荐架构
● 创建 S3 网关 VPC 终端节点。
● 将端点策略限制为所需的存储桶。
● 将最低权限的 IAM 角色附加到批准的 EC2 实例。
● 需要 S3 存储桶策略中的端点和批准的主体。
设计理由
● 技术可行性：端点使 S3 流量保持私有，IAM 授予积极授权，并且存储桶策略强制执行预期路径。
● 需求匹配：只有Web Portal实例才能通过批准的VPC路由使用该存储桶。
● 场景匹配：该应用程序在专用网络中的 EC2 上运行。
● 工程常识：网络位置不能替代工作负载身份。
应排除的备选方案
● NACL 无法识别单个 EC2 工作负载以进行 S3 授权。
● 存储桶策略无法安全地将私有子网视为主体。
● 当端点路由改变观察到的路径时，SourceIp 是不可靠的。
● 每实例路由不授予 IAM 权限。
工作流：EC2 角色签署请求 → 网关端点策略 → 存储桶策略路径和主体检查 → S3 操作。
扩容现有VPC CIDR
VPC 可以通过关联辅助 IPv4 CIDR 块来获得地址空间。
推荐流程
● 选择 VPC 规则允许的非重叠辅助 CIDR。
● 将其与现有 VPC 关联。
● 从次要范围创建新子网。
● 更新路由、安全规则、网络设备和IP地址管理记录。
设计理由
● 技术可行性：AWS 在一个 VPC 上支持多个关联的 CIDR 块。
● 需求匹配：该公司无需重建网络即可添加地址。
● 场景匹配：现有资源和连接应保留在同一 VPC 中。
● 工程常识：首先检查与对等网络、传输网络、VPN 和本地网络的重叠。
应排除的备选方案
● 删除子网不会更改主 VPC CIDR。
● 第二个 VPC 加上对等互连创建了单独的网络和额外的路由操作。
● 主网段不需要更换。
● 重叠的次要范围可能会破坏连接。
工作流：规划地址空间 → 关联辅助 CIDR → 创建子网 → 更新控制 → 迁移或启动工作负载。
Redshift 区域灾难恢复
Redshift 灾难恢复使用复制到另一个区域的快照，而不是连续集群复制。
推荐架构
● 启用自动 Redshift 快照。
● 配置跨Region快照复制到恢复Region。
● 设置保留以满足 24 小时 RPO。
● 测试在一小时 RTO 内恢复集群。
设计理由
● 技术可行性：本机快照副本将可恢复的仓库数据放置在源区域之外。
● 需求匹配：自动快照满足数据丢失目标，区域副本可防止区域故障。
● 场景匹配：工作负载是 Redshift，而不是具有跨区域副本的事务数据库。
● 工程常识：恢复时间必须包括集群恢复和应用程序重新连接。
应排除的备选方案
● 在灾难期间，手动快照复制开始得太晚。
● S3 跨区域复制不是 Redshift 集群故障转移机制。
● Redshift 这里没有连续的跨区域集群复制设计。
● 除非启用复制，否则自动快照将保留在源区域中。
工作流：自动快照→跨区域复制→灾难→恢复集群→验证→重新连接分析。
用于 ECR 图像拉取的私有 Fargate 出口
私有子网中的 Fargate 任务需要出站路径来检索其容器映像，除非配置了所有必需的私有端点。
推荐架构
● 保持自动公共 IP 分配处于禁用状态。
● 将 NAT 网关放置在公共子网中。
● 为公有子网提供一条到 Internet 网关的路由。
● 将私有子网出站流量路由到 NAT 网关。
● 通过网络控制允许所需的 HTTPS 流量。
设计理由
● 技术可行性：该任务使用其私有地址并通过 NAT 获取出站连接以达到 ECR 依赖项。
● 需求匹配：容器启动时不会将任务直接暴露给互联网。
● 场景匹配：从 ECR 注册表端点拉取时发生报告的连接超时。
● 工程常识：公共出口基础设施属于公共子网；工作负载保持私有。
应排除的备选方案
● ECR 使用接口端点，而不是替代方案中描述的网关端点。
● Fargate 需要 awsvpc 网络并且无法切换到桥接模式。
● 私有子网中的 NAT 网关无法到达 Internet 网关。
● 启用任务公共 IP 与私有设计冲突。
工作流：任务启动→私有路由→NAT网关→ECR镜像拉取→容器启动。
使用 CHAP 保护 iSCSI 会话
Storage Gateway iSCSI 会话应在块存储公开之前对启动器进行身份验证。
推荐控制
● 为 iSCSI 目标配置质询握手身份验证协议。
● 将 CHAP 凭据安全地存储在网关和批准的启动器上。
● 限制对所需 iSCSI 端口和源系统的网络访问。
● 通过受控维护轮换凭证。
设计理由
● 技术可行性：CHAP 通过质询-响应交换对 iSCSI 启动器进行身份验证，而不直接发送机密。
● 需求匹配：该控制降低了网关块卷的未经授权的附加和重放风险。
● 场景匹配：该接口是iSCSI，因此保护应使用其支持的身份验证机制。
● 工程常识：将协议认证与网络限制相结合；两者都不能替代对方。
应排除的备选方案
● SMB 和 NFS 身份验证设置不能保护 iSCSI 卷。
● HTTPS 保护管理或 API 流量，而不是 iSCSI 会话本身。
● S3 存储桶策略不会对本地 iSCSI 启动器进行身份验证。
● 仅加密并不能证明哪个主机正在连接目标。
工作流：启动器连接 → 网关发出质询 → 启动器使用共享密钥进行响应 → 网关验证 → iSCSI 会话打开。
联合员工对个人 S3 前缀的访问
目录用户可以接收仅限于匹配的个人 S3 前缀的临时凭证。
推荐架构
● 使用联合代理对公司目录用户进行身份验证。
● 将身份属性映射到 IAM 角色会话。
● 使用 STS 获取临时凭证。
● 应用带有将每个用户映射到 S3 前缀的变量的 IAM 策略。
设计理由
● 技术可行性：策略变量范围来自联合身份上下文的对象路径。
● 需求匹配：员工使用现有凭证，无需重复的 IAM 用户。
● 场景匹配：每个人都需要在一个存储桶中拥有一个单独的文件夹。
● 工程常识：保持身份验证集中并动态授权数据路径。
应排除的备选方案
● Amazon Connect 是一项联络中心服务。
● 将每个目录身份镜像到 IAM 会增加生命周期开销。
● 每个员工的 IAM 用户会创建重复的密码或访问密钥。
● 静态共享凭据无法隔离个人前缀。
工作流：员工登录 → 代理验证目录 → STS 发出会话 → 策略变量选择前缀 → S3 请求。
使用 DynamoDB 全局表进行多区域事务
全球市场需要本地区域读写以及区域之间的托管复制。
推荐架构
● 创建一个 DynamoDB 全局表，其中包含所有所需区域中的副本。
● 将每个区域 API 定向到其本地副本。
● 让 DynamoDB 跨所有副本表复制项目更改。
● 设计多区域写入的事务密钥和冲突行为。
设计理由
● 技术可行性：全局表提供托管多活动复制和区域端点。
● 需求匹配：该设计降低了全球用户的延迟，并避免了自定义复制基础设施。
● 场景匹配：数以百万计的市场用户和多区域 API 需要水平可扩展的存储。
● 工程常识：与构建重播系统相比，更喜欢数据库的本机复制功能。
应排除的备选方案
● 所描述的 Aurora 多主架构不是有效的多区域主动-主动设计。
● 基于 Lambda 的重播复制了内置复制，并引入了排序、重试和冲突管理工作。
● Control Tower 管理 AWS 账户，并且不复制应用程序记录。
● Amazon Connect 是一项联络中心服务，与数据库复制无关。
工作流：API写入本地副本→基于流的全局复制→远程副本更新→应用程序本地读取→监控复制和冲突指标。
具有服务控制策略的中央帐户护栏
多账户治理需要集中强制执行权限边界，而不是重复的账户级 IAM 策略。
推荐架构
● 使用 AWS Organizations 和组织单位组织部门账户。
● 将服务控制策略附加到适当的根、OU 或帐户。
● 将工作负载 IAM 策略保留在每个账户内以获取实际的权限授予。
设计理由
● 技术可行性：SCP 定义成员帐户中主体可用的最大权限。
● 需求匹配：中央管理员可以允许或拒绝维护成本低的服务类别。
● 场景匹配：部门账户在继承公司护栏的同时保持独立管理。
● 工程常识：将组织范围的边界与本地角色权限分开。
应排除的备选方案
● 每个账户内附加的 IAM 策略不会集中约束每个委托人或成员账户根用户。
● 身份联合解决身份验证和员工访问问题，而不是帐户范围的服务限制。
● 跨账户角色和每个资源的策略造成了高度复杂性和不完整的治理覆盖范围。
重要行为：SCP 不授予访问权限。仅当身份或资源策略允许并且没有适用的 SCP 阻止请求时，请求才会成功。
工作流：群组帐户 → 设计护栏 → 在有限的 OU 中进行测试 → 附加 SCP → 监控被拒绝的操作。
防止生产 EC2 终止
开发人员访问权限应允许正常工作，同时明确防止生产实例终止。
推荐控制
● 删除开发人员角色的生产终止权限。
● 当目标具有生产标签时，为 ec2:TerminateInstances 添加显式 IAM 拒绝。
● 保护标签管理权限，以便开发人员无法删除控制标签。
设计理由
● 技术可行性：显式拒绝会覆盖允许，并且资源标记条件会限制限制。
● 需求匹配：开发人员保留对非生产资源的安全操作。
● 场景匹配：主要风险是对生产实例的破坏性 API 访问。
● 工程常识：最小特权比在不必要的广泛许可上增加审批摩擦更强大。
应排除的备选方案
● PowerUserAccess 仍然允许许多删除操作。
● 安全组影响网络流量，而不影响 EC2 API 授权。
● MFA 条件可能会减少事故，但仍允许终止。
● 如果用户可以修改设置，则单独的 EC2 终止保护并不是完整的 IAM 边界。
工作流：开发人员调用终止 → IAM 评估角色和生产标签 → 显式拒绝阻止请求 → CloudTrail 记录尝试。
从 LDAP 到 IAM 角色的自定义联合
自定义移动身份验证解决方案可以在颁发临时 AWS 角色凭证时保留 LDAP 作为凭证源。
支持的模式
● 构建自定义 OpenID Connect 提供商并使用 Cognito 身份池将经过身份验证的身份映射到 IAM 角色。
● 或者构建一个与 SAML 兼容的解决方案，根据 LDAP 进行身份验证并将断言发送到 IAM SAML 身份提供商。
设计理由
● 技术可行性：OIDC或SAML建立联盟； Cognito 或 IAM 交换临时角色会话的可信身份信息。
● 需求匹配：移动应用程序使用自定义身份验证和 IAM 角色，无需存储 AWS 访问密钥。
● 场景匹配：公司必须保留 LDAP 并满足严格的安全控制。
● 工程常识：重用标准联合协议，而不是发明令牌数据库和授权引擎。
应排除的备选方案
● 与这种直接移动角色联合流程相比，IAM Identity Center 更适合员工访问门户。
● 自定义 API 网关和 DynamoDB 令牌服务复制身份、会话和凭证功能。
● 仅与 Identity Center 结合使用的 OIDC 并不直接提供所请求的移动 IAM 角色工作流程。
工作流：用户凭证 → LDAP 验证 → OIDC 令牌或 SAML 断言 → 角色映射 → 临时 AWS 凭证。
经济高效的 OpsWorks 层
相关应用程序组件可以共享一个 OpsWorks 堆栈，同时为不同的角色使用单独的层。
推荐架构
● 将现有的客户支持 Web 应用程序保留在一层中。
● 为视频聊天组件添加第二层。
● 在可行的情况下，使用一种自定义 Chef 配方来执行共享安装或集成任务。
● 将实例和生命周期事件分配给适当的层。
设计理由
● 技术可行性：OpsWorks 层在堆栈中组织实例、配方、包和生命周期配置。
● 需求匹配：新组件保持独立配置，无需复制整个堆栈。
● 场景匹配：Web 支持和视频聊天属于同一个应用环境，但具有不同的服务器角色。
● 工程常识：将运营角色（不是每个功能）分离到不同的基础设施资产中。
应排除的备选方案
● 第二个完整堆栈会重复配置和管理成本。
● 在一层中混合两种服务器角色会减少对扩展和配方的控制。
● 每个相同依赖项的单独配方会增加不必要的维护。
● 在功能发布期间替换 OpsWorks 扩大了范围。
工作流：更新堆栈→创建视频层→附加配方→启动实例→验证集成→独立缩放每个层。
将 TLS 证书控制与开发人员分离
安全性可以控制私钥，而开发人员可以通过在负载均衡器处终止 TLS 来管理应用程序服务器。
推荐架构
● 将证书存储在 AWS Certificate Manager 或支持的 AWS 证书存储中。
● 限制安全团队的证书权限。
● 将证书附加到 ALB HTTPS 侦听器。
● 让私钥材料远离 EC2 实例。
设计理由
● 技术可行性：ALB 执行 TLS 终止，而不将私钥分发给应用程序主机。
● 需求匹配：当开发人员操作 EC2 时，安全性保留证书生命周期控制。
● 场景匹配：团队需要严格的职责分离。
● 工程常识：当开发人员拥有广泛的服务器管理权限时，主机级文件权限会很弱。
应排除的备选方案
● 将证书存储在 EC2 上会将其公开给特权主机用户。
● 从 S3 检索私钥会破坏分离。
● 从 CloudHSM 复制密钥会破坏 HSM 隔离。
● 应用程序所有者不应管理生产证书更新。
工作流：安全管理证书→ALB终止TLS→转发的请求到达EC2而不暴露私钥。
通过 Direct Connect 网关实现区域间专用连接
中央办公室可以通过一个托管的 Direct Connect 架构访问多个区域的 VPC。
推荐架构
● 使用 AWS Direct Connect 网关。
● 将虚拟专用网关附加到每个区域 VPC。
● 将专用虚拟接口连接到 Direct Connect 网关。
● 使用 BGP 公布批准的路由。
设计理由
● 技术可行性：Direct Connect 网关将私有 VIF 连接与跨受支持区域的虚拟私有网关关联起来。
● 需求匹配：流量使用具有可预测性能和集中管理的专用连接。
● 场景匹配：该办公室需要对多个区域 VPC 进行私有访问，而不仅仅是 VPC 到 VPC 的通信。
● 工程常识：使用集线器服务而不是构建和维护点对点链路的完整网格。
应排除的备选方案
● 区域间 VPC 对等互连不会连接本地办公室并创建许多成对关系。
● 公共 VIF 不是私有 VPC 前缀的正确路径。
● 链路聚合组可提高一个 Direct Connect 位置的容量或弹性，但不会取代专用 VIF 设计。
● 具有基于 Internet 的 VPN 的 Transit Gateway 不满足专用路径要求。
工作流：办公室路由器 → Direct Connect → 私有 VIF → Direct Connect 网关 → 区域 VGW → VPC。
SCP 继承和临时帐户加入
从组织根继承的显式拒绝不能被子组织单位上的允许策略覆盖。
推荐架构
● 将生产限制从组织根移动到生产 OU。
● 创建具有配置 AWS Config 所需权限的临时 Onboarding OU。
● 安装所需的控件后，将新帐户置于入职中。
● 验证后将帐户移至生产。
设计理由
● 技术可行性：SCP评估尊重继承的否认；将拒绝更改重新定位到适用的位置。
● 需求匹配：可以在不削弱现有生产帐户的情况下配置入职帐户。
● 场景匹配：这一例外情况是暂时的，并且仅限于一个新获得的帐户。
● 工程常识：将控件放置在符合其预期范围的最窄级别。
应排除的备选方案
● 消除每个人的 root 限制会导致整个组织范围内的暴露。
● 入职时允许 SCP 无法覆盖根级显式拒绝。
● 根允许列表可以发挥作用，但会在需要新服务时增加长期维护。
● 服务目录不会覆盖 SCP 评估。
工作流：创建 OU → 重新定位生产 SCP → 内置帐户 → 配置配置规则 → 验证合规性 → 将帐户移至生产。
使用 StackSets 进行多账户部署
CloudFormation StackSets 跨账户和区域集中部署一致的基础设施。
推荐架构
● 将 StackSets 与 AWS Organizations 集成。
● 定义一次所需的 CloudFormation 模板。
● 目标组织部门、客户和区域。
● 使用受控权限、容错能力和部署顺序。
设计理由
● 技术可行性：StackSets 在多个账户和区域中创建和更新堆栈实例。
● 需求匹配：中央团队以较少的体力工作维持一致的资源。
● 场景匹配：部署范围跨越整个组织。
● 工程常识：集中标准化，同时仅在必要时允许特定于账户的参数。
应排除的备选方案
● 嵌套堆栈提供模板模块化，但不协调组织范围内的部署。
● 区域参数和 IAM 策略仍然需要单独的堆栈操作。
● Control Tower 管理登陆区域，但不是直接的通用 StackSet 部署机制。
● 手动堆叠容易发生漂移。
工作流：更新模板 → 选择目标 → 部署堆栈实例 → 监控故障 → 修复偏差。
使用时间点数据恢复交易平台
严格的恢复计划需要频繁的可恢复性、受保护的备份以及故障区域之外的副本。
推荐架构
● 将 AWS Backup 与受支持数据库的时间点恢复结合使用。
● 将应用程序备份和事务日志存储在 Amazon S3 中。
● 经常捕获日志足以满足十分钟的 RPO。
● 使用 S3 跨区域复制将恢复对象复制到另一个区域。
● 在两小时 RTO 内测试恢复。
设计理由
● 技术可行性：PITR 可在选定时间附近恢复数据库状态，而复制备份可在区域故障中幸存下来。
● 需求匹配：频繁的日志可以限制数据丢失，预先定位的副本可以减少恢复延迟。
● 场景匹配：受监管的交易系统既需要运营恢复，也需要持久的证据。
● 工程常识：RPO决定捕获频率； RTO 决定恢复自动化和数据放置。
应排除的备选方案
● 多可用区可以防止可用区故障，但不是区域灾难恢复。
● 每日快照无法满足十分钟的 RPO。
● 冰川修复可能会延迟短暂的 RTO。
● 仅保留在生产区域中的备份可能会因区域中断而消失。
工作流：连续事务→PITR和频繁日志→跨区域复制→恢复→重放→验证→重定向流量。
低成本可搜索冰川档案
大型数据集可以压缩为更少的 Glacier 档案，而可搜索元数据保留在 DynamoDB 中。
推荐架构
● 将每个数据集压缩到一个存档中。
● 将存档存储在 S3 Glacier 存储中。
● 在 DynamoDB 中记录文件名、元数据和存档标识符。
● 搜索 DynamoDB，然后使用存档标识符请求恢复。
设计理由
● 技术可行性：DynamoDB 提供在线元数据查询，而 Glacier 提供低成本档案存储。
● 需求匹配：存档计数开销下降，用户可以在检索之前找到数据集。
● 场景匹配：内容很少被访问，但必须保持可发现性。
● 工程常识：归档存储不是搜索索引。
应排除的备选方案
● 无法通过档案内的文件名直接查询冰川库。
● 仅存储为 S3 对象的元数据仍然需要可搜索索引。
● 两桶设计增加了复杂性，但没有改善档案发现。
● 将所有数据集保存在在线 S3 存储中的成本高于所需的 Glacier 方法。
工作流：压缩数据集 → 存档 → DynamoDB 中的索引元数据 → 搜索 → 按需检索存档。
集中出口检查
超过 50 个帐户应共享一个托管出站检查路径，而不是重复代理或防火墙组。
推荐架构
● 构建集中式出口VPC。
● 通过 Transit Gateway 连接工作负载 VPC。
● 通过 AWS 网络防火墙路由出站流量。
● 使用 NAT 网关作为 Internet 出口。
● 集中管理规则和路线。
设计理由
● 技术可行性：Transit Gateway 提供集线器路由，网络防火墙执行托管检查，NAT 网关转换出站流量。
● 需求匹配：该设计将策略管理扩展到多个账户，操作量较低。
● 场景匹配：所有帐户都需要一致的出站过滤。
● 工程常识：通过检查路径保留对称路由。
应排除的备选方案
● 每个帐户中的代理队列都会创建修补和扩展工作。
● 每个帐户中的防火墙端点都会重复成本和策略。
● 中央 EC2 代理可以工作，但需要容量和软件维护。
● 独立的 NAT 路径可以绕过集中检查。
工作流：分支 VPC → 中转网关 → 网络防火墙 → NAT 网关 → 互联网 → 对称返回路径。
与 EFS 共享高通量数据
使用相同数据集的队列应安装一个共享文件系统，而不是在每个实例上保留副本。
推荐架构
● 将数据集存储在 Amazon EFS 上。
● 从所有应用程序实例安装它。
● 当所需吞吐量超过文件系统大小提供的大小时，请使用预配置吞吐量。
● 监控吞吐量利用率和客户端性能。
设计理由
● 技术可行性：EFS 提供共享弹性文件访问，预配置吞吐量将性能与存储容量分离。
● 需求匹配：数据重复消失，吞吐量变得可预测。
● 场景匹配：多个实例需要并发访问相同的文件。
● 工程常识：与吞吐量模式分开选择性能模式。
应排除的备选方案
● 实例存储是短暂的且不共享。
● 最大 I/O 提高了聚合规模，但增加了每个操作的延迟，并且可能不适合此工作负载。
● 过大的 gp2 卷只是为了获得性能而浪费存储空间。
● 单独的 EBS 副本会产生同步和替换问题。
工作流：实例挂载EFS→全部读取共享数据集→配置吞吐量服务负载→指标指导调优。
使用临时 S3 凭证进行 LDAP 身份验证
现有 LDAP 身份可以通过将用户映射到 IAM 角色的联合代理安全地访问 S3。
推荐模式
● 让应用程序根据 LDAP 对用户进行身份验证，将身份映射到 IAM 角色，然后调用 STS。
● 或者使用专用身份代理来执行 LDAP 验证和角色映射。
● 返回授权 S3 操作的临时 AWS 凭证。
设计理由
● 技术可行性：在受信任的应用程序或代理验证用户后，STS 提供短期角色凭据。
● 需求匹配：员工使用现有凭证，无需创建永久 IAM 用户或嵌入 AWS 密钥。
● 场景匹配：LDAP 仍然是企业身份源，而 S3 托管受保护的内容。
● 工程常识：将身份验证与 AWS 授权分开并保持会话临时。
应排除的备选方案
● 为每个 LDAP 员工创建一个 IAM 用户会重复身份生命周期管理。
● Direct Connect 网关和中转网络不执行身份验证。
● S3 存储桶策略无法验证 LDAP 密码。
● 应用程序中的长期访问密钥会增加曝光和轮换工作。
工作流：用户登录 → LDAP 验证 → 角色映射 → STS 临时凭证 → 签名的 S3 请求 → 过期。
低延迟 UDP 游戏网络
UDP 游戏流量需要第 4 层负载平衡器和子网控制，可以明确拒绝不需要的协议。
推荐架构
● 将网络负载均衡器与 UDP 侦听器结合使用。
● 根据需要分配静态弹性 IP 地址。
● 为 NLB 创建 Route 53 记录。
● 使用 NACL 拒绝规则来限制不需要的非 UDP 流量。
设计理由
● 技术可行性：NLB支持UDP和高吞吐量低延迟传输； NACL 支持显式拒绝。
● 需求匹配：该服务获得稳定的寻址和适合协议的扩展。
● 场景匹配：游戏协议是UDP，而不是HTTP。
● 工程常识：选择在所使用的协议层运行的安全和负载平衡控制。
应排除的备选方案
● CloudFront 专注于 HTTP 和 HTTPS 交付。
● AWS WAF 检查 HTTP 负载，而不是 UDP。
● ALB 不支持 UDP 侦听器。
● 安全组是仅允许的，不能明确表示拒绝。
工作流：玩家解析Route 53→NLB弹性IP→UDP监听→健康的游戏目标； NACL 拒绝不需要的流量。
减少数据库读取延迟
在考虑分片或引擎替换之前，重复的读取流量应该由缓存和数据库副本吸收。
推荐架构
● 在所需的可用区中部署 ElastiCache。
● 缓存频繁请求的记录和查询结果。
● 添加 RDS 只读副本并将只读流量路由到它们。
设计理由
● 技术可行性：ElastiCache 提供内存中响应，副本分发数据库读取。
● 需求匹配：公告流量的延迟较低，应用程序更改有限。
● 场景匹配：此次发布会造成读取量激增。
● 工程常识：在增加数据库大小之前删除重复的工作。
应排除的备选方案
● 分片需要对代码和操作进行重大更改。
● 键空间迁移不必要地改变了数据模型。
● 更大的实例和更多的 IOPS 可以垂直扩展。
● CloudFront 支持静态内容，但不能支持每个动态数据库查询。
● 没有可用区恢复能力的缓存节点可能会成为故障点。
工作流：应用程序检查缓存→命中返回→未命中读取副本→更新缓存→写入保留在主服务器上。
在 CloudFormation 中连接 SNS 和 SQS
基础设施即代码应该使用资源引用而不是硬编码标识符来创建通知主题、队列和订阅。
推荐模板行为
● 定义 AWS::SNS::Topic 资源。
● 定义 AWS::SQS::Queue 资源。
● 使用协议 sqs 定义 SNS 订阅。
● 使用 Fn::GetAtt 检索订阅终端节点的队列 ARN。
● 允许SNS主题通过SQS队列策略发送消息。
设计理由
● 技术可行性：SNS 发布通知，SQS 为消费者持久缓冲通知。
● 需求匹配：CloudFormation 可跨环境重复创建关系。
● 场景匹配：队列端点是在堆栈部署期间生成的。
● 工程常识：引用已部署的资源属性，而不是手动复制 ARN。
应排除的备选方案
● 当需要 SQS ARN 时，队列 URL 不是 SNS 订阅终端节点。
● 仅创建主题和队列不会订阅它们。
● 忽略队列策略可能会阻止 SNS 传递。
● 硬编码的 ARN 会降低可移植性，并且可能会定位到错误的账户或区域。
工作流：部署主题→部署队列→解析队列ARN→创建订阅→授权主题→测试消息传递。
使用 DynamoDB 处理全局半结构化数据
需要本地低延迟读取和写入的多区域应用程序可以使用具有托管区域计算的 DynamoDB 全局表。
推荐架构
● 在区域 ALB 后面的每个区域中部署 Fargate 应用程序服务。
● 将半结构化记录存储在 DynamoDB 全局表中。
● 使用 Global Accelerator 将用户路由到附近健康的 ALB。
设计理由
● 技术可行性：全局表提供多活复制； Fargate 取消了服务器管理； Global Accelerator 提供健康感知的选播路由。
● 需求匹配：用户以高可用性接收区域写入和读取。
● 场景匹配：数据是半结构化的并且在全球范围内活跃。
● 工程常识：将数据库的复制模型与应用程序的主动-主动行为保持一致。
应排除的备选方案
● Aurora 是关系型的，对于该数据模型来说不太自然。
● EC2 添加了服务器操作。
● DocumentDB 在所描述的设计中是区域性的。
● S3 复制是异步对象复制，而不是低延迟记录访问。
工作流：用户 → 全局加速器 → 区域 ALB → Fargate → 本地 DynamoDB 副本 → 全局复制。
无服务器 REST 会话服务
基于状态的 REST API 可以使用托管请求处理、无服务器逻辑和可扩展会话存储。
推荐架构
● 使用 API Gateway 获取 REST 资源、阶段、API 密钥和使用控制。
● 在 Lambda 中运行状态转换逻辑。
● 使用 Auto Scaling 将会话存储在 DynamoDB 中。
设计理由
● 技术可行性：API Gateway 调用 Lambda，DynamoDB 提供低操作可扩展状态。
● 需求匹配：该服务支持 REST API、测试阶段和可变需求，无需服务器管理。
● 场景匹配：现有接口是 REST 而不是 GraphQL。
● 工程常识：选择与客户端合同匹配的API服务。
应排除的备选方案
● EC2、NLB 和 Aurora 添加服务器和数据库操作。
● AppSync 公开 GraphQL 而不是所需的 REST 接口。
● ALB 可以调用 Lambda，但缺少 API Gateway 的直接 API 密钥、使用计划和阶段工作流程。
● 固定的数据库容量与可变的会话需求相冲突。
工作流：REST 请求 → API 网关授权和阶段 → Lambda 逻辑 → DynamoDB 会话更新。
EC2 到 Aurora 的安全组引用
可以通过引用安全组而不是广泛的 CIDR 范围来将数据库访问限制为应用程序实例。
推荐规则
● 允许从 EC2 安全组到 Aurora 安全组的出站 TCP 3306。
● 允许 Aurora 安全组上来自 EC2 安全组的入站 TCP 3306。
● 删除更广泛的数据库访问规则。
设计理由
● 技术可行性：安全组是有状态的，可以引用其他安全组。
● 需求匹配：只有经过批准的应用程序实例才能发起 MySQL 连接。
● 场景匹配：EC2 是客户端，Aurora 是服务器。
● 工程常识：授权工作负载身份组而不是更改实例 IP 地址。
应排除的备选方案
● 应用程序不需要其自己的安全组上的入站数据库流量。
● Aurora 不会启动应用程序数据库会话。
● NACL CIDR 规则更广泛且无国籍。
● 单独的入站 NACL 忽略了返回路径考虑因素并且缺乏安全组精度。
工作流：EC2 发起 3306 → 出站 SG 检查 → Aurora 入站 SG 检查 → 允许有状态返回流量。
管理型智能联络中心
自动呼叫处理需要持久的工作集成、语音理解、意图识别和托管代理平台。
推荐架构
● 使用 Amazon Connect 进行入站呼叫、路由和代理工作流程。
● 使用 Amazon Lex 进行语音识别和意图检测。
● 在必须异步缓冲后端工作的情况下使用 Amazon SQS。
● 调用受控应用程序集成来执行业务操作。
设计理由
● 技术可行性：Connect 提供联络中心基础设施，Lex 解释呼叫者请求，SQS 解耦后端任务。
● 需求匹配：常见请求可以自动化并在必要时升级给代理。
● 场景匹配：工作负载是客户呼叫，而不是纯文本分析。
● 工程常识：将对话状态与持久的业务工作分开。
应排除的备选方案
● Alexa for Business 不是客户联络中心平台。
● Kinesis 和 Comprehend 不提供呼叫语音识别和路由。
● Rekognition 分析图像和视频。
● Polly 发出语音，但无法检测呼叫者的意图。
工作流：呼叫者 → 连接流程 → Lex 意图 → 业务集成或 SQS → 响应或代理转移。
缓冲捐款激增
捐赠活动需要持久的突发吸收、弹性工作人员和可预测的可扩展写入。
推荐架构
● 将捐赠请求放入 Amazon SQS 中。
● 根据队列深度扩展 EC2 工作线程。
● 将已处理的捐赠存储在 DynamoDB 中，并为活动预置吞吐量大小。
● 使用幂等性和死信处理。
设计理由
● 技术可行性：SQS 保护请求，Auto Scaling 添加使用者，DynamoDB 处理高写入吞吐量。
● 需求匹配：突发流量不会使一条同步数据库路径超载。
● 场景匹配：该活动会创建临时写入突发。
● 工程常识：在执行较慢的处理之前持久地接受请求。
应排除的备选方案
● 没有队列的 DynamoDB 无法保护下游处理免受峰值影响。
● CloudFront 不缓冲捐赠写入。
● 一个 RDS 实例保持垂直边界。
● 专用的超大型 Oracle 主机成本高昂且操作繁重。
工作流：捐赠者提交 → SQS → 工作人员规模 → 验证并写入 DynamoDB → 确认并通知。
现代化 WebSphere、DB2 和 IBM MQ
托管平台重组可以保留关键应用程序接口，同时减少数据库和消息代理操作。
推荐架构
● 使用 SCT 和 DMS 将 DB2 迁移到 Aurora。
● 在 ELB 后面的 EC2 Auto Scaling 上运行 WebSphere。
● 在兼容性允许的情况下，将自我管理的 IBM MQ 基础设施替换为 Amazon MQ。
设计理由
● 技术可行性：SCT 转换架构，DMS 移动数据，EC2 保留 WebSphere，Amazon MQ 支持托管代理兼容性。
● 需求匹配：在不重写整个应用程序的情况下，可用性会提高，而操作会下降。
● 场景匹配：不同的层级需要不同的迁移策略。
● 工程常识：实现托管等价物的现代化，同时保留重写成本高昂的协议。
应排除的备选方案
● 在 EC2 上自我管理 IBM MQ 可保留许可和操作。
● 重新托管每个 IBM 产品对云的好处微乎其微。
● 用 SQS 替换 MQ 可能需要更改应用程序。
● 保持 DB2 自我管理会错过托管数据库的节省。
工作流：转换架构 → 迁移数据 → 部署 WebSphere 队列 → 配置 Amazon MQ → 测试 → 切换。
组织范围内的 CloudTrail 日志记录
集中式组织跟踪记录成员帐户的活动，无需为每种访问方法创建单独的跟踪。
推荐架构
● 从管理账户创建 CloudTrail 组织跟踪。
● 启用对所有组织帐户和所需区域的覆盖。
● 将日志传送到专用的 S3 存储桶。
● 加密审核日志并启用强大的删除保护，包括适当的 MFA 删除。
设计理由
● 技术可行性：一项跟踪记录参与帐户之间的控制台、SDK、CLI 和 API 活动。
● 需求匹配：中央存储提高了审计覆盖范围、完整性和管理。
● 场景匹配：该公司通过 AWS Organizations 管理多个账户。
● 工程常识：将审计证据与工作负载管理员分开。
应排除的备选方案
● 单一账户跟踪不覆盖整个组织。
● SNS 发送通知不是审核记录。
● 区域路线可能会忽略其他区域的活动。
● 控制台、SDK 和 CLI 的单独路径无需重复配置。
工作流：成员帐户操作→组织跟踪→加密的S3日志→受控的审核员访问→保留监控。
扩展 Web 会话和 Aurora 读取
有状态 Web 应用程序需要第 7 层负载平衡、弹性计算和可扩展的数据库读取器。
推荐架构
● 在 ALB 后面的 Auto Scaling 组中运行 Web 实例。
● 仅当应用程序需要时才启用粘性会话。
● 添加 Aurora 副本并使用 Aurora Auto Scaling 来获取读取容量。
● 保持写入定向到写入器端点。
设计理由
● 技术可行性：ALB支持HTTP路由和粘性； Aurora Auto Scaling 根据负载添加副本。
● 需求匹配：Web 需求和数据库读取独立扩展。
● 场景匹配：会话是有状态的并且读取流量各不相同。
● 工程常识：Aurora Auto Scaling 扩展副本，而不是写入器。
应排除的备选方案
● NLB 缺乏规定的第 7 层路由和粘性会话行为。
● Aurora Auto Scaling 不会扩展主数据库。
● 仅扩展 EC2 会给数据库带来读取压力。
● 粘性会话会降低平衡效率，因此在可行的情况下最好使用外部会话存储。
工作流：客户端 → ALB 粘性路由 → Auto Scaling 实例 → 用于读取的读取器端点 → 用于更新的写入器。
高峰负载期间经济高效的可用性
多可用区应用程序应保持足够的空间，以承受一个可用区的损失，同时将定价模型与负载稳定性相匹配。
推荐架构
● 跨所有可用区运行 Auto Scaling。
● 保持峰值条件下的恢复空间。
● 通过预留定价涵盖稳定的使用情况。
● 使用可靠的按需容量来应对关键峰值，并使用可选的 Spot 来应对宽容的工作。
● 需求下降后缩小规模。
设计理由
● 技术可行性：当一个可用区发生故障时，Auto Scaling 会替换健康可用区中的容量。
● 需求匹配：该应用程序可以承受高峰流量，而无需永久过度配置每个区域。
● 场景匹配：故障期间的高利用率几乎没有剩余容量。
● 工程常识：可用性计算必须使用故障后容量，而不是正常容量。
应排除的备选方案
● 修复了正常运行期间的容量过剩问题。
● 每个可用区的实例太少，无法吸收故障后的峰值流量。
● All-Spot 容量可能会在中断期间消失。
● 单可用区 Auto Scaling 组的可用性不高。
工作流：覆盖基线 → 峰值扩展开始 → AZ 失败 → 健康的 AZ 扩展 → 负载重新分配 → 队列稍后缩小。
通过 AppSync 订阅进行实时评论
客户端可以通过 WebSockets 上的 GraphQL 订阅实时接收新评论。
推荐架构
● 通过 AWS AppSync 发布评论突变。
● 定义与这些突变相关的 GraphQL 订阅。
● 让连接的客户端接收推送的更新。
● 将评论存储在现有的持久数据存储中。
设计理由
● 技术可行性：AppSync 维护 WebSocket 连接并推送订阅事件。
● 需求匹配：新评论出现，无需重复投票。
● 场景匹配：该应用程序需要实时客户端更新。
● 工程常识：仅推送用户有权接收的事件。
应排除的备选方案
● 每三秒轮询一次会增加 API 和 Lambda 负载。
● 更多 Lambda 并发不会将数据推送到连接的客户端。
● CloudFront 缓存可以提供过时的评论，并且不是双向实时通道。
● 单独的数据库写入不会通知客户端。
工作流：用户发布突变 → AppSync 授权并存储 → 订阅事件 → 连接的客户端更新。
具有持久区域存储的解耦处理
附加 EBS 的单个 EC2 服务器无法独立扩展以进行上传和处理。独立的对象存储、工作队列和工作人员容量。
推荐架构
● 将申请人文档和照片存储在 Amazon S3 中。
● 启用 S3 跨区域复制以保护区域数据。
● 将验证任务放置在 Amazon SQS 上。
● 根据队列深度扩展 EC2 工作线程实例。
● 使用 CloudFormation 在另一个区域复制基础设施。
设计理由
● 技术可行性：S3 提供持久的可扩展对象存储，SQS 缓冲工作，Auto Scaling 添加并行处理器。
● 需求匹配：上传增长不再取决于一台 EBS 卷，流量激增不会压垮一台服务器。
● 场景匹配：文件被接受后，验证任务可以异步处理。
● 工程常识：将摄取与处理分离，并将持久数据保留在工作实例之外。
应排除的备选方案
● SNS 是推送通知，而不是具有队列深度扩展的持久工作积压。
● 更大的预配置 IOPS EBS 改进了一个卷，但保留了实例附加存储限制。
● EBS不提供共享的跨Region对象存储。
● 从 SNS 通知数量进行扩展缺乏持久的重试和积压语义。
工作流：上传到 S3 → 排队任务 → 工作规模 → 处理文件 → 存储结果 → 复制对象并根据需要恢复堆栈。
突发就绪电子商务架构
大型销售需要弹性的网络容量、全球内容交付、可扩展的身份以及能够吸收突然爆发的购买的结帐路径。
推荐架构
● 将 Elastic Load Balancer 放置在 EC2 Auto Scaling 组之前。
● 通过 Amazon CloudFront 缓存静态资产。
● 使用 Amazon Cognito 进行客户和社交登录。
● 在 Amazon SQS 中缓冲结帐请求。
● 将排队购买处理到 Amazon DynamoDB 中。
设计理由
● 技术可行性：Auto Scaling 增加了 Web 容量，SQS 在高峰期间保留请求，DynamoDB 水平扩展事务记录。
● 需求匹配：该设计可支持数百万访客，而不会导致结账人员同步超载。
● 场景匹配：浏览流量和购买处理具有不同的突发模式。
● 工程常识：将接受与处理分离，这样暂时的后端减速就不会丢失订单。
应排除的备选方案
● 固定的 EC2 机群无法承受不可预测的销售激增。
● 没有缓冲的 RDS 可能会成为写入瓶颈。
● 单独的静态 S3 托管无法执行动态结帐逻辑。
● IAM 用户不是公共客户的可扩展身份模型。
工作流：客户 → CloudFront 或负载均衡器 → Cognito 会话 → SQS 中的结账消息 → 工作人员 → DynamoDB 订单状态。
组织范围内所需的带有 SCP 的标签
当所需的标签键或请求标签丢失时，组织 SCP 可以拒绝资源创建。
推荐架构
● 定义所需的标签键，例如成本中心和所有者。
● 将 SCP 条件与 aws:TagKeys 和请求标签键一起使用。
● 将 SCP 连接到适当的 OU。
● 测试其创建 API 支持标记的服务。
设计理由
● 技术可行性：显式拒绝会阻止成员帐户之间的不合规创建。
● 需求匹配：未标记的资源不能消耗配额或产生未分配的成本。
● 场景匹配：执法必须集中。
● 工程常识：创建后标记或使用不同 API 的服务的帐户。
应排除的备选方案
● AWS Config 在创建后检测丢失的标签。
● Systems Manager 不是组织范围内的预防策略服务。
● 每个账户的 IAM 条件需要重复管理。
● 标签策略标准化了值，但本身并不强制执行每个创建操作。
工作流：创建请求包含标签 → SCP 评估键和值 → 合规请求继续；缺少标签被拒绝。
使用 CodeDeploy 安全混合部署
跨越 EC2 和本地服务器的部署平台需要不同的身份机制，但需要一个发布工作流程。
推荐架构
● 将数据库凭据作为 KMS 加密的 SecureString 参数存储在 Systems Manager Parameter Store 中。
● 安装所需的部署和管理代理。
● 为 EC2 实例提供包含参数和解密权限的实例配置文件。
● 使用适当的服务标识注册本地实例。
● 对两个目标环境使用 AWS CodeDeploy。
设计理由
● 技术可行性：CodeDeploy 支持 EC2 和注册的本地实例； Parameter Store 提供加密的运行时配置。
● 需求匹配：凭证在静态和传输过程中保持加密状态，并且发布始终自动化。
● 场景匹配：该应用程序在预留的 EC2 容量和现有的本地服务器上运行。
● 工程常识：不要假装本地服务器可以接收 EC2 实例配置文件。
应排除的备选方案
● Elastic Beanstalk 不会部署到任意本地服务器。
● 将 Secrets Manager 存储与 Parameter Store 权限混合使用会不一致。
● 将 EC2 实例配置文件策略附加到本地计算机并不是正确的身份模型。
工作流：存储参数 → 分配目标身份 → 部署修订版 → 在运行时检索机密 → 验证应用程序。
大型游戏包全球交付
静态 5 GB 游戏包应使用持久对象存储和全局 CDN，而不是文件传输服务器。
推荐架构
● 将包存储在 Amazon S3 中。
● 创建以 S3 作为源的 CloudFront 分配。
● 将 Route 53 用于公共领域。
● 配置缓存和源保护。
设计理由
● 技术可行性：S3 持久存储对象，CloudFront 通过边缘位置扩展下载。
● 需求匹配：全球用户只需最少的服务器管理即可获得较低延迟的交付。
● 场景匹配：该包是静态的，并且对于每个下载者来说都是相同的。
● 工程常识：不要为全局可缓存的公共文件运行 FTP 服务器。
应排除的备选方案
● 请求者付款需要经过身份验证的 AWS 请求者，不适合匿名网站下载。
● EC2 FTP、EFS 和 NLB 需要服务器扩展和更高的操作。
● EBS 不会在 Auto Scaling 队列中自动共享。
● ALB 不支持 FTP 流量。
工作流：用户解析域 → CloudFront 边缘 → 缓存包或 S3 源获取 → 下载。
跨网络和应用层的 DDoS 防护
防御第 3 层、第 4 层和第 7 层攻击需要互补的托管控制。
推荐架构
● 为受支持的公共资源启用 AWS Shield Advanced 并增强 DDoS 响应。
● 将 AWS WAF Web ACL 应用于公共 HTTP 终端节点。
● 为检测到的攻击配置警报和响应联系人。
设计理由
● 技术可行性：Shield Advanced 可解决基础设施层攻击，而 WAF 可过滤恶意 HTTP 请求模式。
● 需求匹配：该组合涵盖网络、传输和应用层，并支持攻击通知。
● 场景匹配：公共加密货币平台可能是容量攻击和网络层攻击的目标。
● 工程常识：没有任何一个 Web 过滤器能够阻止所有基础设施泛滥，并且网络保护无法理解所有 HTTP 有效负载。
应排除的备选方案
● CloudFront 提高了弹性，但并不能单独提供所需的完整保护和响应功能。
● AWS 网络防火墙控制 VPC 流量，但不是公共终端节点的主要托管 DDoS 服务。
● Amazon Fraud Detector 评估欺诈性业务活动，而不是网络攻击。
● 仅扩展源会增加成本而不过滤恶意流量。
工作流：互联网流量→屏蔽防护→边缘或负载均衡器→WAF检查→应用；警报触发响应。
通过 IAM 身份中心进行集中劳动力访问
大型多帐户环境需要集中的权限集以及与现有公司目录的联合。
推荐架构
● 使用 AWS Organizations 作为账户层次结构。
● 启用 IAM 身份中心。
● 与企业 Active Directory 建立所需的信任或集成。
● 将用户和组分配给跨帐户的权限集。
设计理由
● 技术可行性：Identity Center 创建集中管理的帐户分配和联合会话。
● 需求匹配：员工使用现有凭据，对数百个帐户进行较低的管理。
● 场景匹配：该设计是员工 SSO，而不是客户身份。
● 工程常识：集中身份和权限分配，而不是逐个帐户维护角色映射。
应排除的备选方案
● 自定义 AD FS 正则表达式和角色映射需要大量手动工作。
● AD Connector 可以代理身份验证，但不能取代集中式多帐户权限集。
● 品牌定制门户仍然需要集成和角色管理代码。
● 单独的 IAM 用户重复生命周期管理。
工作流：员工身份验证→目录信任→身份中心分配→临时帐户会话。
立即 IP 阻止和托管 DDoS 防护
在子网边界阻止已知的恶意源，并针对更广泛的 DDoS 攻击使用专用保护。
推荐架构
● 将有问题的 CIDR 的显式拒绝添加到相关网络 ACL。
● 使用 AWS Shield Advanced 对受支持的资源提供增强的 DDoS 保护。
设计理由
● 技术可行性：网络ACL是无状态的，支持显式拒绝规则； Shield Advanced 提供托管 DDoS 检测和响应功能。
● 需求匹配：源头立即被封锁，环境获得更广泛的保护，免受常见基础设施攻击。
● 场景匹配：端口扫描针对 VPC 子网内的 EC2 资源。
● 工程常识：使用可以在流量到达主机之前拒绝流量的网络控制。
应排除的备选方案
● 安全组是仅允许的，不能表达显式的源拒绝。
● Route 53 不是 IP 防火墙。
● Macie 发现敏感的 S3 数据，而不是 DDoS 流量。
● 主机防火墙需要针对每个实例进行更改，并且只有在流量消耗网络资源后才能到达。
● GuardDuty 和补丁管理器改进了检测和卫生，但不提供所请求的立即阻止和 DDoS 保护。
工作流：识别 CIDR → 在 NACL 中拒绝 → 验证影响 → 启用托管保护 → 监控结果。
持久且可扩展的新闻发布平台
新闻网站应该在全球范围内分发媒体、扩展数据库读取并将静态资产保留在网络服务器磁盘之外。
推荐架构
● 在 Amazon S3 中存储图像、视频和静态媒体。
● 通过 Amazon CloudFront 交付内容。
● 使用 Amazon RDS 多可用区实现数据库高可用性。
● 为读取量大的评论和文章查询添加 RDS 只读副本。
● 保持应用程序服务器无状态且可扩展。
设计理由
● 技术可行性：S3 和 CloudFront 扩展内容交付，而 RDS 多可用区和副本则分别解决可用性和读取负载问题。
● 需求匹配：该设计经久耐用，具有全球响应能力，并支持流量增长。
● 场景匹配：新闻媒体是静态内容，而评论和元数据仍然相关。
● 工程常识：多可用区保护写入者；读取副本规模读取。他们解决不同的问题。
应排除的备选方案
● EBS RAID 将介质耐用性和扩展性与各个服务器联系起来。
● EFS 可以共享文件，但与 S3 相比并不是最好的全局内容源。
● Lambda 不会自动修复设计不当的有状态 Web 层。
● Oracle RAC 在规定的需求之外增加了成本和操作复杂性。
工作流：将媒体发布到 S3 → 通过 CloudFront 缓存 → 将元数据写入主数据库 → 提供从副本的读取服务。
扩展读取繁重的 Web 应用程序
读取密集型应用程序可以在分片或垂直扩展之前通过数据库副本、缓存、静态卸载和适当大小的计算进行改进。
推荐架构
● 添加 RDS 只读副本。
● 使用多可用区 ElastiCache 处理重复的查询结果。
● 将静态媒体移至 CloudFront 后面。
● 使用 Compute Optimizer 调整 EC2 容量大小。
设计理由
● 技术可行性：副本卸载读取，缓存删除重复查询，CloudFront 减少源流量。
● 需求匹配：通过降低成本和减少应用程序更改来提高性能。
● 场景匹配：瓶颈在于高读取量。
● 工程常识：在引入数据分区之前消除重复的工作。
应排除的备选方案
● 分片增加了主要的应用程序和操作复杂性。
● 预配置 IOPS 有助于存储受限的工作负载，但可能无法解决重复查询。
● 较大的数据库实例仅提供垂直扩展。
● 仅扩展应用程序服务器就可以保持 RDS 压力不变。
工作流：查看器静态请求→CloudFront；动态请求 → 应用程序 → ElastiCache → 未命中时读取副本 → 更新写入器。
NLB 背后的 PrivateLink 流量控制
PrivateLink 客户端连接到网络负载均衡器，因此后端控制必须考虑 NLB 到目标的网络路径。
推荐控制
● 配置网络 ACL 以允许 NLB 子网和日志记录服务子网之间双向所需的流量。
● 配置 EC2 目标安全组以允许来自 NLB 子网 IP 范围的入站应用程序流量。
● 拒绝不必要的端口。
设计理由
● 技术可行性：NLB 接受端点服务连接并将其转发到已注册的目标。
● 需求匹配：仅预期的负载均衡器路径到达日志记录实例。
● 场景匹配：消费者使用 PrivateLink，而不是直接连接到后端 EC2 地址。
● 工程常识：在选择防火墙规则的源地址之前跟踪完整的数据包路径。
应排除的备选方案
● 客户端 VPC CIDR 不一定是此架构中的目标观察到的直接源。
● 所述模型中的网络负载均衡器不使用安全组作为主要过滤器。
● 允许所有私有地址范围比要求的范围更广泛。
● 由于网络 ACL 是无状态的，仅配置一个 NACL 方向会失败。
工作流：接口端点 → 端点服务 → NLB 子网 → 目标子网 NACL → EC2 安全组 → 日志服务。
经济高效的直连备份
单个 Direct Connect 电路是一个故障点，但成本最低的备份不需要购买另一个专用电路。
推荐架构
● 建立从数据中心到每个 VPC 的 AWS Site-to-Site VPN 连接。
● 终止相应虚拟专用网关上的每个 VPN。
● 使用BGP发布和选择备份路由。
● 在正常操作期间首选直接连接，并在需要时不使用 VPN。
设计理由
● 技术可行性：动态路由可以撤销专线路径并选择可用的VPN路由。
● 需求匹配：该解决方案以比其他 Direct Connect 连接更低的成本添加了混合连接冗余。
● 场景匹配：十个 VPC 已依赖于一条托管电路。
● 工程常识：将备份成本和性能与紧急使用相匹配，而不是自动复制完整的主容量。
应排除的备选方案
● 每个 VPC 的 MPLS 成本高昂且配置缓慢。
● 第二个 Direct Connect 提供更强的专用冗余，但成本更高。
● 通过新购买的第二个 Direct Connect 的 VPN 仍需支付另一条线路的费用。
工作流：构建 VPN → 配置 BGP 优先级 → 测试路由撤销 → 验证每个 VPC → 监控隧道状态。
现代化桌面应用程序和 MySQL
托管现代化可以流式传输桌面应用程序、将 MySQL 迁移到 Aurora 以及跨可用区托管支持 Web 服务。
推荐架构
● 使用 Amazon AppStream 2.0 进行集中管理的桌面应用程序流。
● 将 MySQL 迁移到 Amazon Aurora。
● 在 ALB 后面的多可用区 Auto Scaling 组中运行 Web 或应用程序服务。
设计理由
● 技术可行性：AppStream 流式传输应用程序，无需完整的桌面管理； Aurora 兼容 MySQL； ALB 和 Auto Scaling 提供弹性托管。
● 需求匹配：该设计减少了基础设施运营，同时提高了规模和可用性。
● 场景匹配：用户需要应用程序而不是完整的持久桌面。
● 工程常识：选择满足访问要求的最窄管理最终用户服务。
应排除的备选方案
● WorkSpaces 提供完整的桌面，并且在仅需要应用程序时可能会增加成本。
● 自我管理的 MySQL 保留备份和故障转移工作。
● CloudFront 不会加速交互式桌面协议。
● Redshift 不是 OLTP MySQL 的替代品。
● ElastiCache 无法交付桌面应用程序，DynamoDB 转换需要进行重大重新设计。
工作流：用户启动流 → AppStream 会话 → 应用程序到达 ALB 服务 → Aurora 存储关系数据。
使用临时 AWS 凭证进行社交登录
移动应用程序可以用 OIDC 社交身份令牌交换临时 AWS 权限。
推荐架构
● 使用支持的社交身份提供商对用户进行身份验证。
● 致电 STS AssumeRoleWithWebIdentity。
● 将身份映射到 S3 和 DynamoDB 范围内的 IAM 角色。
● 使用移动 SDK 中的临时凭证。
设计理由
● 技术可行性：STS 验证 Web 身份令牌并返回短期角色凭据。
● 需求匹配：该应用程序无需嵌入长期密钥即可访问 AWS 资源。
● 场景匹配：社交提供商使用 OIDC 风格的网络身份联合。
● 工程常识：将移动设备视为永久机密的不受信任位置。
应排除的备选方案
● 即使提到 Cognito，长期访问和密钥仍然不安全。
● AssumeRoleWithSAML 针对企业 SAML 联盟。
● IAM 用户的通用 AssumeRole 不会直接验证社交令牌。
● 分发一把共享密钥会妨碍安全的用户隔离。
工作流：社交登录 → OIDC 令牌 → STS 角色交换 → 临时凭证 → 范围 S3 或 DynamoDB 请求。
月末 MySQL 读取扩展
可预测的读取峰值最好通过托管数据库操作和临时只读副本来处理。
推荐架构
● 将自我管理的 MySQL 从 EC2 迁移到 Amazon RDS for MySQL。
● 在月底之前添加只读副本。
● 将报告查询路由到副本。
● 峰值后删除不必要的副本。
设计理由
● 技术可行性：RDS 管理备份和维护，而副本则卸载写入器的读取操作。
● 需求匹配：在可预测的窗口期间，性能会得到提高，操作风险也会降低。
● 场景匹配：瓶颈在于读取量大的月末处理。
● 工程常识：扩展查询路径而不是重复更改存储硬件。
应排除的备选方案
● 快照和切换 EBS 类型速度慢且风险大。
● Lambda 无法透明地调整正在运行的 EC2 数据库的大小。
● 垂直缩放仍然有限。
● ALB 预热与数据库读取无关。
● 对于每个繁重的 I/O 工作负载，gp2 不会自动变得更快。
工作流：迁移到 RDS → 在峰值之前添加副本 → 路由读取 → 监控滞后 → 之后删除副本。
使用 AWS MGN 进行持续 VMware 迁移
物理或VMware服务器可以通过连续的块级复制和受控切换迁移到EC2。
推荐架构
● 在每台源服务器上安装 AWS Replication Agent。
● 使用 AWS Application Migration Service 暂存资源。
● 持续复制磁盘更改。
● 启动测试实例、验证并启动切换。
设计理由
● 技术可行性：代理发送块级更改，MGN 将复制的服务器转换为 EC2 启动资源。
● 需求匹配：测试和最终同步可减少停机时间。
● 场景匹配：现有虚拟机必须在不重新设计应用程序的情况下进行迁移。
● 工程常识：测试用于生产切换的相同复制流。
应排除的备选方案
● CloudFormation 会重建基础架构，但不会复制 VM 磁盘。
● Direct Connect 和 Service Catalog 不执行 VM 转换。
● SAM 部署无服务器应用程序。
● ECS 托管容器，而不是导入的虚拟机。
工作流：安装代理 → 复制到暂存 → 测试启动 → 修复 → 最终同步 → 切换 → 停用源。
使用 Secrets Manager 轮换数据库密码
数据库密码应存储在专用的秘密服务中，在运行时检索并引用，而不会出现在模板中。
推荐架构
● 将 RDS 主密码存储在 AWS Secrets Manager 中。
● 使用批准的 KMS 密钥对其进行加密。
● 在支持的情况下配置托管轮换。
● 让应用程序通过 IAM 角色在运行时检索密钥。
● 对 MasterUserPassword 使用 CloudFormation 动态引用。
设计理由
● 技术可行性：动态引用在配置期间解析秘密，而无需在模板中嵌入明文。
● 需求匹配：密码受到集中保护、访问控制且可轮换。
● 场景匹配：基础设施部署和应用程序连接都需要相同的凭证生命周期。
● 工程常识：切勿将数据库密码复制到用户数据、源存储库或输出中返回的模板参数中。
应排除的备选方案
● 普通 CloudFormation 参数可以通过处理和部署工作流程公开值。
● 普通的 Ref 不提供秘密轮换。
● 硬编码的应用程序配置在轮换后会变得陈旧。
● 没有所需旋转工作流程的参数存储对于此要求来说不太直接。
工作流：创建秘密→使用动态引用部署RDS→应用程序检索秘密→旋转→应用程序刷新连接。
NGINX和MySQL高效迁移
通过创建弹性 Web 层并使用托管数据库迁移路径，小型交互式 Web 应用程序可以迁移到 AWS。
推荐架构
● 在两个可用区中启动 NGINX EC2 实例。
● 通过 S3 暂存位置复制应用程序文件。
● 使用 AWS Database Migration Service 迁移 MySQL 数据。
● 将 Web 服务器放置在弹性负载均衡器后面。
● 为负载均衡器创建 Route 53 别名记录。
设计理由
● 技术可行性：EC2 保留现有的 NGINX 应用程序，DMS 移动数据库记录，负载均衡器分配流量。
● 需求匹配：该设计无需对应用程序进行重大重写即可提高可用性。
● 场景匹配：源由一台 NGINX 服务器和一个 MySQL 数据库组成。
● 工程常识：首先重新托管应用程序层，并通过稳定的负载平衡端点管理流量。
应排除的备选方案
● 动态应用程序不能简单地作为 S3 静态网站运行。
● Application Discovery Service 会清点工作负载，但不会迁移 Web 服务器。
● 私有托管区域不为公共用户提供服务。
● 多可用区数据库不仅仅位于一个可用区。
工作流：构建两个Web节点→复制文件→迁移数据库→验证→放置在负载均衡器后面→切换Route 53。
更安全的自动化部署
低停机时间交付流程应该测试代码、预览基础设施效果并保留快速回滚路径。
推荐架构
● 使用 CodeBuild 运行自动化非生产测试。
● 在基础设施更新之前创建 CloudFormation 更改集。
● 对应用程序使用 CodeDeploy 蓝/绿部署。
● 仅在验证后转移流量并回滚失败的警报。
设计理由
● 技术可行性：CodeBuild 执行测试，更改集显示计划的资源更改，蓝色/绿色保持旧环境可用。
● 需求匹配：该工作流程减少了停机时间和部署风险。
● 场景匹配：应用程序和基础设施的更改都是通过 CI/CD 发生的。
● 工程常识：语法验证是必要的，但不能证明运行时行为。
应排除的备选方案
● 单独的模板验证并不能测试应用程序或预览所有影响。
● 手动实例测试缓慢且不一致。
● 帮助程序脚本和手动 QA 不提供自动流量切换和回滚。
● 就地生产更新增加了爆炸半径。
工作流：提交 → CodeBuild 测试 → 变更集审查 → 部署绿色 → 验证 → 转移流量 → 保留或删除蓝色。
现代化基于磁带的媒体目录
面向文件的媒体系统可以将存档内容移至 S3 并添加托管面部分析，而无需替换其现有界面。
推荐架构
● 在本地部署 Storage Gateway 文件网关。
● 让媒体资产系统通过文件共享复制磁带提取的文件。
● 将文件存储在 Amazon S3 中。
● 通过 Lambda 调用 Amazon Rekognition。
● 将生成的元数据写回现有目录。
设计理由
● 技术可行性：文件网关保留文件访问权限，而 Rekognition 则分析支持的 S3 媒体。
● 需求匹配：该设计最大限度地减少了中断和持续的基础设施管理。
● 场景匹配：来源是历史磁带档案，而不是实时流。
● 工程常识：在现有 MAM 系统已经理解的接口后面引入云服务。
应排除的备选方案
● Kinesis Video Streams 针对实时视频摄取进行了优化。
● 当 Rekognition 已提供该功能时，定制 SageMaker 计算机视觉培训会增加工作量。
● SFTP 和自我管理的 EC2 Vision 软件可创建修补、扩展和恢复工作。
● 替换 MAM 工作流程扩大了范围。
工作流：提取磁带文件→文件网关→S3→Lambda→Rekognition→元数据返回到目录。
经济高效的一次性 EMR 集群
一次性分析集群应保护控制和数据节点，同时仅将可中断容量用于可重新启动的工作。
推荐架构
● 在按需实例上运行 EMR 主节点和核心节点。
● 在 Spot 实例上运行任务节点。
● 将持久的输入和输出存储在一次性任务节点之外。
设计理由
● 技术可行性：主节点和核心节点维护集群控制和HDFS数据；任务节点执行可重复的计算。
● 需求匹配：Spot 可以降低成本，而不会导致关键集群状态中断。
● 场景匹配：集群运行一次，因此长期承诺效率低下。
● 工程常识：仅在可以重试丢失的工作的情况下才使用廉价的可中断容量。
应排除的备选方案
● 预留实例需要不适合一次执行的承诺。
● 只保留master仍然浪费承诺成本。
● Spot 主节点或核心节点可能会终止集群或丢失 HDFS 数据。
● 按需任务节点错过了最佳节省成本的机会。
工作流：启动稳定的 master 和 core → 添加 Spot 任务队列 → 处理数据 → 持久输出 → 终止集群。
基础设施即代码与全球 CDN
可重复的基础设施部署和全局内容加速是 CloudFormation 和 CloudFront 满足的不同需求。
推荐架构
● 在 AWS CloudFormation 中定义网络、计算、安全和托管服务。
● 将模板存储在版本控制中并通过受控管道进行部署。
● 使用 Amazon CloudFront 作为可缓存内容的全局 CDN。
设计理由
● 技术可行性：CloudFormation 一致地创建和更新 AWS 资源； CloudFront 在边缘位置缓存内容。
● 需求匹配：当用户接收较低延迟的内容时，环境变得可重复。
● 场景匹配：该解决方案需要全面的基础设施自动化，而不仅仅是应用程序部署。
● 工程常识：监控、部署和内容交付不应混淆。
应排除的备选方案
● CloudWatch 观察系统，但既不是基础设施即代码，也不是 CDN。
● Elastic Beanstalk 管理应用程序平台，但并不直接对整个环境进行全面建模。
● 手动控制台部署会产生偏差。
● CDN 不会取代基础设施配置。
工作流：提交模板→验证→部署CloudFormation堆栈→发布内容→CloudFront全局缓存和交付。
跨可用区经济高效的峰值容量
多可用区 Web 层应将可预测的基本容量与容错峰值容量分开。
推荐架构
● 保持预留实例覆盖率以实现稳态使用。
● 利用多元化现货容量应对临时高峰。
● 将 Auto Scaling 容量放置在可用区中。
● 让扩展策略替代可用区或 Spot 中断期间损失的容量。
设计理由
● 技术可行性：无状态 Web 服务器可以在不保留本地会话状态的情况下被替换。
● 需求匹配：Spot 降低了峰值成本，而 Auto Scaling 支持快速容量恢复。
● 场景匹配：该应用程序已经跨越了三个可用区，并且在高峰期间达到了非常高的利用率。
● 工程常识：不依赖于一个 Spot 池；实例类型和容量池多样化。
应排除的备选方案
● 固定预留和按需容量有效，但可能会过度配置，并且不保证自动替换。
● 预留实例是一种定价承诺，而不是特殊的 Auto Scaling 容量类型。
● 在没有 Auto Scaling 的情况下混合使用 Spot 和 On-Demand 无法提供快速恢复。
工作流：衡量基线 → 通过承诺覆盖基线 → 使峰值池多样化 → 跨可用区扩展 → 监控中断和利用率。
HPC 控制器的低延迟布局
与集群计算节点频繁通信的控制器应共享现有的集群置放群组。
推荐流程
● 如果需要，停止控制器实例。
● 将其移至计算队列的集群置放组中。
● 重新启动并测量延迟和吞吐量。
设计理由
● 技术可行性：集群置放组使受支持的实例保持物理上靠近，以实现低延迟网络。
● 需求匹配：无需重建整个集群即可改善控制器到节点的通信。
● 场景匹配：计算节点已使用正确的放置组。
● 工程常识：更改异常组件而不是破坏每个健康节点。
应排除的备选方案
● 弹性 IP 不会提高内部网络性能。
● 分散放置有意分隔实例并增加距离。
● ENA 未按照建议的方式作为单独的适配器连接。
● 重建每个计算实例会造成不必要的停机。
工作流：停止控制器→修改布局→启动→验证网络性能→恢复工作负载。
CloudFront 的国家/地区级内容限制
当报告文件必须在特定国家/地区不可用时，请在内容交付层强制实施地理位置。
推荐架构
● 通过 Amazon CloudFront 分发报告文件。
● 启用 CloudFront 地理限制。
● 配置禁止国家/地区的拒绝列表。
● 限制源访问，以便用户无法绕过 CloudFront。
设计理由
● 技术可行性：CloudFront 会评估查看者所在的国家/地区，并根据配置的地理策略阻止或允许传送。
● 需求匹配：相同的分布提供低延迟的全球交付和国家级限制。
● 场景匹配：受保护的资源是交付给全球用户的报告文件。
● 工程常识：在内容交付位置应用控制并防止直接来源访问。
应排除的备选方案
● Route 53 地理位置选择端点，但不是对单个报告文件的直接拒绝控制。
● 地理位置邻近路由根据位置和偏差转移流量；它不会阻止国家。
● 网络 ACL 国家/地区阻止需要维护较大的 IP 范围，并且仅适用于子网边界。
● Elastic Beanstalk 本身不提供地理内容限制。
工作流：查看者请求 → CloudFront 确定国家/地区 → 允许或拒绝 → 从受保护的源检索允许的内容 → 缓存在允许的用户附近。
无服务器通话录音处理
通话录音应从昂贵的主存储转移到持久对象存储、自动转录和基于生命周期的存档。
推荐架构
● 将录音存储在 Amazon S3 中。
● 当新记录到达时触发 Lambda。
● 将音频提交到 Amazon Transcribe。
● 将成绩单和元数据存储在 S3 中。
● 在合适的情况下从 S3 托管轻量级搜索或检索门户。
● 通过生命周期规则将旧录音转移到 S3 Glacier。
设计理由
● 技术可行性：S3 事件驱动无服务器处理，Transcribe 将语音转换为文本，生命周期策略自动归档。
● 需求匹配：该设计降低了运营和存储成本，同时使录音可搜索。
● 场景匹配：每次上传的调用都会进行处理，不需要始终在线的服务器。
● 工程常识：保持原件、派生抄本和存档生命周期的不同。
应排除的备选方案
● EC2 转录工作人员增加了容量和修补工作。
● 与生命周期策略相比，手动归档作业速度较慢且可靠性较低。
● 将所有录音保存在高级主动存储中会浪费成本。
● 关系数据库不是大型音频对象的正确主存储。
工作流：上传录音 → Lambda 触发器 → 转录作业 → 转录到 S3 → 门户访问 → 生命周期存档。
不可变的补丁、频繁的部署和共享数据
可扩展的 EC2 队列应从修补的映像启动，自动部署应用程序修订版，并挂载大型共享数据，而不是在启动期间下载数据。
推荐架构
● 使用 Systems Manager 自动化来修补和烘焙新的 AMI。
● 更新 Auto Scaling 组并替换旧实例。
● 使用 AWS CodeDeploy 部署应用程序修订版。
● 将 500 GB 静态数据集存储在 Amazon EFS 上并在启动时挂载。
设计理由
● 技术可行性：黄金 AMI 创建一致的操作系统状态，CodeDeploy 支持频繁发布，并且 EFS 可立即供多个实例访问。
● 需求匹配：实例可以快速扩展，部署可以每天进行多次，并且补丁可以在规定的期限内完成。
● 场景匹配：数据集是共享的和静态的，而计算实例是可替换的。
● 工程常识：不要在每次横向扩展事件期间下载 500 GB。
应排除的备选方案
● 每晚部署作业无法支持每天多个版本。
● 就地修补可能会导致混合舰队。
● 等待新供应商 AMI 并不能保证在 48 小时内安装补丁。
● 大量 S3 下载导致用户数据延迟启动。
工作流：修补映像 → 测试 → 更新启动模板 → 滚动队列 → 挂载 EFS → 使用 CodeDeploy 部署代码。
对受邀组织帐户的管理访问权限
加入 AWS Organizations 可以集中管理和计费，但管理访问权限仍然需要每个成员账户中的可信角色。
推荐架构
● 从组织管理帐户邀请现有帐户。
● 确保每个成员帐户都具有 OrganizationAccountAccessRole 或同等管理角色。
● 信托批准的管理账户委托人。
● 使用 STS 角色假设进行管理。
设计理由
● 技术可行性：组织处理会员资格； IAM 角色信任授予实际的跨账户权限。
● 需求匹配：中央管理员可以管理受邀帐户，而无需重复的长期用户。
● 场景匹配：这些帐户在加入组织之前就已存在。
● 工程常识：帐户成员资格和帐户授权是单独的控制平面。
应排除的备选方案
● 仅会员资格并不授予管理权。
● 邀请来自管理帐户。
● 控制塔注册增加了治理，但不应假定自动授予不受限制的访问权限。
● 共享根凭据是不安全且不必要的。
工作流：管理帐户发送邀请→成员接受→管理员承担受信任的角色→临时凭据管理帐户。
DNS 分配或托管负载平衡
固定公共服务器组可以使用 DNS 级多值响应，但应用程序负载均衡器是更强大的托管设计。
推荐选项
● 使用 Route 53 多值路由和运行状况检查来返回多个运行状况良好的服务器 IP。
● 当托管请求分发可用时，首选具有 Route 53 别名的 ALB。
设计理由
● 技术可行性：多值响应分配客户选择； ALB 主动平衡健康目标之间的请求。
● 需求匹配：两者都提高了可用性和分发，而 ALB 则减少了服务器地址管理。
● 场景匹配：该应用程序有多个 Web 服务器为一个域提供服务。
● 工程常识：DNS 不是一个完整的负载均衡器，因为客户端缓存答案并独立选择地址。
应排除的备选方案
● NAT 提供出站转换，而不提供入站负载平衡。
● 非别名记录不太适合 AWS 负载均衡器，并且无法支持所有顶级域情况。
● CloudFront 无法使用任意私有 EC2 IP 地址作为公共源。
● 一条静态 A 记录会留下一个服务器故障点。
工作流：DNS 返回健康的 ALB 别名或多值地址 → 客户端连接 → 健康控制删除失败的目标。
NoSQL 应用程序的快速多区域恢复
区域灾难恢复设计应该重现基础设施，复制每种数据类型，并自动进行流量故障转移和故障恢复。
推荐架构
● 使用 CloudFormation StackSets 在两个区域中部署匹配的 Auto Scaling Web 和应用程序层。
● 为静态内容启用 S3 跨区域复制。
● 使用 DynamoDB 全局表进行多区域 NoSQL 数据复制。
● 配置具有运行状况检查的 Route 53 故障转移路由。
设计理由
● 技术可行性：StackSets 标准化区域基础设施，S3 CRR 复制对象，全局表复制 DynamoDB 记录。
● 需求匹配：准备好的辅助站点可实现快速恢复，而 Route 53 可自动执行流量移动和返回。
● 场景匹配：数据库要求明确为 NoSQL，这使得 DynamoDB 全局表成为直接适合的选择。
● 工程常识：恢复速度取决于预先配置的基础设施和持续复制的数据。
应排除的备选方案
● Aurora 是关系型的，与规定的 NoSQL 层不匹配。
● Service Catalog 不会直接重现此工作流程的完整区域堆栈。
● 手动 DNS 更改会降低恢复和故障恢复速度。
● 定期备份到 S3 会留下较大的数据间隙，需要在使用前进行恢复。
工作流：部署两个区域 → 复制 S3 和 DynamoDB → 运行状况检查主区域 → 故障转移到辅助区域 → 恢复后故障恢复。
提高游戏性能的分层缓存
缓慢的游戏资源加载和重复的动态查找需要两个不同的缓存层。
推荐架构
● 通过 Amazon CloudFront 交付静态游戏资产。
● 在 Amazon ElastiCache 中缓存经常访问的动态数据。
● 将持久源数据保存在现有的权威存储中。
设计理由
● 技术可行性：CloudFront 缓存全球玩家附近的对象； ElastiCache 在应用程序架构内提供低延迟内存访问。
● 需求匹配：静态下载时间和重复后端读取时间均有所改善。
● 场景匹配：游戏文件和动态应用程序数据具有不同的访问模式。
● 工程常识：在最接近其使用者的层缓存内容。
应排除的备选方案
● DynamoDB 是一个持久数据库，而不是直接的内存缓存替代品。
● 使用 ElastiCache 进行静态全局文件传输缺乏边缘分布。
● 使用 CloudFront 作为私有快速变化的后端记录的主缓存会颠倒正确的服务角色。
● 选择不受支持或不合适的 ElastiCache 引擎会使看似合理的设计变得不可行。
工作流：静态请求 → CloudFront 边缘 → 未命中的来源；动态请求 → 应用程序 → ElastiCache → 数据库丢失。
将外部 HSM 密钥材料导入 KMS
客户生成的 HSM 密钥材料可以导入到来源为外部的 KMS 密钥中。
推荐架构
● 创建具有 EXTERNAL 来源的 KMS 密钥。
● 导入由批准的本地 HSM 生成的密钥材料。
● 配置需要使用该密钥的 SSE-KMS 的 S3 存储桶策略。
● 监控密钥材料的过期和重新导入要求。
设计理由
● 技术可行性：KMS 外部源密钥接受导入的密钥材料并可以加密 S3 对象。
● 需求匹配：组织保留对原始密钥生成过程的控制。
● 场景匹配：必须使用而不是替换现有的 HSM 生成的材料。
● 工程常识：丢失导入的密钥材料可能会导致密文无法恢复，因此请安全保存。
应排除的备选方案
● Direct Connect 不导入加密密钥。
● AWS_KMS 原始密钥无法覆盖其托管密钥材料。
● CloudHSM 自定义密钥存储创建一个新的 AWS HSM 支持的系统，而不是根据请求导入现有密钥。
● SSE-S3不使用客户导入的密钥。
工作流：在 HSM 中生成材料 → 创建外部源 KMS 密钥 → 安全导入 → 在 S3 策略中强制执行密钥。
使用 X-Ray 进行 Canary Lambda 部署
Lambda 版本可以首先公开一小部分流量，并通过下游服务跟踪请求。
推荐架构
● 使用 CodeDeploy 金丝雀流量转移。
● 将 10% 路由到新的 Lambda 版本，然后在五分钟后（如果运行正常）转移剩余的 90%。
● 对函数和支持的下游调用启用 AWS X-Ray 主动跟踪。
● 附加触发回滚的警报。
设计理由
● 技术可行性：Lambda 别名在版本之间划分流量； CodeDeploy 控制转变； X-Ray 记录请求段。
● 需求匹配：该版本限制了爆炸半径并提供端到端诊断。
● 场景匹配：所需的推出明确是两步金丝雀暴露。
● 工程常识：部署安全需要受控的流量和可观察的成功标准。
应排除的备选方案
● EC2 式滚动部署不实现 Lambda 别名百分比。
● 一次性部署消除了逐步验证。
● 线性移位使用重复的相等增量而不是所请求的金丝雀模式。
● AWS Config 记录配置但不跟踪请求。
工作流：发布版本 → 别名发送 10% → 监控警报和跟踪 → 移动 90% 或回滚。
可靠的 S3 预签名 URL
预签名 URL 仅当由授权 AWS 身份创建并在过期前使用时才有效。
推荐控制
● 为门户提供有效的 IAM 角色以及所请求的 S3 操作的权限。
● 生成具有足够长的过期时间以供用户工作流程使用的 URL。
● 保持存储桶、密钥、方法和标头与签名的请求一致。
设计理由
● 技术可行性：签名者的凭据和权限授权临时请求。
● 需求匹配：用户无需收到永久 AWS 凭证即可上传或下载。
● 场景匹配：失败是间歇性的，表明存在过期或签名身份问题。
● 工程常识：时间限制应该可以降低风险，而不会在正常转移期间过期。
应排除的备选方案
● S3 版本控制本质上不会使所寻址操作的现有 URL 失效。
● 开发人员控制台权限与门户的运行时身份是分开的。
● 仅靠 ACL 无法弥补签名者凭据的缺失。
● 在大型传输开始或完成之前，非常短的到期时间可能会失败。
工作流：门户角色签署请求→用户接收URL→S3验证签名和时间→操作成功或过期。
按月分区的博客存储和私人传送
基于时间的博客内容可以使用一个分区存储桶、自动化生命周期规则和私有 CloudFront 源。
推荐架构
● 将条目存储在基于月份的 S3 前缀下。
● 通过前缀或标签应用生命周期策略。
● 使用一个 CloudFront 发行版实现可扩展的交付。
● 将存储桶限制为 CloudFront 源身份或等效的私有源控制。
设计理由
● 技术可行性：S3 前缀组织对象，生命周期规则转换对象，CloudFront 缓存交付。
● 需求匹配：该设计减少了存储和分发管理。
● 场景匹配：博客条目具有基于时间的保留和访问模式。
● 工程常识：逻辑分区不需要单独的存储桶或分布。
应排除的备选方案
● 两个发行版重复配置，但没有改进生命周期管理。
● 最小 TTL 为零会阻止有用的缓存。
● 转发不必要的查询字符串会造成缓存碎片。
● 在两个存储桶中复制每个条目可以使存储和管理加倍，而无需恢复。
工作流：在每月前缀下发布 → CloudFront 私下检索 → 边缘缓存 → 生命周期转换旧前缀。
在 OpsWorks 中修补 Linux 实例
OpsWorks Linux 实例可以通过本机依赖项更新或受控替换来接收当前包。
推荐做法
● 运行 OpsWorks Update Dependencies 命令以获取当前软件包更新。
● 替换实例，以便设置和生命周期配方在新容量上安装当前包。
● 逐波修补并验证应用程序运行状况。
设计理由
● 技术可行性：OpsWorks 集成了包更新命令和实例生命周期配置。
● 需求匹配：Linux 服务器接收更新时服务容量风险较低。
● 场景匹配：该应用程序已使用 OpsWorks 堆栈。
● 工程常识：替换提供了更干净的状态，而就地更新可以解决紧急包裹。
应排除的备选方案
● CloudFormation 不是现有 OpsWorks 实例的本机依赖项更新机制。
● 该命令不是等效的 Windows 补丁工作流程。
● 删除整个堆栈会造成不必要的破坏。
● AWS WAF 过滤请求并且无法安装操作系统更新。
工作流：选择 Wave → 更新依赖项或替换实例 → 验证 → 继续 → 查看版本。
在 CloudFormation 堆栈删除期间保留数据
基础设施删除应消除持续的计算成本，同时通过资源适当的删除策略保留数据。
推荐配置
● 将 RDS 资源设置为 DeletionPolicy: Snapshot。
● 将 S3 存储桶设置为 DeletionPolicy: Retain。
● 仅在验证策略更改后才删除堆栈。
设计理由
● 技术可行性：CloudFormation 在删除数据库之前创建最终的 RDS 快照，并将 S3 存储桶保留在堆栈删除之外。
● 需求匹配：数据库计算费用停止，而数据库备份、图像和参赛者数据仍然可用。
● 场景匹配：应用程序已完成，需要保存而不是继续操作。
● 工程常识：在创建重复的存储工作流之前使用本机生命周期行为。
应排除的备选方案
● 不支持 Snapshot 作为 S3 存储桶的删除策略。
● RDS 上的 Retain 保留实时数据库及其持续成本，而不是仅创建备份。
● S3 复制可以保留第二个副本，但它会不必要地增加另一个存储桶、复制配置、传输和存储成本。
工作流：更新模板→审核变更→删除堆栈→验证RDS快照→验证保留桶→单独管理保留资源。
大文件的托管加密存储
需要完全托管存储、KMS 加密和仅 HTTPS 访问的大型文件适合 Amazon S3。
推荐架构
● 将文件存储在 S3 中。
● 将 SSE-KMS 与经批准的客户管理密钥结合使用。
● 添加存储桶策略，拒绝不使用安全传输的请求。
● 应用最小权限 IAM 和密钥策略。
设计理由
● 技术可行性：S3 支持大型对象、托管持久性、KMS 加密和基于策略的 HTTPS 实施。
● 需求匹配：该设计取消了服务器和卷管理。
● 场景匹配：数据由文件而不是数据库项组成。
● 工程常识：加密需要访问控制和传输策略来形成完整的保护链。
应排除的备选方案
● EC2 和 EBS 保留服务器和卷操作。
● 当不需要持续的混合访问时，迁移后不需要文件网关。
● SSE-S3 缺乏客户管理的 KMS 控制。
● DynamoDB 不适合大文件，需要应用程序级拆分。
工作流：授权的 HTTPS PUT → S3 使用 KMS 密钥 → 存储加密对象 → 策略拒绝不安全的 GET 或 PUT。
更快的全局上传到 S3
远离 S3 区域的用户可以使用 S3 传输加速通过附近的 AWS 边缘站点进行上传。
推荐架构
● 在目标存储桶上启用传输加速。
● 更新上传客户端以使用 s3-accelerate 端点。
● 从主要用户位置测试性能。
● 保留大对象的分段上传。
设计理由
● 技术可行性：加速端点在 AWS 边缘站点接收数据，并通过 AWS 全球网络将其传送到存储桶区域。
● 需求匹配：欧洲艺术家无需移动或复制水桶即可实现更快的传输。
● 场景匹配：延迟是由到当前 S3 区域的长距离互联网路径引起的。
● 工程常识：验证加速优势，因为性能和成本取决于源位置和网络条件。
应排除的备选方案
● CloudFront 主要是为内容交付而设计的，并不是这里的直接通用上传加速器。
● 创建 EC2 上传代理会增加扩展、故障和数据处理工作。
● S3 跨区域复制会在上传后复制对象，并且不会加速初始传输。
● 更改存储类别不会改善上传网络延迟。
工作流：客户端选择加速端点→最近的边缘接收上传→AWS骨干网传输对象→S3存储它。
围绕重叠的对等 VPC CIDR 进行路由
VPC 对等互连是非传递性的，使用静态路由，并在路由重叠时应用最长前缀匹配。
推荐路由
● 在VPC A中，将主机路由（例如10.0.0.77/32）添加到VPC B对等连接。
● 将更广泛的 10.0.0.0/16 路由添加到 VPC C 对等连接。
● 在VPC B和VPC C中配置互通路由。
● 确保安全组和网络 ACL 允许流量。
设计理由
● 技术可行性：/32 路由比 /16 更具体，因此所需 VPC B 主机的流量遵循正确的对等连接。
● 需求匹配：尽管地址范围重叠，但该设计仍到达两个目的地。
● 场景匹配：在一个重叠的 VPC 中只需要特定的数据库地址。
● 工程常识：对于有限的例外，优先考虑路由特异性，但避免在新设计中重叠 CIDR。
应排除的备选方案
● 对等互连不会动态交换路由。
● 网络 ACL 无法修复错误的路由决策。
● 到两个对等点的广泛重叠路由不明确，并且无法提供到两个 CIDR 空间的完全连接。
工作流：目的地查找→最长前缀匹配→选择对等连接→相互路由→安全评估。
大规模基于位置的移动警报
数百万接收时间敏感的本地优惠的用户需要持久的缓冲、可扩展的处理、快速查找和移动推送交付。
推荐架构
● Amazon SQS 中的缓冲区工作。
● 根据队列深度扩展 EC2 工作线程。
● 在 DynamoDB 中存储商品和位置映射。
● 通过 Amazon SNS 移动推送发送警报。
设计理由
● 技术可行性：SQS 吸收突发，工作人员异步处理，DynamoDB 提供可扩展的查找，SNS 提供平台推送通知。
● 需求匹配：管道可以在所需的短时间间隔内发送警报，而不会丢失突发流量。
● 场景匹配：超过200万移动用户可能会触发不规则的通知需求。
● 工程常识：将报价选择与通知传递分开，并将待处理的工作保留在队列中。
应排除的备选方案
● AWS Device Farm 测试应用程序；它不提供生产推送通知。
● AWS AppSync 提供托管 GraphQL 和订阅，但不是直接批量移动推送服务。
● 直接同步处理在突发需求时缺乏缓冲。
● Pinpoint 可以支持活动，但 SQS、worker、DynamoDB 和 SNS 链更直接地适合规定的事务工作流程。
工作流：位置事件 → SQS → 工作人员选择 DynamoDB 产品 → SNS 推送 → 移动设备。
使用 CloudTrail 进行审核员访问
审核员需要权威的 API 历史记录以及专用的只读身份来检查日志和资源。
推荐架构
● 跨所需区域和全球服务启用 AWS CloudTrail。
● 将日志传送到受保护的 S3 存储桶。
● 创建专用的只读审核员身份。
● 仅授予对所需日志和资源元数据的访问权限。
设计理由
● 技术可行性：CloudTrail 记录账户活动，而 IAM 控制证据访问。
● 需求匹配：审核员可以在不改变生产资源的情况下检查事件。
● 场景匹配：该请求是外部合规审查。
● 工程常识：通知不是证据；保留完整的日志和受控的搜索访问。
应排除的备选方案
● 没有 CloudTrail 的只读角色会忽略所需的活动历史记录。
● SNS 发送通知不是审核记录。
● 拒绝审核员日志访问会阻止证据审查。
● AWS 不会独立为第三方创建客户账户权限。
工作流：API 操作 → CloudTrail 事件 → 受保护的 S3 日志 → 审核员身份验证 → 只读审查。
将网关块存储恢复到 EBS
Storage Gateway 卷快照可以成为 EC2 恢复环境的本机 AWS 块存储。
推荐流程
● 选择存储网关快照。
● 将其恢复为 Amazon EBS 卷。
● 在所需的可用区中创建卷。
● 将其连接到 EC2 应用程序服务器。
● 挂载并验证文件系统。
设计理由
● 技术可行性：网关快照与 EBS 快照和卷工作流程集成。
● 需求匹配：应用程序接收可连接的块存储，而不依赖于本地网关。
● 场景匹配：原始工作负载需要 iSCSI 样式的块卷。
● 工程常识：在考虑以后的现代化之前，在灾难恢复期间保留存储接口。
应排除的备选方案
● 直接连接到本地网关可保留混合依赖性。
● S3是对象存储，不能直接替换已挂载的块设备。
● Storage Gateway 不会将卷直接转换为 EFS。
● 手动复制文件会增加恢复时间并可能会丢失元数据。
工作流：网关快照 → EBS 卷 → EC2 附件 → 文件系统检查 → 应用程序启动。
使用 CloudFormation 滚动 AMI 更新
Auto Scaling 组可以逐渐替换实例，同时保持最低的健康服务容量。
推荐配置
● 将启动模板或启动配置更新为新的 AMI。
● 在 CloudFormation 更新策略中定义 AutoScalingRollingUpdate。
● 配置批量大小、暂停时间和服务中的最小实例数。
● 在继续每批之前监视健康状况。
设计理由
● 技术可行性：CloudFormation 协调 Auto Scaling 组中的受控实例替换。
● 需求匹配：队列接收新的 AMI，而无需同时更换每个实例。
● 场景匹配：该应用程序已使用 Auto Scaling，并且需要较短的停机时间。
● 工程常识：运行状况检查必须验证应用程序准备情况，而不仅仅是实例启动。
应排除的备选方案
● 更改集预览更改，但不控制队列替换。
● 完整的蓝/绿堆栈可以工作，但会增加重复的基础设施和 DNS 交换。
● DeletionPolicy 不定义滚动替换行为。
● 就地 AMI 更改无法修改已运行的实例。
工作流：更新模板→替换一批→等待运行状况→继续批次→完成或回滚。
适用于 Windows 和 Linux 的统一系统遥测
操作系统内存、磁盘和日志数据需要客户机内收集器，因为标准 EC2 指标不会公开每个请求的测量。
推荐架构
● 跨 Windows 和 Linux 实例安装和配置统一的 Amazon CloudWatch 代理。
● 将系统日志发送到 CloudWatch Logs。
● 发布来宾指标，例如内存和磁盘利用率。
● 使用 CloudWatch Logs Insights 分析聚合记录。
● 将所需结果导出到 Amazon S3。
设计理由
● 技术可行性：一个受支持的代理可以处理两个操作系统并集中遥测。
● 需求匹配：该解决方案涵盖 200 多个实例，只需最少的定制开发。
● 场景匹配：每月性能分析需要整个机队范围内的可搜索数据，而不是单个主机检查。
● 工程常识：集中标准化采集配置和查询。
应排除的备选方案
● SSM 代理管理实例，但不是完整日志和指标集的主要收集器。
● 流量镜像捕获网络数据包，而不是内存或磁盘使用情况。
● 自定义守护进程和 CDK 部署增加了不必要的维护。
● Amazon Inspector 评估漏洞，而仪表板不会取代日志查询。
工作流：定义代理配置 → 部署 → 验证摄取 → 使用 Logs Insights 查询 → 保留或导出结果。
使用 NACL 阻止恶意源网络
网络 ACL 可以显式拒绝来自子网边界的已知攻击 CIDR 范围的流量。
推荐控制
● 为恶意源 CIDR 添加编号拒绝规则。
● 将规则放置在更广泛的允许条目之前。
● 将其应用到受影响的公共子网。
● 保留所需的返回路径规则，因为 NACL 是无状态的。
设计理由
● 技术可行性：NACL 支持显式允许和拒绝规则。
● 需求匹配：来自已识别来源的流量在到达实例之前会被阻止。
● 场景匹配：该门户必须对其他用户保持公开。
● 工程常识：将此视为立即遏制，而不是完整的 DDoS 保护。
应排除的备选方案
● 将整个门户移动到私有子网会消除公共可用性，而无需其他入口设计。
● 路由表不按源 IP 进行过滤。
● 安全组仅允许，无法创建显式拒绝。
● 主机防火墙需要按实例进行管理。
工作流：数据包进入子网 → NACL 评估最低匹配规则 → 敌对 CIDR 被拒绝 → 其他用户继续。
对私有 S3 内容的限时访问
私人内容可以通过签名暂时共享，而直接的匿名来源访问仍然被阻止。
推荐模式
● 使用 S3 预签名 URL 直接、限时访问特定对象。
● 或者使用 CloudFront 签名 URL 来获取边缘交付的私有内容。
● 对于 CloudFront，使用源访问身份和限制性存储桶策略保护 S3 源。
● 删除公共 S3 权限。
设计理由
● 技术可行性：签名对过期和授权资源进行编码； S3 或 CloudFront 在交付前对其进行验证。
● 需求匹配：只有获得批准的客户端才能获得临时访问权限，而无需永久 AWS 凭证。
● 场景匹配：内容存储在 S3 中，并可以通过 CloudFront 分发。
● 工程常识：在用户实际访问的交付层选择签名者。
应排除的备选方案
● 公共读取 ACL 无法限制对一个客户端的访问。
● 共享 IAM 访问密钥会产生长期的凭证风险。
● OAI 本身保护来源，但不授权个人查看者。
● 网络 ACL 不提供对象级时间限制。
工作流：应用程序授权客户端 → 生成 S3 或 CloudFront 签名 → 到期前的客户端请求 → 服务验证 → 交付对象。
使用 DynamoDB TTL 保留大量数据
具有固定 120 天保留期的高摄取工作负载需要可扩展写入、低延迟读取和自动项目过期。
推荐架构
● 使用均匀分布的分区键将记录存储在 Amazon DynamoDB 中。
● 为每个项目添加过期时间戳属性。
● 在该属性上启用 DynamoDB 生存时间。
● 根据流量可预测性选择按需或预置容量。
设计理由
● 技术可行性：DynamoDB 水平扩展，TTL 会自动删除过期项目，无需应用程序删除作业。
● 需求匹配：该设计支持持久摄取、响应式访问和低操作保留管理。
● 场景匹配：记录具有统一的生命周期，不需要关系连接。
● 工程常识：在项目创建时对生命周期进行编码，而不是稍后扫描表中的旧数据。
应排除的备选方案
● 关系数据库为简单的大容量键值流添加连接和扩展约束。
● 计划删除作业会消耗容量并需要检查点、重试和维护。
● 无限期保留过期数据会增加存储成本并违反保留意图。
● 当活动需求包括低延迟记录访问时，归档对象存储不太合适。
工作流：摄取项目 → 分配分区键和到期时间 → 提供低延迟查询 → TTL 在 120 天后删除数据。
现货船队成本最低的峰值容量
可预测的基线容量仍然可以通过预留来满足，同时多样化的 Spot 可以处理临时的容错峰值。
推荐架构
● 保持预留定价以满足稳定的应用需求。
● 跨可用区启动多元化的 Spot 队列，以应对高峰流量。
● 使用 Auto Scaling 和中断感知替换。
设计理由
● 技术可行性：多个 Spot 池可减少对单一容量源的依赖。
● 需求匹配：该设计提供最低成本的峰值容量。
● 场景匹配：工作负载可以替代中断的峰值实例。
● 工程常识：切勿将预留实例视为可启动的临时容量。
应排除的备选方案
● 预留实例是计费承诺，而不是 Auto Scaling 队列类型。
● Spot 加 On-Demand 提高了可靠性，但成本高于最低成本要求。
● 预留加按需可保留更高的峰值成本。
● One Spot 池会增加中断和容量风险。
工作流：基线运行→峰值报警→多元化Spot上线→流量分配→中断容量替换→机队规模缩减。
使用 AWS MGN 进行连续虚拟机复制
以最短的停机时间进行服务器迁移需要连续的块级复制，而不是重复的完整映像导入。
推荐架构
● 在每台源服务器上安装 AWS Application Migration Service 复制代理。
● 持续复制根数据卷和附加数据卷。
● 从复制状态启动测试实例。
● 验证后执行最终切换。
设计理由
● 技术可行性：AWS MGN 复制完整的服务器磁盘并启动等效的 EC2 实例。
● 需求匹配：持续同步可保持切换状态最新并减少停机时间。
● 场景匹配：TB 级根卷和数据卷属于一个协调的迁移工作流程。
● 工程常识：测试将用于生产切换的相同复制流。
应排除的备选方案
● VM Import/Export 对于映像导入很有用，但重复的完整导入对于持续同步来说效率低下。
● 发现服务和迁移中心支持规划和跟踪，而不是块复制。
● 当 MGN 可以复制数据卷快照时，单独导入数据卷快照会增加协调、附件和一致性风险。
工作流：安装代理→复制→测试启动→修复→最终同步→切换→验证应用程序和数据。
在 ALB 上启用可用区
应用程序负载均衡器仅将流量路由到为该负载均衡器启用的可用区中的目标。
推荐流程
● 查看哪些子网和可用区与 ALB 关联。
● 从缺少的可用区添加合适的子网。
● 验证目标实例是否已注册且运行状况良好。
● 确认路由表、安全组和网络 ACL 允许运行状况检查和应用程序路径。
设计理由
● 技术可行性：关联 AZ 为 ALB 提供了该区域的节点和网络路径。
● 需求匹配：所有预期可用区中运行状况良好的 Auto Scaling 实例都可以接收流量。
● 场景匹配：实例启动成功，但有一个可用区未收到负载均衡请求。
● 工程常识：Auto Scaling 放置和负载均衡器区域启用是单独的配置。
应排除的备选方案
● 当 ALB 无法路由到可用区时，手动添加更多实例没有帮助。
● Auto Scaling 不会自动关联新的 ALB 子网。
● 跨区域负载均衡不会使禁用的可用区可供负载均衡器使用。
● 该问题无法通过更改 AWS 区域来解决。
工作流：ASG启动目标→目标寄存器→ALB检查启用AZ→健康检查成功→流量开始。
成本优化的内部容器和文档平台
低成本的内部平台应该使用可中断的计算，并使用安全、承诺的数据库定价来满足稳定的需求，以及生命周期管理的对象存储。
推荐架构
● 在 EC2 Spot 容量上运行 ECS 容器实例。
● 启用 ECS Spot 实例耗尽。
● 对稳定的 Amazon RDS 数据库层使用预留定价。
● 将文档存储在加密的 Amazon S3 中。
● 三个月后将文档转移到 S3 Glacier，并仅在所需的五年保留期后过期。
设计理由
● 技术可行性：ECS 在 Spot 中断之前耗尽任务，而 S3 生命周期策略则自动执行存储转换。
● 需求匹配：该设计最大限度地降低了计算和存储成本，同时将文档保存五年。
● 场景匹配：文件仅在前三个月内被频繁访问。
● 工程常识：将存储类别与访问期限保持一致，并避免自定义归档 cron 作业。
应排除的备选方案
● 对于可预测的长期运行使用，按需 ECS 和 RDS 成本更高。
● EFS 加上自定义复制脚本添加了文件系统和归档操作。
● EKS 在没有明确需求的情况下添加了 Kubernetes 管理。
● RDS 无法在 Spot 实例上运行。
● 主机本地容器卷不是持久的文档存储。
工作流：将活动文档存储在 S3 中→作为授权→生命周期到 Glacier→保留五年→按策略过期。
使用 STS 进行范围内的移动 S3 访问
移动应用程序应在对用户进行身份验证后接收临时凭据。
推荐架构
● 在应用程序身份系统中对用户进行身份验证。
● 将身份映射到 IAM 角色。
● 使用 STS 颁发临时的、有范围的凭证。
● 限制对用户授权的 S3 对象的访问。
设计理由
● 技术可行性：移动 SDK 可以使用可更新的 STS 会话签署 S3 请求。
● 需求匹配：用户无需永久嵌入 AWS 密钥即可访问其数据。
● 场景匹配：直接移动对象访问需要每个用户的隔离。
● 工程常识：将分布式客户端视为不受信任的秘密存储环境。
应排除的备选方案
● 长期 IAM 用户密钥可以提取并重复使用。
● STS 凭证是临时的，不得将其视为永久嵌入的机密。
● 在 DynamoDB 中存储用户信息本身并不会将身份映射到安全的 AWS 角色。
● 一份共享凭证无法隔离用户。
工作流：用户登录 → 角色映射 → STS 会话 → 范围 S3 请求 → 凭证刷新或过期。
基于队列的媒体处理
可变的、长时间运行的媒体作业需要持久的缓冲和可扩展的工作人员，而不是同步处理。
推荐架构
● 在 Amazon SQS 中放置作业。
● 根据队列深度扩展 EC2 工作线程。
● 将源媒体和处理后的媒体存储在 Amazon S3 中。
● 将可见性超时设置为超出预期处理时间。
● 使用重试和死信队列。
设计理由
● 技术可行性：SQS 将上传与处理分离，Auto Scaling 跟踪积压，S3 提供持久的共享存储。
● 需求匹配：该平台以低成本处理可变工作，而不会导致失业。
● 场景匹配：媒体处理可能会超出较短的无服务器执行窗口。
● 工程常识：工人是一次性的；消息和媒体必须能够承受工人的失败。
应排除的备选方案
● Lambda 可能不适合长时间运行的作业。
● EBS 不是用于扩展队列的共享持久输出存储。
● Amazon MQ 添加了此处不需要的代理兼容性和管理。
● 将 MQ 与 SQS 触发的设计混合使用在内部是不一致的。
工作流：上传→SQS消息→工人索赔→从S3处理→写入结果→删除消息。
CloudFront WordPress 的可信 HTTPS
自定义 WordPress 域应将查看者重定向到 HTTPS，并为两个交付层使用受信任的 ACM 证书。
推荐架构
● 在 CloudFront 中配置 HTTP 到 HTTPS 重定向。
● 使用所需区域中 CloudFront 自定义域的 ACM 证书。
● 在其区域中的源终端节点上使用受信任的 ACM 证书。
● 强制执行从 CloudFront 到源的 HTTPS。
设计理由
● 技术可行性：ACM 与 CloudFront 和 AWS 负载均衡源集成。
● 需求匹配：查看者和源流量通过托管续订接收可信加密。
● 场景匹配：该网站使用自定义 WordPress 域。
● 工程常识：证书名称必须与查看器和源主机名匹配。
应排除的备选方案
● 自签名证书不受公共浏览器或 CloudFront 源的信任。
● 第三方证书可以使用，但增加了购买和续订操作。
● 默认 CloudFront 证书仅涵盖 cloudfront.net，而不涵盖自定义域。
工作流：HTTP 查看器 → 重定向 → CloudFront TLS → HTTPS 源请求 → WordPress 响应。
React 应用程序的无服务器交付
静态单页应用程序不需要始终在线的 Web 服务器群。
推荐架构
● 在 Amazon S3 网站存储桶中托管 React 构建。
● 通过受支持的 Web 身份提供商对用户进行身份验证。
● 使用 STS 将身份令牌交换为临时 AWS 凭证。
● 授予对所需 S3 对象和 DynamoDB 项目的小范围访问权限。
设计理由
● 技术可行性：浏览器可以从 S3 加载静态 React 资产，并使用临时凭证进行授权的 AWS API 调用。
● 需求匹配：该设计无需服务器即可扩展，并将固定成本降至最低。
● 场景匹配：使用量没有出现大幅增长，标题很小，并且 DynamoDB 已经与数据模式匹配。
● 工程常识：使用临时凭证而不是嵌入式密钥或自定义令牌服务。
应排除的备选方案
● NGINX、EC2、负载均衡器和 Auto Scaling 会增加静态内容的成本。
● 单个令牌自动售货机成为瓶颈和故障点。
● 自定义令牌服务加上 EC2 Web 队列可复制托管功能。
工作流：登录 → 接收身份令牌 → 承担网络身份角色 → 接收临时凭证 → 访问批准的资源。
使用 Redis 减少混合数据库负载
动态门户可以通过缓存会话和频繁重复的查询结果来减少本地数据库压力。
推荐架构
● 部署适用于 Redis 的 Amazon ElastiCache。
● 缓存会话状态和合适的查询结果。
● 配置复制以实现缓存可用性和读取扩展。
● 根据可接受的陈旧程度设置过期时间。
设计理由
● 技术可行性：Redis 提供低延迟内存读取和适合会话的数据结构。
● 需求匹配：通过混合链路或到达数据库的请求更少。
● 场景匹配：门户和评论是动态的，因此完全静态托管是不可行的。
● 工程常识：仅缓存应用程序在驱逐后可以安全重建的数据。
应排除的备选方案
● S3静态托管无法替代动态门户和评论处理。
● 迁移到 Aurora 可能可行，但这是一个比缓存更大的数据库项目。
● 对于兼容的数据库移动来说，SCT 是不必要的。
● OpenSearch 是一个搜索引擎，而不是评论和会话的事务存储。
工作流：应用程序读取缓存→命中立即返回→错过查询数据库→使用TTL缓存的结果。
使用 EC2 角色轮换 S3 凭证
EC2 应用程序应从附加的 IAM 角色获取短期 S3 凭证。
推荐架构
● 创建受 EC2 信任的 IAM 角色。
● 仅授予所需的存储桶列表和对象上传操作。
● 通过实例配置文件附加角色。
● 让 AWS 开发工具包从实例元数据服务检索凭证。
设计理由
● 技术可行性：该平台自动提供和轮换临时凭证。
● 需求匹配：该应用程序列出并上传对象而不存储机密。
● 场景匹配：工作负载在 EC2 上运行并调用 S3 API。
● 工程常识：授予所需的确切存储桶级别和对象级别操作。
应排除的备选方案
● EC2 上的静态访问密钥会造成长期暴露。
● 仅列表权限无法上传对象。
● 用户数据不是安全的轮换凭证提供者。
● IAM 用户无法附加到 EC2 实例，并且元数据不会公开用户凭证。
工作流：实例以角色启动 → SDK 获取临时会话 → 签署 S3 请求 → 凭证在过期前轮换。
为什么 SCP 不限制服务相关角色
服务控制策略限制成员账户中委托人可用的权限，但 AWS 服务相关角色不受 SCP 限制。
关键行为
● 服务相关角色由 AWS 服务预定义。
● 其信任关系允许该服务执行所需的操作。
● SCP 否认不限制通过服务相关角色执行的操作。
设计理由
● 技术可行性：即使账户委托人面临 SCP 拒绝，ECS 也可以通过其服务相关角色继续服务管理的操作。
● 需求匹配：此行为解释了为什么预期的限制不会影响观察到的操作。
● 场景匹配：ECS 集群使用为 AWS 服务集成创建的服务相关角色。
● 工程常识：在诊断策略评估之前，首先确定哪个委托人提出了请求。
应排除的错误解释
● 资源不在组织的管辖范围之外运作。
● 父允许不能覆盖适用 SCP 路径中其他位置的显式拒绝。
● 默认 FullAWSAccess SCP 不会取消显式拒绝。
● 编辑默认 SCP 不是服务相关角色行为的原因。
排查工作流：查看 CloudTrail 主体 → 识别服务相关角色 → 映射适用的 SCP → 将服务操作与用户或角色操作分开。
资源终止的业务单元控制
多帐户结构应该使每个业务部门对自己的资源负责，而不向其他部门授予破坏性访问权限。
推荐架构
● 使用 AWS Organizations 将账户组织到业务部门 OU 中。
● 为批准的单位管理员创建跨账户 IAM 角色。
● 仅授予该单位拥有的资源和帐户的资源级终止权限。
● 使用信任策略来限制谁可以担任每个角色。
设计理由
● 技术可行性：IAM 角色和资源权限授权目标账户内的操作。
● 需求匹配：每个单位管理自己的资源，而帐户边界限制爆炸半径。
● 场景匹配：所有权自然与单独的帐户或 OU 保持一致。
● 工程常识：使用 SCP 作为实际操作访问的最大护栏和 IAM 角色。
应排除的备选方案
● SCP 不授予资源访问权限，也不能替换目标账户 IAM 权限。
● 广泛的组织范围管理员角色违反了业务部门隔离。
● 服务相关角色允许 AWS 服务运行；他们不是人类的管理角色。
● 资源标签本身并不授权终止，除非 IAM 条件明确使用它们。
工作流：管理员登录 → 承担单位角色 → IAM 评估资源范围 → 发生允许的终止 → CloudTrail 记录操作。
仅允许通过 CloudFront 访问 S3
私有 S3 源应信任 CloudFront，而不是匿名查看者或发行版的公共 DNS 名称。
推荐架构
● 创建 CloudFront 源访问身份。
● 配置分配以使用 OAI 作为 S3 源。
● 更新 S3 存储桶策略以仅向 OAI 授予对象读取权限。
● 删除公共读取 ACL 和公共存储桶权限。
设计理由
● 技术可行性：CloudFront 使用 OAI 身份对源请求进行签名，S3 在存储桶策略中评估该身份。
● 需求匹配：用户通过 CloudFront 接收内容，但直接 S3 URL 失败。
● 场景匹配：该存储桶是一个源，而不是公共网站端点。
● 工程常识：授权发出源请求的服务身份。
应排除的备选方案
● CloudFront 分配 ID 不是用于 OAI 授权的 S3 委托人。
● 为 CloudFront 创建一般 IAM 用户会引入不必要的手动凭据。
● 查看者签名的 URL 控制对 CloudFront 的访问，但不会自动限制直接 S3 访问。
● 公共存储桶访问破坏了源保护。
工作流：查看器 → CloudFront 授权 → OAI 签名的源请求 → S3 存储桶策略 → 对象响应。
保护电子商务信任链
安全的公共访问需要保护 DNS 解析和 HTTPS 路径。
推荐架构
● 使用 Route 53 托管并注册域。
● 为公共托管区域启用 DNSSEC 签名并发布所需的委派记录。
● 从 AWS Certificate Manager 请求受信任的公共证书。
● 在应用程序负载均衡器处终止 HTTPS。
● 使用 SNI 配置 CloudFront 并将 HTTP 查看器重定向到 HTTPS。
设计理由
● 技术可行性：DNSSEC 验证签名的 DNS 响应； ACM和ALB建立可信TLS； CloudFront 强制执行安全的查看器连接。
● 需求匹配：该设计减少了 DNS 欺骗、HTTPS 欺骗和降级暴露。
● 场景匹配：它使用现有的 Fargate、ALB、CloudFront 和 Route 53 架构。
● 工程常识：使用本机托管控件而不是操作自定义 DNS 服务器或证书进程。
应排除的备选方案
● 自托管 BIND 增加了修补、可用性和密钥管理工作。
● 外部 DNSSEC 可以工作，但无需引入其他提供商。
● 导入的证书可以工作，但当 ACM 可以颁发和续订它们时，会添加续订和部署操作。
工作流：签署 DNS → 验证委派 → 颁发证书 → 配置 ALB HTTPS → 强制执行 CloudFront HTTPS。
用于混合劳动力访问的 SAML 联合
员工可以通过基于标准的 SAML 联合使用企业身份访问 AWS。
推荐架构
● 为 SAML 2.0 配置企业身份提供商。
● 在 AWS 中创建相应的 SAML 提供商和 IAM 角色。
● 将用户或组映射到批准的角色。
● 通过 AWS 联合和 STS 终端节点交换临时会话的 SAML 断言。
设计理由
● 技术可行性：AWS 在颁发临时凭证之前会验证已签名的断言和角色映射。
● 需求匹配：用户保留公司身份验证并避免单独的长期 IAM 密码。
● 场景匹配：该公司运营着具有现有企业身份源的混合环境。
● 工程常识：在 IdP 处集中进行身份验证，并将 AWS 授权保留在 IAM 角色中。
应排除的备选方案
● 创建 IAM 用户会重复密码生命周期和注销。
● Web 身份联合针对的是消费者 OIDC 提供商，而不是此劳动力 SAML 场景。
● 如果没有代理或联合层，STS 无法单独接受 LDAP。
● VPN 等网络连接不提供身份联合。
工作流：用户向 IdP 进行身份验证 → 接收 SAML 断言 → 选择映射角色 → AWS 验证断言 → 临时控制台或 API 会话。
将 Kafka 事件移至 AWS
混合 Kafka 管道需要可靠的网络连接和对 AWS 流服务的受控摄取。
推荐架构
● 建立 AWS Direct Connect 以实现可预测的混合传输。
● 运行读取本地 Kafka 主题的 EC2 使用者。
● 将使用的记录发布到 Amazon Kinesis 以供 AWS 处理。
● 仅将 API Gateway WebSocket API 与 Lambda 结合用于需要它们的面向客户端的实时交互。
设计理由
● 技术可行性：Kafka 消费者保留源协议，Direct Connect 提供容量，Kinesis 支持可扩展的 AWS 消费者。
● 需求匹配：当事件可供 AWS 工作负载使用时，现有 Kafka 仍然可用。
● 场景匹配：该设计连接了本地流媒体和基于云的实时应用程序。
● 工程常识：将后端流摄取与浏览器或移动 WebSocket 传输分开。
应排除的备选方案
● API Gateway 并不是 Kafka 代理的直接替代品。
● 如果没有支持的连接和事件源设计，Lambda 无法连续轮询任意 Kafka 端点。
● S3 批量传输失去实时行为。
● 仅 VPN 可能无法满足所需的持续带宽和可预测性。
工作流：Kafka 主题 → 通过 Direct Connect 的 EC2 消费者 → Kinesis 流 → 处理器 → 可选的 Lambda 和 WebSocket 更新。
具有实例配置文件的 CloudFormation EC2 角色
CloudFormation 通过实例配置文件将 IAM 角色附加到 EC2。
推荐架构
● 定义 EC2 信任的 IAM 角色。
● 将 DynamoDB 权限附加到角色。
● 创建包含角色的 AWS::IAM::InstanceProfile。
● 引用 EC2 启动配置中的实例配置文件。
设计理由
● 技术可行性：EC2 通过附加的实例配置文件接收临时角色凭证。
● 需求匹配：应用程序无需长期密钥即可访问 DynamoDB。
● 场景匹配：基础设施通过 CloudFormation 进行部署。
● 工程常识：切勿将秘密访问密钥作为堆栈参数或用户数据传递。
应排除的备选方案
● 用户访问密钥可能会通过部署工作流程泄漏。
● CloudFormation 不应创建 IAM 用户密钥并将其分发给实例。
● AWS::IAM::InstanceRoleName 不是所描述的有效 EC2 附加机制。
● 没有实例配置文件的角色不会附加到 EC2。
工作流：堆栈创建角色 → 实例配置文件包含角色 → EC2 启动 → SDK 检索临时凭证。
跨 AWS 账户的中央私有 DNS
共享服务账户可以拥有私有 DNS，而其他账户中的应用程序 VPC 则解析相同的内部名称。
推荐架构
● 在共享服务帐户中创建私有托管区域。
● 为已批准的应用程序 VPC 授权跨账户关联。
● 将每个 VPC 与中央私有托管区域关联。
● 集中维护记录并启用 VPC DNS 支持。
设计理由
● 技术可行性：Route 53 私有托管区域支持与其他 AWS 账户拥有的 VPC 关联。
● 需求匹配：DNS 管理保持集中化，无需复制区域或运行自定义解析器。
● 场景匹配：多个帐户需要一致的内部服务发现。
● 工程常识：对通用名称使用一种事实来源，并仅委托关联权。
应排除的备选方案
● 在每个帐户中重新创建相同的私人区域可能会导致记录不一致。
● 仅 VPC 对等互连不共享托管区域关联。
● 公共托管区域公开内部命名，并且不提供仅限私有的解析。
● 自我管理的 DNS 服务器添加了修补、可用性、转发和扩展工作。
工作流：创建中心区→授权VPC→工作负载账户关联→发布记录→测试解析→审计关联。
减少 RDS 故障转移时间
快速数据库恢复需要有弹性的数据库目标和应用程序连接管理。
推荐架构
● 使用 RDS Proxy 池连接并将应用程序路由到健康目标。
● 当需要更快的副本故障转移时，迁移到 Aurora MySQL。
● 跨可用区部署 Aurora 副本。
● 测试客户端重试行为。
设计理由
● 技术可行性：RDS Proxy 减少了连接流失，而 Aurora 副本提供了升级目标。
● 需求匹配：应用程序在写入器发生故障后恢复得更快。
● 场景匹配：目标故障转移低于标准 DNS 和重新连接行为。
● 工程常识：数据库升级和客户端重新连接都会导致中断时间。
应排除的备选方案
● 优化写入、优化读取和缓存可提高性能，而不是故障转移。
● 标准只读副本不提供自动写入器故障转移。
● Redis 在发生故障后不会创建可写的关系数据库。
● 较大的实例不会缩短故障转移时间。
工作流：编写器失败 → Aurora 提升副本 → 代理路由池连接 → 应用程序重试 → 服务恢复。
CodeCommit 中的即时凭证扫描
推送代码时应检测暴露的 IAM 访问密钥，然后立即包含。
推荐架构
● 配置 CodeCommit 推送事件以调用 AWS Lambda。
● 扫描新提交以获取 IAM 访问密钥模式。
● 找到凭据后通知开发人员和安全团队。
● 禁用公开的 IAM 密钥并需要受控替换。
设计理由
● 技术可行性：CodeCommit 事件提供及时的调用，Lambda 可以检查提交的内容并调用 IAM API。
● 需求匹配：事件驱动扫描的响应速度比日常检查更快，并限制了曝光窗口。
● 场景匹配：安全问题源于源代码提交。
● 工程常识：在生成或分发替换凭据之前包含泄露的凭据。
应排除的备选方案
● Amazon Macie 发现 S3 中的敏感数据，而不是 CodeCommit 存储库中的敏感数据。
● 每日 EC2 和 Systems Manager 扫描会延迟且操作量更大。
● 旋转密钥而不立即禁用暴露的密钥会带来主动风险。
● KMS存储加密密钥；它不是用于替换 IAM 凭证的存储库。
工作流：开发者推送→事件→Lambda扫描→查找→禁用密钥→通知所有者→从历史记录中删除秘密→安全地发布替换。
经济高效的区域灾难恢复工件
恢复可以通过持续复制数据库并将重建工件复制到备份区域来避免热备成本。
推荐架构
● 维护跨区域 Aurora 副本。
● 将 Web 和应用程序 AMI 或快照复制到恢复区域。
● 存储重建无状态层所需的模板和配置。
● 在灾难期间提升副本并启动计算。
设计理由
● 技术可行性：Aurora 复制可保持数据最新，而区域映像可实现快速服务器重建。
● 需求匹配：该设计降低了稳定的计算成本，同时保留了实际恢复能力。
● 场景匹配：无状态层可以重建；数据库需要持续复制。
● 工程常识：恢复工件必须已存在于目标区域中。
应排除的备选方案
● AWS Backup 并不只是将 RDS 和 EBS 备份放入客户 S3 存储桶中，如所述。
● 恒定的五分钟 Aurora 快照不是本机区域复制方法。
● 仅快照恢复会增加 RTO。
● 热备速度更快，但成本高于要求。
工作流：复制 Aurora → 复制镜像 → 宣布灾难 → 升级副本 → 启动层 → 验证 → 切换流量。
最小权限跨账户 S3 和 KMS
跨账户访问KMS加密对象需要密钥、角色和存储桶的授权。
推荐控制
● 将特定管理帐户审阅者角色添加到 KMS 密钥策略以进行解密。
● 授予审阅者角色身份权限以进行 S3 读取和 KMS 解密。
● 在 S3 存储桶策略中允许审阅者角色或管理帐户。
设计理由
● 技术可行性：S3 和 KMS 评估单独的权限链。
● 需求匹配：只有指定的审阅者才能读取和解密对象。
● 场景匹配：对象由一个帐户拥有并由另一个帐户查看。
● 工程常识：在每项政策中使用最窄的原则。
应排除的备选方案
● 信任营销帐户会导致错误的一方。
● 授予整个管理帐户解密权限比所需的范围更广泛。
● 完整的 S3 权限超出了只读需求。
● IAM 解密权限无法覆盖不信任该角色的 KMS 密钥策略。
工作流：审核者承担角色 → S3 存储桶授权读取 → KMS 密钥授权解密 → 返回对象。
将证书控制与应用程序操作分离
应用程序团队可以管理 EC2 工作负载，而网络安全保留对生产 TLS 证书的独家控制。
推荐架构
● 在 AWS Certificate Manager 中存储和管理证书。
● 通过 IAM 策略将 ACM 证书操作限制为网络安全团队。
● 终止弹性负载均衡器上的 SSL 或 TLS。
● 将证书材料保留在应用程序 EC2 实例之外。
● 让 DevOps 仅管理其所需的应用程序和计算权限。
设计理由
● 技术可行性：负载均衡器与 ACM 集成，无需将私钥分发给服务器。
● 需求匹配：当门户提供 HTTPS 时，职责保持分离。
● 场景匹配：DevOps 拥有计算操作，网络安全拥有 X.509 证书生命周期。
● 工程常识：在服务和权限边界强制分离，而不是通过非正式程序。
应排除的备选方案
● 在 S3 中存储证书会创建检索和密钥公开路径。
● 在 EC2 上安装证书使应用程序管理员可以访问私有材料。
● SCP 是广泛的组织护栏，并不是细粒度团队证书访问的常规工具。
● AWS Config 可以检测更改，但不会授予或拒绝证书使用。
工作流：网络安全管理 ACM 证书 → 负载均衡器终止 TLS → DevOps 管理无需证书访问的后端目标。
使用 AWS RAM 在组织范围内共享
AWS Resource Access Manager 通过可信访问与 AWS Organizations 集成，避免自定义跨账户自动化。
推荐架构
● 使用 enable-sharing-with-aws-organization 启用与 AWS Organizations 的资源共享。
● 允许 AWS RAM 创建和使用其服务相关角色。
● 为组织帐户或 OU 复制已建立的资源共享配置。
设计理由
● 技术可行性：可信访问允许 RAM 使用 AWS 托管的集成跨组织帐户进行操作。
● 需求匹配：与逐个帐户的角色编排相比，本机机制的持续管理量较低。
● 场景匹配：任务是组织资源共享，而不是操作系统自动化。
● 工程常识：当托管服务集成已经实现了所需的信任关系时，首选托管服务集成。
应排除的备选方案
● 服务相关角色信任策略是服务控制的，不是正常的自定义点。
● 通用跨账户访问不会激活 RAM 和组织集成。
● SSM 代理、工作虚拟机和自动化文档不参与 RAM 共享。
工作流：启用可信访问→验证服务相关角色→定义资源共享→选择主体→验证访问→审核更改。
网络控制和配置历史记录
连接实施和资源更改历史记录是不同的控制，应使用不同的 AWS 服务。
推荐架构
● 将安全组用于有状态实例级允许规则。
● 将网络 ACL 用于无状态子网级允许和拒绝规则。
● 启用 AWS Config 记录资源配置和历史更改。
● 需要合规性评估时，添加配置规则。
设计理由
● 技术可行性：安全组和 NACL 评估流量，而 Config 记录支持的资源如何随时间变化。
● 需求匹配：该设计提供受控的 EC2 通信和可审计的安全配置历史记录。
● 场景匹配：调查需要当前的连接策略和以前的配置状态。
● 工程常识：流量过滤器不会自动提供历史治理证据。
应排除的备选方案
● CloudTrail 记录 API 调用，但不是 Config 提供的完整规范化配置时间线。
● VPC 流日志显示接受和拒绝的流量，而不是完整的规则历史记录。
● Systems Manager 管理实例，但不会取代 VPC 网络控制。
● 路由表选择路径，不提供端口级策略。
工作流：数据包→路由→NACL→安全组→实例；配置更改 → AWS Config 历史记录和合规性。
控制预留实例折扣共享
预留实例共享是一项由 AWS Organizations 管理账户控制的账单分配功能。
推荐流程
● 将业务部门保留在组织内部。
● 通过合并账单首选项禁用相关成员帐户或帐户范围的 RI 折扣共享。
● 在计划的工作负载开始之前验证如何应用折扣。
设计理由
● 技术可行性：管理账户控制是否在关联账户之间共享符合条件的 RI 折扣。
● 需求匹配：采购业务部门保留预期的计费优势。
● 场景匹配：无需更改工作负载、IAM 或账户所有权。
● 工程常识：通过计费设置而不是重组治理来解决狭隘的成本分配问题。
应排除的备选方案
● RI 折扣并非不可避免地共享；偏好可以改变。
● 会员帐户没有特殊的“私人 RI”设置。
● 从组织中删除该帐户会扰乱整合的计费、策略和集中管理。
运维说明：预留实例影响计费效益，而不是实例放置或技术能力。容量规划和扩展仍然必须分开设计。
工作流：审查所有权 → 更改共享偏好 → 建立有效覆盖范围模型 → 监控计费分配。
缓冲在线考试提交
同时提交高峰需要持久排队，而静态考试资产则单独处理。
推荐架构
● 将考试提交放入 SQS。
● 用受控的消费者来处理它们。
● 将图像和图表存储在 S3 中。
● 通过 CloudFront 交付静态资产。
设计理由
● 技术可行性：SQS 吸收突发写入，而 S3 和 CloudFront 则扩展只读考试内容。
● 需求匹配：保留提交数据，无需过度配置固定写入目标。
● 场景匹配：数千名候选人同时提交。
● 工程常识：静态内容交付和写入处理需要不同的扩展机制。
应排除的备选方案
● 固定的 10,000 WCU 可能过高或过低。
● CloudFront Functions 不托管图像。
● 100% 的利用率目标没有留下任何空间。
● 较低的最大容量仍然会抑制突发。
● 迁移到 RDS 是一次重大的重新设计，只读副本无助于写入。
工作流：候选人从 CloudFront 加载资产 → 提交到队列 → 消费者安全地保留结果。
发现 PII 并检查 S3 访问
敏感数据发现和对象访问调查需要不同的服务。
推荐架构
● 使用 Amazon Macie 发现 S3 中的 PII 并对其进行分类。
● 为相关存储桶启用 CloudTrail 数据事件。
● 查看最近的 GetObject 活动以及执行该活动的身份。
设计理由
● 技术可行性：Macie 分析对象内容和元数据； CloudTrail 数据事件记录对象级 API 活动。
● 需求匹配：团队了解敏感数据存在的位置以及访问者。
● 场景匹配：受保护的信息存储在S3中。
● 工程常识：分类并不能证明访问，访问日志也不会自动识别 PII。
应排除的备选方案
● GuardDuty 检测威胁，但不会对 S3 对象内的 PII 进行分类。
● Inspector 会扫描计算工作负载，但无法在存储桶上安装代理。
● Athena 查询已知数据，但不会自动发现所有 PII。
● CloudWatch 不会独立记录 S3 对象 GET 调用。
工作流：Macie 扫描存储桶 → 结果识别敏感对象 → CloudTrail 数据事件揭示最近的访问 → 调查主体。
使用 SWF 进行长时间运行的人工工作流程
人工任务和批处理活动需要持久的工作流状态、重试、历史记录和长期协调。
推荐架构
● 在 Amazon Simple Workflow Service 中对工作流程进行建模。
● 使用活动工作人员执行自动化任务。
● 将 Mechanical Turk HIT 创建和结果表示为工作流活动。
● 单独存储持久的业务输出。
设计理由
● 技术可行性：SWF 保留工作流历史记录并协调长时间运行的活动和重试。
● 需求匹配：人类反应和批次进度仍然可追踪。
● 场景匹配：Mechanical Turk 任务可能会花费不可预测的时间。
● 工程常识：不要将长时间运行的工作流状态保留在计算内存中。
应排除的备选方案
● RDS 轮询和 Lambda 工作线程需要自定义编排。
● AWS Config 是一项合规性服务。
● Amazon MQ 传输消息，但不管理工作流程历史记录和人工任务状态。
● 简单的队列并不能表达完整的流程。
工作流：启动批处理 → 创建 HIT 活动 → 持久等待 → 收集结果 → 重试失败 → 完成批处理。
流式基因组分析
连续的基因组数据需要流式摄取、可扩展处理和用于分析查询的仓库。
推荐架构
● 使用 Amazon Kinesis Data Streams 提取记录。
● 使用流消费者进行近实时处理。
● 根据需要使用 Amazon EMR 进行大规模转型。
● 将整理的分析结果加载到 Amazon Redshift 中。
设计理由
● 技术可行性：Kinesis 处理连续记录，EMR 处理大型数据集，Redshift 支持分析 SQL。
● 需求匹配：该管道支持及时分析和持久的仓库报告。
● 场景匹配：基因组测量持续到达，而不是偶尔发出 API 请求。
● 工程常识：将摄取与繁重的分析分开，这样处理延迟就不会阻碍生产者。
应排除的备选方案
● API Gateway 和 SQS 添加了用于连续流式传输的间接消息工作流程。
● Kinesis 不会简单地通过添加 SQS 来分析现有 S3 对象。
● Firehose 提供数据，但不是活动 Kinesis 客户端描述的完整处理链。
● QuickSight 可将结果可视化，但不会取代仓库处理。
工作流：数据生产者 → Kinesis → 消费者或 EMR → Redshift → 分析查询。
近实时事件搜索和仪表板
半结构化 JSON 事件需要可扩展的摄取、转换、索引和仪表板可视化。
推荐架构
● 使用 Kinesis Data Firehose 缓冲和传送记录。
● 需要时使用 Lambda 转换事件。
● 在 Amazon OpenSearch Service 中对数据进行索引和可视化。
设计理由
● 技术可行性：Firehose 管理交付，Lambda 重塑记录，OpenSearch 提供可搜索索引和仪表板。
● 需求匹配：该管道支持动态模式和近实时操作视图。
● 场景匹配：工作负载是事件搜索，而不是关系事务或图遍历。
● 工程常识：摄取服务应该缓冲临时目标减速。
应排除的备选方案
● Aurora PostgreSQL 仍然是此事件模式的关系写入瓶颈。
● QuickSight 对于操作近乎实时的事件仪表板来说不太直接。
● Neptune 是一个图形数据库。
● Kinesis Data Streams 和 Lambda 单独省略了持久的可搜索存储和可视化。
工作流：事件 → Firehose → Lambda 转换 → OpenSearch 索引 → 仪表板查询。
使用 AWS MGN 迁移物理服务器
物理服务器可以通过持续复制、测试和受控切换迁移到 EC2。
推荐架构
● 在每台源服务器上安装 AWS Replication Agent。
● 配置 AWS Application Migration Service 暂存资源。
● 连续复制块级更改。
● 启动测试、修复并启动切换。
设计理由
● 技术可行性：MGN 将复制的服务器磁盘转变为可启动的 EC2 启动资源。
● 需求匹配：测试和最终同步可减少迁移停机时间。
● 场景匹配：完整的物理服务器工作负载必须移动，而不仅仅是文件。
● 工程常识：在最终切换之前验证网络、启动和应用程序依赖性。
应排除的备选方案
● Application Discovery Service 会清点服务器但不会迁移它们。
● DataSync 移动文件并且不创建可启动服务器映像。
● Outposts 不提供这种复制到 AMI 的工作流程。
● 手动重建会造成配置漂移。
工作流：安装代理→复制→启动测试→验证→最终同步→切换→停用源。
通过 URL 限制 EC2 出口
安全组和网络 ACL 过滤地址和端口，而不是完整的包存储库 URL。
推荐架构
● 部署带有已批准更新 URL 允许列表的转发代理。
● 通过代理路由 EC2 出站 Web 请求。
● 根据需要从工作负载子网中删除直接默认 Internet 路由。
● 记录代理请求并阻止每个未明确批准的目的地。
设计理由
● 技术可行性：应用层代理可以在根据策略转发 HTTPS 或 HTTP 流量之前检查主机名和 URL。
● 需求匹配：实例可以检索已批准的软件更新，而其他出站目的地仍然不可用。
● 场景匹配：该策略基于目标 URL，而不仅仅是基于 IP 或端口。
● 工程常识：在包含正在评估的信息的协议层实施控制。
应排除的备选方案
● 安全组是仅允许的，不能按 URL 进行过滤。
● 网络 ACL 需要 IP 范围，并且无法检查 HTTP 路径。
● NAT 网关提供出口转换，但不提供目标 URL 策略。
● DNS 控制本身并不能阻止直接 IP 访问或检查 URL 路径。
工作流：EC2 请求 → 代理 → URL 策略 → 批准的存储库 → 记录的响应；被拒绝的目的地在代理处停止。
扩展大型且不断增长的 MySQL 工作负载
持续增长的 16 TiB 数据库和 24×7 应用程序需要托管存储增长、数据库可用性和弹性应用程序层。
推荐架构
● 在应用程序负载均衡器后面跨可用区的 EC2 Auto Scaling 组中运行应用程序。
● 通过预留定价涵盖可预测的应用程序容量，并使用弹性容量来实现增长。
● 将 MySQL 迁移到 Amazon Aurora。
● 在另一个可用区中添加 Aurora 副本以实现可用性和读取扩展。
设计理由
● 技术可行性：Aurora 提供分布式托管存储、自动增长、副本和托管故障转移。
● 需求匹配：该设计支持持续的数据集扩展，并且比自管理 MySQL 的运营工作量更低。
● 场景匹配：Ruby on Rails 应用程序仍然基于服务器，并且可以水平扩展。
● 工程常识：选择具有增长空间的数据库，而不是重复扩展逻辑卷。
应排除的备选方案
● Lambda@Edge 并不是 Rails 处理层的一般替代品。
● 自我管理的源副本 MySQL 需要故障转移、备份和卷工程。
● 手动 RDS 存储会增加运营工作并减少增长空间。
● 预留实例可以降低成本，但其本身并不提供数据库高可用性。
工作流：扩展应用程序层→迁移数据→验证Aurora→添加副本→切换→监控存储和查询负载。
消除 NAT 实例下载超时
当 NAT 实例超时并发送 TCP FIN 时，长补丁下载可能会失败。
推荐架构
● 将 NAT 实例替换为 NAT 网关。
● 将 NAT 网关放置在具有弹性 IP 的公有子网中。
● 更新私有子网默认路由。
● 监视网关连接、错误和吞吐量。
设计理由
● 技术可行性：NAT 网关提供适合出站包下载的托管扩展和连接处理。
● 需求匹配：补丁下载变得更加可靠，无需维护 NAT 服务器。
● 场景匹配：Internet 连接已存在，但 NAT 实例中断了长流量。
● 工程常识：修复失败的出口组件，而不是修复不相关的放置或 VPN 设置。
应排除的备选方案
● 工作 NAT 出口已经暗示了互联网网关。
● 归置组影响东西向 EC2 延迟，而不影响 Internet 补丁下载。
● 虚拟专用网关服务于 VPN 或 Direct Connect，而不是公共存储库。
● 增加 NAT 实例大小可以保留超时和管理风险。
工作流：私有实例 → 路由到 NAT 网关 → 互联网网关 → 存储库 → 长下载通过 NAT 返回。
定期 AMI 漏洞评估
经批准的 AMI 管道应自动执行重复扫描、批准状态和更换决策。
推荐架构
● 使用 Amazon Inspector 评估模板扫描目标 EC2 实例中的 CVE。
● 将批准的 AMI 标识符存储在 Systems Manager Parameter Store 中。
● 使用 EventBridge 启动重复工作流程。
● 使用 Lambda 进行审批逻辑，使用 Systems Manager Automation 进行图像或队列操作。
设计理由
● 技术可行性：Inspector 执行漏洞评估，而其他服务协调调度和修复。
● 需求匹配：该过程定期识别易受攻击的图像并维护权威批准的列表。
● 场景匹配：该组织需要自动 CVE 扫描，而不仅仅是启动审核。
● 工程常识：单独的检测、批准决策和修复执行。
应排除的备选方案
● CloudTrail 记录启动但不扫描包中的 CVE。
● AWS Config 记录合规性，但不是详细的漏洞扫描程序。
● SSM 代理本身不执行评估。
● 手动审核无法满足重复的自动化要求。
工作流：EventBridge 计划 → Inspector 扫描 → Lambda 评估结果 → 更新批准的参数 → SSM 自动化修复。
将源限制为 CloudFront
CloudFront 应该是动态 ALB 内容和静态 S3 对象的唯一公共路径。
推荐架构
● 配置 CloudFront 以将秘密自定义标头添加到 ALB 源请求。
● 将 AWS WAF 连接到 ALB 并拒绝缺少标头的请求。
● 为 S3 源创建源访问身份。
● 更新 S3 存储桶策略以允许从 OAI 进行只读。
设计理由
● 技术可行性：自定义标头检查可区分 CloudFront 源请求，而 OAI 将请求签名为私有 S3 内容。
● 需求匹配：在不更改公共 CloudFront 终端节点的情况下，直接 ALB 和 S3 访问将被阻止。
● 场景匹配：一种发行版提供来自不同来源的动态和静态路径。
● 工程常识：使用该源类型支持的控件来保护每个源。
应排除的备选方案
● 与 OAI 的存储桶策略相比，单独的 S3 ACL 提供的控制更弱且集中度更低。
● 网络 ACL 无法可靠地允许将 CloudFront 源地址更改为应用程序身份。
● 仅附加到 CloudFront 的 WAF 会过滤查看器，但不能证明 ALB 请求来自 CloudFront。
● Route 53 不阻止直接源访问。
工作流：查看器 → CloudFront → 自定义标头 ALB 路径或 OAI 签名的 S3 路径。
使用客户端 VPN 进行私人员工访问
个人员工可以通过经过身份验证的 AWS 客户端 VPN 连接访问私有应用程序。
推荐架构
● 将应用程序服务器保留在私有子网中。
● 使用证书或批准的身份验证创建 AWS 客户端 VPN 终端节点。
● 授权员工网络和应用程序路线。
● 应用安全组来限制可访问的服务。
设计理由
● 技术可行性：客户端 VPN 提供从单个设备到 VPC 的加密远程访问。
● 需求匹配：该应用程序不公开，授权员工可以通过互联网进行连接。
● 场景匹配：用户是单个远程员工，而不是整个分支机构网络。
● 工程常识：私有子网放置和用户身份验证解决了不同层的访问控制。
应排除的备选方案
● Direct Connect 对于临时个人访问来说成本高昂。
● 站点到站点 VPN 连接网络，而不是漫游用户。
● 公共子网不必要地暴露服务器。
● 单独的公共负载均衡器不会限制员工的访问。
工作流：员工身份验证→加密客户端VPN隧道→授权路由→应用安全组→私有服务器。
使用 IAM 角色进行跨账户管理
合并计费不会授予成员帐户管理访问权限。访问权限必须明确委派。
推荐架构
● 将管理员 IAM 身份保留在管理账户中。
● 在开发和测试账户中创建管理 IAM 角色。
● 配置每个角色的信任策略以允许批准的管理帐户委托人代入该策略。
● 在每个目标帐户中附加所需的管理权限。
设计理由
● 技术可行性：当受信任的管理员担任目标账户角色时，AWS STS 会颁发临时凭证。
● 需求匹配：管理员使用一个家庭身份即可获得受控访问，而无需重复 IAM 用户。
● 场景匹配：这些帐户相互关联以进行计费，但仍保持独立的安全边界。
● 工程常识：定义资源所在的权限，并仅信任需要它们的中央身份。
应排除的备选方案
● 合并账单更改付款聚合，而不是 IAM 授权。
● 仅在管理账户中创建的角色无法自动管理目标账户资源。
● 在每个账户中复制长期 IAM 用户会增加凭证和注销工作。
● 资源策略本身不提供一般帐户管理。
工作流：集中登录 → 请求 AssumeRole → 目标信任策略评估 → 接收临时凭证 → 管理目标帐户。
具有缓存卷的可扩展混合块存储
需要 iSCSI 块接口的应用程序可以使用小型本地缓存，同时将数据集持久存储在 AWS 中。
推荐架构
● 在缓存卷模式下部署 AWS Storage Gateway Volume Gateway。
● 将 iSCSI 块卷提供给本地服务器。
● 将频繁访问的块保留在本地缓存存储中。
● 通过托管网关服务将主卷数据存储在 Amazon S3 中。
● 使用快照进行恢复和AWS端恢复。
设计理由
● 技术可行性：缓存卷保留块访问，同时减少所需的本地存储量。
● 需求匹配：该设计可扩展非常大的数据集并在本地维护频繁的数据。
● 场景匹配：现有应用程序需要块存储而不是对象 API。
● 工程常识：保留应用程序所需的接口，同时将持久容量转移到云存储。
应排除的备选方案
● 存储卷需要完整的主数据集保留在本地。
● 直接 S3 访问是基于对象的，并且不提供 iSCSI 块设备。
● S3 Glacier 是归档对象存储，无法安装为活动块卷。
● 文件网关提供文件协议，而不是所需的块接口。
工作流：应用程序 I/O → iSCSI 卷 → 本地缓存 → 网关管理的 S3 支持 → 需要时的快照。
保护高度可用的 Web 应用程序
生产 Web 应用程序需要弹性入口、私有管理、数据库故障转移、边缘加速和 Web 过滤。
推荐架构
● 将 ALB 与 EC2 Auto Scaling 组结合使用。
● 通过 Systems Manager 会话管理器管理实例。
● 使用 RDS 多可用区。
● 添加 CloudFront 和 AWS WAF。
设计理由
● 技术可行性：ALB 和 Auto Scaling 分配流量，Session Manager 删除入站 SSH，RDS 提供备用故障转移，CloudFront 加上 WAF 改进交付和保护。
● 需求匹配：该设计通过托管服务解决可用性和安全性问题。
● 场景匹配：该工作负载是面向互联网的 EC2 应用程序。
● 工程常识：安全管理不应引入另一个公共服务器。
应排除的备选方案
● 直接 SSH 保留密钥和端口暴露。
● 单可用区 RDS 仍然是数据库故障点。
● 堡垒可以工作，但与会话管理器相比增加了操作。
● Shield Standard 本身并不提供完整的网页过滤架构。
工作流：用户 → CloudFront 和 WAF → ALB → EC2；管理员→会话管理器；数据 → 多可用区 RDS。
重新构建容器化应用程序平台
低变化迁移保留了应用程序的现有边界，同时用托管服务取代了自我管理的基础设施。
推荐架构
● 将经过测试的 OpenJDK 容器映像存储在 Amazon ECR 中。
● 在 Amazon ECS 上运行容器。
● 使用 AWS Database Migration Service 将 MySQL 迁移到 Amazon RDS。
设计理由
● 技术可行性：ECS 运行 Docker 工作负载，RDS 支持 MySQL，DMS 在有限中断的情况下移动关系数据。
● 需求匹配：OpenJDK 取消了商业 Java 许可，同时托管计算和数据库服务减少了操作。
● 场景匹配：该应用程序已经使用容器和 MySQL，因此平台重构保留了这两种模式。
● 工程常识：一次对一层进行现代化改造，而不是一起改变计算和数据模型。
应排除的备选方案
● EC2 重新托管可以工作，但保留服务器和数据库管理。
● 使用 DynamoDB 替换 MySQL 会更改关系行为和应用程序代码。
● 将容器转换为 Lambda 是一种重构，而不是最小更改迁移。
工作流：构建 OpenJDK 镜像 → 测试 → 推送到 ECR → 部署到 ECS → 使用 DMS 复制 MySQL → 验证 → 切换。
托管对话式联络中心
可扩展的呼叫中心需要托管电话、语音理解、会话意图处理以及与业务系统的安全集成。
推荐架构
● 使用 Amazon Connect 进行入站呼叫和联系流。
● 使用 Amazon Lex 进行自动语音识别和自然语言意图处理。
● 调用AWS Lambda函数来查询或更新业务应用程序。
● 通过联系流返回相关结果。
设计理由
● 技术可行性：Connect 处理联络中心路由，Lex 理解语音请求，Lambda 集成后端操作。
● 需求匹配：呼叫者无需代理即可完成常见任务，而服务无需呼叫中心基础设施管理即可扩展。
● 场景匹配：密码更改和余额检查是基于意图的自助服务操作。
● 工程常识：将会话口译与受控商业交易分开。
应排除的备选方案
● MediaConnect 传输专业视频流，并不是联络中心平台。
● Polly 产生语音，但不执行语音识别或意图检测。
● 地面站支持卫星通信。
● Comprehend 分析文本，但不提供 Lex 提供的交互式语音机器人工作流程。
工作流：来电 → Connect 流程 → Lex 识别意图 → Lambda 验证并执行操作 → Connect 将响应或路由返回给代理。
数千个 AWS 账户的集中出口
大型多帐户环境需要可扩展的路由中心和集中的出站流量策略实施。
推荐架构
● 将分支 VPC 连接到 AWS Transit Gateway。
● 将批准的出站流量路由到集中出口或检查 VPC。
● 根据检查设计使用托管或防火墙 VPN 连接。
● 应用组织控制的路由和防火墙策略。
● 将允许的流量返回到适当的分支。
设计理由
● 技术可行性：Transit Gateway 提供中心辐射型路由，无需数千个成对对等关系。
● 需求匹配：安全团队集中管理出口控制，而应用程序帐户保留单独的 VPC。
● 场景匹配：该设计必须能够扩展到数千个帐户。
● 工程常识：集中策略和检查，而不是每个工作负载的应用程序架构。
应排除的备选方案
● VPC 对等互连会造成无法管理的连接和路由增长。
● 共享 VPC 并不适合每个独立账户和路由边界。
● 具有 EC2 设备的自我管理传输 VPC 增加了修补和扩展工作。
● 每个帐户中都有独立的 NAT 和防火墙堆栈，重复成本和策略管理。
工作流：分支路由→中转网关→集中检查→批准的互联网出口→通过集线器的返回路径。
流量逐渐转移的独立合规性发布
新的合规性边界应部署为并行环境，而不是强制到现有的生产堆栈中。
推荐架构
● 为兼容的应用程序版本构建单独的 OpsWorks 堆栈。
● 独立验证新环境。
● 使用 Route 53 加权路由向其发送一小部分生产流量。
● 逐渐增加流量，保留原来的堆栈进行回滚。
设计理由
● 技术可行性：并行堆栈可以运行不同的版本，而 DNS 权重控制暴露。
● 需求匹配：逐步割接保护百万用户并支持快速回滚。
● 场景匹配：现有平台已经使用 OpsWorks 和 EC2，因此该版本保持相同的操作模型。
● 工程常识：在验证过程中隔离监管变化并减少影响范围。
应排除的备选方案
● 就地升级暴露所有用户并削弱回滚。
● 将所有流量发送到新堆栈会立即删除分阶段验证。
● 将 Lambda 引入 OpsWorks 版本会改变平台，但没有解决规定的隔离需求。
工作流：构建→合规性测试→功能测试→低流量权重→观察→增加权重→验收后淘汰旧堆栈。
通过 Direct Connect 进行加密 VPN 传输
Direct Connect 提供私有、可预测的传输，但默认情况下不加密流量。可以通过专用连接上承载的 AWS 站点到站点 VPN 进行分层加密。
推荐架构
● 在现有 Direct Connect 连接上创建公共虚拟接口。
● 通过该接口访问公共 AWS VPN 终端节点。
● 建立到 VPC 的基于 BGP 的 Site-to-Site VPN。
● 通过加密隧道路由公司员工流量。
设计理由
● 技术可行性：公共 VIF 提供对 AWS 公共服务终端节点的访问，包括 VPN 终止地址。
● 需求匹配：IPsec 对流量进行加密，同时底层路径保留 Direct Connect 性能特征。
● 场景匹配：员工已经从公司网络访问私有 EC2 应用程序。
● 工程常识：向现有可靠路径添加加密，而不是将流量移回公共互联网。
应排除的备选方案
● 通过 Internet 路由的 VPN 会失去所请求的 Direct Connect 一致性。
● 私有 VIF 到达 VPC 私有地址，但不到达此模式所需的公共 VPN 终端节点。
● 笔记本电脑之间的 VPN 连接与现有的企业网络路由设计不匹配。
工作流：公司路由 → 客户路由器 → IPsec 隧道 → Direct Connect 上的公共 VIF → AWS VPN 终端节点 → VPC。
安全的企业应用部署
复杂的应用程序需要完整的基础设施定义、受控的流量移动和不可变的容量替换。
推荐架构
● 使用 CloudFormation 定义完整的堆栈。
● 使用 CodeDeploy 蓝/绿来控制生产流量转移。
● 在适用的情况下，使用 Elastic Beanstalk 不可变部署来实现托管应用程序容量。
● 监视运行状况并保留回滚目标。
设计理由
● 技术可行性：CloudFormation 编排资源，而蓝/绿和不可变部署避免了修改服务队列。
● 需求匹配：发布最大限度地减少停机时间和回滚风险。
● 场景匹配：该堆栈包括 DynamoDB、Lambda、OpenSearch 和 Beanstalk 资源。
● 工程常识：基础设施和应用程序版本应该通过测试阶段一起推广。
应排除的备选方案
● SAM 针对无服务器应用程序进行了优化，但并不是此混合堆栈的最佳完整模型。
● 就地部署会增加中断和回滚风险。
● Lightsail 缺乏所需的企业编排。
● 手动切换会导致恢复不一致。
工作流：提交→构建和测试→更新堆栈→部署替换容量→转移流量→监控或回滚。
无屏蔽高级的分层 DDoS 弹性
当优质 DDoS 响应服务超出预算时，网络弹性应结合边缘吸收、过滤、负载分配、监控和弹性。
推荐架构
● 在适当的情况下使用 Amazon CloudFront 进行静态和动态 Web 交付。
● 将应用程序负载均衡器放置在多个应用程序实例前面。
● 将 AWS WAF 规则应用于 CloudFront 或 ALB 以获取应用程序层攻击模式。
● 针对 CPU 和网络压力创建 CloudWatch 警报。
● 当需求增加时自动扩展 EC2 队列。
设计理由
● 技术可行性：边缘容量吸收流量，WAF 过滤请求，ALB 分散负载，Auto Scaling 增加应用程序容量。
● 需求匹配：这些控件可提高可用性，而无需 Shield Advanced 成本。
● 场景匹配：受保护的工作负载是 EC2 托管的 Web 应用程序。
● 工程常识：没有单一的控制可以处理每个 DDoS 层；使用补充防御。
应排除的备选方案
● 预留实例是一种计费模型，不提供额外的性能。
● 附加 ENI 或增强网络无法识别恶意请求。
● S3 不是 POSIX 存储，修补并不能缓解主动流量泛滥。
工作流：边缘→WAF→ALB→目标→缩放和警报。
IAM 授权的 API 网关请求
AWS 委托人可以通过本机 IAM 授权和签名版本 4 安全地调用 API Gateway。
推荐架构
● 设置API授权类型为AWS_IAM。
● 在所需的阶段和方法上授予批准的用户或角色 execute-api:Invoke。
● 使用 SigV4 签署客户端请求。
● 当需要请求跟踪时启用 X-Ray。
设计理由
● 技术可行性：API Gateway 根据 IAM 权限验证签名的请求。
● 需求匹配：现有 IAM 身份无需另一个凭证数据库即可接收受控 API 访问。
● 场景匹配：调用者是 AWS 用户或角色。
● 工程常识：切勿将秘密访问密钥传输给自定义授权者。
应排除的备选方案
● CORS 控制浏览器源行为，而不是身份验证。
● 客户端证书对选定后端集成的 API Gateway 进行身份验证，而不是对公共 API 的调用者进行身份验证。
● 手动密钥验证会重复 AWS 身份验证并存在泄露机密的风险。
● API 密钥用于识别使用计划，并不是强大的授权机制。
工作流：客户端签署请求 → API Gateway 验证 SigV4 → IAM 评估 execute-api:Invoke → 后端运行。
用于迁移发现和准备的工具
迁移规划应结合投资组合跟踪、依赖性发现和业务案例分析。
推荐工具
● 使用 AWS Migration Hub 跟踪应用程序和迁移进度。
● 使用 AWS Application Discovery Service 收集服务器配置、利用率和依赖项数据。
● 使用云采用准备工具来评估组织准备情况并确定能力差距。
设计理由
● 技术可行性：Discovery Service 收集资产数据，Migration Hub 集中可见性，CART 构建准备情况评估。
● 需求匹配：它们共同支持工作负载移动开始之前的规划。
● 场景匹配：组织需要对产品组合级别的理解，而不仅仅是一台服务器的传输。
● 工程常识：在对迁移浪潮进行排序之前发现依赖关系。
应排除的备选方案
● 应用程序迁移服务执行服务器迁移，但不会取代组织准备情况评估。
● 数据库迁移服务专注于数据库数据移动。
● CloudFormation 部署基础设施，但不发现本地资产。
● Cost Explorer 会分析采用后或采用期间的 AWS 支出，并不是主要的迁移发现工具。
工作流：评估准备情况→发现服务器和依赖项→对应用程序进行分组→构建wave→跟踪迁移中心的执行情况。
将 Active Directory 身份验证扩展到 AWS
AWS 中的 Windows 工作负载可以通过托管目录信任使用现有的企业凭证。
推荐架构
● 使用 AWS Directory Service 部署 AWS Managed Microsoft AD。
● 与本地 Microsoft Active Directory 建立所需的信任关系。
● 配置目录之间的 DNS 和网络连接。
● 将 AWS 托管的 Windows 资源加入托管域并启用所需的 SSO 体验。
设计理由
● 技术可行性：目录信任允许来自企业林或域的身份对受信任的 AWS 托管资源进行身份验证。
● 需求匹配：员工保留现有的用户名和密码，同时管理 AWS 中的目录基础设施。
● 场景匹配：要求是 Windows 域扩展和单点登录，而不是消费者身份。
● 工程常识：使用托管兼容目录，而不是将密码同步到应用程序数据库中。
应排除的备选方案
● Amazon Cognito 以应用程序用户为目标，不扩展 Windows 域。
● IAM 角色授权 AWS API 操作，但不提供域身份验证。
● IAM Identity Center 可以联合员工访问，但不会替换域加入所需的 Windows 目录。
● 自定义 LDAP 服务器增加了可用性和修补工作。
工作流：用户向公司 AD 进行身份验证 → 评估信任 → AWS Managed Microsoft AD 授权访问 → Windows 资源会话。
托管 PB 级批处理
大型并行图像工作负载需要托管作业调度、弹性低成本计算、持久对象存储和临时本地处理空间。
推荐架构
● 打包 AWS Batch 作业的处理可执行文件。
● 使用具有 EC2 Spot 容量的托管计算环境。
● 将原始图像和处理后的图像存储在单独的 Amazon S3 位置。
● 使用作业队列来安排数千个并行任务。
● 仅使用 EBS 卷作为临时本地工作区。
设计理由
● 技术可行性：AWS Batch 提供计算和调度作业，而 S3 可扩展到 PB 级并具有高耐用性。
● 需求匹配：Spot 降低了计算成本，托管调度程序最大限度地减少了运营开销。
● 场景匹配：作业是独立、并行的，并且在大约一周内完成。
● 工程常识：将持久数据保留在一次性工作人员之外。
应排除的备选方案
● 自定义 SQS 和 Auto Scaling 工作线程平台需要更多调度和队列逻辑。
● 对于 10 PB 批量数据集，EFS 并不是最经济的共享源。
● EKS 可以运行作业，但添加了 Kubernetes 管理。
● EMR 适用于受支持的大数据框架，而不是自动适用于需要为 Spark 重写的现有可执行文件。
工作流：上传输入 → 提交作业 → 批量调度 Spot 工作人员 → 阶段到 EBS → 处理 → 将结果写入 S3。
分层 Web DDoS 缓解
DDoS 弹性结合了减少暴露、边缘容量、应用程序过滤和托管响应。
推荐架构
● 使用网络 ACL 和安全组限制不必要的端口。
● 将 CloudFront 放置在公共 Web 源之前。
● 使用 AWS WAF 阻止恶意 Web 模式。
● 当需要增强 DDoS 防护时启用 Shield Advanced。
设计理由
● 技术可行性：网络控制减少攻击面，CloudFront 吸收边缘流量，WAF 过滤第 7 层请求，Shield 增加基础设施保护。
● 需求匹配：这些控制涵盖了互补的攻击路径。
● 场景匹配：工作负载是面向互联网的 Web 应用程序。
● 工程常识：扩展有助于可用性，但不能取代过滤。
应排除的备选方案
● MFA、Config、Trusted Advisor 和 Fraud Detector 不会直接阻止 DDoS 流量。
● 较大的实例仍然可能被淹没并增加攻击成本。
● 会话管理器是一个管理工具。
● S3 版本控制和操作系统补丁可提高耐用性和卫生性，而不是主动缓解流量。
工作流：互联网 → Shield 和 CloudFront → WAF → 允许的端口 → 负载均衡器和应用程序。
跨账户私人托管区关联
Route 53 私有托管区域仅解析与该区域关联的 VPC 的记录。
推荐流程
● 在托管区域所有者账户中，授权与第二个账户中的应用程序 VPC 关联。
● 在 VPC 所有者账户中，将 VPC 与私有托管区域关联。
● 完成后删除临时关联授权。
● 验证VPC DNS支持并查询数据库CNAME。
设计理由
● 技术可行性：Route 53 通过先授权后关联的方式支持跨账户私有托管区域关联。
● 需求匹配：EC2 实例解析集中式私有数据库名称，无需复制 DNS 区域。
● 场景匹配：记录正确，但应用VPC尚未链接到可用区。
● 工程常识：修复名称解析范围，而不是硬编码更改数据库地址。
应排除的备选方案
● VPC 对等互连不会自动将私有托管区域与另一个 VPC 关联。
● 私有托管区域不能相互关联以进行记录复制。
● 使用 RDS IP 编辑 /etc/resolv.conf 很脆弱，因为地址可能会在故障转移期间发生变化。
工作流：授权→关联→解除授权→解析CNAME→连接RDS。
ECS 微服务的任务级安全性
容器安全性应在任务级别隔离网络访问和 AWS 权限，而不是共享主机级别的控制。
推荐架构
● 在 ECS 任务定义中使用 awsvpc 网络模式。
● 直接将安全组分配给 ECS 任务。
● 使用 IAM 任务角色访问 AWS 服务。
● 仅向每个微服务授予其所需的操作和资源。
设计理由
● 技术可行性：每个任务都会接收一个弹性网络接口、私有 IP 地址和安全组控制。
● 需求匹配：任务角色和任务安全组实现网络和 API 访问的最低权限。
● 场景匹配：严格的安全策略需要容器级别的标准网络监控和控制。
● 工程常识：不要为每个容器授予其 EC2 主机的广泛权限。
应排除的备选方案
● 桥接模式在主机上应用安全组，而不是单个任务。
● EC2 实例角色可以向主机上的多个服务公开更广泛的权限。
● 将 IAM 凭证传递到容器中会产生长期的秘密风险。
● 迁移到 App Runner 不会证明环境变量中的凭据是合理的，并且会不必要地更改平台。
工作流：定义任务角色→选择awsvpc→附加任务安全组→部署→检查流程和应用程序日志→细化权限。
使用外部 ID 进行供应商访问
供应商应通过最低权限的 IAM 角色和外部 ID 条件来访问客户资源。
推荐架构
● 在客户帐户中创建角色。
● 仅授予所需的操作和资源。
● 信任供应商的 AWS 账户或角色。
● 需要客户特定的外部 ID。
● 让供应商致电 STS 获取临时凭证。
设计理由
● 技术可行性：信任策略在角色承担之前验证供应商身份和外部 ID。
● 需求匹配：访问权限是临时的、可撤销的，并且可以防止代理跨客户错误。
● 场景匹配：一个供应商应用程序为多个客户提供服务。
● 工程常识：切勿与服务提供商共享个人或根访问密钥。
应排除的备选方案
● 长期 IAM 用户密钥会增加暴露和轮换工作。
● Amazon Connect 与第三方 API 授权无关。
● 个人访问密钥暴露了客户自己的身份和权限。
● 信任没有外部 ID 的供应商会削弱客户分离。
工作流：供应商使用外部 ID 请求角色 → IAM 信任评估 → STS 发出临时会话 → 供应商执行范围内的工作。
持久报纸搜索和 OCR 现代化
数字报纸档案需要持久的图像存储、全球交付、可扩展的搜索以及对即将到期的 OCR 软件的托管替代品。
推荐架构
● 将扫描的 PNG 文件存储在 Amazon S3 中。
● 通过 Amazon CloudFront 交付图像。
● 在多可用区 Elastic Beanstalk 环境中运行 Web 应用程序。
● 使用 Amazon CloudSearch 为可搜索内容编制索引。
● 使用 Amazon Textract 从扫描的报纸中提取文本。
设计理由
● 技术可行性：Textract 执行文档 OCR，CloudSearch 支持文本查询，S3 加 CloudFront 提供持久的全局内容交付。
● 需求匹配：托管服务减少了管理，同时支持可用性和增长。
● 场景匹配：存档包含必须可搜索的扫描文档。
● 工程常识：单独的持久源图像、提取的文本、搜索索引和网络交付。
应排除的备选方案
● Rekognition 不是用于文档文本提取的主要 OCR 服务。
● Glacier 与立即检索冲突，并且不能解决 OCR。
● 自我管理的 EC2、EBS、NGINX 和搜索软件增加了操作和较弱的共享存储扩展。
工作流：摄取扫描 → 存储在 S3 中 → 使用 Textract 提取文本 → 索引结果 → 通过应用程序搜索 → 通过 CloudFront 交付图像。
通过消除数据库等待来降低无服务器成本
在调整计算设置之前，应在延迟源处纠正由网络等待导致的较长 Lambda 持续时间。
推荐架构
● 将本地 MySQL 数据库迁移到 Amazon RDS for MySQL。
● 使用多可用区实现数据库可用性。
● 启用 API 网关缓存以实现安全、可重复的响应。
● 测量新的执行配置文件后调整 Lambda 内存大小和超时。
● 使用 DynamoDB Auto Scaling 实现不可预测的增长。
设计理由
● 技术可行性：将 MySQL 移至靠近 Lambda 的位置可消除重复的混合延迟； API 缓存减少了调用。
● 需求匹配：更短的执行时间和更少的调用直接降低了成本。
● 场景匹配：该应用程序已经实现了无服务器扩展，因此用服务器替换 Lambda 将颠倒工作设计。
● 工程常识：消除优化辅助资源之前 4.5 分钟的等待。
应排除的备选方案
● Direct Connect 可以改善延迟，但对于单个工作负载来说成本高昂，并且保留了远程依赖性。
● 将 Lambda 转换为 EC2 增加了容量管理。
● CloudFront 缓存不如 API Gateway 阶段缓存直接。
● DAX 或 ElastiCache 会增加成本，但没有规定低延迟缓存要求。
工作流：迁移数据库→验证→缓存API→测量Lambda→调整→监控成本。
按队列长度缩放图像分析
共享对象存储、持久工作分配和基于待办事项的扩展可以安全地减少图像处理时间。
推荐架构
● 将输入和输出文件存储在 Amazon S3 中。
● 在 Amazon SQS 中为每个图像放置一个处理任务。
● 使用 SQS 队列深度指标扩展 EC2 工作线程。
● 使工作人员幂等并配置死信队列。
设计理由
● 技术可行性：每个工作人员都可以访问 S3，SQS 分配任务，Auto Scaling 遵循实际的积压工作。
● 需求匹配：更多的工作人员在高峰期启动，并在工作量下降时终止。
● 场景匹配：图像是独立的并行任务。
● 工程常识：从待处理的工作进行扩展，而不是从可能已经使用的通知进行扩展。
应排除的备选方案
● EBS 附加到实例和可用区，而不是在动态队列中共享。
● SNS 是一种通知服务，而不是持久的竞争消费者队列。
● SNS 通知计数不是当前处理积压的数量。
● 仅从 CPU 进行扩展可能反应太晚或忽略排队的需求。
工作流：图像到 S3 → 任务到 SQS → 队列增长 → 工作人员扩展 → 结果到 S3 → 队列耗尽。
对未经授权的 IAM 用户立即响应
创建新的 IAM 用户时，CloudTrail 事件可以触发自动审批和修复工作流程。
推荐架构
● 将 CloudTrail CreateUser 事件与 EventBridge 匹配。
● 调用 Step Functions 进行批准和修复。
● 未经批准时删除或限制权限。
● 通过 SNS 通知安全部门。
设计理由
● 技术可行性：CloudTrail 记录 API，EventBridge 近乎实时地做出反应，Step Functions 协调操作。
● 需求匹配：未经授权的用户会被快速遏制，并通知安全部门。
● 场景匹配：该控件专注于一个帐户更改 API 事件。
● 工程常识：在修改身份之前保留事件详细信息。
应排除的备选方案
● 审计经理收集证据并不会立即采取补救措施。
● CloudTrail 记录事件但不独立过滤和通知。
● Fargate 添加了不必要的容器启动和操作。
● 未经许可删除的通知会使风险处于活动状态。
工作流：创建用户 → CloudTrail → EventBridge → Step Functions → 限制用户 → SNS 警报。
弹性全球网络平台
公共网络平台需要全局静态交付、网络保护、弹性计算和托管关系数据库。
推荐架构
● 将静态内容存储在 S3 中并通过 CloudFront 进行交付。
● 附加 AWS WAF 以应对常见应用程序攻击。
● 在多可用区 Auto Scaling 组中运行 Web 服务器。
● 使用 Aurora MySQL 来实现托管数据库的可用性和规模。
设计理由
● 技术可行性：CloudFront 缓存内容，WAF 过滤 HTTP 请求，Auto Scaling 替换故障服务器，Aurora 提供托管关系存储。
● 需求匹配：该设计同时提高了性能、安全性、可用性和操作。
● 场景匹配：静态内容、网络计算和关系数据需要不同的服务。
● 工程常识：使用托管层而不是自我管理每个组件。
应排除的备选方案
● EC2 上的自我管理 MySQL 保留了数据库操作并省略了边缘保护。
● Global Accelerator 不是静态内容缓存。
● S3 Transfer Acceleration 加速上传速度，而不是网站传送速度。
● 标准 RDS 可以工作，但所选的 Aurora 设计更适合托管扩展和可用性。
工作流：用户 → CloudFront 和 WAF → Auto Scaling Web 层 → Aurora MySQL。
针对紧急流量激增的边缘卸载
当无法完全迁移时，请在不更改应用程序事务核心的情况下缓解主要流量路径。
推荐架构
● 在本地保留动态网站和支付工作流程。
● 将 Amazon CloudFront 放置在高分辨率图像和其他可缓存资产的前面。
● 附加阻止常见 SQL 注入和跨站点脚本模式的 AWS WAF 规则。
设计理由
● 技术可行性：CloudFront 可以使用现有站点作为源并缓存用户附近的静态响应。
● 需求匹配：边缘缓存快速降低源带宽和负载； WAF 添加了所请求的 Web 层保护。
● 场景匹配：大型静态资产是直接的扩展压力，而支付仍然是动态的。
● 工程常识：首先解决瓶颈，而不是匆忙开始全面迁移。
应排除的备选方案
● S3 静态网站托管无法替代动态支付处理。
● 构建 EC2 映像、Auto Scaling、混合路由和 ALB 对于截止日期来说过于宽泛。
● 当边缘服务满足紧急需求时，完整的服务器迁移会带来时间和切换风险。
工作流：对可缓存路径进行分类 → 配置源和缓存行为 → 附加 WAF → 测试支付 → 监控源卸载。
借助 RDS 多可用区实现 Oracle 高可用性
需要自动故障转移的托管 Oracle 数据库应使用 Amazon RDS 多可用区部署。
推荐架构
● 在启用多可用区的 Amazon RDS 上运行 Oracle。
● 通过 RDS 端点连接应用程序。
● 让 RDS 在另一个可用区中保持同步备用。
● 测试应用程序在受控故障转移期间的重新连接行为。
设计理由
● 技术可行性：RDS 检测基础设施故障、提升备用状态并更新端点的 DNS 映射。
● 需求匹配：无需客户管理的集群和复制操作即可提高数据库可用性。
● 场景匹配：网站需要连续性，而不仅仅是分析读取扩展。
● 工程常识：在数据库引擎和版本支持的情况下使用托管故障转移。
应排除的备选方案
● RMAN 备份支持恢复，但不提供自动故障转移。
● Oracle 只读副本（如果可用）与同步多可用区备用数据库不同。
● EC2 上的自我管理 Oracle RAC 增加了许可、集群、存储和修补的复杂性。
● 单个 RDS 实例仍然存在可用性风险。
工作流：应用程序使用端点→主故障→RDS提升备用→DNS更新→应用程序重新连接。
适用于对等 VPC 的单客户端 VPN
员工可以通过一个集中管理的客户端 VPN 终端节点进行连接，并访问对等 VPC 中的应用程序。
推荐架构
● 在主 VPC 中部署客户端 VPN 终端节点。
● 在员工设备上安装 VPN 客户端。
● 添加远程 VPC CIDR 的客户端 VPN 授权和路由。
● 配置互惠 VPC 对等路由和安全规则。
设计理由
● 技术可行性：客户端 VPN 终止远程用户会话，而 VPC 对等互连将流量传输到连接的应用程序 VPC。
● 需求匹配：一个端点可降低跨账户的成本和管理。
● 场景匹配：内部应用程序已驻留在对等 VPC 中。
● 工程常识：验证 CIDR 不重叠并且对等互连是非传递的。
应排除的备选方案
● 每个帐户一个客户端 VPN 会重复管理。
● 客户端软件属于员工设备，而不是数据中心。
● 站点到站点 VPN 不会取代漫游用户的客户端 VPN 终端节点。
● 缺少返回路线会中断连接。
工作流：员工 → 客户端 VPN → 主 VPC 路由 → 对等连接 → 应用程序 VPC → 返回路径。
可扩展的移动照片和字幕平台
期望有数百万次浏览的消费者移动应用程序应该将身份验证、小型结构化记录、对象存储和全局交付分开。
推荐架构
● 使用 Amazon Cognito 进行用户身份验证和身份管理。
● 将字幕和用户元数据存储在 Amazon DynamoDB 中。
● 将上传的照片和静态资源存储在 Amazon S3 中。
● 通过 Amazon CloudFront 交付静态内容。
设计理由
● 技术可行性：Cognito 支持移动登录，DynamoDB 扩展键值记录，并且带有 CloudFront 的 S3 处理大型对象流量。
● 需求匹配：所有组件都可以以较低的运营开销进行扩展，并且没有固定的服务器群。
● 场景匹配：照片是对象，而简短的标题是小的结构化项目。
● 工程常识：将每种数据类型与为其设计的服务相匹配。
应排除的备选方案
● RDS 是可行的，但增加了简单字幕数据的容量规划和数据库操作。
● 直接移动访问 RDS 是不合适的。
● 社交登录不需要本地 Active Directory 和自定义 LDAP 代码。
● SAML 不是普通消费者社交身份提供商的直接模式。
工作流：用户登录→接收范围身份→将照片上传到S3→将标题写入DynamoDB→查看者通过CloudFront接收缓存的资产。
异构数据库迁移：Oracle 到 PostgreSQL
异构数据库迁移有两个不同的工作：转换数据库对象，然后移动和同步数据。
推荐架构
● 使用 AWS Schema Conversion Tool 评估和转换 Oracle 架构和代码。
● 解决需要手动转换的对象。
● 创建目标 Amazon RDS for PostgreSQL 数据库。
● 使用 AWS Database Migration Service 进行满负载和持续更改复制。
设计理由
● 技术可行性：SCT转换结构不同的数据库对象； DMS 在源引擎和目标引擎之间传输记录。
● 需求匹配：该工作流程支持在有限的停机时间和专用工具的情况下进行迁移。
● 场景匹配：Oracle和PostgreSQL是不同的引擎，因此模式转换必须先于数据切换。
● 工程常识：不要期望数据移动服务重新设计存储过程或不兼容的架构。
应排除的备选方案
● SAM 和 Lambda 是应用程序开发工具，而不是数据库转换服务。
● 服务器迁移服务移动服务器而不是转换数据库引擎。
● 仅DMS并不能完成异构模式和代码转换。
● Data Pipeline、CodeCommit 和 Batch 可以支持自定义脚本，但会添加不必要的工程。
工作流：评估 → 转换架构 → 修复代码 → 创建目标 → 完全加载 → 复制更改 → 验证 → 切换。
强制执行成本分配标签
准确的成本报告需要纠正现有资源并防止未来创建无标签的情况。
推荐架构
● 使用标签编辑器将所需标签添加到现有 RDS 和 DynamoDB 资源。
● 激活这些键作为成本分配标签。
● 使用带有标签条件的 SCP 可在缺少所需标签时拒绝将来的资源创建。
设计理由
● 技术可行性：标签编辑器执行批量更新，计费公开激活的标签，SCP 条件创建预防性护栏。
● 需求匹配：历史资源变得可报告，并且新的漂移减少。
● 场景匹配：成本中心和项目元数据在账户之间是强制性的。
● 工程常识：纠正过去并防止再次发生。
应排除的备选方案
● 激活计费标签不会创建丢失的资源标签。
● Lambda 修复会添加自定义代码并在创建后执行操作。
● 仅标记当前资源并不会强制执行未来的行为。
● AWS Config 可以检测丢失的标签，但不会阻止创建。
工作流：库存→批量标签→激活计费密钥→应用SCP→测试批准和拒绝的供应。
传感器时间序列的 DynamoDB 键
每个传感器的时间序列查询需要传感器的分区键和时间的有序排序键。
推荐设计
● 每周创建 DynamoDB 表以限制活动数据大小。
● 使用传感器 ID 作为分区键。
● 使用时间戳作为排序键。
● 查询一个传感器的时间范围条件。
设计理由
● 技术可行性：一个传感器的项目在逻辑上位于同一位置并按时间戳排序。
● 需求匹配：该应用程序有效地检索传感器的最近测量值。
● 场景匹配：数据自然地按设备和时间分组。
● 工程常识：确保传感器流量充分分布以避免热分区。
应排除的备选方案
● 将传感器和时间戳连接到一个分区键会使范围查询变得困难。
● 仅靠周表并不能修复糟糕的键设计。
● DynamoDB 的分区键是哈希键；颠倒关键角色是不正确的。
● 一个全局分区键创建一个热分区。
工作流：选择每周表→查询传感器分区→应用时间戳范围→返回有序测量。
在资源创建时应用标签
治理标签应在配置期间应用，而不是事后发现和修复。
推荐架构
● 通过 AWS Service Catalog 发布批准的产品，以便预配置的资源继承产品组合、产品和用户元数据。
● 在 CloudFormation 资源中定义所需的 Tags 属性。
● 保护配置模板和标签修改权限。
设计理由
● 技术可行性：Service Catalog 和 CloudFormation 在创建资源时应用支持的标签。
● 需求匹配：成本分配和所有权元数据立即存在。
● 场景匹配：资源通过受管理的服务和基础设施模板进行配置。
● 工程常识：尽可能防止元数据丢失，然后对异常情况使用检测控制。
应排除的备选方案
● Systems Manager Automation 在创建后添加标签。
● AWS 生成的成本分配标签并不涵盖每个组织特定的要求。
● AWS Config 会检测缺失的标签，但不会在创建时添加它们。
● 手动标记不一致且难以审核。
工作流：用户选择目录产品或管道部署堆栈→应用标签→创建资源→合规性验证。
可搜索的 50 TB 文档平台
大型文档存档需要持久的对象存储、搜索索引、动态应用程序托管和可重复的基础设施。
推荐架构
● 在 AWS CloudFormation 中定义环境。
● 将 50 TB 文档集合存储在 Amazon S3 中。
● 在 Amazon CloudSearch 中为可搜索元数据和文本建立索引。
● 在 Amazon EC2 上托管动态网站。
设计理由
● 技术可行性：S3 存储大型对象集合，CloudSearch 处理查询，EC2 运行动态应用程序逻辑。
● 需求匹配：该设计可扩展，同时避免文档二进制文件的大型关系数据库。
● 场景匹配：用户搜索文档而不是处理实时流。
● 工程常识：将原始对象与可重建搜索索引分开。
应排除的备选方案
● S3静态网站托管无法替代动态应用。
● S3 不提供本机全文搜索。
● 对于 50 TB 的文档对象，RDS 成本高昂且不必要。
● Kinesis 是一种流服务，而不是持久文档存储或搜索索引。
工作流：上传文档→存储在S3→提取并索引元数据→查询CloudSearch→检索对象。
使用 AWS Config 监控批准的 AMI
AWS Config 可以根据批准的 AMI 列表评估正在运行的实例，并通知团队有关不合规的情况。
推荐架构
● 配置 approved-amis-by-id 托管规则。
● 提供授权的 AMI ID。
● 通过 SNS 发送违规通知。
● 通过批准的更换流程进行修复。
设计理由
● 技术可行性：Config 评估与运行的 EC2 实例关联的 AMI。
● 需求匹配：该组织可以获得持续的合规可见性，而不会阻止开发启动。
● 场景匹配：关注的是图像审批，而不是软件漏洞扫描。
● 工程常识：检测不良图像和扫描图像中的 CVE 是不同的控制。
应排除的备选方案
● Inspector 扫描的是漏洞，而不是已批准的 AMI 列表中的成员资格。
● 预防性 SCP 和 IAM 限制可能会阻碍开发。
● CloudWatch 本身并不评估已批准的 AMI。
● Trusted Advisor 没有直接批准的 AMI 合规性检查。
工作流：记录实例配置→配置规则评估AMI→不合规结果→SNS通知→替换。
托管 Windows 桌面和应用程序
托管虚拟桌面服务可以提供 Windows 访问，同时减少服务器维护和应用程序分发工作。
推荐架构
● 将 Amazon WorkSpaces 用于托管 Windows 桌面。
● 在适用的情况下，使用 Amazon WorkSpaces Application Manager 进行受控应用程序交付。
● 启用自动 Windows 更新和定义的维护时段。
● 集中应用目录、网络和访问控制。
设计理由
● 技术可行性：WorkSpaces 管理桌面基础设施，而 WAM 打包和分配应用程序。
● 需求匹配：用户获得管理程度较低的托管 Windows 环境。
● 场景匹配：需要的是安全的桌面访问，而不是 Web 开发环境或堡垒主机。
● 工程常识：将桌面服务用于桌面，并将管理跳转访问保留为单独的安全设计。
应排除的备选方案
● Lightsail 不是托管企业桌面解决方案，并且缺少所描述的操作系统升级工作流程。
● AppSync 是一项 GraphQL 服务。
● Cloud9 是一个开发环境，而不是一个强化的 Windows 桌面平台。
● AppStream 流式传输应用程序，但不是堡垒主机。
工作流：用户身份验证 → WorkSpaces 会话启动 → 交付分配的应用程序 → 维护期间应用更新。
PII 发现、存储生命周期和数据库可用性
照片共享服务需要单独控制敏感对象发现、存储成本优化和关系数据库停机时间。
推荐架构
● 使用 Amazon Macie 发现 S3 中的 PII 并对其进行分类。
● 应用 S3 生命周期规则，在访问下降时将旧照片转换为 S3 Standard-IA。
● 配置 RDS 数据库以进行多可用区部署。
设计理由
● 技术可行性：Macie 分析 S3 对象中的敏感数据，生命周期策略自动执行存储转换，RDS 多可用区提供托管备用故障转移。
● 需求匹配：该平台降低了存储成本，提高了数据库可用性，并获得了 PII 暴露的可见性。
● 场景匹配：用户照片驻留在 S3 中，而应用程序记录仍然相关。
● 工程常识：使用不同的服务来实现数据分类、对象生命周期和数据库高可用性。
应排除的备选方案
● Amazon Inspector 评估计算工作负载，并且不会对 S3 中的 PII 进行分类。
● 立即将每张新照片转移到 Standard-IA 可能会产生检索费用和最短持续时间费用。
● 当用户仍期望常规照片访问时，冰川不适合。
● Redshift 是一个分析仓库，而不是事务数据库的高可用性替代品。
● EBS 更改无法解决托管 RDS 停机问题。
工作流：上传照片 → Macie 评估敏感内容 → 生命周期转换老化对象 → RDS 在需要时自动故障转移。
ECS Fargate 的托管秘密注入
容器凭据应在运行时从专用秘密存储中检索，而不是嵌入到图像或任务定义文件中。
推荐架构
● 将数据库凭证存储在 AWS Secrets Manager 中。
● 使用 AWS KMS 加密密钥。
● 配置托管凭证轮换。
● 仅授予 ECS 任务执行角色所需的 Secret 和 KMS 权限。
● 在容器定义中引用秘密 ARN 以进行环境变量注入。
设计理由
● 技术可行性：ECS 可以在任务启动期间解析机密并将其值注入到容器环境中。
● 需求匹配：Secrets Manager 提供专门的生命周期管理和轮换，只需最少的定制工作。
● 场景匹配：工作负载已在 Fargate 上运行，因此无需进行平台迁移。
● 工程常识：将纯文本排除在源文件、S3 任务定义工件和容器映像之外。
应排除的备选方案
● Parameter Store SecureString 是可行的，但 Secrets Manager 更好地满足显式托管轮换要求。
● 迁移到 EKS 会增加 Kubernetes 管理，但不会改进此秘密工作流程。
● 对任务定义文件内的凭据进行加密会产生手动暴露和分发风险。
工作流：创建秘密 → 配置轮换 → 授予角色 → 引用 ARN → 部署任务 → 测试轮换。
多区域 ALB 的区域 ACM 证书
Application Load Balancer 及其附加的 ACM 证书是区域资源。
推荐架构
● 在每个应用区域请求或导入所需的证书。
● 验证每个完全限定域名。
● 将区域证书附加到同一区域中的应用程序负载均衡器。
● 使用基础设施即代码自动化证书和侦听器部署。
设计理由
● 技术可行性：仅当 ACM 证书存在于 ALB 的区域中时，ALB 才能使用该证书。
● 需求匹配：每个区域 HTTPS 端点都会继续提供受信任的证书。
● 场景匹配：该应用程序正在从一个区域扩展到多个独立的区域堆栈。
● 工程常识：将区域依赖性复制在一起，而不是假设一种区域资源是全球性的。
应排除的备选方案
● 在一个区域中创建的证书无法附加到其他区域中的 ALB。
● AWS KMS 管理加密密钥，但不颁发公共网站证书。
● 重复使用一个区域 ALB 证书并不提供区域独立性。
工作流：定义 FQDN → 请求每个区域的 ACM 证书 → 完成 DNS 验证 → 附加到区域 ALB 侦听器 → 测试 TLS → 将用户路由到区域端点。
具有直接连接的专用混合连接
从 VPC 到内部服务的私有、专用连接使用 Direct Connect 和支持 BGP 的客户路由。
推荐架构
● 配置 AWS Direct Connect。
● 配置所需的私有虚拟接口和 VPC 连接架构。
● 使用支持 BGP 的本地路由器。
● 根据需要为 BGP 会话配置 MD5 身份验证。
设计理由
● 技术可行性：Direct Connect 提供专用传输，BGP 动态交换路由。
● 需求匹配：该路径避免了对公共互联网带宽的依赖。
● 场景匹配：内部服务需要稳定的私有混合连接。
● 工程常识：当连接对业务至关重要时，添加冗余位置或 VPN 备份。
应排除的备选方案
● 互联网网关加 VPN 是加密的，但不是专用带宽。
● 中转 VPC 仍然依赖 VPN 传输。
● 弹性 IP 是公共寻址，而不是专用连接。
● 仅静态路由无法满足所需的 Direct Connect 路由会话。
工作流：本地路由器 → 通过 Direct Connect 的 BGP → 私有 VIF → AWS 网关 → VPC 路由。
通过 S3 REST API 使用 SSE-C
使用客户提供的密钥进行 S3 服务器端加密要求客户端在每个相关请求时发送加密密钥。
所需请求头
● x-amz-server-side-encryption-customer-algorithm
● x-amz-server-side-encryption-customer-key
● x-amz-server-side-encryption-customer-key-MD5
● 创建和使用预签名请求时包含所需的 SSE-C 信息。
设计理由
● 技术可行性：S3 使用提供的密钥来加密或解密对象，但不存储密钥。
● 需求匹配：当 S3 执行对象加密时，客户保留密钥保管权。
● 场景匹配：上传和下载通过 REST API 而不仅仅是控制台进行。
● 工程常识：丢失客户密钥会使对象无法恢复。
应排除的备选方案
● SSE-C 不仅限于 AWS 控制台。
● WebSocket Secure 保护 WebSocket 传输，与 S3 加密无关。
● 仅 MD5 标头是不够的，因为 S3 还需要算法和密钥。
● 通过不受保护的连接发送密钥是不安全的；使用 HTTPS。
工作流：客户端构建 HTTPS 请求 → 提供所有 SSE-C 标头 → S3 验证 MD5 → 加密或解密对象。
平滑智能电表写入 DynamoDB
写入吞吐量错误需要更多数据库容量或缓冲区，以在写入到达 DynamoDB 之前平滑突发。
推荐架构
● 增加或自动扩展 DynamoDB 写入容量。
● 通过 Amazon Kinesis 摄取仪表事件。
● 让 Lambda 使用者批量记录并将其写入 DynamoDB。
● 监视限制、迭代器寿命和消耗的容量。
设计理由
● 技术可行性：额外的容量消除了直接瓶颈； Kinesis 持久缓冲突发流量以控制消耗。
● 需求匹配：仪表事件继续到达，不会立即发生写入丢失。
● 场景匹配：设备产生具有突发吞吐量的大容量流。
● 工程常识：扩展受限资源并将生产者与下游写入速度分离。
应排除的备选方案
● 当处理已成功时，更多 Lambda 内存并不能解决 DynamoDB 限制问题。
● 除非业务需要并且会限制吞吐量，否则 FIFO 排序和重复数据删除是不必要的。
● 减少设备报告会改变产品行为，而不是修复摄取架构。
● 在没有缓冲的情况下重试可能会加剧限制。
工作流：计量事件 → Kinesis 分片 → Lambda 批处理 → DynamoDB 写入 → 根据观察到的需求扩展容量。
发现用于迁移的服务器 TCO
准确的迁移规模和总成本估算需要测量服务器配置、利用率和依赖性数据。
推荐架构
● 部署 AWS Application Discovery Service 代理或无代理收集器。
● 收集 CPU、内存、网络、进程和连接信息。
● 将相关服务器分组到应用程序中。
● 使用收集的利用率来调整 AWS 目标并估算 TCO。
设计理由
● 技术可行性：发现服务收集迁移规划所需的详细资产数据。
● 需求匹配：建议基于观察到的使用情况，而不是仅基于已安装的硬件。
● 场景匹配：该组织仍在迁移前评估其数据中心。
● 工程常识：根据代表性的使用周期和已知的业务高峰来确定合适的规模。
应排除的备选方案
● Migration Hub 跟踪进度，但不会独立收集所有详细的利用率数据。
● AWS SAM 构建无服务器应用程序。
● AWS MGN 复制服务器，并不是主要的发现和 TCO 服务。
● 手动电子表格很快就会变得陈旧，并且可能会丢失依赖项。
工作流：安装收集器→观察工作负载周期→检查依赖关系→对应用程序进行分组→调整目标大小→估计迁移业务案例。
使用文件网关进行低中断媒体编目
大型本地媒体存档可以采用云对象存储和托管面部识别，同时保留其现有的面向文件的工作流程。
推荐架构
● 在本地部署 AWS Storage Gateway 文件网关。
● 让媒体资产管理系统通过熟悉的文件接口写入文件。
● 将网关支持的对象存储在 Amazon S3 中。
● 使用 AWS Lambda 调用 Amazon Rekognition 进行媒体分析。
● 将提取的元数据返回到现有目录系统。
设计理由
● 技术可行性：文件网关公开 S3 支持的文件协议，Rekognition 处理支持的 S3 媒体对象。
● 需求匹配：该工作流程最大限度地减少中断和持续的基础设施管理。
● 场景匹配：现有工具需要文件，而长期方向是迁移到 AWS。
● 工程常识：先在现有接口集成，然后自动化云端处理。
应排除的备选方案
● Kinesis Video Streams 的目标是实时视频，而不是历史磁带存档。
● Rekognition 无法直接实时处理 Glacier 虚拟磁带。
● Snowball 可以移动大量数据，但自我管理的 EC2 面部识别软件增加了维护工作。
工作流：MAM 导出文件 → 文件网关存储在 S3 中 → 事件调用处理 → Rekognition 返回标签或面孔 → 元数据更新 MAM。
检测和删除未经批准的 AMI
敏捷的管道可以允许启动，同时自动识别和修复从未经授权的映像构建的实例。
推荐模式
● 使用 AWS Config 检测未经批准的 AMI ID，然后调用 Lambda 发出警报并终止不合规实例。
● 或者运行计划的 Lambda，检查实例 AMI ID、通知安全部门并终止未经授权的实例。
设计理由
● 技术可行性：EC2 公开源 AMI ID，Lambda 可以评估和终止实例。
● 需求匹配：CI/CD 不会被阻止，但未经授权的容量是短暂的。
● 场景匹配：该政策有利于侦查和纠正控制，而不是预防性否认。
● 工程常识：在终止前保留证据并保护批准的图像列表。
应排除的备选方案
● 手动审批会延迟交付。
● Amazon Inspector 会扫描漏洞，但不会决定 AMI 是否获得批准。
● 预防性 IAM 限制与不停止启动的要求相冲突。
● 没有补救措施的通知会使不合规的工作负载继续运行。
工作流：实例启动 → AMI 评估 → 合规实例仍然存在；不合规实例将被记录、发出警报并终止。
使用磁带网关的虚拟磁带档案
现有的磁带备份软件可以迁移到云支持的虚拟磁带，而无需改变其操作模型。
推荐架构
● 部署 Storage Gateway 磁带网关。
● 将虚拟磁带库呈现给现有的备份软件。
● 将活动虚拟磁带保留在 S3 支持的存储中。
● 将磁带弹出到虚拟磁带架以进行 Glacier 级存档。
设计理由
● 技术可行性：磁带网关模拟磁带库并与常见备份应用程序集成。
● 需求匹配：该公司保留了当前的工作流程，同时减少了物理磁带操作。
● 场景匹配：源进程已使用磁带备份语义。
● 工程常识：选择与备份软件所需接口相匹配的网关类型。
应排除的备选方案
● 虚拟磁带架是存档位置，而不是通用的 S3 时间点备份。
● 存储卷网关提供 iSCSI 块卷，而不是磁带模拟。
● 文件网关公开文件协议并且不模拟磁带库。
● 无需重写备份应用程序。
工作流：备份写入虚拟磁带→存储活动磁带→弹出→归档到虚拟磁带架→需要时检索。
保护支付字段并改进 CloudFront 缓存
传输加密可保护连接，而字段级加密可在选定的敏感值通过中间系统时对其进行保护。
推荐架构
● 要求从查看器到 CloudFront 使用 HTTPS。
● 需要从 CloudFront 到源的 HTTPS。
● 使用批准的公钥为信用卡字段配置 CloudFront 字段级加密。
● 为可以安全缓存的内容设置适当的 Cache-Control 指令。
设计理由
● 技术可行性：CloudFront 在转发选定的表单字段之前对其进行加密，并且只有私钥持有者才能解密它们。
● 需求匹配：卡数据在传输路径中始终受到保护，而较长的安全 TTL 则可提高缓存命中率。
● 场景匹配：该应用程序使用 CloudFront 并接受敏感付款信息。
● 工程常识：切勿仅仅为了提高性能而缓存个性化支付响应。
应排除的备选方案
● 签名 URL 控制访问，但不加密选定的付款字段。
● 自定义 TLS 证书可保护连接，但不提供字段级保护。
● 源访问身份保护 S3 源，而不是支付属性。
● 转发不必要的 User-Agent 或 Host 变体会导致缓存碎片并降低命中率。
工作流：HTTPS 请求 → CloudFront 加密敏感字段 → 源处理受保护的值 → 仅缓存批准的内容。
突发准备电视投票
实时投票平台需要全球交付、公共身份验证、持久突发缓冲和可扩展的投票存储。
推荐架构
● 在 ALB 和 EC2 Auto Scaling 组之前使用 CloudFront。
● 使用 Amazon Cognito 对查看者进行身份验证。
● 将提交的投票放入 Amazon SQS 中。
● 将排队投票处理到 DynamoDB 中。
设计理由
● 技术可行性：CloudFront 和 Auto Scaling 吸收观看流量，SQS 缓冲投票峰值，DynamoDB 扩展写入。
● 需求匹配：即使处理暂时滞后，选票也会被保留。
● 场景匹配：公众观众会产生短暂、极端的写入突发。
● 工程常识：将投票接受与计票脱钩。
应排除的备选方案
● S3静态托管无法运行动态投票服务。
● 通用 IAM 角色假设不是公共用户身份验证。
● SAML 针对的是劳动力联盟，而不是观众。
● RDS 与突发写入量保持紧密耦合。
● IAM 并不直接对数百万公共用户进行身份验证。
工作流：查看器 → CloudFront → Cognito → ALB 和应用程序 → SQS → 工作人员 → DynamoDB 结果。
重新构建托管应用程序和数据库服务平台
平台重构改变了托管平台，同时保留了应用程序的核心架构和行为。
推荐迁移方案
● 将关系数据库移至 Amazon RDS。
● 通过 AWS Elastic Beanstalk 部署应用程序。
● 保留应用程序逻辑和数据库语义。
● 用托管部署、扩展、备份和故障转移功能取代服务器管理。
设计理由
● 技术可行性：Elastic Beanstalk 运行受支持的应用程序堆栈，而 RDS 提供托管关系引擎。
● 需求匹配：该方法无需完全重新设计即可减少运营和成本。
● 场景匹配：该应用程序可以使用 AWS 管理的等效项，只需进行有限的代码更改。
● 工程常识：采用托管服务，直接替换现有层。
应排除的备选方案
● 重新托管会将服务器复制到 EC2 并保留大部分操作系统和数据库管理。
● 重构改变了应用程序架构和代码，超出了规定的需求。
● 重新购买会用不同的产品替换应用程序，并且可能无法保留所需的行为。
● 将这种方法称为重新托管忽略了向托管平台服务的运营转变。
工作流：评估兼容性 → 将数据库迁移到 RDS → 将应用程序部署到 Elastic Beanstalk → 测试 → 切换 → 退役源系统。
通过承担的角色进行第三方审计
外部审计师应获得仅限于所需审计行动的临时跨账户访问权限。
推荐架构
● 在审核账户中创建跨账户 IAM 角色。
● 信任审计员控制的 AWS 委托人。
● 附加只读、资源范围的权限。
● 需要 STS 角色承担并记录 CloudTrail 中的活动。
设计理由
● 技术可行性：STS 返回临时凭证，而不在审核帐户中创建永久用户。
● 需求匹配：访问权限是可撤销的、可归属的和最低权限的。
● 场景匹配：第三方需要临时审查权限。
● 工程常识：审计并不能证明不受限制的管理是合理的。
应排除的备选方案
● 完全访问违反了最低权限。
● 长期 IAM 用户密钥更难安全轮换和撤销。
● 即使有限的 IAM 用户密钥仍然不如临时角色会话。
● 共享现有员工凭证会破坏问责制。
工作流：审核员在家庭帐户中进行身份验证 → 承担审核角色 → 审查证据 → CloudTrail 记录会话 → 凭证过期。
使用 ACM 和 ALB 终止公共 HTTPS
Application Load Balancer 背后的公共网站可以使用受信任的 AWS Certificate Manager 证书来实现简单、低成本的 HTTPS。
推荐架构
● 请求大学域的公共 ACM 证书。
● 完成 DNS 验证。
● 将证书附加到 ALB HTTPS 侦听器。
● 将 HTTP 请求重定向到 HTTPS。
● 根据设计要求将解密的流量转发到应用程序目标。
设计理由
● 技术可行性：ALB 直接与 ACM 集成并执行 TLS 终止。
● 需求匹配：公共 ACM 证书受信任、受管理，并且不会增加证书费用。
● 场景匹配：学习系统已在 EC2 实例前面使用 ALB。
● 工程常识：除非明确需要端到端应用程序加密，否则在托管负载均衡器处终止 TLS。
应排除的备选方案
● 默认情况下，ACM 私有 CA 证书不受公开信任，并且会引入私有 CA 成本。
● 在每个 EC2 实例上安装证书会增加续订和部署工作。
● 自签名证书会触发浏览器信任失败。
● 购买并手动轮换第三方证书是可行的，但操作效率较低。
工作流：请求证书 → 验证域 → 配置 HTTPS 侦听器 → 重定向 HTTP → 测试信任和续订。
在死信隔离之前可靠的 SQS 重试
死信队列应该隔离重复失败的工作，而不是经历一个瞬时处理错误的消息。
推荐配置
● 使可见性超时时间比正常处理时间长。
● 将重新驱动策略 maxReceiveCount 从 1 增加到合理的重试值，例如 10。
● 继续对死信队列深度发出警报。
● 仅在正常重试次数耗尽后才调查消息。
设计理由
● 技术可行性：当处理失败或消息未删除时，SQS 会使其再次可见，直到达到接收阈值。
● 需求匹配：多次尝试可以在不改变工人队伍的情况下提高完成率。
● 场景匹配：视频通常会在 20 到 40 分钟内完成，低于一小时的可见超时时间。
● 工程常识：区分暂时的工作故障和永久无效的输入。
应排除的备选方案
● 维持更多空闲 EC2 容量并不能解决失败的消息处理问题。
● 将可见性延长至两小时会延迟重试，即使正常处理已在一小时内完成。
● 交付延迟会推迟首次可用性，并且在消费者失败后无济于事。
工作流：接收 → 处理期间隐藏 → 成功时删除 → 失败时重试 → 在阈值后移至 DLQ → 提醒开发人员。
使用 Aurora 全球数据库进行区域恢复
跨区域的低 RPO 和 RTO 需要持续复制的数据库和基于健康状况的流量移动。
推荐架构
● 将 Aurora Global Database 与主要区域和辅助集群结合使用。
● 在两个区域部署应用程序容量。
● 配置 Route 53 运行状况检查和故障转移路由。
● 测试管理的区域推广和应用程序重新连接。
设计理由
● 技术可行性：Aurora 以低延迟跨区域复制存储更改，并支持二次升级。
● 需求匹配：与快照恢复相比，该设计减少了数据丢失和恢复时间。
● 场景匹配：该应用程序需要两个区域的关系数据库。
● 工程常识：数据库恢复和应用程序流量故障转移必须一起测试。
应排除的备选方案
● RDS 多可用区仍位于一个区域内。
● 标准的跨区域只读副本可以工作，但 Aurora Global Database 更直接地实现快速区域恢复。
● 手动 EC2 快照恢复会增加操作和延迟。
● 没有现成应用程序容量的备份会延长 RTO。
工作流：主服务写入 → 全局复制 → 运行状况故障 → 升级辅助 → Route 53 将流量发送到恢复区域。
具有目标运行状况的主动-主动 DNS
公共用户可以通过 Route 53 路由到最低延迟的健康区域端点。
推荐架构
● 为区域弹性负载均衡器创建基于延迟的别名记录。
● 启用 Evaluate Target Health。
● 保持两个区域处于活动状态并能够处理请求。
● 监控应用程序和数据层的运行状况。
设计理由
● 技术可行性：Route 53 选择延迟较低的终端节点并从答案中删除不健康的别名目标。
● 需求匹配：该设计支持主动-主动区域流量和自动端点回避。
● 场景匹配：公共应用程序在多个区域的负载均衡器后面运行。
● 工程常识：DNS 健康路由仅在每个区域具有完整的应用程序依赖性时才起作用。
应排除的备选方案
● 私有托管区域无法路由公共用户。
● DNSSEC 保护 DNS 完整性，但不执行基于运行状况的故障转移。
● 禁用目标健康评估会削弱自动恢复。
● 中转 VPC 连接网络且不路由公共客户端。
工作流：DNS查询→延迟和健康评估→区域ELB答案→客户端连接→删除不健康的目标。
通过预留并发保护 Lambda 容量
高容量复制功能应具有明确的并发边界，因此它不能消耗所有区域 Lambda 容量。
推荐架构
● 配置复制功能的预留并发。
● 根据下游容量和所需吞吐量确定预留大小。
● 监控 Lambda Throttles、ConcurrentExecutions、持续时间和错误指标。
● 创建 CloudWatch 警报以进行持续限制。
设计理由
● 技术可行性：预留并发保证了函数的容量，并限制了其最大并发执行。
● 需求匹配：其他 Lambda 函数保留容量，同时复制负载保持受控。
● 场景匹配：一项功能可能会严重爆发并影响同一区域中不相关的工作负载。
● 工程常识：保护共享平台容量和较慢的下游系统。
应排除的备选方案
● 增加函数超时不会限制并发性。
● SQS 可以缓冲事件，但本身不会强制执行函数的区域并发共享。
● 重试退避可减少重复失败，但不能保证隔离容量耗尽。
● 预配置并发可提高启动准备情况，但不是直接请求的最大并发边界。
工作流：事件到达→并发分配检查→限制内调用→节流过量→持续压力报警→调整容量。
分阶段进行 Windows 修补以延长正常运行时间
大型 Windows 机群应按受控波次进行修补，以便维护不会立即消除所有服务容量。
推荐架构
● 使用标签将实例分为两个补丁组。
● 将批准的补丁基准与每个组相关联。
● 创建不重叠的 Systems Manager 维护时段。
● 在不同的开始时间针对每个组运行 AWS-RunPatchBaseline。
设计理由
● 技术可行性：补丁管理器识别、安装和报告批准的补丁；维护窗口控制执行时间。
● 需求匹配：单独的窗口可防止整个机队同时重新启动。
● 场景匹配：数百个生产实例需要可重复的自动化，而不是单独的维护。
● 工程常识：保持一个服务组可用，同时对另一个服务组进行修补和验证。
应排除的备选方案
● 一个补丁组和一个窗口可以一起重新启动整个队列。
● CloudWatch 调度加上自定义状态管理器命令是可能的，但是间接的且操作繁重。
● 没有分离窗口的设计无法控制破坏边界。
工作流：标记 → 组 → 基线 → 安排 A 组 → 验证 → 安排 B 组 → 审查合规性。
自动 RDS 密码轮换
Secrets Manager 可以通过本机 CloudFormation 资源生成、存储和轮换 RDS 密码。
推荐架构
● 在 Secrets Manager 中创建数据库机密。
● 让 CloudFormation 将密钥连接到 RDS。
● 定义每 90 天调用轮换 Lambda 的 RotationSchedule。
● 授予应用程序运行时检索机密的权限。
设计理由
● 技术可行性：Secrets Manager 协调密码更新和秘密值更改。
● 需求匹配：轮换是自动的，并且密码不会嵌入到模板中。
● 场景匹配：秘密是 RDS 数据库凭证。
● 工程常识：应用程序必须在轮换后刷新连接。
应排除的备选方案
● Parameter Store 没有等效的本机数据库 RotationSchedule 资源。
● KMS 密钥轮换会轮换加密密钥材料，而不是存储的数据库密码。
● EventBridge 加上自定义代码会重复本机轮换并增加风险。
● 硬编码凭证在轮换后就会变得陈旧。
工作流：生成密钥 → 部署 RDS → 轮换计划触发 Lambda → 密码更改 → 应用程序检索当前值。
使用 Systems Manager 进行自动化 EC2 救援
可以通过专门构建的 Systems Manager Automation Runbook 诊断受损的 Windows 或 Linux EC2 实例。
推荐流程
● 通过 Systems Manager Automation 运行 AWSSupport-ExecuteEC2Rescue。
● 提供受损的实例和所需的权限。
● 让工作流程收集诊断信息并应用支持的修复措施。
● 在将实例返回服务之前检查输出。
设计理由
● 技术可行性：EC2Rescue 自动执行常见访问和启动故障排除步骤。
● 需求匹配：恢复比手动修复更快、更一致。
● 场景匹配：问题是立即实例损害。
● 工程常识：在构建自定义修复自动化之前，请使用支持操作手册。
应排除的备选方案
● AWS Config 和 State Manager 不提供此救援工作流程。
● 维护窗口计划任务并且不需要立即修复。
● OpsWorks Chef Automate 添加了不相关的配置基础设施。
● 会话管理器可以提供访问权限，但本身不会诊断和修复问题。
工作流：启动自动化→根据需要创建帮助资源→诊断→修复→审查报告→验证实例。
具有只读角色的中央审计员帐户
外部审计访问应使用专用审计账户的临时跨账户角色。
推荐架构
● 创建专用审核员 AWS 账户。
● 在每个目标帐户中创建只读角色。
● 信任审计账户经批准的委托人。
● 需要 STS 角色承担并使用 CloudTrail 记录活动。
设计理由
● 技术可行性：STS 颁发每个目标角色范围内的临时凭证。
● 需求匹配：审核员通过可跟踪会话获得最低权限的访问权限。
● 场景匹配：必须一致地审查多个帐户。
● 工程常识：将审核员身份、权限和会话历史记录与操作用户分开。
应排除的备选方案
● 长期 IAM 用户密钥会增加轮换和暴露风险。
● 在每个帐户中创建目录标识会增加不必要的管理。
● 共享现有员工密码会破坏问责制。
● 一项广泛的管理员角色超出了审计需求。
工作流：审核员集中登录 → 承担目标只读角色 → 审查资源和日志 → 会话过期。
满足数百万用户偏好的安全存储
每个用户的小首选项是直接的键值工作负载，不应跨多个存储系统拆分。
推荐架构
● 在 Amazon DynamoDB 中为每个用户存储一项。
● 通过网络身份联合对社交用户进行身份验证。
● 使用STS临时凭证。
● 应用 DynamoDB 细粒度访问控制，以便每个用户只能访问允许的项目。
设计理由
● 技术可行性：DynamoDB 通过托管可用性和水平扩展来处理数百万条小记录。
● 需求匹配：该设计具有高可用性、经济高效、可扩展的特点，并且避免了长期的移动凭证。
● 场景匹配：每个首选项记录只有大约 4 KB，自然由用户 ID 寻址。
● 工程常识：在一个数据库中保留一个小的原子记录，除非第二个存储服务解决了真正的限制。
应排除的备选方案
● RDS 只读副本可以扩展读取，但数据库帐户对于数百万社交用户来说并不是一个实用的身份模型。
● 公共应用程序服务器加上 RDS 添加了服务器和连接管理。
● 将每个微小的首选项对象存储在 S3 中并将其指针存储在 DynamoDB 中会使请求和复杂性增加一倍。
工作流：社交登录→身份令牌→STS角色会话→项目级授权→读取或更新首选项。
无服务器订单和发货工作流程
物流工作流程需要持久的订单状态、明确的流程编排和事件驱动的发货更新。
推荐架构
● 在 Amazon DynamoDB 中存储订单和状态。
● 使用 AWS Step Functions 对处理步骤进行建模。
● 调用 Lambda 函数进行验证、状态更改和外部服务调用。
● 当货件扫描或递送事件到达时触发 Lambda 更新。
设计理由
● 技术可行性：Step Functions 管理状态、重试、分支和服务集成； DynamoDB 提供可扩展的订单记录。
● 需求匹配：该工作流是无服务器的、事件驱动的，并且运营开销较低。
● 场景匹配：订单经过定义的阶段，发货事件异步更新其状态。
● 工程常识：将持久的业务状态保存在数据库中，将工作流程进度保存在协调器中，而不是保存在计算内存中。
应排除的备选方案
● AWS Batch 专为批量计算而设计，而不是交互式订单状态编排。
● EFS 是文件存储，并不对工作流程状态进行建模。
● SQS 可以解耦步骤，但本身并不表示分支、重试和端到端状态。
● 通知服务不会取代交易订单存储。
工作流：创建订单 → 写入 DynamoDB 项目 → 启动状态机 → 执行步骤 → 接收发货事件 → Lambda 更新状态。
安全的第三方跨账户访问
第三方访问应使用临时角色凭据和外部 ID，以减少混淆代理风险。
推荐架构
● 在资源拥有账户中创建 IAM 角色。
● 仅授予所需的资源操作。
● 在角色信任策略中信任提供商的 AWS 账户。
● 需要客户提供唯一的外部 ID。
● 让提供商调用 STS AssumeRole。
设计理由
● 技术可行性：仅当可信主体和外部 ID 条件匹配时，STS 才会颁发临时凭证。
● 需求匹配：如果没有客户创建的长期用户，提供商将获得有限的、可撤销的访问权限。
● 场景匹配：外部组织管理多个客户的资源。
● 工程常识：将权限放入客户帐户中并需要客户特定的信任信号。
应排除的备选方案
● IAM 用户创建长期凭证并难以退出。
● 仅信任提供者帐户可能会将角色暴露于混乱的副场景中。
● 资源策略不提供一般的多服务管理。
● 通过 Secrets Manager 共享访问密钥不会将其转换为临时会话。
工作流：提供者使用外部 ID 请求角色 → 信任策略评估 → STS 返回临时凭证 → 发生范围内的操作。
在 API 网关阻止 SQL 注入
应在托管 API 入口点过滤注入攻击，同时应记录防火墙配置更改以供审核。
推荐架构
● 将 AWS WAF Web ACL 与 Amazon API Gateway 关联。
● 启用检测 SQL 注入模式的托管或自定义规则。
● 使用 AWS Config 记录 Web ACL、规则和配置更改。
● 查看 WAF 指标和阻止的请求日志。
设计理由
● 技术可行性：AWS WAF 与 API Gateway 集成，并在后端调用之前检查 HTTP 请求。
● 需求匹配：该解决方案可阻止已展示的攻击模式，并以低成本提供历史配置跟踪。
● 场景匹配：该应用程序已使用 API Gateway 和 Lambda，因此不需要新的负载平衡层。
● 工程常识：阻止攻击类别而不是观察到的某一源 IP。
应排除的备选方案
● API 网关无法按照建议的方式放置在 ALB 后面。
● WAF 不直接附加到各个 Lambda 函数。
● 防火墙管理器集中策略管理，但不是所请求的配置历史记录器。
● VPC 网络 ACL 不会保护托管 API 网关终端节点免受 SQL 注入内容的影响。
工作流：请求→WAF检查→API网关→Lambda→数据层；配置记录策略更改。
补丁执行和批准的 AMI 监控
安全补丁和 AMI 合规性是单独的控制：一个更改实例状态，另一个检测配置偏差。
推荐架构
● 使用 Systems Manager 补丁管理器基线定义已批准的 Windows 补丁。
● 跨托管实例安排或运行补丁操作。
● 使用 AWS Config 托管规则来评估正在运行的 EC2 实例是否使用批准的 AMI。
● 当检测到不合规实例时发送通知。
设计理由
● 技术可行性：补丁管理器安装批准的更新； AWS Config 评估资源配置而不阻止启动。
● 需求匹配：实例会收到最新的安全修复程序，并且开发人员在报告违规行为时仍可以自由启动。
● 场景匹配：该组织希望对 AMI 选择进行监控，而不是预防性拒绝。
● 工程常识：仅当阻塞可接受时才使用预防性控制措施；否则迅速检测并通知。
应排除的备选方案
● GuardDuty 检测可疑行为，而不是修补程序或批准的 AMI 合规性。
● IAM 拒绝会阻碍开发人员，违反操作要求。
● Shield Advanced 可防御 DDoS 攻击，并且不会修补操作系统或评估 AMI。
工作流：批准补丁 → 部署补丁 → 评估 AMI ID → 标记合规性 → 通知 → 通过受控更换流程进行修复。
使用 NAT 网关替换 NAT 实例
私有子网需要可靠的出站互联网访问，而无需维护自定义 NAT 服务器群。
推荐架构
● 在公有子网中创建 NAT 网关。
● 关联弹性IP地址。
● 确保公有子网路由到 Internet 网关。
● 将私有子网默认路由指向 NAT 网关。
● 当需要 AZ 独立性时，每个可用区使用一个 NAT 网关。
设计理由
● 技术可行性：NAT 网关对出站连接和返回流量执行托管源转换。
● 需求匹配：与 NAT 实例相比，它提供更高的可用性和带宽，并且管理更少。
● 场景匹配：现有的 NAT 实例不可靠并且限制了吞吐量。
● 工程常识：保留没有公共 IP 的私有工作负载，并将面向互联网的出口放置在公共子网中。
应排除的备选方案
● 增加 NAT 实例大小可以保留修补和故障转移责任。
● 私有子网中的 NAT 网关无法到达 Internet 网关。
● Internet 网关路由不会使私有地址实例可以直接通过 Internet 访问。
● VPC 对等互连不提供互联网出口。
工作流：私有实例 → 默认路由 → NAT 网关 → 互联网网关 → 目的地 → 通过 NAT 返回。
边缘设备特定的静态内容
静态内容可以在全球范围内交付，而边缘逻辑则为每种设备类型选择适当的版本。
推荐架构
● 将静态资产移动到 Amazon S3。
● 将存储桶配置为 CloudFront 源。
● 使用 Lambda@Edge 检查查看器的 User-Agent 标头。
● 重写或路由请求到正确的设备特定对象。
● 在边缘缓存所选响应。
设计理由
● 技术可行性：Lambda@Edge 在 CloudFront 请求处理期间运行，并且可以根据标头更改请求的 URI。
● 需求匹配：在用户附近选择内容并进行缓存，从而减少 EC2 负载和响应时间。
● 场景匹配：该应用程序为不同的设备类别提供不同的静态资源。
● 工程常识：将静态路由决策移至内容交付层，而不是扩展通用服务器。
应排除的备选方案
● 网络负载均衡器在第 4 层运行，无法检查 User-Agent。
● Route 53 路由 DNS 查询，无法评估 HTTP 标头。
● 简单的 CloudFront 缓存行为无法在没有边缘逻辑的情况下对任意设备标头进行分类。
● 将所有静态内容保留在 EC2 上可以保留原始负载问题。
工作流：请求 → 边缘读取标头 → URI 重写 → S3 对象 → 缓存的设备特定响应。
移动内容的托管 REST 后端
移动 REST 服务应使用托管身份验证、无服务器 API、可扩展元数据存储和直接对象上传。
推荐架构
● 将 Amazon API Gateway 与 AWS Lambda 结合使用。
● 使用 Amazon Cognito 对用户进行身份验证。
● 将应用程序元数据存储在 DynamoDB 中。
● 将文件存储在 Amazon S3 中。
● 发布预签名的 S3 URL 以进行授权上传和下载。
设计理由
● 技术可行性：API Gateway 调用 Lambda，Cognito 提供身份，DynamoDB 扩展记录，预签名 URL 提供限时对象访问。
● 需求匹配：该设计无需管理服务器或通过 Lambda 代理大型对象即可扩展。
● 场景匹配：REST 操作在用户交换文件时管理元数据。
● 工程常识：在 S3 上保持大量有效负载传输，并使 API 功能专注于授权和业务逻辑。
应排除的备选方案
● EC2 Web 队列增加了修补和扩展工作。
● 在 DynamoDB 中存储大文件既昂贵又不必要。
● 在移动应用程序中嵌入永久 AWS 密钥是不安全的。
● 通过 Lambda 路由所有文件字节会增加延迟、成本和运行时限制。
工作流：用户身份验证 → API 授权请求 → Lambda 创建预签名 URL → 客户端将对象直接传输到 S3。
成本优化的分析和持续报告
可中断分析和持续可用的报告具有不同的计算要求。
推荐架构
● 在基于 EC2 Spot 的 Auto Scaling 组上运行大型分析作业。
● 设计具有检查点和重试支持的作业。
● 在 Amazon ECS Fargate 上运行持续报告服务。
● 独立缩放每个组件。
设计理由
● 技术可行性：Spot 为可重新启动的处理提供折扣计算，而 Fargate 则运行长期存在的容器，无需服务器管理。
● 需求匹配：Spot 节省了大约 10,000 个分析计算小时，同时报告仍然持续可用。
● 场景匹配：分析是面向批量的，但报告服务于持续的用户请求。
● 工程常识：不要对必须始终响应的组件使用可中断容量。
应排除的备选方案
● 所有按需容量都是可行的，但对于容错分析来说成本过高。
● 当分析需求变化且承诺不确定时，预留容量效率低下。
● 使用 Spot 进行报告服务可能会导致明显的中断。
● App Runner 可以托管 Web 服务，但它不会提高分析层的批量计算经济性。
工作流：提交分析工作 → 扩展 Spot 工作人员 → 保存结果 → 报告容器读取结果 → Fargate 扩展服务需求。
基于位置的移动优惠
较短的交付窗口需要持久的位置缓冲、快速报价查找、可扩展处理和托管移动推送。
推荐架构
● 在 SQS 中缓冲传入位置。
● 根据待办事项扩展 API 或工作实例。
● 在 DynamoDB 中存储商品。
● 通过 SNS 移动推送发送选定的优惠。
设计理由
● 技术可行性：SQS吸收突发，DynamoDB提供低延迟查找，SNS达到移动推送服务。
● 需求匹配：可以在短时间内选择并交付附近的报价。
● 场景匹配：数以百万计的移动位置可能会不定期到达。
● 工程常识：将位置接收与推送传送分开。
应排除的备选方案
● Kinesis 和 SES 不形成直接的移动推送工作流程。
● 直接连接到移动运营商并不是设备 GPS 或平台推送的工作方式。
● EC2 无法直接替代托管移动推送通道。
● 没有队列的同步处理存在丢弃事件的风险。
工作流：设备位置 → SQS → 工作人员查询 DynamoDB → SNS 移动推送 → 电话通知。
提供大型预测数据集
服务器群共享的大型预测输出可以使用 EFS、弹性查询服务器和短 CloudFront 缓存。
推荐架构
● 将生成的 20 GB 预测存储在 EFS 上。
● 在 ELB 后面的 Auto Scaling 组中运行查询服务器。
● 在 CloudFront 中缓存响应 15 分钟。
设计理由
● 技术可行性：EFS 为所有服务器提供共享文件访问，Auto Scaling 处理并发，CloudFront 吸收重复查询。
● 需求匹配：该设计支持 1,500 至 15,000 个并发用户和频繁的数据集替换。
● 场景匹配：每 15 分钟更换一次大型预报。
● 工程常识：避免在索引获得其成本之前对完全重新生成的数据建立索引。
应排除的备选方案
● OpenSearch 每 15 分钟索引 10 亿个点是昂贵的。
● 更改边缘逻辑并不能修复低效的索引工作流程。
● 每次更新创建 10 亿个 S3 对象会产生极大的对象和请求开销。
● 一台固定查询服务器无法安全地处理该范围。
工作流：写入 EFS 的预测 → 弹性服务器对其进行查询 → CloudFront 缓存响应 15 分钟。
两区域关系应用程序弹性
读取密集型应用程序可以使用一个高度可用的写入器区域和辅助区域读取器，同时保持应用程序层在两个区域中处于活动状态。
推荐架构
● 在两个区域中部署 Auto Scaling 应用程序层。
● 使用 Amazon Aurora 全球数据库。
● 将写入保留在主区域中，并使用区域内端点进行读取。
● 按地理位置路由用户，并将经过运行状况检查的故障转移配置到运行状况良好的区域。
设计理由
● 技术可行性：Aurora 全球数据库通过一名主要写入者和区域读取者跨区域复制关系数据。
● 需求匹配：区域应用程序群提供弹性，而数据库保留关系语义。
● 场景匹配：北美和亚洲用户受益于区域读取和受控故障转移。
● 工程常识：除非明确设计了冲突解决方案，否则应避免使用两个独立的可写数据库。
应排除的备选方案
● 独立可写的RDS MySQL数据库并不能通过简单的复制成为安全的双活主。
● 多可用区可以防止可用区故障，而不是整个区域故障。
● 快照是恢复工件，而不是活动的区域读取解决方案。
● 多值路由可能会返回多个健康端点，而不是实施预期的区域故障转移策略。
工作流：写入主 → 全局复制 → 本地读取 → 监控运行状况 → 将流量故障转移到幸存区域。
扩展受许可证限制的 EC2 应用程序
获得网络接口身份许可的应用程序需要一个受控的可重用 ENI 池和集中分配的许可证文件。
推荐架构
● 维护一个 ENI 池，以保留许可证绑定的身份。
● 将许可证文件安全地存储在 S3 中。
● 使用引导逻辑在横向扩展期间分配一个未使用的 ENI 和许可证。
● 使用 Lambda 维护 Parameter Store 中的当前数据库地址。
● 在实例引导期间检索当前地址。
设计理由
● 技术可行性：ENI 在实例替换过程中保留网络身份，而参数存储将更改的配置与映像分开。
● 需求匹配：机群可扩展，无需复制许可证或烘焙过时的数据库地址。
● 场景匹配：许可与 ENI 身份相关联。
● 工程常识：以原子方式协调分配，以便两个实例无法申请同一个许可证。
应排除的备选方案
● 具有一个许可证的一个 AMI 无法安全扩展。
● 在启动时解析 DNS 仍然会留下陈旧的本地地址。
● 将每个许可证烘焙到 AMI 中都有重复使用的风险。
● 地址更改后静态数据库 IP 会失败。
工作流：横向扩展 → 申请 ENI 和许可证 → 读取参数存储 → 配置应用程序 → 终止时释放资产。
全球游戏 API 的长期成本优化
可预测的多年应用程序可以将承诺的计算定价与静态资产的边缘交付结合起来。
推荐架构
● 在适当大小的 EC2 实例上运行 GraphQL API。
● 预期三年内稳定基线的购买保留定价。
● 将 API 队列放置在合适的负载均衡器后面。
● 将静态资产存储在持久的原始存储中，并通过 CloudFront 分发它们。
设计理由
● 技术可行性：EC2 支持现有的 API 运行时，CloudFront 提供来自全球边缘位置的缓存资产。
● 需求匹配：预留定价降低了长期基准成本，而边缘缓存则提高了全球响应能力。
● 场景匹配：服务预期寿命超过三年，核心需求稳定。
● 工程常识：仅提交可预测的基线并保持突发容量的灵活性。
应排除的备选方案
● 所有按需容量都忽略了较长的、可预测的服务寿命。
● 直接从 API 服务器提供静态文件会浪费计算和带宽。
● 仅现货 API 容量存在客户可见的中断风险。
● 如果当前的 API 架构能够满足功能需求，则无需重新平台化至不相关的服务。
工作流：客户端 → 资产的 CloudFront → GraphQL 的负载均衡器 → 预留基线 EC2 → 根据需要扩展额外容量。
发布 S3 静态网站
S3 网站端点必须能够读取网站对象。 DNS 路由本身并不授予对象访问权限。
推荐配置
● 在正确命名的 S3 存储桶上启用静态网站托管。
● 配置索引文档。
● 将 Route 53 别名记录指向区域 S3 网站终端节点。
● 通过所需的存储桶策略和公共访问设置，允许对网站对象进行公共读取访问。
设计理由
● 技术可行性：当存储桶授权允许匿名读取时，网站端点将提供配置的索引对象。
● 需求匹配：访问者可以通过自定义域检索公共网站内容。
● 场景匹配：该网站有意公开并直接从 S3 网站端点托管。
● 工程常识：检查完整的请求链：DNS 解析、端点选择、存储桶策略、公共访问块和对象存在。
应排除的备选方案
● 自定义错误文档是可选的，并且不控制索引的可用性。
● 配置索引文档时，访问者不需要附加index.html。
● Route 53 传播通常很快，等待并不能修复授权失败。
工作流：解析域名→到达网站端点→评估存储桶访问→返回索引对象和引用的资产。
使用流量镜像捕获完整数据包
需要数据包有效负载的安全分析需要完整的数据包副本，而不是连接元数据。
推荐架构
● 在选定的 EC2 弹性网络接口上启用 VPC 流量镜像。
● 将镜像流量发送到检查设备或支持的监控目标。
● 过滤会话以仅捕获所需的协议和源。
设计理由
● 技术可行性：流量镜像从 ENI 复制数据包标头和有效负载。
● 需求匹配：分析师可以检查完整的网络对话。
● 场景匹配：该要求涵盖 HTTP 请求之外的实例网络流量。
● 工程常识：限制捕获范围，因为完整的数据包会消耗带宽并且可能包含敏感数据。
应排除的备选方案
● VPC 流日志包含地址、端口、操作和元数据，而不是负载。
● ALB 访问日志包含请求元数据而不是完整的数据包。
● AppFlow 不是数据包分析目标。
● WAF 日志描述了检查的 Web 请求，但不捕获所有实例流量。
工作流：实例 ENI → 镜像会话和过滤器 → 镜像目标 → 数据包检查 → 安全证据保留。
使用两个缓存层改善页面负载
CloudFront 和 ElastiCache 解决不同的性能问题，可以一起使用。
推荐架构
● 在 CloudFront 中缓存可重用的网站内容。
● 将会话和经常访问的查询结果存储在 ElastiCache 中。
● 将 EC2 Auto Scaling 和 RDS 保留为权威的计算和数据层。
设计理由
● 技术可行性：CloudFront 减少了网络距离和源请求； ElastiCache 减少后端数据库读取。
● 需求匹配：无需部署第二个区域即可改善页面响应。
● 场景匹配：该应用程序提供可缓存的内容和动态会话或查询。
● 工程常识：测量缓存命中率并避免错误地缓存个性化响应。
应排除的备选方案
● 状态管理器配置实例，不会取代 Auto Scaling。
● 降低缩放触发器会增加计算量，但不会消除重复工作。
● 第二个区域引入了成本和数据管理的复杂性。
● 数据库扩展本身并不能改善全局静态交付。
工作流：查看器 → CloudFront → 应用程序未命中 → ElastiCache → RDS 缓存未命中。
将物联网数据流式传输到分析仓库
物联网遥测需要托管流传输、持久保留、归档生命周期和转型的仓库分析。
推荐架构
● 使用 Kinesis Data Firehose 摄取记录。
● 将原始数据传送到 S3。
● 使用生命周期策略将旧数据存档到 Glacier 类。
● 使用 EMR 处理数据并将整理的结果加载到 Redshift 中。
设计理由
● 技术可行性：Firehose 缓冲并传输流，S3 持久存储流，EMR 和 Redshift 支持分析。
● 需求匹配：该管道处理连续事件和长期成本控制。
● 场景匹配：设备发出持续的流。
● 工程常识：保留原始数据，以便可以重播转换。
应排除的备选方案
● 直接 S3 摄取缺乏托管流缓冲区。
● Athena 不接受流事件或将它们存储在 DynamoDB 中。
● DynamoDB 和 Data Pipeline 增加了写入成本和计划编排。
● Glacier 是存档目标，而不是摄取层。
工作流：设备流 → Firehose → S3 原始区域 → 生命周期存档 → EMR 转换 → Redshift 分析。
解决 CloudFormation 中的当前 AMI
CloudFormation 可以解析包含当前 AMI ID 的 AWS 管理的公共 Systems Manager 参数。
推荐架构
● 在模板中引用适当的公共 SSM AMI 参数。
● 在堆栈创建或更新期间解决它。
● 当车队应该采用更新的映像时，有意运行 update-stack 。
● 使用受控滚动更新策略。
设计理由
● 技术可行性：CloudFormation 参数类型可以解析 Parameter Store 中的当前 AMI 标识符。
● 需求匹配：模板避免硬编码区域 AMI ID。
● 场景匹配：该组织希望通过有意的堆栈更新来获得最新的 AWS 映像。
● 工程常识：最新并不意味着未经测试；在生产推出之前验证图像。
应排除的备选方案
● 服务目录分发产品，但本身并不解析每个最新的 AMI。
● AWS Config 评估合规性，不是 AMI 查找服务。
● 状态管理器维护实例配置，不是 CloudFormation AMI 参数源。
● 在堆栈更新之前，现有实例不会更改。
工作流：模板解析SSM参数→启动模板更改→滚动堆栈更新→健康验证。
改善边缘的全局登录延迟
通过在用户附近执行适当的请求逻辑并为服务器错误提供源故障转移，可以提高全局身份验证性能。
推荐架构
● 使用 Lambda@Edge 进行与身份验证相关的处理，该处理可以安全地在 CloudFront 边缘站点执行。
● 配置具有主要源和辅助源的 CloudFront 源组。
● 当主服务器返回选定的错误（包括相关网关故障）时进行故障转移。
设计理由
● 技术可行性：Lambda@Edge 在 CloudFront 请求或响应事件期间运行；源故障转移将符合条件的请求重定向到备份源。
● 需求匹配：该组合减少了与距离相关的登录延迟，并限制了 HTTP 504 失败的影响，且成本低于完全全局复制。
● 场景匹配：该应用程序已经是无服务器的，并为全球用户提供服务。
● 工程常识：仅移动合适的边缘逻辑，并保留需要权威后端状态的操作的起源。
应排除的备选方案
● 多个VPC和中转VPC不会直接加速身份验证。
● 完整的多区域应用程序部署可以工作，但成本更高。
● 增加缓存 TTL 有助于静态对象，而不是减慢动态登录处理速度，并且通常不应广泛缓存身份验证响应。
工作流：查看器请求→边缘身份验证步骤→主要来源→配置错误时自动故障转移。
具有渐进式 Lambda 部署的无服务器 CI/CD
无服务器交付管道应该对应用程序进行建模、构建和测试工件、编排发布以及安全地转移生产流量。
推荐架构
● 使用 AWS SAM 定义 Lambda、API Gateway、DynamoDB 和相关权限。
● 使用 CodeBuild 安装依赖项、运行测试和打包工件。
● 使用 CodePipeline 协调源代码、构建、批准和部署阶段。
● 使用 CodeDeploy 部署首选项逐步进行 Lambda 流量转移和回滚。
设计理由
● 技术可行性：SAM 转换为 CloudFormation，而 CodeDeploy 可以使用 Lambda 别名进行金丝雀或线性部署。
● 需求匹配：该管道自动构建和发布，同时限制生产影响。
● 场景匹配：新的架构完全是无服务器的。
● 工程常识：将基础架构和应用程序部署的版本保持在一起，并在失败警报时自动回滚。
应排除的备选方案
● 无服务器应用程序存储库分发可重用的应用程序，但不是完整的 CI/CD 管道。
● OpsWorks 不是 Lambda、API Gateway 和 DynamoDB 的天然配置服务。
● 构建代码或转移 Lambda 别名流量不需要 Systems Manager Automation。
工作流：提交→构建和测试→打包→部署堆栈→转移别名流量→监控→完成或回滚。
EC2 上的 Oracle RAC 备份
Oracle RAC 必须保留在 EC2 上，因为 Amazon RDS for Oracle 不提供 RAC。
推荐架构
● 在 EC2 上运行支持的 Oracle RAC 集群。
● 将数据库卷存储在所需的 EBS 架构上。
● 使用 Amazon Data Lifecycle Manager 进行计划的 EBS 快照。
● 协调崩溃一致或应用程序一致的备份过程。
设计理由
● 技术可行性：EC2 保留 RAC 控制，而 DLM 自动化可重复的快照策略。
● 需求匹配：该设计在不改变数据库架构的情况下减少了备份管理。
● 场景匹配：RAC 兼容性是强制性的。
● 工程常识：快照编排必须考虑所有集群卷和数据库的一致性。
应排除的备选方案
● RDS Oracle RAC 不是受支持的服务配置。
● RDS 多可用区不会将 RDS 转变为 RAC。
● 手动 shell 快照很脆弱且难以审核。
● 迁移到另一个引擎会扩大范围，并可能会破坏应用程序兼容性。
工作流：停顿或协调数据库 → DLM 快照策略 → 验证所有卷 → 测试恢复 → 按策略保留。
自动化混合补丁管理
混合资产可以对 EC2 和注册的本地服务器使用一个 Systems Manager 补丁工作流程。
推荐架构
● 在符合条件的服务器上安装并注册 SSM 代理。
● 在 Systems Manager 补丁管理器中定义批准的补丁基准。
● 使用标签或补丁组属性对服务器进行分组。
● 使用维护时段来安排 AWS-RunPatchBaseline。
● 集中审查补丁合规性。
设计理由
● 技术可行性：Systems Manager 通过代理管理 EC2 实例和混合激活的服务器。
● 需求匹配：基线和时间表保持同步和自动化，操作工作量很少。
● 场景匹配：该组织已经在本地和云服务器上维护补丁策略。
● 工程常识：在提高自动化频率之前标准化政策和报告。
应排除的备选方案
● 单独的 cron 脚本会创建不同的补丁逻辑和报告。
● 重建每个服务器映像不会直接修补长期存在的本地计算机。
● AWS Config 记录配置但不安装操作系统补丁。
● 手动控制台修补无法扩展或证明一致性。
工作流：注册服务器→分配补丁组→评估基线→在维护时段运行→按配置重新启动→报告合规性。
可扩展的媒体网站和成本审查
动态媒体站点应将持久媒体交付与弹性应用程序处理分开，并使用本机成本分析服务。
推荐架构
● 将媒体存储在 S3 中并通过 CloudFront 传送。
● 在 ELB 后面的 Auto Scaling 中运行动态 Web 服务器。
● 使用 Cost Explorer 和 Trusted Advisor 来确定节省的成本。
设计理由
● 技术可行性：S3 和 CloudFront 扩展媒体交付，而 Auto Scaling 处理可变的服务器端流量。
● 需求匹配：该设计提高了性能、弹性和成本可见性。
● 场景匹配：该应用程序包含静态媒体和服务器端逻辑。
● 工程常识：不要通过应用程序服务器路由大量媒体。
应排除的备选方案
● CloudFront 无法直接使用 EFS 作为源。
● 当媒体移动到 S3 时，不需要存储优化的 Web 实例。
● 合并账单汇总费用，但不是成本分析工具。
● 完全静态的 S3 站点无法执行服务器端处理。
● 跨区域复制会增加不必要的成本。
工作流：静态媒体 → CloudFront 和 S3；动态请求→ELB和Auto Scaling；成本 → 探索者和顾问。
为不常用的 Oracle 数据提供经济高效的存储
历史数据库数据量大、访问频率低且以吞吐量为导向，不需要高级 SSD 性能。
推荐架构
● 使用 AWS Database Migration Service 移动 Oracle 工作负载或数据。
● 当数据库保留在 EC2 上时，将不经常访问的历史数据放置在 EBS sc1 冷 HDD 卷上。
● 验证工作负载不需要启动卷支持或高随机 IOPS。
设计理由
● 技术可行性：DMS 迁移数据库记录，而 sc1 为大型连续工作负载提供低成本 HDD 存储。
● 需求匹配：该设计最大限度地减少了冷历史数据的存储费用。
● 场景匹配：访问不频繁，吞吐量比低延迟随机 I/O 更重要。
● 工程常识：根据实际访问模式而不是最大可能的性能来选择存储。
应排除的备选方案
● 服务器迁移服务移动服务器而不是提供数据库迁移工作流程。
● gp2 SSD 成本更高，并且针对通用随机 I/O。
● st1 吞吐量优化 HDD 适合频繁访问的吞吐量工作负载，且成本高于 sc1。
● 对于冷历史记录，不需要配置 IOPS SSD。
工作流：评估 I/O → 使用 DMS 迁移 → 连接并格式化 sc1 → 验证吞吐量 → 监控访问模式。
具有 STS 凭证的 LDAP 联合
LDAP 对企业用户进行身份验证，而 IAM 角色和 STS 则授权对 AWS 资源的临时访问。
推荐模式
● 让应用程序根据 LDAP 验证凭证、将用户映射到 IAM 角色并调用 STS。
● 或者使用执行 LDAP 身份验证并请求范围内联合凭据的自定义身份代理。
设计理由
● 技术可行性：在受信任的应用程序或代理验证身份后，STS 会颁发临时角色凭据。
● 需求匹配：用户保留公司凭证，无需永久 IAM 用户。
● 场景匹配：该应用程序已经依赖于 LDAP。
● 工程常识：将身份验证与 AWS 授权分开并保持会话短暂。
应排除的备选方案
● STS 不直接验证 LDAP 密码。
● IAM 本身无法验证公司 LDAP 用户名和密码。
● 长期访问密钥会重复身份生命周期并增加凭证暴露。
● 网络连接本身并不能提供联合。
工作流：用户登录 → LDAP 验证 → 角色映射 → STS 请求 → 临时凭证 → 签名的 AWS 请求。
附属账户的集中治理
一个 AWS 组织可以集中子公司账单并通过组织单位应用服务限制。
推荐架构
● 将所有子公司置于一个 AWS 组织中。
● 根据治理需要将帐户分组到 OU。
● 附加服务控制策略以定义最大服务和操作。
● 使用合并计费进行集中成本管理。
设计理由
● 技术可行性：SCP 限制成员帐户权限，而合并计费则汇总费用。
● 需求匹配：母公司集中管理服务边界和成本。
● 场景匹配：子公司仍保留独立的 AWS 账户。
● 工程常识：SCP 设置护栏；帐户 IAM 仍授予实际权限。
应排除的备选方案
● 单独的合并计费不会施加服务限制。
● 一个帐户不能属于多个组织。
● 每个子公司都有一个独立的组织，避免了单一的母公司治理层次结构。
● 服务配额限制数量，而不是允许哪些 API 或服务。
工作流：邀请账户 → 安排 OU → 附加 SCP → 配置账户 IAM → 审查综合成本。
私有跨 VPC 连接和拒绝流量监控
同区域 VPC 可以通过对等互连进行私密通信，而流日志则记录接受和拒绝的流量。
推荐架构
● 将每个部门 VPC 与中央应用程序 VPC 对等。
● 添加所需的路由和安全规则。
● 启用 VPC 流日志以捕获拒绝的记录和源地址。
● 将日志传送到 CloudWatch Logs。
● 使用日志订阅将记录转发到安全帐户。
设计理由
● 技术可行性：对等互连通过 AWS 网络路由流量，无需公共 Internet；流日志记录网络接口流量决策。
● 需求匹配：该设计提供私人通信和对被拒绝请求的可见性。
● 场景匹配：VPC 位于一个区域并需要访问一项中央服务。
● 工程常识：在引入无法解决任何指定问题的加密设备或外部电路之前，请使用直接 AWS 网络。
应排除的备选方案
● 单独的 IPsec 隧道添加网关和路由操作。
● 第三方中转 VPC 过多，AWS Config 不记录数据包拒绝。
● Direct Connect 将外部网络连接到 AWS；它不是 VPC 到 VPC 服务。
工作流：部门VPC→对等路由→中心服务；被拒绝的流 → 流日志 → CloudWatch → 安全订阅。
跨账户资源策略和持续审计
当权限直接附加到支持基于资源的策略的资源时，跨账户共享是最简单的。
推荐架构
● 将批准的外部帐户主体添加到 S3、KMS 和 OpenSearch 资源策略。
● 将操作、资源和条件限制到所需的访问路径。
● 使用 AWS Config 记录配置更改并评估合规性。
设计理由
● 技术可行性：资源策略可以信任来自另一个 AWS 账户的委托人。
● 需求匹配：外部用户保留其正常的身份权限，不需要用此访问模型的角色会话替换它们。
● 场景匹配：命名服务支持资源级策略控制。
● 工程常识：定义共享资源的共享边界并不断验证。
应排除的备选方案
● 仅外部帐户中的身份策略无法授权访问其他帐户的资源。
● SCP 定义组织护栏；他们不授予对个人共享资源的访问权限。
● 服务相关角色适用于 AWS 服务集成，而不是此用户共享模式。
● Systems Manager 不是配置合规性记录器。
工作流：识别主体→编写最低权限资源策略→测试访问→使用配置记录→对不合规情况发出警报。
托管视频门户处理
视频门户可以通过分离 Web 层、异步分析和持久媒体存储来减少操作。
推荐架构
● 在 ECS Fargate 上运行动态 Web 应用程序。
● 在 S3 中存储视频和静态内容。
● 将分析作业放置在 SQS 中。
● 使用 EC2 Spot 工作线程进行长时间处理。
● 使用 Amazon Rekognition 而不是自定义视觉软件。
设计理由
● 技术可行性：Fargate 消除了 Web 服务器管理，Spot 降低了员工成本，Rekognition 提供托管分析。
● 需求匹配：该设计降低了成本和运营开销。
● 场景匹配：上传处理是动态的，而分析是异步的并且可能很长。
● 工程常识：将媒体保留在计算实例之外。
应排除的备选方案
● S3静态托管无法运行上传应用程序。
● Lambda 可能不适合长视频工作。
● EFS 和 EC2 Web 服务器保留更多基础设施管理。
● Elastic Beanstalk 仍然运营两个层级的 EC2 队列。
工作流：用户上传 → Fargate → S3 和 SQS → Spot 工作人员 → Rekognition → 存储结果。
SAML 角色联合故障排除
SAML 联合流程取决于信任配置、有效断言、正确的角色映射以及正确形成的 STS 请求。
验证步骤
● 确认 IAM 角色信任策略命名正确的 SAML 提供商并允许 sts:AssumeRoleWithSAML。
● 检查身份提供者是否将用户或组映射到预期角色。
● 验证 SAML 断言包含所需的角色和提供者信息。
● 确认 AssumeRoleWithSAML 调用包括角色 ARN、提供商 ARN 和断言。
设计理由
● 技术可行性：仅当断言和 IAM 信任关系一致时，STS 才会颁发临时凭证。
● 需求匹配：这些检查隔离整个联合链中的故障。
● 场景匹配：企业身份提供商的身份验证成功，但 AWS 角色访问失败。
● 工程常识：在调查不相关的网络服务之前先解决身份声明和信任问题。
应排除的备选方案
● IAM 用户策略不会修复 SAML 角色信任故障。
● VPC DNS 设置与 STS 联合决策无关。
● 将用户置于任意 AWS 组中不会更改外部 IdP 发出的声明。
工作流：用户 → IdP 身份验证 → SAML 断言 → STS 验证 → 角色会话。
跨对等 VPC 的私有 DNS
内部应用程序需要专用网络可达性和专用名称解析。
推荐架构
● 为内部域创建 Route 53 私有托管区域。
● 将所需的 VPC 与托管区域关联。
● 为数据库服务器的私有IP地址创建一条A记录。
● 根据需要启用 enableDnsSupport 和 enableDnsHostnames。
● 维护数据库流量的对等路由和安全规则。
设计理由
● 技术可行性：关联的 VPC 可以通过 Amazon 提供的解析器解析私有托管区域记录。
● 需求匹配：该名称仍然无法通过公共 DNS 获取。
● 场景匹配：现有 VPC 对等互连承载解析后的流量。
● 工程常识：内部服务应使用私有地址和稳定的 DNS 名称，而不是公共端点。
应排除的备选方案
● 公共托管区域公开公开名称。
● CNAME 记录无法直接映射到 IP 地址。
● 弹性 IP 创建了不必要的公共寻址路径。
● 禁用 DNS 支持会阻止预期的解析。
工作流：关联区域 → 启用 DNS → 创建私有记录 → 验证路由 → 验证安全组 → 测试每个 VPC 的解析和连接。
一次性 EMR 容量组合
一次性 300 TB 分析作业应在使用 Spot 执行可重新启动任务的同时保护集群控制和 HDFS。
推荐架构
● 对 EMR 主节点和核心节点使用按需实例。
● 对任务节点使用 Spot 实例。
● 将最终结果保存到持久存储中。
● 完成后终止集群。
设计理由
● 技术可行性：主节点和核心节点维护集群状态和数据；任务节点可以在中断后进行替换。
● 需求匹配：该设计降低了成本，且不会因控制节点中断而导致整个工作面临风险。
● 场景匹配：该集群仅运行八小时并且不重复运行。
● 工程常识：不要为单次执行购买长期承诺。
应排除的备选方案
● 预留的主容量对于一次使用来说并不划算。
● Spot 主节点或核心节点可能会导致集群故障和 HDFS 丢失。
● 预留的主节点和核心节点需要不必要的承诺。
● 所有按需容量都会错过安全的任务节点节省。
工作流：启动稳定的 master 和 core → 添加 Spot 任务节点 → 处理 300 TB → 保存输出 → 终止。
JBoss 和 Oracle 的快速灾难恢复
在灾难期间，与重新设计应用程序相比，现有备份项目可以更快地恢复到 AWS 中。
推荐架构
● 为 JBoss 应用程序和 Oracle 数据库启动 EC2 容量。
● 使用存储在 Amazon S3 中的 RMAN 备份恢复 Oracle。
● 将 Storage Gateway 卷快照恢复为 Amazon EBS 卷。
● 将 EBS 卷附加到应用程序服务器。
● 从准备好的模板重新创建网络和配置。
设计理由
● 技术可行性：RMAN 恢复 Oracle 数据，Storage Gateway 快照可以创建 EBS 卷以进行本机 EC2 块访问。
● 需求匹配：该设计利用现有的备份来实现更短的恢复时间。
● 场景匹配：源架构已使用 JBoss、Oracle 和 Storage Gateway。
● 工程常识：在事件发生前预先记录恢复顺序和依赖关系。
应排除的备选方案
● 让应用程序依赖于本地网关会阻碍区域灾难恢复。
● S3对象存储无法直接替换所需的附加块存储卷。
● 在恢复期间将工作负载转换为 EFS 会增加不受支持的转换工作。
● 在中断期间重构 Oracle 和 JBoss 会增加恢复时间。
工作流：宣布灾难→部署EC2→恢复Oracle→从快照创建EBS→附加→验证→切换流量。
修补 EC2 和记录合规性
紧急操作系统修复需要部署服务和单独的合规性记录器。
推荐架构
● 在 Systems Manager 补丁管理器中定义批准的补丁。
● 通过补丁组和维护时段来定位托管 EC2 实例。
● 及时运行补丁操作。
● 使用 AWS Config 记录和评估合规性状态。
设计理由
● 技术可行性：补丁管理器安装更新；配置记录资源和合规性历史记录。
● 需求匹配：正在运行的实例会收到修复，审核员可以检查队列状态。
● 场景匹配：该漏洞目前影响现有的 EC2 实例。
● 工程常识：新图像有助于未来的发射，但本身并不能修复当前的机队。
应排除的备选方案
● 等待每周 AMI 更换可能太慢。
● 补丁部署不需要OpenSearch。
● 状态管理器对于所需的状态很有用，但补丁管理器是专门构建的。
● Control Tower 管理帐户，但不修补操作系统。
工作流：批准补丁 → 目标队列 → 安装并重新启动 → 报告状态 → 配置记录合规性 → 修复故障。
使用 Web 代理的基于 URL 的出口
当实例接受入站流量但只能从指定网站下载更新时，出站检查必须独立于入站访问进行。
推荐架构
● 在出站路径上放置托管或自我管理的 Web 代理。
● 配置显式 URL 或域允许规则。
● 让私有实例使用代理进行Web访问。
● 删除备用直接出口路径。
● 分别保留入站负载均衡器和安全组规则。
设计理由
● 技术可行性：代理评估应用程序层目标并仅转发合规请求。
● 需求匹配：入站服务可用性保持不变，而出站访问受到严格控制。
● 场景匹配：包更新使用其底层 IP 地址可能更改的已知 URL。
● 工程常识：不要为 URL 标识的服务维护脆弱的 IP 允许列表。
应排除的备选方案
● NAT 网关不过滤网站。
● 安全组和 NACL 无法检查请求的 URL。
● 删除所有互联网访问会阻止所需的更新。
● 仅当批准的存储库是端点支持的 AWS 服务时，S3 或服务 VPC 端点才有帮助。
工作流：应用程序接收入站请求 → EC2 发起更新请求 → 代理检查 URL → 批准的请求退出 → 所有其他出口被拒绝。
扫描文档的可搜索存档
扫描的存档需要持久的对象存储、提取的可搜索元数据和可扩展的 Web 访问层。
推荐架构
● 将扫描的文件存储在 Amazon S3 中。
● 在 Amazon CloudSearch 中对提取的文本和元数据建立索引。
● 在 AWS Elastic Beanstalk 中托管 Web 应用程序。
● 保持搜索结果与权威 S3 对象的链接。
设计理由
● 技术可行性：S3 提供持久存储，CloudSearch 支持托管索引和查询，Elastic Beanstalk 管理应用程序部署和扩展。
● 需求匹配：用户无需操作自定义搜索集群即可搜索和检索文件。
● 场景匹配：源数据由扫描文件而不是关系事务组成。
● 工程常识：将原始数据与派生搜索索引分开存储，以便可以安全地重建两者。
应排除的备选方案
● 文件服务器单独存储文档，但不提供可扩展的全文搜索。
● EC2 上的自我管理搜索软件增加了修补、扩展和恢复工作。
● 对于大型存档来说，没有适当索引的数据库关键字字段的扩展性很差。
● 对象存储本身并不能使图像文本变得可搜索。
工作流：上传扫描件 → 通过现有 OCR 流程提取文本 → 索引元数据 → 查询 CloudSearch → 从 S3 检索原始文件。
三可用区 Web 和数据库可用性
24×7 Web 应用程序需要跨三个可用区的弹性计算和托管数据库故障转移。
推荐架构
● 在三可用区 Auto Scaling 组中运行 EC2 实例。
● 将应用程序负载均衡器放置在队列之前。
● 关系数据库使用RDS多可用区。
设计理由
● 技术可行性：ALB 路由到健康目标，Auto Scaling 取代计算，RDS 促进同步备用。
● 需求匹配：实例和可用区故障不会创建单个服务故障点。
● 场景匹配：该应用程序需要事务数据库可用性，而不仅仅是读取扩展。
● 工程常识：每个服务层都必须消除自己的故障点。
应排除的备选方案
● 读取副本可扩展读取，但不会取代多可用区写入器故障转移。
● 没有负载均衡器的设计无法安全地分配用户流量。
● 即使 Web 层跨越可用区，一个数据库实例仍然是一个故障点。
● 更多 Web 服务器无法修复数据库可用性。
工作流：用户 → ALB → 健康的 EC2 目标 → RDS 写入器；数据库故障时提升备用。
为什么 SCP 不授予权限
服务控制策略定义成员帐户中可用的最大权限，但其本身不授予任何内容。
所需授权链
● 保留适用的 SCP 津贴。
● 将身份策略附加到授予所需 EC2 和 S3 操作的 IAM 用户或角色。
● 评估资源策略和其他权限边界。
设计理由
● 技术可行性：有效访问需要允许该操作的 SCP 边界和 IAM 授权。
● 需求匹配：添加身份权限可以在不削弱组织控制的情况下解决访问问题。
● 场景匹配：该帐户通过其 OU 继承 SCP。
● 工程常识：护栏和补助金有不同的目的。
应排除的备选方案
● SCP 是有效的组织护栏，不应仅仅因为缺少访问权限而被替换。
● 帐户自动继承附加到父 OU 的 SCP。
● 会员帐户 root 用户也受到 SCP 的限制。
● 根目录不应该用于正常的资源创建。
工作流：请求 → 检查 SCP 最大值 → 检查 IAM 授予 → 检查资源策略和条件 → 允许或拒绝。
高可用的三层 Web 架构
高流量 Web 应用程序需要弹性应用程序容量、HTTP 感知负载均衡器以及具有高可用性的托管关系数据库。
推荐架构
● 在跨多个可用区的 Auto Scaling 组中运行 EC2 实例。
● 将应用程序负载均衡器放置在 Web 层前面。
● 跨可用区使用 Amazon Aurora MySQL。
● 使用应用程序终端节点的 Route 53 别名记录。
● 如果删除基础架构堆栈，请保留数据库。
设计理由
● 技术可行性：Auto Scaling 和 ALB 分配大量 HTTP 工作负载； Aurora 提供托管可用性和可扩展存储。
● 需求匹配：该架构可以处理高峰用户，而无需支付第二个区域的费用。
● 场景匹配：现有的 .NET 应用程序和 MySQL 模型无需进行重大重新设计即可迁移。
● 工程常识：使用满足规定可用性目标的最简单的多可用区设计。
应排除的备选方案
● 全 Spot 应用程序层在中断期间可能会损失太多容量。
● 对于正常的 HTTP 应用程序路由，网络负载均衡器不如 ALB 合适。
● 两个区域应用程序和跨区域数据库副本增加了不必要的成本和操作复杂性。
工作流：Route 53 → ALB → Auto Scaling Web 层 → Aurora writer 和副本。
区域预留实例折扣如何适用
区域预留实例折扣适用于与其属性（包括可用区）匹配的正在运行的实例。
示例结果
● us-west-2a 中 r4.16xlarge 的预留与该可用区中的 DEV 实例匹配。
● 另一个可用区中的类似 UAT 实例与区域预留不匹配。
● 在合并计费下，当属性匹配时，可以共享符合条件的折扣。
设计理由
● 技术可行性：计费评估实例系列、大小、平台、租赁、区域和区域范围。
● 需求匹配：组织可以识别哪个帐户收到折扣。
● 场景匹配：账户在不同可用区运行相似的实例。
● 工程常识：预订是计费结构；购买前验证尺寸是否精确匹配。
应排除的备选方案
● 启用共享时，折扣不限于购买者。
● 不同的可用区与可用区 RI 不匹配。
● 当只有一项工作负载匹配时，两个账户都不能使用一项区域福利。
● 未使用的匹配预留不会手动附加到命名实例。
工作流：实例运行 → 匹配 RI 的综合计费搜索 → 匹配的 DEV 使用获得折扣。
针对 Web 漏洞和 DDoS 的托管保护
公共应用需要应用层过滤和基础设施层DDoS防护。
推荐架构
● 将 AWS WAF 连接到支持的 Web 终端节点。
● 使用托管或自定义规则进行 SQL 注入和常见攻击。
● 启用 AWS Shield Advanced 以增强 DDoS 保护和监控。
设计理由
● 技术可行性：WAF 检查 HTTP 请求，而 Shield Advanced 则保护受支持的 AWS 边缘和负载平衡资源。
● 需求匹配：该组合可解决网络漏洞和分布式攻击。
● 场景匹配：该工作负载是面向互联网的 AWS 应用程序。
● 工程常识：反应式 IP 阻止无法取代为分布式和不断变化的源而设计的控制。
应排除的备选方案
● Direct Connect 和本地硬件 WAF 会增加成本，并且不能直接保护 AWS 公共边缘。
● 一项 NACL 拒绝仅阻止已知地址，并且无法检查 SQL 有效负载。
● 备用区域可以提高恢复能力，但不能阻止当前的恶意流量。
● 单独扩展会增加攻击成本而不过滤请求。
工作流：互联网→屏蔽防护→WAF检查→允许请求→申请；警报启动响应。
托管文档 OCR 和实体提取
扫描的表单可以通过托管 OCR、文本分析和无服务器工作流程编排进行处理。
推荐架构
● 使用 Step Functions 协调处理阶段。
● 调用Lambda函数进行集成和转换。
● 使用 Amazon Textract 进行文档 OCR 和结构提取。
● 使用 Amazon Comprehend 进行实体或文本分析。
● 根据需要将结构化结果存储在 RDS 中，并将持久工件存储在 S3 中。
设计理由
● 技术可行性：Textract 提取文档内容，Comprehend 分析文本，Step Functions 处理重试和排序。
● 需求匹配：该设计以较低的运营开销实现处理自动化。
● 场景匹配：输入是文档，而不是语音或一般照片。
● 工程常识：在培训或操作自定义 OCR 系统之前，使用专门构建的托管服务。
应排除的备选方案
● 自定义 SageMaker 模型增加了培训和维护。
● 重新识别和转录目标图像和语音，而不是结构化文档 OCR。
● EKS 上的自我管理 OCR 添加了集群和软件操作。
● 一个大的 Lambda 函数会削弱可观察性和重试控制。
工作流：表单上传→状态机→Textract→理解→验证→RDS或S3输出。
日志频繁的区域恢复
两小时的 RTO 和十分钟的 RPO 需要灾难恢复区域中已存在的恢复数据。
推荐架构
● 在 S3 中创建每小时应用程序或数据库备份。
● 每五分钟导出一次事务日志。
● 启用到恢复区域的 S3 跨区域复制。
● 自动恢复和日志重放。
设计理由
● 技术可行性：基础备份加上频繁的日志可以重建故障时间附近的状态。
● 需求匹配：五分钟日志捕获适合 RPO，区域副本支持 RTO。
● 场景匹配：该要求涵盖了完整的区域损失。
● 工程常识：备份频率和备份位置解决不同的风险。
应排除的备选方案
● 区域 EBS 备份不提供另一个区域中的恢复数据。
● 冰川恢复可能会超过 RTO。
● 多可用区可以防止可用区故障，而不是区域灾难。
● 未经测试的恢复自动化的备份仍可能错过 RTO。
工作流：每小时备份→五分钟日志→跨区域复制→恢复基础→重播日志→验证。
用于图像处理的临时 S3 凭证
EC2 图像处理工作线程应使用 IAM 角色来访问 S3，而不处理长期凭证。
推荐架构
● 创建一个 EC2 IAM 角色，该角色对所需的存储桶和前缀具有确切的读写权限。
● 通过实例配置文件附加角色。
● 让应用程序 SDK 从实例元数据服务检索临时凭证。
● 将带水印的图像上传到授权目的地。
设计理由
● 技术可行性：实例配置文件凭证会自动轮换，并由标准 AWS 开发工具包凭证提供商使用。
● 需求匹配：工作人员无需嵌入访问密钥即可下载和上传照片。
● 场景匹配：处理发生在与 S3 交互的 EC2 实例上。
● 工程常识：分别为源读取和目标写入划分权限范围。
应排除的备选方案
● 硬编码密钥可能会泄漏到图像、日志、AMI 或源存储库中。
● IAM 用户无法直接附加到 EC2 实例。
● 公共存储桶权限不必要地公开了每个对象。
● 将凭证从移动客户端传递给工作人员打破了信任边界。
工作流：EC2接收作业→SDK获取角色凭证→下载源→水印图像→上传结果→凭证轮换。
删除 VPN 站点和隧道故障点
站点到站点 VPN 弹性需要独立的本地位置和冗余隧道。
推荐架构
● 在第二个数据中心添加客户网关。
● 使用两个 AWS 托管隧道创建站点到站点 VPN 连接。
● 在支持的情况下使用动态路由。
● 测试一条隧道丢失和一个数据中心丢失。
设计理由
● 技术可行性：第二个客户网关创建单独的本地路径，同时双隧道可防止隧道端点故障。
● 需求匹配：连接可以解决站点和隧道问题。
● 场景匹配：目前单一数据中心是主要的故障域。
● 工程常识：冗余不得共享受保护的组件。
应排除的备选方案
● VPC 不会按可用区附加单独的虚拟专用网关。
● 第二个 VGW 并不是一个 VPC VPN 弹性的正常模型。
● NAT 网关提供出站 Internet 转换，并且不是本地 VPN 端点。
● 终止于一个发生故障的客户站点的两条隧道不提供站点冗余。
工作流：正常 BGP 路径 → 隧道故障使用对等隧道 → 站点故障使用第二个客户网关 → 路由收敛。
降低每日 DynamoDB 成本
可预测的每日吞吐量受益于预留容量，而历史表数据可以移动到 S3 并删除。
推荐架构
● 购买预留容量以实现可预测的预配置 DynamoDB 使用情况。
● 在需要现有模式的地方使用一张每日表格。
● 将完成的表导出到 S3。
● 验证后删除旧的 DynamoDB 表。
设计理由
● 技术可行性：预留容量会降低可预测的吞吐量，S3 以较低的成本保留历史数据。
● 需求匹配：该应用程序保留当前的低延迟数据，同时避免长期 DynamoDB 存储费用。
● 场景匹配：生物识别数据按天分区，并且不会主动查询较旧的数据。
● 工程常识：在删除源表之前验证导出。
应排除的备选方案
● Redshift 不是低延迟操作数据库。
● S3 One Zone-IA 不必要地降低了报告的弹性。
● ElastiCache 不是持久的主存储。
● RDS 添加了固定的关系容量和管理，而无需关系要求。
工作流：使用日常表→导出到S3→验证对象→删除表→保留当前配置容量。
低 CPU 时自动缩容
当 CloudWatch 指标低于安全阈值时，Auto Scaling 可以删除多余的 EC2 容量。
推荐架构
● 针对 CPU 处于或低于 15% 的情况创建 CloudWatch 警报。
● 将警报附加到 Auto Scaling 缩减策略。
● 配置冷却或实例预热行为。
● 保留最小容量和可用性限制。
设计理由
● 技术可行性：当满足评估标准时，警报会直接调用伸缩策略。
● 需求匹配：不需要的实例会自动终止并降低成本。
● 场景匹配：容量应遵循测量的利用率，而不是固定的时间表。
● 工程常识：避免对一个简短的低 CPU 样本做出反应。
应排除的备选方案
● 手动电子邮件驱动的删除速度很慢。
● 本机扩展操作不需要 Lambda 通知代码。
● 计划的扩展遵循时间而不是实际需求。
● 终止 Auto Scaling 组外部的实例可能会破坏所需的容量管理。
工作流：CPU 保持低电平 → 警报进入 ALARM → 缩减策略减少所需容量 → Auto Scaling 安全终止。
三可用区应用程序和数据库可用性
弹性 Web 平台跨三个可用区分配计算，并使用具有写入器可用性的数据库设计。
推荐架构
● 在三可用区 Auto Scaling 组中运行 EC2 实例。
● 将应用程序负载均衡器放置在队列之前。
● 使用支持所需写入器可用性的 Aurora 架构。
● 创建 ALB 的 Route 53 别名。
设计理由
● 技术可行性：Auto Scaling 替换失败的计算，ALB 仅路由到正常目标，Route 53 别名跟踪负载均衡器端点。
● 需求匹配：该设计在实例或可用区故障时仍然可用。
● 场景匹配：该应用程序需要托管关系编写器的弹性。
● 工程常识：避免不必要的可用区或不会改善规定的恢复目标的额外数据库。
应排除的备选方案
● 通用 A 记录不应硬编码 ALB 地址。
● 没有合适的故障转移的数据库编写器仍然是一种风险。
● 四个可用区增加了复杂性，而没有明确的需求。
● 额外的副本不会自动创建写入器可用性。
工作流：Route 53 别名 → ALB → 正常的 Auto Scaling 目标 → 可用的 Aurora writer。
托管 CI/CD 测试、警报和功能开关
托管交付管道应该运行可重复的测试、警报故障并部署基础设施定义的功能开关。
推荐架构
● 使用 CodePipeline 来编排阶段。
● 使用 CodeBuild 进行测试和安全扫描。
● 使用 EventBridge 和 SNS 进行故障通知。
● 使用 AWS CDK 对功能开关和基础设施进行建模。
设计理由
● 技术可行性：CDK 综合部署模板，CodeBuild 执行任意测试命令，CodePipeline 协调升级。
● 需求匹配：工作流程是自动化的，并减少了服务器管理。
● 场景匹配：构建包括自定义测试和基础架构更改。
● 工程常识：使用部署代码保持功能配置的版本。
应排除的备选方案
● Lambda 并不是最好的通用完整构建环境。
● Amplify 插件不提供通用基础设施功能切换。
● Jenkins 可以工作，但增加了服务器管理。
● 当 SNS 处理操作警报时，不需要 SES。
● CodeArtifact 存储包但不运行所有测试和扫描。
工作流：提交 → CodePipeline → CodeBuild 测试 → CDK 部署 → EventBridge 和 SNS 报告失败。
在 CloudFront 上实施 HTTPS
CloudFront 可以在其默认域上提供受信任的 HTTPS 并强制执行安全的查看器连接。
推荐配置
● 使用分配的 cloudfront.net 主机名的默认 CloudFront 证书。
● 将查看器协议策略设置为将 HTTP 重定向到 HTTPS 或仅 HTTPS。
● 当需要自定义域时，在 us-east-1 中使用 ACM。
设计理由
● 技术可行性：浏览器信任默认主机名的默认 CloudFront 证书，并且查看器策略控制接受的协议。
● 需求匹配：用户通过 HTTPS 访问内容，支持机密性和安全索引。
● 场景匹配：直接要求可以使用默认的分发域。
● 工程常识：证书主机名覆盖范围必须与用户访问的 URL 匹配。
应排除的备选方案
● 自签名证书不受公众信任。
● 在 S3 中存储证书不会建立浏览器信任。
● ELB 证书不会自动成为 CloudFront 查看器证书。
● 假定的通用 ELB 默认证书无法保护应用程序的自定义主机名。
工作流：查看器使用 HTTP 或 HTTPS → 策略重定向或接受 → TLS 在 CloudFront 终止 → 源请求遵循配置的协议。
区域 ALB 的全球选播入口点
多区域应用程序可以使用 AWS Global Accelerator 作为健康区域应用程序负载均衡器的一个公共入口点。
推荐架构
● 创建全球加速器。
● 为所需区域定义端点组。
● 将区域 ALB 注册为端点。
● 在指向加速器的顶点域创建 Route 53 公共别名记录。
设计理由
● 技术可行性：Global Accelerator 使用静态任播 IP 地址并将用户通过 AWS 网络路由到健康的终端节点。
● 需求匹配：该设计支持顶级域，改进全局路由，并最大限度地减少 DNS 和故障转移操作。
● 场景匹配：该应用程序已经拥有公共区域 ALB 和多区域数据服务。
● 工程常识：使用一个托管的全局流量层，而不是手动维护区域 IP 映射。
应排除的备选方案
● Transit Gateway 用于专用网络路由，不能是公共应用程序端点。
● Route 53 解析器入站终端节点提供私有 DNS 查询，而不是公共顶点路由。
● 区域顶端的公共 CNAME 不是合适的模型； Route 53 别名记录解决了 apex 要求。
工作流：客户端 → Global Accelerator 任播地址 → 基于健康状况的区域端点组 → ALB → 应用程序。
IoT 文件的事件驱动处理
每五分钟到达的文件应在到达时进行处理，而不是等待夜间轮询作业。
推荐架构
● 将现有的 Python 处理逻辑转换为 AWS Lambda 函数。
● 配置 S3 对象创建的事件通知以调用 Lambda。
● 处理每个上传的文件并将其值写入 Amazon RDS。
● 仅在成功处理后才删除或生命周期源对象。
设计理由
● 技术可行性：S3 可以直接为新对象调用 Lambda，并且 Lambda 可以使用正确的网络和凭据连接到数据库。
● 需求匹配：数据上传后不久即可使用，几乎不需要基础设施管理。
● 场景匹配：每日处理只需大约十分钟，这表明每个单独的文件都足够小，可以进行基于事件的执行。
● 工程常识：对于离散对象到达，更喜欢推送事件而不是一分钟轮询。
应排除的备选方案
● 更大的 EC2 队列和频繁的 cron 执行会浪费容量并需要协调。
● CloudTrail 数据事件加上 EventBridge 可以检测上传，但当本机 S3 通知足够时会增加成本和延迟。
● 多个计划规则会产生重复调用风险，而不会提高及时性。
工作流：设备上传→S3事件→Lambda处理→RDS写入→成功处理和对象清理。
不可导出的 TLS 密钥和持久的安全日志
敏感私钥应保留在专用加密硬件内，而日志应独立于计算实例存储。
推荐架构
● 使用 TCP 负载平衡，以便 TLS 操作到达应用程序层，而不会在负载平衡器处终止。
● 使用 AWS CloudHSM 进行私钥操作。
● 跨两个可用区部署 HSM 容量。
● 将加密的应用程序日志传送到私有 Amazon S3 存储桶。
设计理由
● 技术可行性：CloudHSM 执行加密操作，无需导出私钥材料； S3 提供持久的加密存储。
● 需求匹配：多可用区 HSM 部署支持可用性，IAM 加加密控制日志访问。
● 场景匹配：流量是可预测的，因此密钥保管和持久性比激进的弹性更重要。
● 工程常识：切勿将敏感日志存储在临时实例存储上或将私钥复制到 Web 服务器上。
应排除的备选方案
● TLS 卸载可以工作，但实例存储日志不持久。
● 单个 HSM 位置会造成可用性差距。
● 从 S3 检索密钥使密钥可移动并将其公开给服务器进程。
工作流：TCP 直通 → HSM 支持的 TLS → 应用程序 → 加密的 S3 日志记录 → 授权审核访问。
替换脆弱的 NAT 实例
当两个可用区应用程序中一半的出站请求失败时，一个失败的 NAT 路径是一个强烈的架构信号。
推荐架构
● 将 EC2 NAT 实例替换为托管 NAT 网关。
● 在每个活动可用区中部署一个 NAT 网关。
● 将每个私有子网路由到同一可用区中的 NAT 网关。
● 监控 NAT 指标和第三方 API 连接。
设计理由
● 技术可行性：NAT 网关在其可用区内为私有子网互联网出口提供托管扩展和可用性。
● 需求匹配：无需维护 NAT 实例运行状况或容量即可访问地图 API。
● 场景匹配：两条 AZ 路径上大约 50% 的成功表明一条出口路由已损坏。
● 工程常识：避免跨可用区依赖，并删除存在托管等效设备的自我管理网络设备。
应排除的备选方案
● 扩大 NAT 实例可以解决吞吐量问题，但不能解决失败的实例或路由问题。
● 责备提供商并不能解释通过其他申请路径取得的持续成功。
● 网络 ACL 错误是可能的，但 NAT 实例模式更直接地解释了观察到的拆分行为。
工作流：每个可用区创建 NAT 网关 → 更新私有路由 → 测试出站呼叫 → 停用 NAT 实例。
使用 FSx 实现 Lustre 爆发 HPC 存储
每月 200 TB 的建模作业需要经济耐用的存储和临时并行文件系统来进行密集处理。
推荐架构
● 将源数据保留在 S3 智能分层中。
● 为每月计算窗口创建 FSx for Lustre。
● 仅延迟加载所需的 S3 对象。
● 针对文件系统运行并行计算。
● 导出结果并随后删除临时文件系统。
设计理由
● 技术可行性：FSx for Lustre 与 S3 集成并提供高吞吐量并行文件访问。
● 需求匹配：智能分层可降低闲置存储成本，临时 FSx 可避免长达一个月的文件系统费用。
● 场景匹配：该作业每月运行时间较短，但需要极高的并行 I/O。
● 工程常识：将持久存储与临时性能存储分开。
应排除的备选方案
● EBS Multi-Attach 具有可用区和实例限制，并且不是 200 TB 共享队列文件系统。
● 对于每月的批量计算来说，冰川检索费用和恢复行为很差。
● EFS 可以适用于一般共享文件，但不太适合这种并行建模爆发。
工作流：S3源→创建FSx→延迟加载→计算→导出结果→删除FSx。
并行照片元数据编排
照片列表可以分布在并行的无服务器分支上，并在写入最终元数据之前加入。
推荐架构
● 使用 Step Functions 分布式处理照片列表。
● 并行调用专用 Lambda 函数。
● 跟踪每个分支并处理重试。
● 所有必需的分支完成后合并结果。
设计理由
● 技术可行性：Step Functions 协调并行 Lambda 执行并保留工作流状态。
● 需求匹配：处理规模同时产生一个协调的完成结果。
● 场景匹配：每张照片都需要多个独立的元数据操作。
● 工程常识：当下游工作必须在完成之前加入时，请使用协调器。
应排除的备选方案
● 独立的 SQS 触发函数不会自动创建一个协调的聚合结果。
● 自定义列表函数加上队列使编排不完整。
● Lambda 函数无法按照建议附加到 AWS Batch 计算环境。
● 一个串行 Lambda 会浪费并行性并面临超时风险。
工作流：照片列表→分布式地图→并行Lambda分支→重试失败→连接结果→存储组合元数据。
多区域一网直达
Direct Connect 网关将一种私有连接设计扩展到多个 AWS 区域中的 VPC。
推荐架构
● 创建直连网关。
● 关联区域虚拟专用网关。
● 将私有虚拟接口连接到网关。
● 通过 BGP 公布批准的前缀。
设计理由
● 技术可行性：Direct Connect 网关将私有 VIF 连接链接到跨受支持区域的 VGW。
● 需求匹配：数据中心通过集中式高带宽专用连接到达两个区域 VPC。
● 场景匹配：一个本地站点需要访问东、西VPC。
● 工程常识：在购买重复电路之前使用一个集线器。
应排除的备选方案
● VPC 对等互连不连接本地数据中心。
● 通往东部区域的 VPN 不会自动到达西部 VPC。
● VPN 缺乏 Direct Connect 的可预测性能。
● 单独的 Direct Connect 连接可以工作，但成本更高并且需要增加管理。
工作流：数据中心 → Direct Connect → 私有 VIF → Direct Connect 网关 → 区域 VGW → VPC。
受管理的自助服务 SageMaker 环境
数据科学家可以通过受控的自助服务目录接收经过批准的机器学习环境。
推荐架构
● 在 CloudFormation 中定义 SageMaker 环境。
● 使用客户控制的 KMS 密钥加密所需的资源。
● 将批准的模板发布为 AWS Service Catalog 产品。
● 仅公开允许用户选择的映射参数。
● 应用投资组合访问控制和约束。
设计理由
● 技术可行性：服务目录根据管理员定义的权限和约束提供 CloudFormation 产品。
● 需求匹配：用户无需广泛的基础设施权限即可启动标准化环境。
● 场景匹配：多个团队需要具有治理和加密功能的可重复 SageMaker 工作区。
● 工程常识：将产品设计与产品消费分开。
应排除的备选方案
● 授予每个数据科学家管理员权限会削弱治理。
● 基于票证的手动配置会产生可避免的延迟和不一致。
● 原始 CloudFormation 访问可能允许未经批准的参数和资源更改。
● 自定义部署脚本在 Service Catalog 已提供组合和约束的情况下添加了维护。
工作流：管理员创建模板 → 发布目录产品 → 授予产品组合访问权限 → 用户选择批准的参数 → 受控堆栈部署。
使用 WorkDocs 管理文档版本
协作文档服务需要托管用户、版本、加密、API 和旧内容的恢复。
推荐架构
● 将文档存储在 Amazon WorkDocs 中。
● 使用其托管版本历史记录和访问控制。
● 通过 WorkDocs API 集成应用程序逻辑。
● 需要时将选定的旧版本恢复为当前文档。
设计理由
● 技术可行性：WorkDocs 提供面向文档的存储、用户、版本和托管加密。
● 需求匹配：该平台避免了自定义版本和密钥管理代码。
● 场景匹配：用户协作处理文档而不是通用对象或共享文件系统块。
● 工程常识：当文档生命周期是核心要求时，使用文档管理服务。
应排除的备选方案
● S3 可以对对象进行版本控制，但分发客户端主密钥不安全且操作繁重。
● S3 访问日志不提供没有版本控制的回滚。
● EFS 是一个文件系统，而不是托管文档版本服务。
● IAM 无法按照建议为每个锁定的 EFS 文件分配不同的 KMS 密钥。
工作流：用户编辑 → WorkDocs 创建版本 → 应用程序列出历史记录 → 所选版本恢复为当前版本。
对 ERP 的私人远程访问
漫游员工可以通过经过身份验证的 SSL 客户端 VPN 访问私有 ERP 服务器。
推荐架构
● 将 ERP 服务器保留在私有子网中。
● 部署 AWS 客户端 VPN 终端节点。
● 在授权设备上安装客户端软件。
● 配置身份认证、路由、限制性安全组。
设计理由
● 技术可行性：客户端 VPN 创建加密的用户到 VPC 隧道。
● 需求匹配：经理和分析师可以远程连接，无需公开暴露 ERP 服务器。
● 场景匹配：用户在不断变化的家庭或旅行网络中工作。
● 工程常识：网络到网络解决方案对于个人漫游客户端来说并不理想。
应排除的备选方案
● 站点到站点 VPN 连接固定网络，而不是单个员工。
● Direct Connect 直接为企业站点提供服务，而不是直接为漫游用户提供服务。
● 公共应用程序服务器增加了曝光度。
● 公共 ELB 上的 HTTPS 会对流量进行加密，但不会单独限制授权人员的访问。
工作流：用户认证→客户端VPN隧道→授权VPC路由→ERP安全组→私有服务器。
区域和全球服务的持久审核日志
可靠的安全审计跟踪应覆盖每个区域和全球服务，同时将日志与正常工作负载访问隔离。
推荐架构
● 创建一个多区域 AWS CloudTrail 跟踪。
● 包括全局服务事件，例如 IAM 活动。
● 将日志传送到专用的 Amazon S3 存储桶。
● 在适当的情况下，使用限制性策略、版本控制、加密和 MFA 删除来保护存储桶。
设计理由
● 技术可行性：CloudTrail 记录 EC2、RDS、IAM 和其他服务的管理活动。
● 需求匹配：S3 提供持久存储，而访问限制和删除控制可保护机密性和完整性。
● 场景匹配：该账户使用跨多个区域的资源，并需要集中合规证据。
● 工程常识：将审核日志保存在专用位置，管理员数量少于生产资源。
应排除的备选方案
● 忽略全局事件的跟踪会错过 IAM 活动。
● 复用通用桶，主要依靠ACL，隔离性弱。
● 控制台、SDK 和 CLI 不需要单独的跟踪，因为 CloudTrail 记录所有三个通道。
● SNS 传送通知不会取代日志保护或验证。
工作流：帐户操作 → CloudTrail 事件 → 受保护的 S3 存储 → 受控的审核员访问 → 保留监控。
通过请求者支付转移 S3 检索费用
当合作伙伴频繁从另一家公司的 S3 存储桶下载对象时，Requester Pays 可以向请求者分配请求和转移费用。
推荐架构
● 在共享存储桶上启用 S3 请求者付款。
● 授予合作伙伴所需的对象权限。
● 要求请求确认请求者的账单。
● 监控访问和成本分配。
设计理由
● 技术可行性：授权请求者包含 requester-pays 参数，并为符合条件的请求和数据传输付费。
● 需求匹配：初创公司保留一份权威副本，而媒体公司则为其消费付费。
● 场景匹配：频繁的合作伙伴检索（而不是存储增长）正在推动成本。
● 工程常识：在复制整个数据集之前更改计费模型。
应排除的备选方案
● 同步到另一个存储桶会重复存储，并且需要持续的一致性管理。
● AWS Organizations 和 SCP 管理账户，但不转移 S3 检索费用。
● 仅跨账户权限并不会让请求者付费；必须明确启用计费行为。
工作流：启用请求者付款 → 更新合作伙伴请求流程 → 测试计费确认 → 观察使用情况 → 保留内部工作流程的正常所有者访问权限。