AWS Auto Scaling 是跨服务的统一扩展平台，支持 EC2、ECS、DynamoDB、RDS 等资源的动态调整，通过目标利用率策略（如“当 CPU 利用率超过 70% 时增加实例”）实现自动化扩展。其核心优势在于多服务协同，例如可同时扩展 EC2 实例与关联的 DynamoDB 表吞吐量，避免因单点瓶颈导致扩展失效。
Amazon EC2 Auto Scaling（简称 EC2 ASG）专注于 EC2 实例的精细化管理，提供预测性扩展（基于机器学习分析历史负载模式）和生命周期钩子（在实例启动 / 终止前执行自定义脚本，如数据备份）。官方明确指出，EC2 ASG 是 AWS Auto Scaling 的底层组件，后者通过调用前者 API 实现 EC2 实例的扩展，但前者支持更复杂的跨服务编排。例如，AWS Auto Scaling 可配置“维持 EC2 实例组 CPU 利用率在 60%”的通用策略，而 EC2 ASG 需单独定义“基于 CloudWatch 警报触发扩展”的规则。
AWS Auto Scaling 的跨服务特性虽能提升扩展效率，但易因依赖链断裂引发系统性风险。例如，扩展 EC2 实例时若未同步调整 RDS 连接池或 ElastiCache 缓存节点，可能导致数据库连接耗尽或缓存命中率下降，最终抵消扩展效果。此外，其区域限制是另一痛点：AWS Auto Scaling 仅支持单区域内资源扩展，多区域应用需手动部署多组配置，增加运维复杂度。相比之下，EC2 ASG 的难点在于实例生命周期管理。例如，使用 Spot 实例时，若未在 ASG 中配置混合实例策略或优先级规则，可能因 Spot 实例回收导致容量骤降；而生命周期钩子的误配置（如未设置足够的预热时间）可能导致新实例未完全初始化就被加入负载均衡，引发响应延迟。成本管控方面，两者均需警惕过度扩展：AWS Auto Scaling 可能因未设置实例数量上限或未绑定预留实例（RI）导致按需实例费用激增，而 EC2 ASG 的动态策略若未结合冷却时间（Cooldown Period）可能因短期波动触发频繁伸缩，加剧资源浪费。
备考时需重点掌握服务选择逻辑：若应用仅需扩展 EC2 实例，优先使用 EC2 ASG 以利用其预测性扩展和生命周期钩子；若需协调多服务（如同时扩展 EC2 与 DynamoDB），则选择 AWS Auto Scaling。对于 AWS Auto Scaling，需熟悉扩展计划（Scaling Plan）的配置。例如通过 AWS CloudFormation 模板定义不同资源组的扩展策略，或利用 AWS Cost Explorer 分析历史负载数据优化目标利用率阈值。针对 EC2 ASG，需掌握混合实例策略（如结合 Spot 与按需实例降低成本）和健康检查配置（如结合 ELB 实现跨可用区流量分发）。此外，需通过实战场景理解故障注入测试的重要性：例如，使用 AWS Fault Injection Simulator（FIS）模拟 EC2 实例终止，验证 ASG 的自动替换能力及生命周期钩子的执行效果。最后，需熟悉安全合规配置，如通过 AWS IAM Access Analyzer 限制 Auto Scaling 角色的权限，避免因过度授权导致实例被恶意扩展。