Amazon SAA-C03: 计算、Auto Scaling 与实例管理 — 学习指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

EC2 实例类型与 AMI

选择正确的 EC2 实例系列是构建良好计算层的基础，因为实例系列、代数和规格共同决定了 CPU 架构、内存与 vCPU 的比例、网络带宽以及可用的加速器。通用型 (M6i, M7g, T-系列) 适用于均衡的 Web 层和混合工作负载。计算优化型 (C7i, C7gn) 适合 CPU 密集型的模拟、编码、批处理和 Web 前端。内存优化型 (R7i, X2idn) 专为内存数据库和缓存设计。存储优化型 (I4i, D3) 专为 NoSQL、HDFS 和数据仓库设计。加速计算型 (P5, G5, Trn1, Inf) 提供 GPU 或 ML 芯片。对于可干净编译到 ARM64 的横向扩展工作负载，Graviton (g 后缀) 实例通常能提供 20-40% 的性价比提升。

T 系列是可突发的，并默认为标准模式，即 CPU 积分在空闲时累积，在突发时消耗；当积分耗尽时，性能会限制到基准水平。对于具有不可预测峰值的工作负载——例如小型 Web 层、开发/测试环境，或支持有突发流量前端的 Elastic Beanstalk 环境——处于无限模式下的 T 系列实例允许实例借用积分，并按超出部分的 vCPU 小时数收取少量附加费，从而避免用户可见的性能限制。这就是为什么对于有短暂 CPU 饱和的 Beanstalk 环境，通常通过启用无限模式而不是升级到更昂贵的计算优化型实例系列来解决问题。将 T 系列实例用于真正有突发性、平均负载低的工作负载非常重要：在标准模式下持续的 CPU 使用会在几分钟内耗尽积分。

垂直扩展（在同一系列内更换为更大规格的实例）受限于可用的最大实例规格，变更时需要停机，会引入单点故障，并且无法跨可用区分布工作负载。当负载变化显著时，使用 Auto Scaling 组进行水平扩展才是正确的解决方案。

黄金 AMI 将应用程序代码、运行时和依赖项烘焙到根快照中，从而实现快速、确定性的启动——这在 Auto Scaling 应对流量高峰时至关重要。每次启动时都通过用户数据进行引导，恰恰会在最不应该的时候增加数分钟的延迟。

存储选择：实例存储 vs EBS、快照与快速快照还原

实例提供两种存储基底：实例存储（附加在物理主机上的临时 NVMe）和 Amazon EBS（网络附加块存储）。实例存储提供最低的延迟，但其数据会在实例停止、休眠、终止或发生硬件故障时被销毁。将其视为持久化存储是一个常见且危险的错误——它只适用于临时空间、缓冲区、缓存或复制数据，例如 HDFS 数据节点（其副本存在于其他节点上）。持久化数据应放在 EBS 上，并通过存储在 S3 中的快照进行备份。

快照一旦创建，就是增量且独立的，因此将快照恢复到新卷永远不会影响源卷。将大型生产数据集复制到测试环境的典型方法是为源卷创建快照，然后从该快照创建新卷。但是，从快照恢复的卷在首次读取时会从 S3 延迟加载数据块，这会导致显著的 I/O 延迟，直到每个数据块都被预热加载。同样的延迟加载问题也会影响从根快照较大的 AMI 启动的新实例——它们在启动后的几分钟内会显得反应迟钝。

EBS 快速快照还原 (FSR) 消除了这种性能损失。在 ASG 启动实例的可用区中，为快照启用 FSR，从该快照创建的卷能立即提供完整的预置性能：

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

当横向扩展事件必须在数秒而不是数分钟内增加容量时，这一点至关重要。

使用 ENA 和 EFA 的增强联网

宣称的网络吞吐量随实例规格的增大而提升，但只有在存在弹性网络适配器 (ENA) 驱动程序时才能实现。ENA 提供基于 SR-IOV 的增强联网功能，在较新的实例上支持高达 200 Gbps 的速率。现代的 AMI (Amazon Linux 2, 近期版本的 Ubuntu, Windows) 已预装并启用了 ENA；使用以下命令验证：

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

如果没有 ENA，实例会静默地回退到较低的吞吐量和较高的抖动，无论选择哪种置放群组，这都会破坏任何低延迟设计。

对于微秒级的集合通信——例如 CFD、气象建模、分子动力学、大模型训练——请添加弹性结构适配器 (EFA)。EFA 向 MPI 和 NCCL 暴露了一个操作系统旁路传输层 (Libfabric)，从而完全绕过内核网络堆栈。EFA 只有在集群置放群组内、且在受支持的实例类型（c7gn, hpc7a, p5）上才能发挥其优势，并需要 EFA 驱动程序以及兼容的 MPI (Open MPI, Intel MPI) 或 NCCL 构建。

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

放置组

放置组控制实例的物理拓扑结构：

选择不当会浪费此功能。集群放置组无法跨越可用区——其设计就是可用区内的。由于每个可用区最多 7 个实例的上限，分散放置组无法承载数百台 Web 服务器。对于一个 40 节点的 Kafka 集群，分区放置（而非分散放置）是正确的工具，因为它能将副本的放置与故障域对齐。为实现通用的高可用性，不要将 ASG 限制在单个可用区的单个放置组中——应将 ASG 分散到多个可用区。

对于需要最低节点间延迟的流式分析或 MPI 工作负载，正确的组合是集群放置组加上启用 ENA 的实例；集群放置组减少了网络跳数，而 ENA 提供了实现该延迟优势所需的每秒数据包处理能力。

Auto Scaling 组和启动模板

Auto Scaling 组 (ASG) 是一个运行时单元，它根据三个整数——MinSize、DesiredCapacity、MaxSize——以及一个子网列表，在一个或多个可用区中维护所需数量的 EC2 实例。ASG 本身不描述要启动什么；这由启动模板负责，它是启动配置的现代替代品。启动模板支持版本控制、混合实例策略、Spot/On-Demand 实例混合、IMDSv2 强制执行、容量预留以及 T 系列实例的无限模式。启动模板引用一个 AMI、实例类型、安全组、IAM 实例配置文件、用户数据和块储存设备映射。

典型的无状态 Web 模式是 AMI + 启动模板 + ASG + ALB。AMI 提供快速启动；ALB（或用于 TCP/UDP 的 NLB）分发流量并驱动健康检查；ASG 自动将新实例注册到目标组并终止不健康的实例。多可用区部署（至少两个可用区，对于需要仲裁的系统则为三个）是强制性的——一个绑定到单个子网的 ASG 无法在可用区中断中幸存，因为在可用区受损期间 ASG 本身无法启动替代实例。

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

扩展策略：目标跟踪、步进、计划、预测

ASG 扩展有四种模式，每种模式解决不同的问题：

• 目标跟踪 选择一个指标并将其维持在设定点附近（例如，ASGAverageCPUUtilization = 50%，ALBRequestCountPerTarget = 1000）。它是自调节的——AWS 管理警报并根据指标的偏离程度调整速度。这应该是默认选择。
• 步进扩展 根据指标超出范围的程度，分级增加或减少容量，适用于响应幅度必须与警报严重性成比例的场景。
• 简单扩展 这是旧版策略：每次警报只进行一次调整，在冷却期间会阻塞，新设计中不应选择。
• 计划扩展 在 cron 表达式指定的时间更改 MinSize/DesiredCapacity/MaxSize。
• 预测性扩展 使用机器学习分析长达 14 天的历史数据来预测未来 48 小时的情况，在高峰到来之前预先配置容量。

动态扩展本质上是滞后的——它只有在指标突破阈值后才做出反应，而新实例需要几分钟时间来启动、注册和预热。对于一个办公应用，所有用户都在 09:00 上线，并在 ASG 追赶负载时经历 2-3 小时的缓慢，单独使用动态扩展是错误的答案。在高峰到来之前，通过计划操作来提高 MinSize 和 DesiredCapacity：

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

然后让目标跟踪来吸收剩余的波动。当高峰的形状稳定但其确切时间每天都有漂移时，预测性扩展是正确的选择。对于可预测的非生产环境关停（例如开发环境在夜间和周末关闭），在周五晚上设置 desired=0, min=0 并在周一早上恢复的计划操作是开销最小的解决方案——ASG 本身就是调度引擎，无需 Lambda 或 EventBridge 等粘合代码。

指标的选择与策略的选择同等重要。CPU 指标适用于 CPU 密集型的 Web 工作负载，但对于从 SQS 拉取消息的积压驱动型工作进程，您必须根据队列深度而不是 CPU 进行扩展：一个因 I/O 阻塞的工作进程可能只显示 10% 的 CPU 使用率，而队列中却积累了数百万条消息。使用每个实例的 ApproximateNumberOfMessagesVisible 指标，可以将其作为自定义指标发布，或通过内置的 SQSQueueBacklogPerInstance 目标来实现：

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

同样，对延迟敏感的 HTTP 层应跟踪 TargetResponseTime 或 RequestCountPerTarget；受内存、磁盘或下游延迟限制的应用程序应发布一个能反映真实瓶颈的自定义指标。当 CPU 不是瓶颈时，基于 CPU 进行扩展会精确地导致这样一种故障模式：实例永远不会横向扩展，队列无限增长，ALB 返回 5xx 错误。

健康检查与生命周期挂钩

ASG 默认使用 EC2 状态检查，这种检查能发现虚拟机监控程序的故障，但无法发现应用程序的故障。在 ASG 上启用 ELB 健康检查，可以将替换决策委托给负载均衡器的应用程序级探测，这在操作系统正常但进程卡住的情况下至关重要。请将 HealthCheckGracePeriod 设置得足够长，以确保用户数据脚本执行完毕；否则，新实例会在引导过程中被终止，从而陷入循环。

负载均衡器的选择会影响“健康”的定义：

一个位于 NLB 后端的 HTTP 应用程序，如果只进行 TCP 健康检查，会继续将流量发送到那些能接受连接但返回 500 错误的实例。要恢复有意义的信号传递，应切换到 ALB，或在 NLB 上配置 HTTP 健康检查。

生命周期挂钩会将实例在 Pending:Wait 或 Terminating:Wait 状态暂停，以便外部自动化系统可以介入操作。启动时，挂钩可以让你在 ALB 发送流量之前，将实例注册到配置管理系统、预热缓存或拉取密钥。终止时，挂钩可以让你排空会话、刷写日志以及从服务网格中注销。挂钩会发出 EventBridge 事件；处理程序必须调用 CompleteLifecycleAction，否则挂钩会超时并进入其默认状态（CONTINUE 或 ABANDON）。

暖池与休眠

对于那些需要加载大型模型、预热缓存或在提供服务前进行 JIT 编译的应用程序来说，冷启动时间是一个现实问题。暖池是附加到 ASG 的一个预初始化资源池：实例启动、运行引导脚本，然后被停止、保持运行或休眠，并保留在池中，直到 ASG 需要横向扩展。从池中拉取实例可以跳过数分钟的启动时间。

休眠功能将操作系统状态挂起到加密的 EBS 根卷，这样 JVM 堆、机器学习权重和操作系统页面缓存可以在恢复时重新加载。要求：加密的根卷大小足以容纳内存内容，实例内存 ≤ 150 GB 且属于支持的实例族，并在启动时设置 HibernationOptions.Configured = true。一个 PoolState: Hibernated 的暖池结合了两者——实例在停止期间不产生计算费用，并能在数秒内恢复，内存中已填充好数据。当应用程序“在高效工作前需要很长时间加载内存”时，这是一种正确的模式。

不可扩展工作负载的自动恢复

并非所有工作负载都能水平扩展。那些具有 MAC 绑定的许可证、基于文件的锁或没有共享存储的内存中会话状态的传统应用程序，无法在多个实例上运行——启动额外的节点会导致数据损坏或许可证违规。对于这些应用，弹性来自于自动恢复，而非横向扩展。

有两种模式可行。一个基于 StatusCheckFailed_System 的 CloudWatch 警报与 EC2 恢复操作相结合，可以在底层主机发生故障时，保留实例 ID、私有 IP、弹性 IP 和 EBS 挂载。更简单的是：一个 MinSize=MaxSize=1 且跨多个可用区的 ASG 可以替换失败的实例，并且与恢复操作不同，它能应对可用区故障——前提是状态已从根卷中外部化，或者 AMI 是可重建的。

负载均衡器与子网放置

ALB 工作在 L7，终止 HTTP/HTTPS，提供主机/路径/标头路由、HTTP/2、WebSockets、WAF/Cognito/OIDC 集成。NLB 工作在 L4，保留客户端 IP，支持静态 IP 和 TLS 穿透、PrivateLink，并能维持每秒数百万的连接。Gateway Load Balancer 将第三方设备（如防火墙、IDS）插入流量路径中。

子网放置是架构中最常出错的地方。一个面向互联网的 ALB 必须附加到公有子网——即具有指向互联网网关（IGW）的 0.0.0.0/0 路由的子网——每个目标所在的可用区都需要一个。目标本身应位于私有子网中。如果 ALB 被放置在私有子网中，或者所谓的“公有”子网缺少到 IGW 的默认路由，客户端将会遇到连接超时。要实现目标可达性，目标安全组必须允许来自 ALB 安全组在目标端口上的入站流量；在同一 VPC 内的 ALB 和目标之间不需要 NAT。

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

在 ASG 上启用 ELB 健康检查，这样不健康的目标会被替换，而不仅仅是被注销。跨区域负载均衡（ALB 默认开启，NLB 可选开启）可以均匀分配请求，不受各可用区实例数量的影响。Route 53 必须通过别名记录（或跨多个 ALB 的加权/延迟策略）解析到 ALB——绝不要将 Route 53 指向单个 EC2 的 IP，因为故障实例在 TTL 过期前会一直接收流量，而 ASG 替换的新实例会有不同的 IP。

购买模式与混合实例集

无论架构模式如何，选择购买模式是降低 EC2 开销最有效的单一手段。

合理的策略是：使用预留实例或 Savings Plan 覆盖基准负载，使用按需实例处理突发负载，使用 Spot 实例运行容错工作。在 ASG 中，这通过混合实例策略来表达：

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

多样化实例类型可以加深 Spot 池，减少相关性中断。price-capacity-optimized（或 capacity-optimized）策略在价格和池深度之间取得平衡，从而降低实例被回收的可能性。

Spot 适用于无状态 (stateless)、可设置检查点 (checkpointable)、可重试 (retriable) 或水平冗余 (horizontally redundant) 的工作负载：ALB 后端的 Web 工作节点、带自动重试的 Batch 作业、Spark 执行器、CI 运行器。它不适用于为关键的、需要持续在线的服务提供唯一容量的场景，例如有状态的主数据库或没有恢复路径的领导节点——两分钟的中断通知无法保证安全关机，并且特定实例类型的整个实例集发生相关性回收是一种真实的故障模式。当需求明确指出“不得中断”时，Spot 就不符合条件。

反之，一个常见的陷阱是将 RI 或 Savings Plan 应用于真正可变的工作负载：无论是否使用，您都需要支付每小时的承诺费用，因此，一个每周运行40小时的工作负载如果使用了168小时的承诺，将浪费76%的预留。当关注点是容量本身——而不是价格时（例如事件驱动的激增、灾难恢复），应使用按需容量预留 (On-Demand Capacity Reservation)：这是一种在可用区 (AZ) 范围内的纯容量保证，按需付费，并可与 Savings Plan 结合以获得折扣。

无服务器计算：Lambda 和 Fargate

无服务器将容量管理的责任转移给了平台。Lambda 适合事件驱动的、短时运行的工作：S3 ObjectCreated 触发器、DynamoDB Streams、低容量的 SQS 消费者、API Gateway 后端、粘合逻辑。内存（128 MB – 10,240 MB）会按比例分配 CPU，因此调高内存通常可以通过缩短执行时间来降低成本。硬性限制定义了其适用范围：最长执行时间15分钟、10 GB 内存、10 GB /tmp 空间、250 MB 未解压的部署包（或通过容器镜像的 10 GB）、6 MB 同步负载。使用 Lambda 进行30分钟的视频转码、数小时的 ETL 或 GPU 训练在架构上是错误的——函数会在工作中途超时，而重试逻辑只会加倍浪费。对于延迟敏感的路径，可以使用 Provisioned Concurrency 来缓解冷启动和 VPC 附加 ENI 的初始化时间。

Fargate 可以在无需管理 EC2 主机的情况下运行容器。当任务超过15分钟、需要自定义运行时，或者适合 ECS/EKS 编排但团队不想管理容量时，Fargate 是正确的选择。Fargate 的每 vCPU-小时成本高于 EC2 Spot，因此当稳态利用率高且可预测时，在 ECS 上使用带有 Spot 的混合实例 ASG 会更便宜。对于突发性或不可预测的流量，Fargate 的按秒计费更具优势。

对于跨多个 Lambda 的编排，Step Functions 比通过 SNS/SQS 链式调用更优，因为它提供了可视化的执行历史、重试语义、集中的错误处理和持久化状态。标准工作流按状态转换计费，最长可运行一年；Express 工作流则针对高容量、短时间的事件处理进行了优化。

对于需要扇出成千上万个参数化容器作业的场景——例如基因组学、蒙特卡洛模拟、ETL——AWS Batch 负责处理排队、依赖解析、重试以及在托管的 EC2、Spot 或 Fargate 上进行资源配置。作业引用一个作业定义（容器 + vCPU/内存 + IAM 角色），Batch 会将它们打包到大小合适的实例上。Step Functions 经常在一个状态机内编排 Batch、Lambda 和 ECS。

Elastic Beanstalk

Beanstalk 是一个托管的 PaaS，它能根据应用程序包自动配置 ALB、ASG、EC2 实例以及可选的 RDS。它支持滚动、带附加批次的滚动、不可变和蓝/绿部署，并与 CloudWatch 集成。扩展策略作为环境选项（指标、阈值、最小/最大值）暴露出来。由于 Beanstalk 默认使用可突发实例类型，启用 T-unlimited 模式是解决短暂 CPU 饱和问题的低成本方案。计划的扩展操作可以像其他操作一样附加到 Beanstalk 管理的 ASG 上。当团队希望获得标准的 Web 应用拓扑结构，而不想手动编写 CloudFormation，并且滚动更新和版本化部署包的模式符合其发布节奏时，应选择 Beanstalk。

使用 Systems Manager 进行实例集管理

SSH 和堡垒机的模式既脆弱，安全成本又高昂。AWS Systems Manager 可以取而代之。只需 SSM Agent（已预装在 Amazon Linux 2、Ubuntu、Windows 上）和一个授予 AmazonSSMManagedInstanceCore 权限的实例配置文件即可。

• Run Command 跨越带有标签的实例集执行 shell/PowerShell 命令，并整合输出。
• Session Manager 通过 AWS API 开启交互式 shell——无需入站 22 端口，无需堡垒机，完整的 IAM 身份验证，并且会话可记录到 S3 或 CloudWatch Logs。
• Patch Manager 使用维护时段按计划应用操作系统补丁。

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

计划性启停自动化

对于必须在工作时间之外关闭的非生产环境 EC2 和 RDS，低维护成本的模式是 EventBridge Scheduler → Lambda。一条 cron 规则 (cron(0 19 ? * MON-FRI *)) 调用一个 Lambda 来停止带有标签的资源；另一条在 07:00 的规则则启动它们。

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

这是无服务器模式，没有需要打补丁的实例集，并可根据标签进行扩展。AWS Instance Scheduler 解决方案的作用与此相当。一个细节：已停止的 RDS 实例会在七天后自动启动，因此停止计划必须周期性执行以再次停止它。结合 ASG 的计划性操作在周末将容量降至零，闲置时间的成本可趋近于零。

规模化计算相关的网络陷阱

NAT Gateway 的放置。 一个 NAT Gateway 位于一个可用区（AZ）中。如果一个横跨三个 AZ 的实例集将其所有出口流量都通过位于 us-east-1a 的单个 NAT 路由，那么来自 us-east-1b/us-east-1c 的每个数据包都需要支付跨可用区传输费用，并且当 us-east-1a 发生故障时，将完全失去出口连接。正确的模式是每个 AZ 配置一个 NAT Gateway，每个私有子网的路由表都指向其所在 AZ 的 NAT。这能将流量本地化，并消除单可用区故障模式。

NAT 实例。 随着实例集的增长，单个基于 EC2 的 NAT 实例会成为带宽和 PPS（每秒数据包数）的瓶颈，并且是一个单点故障（SPOF）。托管的 NAT Gateway 每个可扩展至 100 Gbps。对于 AWS 服务流量，VPC 端点（S3/DynamoDB 使用网关类型，其他服务使用接口类型）可以完全绕过 NAT，从而在扩展事件中降低成本并消除饱和风险。

常见的设计陷阱

• 单可用区 ASG 无法在可用区中断中幸存——应始终关联至少两个可用区的子网（对于仲裁系统则为三个），并保持 MinSize ≥ 2。
• 假设所有工作负载都能水平扩展。 对于持有状态、单点写入或无法集群授权的应用，使用 ASG 会使情况变得更糟。应首先使用自动恢复或进行重构。
• 对可预测的峰值使用反应式扩展 会导致“最初 2-3 小时响应迟缓”的症状。应使用计划性或预测性扩展进行预热。
• 当 CPU 不是瓶颈时，仍基于 CPU 进行扩展。 应发布能反映真实瓶颈的指标——例如队列深度、响应时间、连接数。
• 简单扩展和启动配置是旧版功能——应优先使用目标跟踪和启动模板。
• 对 HTTP 应用仅使用 TCP 健康检查 会让故障实例留在轮换中。应使用 HTTP 检查（通过 ALB，或 NLB 的 HTTP 模式检查）。
• 对有状态或不可中断的工作负载使用 Spot 实例——Spot 要求工作节点是可设置检查点、可替换的。
• 对真正可变的工作负载使用预留实例或 Savings Plans——未使用的承诺是纯粹的浪费；应通过容量优化和使用 Spot 实例来降低成本。
• 将 Route 53 指向单个 EC2 的 IP——应路由到 ALB 的别名记录，以便 DNS 能反映实例集的变动。
• 将实例存储视为持久性存储——数据在实例停止、终止或主机故障时会丢失。
• 忽略快照恢复或 AMI 启动后的延迟加载延迟——应在目标可用区启用 Fast Snapshot Restore。

所有领域 · 容器与编排 →

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

浏览 Amazon →