前一段在试用Ansible Playbook对AWS Auto Scaling Group Policy做更新操作时，我发现通过Ansible模块ec2_scaling_policy新建的Auto Scaling Group Policy的AWS输出参数和通过AWS Web Console建立的Auto Scaling Group Policy输出有所不同。
具体情况如下：
通过ansible
通过AWS Web Console
根据两种操作后的变更效果，我发现EstimatedInstanceWarmup和Cooldown代表的意思没有明显的区别。于是乎，我从新通过AWS Web Console进行了如上操作，此次仔细查看了面板上的各个描述，发现了如下内容。
当我们默认创建Scaling Policy时，会打开如下窗口：
在窗口左下角，有这么一行字“Create a simple scaling policy”，我们点击它，窗口的参数会变成如下：
这时，我就发现了差异所在。
对于这个地方的差异，我不是很清楚，于是就查阅AWS Doc。
内容如下：
Scaling Policy Types
When you create a scaling policy, you must specify its policy type. The policy type determines how the scaling action is performed. Auto Scaling supports the following policy types:
* Simple scaling—Increase or decrease the current capacity of the group based on a single scaling adjustment.
* Step scaling—Increase or decrease the current capacity of the group based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.
Simple Scaling Policies
After a scaling activity is started, the policy must wait for the scaling activity or health check replacement to complete and the cooldown period to expire before it can respond to additional alarms. Cooldown periods help to prevent Auto Scaling from initiating additional scaling activities before the effects of previous activities are visible. You can use the default cooldown period associated with your Auto Scaling group, or you can override the default by specifying a cooldown period for your policy. For more information, see Understanding Auto Scaling Cooldowns.
Note that Auto Scaling originally supported only this type of scaling policy. If you created your scaling policy before policy types were introduced, your policy is treated as a simple scaling policy.
Step Scaling Policies
After a scaling activity is started, the policy continues to respond to additional alarms, even while a scaling activity or health check replacement is in progress. Therefore, all alarms that are breached are evaluated by Auto Scaling as it receives the alarm messages. If you are creating a policy to scale out, you can specify the estimated warm-up time that it will take for a newly launched instance to be ready to contribute to the aggregated metrics. For more information, see Instance Warmup.
- Note
- Cooldown periods are not supported for step scaling policies. Therefore, you can't specify a cooldown period for these policies and the default cooldown period for the group doesn't apply.
We recommend that you use step scaling policies even if you have a single step adjustment, because we continuously evaluate alarms and do not lock the group during scaling activities or health check replacements.
参考链接
根据描述，我在和最初的输出进行对比，可以发现ansible的ec2_scaling_policy模块使用的还是旧的扩展策略类型（即简单扩展策略）。这时，我再去看Cloudformation中资源类型Auto Scaling Policy(AWS::AutoScaling::ScalingPolicy)，发现它对扩展策略类型的属性支持也是简单扩展策略。
AWS Cloudformation资源类型 AWS::AutoScaling::ScalingPolicy
{
"Type" : "AWS::AutoScaling::ScalingPolicy",
"Properties" : {
"AdjustmentType" : String,
"AutoScalingGroupName" : String,
"Cooldown" : String, # 注意
"MinAdjustmentStep" : Integer,
"ScalingAdjustment" : String
}
}
参考链接
我留意了下ansible的官方文档，它声明了在使用ec2_scaling_policy模块时的需求，内容如下：
ec2_scaling_policy - Create or delete AWS scaling policies for Autoscaling groups
New in version 1.6.
- Synopsis
- Requirements
- Options
- Examples
- Notes
- This is a Core Module
Synopsis
Can create or delete scaling policies for autoscaling groups Referenced autoscaling groups must already exist
Requirements
- python >= 2.6 # 注意
- boto
参考链接
ansible对aws的操作是通过aws的boto实现的。ansible不支持，那就说明是boto不支持。通过查看boto中对Auto Scaling Policy操作的类，我发现boto确实不支持新的步进扩展策略，仅支持简单扩展策略。
官方文档描述如下：
class boto.ec2.autoscale.policy.ScalingPolicy(connection=None, **kwargs)
Scaling Policy
Parameters:
name (str) – Name of scaling policy.
adjustment_type (str) – Specifies the type of adjustment. Valid values are ChangeInCapacity, ExactCapacity and PercentChangeInCapacity.
as_name (str or int) – Name or ARN of the Auto Scaling Group.
scaling_adjustment (int) – Value of adjustment (type specified in adjustment_type).
min_adjustment_step (int) – Value of min adjustment step required to apply the scaling policy (only make sense when use PercentChangeInCapacity as adjustment_type.).
cooldown (int) – Time (in seconds) before Alarm related Scaling Activities can start after the previous Scaling Activity ends. # 注意
参考链接
由于，我平时都使用的是boto3.接着，我就又查看了boto3的对应类，发现在boto3中已经增加了对步进扩展策略的操作支持。
Request Syntax
response = client.put_scaling_policy(
AutoScalingGroupName='string',
PolicyName='string',
PolicyType='string', # 注意
AdjustmentType='string',
MinAdjustmentStep=123,
MinAdjustmentMagnitude=123,
ScalingAdjustment=123,
Cooldown=123, # 注意
MetricAggregationType='string',
StepAdjustments=[
{
'MetricIntervalLowerBound': 123.0,
'MetricIntervalUpperBound': 123.0,
'ScalingAdjustment': 123
},
],
EstimatedInstanceWarmup=123 # 注意
)
参考链接
这里对以下几个值做下解释:
PolicyType (string) -- The policy type. Valid values are SimpleScaling and StepScaling . If the policy type is null, the value is treated as SimpleScaling .
Cooldown (integer) --
The amount of time, in seconds, after a scaling activity completes and before the next scaling activity can start. If this parameter is not specified, the default cooldown period for the group applies.
This parameter is not supported unless the policy type is SimpleScaling .
For more information, see Understanding Auto Scaling Cooldowns in the Auto Scaling Developer Guide .EstimatedInstanceWarmup (integer) --
The estimated time, in seconds, until a newly launched instance can contribute to the CloudWatch metrics. The default is to use the value specified for the default cooldown period for the group.
This parameter is not supported if the policy type is SimpleScaling .
参考链接
从上述文档可以发现boto3已经支持了这两种扩展策略，并且增加了PolicyType属性来对着两种扩展策略进行了区分。
由于在我们的业务应用中，对扩展策略的需求不是很苛刻，因此简单扩展策略就可以满足我们的需求。因此，此处并未对我本次更新造成任何影响。谨以此文记录使用aws和ansible的疑惑之处。