Amazon SAP-C02: 计算与 Auto Scaling — 学习指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

属于 AWS Solutions Architect Professional SAP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

EC2 实例设计、存储和网络

设计 EC2 实例时，首先要将工作负载特性与实例系列相匹配，以平衡 vCPU、内存、网络和本地存储。根据性能分析结果，选择计算优化型 (C)、内存优化型 (R/X)、存储优化型 (I/D) 或 GPU 型 (P/G) 实例。利用基于 Nitro 的实例和 ENA/SR-IOV 实现高网络吞吐量和低延迟。对于延迟敏感或需要高 IOPS 的临时数据，可考虑使用 I3/I4 或 Nitro SSD 上的实例存储（临时存储）；对于持久性块存储，请使用具有预置 IOPS (io2/io2 Block Express) 的 EBS，并启用 EBS 加密与 KMS 进行密钥管理。当实例位于 Application Load Balancer 后端的 VPC 中时，请确保面向互联网的 ALB 放置在公有子网中，而目标实例则位于私有子网中；错误放置 ALB 或错误配置安全组是一个常见的陷阱。使用置放群组（cluster 用于低延迟 HPC，partition 用于大规模分布式有状态系统，spread 用于故障隔离）来影响实例的放置，但要接受其权衡：cluster 提供最佳性能，但会降低可用区级别的容错能力。对于传输中加密的数据，可在 ALB 上终止 TLS，或使用 NLB 直通实现端到端 TLS。决策标准需要权衡成本与性能：更密集的实例类型可降低成本，但可能会增加爆炸半径和许可成本；推荐使用 CloudWatch、AWS Compute Optimizer 和负载测试来驱动实例规格的优化（right-sizing），而不是依赖经验法则。

Auto Scaling Groups、策略和生命周期管理

Auto Scaling Groups (ASG) 的设计应旨在实现弹性、韧性和成本效益，这需要结合使用启动模板、混合实例策略、生命周期挂钩和扩展策略。使用启动模板对 AMI、实例类型覆盖、EBS 配置和用户数据进行版本控制；采用容量优化型 Spot 分配策略或多样化策略的混合实例可降低中断风险并降低成本。对于扩展行为，对于可预测的指标（CPU、每个目标的请求计数），首选目标跟踪策略；当需要基于阈值的多阶段操作时，则使用步进扩展策略；预测性扩展可以为已知的昼夜模式预先配置容量。实施生命周期挂钩，在实例终止前运行自定义初始化或连接耗尽任务；结合使用暖池以缩短服务就绪时间，并使用计划扩展来满足工作时间的基线容量。健康检查应整合 ELB 和 EC2 的健康检查，以避免实例被过早替换。注意一些陷阱，例如因冷却时间过短导致的缩容抖动、混合 ASG 中实例权重设置不当，以及未考虑应用程序的预热时间。对于有状态服务，避免快速缩容导致内存中缓存丢失；在成本与韧性之间权衡时，由 Spot 实例支持并以降级到按需实例为后备的容量可以节省成本，但需要处理中断，而 100% 的按需实例则以更高的成本最大限度地提高了可预测性。

容器与编排：ECS、EKS 和 Fargate 的选择

在 Amazon ECS、EKS 和 Fargate 之间进行选择，取决于运营模型、控制需求和工作负载模式。Fargate 无需管理节点，非常适合优先考虑运营简单性的团队，但其单位 vCPU 定价较高，且临时存储有限；它支持 Fargate Spot 以节省成本。对于希望进行容器编排但又不想引入 Kubernetes 复杂性的客户，ECS 提供了与 AWS 的紧密集成和简单性。当需要 Kubernetes 生态系统、可移植性或高级调度功能时，EKS 是合适的选择；可考虑使用托管节点组或自管理节点 + Karpenter 来实现动态的规格优化。网络限制（ENI/Pod 密度）和 CNI 的行为会影响 Pod 密度和节点大小；在 EKS 上，使用 IAM Roles for Service Accounts 和用于持久卷的 EBS CSI 可以减少凭证泛滥，并实现 Pod 级别的存储。对于共享文件系统，根据吞吐量和延迟需求使用 EFS (NFS) 或 FSx (Lustre)；避免将基于 NFS 的容器用于高元数据操作的场景——首选 EFS，并根据工作负载调整其吞吐量模式。实施 cluster autoscaler 或 Karpenter 进行节点扩展，并使用 ALB/ECS 服务指标进行服务自动扩展。常见的陷阱包括忽略 Pod 中断预算、低估 Kubernetes 控制平面的配额，以及过度预配置节点而不是使用箱式打包（bin-pack）策略——最终的选择应由控制力、成本和运营开销之间的权衡来驱动。

无服务器计算模式、Lambda 约束和事件驱动设计

无服务器计算减少了运维开销，但需要采用能够解决并发、状态和下游系统限制的架构模式。Lambda 非常适合短时、事件驱动的任务、通过 API Gateway 或 ALB 实现的 API 后端，以及使用 SQS 或 SNS 进行的异步处理。使用 Step Functions 来编排长时间运行的工作流，并使用 DynamoDB 或 RDS Proxy 进行数据库访问以缓解连接风暴。注意由 ENI 创建引起的 Lambda VPC 冷启动开销；对于延迟敏感的端点，可通过预置并发来缓解，或使用 VPC 端点和 RDS Proxy 来限制连接。通过 SNS + SQS 实现扇出/扇入模式，或使用 Kinesis/MKS 进行有序流处理；使用 SQS 死信队列和幂等处理程序来管理重试和重复项。应规划并发限制、预留并发和节流，以避免级联故障；通过节流、带抖动的重试和断路器（API Gateway 或自定义）来设计反压机制。成本性能权衡很明确：Lambda 对于突发性、短时工作负载具有成本效益，而 Fargate 或 EC2 更适合持续的高 CPU 或长时间运行的任务。常见的陷阱包括：依赖同步重试导致下游系统过载、将状态存储在本地 /tmp 目录并期望其持久化，以及未为延迟关键型流程中的冷启动进行预置。

实践问题：NovaTel 企业的联络中心迁移

场景：NovaTel 企业运营着一个混合式联络中心，其呼叫路由在本地（on-premises），并通过 Direct Connect 连接到 AWS。他们在两个可用区中的 EC2 上运行会话代理，并希望迁移到一个 AWS 托管的联络中心，以实现本地 PBX 和云服务之间的高可用性和可预测的延迟。

挑战：他们需要为 SIP 流量提供低延迟连接，一个可扩展且能容忍 Spot 实例中断的语音处理计算层，以及一个跨区域的灾难恢复（DR）策略，同时不增加运维复杂性。

推荐方法：

预置 Amazon Connect 以实现联络中心功能，并使用 Site-to-Site VPN 或带有 AWS Transit Gateway 的 Direct Connect 来实现低延迟的 SIP 中继，该中继终止于会话代理前面的、启用了 TLS 直通的 NLB。
将会话处理组件作为混合 Auto Scaling 组运行，使用启动模板配置容量优化的 Spot 实例并辅以按需实例作为后备。同时，使用置放组（扩展策略）对关键代理进行故障隔离。
对于需要临时低延迟存储的有状态呼叫媒体，使用实例存储支持的实例（Nitro）进行媒体缓冲，并将话单元数据复制到启用了多可用区复制的 DynamoDB 或 ElastiCache；对于持久化数据，采用 RDS（多可用区）或 Aurora Global DB，并配置跨区域只读副本以实现灾难恢复。
实施生命周期挂钩和 Warm Pool 以最大限度地减少代理的冷启动，使用 Route 53 加权故障转移实现跨区域灾难恢复，并利用 CloudWatch + SNS/SQS 进行告警和自动化故障转移运行手册。

基本原理：使用托管的联络中心服务可以减轻运维负担，而带有 Spot 实例的混合 ASG 则可以优化成本；将临时媒体隔离在实例存储上可以保持性能，而将持久状态复制到 DynamoDB/ElastiCache 以及使用多可用区 RDS/Aurora 则提供了弹性和快速故障转移能力，这符合专业架构的最佳实践。

← 安全、身份与合规性 · 所有领域 · 存储与数据管理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →