手册

AWS Certified Solutions Architect Professional

最后审核：2026年5月

SAP-C02 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。

设计解决组织复杂性问题

从第一天起，为拥有100多个账户的AWS环境建立一致的防护措施、日志记录和身份管理。

使用AWS Control Tower作为着陆区。Account Factory配置账户；强制性+强烈推荐的防护措施强制执行基线；自动创建集中式日志存档+审计账户。

原因: Control Tower将良好架构的多账户模式规范化。仅通过Organizations从头开始构建会手动重复相同的底层基础架构。

参考

需要跨所有账户添加超出Control Tower默认设置的自定义防护措施和资源。

使用AWS Control Tower的自定义功能（CfCT）。通过StackSets将CloudFormation模板+SCP的管道部署到OU。

原因: CfCT在不中断Control Tower生命周期的情况下对其进行扩展。自定义Config规则、安全基线、网络——所有这些都经过版本控制且可重放。

参考

在不到15分钟内，在300个账户中强制执行S3 KMS加密并自动修复不合规的存储桶。

通过委托管理员部署AWS Config组织范围的一致性包。Config规则+SSM Automation文档用于自动修复。

原因: 一致性包可以从一个账户将Config规则+修复措施部署到整个组织。单独账户的Lambda或仅SCP的方法会遗漏实时检测或修复。

参考

跨所有账户的CloudTrail日志防篡改并保留7年；只有安全团队可以读取。

将组织跟踪交付到专用日志记录账户的S3存储桶。以合规模式（Compliance mode）启用Object Lock并保留7年。SCP限制安全IAM角色对存储桶的访问。

原因: 合规模式的Object Lock会阻止删除，即使是根用户也无法删除。组织跟踪会自动从所有账户收集日志。专用日志记录账户隔离了爆炸半径。

参考

通过SAML将150个账户联合到公司AD；按AD组分配权限。

使用带有外部SAML 2.0 IdP的IAM Identity Center。通过SCIM配置将权限集映射到AD组。通过组进行账户分配。

原因: Identity Center集中管理所有组织账户的联合。权限集可在账户间重复使用；SCIM使用户/组状态保持同步。

参考

向标记有用户成本中心的资源授予访问权限，可扩展到数千用户。

Identity Center中基于属性的访问控制（ABAC）。通过SAML传递AD属性；权限集将`aws:PrincipalTag/CostCenter`与`aws:ResourceTag/CostCenter`进行引用。

原因: ABAC无需更改每个用户的策略即可扩展。添加新的成本中心只需添加一个标签——无需重写IAM。

参考

CI/CD账户在50个工作负载账户中承担部署角色以运行CloudFormation。

每个工作负载账户一个IAM角色，其信任策略允许CI/CD账户主体。CI/CD通过STS AssumeRole承担角色。如果第三方工具启动，则使用External ID。

原因: External ID可防止混淆代理问题。角色链将会话硬性限制在1小时，即使角色允许更长时间。

参考

跨5个区域连接VPC+本地环境，实现确定性路由和集中检查。

每个区域都有Transit Gateway (TGW)。TGW对等连接用于跨区域。通过TGW路由表可访问带有设备的检查VPC。

原因: TGW对等连接避免了跨区域VPN/对等连接的全网状结构。每个附件的路由表允许安全团队检查特定流量，而不会破坏其他流量。

参考

构建一个跨区域+分支站点的全球私有网络，采用策略驱动路由——超越TGW对等连接。

AWS Cloud WAN。JSON中的核心网络策略声明性地定义了段、区域、附件和共享。

原因: Cloud WAN用一个单一的托管全球骨干网络取代了多中心TGW设计。段在跨区域提供了逻辑隔离。

参考

本地数据中心需要与AWS建立10 Gbps链路，具有链路故障恢复能力且不暴露于互联网。

两个Direct Connect连接，位于不同的DX位置。每个连接都有一个私有VIF，终止于Direct Connect Gateway → TGW。连接之间进行BGP故障转移。

原因: 单个DX是单点故障。不同的DX位置可防止站点范围中断。DX Gateway允许一个VIF访问多个区域/VPC。

参考

Direct Connect链路作为主用；需要自动VPN故障转移。

站点到站点VPN连接到与DX Gateway相同的TGW。AWS优先使用DX BGP路由；当DX BGP撤回时，VPN接管。

原因: BGP路由优先级使故障转移自动化。预配置的VPN避免了中断期间的配置延迟。

参考

监管机构要求通过Direct Connect在本地和AWS之间进行二层加密。

在专用10 Gbps或100 Gbps连接上使用带有MACsec的Direct Connect。两端配置预共享密钥。

原因: IPsec在三层运行；MACsec在二层以线速加密，满足了强制物理链路加密的监管机构要求。

参考

VPC之间的东西向流量必须通过有状态检查。

使用AWS Network Firewall的集中式检查VPC。TGW路由表将跨VPC流量通过防火墙VPC路由，然后到达目的地。

原因: Network Firewall是用于有状态检查的托管式Suricata规则引擎。集中化避免了每个VPC防火墙的蔓延。

参考

自动在组织内的每个账户中强制执行WAF+Network Firewall基线配置。

使用委托管理员的AWS Firewall Manager。WAF、Shield Advanced、Network Firewall、安全组的策略适用于整个组织。

原因: Firewall Manager自动将策略附加到新资源。没有它，随着账户的增加，每个账户都会偏离基线。

参考

在一个单一的控制面板中集中100多个账户的Security Hub调查结果。

Security Hub委托管理员。聚合区域将所有成员账户+所有启用区域的调查结果收集到一个控制台。

原因: 如果没有聚合，调查结果将保留在每个账户/区域。委托管理员避免将管理账户用于安全操作。

参考

在整个组织中启用GuardDuty，实现集中监控和按账户的账单可见性。

带有委托管理员的GuardDuty。通过组织集成在新账户上自动启用。调查结果聚合到管理员账户。

原因: 自动启用弥补了新创建账户的空白，否则这些账户将无法被监控。

参考

在200个账户的所有S3存储桶中持续发现PII。

带有委托管理员的Macie。组织范围内的自动启用。调查结果流向Security Hub进行统一审查。

原因: 没有明确设置，Macie无法跨账户读取。组织级配置确保每个存储桶都在范围内。

参考

通过关联跨账户的CloudTrail+VPC Flow Logs来调查GuardDuty调查结果。

在专用安全账户中设置Amazon Detective委托管理员。成员账户贡献行为图。

原因: Detective自动从VPC Flow Logs、CloudTrail、GuardDuty构建行为图。委托管理员（而非管理账户）遵循AWS最佳实践。

参考

检测组织内任何资源何时与外部账户共享。

IAM Access Analyzer，将组织作为信任区，委托给安全账户。查找S3、IAM角色、KMS密钥、Lambda、SQS、Secrets中的跨账户访问。

原因: Access Analyzer使用形式化验证，而非模式匹配。组织级信任区将兄弟账户视为受信任账户。

参考

在50个工作负载模式不匹配的账户中最大化Savings Plan利用率。

Organizations中的合并账单，启用Savings Plan+RI共享。在付款人账户中购买的计划可在组织范围内共享。

原因: 共享池化了使用量，因此一个账户中未使用的容量可以抵消另一个账户的需求。仅为了成本分配隔离而禁用共享。

参考

让应用程序团队在没有IAM管理员权限的情况下自助部署经批准的基础设施（VPC、RDS）。

AWS Service Catalog组合。带有约束的预批准CloudFormation产品。通过Organizations跨账户共享组合。

原因: 提供有防护措施的自助服务。约束策略隐藏了复杂性（实例类型、标签），而产品则承载了启动所需的IAM范围。

参考

在整个组织中一致地强制执行强制性的`CostCenter`和`Environment`标签。

附加到OU的Organizations标签策略。定义允许的值+大小写。结合Config规则`required-tags`进行强制执行。

原因: 标签策略进行验证；Config规则检测不合规。SCP可以拒绝缺少标签的资源创建。

参考

阻止成员账户中的根用户操作（合规性要求）。

当`aws:PrincipalArn`与`arn:aws:iam::*:root`匹配时，SCP拒绝任何操作。

原因: SCP甚至适用于根用户。IAM无法拒绝根用户。除账户恢复外，不应需要根用户操作。

参考

在所有账户中强制执行AWS Backup计划并保持一致的保留期。

附加到OU的Organizations备份策略。定义计划+选择标准；自动应用于范围内的资源。

原因: 按账户复制Backup计划会导致偏差。组织策略强制执行单一事实来源。

参考

100多个VPC，每个都带有NAT Gateway，导致成本膨胀。需要一个出口点。

集中式出口VPC，带有NAT Gateway。分支VPC将0.0.0.0/0 → TGW → 出口VPC → NAT。

原因: 一个NAT替代100个NAT可大幅降低成本。TGW跨区域数据传输规则适用，因此需要仔细设计跨区域流量。

参考

VPC中的EC2需要解析本地主机名；本地环境必须解析VPC私有DNS。

Route 53 Resolver入站+出站端点。转发规则将`corp.local`查询发送到本地；本地DNS将`*.compute.internal`转发到入站端点。

原因: Resolver端点是两个可用区中的高可用性ENI。条件转发提供了双向解析，而无需将DNS暴露给互联网。

参考

内部服务需要可从跨账户的多个VPC解析的DNS。

通过跨账户VPC关联，将Route 53私有托管区域与多个账户的VPC关联。

原因: 通过跨账户关联共享一个PHZ，优于每个VPC都存在且容易漂移的重复PHZ。

参考

Windows工作负载需要完整的AD，并与本地林建立信任关系。

AWS Managed Microsoft AD。通过DX/VPN与本地AD建立双向林信任。

原因: Managed AD是真正的Microsoft AD（两个可用区中的DC，模式可扩展）。AD Connector仅作代理；Simple AD缺乏信任支持。

参考

AWS中的应用程序需要针对现有本地AD进行身份验证，而无需复制身份。

AD Connector。通过DX/VPN充当从VPC到本地AD的代理。

原因: 没有任何目录数据离开本地；认证请求直接通过。延迟取决于链路。

参考

对延迟敏感的工作负载必须在特定数据中心运行，但通过AWS API进行管理。

AWS Outposts机架/服务器。相同的AWS API（EC2、EBS、ECS、EKS、RDS子集）在本地运行。连接到父区域。

原因: 适用于对本地系统或数据驻留有亚毫秒级延迟要求，且本地区域无法覆盖的场景。单可用区——配对两个Outposts实现高可用性。

参考

减少与远离父区域的都会区终端用户的延迟。

AWS Local Zones。在人口中心附近部署计算、存储；数据平面路由回父区域进行控制平面操作。

原因: Local Zones在主要城市附近托管EC2/EBS/RDS/ELB。当不需要完全拥有数据中心时，比Outposts更便宜。

参考

应用程序需要对5G移动用户实现个位数毫秒级延迟。

运营商5G网络中的AWS Wavelength Zones。在运营商边缘部署EC2/EBS；流量保留在移动提供商网络上。

原因: 对于AR/VR、实时推理、游戏等5G用例，完全消除了公共互联网跳跃。

参考

合规审计员需要组织内所有资源的当前配置。

审计账户中的AWS Config聚合器，范围覆盖所有区域的整个组织。

原因: Config聚合器是组织范围内的只读视图。聚合器不会在成员账户中启用Config——这是单独的。

参考

来自50个账户的CloudWatch Logs需要存储在一个S3存档中，以便SIEM摄取。

每个账户中的订阅过滤器 → 跨账户Kinesis Data Stream / Firehose → 存储到日志记录账户中的S3。

原因: 订阅过滤器允许日志组实时推送。Firehose处理批处理、压缩和S3分区。

参考

持续生成SOC 2、PCI、HIPAA等合规性的组织范围内的证据报告。

AWS Audit Manager。预构建的框架将控制措施映射到AWS证据（Config、CloudTrail、Security Hub）。安全账户中的委托管理员。

原因: Audit Manager自动收集每个控制措施的证据。每个审计周期可节省数百小时的手动截图收集工作。

参考

将基线IAM角色部署到组织中所有现有和未来的账户。

具有服务管理权限+在新账户上自动部署的CloudFormation StackSets。目标是整个组织或特定的OU。

原因: 自管理的StackSets需要在每个账户中设置IAM。服务管理的StackSets利用组织权限，并且是Organizations的默认选项。

参考

StackSets运行数月后，怀疑手动更改导致了漂移。

启动StackSet上的漂移检测。查看每个堆栈实例的结果，但不修改资源。

原因: 漂移检测将实时资源配置与模板进行比较。“修复”漂移而重新部署StackSets可能会导致意外更改。

参考

设计新解决方案

可变、突发性的数据库工作负载——容量需求在几分钟内波动10倍。

Aurora Serverless v2。设置最小/最大ACU；Aurora可在几秒内扩展，且不中断连接。

原因: v2通过向现有实例添加容量进行扩展——无需故障转移。Provisioned Aurora无法如此快速扩展；Serverless v1扩展速度较慢并会暂停连接。

参考

全球应用程序，要求跨区域数据库故障转移RPO <1秒，RTO <1分钟。

Aurora Global Database。基于存储的复制，典型复制延迟<1秒。在几秒内提升辅助区域。

原因: Global DB传输的是页面，而非事务——实现亚秒级跨区域复制。通过逻辑复制的跨区域只读副本无法与之匹敌。

参考

在不支付完整副本费用的情况下，复制生产数据库用于测试。

Aurora克隆。写时复制——初始克隆免费；只对更改的页面收费。

原因: 克隆是时间点、即时、隔离的。快照+恢复需要数小时，并立即对完整存储计费。

参考

在几分钟内（而非几小时），从逻辑错误（生产环境中的DROP TABLE）中恢复。

Aurora MySQL Backtrack。将集群原地回溯到之前的时间点，而无需从备份中恢复。

原因: Backtrack是原地且快速的。PITR恢复会创建新集群——速度较慢且需要应用程序切换。

参考

将报告查询路由到具有更大内存的特定读取器实例。

Aurora自定义端点。定义指向一部分读取器（内存较大的读取器）的端点。

原因: 默认读取器端点会轮询所有读取器。自定义端点按工作负载类型划分集群。

参考

DynamoDB表经历热分区峰值，导致部分读/写被限流。

Provisioned容量模式，启用自动扩缩+自适应容量（自动）。如果单个键是热点，则重新设计分区键。

原因: 自适应容量无需操作即可在分区之间重新分配吞吐量。但如果一个键是热点，只有模式重新设计（复合键、写入分片）才能解决。

参考

每次DynamoDB写入都产生副作用——推送到OpenSearch进行搜索索引。

DynamoDB Streams + Lambda触发器。Lambda批量处理流记录并写入OpenSearch。

原因: Streams捕获项目级更改24小时。原生触发器模型——Kinesis Data Streams适配器可用于更长时间的保留/分析。

参考

跨多个DynamoDB项目的两阶段写入必须是原子的。

TransactWriteItems / TransactGetItems。对多达100个项目实现ACID语义。

原因: 原生事务避免了分布式saga的复杂性。成本是每个项目正常容量的2倍——仅在需要原子性时使用。

参考

将自托管的MongoDB集群迁移到托管服务，同时保留API。

Amazon DocumentDB。MongoDB兼容API。使用mongodump/mongorestore或DMS进行迁移。

原因: DocumentDB与MongoDB 4.0/5.0兼容API（大多数操作符，但不是全部）。在提交之前验证驱动程序/功能兼容性。

参考

推荐引擎需要遍历1亿个节点的社交图谱。

Amazon Neptune。属性图（Gremlin）或RDF（SPARQL）。

原因: 专门构建的图数据库。在DynamoDB或RDS中建模关系是可能的，但查询性能会随着跳跃深度的增加而下降。

参考

IoT设备每秒发出1000万个时间序列数据点，具有混合频率保留策略。

Amazon Timestream。内存存储（近期），磁性存储（历史）——自动分层。

原因: 专门构建的时间序列数据库——DynamoDB/RDS在此速率下扩展成本过高。内置的保留分层降低了存储成本。

参考

银行账本需要对每条记录更改进行加密验证。

Amazon QLDB。不可变、可加密验证的日志。使用SHA-256摘要导出进行证明。

原因: QLDB是专门构建的账本数据库。DynamoDB Streams提供更改历史，但没有内置的加密链。

日志分析工作负载具有不可预测的峰值和无需人工操作的需求。

Amazon OpenSearch Serverless。计算/存储解耦；自动扩缩OCU。

原因: 无需集群大小调整或分片管理。对于可预测、持续的工作负载，预置域更便宜。

参考

PB级分析，具有弹性计算和跨团队数据共享。

Redshift RA3节点，带托管存储。跨集群数据共享（无需复制）。

原因: RA3将计算与存储分离——独立扩展。数据共享消除了团队集群之间的ETL。

参考

现有Redshift集群+S3数据湖——从Redshift查询S3，还是使用Athena？

当需要集群表和S3数据之间的连接时，使用Redshift Spectrum。当只在S3上进行完全无服务器的即席查询时，使用Athena。

原因: Spectrum通过Redshift计算运行S3查询。Athena按扫描的TB付费。根据主要数据所在位置选择。

参考

不同团队需要对相同的Glue Catalog表具有不同的行/列可见性。

AWS Lake Formation，具有行级+列级+单元格级过滤器。通过LF标签授予。

原因: IAM/S3策略无法实现行级。Lake Formation通过Glue Catalog元数据+Athena/Redshift Spectrum/EMR消费者强制执行细粒度访问。

参考

每日Glue作业处理增量数据；必须不重新处理昨天的文件。

Glue作业书签。跟踪已处理的S3键/数据库行；从上次成功的检查点恢复。

原因: 书签避免了无需手动状态跟踪的重复处理。对于完全重新处理的运行禁用此功能。

参考

为事件流选择托管Kafka与Kinesis Data Streams。

现有Kafka客户端/生态系统时选择MSK。需要紧密AWS集成（Lambda触发器、Firehose、KCL）和无服务器选项时选择Kinesis。

原因: 两者都支持可重放的持久流。MSK保留了Kafka API和生态系统；Kinesis对于小型流成本更低，并且原生集成。

参考

可变Kafka吞吐量；需要无需人工操作的集群管理。

MSK Serverless。自动扩缩分区和吞吐量；按分区+数据付费。

原因: 无需Broker大小调整。对于持续高吞吐量，预置的MSK更便宜。

参考

将SQS → 过滤器 → Step Functions连接起来，无需编写胶水Lambda。

EventBridge Pipes。源 → 可选过滤器 → 可选丰富 → 目标。

原因: 取代了典型的Lambda作为胶水代码。减少了代码、成本和操作复杂度。

参考

通过新的消费者重放上周的事件，而无需从源重新发出。

EventBridge存档+重放。存档捕获匹配的事件；稍后将其重放到目标。

原因: 内置重放避免了需要单独的事件存储。对于事件恢复和新消费者的接入很有用。

参考

数百个生产者发出事件；消费者需要类型化的绑定。

带有自动发现功能的EventBridge Schema Registry。生成强类型代码绑定（Java、Python、TypeScript）。

原因: 发现功能从观察到的事件中学习模式。绑定提供了编译时安全性。

参考

高吞吐量短工作流（>10万/秒）的亚秒级计费编排。

Step Functions Express工作流。按执行毫秒计费；最长5分钟。

原因: 标准工作流具有持久性+历史跟踪，按状态转换计费。Express以牺牲审计跟踪为代价，降低了短生命周期流程的成本。

参考

通过Step Function并行处理1000万个S3对象。

分布式Map状态。并发子执行最多可达10,000个并行；直接从S3读取源。

原因: Inline Map最多可并行40个。分布式Map可扩展到S3存储桶大小的作业，而不会触及服务配额。

参考

FIFO队列需要>300消息/秒的吞吐量。

启用高吞吐量模式的SQS FIFO。每个API每个区域高达7万消息/秒；按`MessageGroupId`分区。

原因: 不进行批处理时，标准FIFO上限为300消息/秒。高吞吐量模式按组ID划分排序。

参考

多个消费者需要对同一Kinesis流具有完整的读取吞吐量。

增强型扇出（EFO）。每个消费者通过HTTP/2推送获得专用2 MB/秒/分片管道。

原因: 默认轮询在消费者之间共享2 MB/秒/分片限制。EFO以更高的成本消除了争用。

参考

Firehose到S3；数据湖查询扫描过多，因为分区是按摄取时间而非事件时间。

Firehose动态分区。从JSON中提取事件时间/租户ID；写入S3前缀`year=YYYY/month=MM/tenant=X/`。

原因: Athena/Spectrum按事件时间进行分区剪枝，可大幅降低扫描成本和延迟。

参考

移动/Web客户端需要实时更新和选择性字段获取。

带有订阅功能的AWS AppSync (GraphQL)。由WebSocket支持。

原因: GraphQL客户端仅获取请求的字段并订阅增量。REST/HTTP API Gateway强制过度获取和轮询。

参考

内部API不得从公共互联网访问。

通过接口VPC端点的API Gateway私有端点。资源策略限制为特定的VPC。

原因: 私有API只能从VPC+连接网络访问。公共API需要WAF+认证才能安全。

参考

锁定S3源，使其只能被CloudFront读取。

源访问控制（OAC）。取代传统OAI；支持SSE-KMS和所有S3功能。

原因: OAI不支持SSE-KMS对象。AWS建议所有新分发都使用OAC。

参考

限制对S3中特定付费视频的访问时间。

CloudFront签名URL（按URL）或签名Cookie（多个URL）。受信任的密钥组签署请求。

原因: S3预签名URL绕过了CloudFront缓存。CloudFront签名URL在边缘缓存并限制访问。

参考

轻量级查看器请求转换：标头重写、重定向、A/B路由。

CloudFront Functions。JS语言，亚毫秒级执行，所有边缘POP。

原因: Lambda@Edge是区域边缘的完整Node/Python——更重且更昂贵。Functions对于简单操作便宜10倍。

参考

在EKS中运行不受信任的多租户工作负载，并具有强隔离性。

EKS Fargate按Pod隔离。每个Pod都在专用的微型虚拟机中运行。

原因: 托管节点组共享内核——权限升级会跨越租户。Fargate内核隔离是EKS中最强的。

参考

EKS集群自动扩缩延迟过慢；节点组实例类型蔓延。

Karpenter。根据待处理Pod的要求即时选择实例类型。

原因: Cluster Autoscaler扩展预定义的ASG，速度慢且受限。Karpenter可在几秒内扩展任意EC2并实现多样化。

参考

EKS Pod需要最小权限IAM（避免节点实例角色共享）。

通过OIDC提供商实现服务账户IAM角色（IRSA）。使用角色ARN注解ServiceAccount。

原因: EKS Pod Identity是更新的替代方案——信任模型更简单。IRSA成熟且跨区域可用。

参考

ECS-on-EC2任务在扩缩时启动需要5-7分钟——需要<60秒。

ECS容量提供程序，在`CapacityProviderReservation`上将托管扩缩目标设为~80%。保持空闲缓冲区。

原因: 保留的缓冲区意味着新任务可立即在现有容量上运行，而ASG则启动替换。

参考

Lambda由SQS触发，但只有5%的消息匹配——浪费了调用。

带有过滤条件事件源映射。Lambda仅对匹配的消息进行调用。

原因: Lambda之前的过滤器避免了不相关消息的每次调用成本。SQS、Kinesis、DynamoDB、MQ、Kafka支持过滤。

参考

生产应用程序需要一个具有低运营开销的LLM端点。

Amazon Bedrock用于托管基础模型（Claude、Llama、Titan）。仅当需要托管自定义模型或经过严格调优的开源模型时才使用SageMaker。

原因: Bedrock仅提供API——无基础设施。SageMaker是完整的ML平台——当您拥有训练/微调生命周期时选择。

参考

选择视觉/NLP的托管AI，无需训练模型。

Rekognition（图像/视频标签、人脸、内容审核）。Comprehend（情感、实体、语言、PII检测）。Translate。Polly。Transcribe。

原因: 预训练的AWS AI服务可跳过常见任务的整个ML生命周期。仅当现成方案不适用时才使用SageMaker。

参考

Web应用程序支持电子邮件/密码+Google+Apple+SAML企业SSO。

带有托管UI的Cognito User Pool。配置OIDC+SAML IdP。应用程序接收Cognito JWT。

原因: User Pool将IdP聚合到一个令牌中。Identity Pool仅将令牌交换为AWS凭证——用于AWS API访问，而非身份验证。

参考

DynamoDB Global Tables在两个区域同时写入同一键。

按时间戳实现“最后写入者获胜”。应用程序设计幂等写入或按区域划分写入。

原因: GT复制是异步多主。冲突解决基于时间戳——应用程序必须容忍最终一致性。

参考

持续改进现有解决方案

组织内的EC2实例队列过度配置；需要自动化的大小调整建议。

在组织级别启用AWS Compute Optimizer。根据利用率窗口审查建议；导出到S3进行跟踪。

原因: Compute Optimizer使用机器学习处理CloudWatch指标。手动大小调整会遗漏工作负载形态信号。

参考

在数小时内（而非月末）捕获意外的成本飙升。

AWS Cost Anomaly Detection。机器学习监控每个服务/每个账户的支出；当超出阈值时通过SNS/电子邮件发出警报。

原因: 预算会在计划阈值时触发。异常检测会提前数天/数周捕获意外情况（密钥泄露、失控的训练任务）。

参考

当账户达到每月预算的100%时，自动暂停非必需资源。

AWS Budget actions。应用限制性IAM策略+通过SNS触发Lambda以停止非必需的EC2/RDS。

原因: 预算操作从“仅警报”变为“强制执行”。与成本异常检测结合使用以捕获未预算的支出。

参考

组织范围内的S3成本优化机会可见性。

S3 Storage Lens，具有高级指标+组织范围。显示冷存储层候选对象、IT存储层机会、废弃的多部分上传。

原因: 免费层覆盖基本指标；高级层显示复制、活动、优化建议。集中在审计/安全账户中。

参考

S3账单尽管进行了删除操作，但仍在持续增长。

生命周期规则在7天后中止“不完整的分段上传”。使用`s3api list-multipart-uploads`进行检查。

原因: 失败的上传会留下作为存储计费但未在控制台列表中显示的部件。常见的成本泄漏。

参考

冷存档数据最多每季度访问一次。

S3 Glacier Flexible Retrieval（1-12小时恢复）。对于“从不访问”的数据，使用Deep Archive（12小时检索，成本最低）。

原因: Standard-IA保持毫秒级访问；Glacier层以访问时间换取约80-95%的成本降低。

参考

降低S3+DynamoDB流量的NAT Gateway出口成本。

S3+DynamoDB的Gateway VPC端点（免费）。通过端点路由流量，绕过NAT。

原因: NAT按GB收费；Gateway端点免费。对于其他AWS服务，接口端点可减少但不能消除成本。

参考

工作负载跨AZ进行频繁通信；数据传输成本在账单中占主导地位。

尽可能将微服务部署在同一AZ中。使用VPC Lattice或带有AZ亲和性路由的服务网格。

原因: 跨AZ双向收费$0.01/GB。大规模微服务通信会累积成本。在99.95%可用性足以满足需求的情况下，牺牲一些高可用性以降低成本。

参考

到互联网的出口流量是最大的单一项目。

使用CloudFront作为所有服务的入口。CloudFront到互联网的出口成本低于直接EC2/ALB出口。

原因: CloudFront出口定价分层且显著低于区域出口。缓存进一步减少了源站出口流量。

参考

在Compute Savings Plan、EC2 Instance Savings Plan和Reserved Instances之间进行选择。

Compute SP：最灵活（任何区域、系列、操作系统）——折扣略低。EC2 Instance SP：锁定实例系列和区域——折扣更深。RI：需要容量预留的罕见情况。

原因: Compute SP涵盖Lambda+Fargate+EC2。只有在容量预留很重要的情况下，RI才优于SP；在大多数情况下，SP更具优势。

参考

无状态批处理队列在Spot实例上运行——中断率过高。

Spot Fleet采用容量优化策略，跨多个实例类型+可用区。

原因: 最低价格策略集中在单一池中——中断率高。容量优化策略选择可用容量最深的池。

参考

在不重写代码的情况下，将无状态Web层的计算成本降低约20%。

迁移到Graviton (ARM)——`c7g`、`m7g`、Lambda ARM、Aurora Graviton。测试编译二进制文件的兼容性。

原因: Graviton为大多数工作负载提供约20%的性价比提升。Java/Python/Node“开箱即用”；原生代码可能需要重新编译。

参考

降低长时间运行但可容忍中断的Fargate服务的成本。

通过容量提供程序策略使用Fargate Spot。将Spot与按需实例混合用于高可用性任务。

原因: Fargate Spot便宜约70%。任务在终止前会收到2分钟警告——与优雅耗尽结合使用。

参考

CloudWatch Logs存储成本逐月增长。

按日志组设置保留期（默认永久）。对于长期存储，导出到S3+在CW中删除。使用Logs Infrequent Access类。

原因: CW Logs的摄取+永久存储成本为$0.03/GB。S3 Standard-IA以$0.0125/GB的价格更适合归档访问。

参考

用统一的可观测性替换分散的监控，覆盖所有服务。

CloudWatch ServiceLens用于服务地图；X-Ray用于跟踪；CloudWatch Logs Insights用于即席查询；Container Insights用于ECS/EKS；RUM用于浏览器；Synthetics用于金丝雀。

原因: AWS原生堆栈避免了每个主机代理。与OpenTelemetry SDK结合使用以实现可移植性。

参考

跟踪跨5个账户中服务的请求。

X-Ray跨账户可观测性。源账户通过OAM与中央监控账户共享跟踪。

原因: 没有OAM，跟踪会按账户分散。跨账户聚合集中了请求路径视图。

参考

在一个CloudWatch控制台中查看来自多个账户的指标+日志+跟踪。

CloudWatch可观测性访问管理器（OAM）。源账户通过接收器+链接连接到监控账户。

原因: OAM是规范的多账户可观测性框架。消除了逐账户控制台跳转的麻烦。

参考

Aurora集群运行缓慢——通过等待事件找出排名靠前的SQL。

在集群上启用Performance Insights。通过负载+等待分析找出排名靠前的SQL，无需转储查询日志。

原因: PI以低开销采样等待事件。CloudWatch指标告诉你有什么东西很慢，PI告诉你具体是什么。

参考

无需编写警报阈值即可自动检测DynamoDB/RDS/Lambda/ECS中的异常。

Amazon DevOps Guru。基于机器学习的运维指标异常检测+相关事件。

原因: 静态阈值会遗漏罕见模式。DevOps Guru学习基线并根据偏离正常值的情况发出警报。

参考

在没有每个实例脚本的情况下，按计划修补5000个EC2实例。

SSM Patch Manager，带有补丁基线+维护窗口。基于标签的目标定位；在N天后自动批准安全补丁。

原因: Patch Manager集中了整个补丁生命周期。自管理脚本会漂移并遗漏新实例。

参考

在未经人工批准的情况下，自动修复Config规则失败（例如，开放式安全组）。

Config修复操作，调用SSM Automation文档。预置`AWS-DisablePublicAccessForSecurityGroup`等。

原因: Config检测；SSM Automation执行。比SNS → 人工 → 工单的循环更紧密。

参考

AMI/容器镜像黄金管道必须可重现且补丁最新。

EC2 Image Builder管道。源AMI → 配方（组件） → 测试 → 分发到区域/账户。

原因: 用托管的生命周期取代了临时的Packer脚本。安排每月补丁刷新的重建。

参考

对EC2+ECR镜像+Lambda进行持续CVE扫描。

Amazon Inspector v2，组织范围启用。调查结果流向Security Hub。

原因: Inspector v2在一个服务中涵盖EC2+容器镜像+Lambda依赖。大规模手动CVE匹配是不可能的。

参考

验证多层应用程序是否能满足1小时RTO/15分钟RPO。

AWS Resilience Hub。定义策略 → 评估应用程序 → 建议+自动化运行手册。

原因: Resilience Hub通过具体测试正式化RTO/RPO声明。手动DR运行手册会发生漂移。

参考

测试自动扩缩和故障转移在实际故障下而非假设故障下是否有效。

AWS Fault Injection Service (FIS)。模板化实验——杀死实例、限制API、注入延迟。在Game Day期间运行。

原因: 混沌工程即服务。真正的故障暴露了脆弱的假设；阅读运行手册并不能。

参考

多区域故障转移——自动化就绪检查+区域疏散。

Route 53 Application Recovery Controller。就绪检查+路由控制，实现基于单元的故障转移。

原因: 普通的Route 53健康检查评估端点。ARC添加了主动/备用控制平面，用于明确、经过审计的故障转移。

参考

升级RDS主版本并具备回滚能力。

RDS Blue/Green部署。启动带有新版本的绿色克隆；重放binlog；在<1分钟内切换。

原因: 原地主版本升级不可逆。Blue/Green在切换成功之前保持旧数据库在线。

参考

通过自动回滚减少不良部署的爆炸半径。

带有Canary配置的CodeDeploy（例如，`CodeDeployDefault.ECSCanary10Percent5Minutes`）。CloudWatch警报触发回滚。

原因: Canary在5分钟内将故障限制在10%。一次性部署具有最大爆炸半径；滚动部署可以传播但没有基于流量的门控。

参考

Lambda函数内存过度配置。

Lambda的Compute Optimizer。根据调用配置文件提供内存调优建议。

原因: AWS Lambda Power Tuning状态机是替代方案——Compute Optimizer是无需人工操作的。

参考

从观察到的CloudTrail活动中生成最小权限IAM策略。

IAM Access Analyzer策略生成。分析角色的CloudTrail；仅发出已使用的操作策略。

原因: 优于手动编写`iam:Get*`等。使用生成的策略作为起点，然后进行审查。

参考

从EC2到RDS的连接失败——无需数据包捕获即可找出原因。

VPC Reachability Analyzer。静态分析路由表、安全组、NACL、NAT、对等连接。返回阻塞器。

原因: 比tcpdump更快。识别特定的配置（哪个安全组规则，哪个NACL拒绝）。

参考

审计从互联网可以到达内部资源的哪些路径。

VPC Network Access Analyzer。范围表达式描述禁止的路径（例如，互联网 → DB层）。返回匹配的路径。

原因: Reachability Analyzer是点对点的；Network Access Analyzer是范围广泛的合规性检查。

参考

在整个组织中快速实现成本优化。

Trusted Advisor成本优化检查（需要商业/企业支持）。空闲ELB、低利用率EC2、未使用的EIP、RI利用率。

原因: TA的免费层受限；商业+解锁所有检查。具有委托管理员的组织视图显示聚合的调查结果。

参考

Lambda → RDS连接风暴耗尽数据库连接。

RDS Proxy。Lambda和RDS/Aurora之间的连接池。故障转移更快（减少约66%）。

原因: Lambda并发在最坏情况下每次调用创建一个连接。Proxy将连接多路复用到一个小型池中。

参考

长尾内容在源站的缓存未命中率过高——源站负载过重。

在靠近源站的区域部署CloudFront Origin Shield。在到达源站之前，对边缘请求进行去重。

原因: 没有Origin Shield，每个POP都会独立地向源站发出未命中请求。Shield将源站命中率降低约70%。

参考

加速工作负载迁移和现代化

以最小停机时间将200台本地服务器Lift-and-shift到EC2。

AWS Application Migration Service (MGN)。持续块级复制；每台服务器在几分钟内完成切换。

原因: MGN是AWS推荐的重托管工具（取代了SMS+CloudEndure）。按服务器切换支持基于波次的迁移。

参考

以最小停机时间将本地Oracle迁移到Aurora PostgreSQL。

Schema Conversion Tool (SCT) 用于模式+过程重写。AWS DMS用于全量加载+CDC。

原因: SCT处理代码；DMS处理数据。CDC保持源同步直到切换。

参考

发现所有本地数据库并评估迁移复杂性。

AWS DMS Fleet Advisor。大规模清单+评估异构队列。

原因: Fleet Advisor在启动DMS作业之前，将发现+大小调整整合到一个工作流中。

参考

将500个应用程序分类以制定迁移策略。

七个R框架：退役（Retire）、保留（Retain，保留在本地）、搬迁（Relocate，VMware Cloud直接迁移）、重托管（Rehost，MGN）、重平台（Replatform，RDS代替自管DB）、重新购买（Repurchase，废弃并使用SaaS）、重构（Refactor，微服务）。

原因: 大型组合通常混合所有七种策略。早期对每个应用程序进行映射可避免一刀切的迁移债务。

参考

在启动迁移波次之前，构建包含依赖关系的迁移清单。

AWS Application Discovery Service。无代理（vCenter扫描）或基于代理（每台服务器）。输出依赖关系图。

原因: 没有依赖关系映射，波次规划会遗漏紧密耦合。Discovery会自动发现它们。

参考

跟踪MGN、DMS、手动迁移中数百个进行中的服务器+数据库迁移。

AWS Migration Hub作为单一控制面板。聚合MGN、DMS、Refactor Spaces的状态。

原因: 按工具划分的控制台会分散状态。Migration Hub整合并支持组合报告。

参考

将100 TB数据从没有可用WAN带宽的远程站点移动。

AWS Snowball Edge Storage Optimized。运送设备，本地复制，返回AWS。对于>80 TB的数据，可并行使用多个设备。

原因: Snowmobile（45 PB）适用于EB级；Snowcone（8 TB）适用于小型。Edge是PB级的主力。

参考

本地NFS → S3的持续数据复制，带带宽限制。

AWS DataSync代理。计划任务；每任务带宽限制；完整性验证模式。

原因: DataSync是专门构建的，比通过WAN自管理的rsync快10倍。Snowball是离线；DataSync是在线。

参考

本地应用程序期望NFS/SMB，但数据应存储在S3中。

Storage Gateway中的File Gateway。本地缓存+S3后端；对象也可通过S3 API访问。

原因: Volume Gateway暴露iSCSI；Tape Gateway模拟VTL。File Gateway是NAS到S3的桥梁。

参考

重度依赖VMware的公司希望获得AWS侧容量，而无需重新配置vSphere/NSX。

AWS上的VMware Cloud。在裸机AWS主机上使用相同的vSphere堆栈。使用HCX进行实时迁移。

原因: 保留了操作工具。在重构之前进行桥接。之后，逐步重平台到原生AWS服务。

参考

无需重写代码即可将传统Java/.NET单体应用容器化。

AWS App2Container CLI。检查运行中的应用程序，生成容器工件+ECS/EKS清单。

原因: A2C捕获运行时配置（环境、端口、依赖项）到工作镜像中。手动容器化会遗漏不明显的依赖项。

参考

COBOL大型机现代化——转换为Java微服务。

带有Blu Age（重构）或Micro Focus（重平台）的AWS Mainframe Modernization服务。根据对运行时仿真的容忍度进行选择。

原因: 重构解锁了云原生模式；重平台更快但模拟了大型机。两者都降低了大型机许可成本。

参考

在18个月内分解单体应用，同时不冻结开发。

绞杀者模式。在单体应用前端放置API Gateway/ALB；将特定端点路由到新剥离出的微服务。

原因: 大爆炸式重写通常会失败。绞杀者模式通过路由解耦切换，在过渡期间保持单体应用的功能。

希望增量提取微服务，而无需拥有路由平面。

AWS Migration Hub Refactor Spaces。通过API Gateway+VPC实现托管应用程序/路由/服务抽象。

原因: 省去了编写绞杀者模式的底层管道。为增量提取提供了预构建的路由+VPC连接。

参考

EC2上的自管理PostgreSQL → RDS进行托管操作。

DMS用于带CDC的切换。仅当您需要OS访问或特定供应商扩展时才使用RDS Custom。

原因: RDS处理备份/补丁/HA。RDS Custom是遗留需求的应急方案，但会重新引入运维负担。

参考

从RDS MySQL迁移到Aurora MySQL以获得性能+成本。

从RDS创建Aurora只读副本，然后提升。或者当版本偏差很重要时，使用DMS实现零停机时间。

原因: 只读副本路径是引擎内最简单的。DMS处理版本差异和异构迁移。

参考

企业希望获得AWS迁移资金+最佳实践框架。

AWS迁移加速计划（MAP）。阶段：评估（MRA）、动员（MAP合作伙伴+工具）、迁移与现代化。

原因: MAP解锁了资金和结构化方法论。跳过MAP会错过两者。

参考

为执行发起人提供迁移前成本估算。

AWS定价计算器（设计配置）+迁移评估器（基于本地清单的数据驱动）。

原因: 定价计算器提供“假设”定价。迁移评估器摄取vSphere/Hyper-V数据以预测实际节省。

参考

退役自托管SFTP服务器；供应商合作伙伴需要继续使用SFTP。

由S3或EFS支持的AWS Transfer Family (SFTP/FTPS/FTP)。

原因: 托管协议服务。IAM映射用户；仅VPC端点。避免运行EC2 SSH守护程序。

参考

Lift-and-shift Windows文件共享并集成AD。

Amazon FSx for Windows File Server。加入AD；SMB；DataSync用于从本地在线同步；Snowball用于批量数据。

原因: FSx for Windows是AD原生着陆区。EFS仅适用于Linux；S3缺乏SMB语义。

参考

迁移NetApp ONTAP工作负载，同时保留所有NetApp功能（快照、FlexClone）。

Amazon FSx for NetApp ONTAP。原生ONTAP API；多协议NFS+SMB；从本地进行SnapMirror复制。

原因: 其他FSx类型不公开ONTAP特定功能。无需重新设计备份/复制即可Lift-and-shift NetApp。

参考

基于DNS的切换存在DNS缓存滞留的风险。

在CloudFront/ALB/Global Accelerator后进行切换。无需更改公共DNS即可切换后端。

原因: 缓存遵循TTL，但客户端/防火墙会积极缓存。稳定的公共地址可隔离DNS滞留问题。

参考

为了风险控制，从本地到AWS进行渐进式流量迁移。

Route 53加权路由。从1% → AWS开始，逐步增加。健康检查用于自动故障回退。

原因: 加权路由在DNS层实现了金丝雀式迁移。ARC为更高风险的切换添加了明确的门控。

参考

跨已迁移的工作负载跟踪Windows/Oracle/SQL Server BYOL许可证。

AWS License Manager。定义规则；在启动时强制执行；通过RAM在整个组织中共享。

原因: BYOL不合规代价高昂。License Manager可防止意外的过度部署。

参考

迁移后，开发/测试RDS实例在夜间过度配置。

将开发/测试迁移到具有低最小ACU的Aurora Serverless v2。空闲时自动缩减。

原因: 无需实例调度程序复杂性即可节省夜间空闲成本。

参考

在迁移期间，在本地运行Kubernetes，并使用与EKS相同的工具。

在本地硬件上运行EKS Anywhere。相同的Kubernetes版本+ECR+AWS Outposts集成。

原因: 一致的控制平面减少了操作员技能漂移。之后迁移到EKS是工作负载迁移，而不是工具重写。

参考