aws-cli 实操指南用aws autoscaling update-auto-scaling-group动态调整 Auto Scaling 组配置【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli导读在 AWS 云环境中Auto Scaling 组ASG的配置往往需要随业务负载、架构演进和安全策略的变化而持续调整从单纯的容量上下限调整到切换启动模板、启用混合实例策略再到配置负载均衡健康检查与终止策略。本文以 aws-cli 仓库中官方示例文档 update-auto-scaling-group.rst 为骨架逐一拆解aws autoscaling update-auto-scaling-group命令的 6 个典型实战场景并结合仓库内 autoscaling 服务模型UpdateAutoScalingGroupType结构定义深入讲解每个核心参数的语义、默认值与约束帮助你准确、安全地在线变更 Auto Scaling 组配置。命令概览语义与使用前提UpdateAutoScalingGroup是一个增量更新接口。根据 service-2.json 中的操作定义其核心语义如下更新时只需指定 Auto Scaling 组名称AutoScalingGroupName必填以及你想变更的属性未指定的属性在本次请求中不会被改变新的设置会在本次调用返回之后的下一次扩容/缩容活动中生效如果为组关联了新的启动配置或启动模板新实例会使用最新配置而已有实例仍按最初启动时的配置运行将组从单一启动模板切换为混合实例策略时已有实例可能被逐步替换以匹配新的购买选项——例如当前是 100% On-Demand、策略指定 50% Spot则约一半实例会被终止并重新以 Spot 方式启动。替换过程采用先启动新实例、再终止旧实例的顺序避免影响应用的性能与可用性操作可能返回的错误包括ScalingActivityInProgressFault缩放活动进行中、ResourceContentionFault资源竞争与ServiceLinkedRoleFailure服务相关角色故障。由于该接口采用 POST 协议见 service-2.jsonCLI 层通过 clidriver.py 将参数序列化为请求体发送所有示例执行成功时均不产生输出这是 Auto Scaling 系列更新型命令的典型行为。示例 1调整组的容量上下限min-size / max-size容量边界是 Auto Scaling 组最常调整的属性。以下命令将名为my-asg的组的最小实例数更新为 2、最大实例数更新为 10aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --min-size 2 \ --max-size 10执行成功时命令不产生任何输出。可配合 describe-auto-scaling-groups.rst 中的aws autoscaling describe-auto-scaling-groups查看生效后的配置。调整容量边界的联动规则服务模型文档service-2.json给出了三条必须了解的联动规则调低 DesiredCapacity若因新的DesiredCapacity低于组当前规模而发生缩容活动Auto Scaling 会依据组的终止策略Termination Policies决定终止哪些实例仅调高 MinSize若只指定了新的MinSize而未指定DesiredCapacity且新MinSize大于组当前规模则组的DesiredCapacity会被自动设置为新的MinSize仅调低 MaxSize若只指定了新的MaxSize而未指定DesiredCapacity且新MaxSize小于组当前规模则组的DesiredCapacity会被自动设置为新的MaxSize。此外DesiredCapacity必须大于等于最小规模且小于等于最大规模service-2.json。三种容量字段在模型中的定义分别为AutoScalingGroupMinSize、AutoScalingGroupMaxSize、AutoScalingGroupDesiredCapacityservice-2.json均为整数类型。关于 MaxSize 的一个特殊注意事项服务模型对MaxSize附带一条重要说明service-2.json使用带实例权重的混合实例策略时Auto Scaling 可能为了满足容量需求而暂时超过MaxSize但永远不会超过MaxSize与最大实例权重的差值权重定义了每个实例对组期望容量的贡献单位数。如果你在混合实例组中追求严格的容量上限这一点需要纳入设计考量。示例 2启用 ELB 健康检查并指定可用区与子网对于需要接入负载均衡的业务让 Auto Scaling 组基于 ELB 健康检查结果判定实例健康状态是常见诉求。以下命令同时完成两件事启用 ELB 健康检查、更新vpc-zone-identifier为分布在多个可用区的子网列表aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --health-check-type ELB \ --health-check-grace-period 600 \ --vpc-zone-identifier subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782参数语义详解参数说明取值/默认值--health-check-type健康检查类型逗号分隔的字符串service-2.json合法值EC2、EBS、ELB、VPC_LATTICE。EC2是默认健康检查且不可禁用仅当你需要清除先前设置的值时才单独指定EC2--health-check-grace-period新实例进入服务后、Auto Scaling 开始执行健康检查前的宽限期秒避免实例尚未就绪即被标记为不健康service-2.json整数单位秒HealthCheckGracePeriod为整数类型service-2.json--vpc-zone-identifier子网 ID 的逗号分隔列表用于指定 VPC 内的启动位置service-2.json最长 5000 字符的字符串若与--availability-zones同时指定子网必须位于这些可用区内与可用区参数的关系模型同时提供AvailabilityZones与AvailabilityZoneIds两组参数service-2.json前者按可用区名称指定、后者按可用区 ID 指定二者不能在同一次请求中同时出现。VPCZoneIdentifier与AvailabilityZones同时使用时所列子网必须位于所指定的可用区中——这是保证跨可用区高可用部署不出错的前提。示例 3更新置放群组与终止策略以下命令为my-asg关联已有的置放群组placement group并将终止策略设置为OldestInstanceaws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --placement-group my-placement-group \ --termination-policies OldestInstance置放群组的约束PlacementGroup参数service-2.json接收一个已存在的置放群组名称。需要注意如需移除置放群组设置为placement-group传入空字符串即可集群cluster型置放群组是单个可用区内的实例逻辑分组因此不能同时指定多个可用区与集群型置放群组从源码结构看UpdatePlacementGroupParam允许空字符串min: 0service-2.json这正是清除置放群组用法能在类型层面成立的原因。终止策略的完整取值TerminationPoliciesservice-2.json可指定一个或多个策略多个策略按列表顺序依次执行用于在缩容时挑选要终止的实例。合法值包括Default默认策略AZ 均衡 最旧实例优先等综合规则AllocationStrategy按 Spot 容量分配策略选择ClosestToNextInstanceHour最接近按小时计费边界下一整点的实例NewestInstance/OldestInstance最新 / 最旧启动的实例OldestLaunchConfiguration/OldestLaunchTemplate使用最旧启动配置 / 启动模板的实例arn:aws:lambda:...自定义 Lambda 终止策略函数终止策略是缩容行为的关键控制点与示例 1 中调低 DesiredCapacity 触发缩容的场景配合理解即可确定哪些实例会被优先回收。示例 4切换为使用启动模板的最新版本$Latest使用启动模板Launch Template是现代 Auto Scaling 的推荐做法。服务模型明确建议我们强烈建议所有 Auto Scaling 组使用启动模板以确保 Amazon EC2 Auto Scaling 与 Amazon EC2 的完整功能service-2.json。以下命令将组更新为使用指定启动模板的最新版本aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-template LaunchTemplateIdlt-1234567890abcde12,Version$Latest--launch-template接受键值对语法核心字段来自LaunchTemplateSpecification结构service-2.jsonLaunchTemplateId或LaunchTemplateName二选一指定模板Version模板版本$Latest表示始终跟随最新版本。在 CLI 的 shell 环境中$Latest需用单引号包裹如示例所示避免被 shell 当作变量展开。示例 5固定使用启动模板的指定版本生产环境出于可复现性与审计要求往往需要把组固定到某个已验证的模板版本而不是跟随$Latest漂移aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-template LaunchTemplateNamemy-template-for-auto-scaling,Version2这里通过LaunchTemplateName指定模板名称Version2固定使用第 2 版。与示例 4 相比两者的差别在于模板版本解析策略$Latest是动态指针、随模板发布更新而改变数字版本是快照式固定引用、行为完全可预期。需要特别注意的是在本次更新请求中LaunchTemplate、LaunchConfigurationName、MixedInstancesPolicy三者互斥service-2.json不能同时指定。另外若组原先绑定的是启动配置Launch Configuration可通过--launch-configuration-name继续沿用旧方式但结合服务模型强烈建议使用启动模板的说明新项目应优先考虑模板方案。示例 6定义混合实例策略并启用容量再平衡当工作负载需要同时使用多种实例类型与购买方式On-Demand Spot、或需要针对 x86 与 ARM 架构使用不同启动模板时可以借助--cli-input-json从 JSON 文件加载完整的混合实例策略aws autoscaling update-auto-scaling-group \ --cli-input-json file://~/config.jsonconfig.json 完整内容{ AutoScalingGroupName: my-asg, CapacityRebalance: true, MixedInstancesPolicy: { LaunchTemplate: { LaunchTemplateSpecification: { LaunchTemplateName: my-launch-template-for-x86, Version: $Latest }, Overrides: [ { InstanceType: c6g.large, LaunchTemplateSpecification: { LaunchTemplateName: my-launch-template-for-arm, Version: $Latest } }, { InstanceType: c5.large }, { InstanceType: c5a.large } ] }, InstancesDistribution: { OnDemandPercentageAboveBaseCapacity: 50, SpotAllocationStrategy: capacity-optimized } } }关键字段解读MixedInstancesPolicy.LaunchTemplate混合实例策略的起点对应MixedInstancesPolicy结构service-2.json。其中外层LaunchTemplateSpecification指定基线模板示例中为 x86 模板my-launch-template-for-x86Overrides列表声明可用的实例类型组合每个Override可覆盖该实例类型使用的启动模板如示例中 ARM 实例c6g.large使用my-launch-template-for-arm未覆盖的实例类型c5.large、c5a.large沿用基线模板。这种结构让你能够在同一组内为不同架构提供不同 AMI 与配置InstancesDistributionservice-2.jsonOnDemandPercentageAboveBaseCapacity: 50在基线容量之上On-Demand 实例占 50%即 Spot 与 On-Demand 各占一半SpotAllocationStrategy: capacity-optimizedSpot 容量分配采用容量优化策略优先使用最不易被中断的 Spot 池CapacityRebalance: true启用容量再平衡Capacity Rebalancing。根据模型说明service-2.json启用后 Auto Scaling 会主动替换有风险的 Spot 实例若禁用则不会进行这种预防性替换。如需跨可用区暂停再平衡可配合SuspendProcesses操作实现。使用--cli-input-json加载策略的优势在于复杂嵌套结构多级模板覆盖 分配策略用命令行参数表达极易出错而 JSON 文件可读性、可维护性与版本可控性都更好。其他高频可选参数速查UpdateAutoScalingGroupTypeservice-2.json还支持以下常用参数均遵循未指定即不修改的增量语义参数说明与要点--default-cooldown简单伸缩策略下两次缩放活动之间的冷却时间秒Cooldown为整数类型service-2.json仅使用简单伸缩策略时需要--new-instances-protected-from-scale-in新启动实例是否受缩容保护--service-linked-role-arn组代表你调用其他 AWS 服务时所使用的服务相关角色 ARN--max-instance-lifetime实例可处于服务状态的最大时长秒默认null取值须为 0 或大于等于 864001 天传 0 可清除先前设置service-2.json--desired-capacity-type期望容量的计量单位合法值units默认即实例数、vcpu、memory-mib仅用于基于属性的实例类型选择service-2.json--default-instance-warmup新实例进入InService后被视为初始化完成、资源消耗趋于稳定的等待时间秒建议显式设置哪怕为 0传-1可移除先前值service-2.json--instance-maintenance-policy实例维护策略--deletion-protection删除保护级别合法值none默认、prevent-force-deletion、prevent-all-deletionservice-2.json--capacity-reservation-specification组的容量预留规格更新后的验证方法所有示例命令成功时都不产生输出因此验证必须依赖读型命令使用 describe-auto-scaling-groups.rst 中的aws autoscaling describe-auto-scaling-groups查看组的MinSize、MaxSize、DesiredCapacity、HealthCheckType、VPCZoneIdentifier、MixedInstancesPolicy等已设置属性使用 describe-scaling-activities.rst 中的aws autoscaling describe-scaling-activities观察更新触发的缩放活动进度使用aws autoscaling describe-policies查看组已有的伸缩策略必要时用 put-scaling-policy.rst 更新策略本身。由于更新是增量生效的建议在生产环境遵循先小范围验证、再全量推广的原则并配合 describe-auto-scaling-groups.rst 持续观测组状态。小结aws autoscaling update-auto-scaling-group是 Auto Scaling 组运行时治理的核心命令。通过本文的 6 个官方示例update-auto-scaling-group.rst与 service-2.json 中的参数定义你可以掌握增量更新语义只改动指定属性未指定项保持不变容量调整触发DesiredCapacity联动规则弹性与架构通过 ELB 健康检查、多可用区子网、置放群组与终止策略精细化控制实例生命周期启动模板治理用$Latest跟随最新版、用数字版本锁定可复现配置成本优化通过--cli-input-json定义混合实例策略On-Demand/Spot 配比 容量优化分配并用CapacityRebalance主动保障 Spot 容量稳定。熟练掌握这些用法后你可以在不改动基础设施资源本身的前提下仅凭 CLI 完成 Auto Scaling 组的日常运维与架构演进。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 18:07:48 · 阅读 1.2k aws-cli 实操指南：用 `aws autoscaling update-auto-scaling-group` 动态调整 Auto Scaling 组配置
aws-cli 实操指南用aws autoscaling update-auto-scaling-group动态调整 Auto Scaling 组配置【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli导读在 AWS 云环境中Auto Scaling 组ASG的配置往往需要随业务负载、架构演进和安全策略的变化而持续调整从单纯的容量上下限调整到切换启动模板、启用混合实例策略再到配置负载均衡健康检查与终止策略。本文以 aws-cli 仓库中官方示例文档 update-auto-scaling-group.rst 为骨架逐一拆解aws autoscaling update-auto-scaling-group命令的 6 个典型实战场景并结合仓库内 autoscaling 服务模型UpdateAutoScalingGroupType结构定义深入讲解每个核心参数的语义、默认值与约束帮助你准确、安全地在线变更 Auto Scaling 组配置。命令概览语义与使用前提UpdateAutoScalingGroup是一个增量更新接口。根据 service-2.json 中的操作定义其核心语义如下更新时只需指定 Auto Scaling 组名称AutoScalingGroupName必填以及你想变更的属性未指定的属性在本次请求中不会被改变新的设置会在本次调用返回之后的下一次扩容/缩容活动中生效如果为组关联了新的启动配置或启动模板新实例会使用最新配置而已有实例仍按最初启动时的配置运行将组从单一启动模板切换为混合实例策略时已有实例可能被逐步替换以匹配新的购买选项——例如当前是 100% On-Demand、策略指定 50% Spot则约一半实例会被终止并重新以 Spot 方式启动。替换过程采用先启动新实例、再终止旧实例的顺序避免影响应用的性能与可用性操作可能返回的错误包括ScalingActivityInProgressFault缩放活动进行中、ResourceContentionFault资源竞争与ServiceLinkedRoleFailure服务相关角色故障。由于该接口采用 POST 协议见 service-2.jsonCLI 层通过 clidriver.py 将参数序列化为请求体发送所有示例执行成功时均不产生输出这是 Auto Scaling 系列更新型命令的典型行为。示例 1调整组的容量上下限min-size / max-size容量边界是 Auto Scaling 组最常调整的属性。以下命令将名为my-asg的组的最小实例数更新为 2、最大实例数更新为 10aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --min-size 2 \ --max-size 10执行成功时命令不产生任何输出。可配合 describe-auto-scaling-groups.rst 中的aws autoscaling describe-auto-scaling-groups查看生效后的配置。调整容量边界的联动规则服务模型文档service-2.json给出了三条必须了解的联动规则调低 DesiredCapacity若因新的DesiredCapacity低于组当前规模而发生缩容活动Auto Scaling 会依据组的终止策略Termination Policies决定终止哪些实例仅调高 MinSize若只指定了新的MinSize而未指定DesiredCapacity且新MinSize大于组当前规模则组的DesiredCapacity会被自动设置为新的MinSize仅调低 MaxSize若只指定了新的MaxSize而未指定DesiredCapacity且新MaxSize小于组当前规模则组的DesiredCapacity会被自动设置为新的MaxSize。此外DesiredCapacity必须大于等于最小规模且小于等于最大规模service-2.json。三种容量字段在模型中的定义分别为AutoScalingGroupMinSize、AutoScalingGroupMaxSize、AutoScalingGroupDesiredCapacityservice-2.json均为整数类型。关于 MaxSize 的一个特殊注意事项服务模型对MaxSize附带一条重要说明service-2.json使用带实例权重的混合实例策略时Auto Scaling 可能为了满足容量需求而暂时超过MaxSize但永远不会超过MaxSize与最大实例权重的差值权重定义了每个实例对组期望容量的贡献单位数。如果你在混合实例组中追求严格的容量上限这一点需要纳入设计考量。示例 2启用 ELB 健康检查并指定可用区与子网对于需要接入负载均衡的业务让 Auto Scaling 组基于 ELB 健康检查结果判定实例健康状态是常见诉求。以下命令同时完成两件事启用 ELB 健康检查、更新vpc-zone-identifier为分布在多个可用区的子网列表aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --health-check-type ELB \ --health-check-grace-period 600 \ --vpc-zone-identifier subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782参数语义详解参数说明取值/默认值--health-check-type健康检查类型逗号分隔的字符串service-2.json合法值EC2、EBS、ELB、VPC_LATTICE。EC2是默认健康检查且不可禁用仅当你需要清除先前设置的值时才单独指定EC2--health-check-grace-period新实例进入服务后、Auto Scaling 开始执行健康检查前的宽限期秒避免实例尚未就绪即被标记为不健康service-2.json整数单位秒HealthCheckGracePeriod为整数类型service-2.json--vpc-zone-identifier子网 ID 的逗号分隔列表用于指定 VPC 内的启动位置service-2.json最长 5000 字符的字符串若与--availability-zones同时指定子网必须位于这些可用区内与可用区参数的关系模型同时提供AvailabilityZones与AvailabilityZoneIds两组参数service-2.json前者按可用区名称指定、后者按可用区 ID 指定二者不能在同一次请求中同时出现。VPCZoneIdentifier与AvailabilityZones同时使用时所列子网必须位于所指定的可用区中——这是保证跨可用区高可用部署不出错的前提。示例 3更新置放群组与终止策略以下命令为my-asg关联已有的置放群组placement group并将终止策略设置为OldestInstanceaws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --placement-group my-placement-group \ --termination-policies OldestInstance置放群组的约束PlacementGroup参数service-2.json接收一个已存在的置放群组名称。需要注意如需移除置放群组设置为placement-group传入空字符串即可集群cluster型置放群组是单个可用区内的实例逻辑分组因此不能同时指定多个可用区与集群型置放群组从源码结构看UpdatePlacementGroupParam允许空字符串min: 0service-2.json这正是清除置放群组用法能在类型层面成立的原因。终止策略的完整取值TerminationPoliciesservice-2.json可指定一个或多个策略多个策略按列表顺序依次执行用于在缩容时挑选要终止的实例。合法值包括Default默认策略AZ 均衡 最旧实例优先等综合规则AllocationStrategy按 Spot 容量分配策略选择ClosestToNextInstanceHour最接近按小时计费边界下一整点的实例NewestInstance/OldestInstance最新 / 最旧启动的实例OldestLaunchConfiguration/OldestLaunchTemplate使用最旧启动配置 / 启动模板的实例arn:aws:lambda:...自定义 Lambda 终止策略函数终止策略是缩容行为的关键控制点与示例 1 中调低 DesiredCapacity 触发缩容的场景配合理解即可确定哪些实例会被优先回收。示例 4切换为使用启动模板的最新版本$Latest使用启动模板Launch Template是现代 Auto Scaling 的推荐做法。服务模型明确建议我们强烈建议所有 Auto Scaling 组使用启动模板以确保 Amazon EC2 Auto Scaling 与 Amazon EC2 的完整功能service-2.json。以下命令将组更新为使用指定启动模板的最新版本aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-template LaunchTemplateIdlt-1234567890abcde12,Version$Latest--launch-template接受键值对语法核心字段来自LaunchTemplateSpecification结构service-2.jsonLaunchTemplateId或LaunchTemplateName二选一指定模板Version模板版本$Latest表示始终跟随最新版本。在 CLI 的 shell 环境中$Latest需用单引号包裹如示例所示避免被 shell 当作变量展开。示例 5固定使用启动模板的指定版本生产环境出于可复现性与审计要求往往需要把组固定到某个已验证的模板版本而不是跟随$Latest漂移aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-template LaunchTemplateNamemy-template-for-auto-scaling,Version2这里通过LaunchTemplateName指定模板名称Version2固定使用第 2 版。与示例 4 相比两者的差别在于模板版本解析策略$Latest是动态指针、随模板发布更新而改变数字版本是快照式固定引用、行为完全可预期。需要特别注意的是在本次更新请求中LaunchTemplate、LaunchConfigurationName、MixedInstancesPolicy三者互斥service-2.json不能同时指定。另外若组原先绑定的是启动配置Launch Configuration可通过--launch-configuration-name继续沿用旧方式但结合服务模型强烈建议使用启动模板的说明新项目应优先考虑模板方案。示例 6定义混合实例策略并启用容量再平衡当工作负载需要同时使用多种实例类型与购买方式On-Demand Spot、或需要针对 x86 与 ARM 架构使用不同启动模板时可以借助--cli-input-json从 JSON 文件加载完整的混合实例策略aws autoscaling update-auto-scaling-group \ --cli-input-json file://~/config.jsonconfig.json 完整内容{ AutoScalingGroupName: my-asg, CapacityRebalance: true, MixedInstancesPolicy: { LaunchTemplate: { LaunchTemplateSpecification: { LaunchTemplateName: my-launch-template-for-x86, Version: $Latest }, Overrides: [ { InstanceType: c6g.large, LaunchTemplateSpecification: { LaunchTemplateName: my-launch-template-for-arm, Version: $Latest } }, { InstanceType: c5.large }, { InstanceType: c5a.large } ] }, InstancesDistribution: { OnDemandPercentageAboveBaseCapacity: 50, SpotAllocationStrategy: capacity-optimized } } }关键字段解读MixedInstancesPolicy.LaunchTemplate混合实例策略的起点对应MixedInstancesPolicy结构service-2.json。其中外层LaunchTemplateSpecification指定基线模板示例中为 x86 模板my-launch-template-for-x86Overrides列表声明可用的实例类型组合每个Override可覆盖该实例类型使用的启动模板如示例中 ARM 实例c6g.large使用my-launch-template-for-arm未覆盖的实例类型c5.large、c5a.large沿用基线模板。这种结构让你能够在同一组内为不同架构提供不同 AMI 与配置InstancesDistributionservice-2.jsonOnDemandPercentageAboveBaseCapacity: 50在基线容量之上On-Demand 实例占 50%即 Spot 与 On-Demand 各占一半SpotAllocationStrategy: capacity-optimizedSpot 容量分配采用容量优化策略优先使用最不易被中断的 Spot 池CapacityRebalance: true启用容量再平衡Capacity Rebalancing。根据模型说明service-2.json启用后 Auto Scaling 会主动替换有风险的 Spot 实例若禁用则不会进行这种预防性替换。如需跨可用区暂停再平衡可配合SuspendProcesses操作实现。使用--cli-input-json加载策略的优势在于复杂嵌套结构多级模板覆盖 分配策略用命令行参数表达极易出错而 JSON 文件可读性、可维护性与版本可控性都更好。其他高频可选参数速查UpdateAutoScalingGroupTypeservice-2.json还支持以下常用参数均遵循未指定即不修改的增量语义参数说明与要点--default-cooldown简单伸缩策略下两次缩放活动之间的冷却时间秒Cooldown为整数类型service-2.json仅使用简单伸缩策略时需要--new-instances-protected-from-scale-in新启动实例是否受缩容保护--service-linked-role-arn组代表你调用其他 AWS 服务时所使用的服务相关角色 ARN--max-instance-lifetime实例可处于服务状态的最大时长秒默认null取值须为 0 或大于等于 864001 天传 0 可清除先前设置service-2.json--desired-capacity-type期望容量的计量单位合法值units默认即实例数、vcpu、memory-mib仅用于基于属性的实例类型选择service-2.json--default-instance-warmup新实例进入InService后被视为初始化完成、资源消耗趋于稳定的等待时间秒建议显式设置哪怕为 0传-1可移除先前值service-2.json--instance-maintenance-policy实例维护策略--deletion-protection删除保护级别合法值none默认、prevent-force-deletion、prevent-all-deletionservice-2.json--capacity-reservation-specification组的容量预留规格更新后的验证方法所有示例命令成功时都不产生输出因此验证必须依赖读型命令使用 describe-auto-scaling-groups.rst 中的aws autoscaling describe-auto-scaling-groups查看组的MinSize、MaxSize、DesiredCapacity、HealthCheckType、VPCZoneIdentifier、MixedInstancesPolicy等已设置属性使用 describe-scaling-activities.rst 中的aws autoscaling describe-scaling-activities观察更新触发的缩放活动进度使用aws autoscaling describe-policies查看组已有的伸缩策略必要时用 put-scaling-policy.rst 更新策略本身。由于更新是增量生效的建议在生产环境遵循先小范围验证、再全量推广的原则并配合 describe-auto-scaling-groups.rst 持续观测组状态。小结aws autoscaling update-auto-scaling-group是 Auto Scaling 组运行时治理的核心命令。通过本文的 6 个官方示例update-auto-scaling-group.rst与 service-2.json 中的参数定义你可以掌握增量更新语义只改动指定属性未指定项保持不变容量调整触发DesiredCapacity联动规则弹性与架构通过 ELB 健康检查、多可用区子网、置放群组与终止策略精细化控制实例生命周期启动模板治理用$Latest跟随最新版、用数字版本锁定可复现配置成本优化通过--cli-input-json定义混合实例策略On-Demand/Spot 配比 容量优化分配并用CapacityRebalance主动保障 Spot 容量稳定。熟练掌握这些用法后你可以在不改动基础设施资源本身的前提下仅凭 CLI 完成 Auto Scaling 组的日常运维与架构演进。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考