企业官网建设流程全解析

AWS CLI：application-autoscaling delete-scaling-policy 实战指南——彻底理解并删除 Application Auto Scaling 扩缩容策略

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli

本文基于 aws-cli 仓库中的官方示例文档 delete-scaling-policy.rst 展开，讲解如何删除 Amazon ECS 服务上挂接的 Application Auto Scaling 扩缩容策略：完整参数说明（全部为必填项）、各服务 Resource ID 与 Scalable Dimension 的合法格式、删除后的实际效果（底层告警动作与 CloudWatch 告警的区别）、可能的错误类型，以及如何用describe-scaling-policies验证删除结果。读完后你可以独立完成"定位策略 → 删除策略 → 验证删除"的完整运维闭环。

命令示例：删除 ECS 服务上的扩缩容策略

delete-scaling-policy.rst 给出的核心示例是删除运行在default集群中、名为web-app的 Amazon ECS 服务上的扩缩容策略：

aws application-autoscaling delete-scaling-policy \ --policy-name web-app-cpu-lt-25 \ --scalable-dimension ecs:service:DesiredCount \ --resource-id service/default/web-app \ --service-namespace ecs

该命令对应 AWS SDK 模型中的DeleteScalingPolicy操作。从 服务模型定义 看，该操作以 HTTPPOST请求发送至根路径/，请求与响应结构分别由DeleteScalingPolicyRequest和DeleteScalingPolicyResponse两个 shape 定义。值得注意的是：响应结构体的 members 为空（"members": {}），即删除成功时不返回任何字段——这是该 API 的典型"写操作无返回体"设计，判断成功与否主要依据命令退出码与是否抛出异常。

四个必填参数逐项解析

DeleteScalingPolicyRequest在模型中声明了required: ["PolicyName", "ServiceNamespace", "ResourceId", "ScalableDimension"]，四个参数缺一不可。定位一个扩缩容策略需要"服务命名空间 + 资源 ID + 可伸缩维度 + 策略名"这组四元组，缺一项就无法唯一确定策略：

Resource ID 的格式因服务而异

ResourceId的官方文档给出了各服务的标准格式，这是实际使用中最容易出错的地方。以下为模型文档中列举的典型取值：

另有两类特殊形式：Comprehend / MSK 等服务的资源直接以 ARN 作为ResourceId（例如arn:aws:kafka:us-east-1:123456789012:cluster/demo-cluster-1/6357e0b2-...）；自定义资源（custom resource）不带资源类型前缀，需使用 CloudFormation 模板栈中访问该资源的OutputValue（通常是你 API Gateway 端点的路径）。

Scalable Dimension 的常用取值

ScalableDimension的三段式字符串在模型文档中同样有完整清单，常用的有：

• ecs:service:DesiredCount—— ECS 服务的任务数（本文示例所用）
• dynamodb:table:ReadCapacityUnits/dynamodb:table:WriteCapacityUnits—— DynamoDB 表的预置读写容量
• dynamodb:index:ReadCapacityUnits/dynamodb:index:WriteCapacityUnits—— DynamoDB 全局二级索引的预置读写容量
• ec2:spot-fleet-request:TargetCapacity—— Spot Fleet 目标容量
• elasticmapreduce:instancegroup:InstanceCount—— EMR 实例组实例数
• appstream:fleet:DesiredCapacity—— AppStream 2.0 fleet 容量
• rds:cluster:ReadReplicaCount—— Aurora DB 集群中 Aurora 副本数
• lambda:function:ProvisionedConcurrency—— Lambda 函数预置并发
• cassandra:table:ReadCapacityUnits/cassandra:table:WriteCapacityUnits—— Amazon Keyspaces 表预置容量
• sagemaker:variant:DesiredInstanceCount—— SageMaker 端点变体的 EC2 实例数
• custom-resource:ResourceType:Property—— 自定义资源的可伸缩维度

删除的实际效果：告警动作被删，CloudWatch 告警不删

服务模型中对DeleteScalingPolicy的官方说明包含一条关键语义，直接关系到删除后的清理工作：

"Deleting a step scaling policy deletes the underlying alarm action, but does not delete the CloudWatch alarm associated with the scaling policy, even if it no longer has an associated action."

也就是说，删除一条Step Scaling 策略时，底层与 CloudWatch 告警绑定的"告警动作"（alarm action）会被移除，但 CloudWatch 告警本身不会被删除——即使它已不再有任何关联动作。因此如果你的告警是自行创建的（而非由put-scaling-policy代你创建），删除策略后告警会"残留"但不再触发扩缩容；若希望告警彻底消失，需要另行到 CloudWatch 侧处理。这一点在做容量治理和清理废弃策略时要特别注意。

验证删除结果：describe-scaling-policies

删除是无返回体的操作，标准做法是用describe-scaling-policies复核策略列表。仓库中 describe-scaling-policies.rst 给出了同一web-app服务下查询策略的完整示例与返回结构：

aws application-autoscaling describe-scaling-policies --service-namespace ecs

返回的 JSON 中每个策略包含PolicyName、ScalableDimension、ResourceId、CreationTime、策略配置（如StepScalingPolicyConfiguration，含Cooldown、StepAdjustments、AdjustmentType）、PolicyARN、PolicyType（如StepScaling）、关联的Alarms以及ServiceNamespace。以该示例输出为例，web-app服务上此前存在两条 StepScaling 策略：

• web-app-cpu-gt-75：CPU 超过 75% 时按PercentChangeInCapacity增加 200%，Cooldown 60 秒；
• web-app-cpu-lt-25：CPU 低于 25% 时缩减 50%，Cooldown 1 秒（即本文删除命令的目标策略）。

执行删除命令后重新运行describe-scaling-policies，ScalingPolicies数组中应不再出现web-app-cpu-lt-25，即确认删除成功。

可能的错误类型

根据 service-2.json 中DeleteScalingPolicy操作声明的errors列表，该操作可能抛出以下四类异常：

排查ObjectNotFoundException时的一个技巧：先用describe-scaling-policies --service-namespace ecs确认策略真实存在及其ResourceId、ScalableDimension的精确写法，再原样复制用于删除命令，避免四元组中任何一项与注册时不一致。

与相关命令的协同：完整的策略生命周期

delete-scaling-policy并非孤立操作，仓库的 application-autoscaling 示例目录 覆盖了该服务的完整命令族，理解协同关系有助于把删除放在正确的流程位置：

1. 注册可伸缩目标——register-scalable-target将 ECS 服务纳入 Application Auto Scaling 管理；
2. 创建策略—— put-scaling-policy.rst 演示了如何创建目标追踪（Target Tracking）策略，支持预定义指标、自定义指标与仅扩容（DisableScaleIn）三种配置，且支持file://config.json方式从本地 JSON 文件传入策略配置；
3. 查询策略——describe-scaling-policies查看当前策略及其关联告警；
4. 删除策略—— 即本文的delete-scaling-policy；
5. 注销目标—— deregister-scalable-target.rst 演示注销可伸缩目标。对于自定义资源，其 Resource ID 通常存放于文件中，可通过file://语法传入，例如：

aws application-autoscaling deregister-scalable-target \ --service-namespace custom-resource \ --scalable-dimension custom-resource:ResourceType:Property \ --resource-id file://~/custom-resource-id.txt

其中custom-resource-id.txt的内容为标识该自定义资源的 API Gateway 端点路径（示例：https://example.execute-api.us-west-2.amazonaws.com/prod/scalableTargetDimensions/1-23456789）。

一般而言，先删除目标上的所有扩缩容策略（delete-scaling-policy），再注销可伸缩目标（deregister-scalable-target），是比较稳妥的清理顺序。

适用前提与限制

• 本文基于当前仓库中 API 版本2016-02-06的 Application Auto Scaling 服务模型（见 service-2.json），命令参数与该版本一致；
• 执行删除命令前需确保 AWS 凭证（aws configure或环境变量）具有application-autoscaling:DeleteScalingPolicy权限，且凭证所在账户与策略 ARN 所属账户一致；
• 示例中web-app-cpu-lt-25策略是 Step Scaling 类型，"删除策略只删告警动作、不删告警"的语义主要针对 Step Scaling 策略，Target Tracking 策略删除后的告警行为以服务实际行为为准；
• 四个必填参数任一不匹配（尤其是ResourceId与ScalableDimension的组合）都会导致ObjectNotFoundException，删除前务必先通过describe-scaling-policies核对精确值。

小结

delete-scaling-policy是 Application Auto Scaling 策略生命周期管理中的收尾操作。掌握它的要点在于：用"服务命名空间 + 资源 ID + 可伸缩维度 + 策略名"四元组精确定位策略、理解各服务 Resource ID 与 Scalable Dimension 的格式规范、牢记 Step Scaling 策略删除后 CloudWatch 告警残留的特性，并在删除后用describe-scaling-policies完成闭环验证。仓库中 examples/application-autoscaling 目录下的其余示例（put-scaling-policy、register-scalable-target、describe-scaling-activities等）可作为扩展阅读，帮助你覆盖从注册到注销的完整运维流程。

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli