企业官网建设流程全解析

aws-cli put-scheduled-action 实战：为 AWS 资源配置基于 cron 计划的周期性伸缩动作

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

本文以 aws-cli 中 Application Auto Scaling 的put-scheduled-action命令为例，讲解如何为 DynamoDB 表等 AWS 资源创建“按计划自动伸缩”的定时动作（Scheduled Action）。读完本篇，你将掌握该命令的完整参数体系、三种计划表达式（at / rate / cron）的写法、ScalableTargetAction容量语义，以及如何配合describe-scheduled-actions、delete-scheduled-action完成定时伸缩动作的完整生命周期管理，所有结论均可在仓库内的服务模型与示例文档中核对。

命令定位：创建或更新定时伸缩动作

put-scheduled-action是 aws-cli 中 Application Auto Scaling 服务（API 版本2016-02-06）的操作命令，用于为某个可伸缩目标（scalable target）创建或更新一个定时伸缩动作。从仓库内的服务模型定义（service-2.json）可以看到该操作的三条核心语义：

1. 一个可伸缩目标由**服务命名空间（ServiceNamespace）+ 资源 ID（ResourceId）+ 可伸缩维度（ScalableDimension）**三元组唯一标识，定时动作就是绑定到这个三元组上的；
2. 必须先通过register-scalable-target把资源注册为可伸缩目标，之后才能为其创建定时动作；
3. 如果可伸缩目标被反注册（deregister），其上的所有定时动作会一并被删除——这是管理此类资源时必须注意的“连带删除”行为。

此外，该操作采用Put（幂等覆盖）语义：用相同的--scheduled-action-name再次调用即表示更新已有动作；更新时只传需要变更的参数即可，且“如果不传开始/结束时间，旧的开始/结束时间会被删除”。

官方示例：为 DynamoDB 表配置每日扩缩计划

仓库中的示例文档 put-scheduled-action.rst 给出了一个典型的实战场景：为名为TestTable的 DynamoDB 表添加一个重复执行的定时动作，在每天 12:15（UTC）检查写容量——若当前容量低于MinCapacity，则扩容到该值：

aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \ --scheduled-action-name my-recurring-action \ --schedule "cron(15 12 * * ? *)" \ --resource-id table/TestTable \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --scalable-target-action MinCapacity=6

逐段解读这条命令：

• --service-namespace dynamodb：资源由 DynamoDB 服务提供；
• --scheduled-action-name my-recurring-action：动作名称，在同一个可伸缩目标内必须唯一；
• --schedule "cron(15 12 * * ? *)"：cron 表达式，表示每天 12 点 15 分触发（六字段格式，见下文）；
• --resource-id table/TestTable：DynamoDB 表的资源 ID，格式为table/表名；
• --scalable-dimension dynamodb:table:WriteCapacityUnits：伸缩的容量维度是表的预置写容量（Write Capacity Units）；
• --scalable-target-action MinCapacity=6：动作触发的容量动作——只设置下限。到达计划时间时，若当前写容量 < 6，Application Auto Scaling 会把表扩容到 6 个写容量单位。

这里只指定MinCapacity而不指定MaxCapacity是刻意的：示例意图是“在业务高峰前把写容量抬起来”，而不限制缩容，与目标跟踪等动态伸缩策略可以共存。

参数详解：哪些必填、哪些可选

依据服务模型中的请求结构 PutScheduledActionRequest，各参数如下表：

关于--scheduled-action-name，模型中还给出了严格的格式约束（见 ScheduledActionName 定义）：长度 1–256 字符，不能以空格开头、不能以空格结尾，且不能包含控制字符或:、/、|等分隔符——这解释了为什么示例使用my-recurring-action这类连字符命名。

ResourceId 的常见格式

服务模型中对--resource-id的文档列举了各类服务的标准格式（见 ResourceId 文档说明），常用的有：

• ECS 服务：service/my-cluster/my-service
• EMR 实例组：instancegroup/j-2EEZNYKUA1NTV/ig-1791Y4E1L8YI0
• AppStream 2.0 fleet：fleet/sample-fleet
• DynamoDB 表：table/my-table；GSI：table/my-table/index/my-table-index
• Aurora 集群：cluster:my-db-cluster
• SageMaker 端点变体：endpoint/my-end-point/variant/KMeansClustering
• Lambda 预置并发：function:my-function:prod（需带版本号或别名）
• Amazon Keyspaces 表：keyspace/mykeyspace/table/mytable
• Amazon MSK 集群、Comprehend 端点等：直接使用集群/端点 ARN
• 自定义资源（custom-resource）：不使用资源类型前缀，需指定 CloudFormation 模板栈的OutputValue

ScalableDimension 的常见取值

同样来自模型文档（见 ScalableDimension 文档说明），例如：

• ecs:service:DesiredCount—— ECS 服务的任务数
• elasticmapreduce:instancegroup:InstanceCount—— EMR 实例组实例数
• ec2:spot-fleet-request:TargetCapacity—— Spot Fleet 目标容量
• dynamodb:table:ReadCapacityUnits/dynamodb:table:WriteCapacityUnits—— DynamoDB 表预置读/写容量
• dynamodb:index:ReadCapacityUnits/dynamodb:index:WriteCapacityUnits—— GSI 预置读/写容量
• rds:cluster:ReadReplicaCount—— Aurora 只读副本数
• lambda:function:ProvisionedConcurrency—— Lambda 预置并发
• sagemaker:variant:DesiredInstanceCount—— SageMaker 端点变体实例数
• custom-resource:ResourceType:Property—— 自定义资源的伸缩维度

选择维度时要注意它与--resource-id、--service-namespace必须三者匹配：上例中dynamodb命名空间对应table/...资源 ID，又对应dynamodb:table:...维度。

Schedule 的三种计划表达式

--schedule参数支持三种格式（定义见 Schedule 文档说明）：

1. at 表达式：一次性计划

at(yyyy-mm-ddThh:mm:ss)

适合“在某个确定时刻执行一次”的场景，例如at(2019-05-20T18:35:00)。默认使用 UTC，可用--timezone覆盖。

2. rate 表达式：固定间隔

rate(value unit)

value为正整数，unit取minute | minutes | hour | hours | day | days。例如rate(30 minutes)表示每 30 分钟执行一次。

3. cron 表达式：周期性计划（本例所用）

cron(fields)

cron 格式由六个空格分隔的字段组成：[分钟] [小时] [日] [月] [星期] [年]，同样默认 UTC、可用--timezone覆盖。官方示例中的"cron(15 12 * * ? *)"展开即为：

即“每天 12:15 UTC 触发一次”。

另外两个可选的边界参数--start-time/--end-time对重复计划的作用，在服务模型的操作文档中有明确说明：它们构成重复动作的起止边界，只在边界窗口内按计划触发。

ScalableTargetAction 的容量语义

--scalable-target-action对应模型中的 ScalableTargetAction 结构，包含两个成员：

• MinCapacity：最小容量。定时动作触发时，资源容量至少达到该值——因此“当前容量低于 MinCapacity 就扩到 MinCapacity”只是下限保障，若目标跟踪策略要求更高，实际容量可能更大；
• MaxCapacity：最大容量。若当前容量高于该值，Application Auto Scaling 会缩容到该值。注意即便设定很大的最大值，各服务自身的配额（quota）仍可能施加更低的限制，需要更高层级时应先申请配额提升。

两个值可以只填一个，也可以都填：只填MinCapacity实现“保底扩容”，只填MaxCapacity实现“上限收缩”，都填则把容量收敛到[Min, Max]区间。在命令行上通过逗号分隔传递，例如：

--scalable-target-action MinCapacity=5,MaxCapacity=20

验证与管理：describe 与 delete

创建动作后，建议用describe-scheduled-actions验证。仓库中的 describe-scheduled-actions.rst 展示了 DynamoDB 命名空间下的真实输出形态：

aws application-autoscaling describe-scheduled-actions \ --service-namespace dynamodb

{ "ScheduledActions": [ { "ScalableDimension": "dynamodb:table:WriteCapacityUnits", "Schedule": "at(2019-05-20T18:35:00)", "ResourceId": "table/my-table", "CreationTime": 1561571888.361, "ScheduledActionARN": "arn:aws:autoscaling:us-west-2:123456789012:scheduledAction:2d36aa3b-cdf9-4565-b290-81db519b227d:resource/dynamodb/table/my-table:scheduledActionName/my-first-scheduled-action", "ScalableTargetAction": { "MinCapacity": 15, "MaxCapacity": 20 }, "ScheduledActionName": "my-first-scheduled-action", "ServiceNamespace": "dynamodb" } ] }

返回的ScheduledAction对象（结构见 ScheduledAction 定义）比创建请求多出ScheduledActionARN与CreationTime两个只读字段，其中 ARN 中内嵌了服务命名空间、资源标识与动作名称，便于后续审计与关联。

不再需要某个定时动作时，使用delete-scheduled-action按相同的三元组加名称精确删除，例如仓库示例 delete-scheduled-action.rst 中删除 AppStream fleet 上的动作：

aws application-autoscaling delete-scheduled-action \ --service-namespace appstream \ --scalable-dimension appstream:fleet:DesiredCapacity \ --resource-id fleet/sample-fleet \ --scheduled-action-name my-recurring-action

该命令执行成功时无任何输出。

前提与常见异常

再次强调使用前提：资源必须已注册为可伸缩目标。可参考仓库示例 register-scalable-target.rst 中的 DynamoDB 注册写法（需指定--min-capacity/--max-capacity），以及通过--suspended-state暂停/恢复伸缩（其中ScheduledScalingSuspended=true会直接挂起定时伸缩）。

从模型中该操作声明的异常列表（PutScheduledAction 操作定义）看，执行put-scheduled-action时可能遇到：

• ValidationException：参数校验失败，如三元组不匹配、schedule 表达式格式错误、动作名违反命名约束；
• LimitExceededException：超过服务配额/数量上限；
• ObjectNotFoundException：资源或可伸缩目标不存在；
• ConcurrentUpdateException：与并发更新冲突，可稍后重试；
• InternalServiceException：服务端内部错误。

小结

put-scheduled-action是 aws-cli 中将“可预测的业务波峰波谷”转化为自动容量操作的入口：用三元组（--service-namespace/--resource-id/--scalable-dimension）定位目标，用--schedule的 at/rate/cron 表达式定义触发时机，用--scalable-target-action的 Min/Max 容量定义动作效果。配合register-scalable-target（前提）、describe-scheduled-actions（验证）、delete-scheduled-action（清理）即可完整管理定时伸缩动作；同时留意“反注册可伸缩目标会连带删除其定时动作”这一服务行为，避免运维时产生预期外的状态丢失。

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