- NPM Downloads Last Month
ScalingPolicyresources that are added to CloudFormation stack
npm install serverless-plugin-dynamodb-autoscaling
Activate plugin in
plugins: - serverless-plugin-dynamodb-autoscaling
In most cases it’s all you need to have autoscaling resources configured. Still if you need to fine tune configuration for some reason see tables and IAM role configuration. Additionally if you approach any errors during CloudFormation deployment, refer to troubleshooting
By default autoscaling configuration is automatically applied to all preconfigured DynamoDB tables and all its eventual global secondary indexes.
Still, we can exclude individual tables or tweak their configuration via configuration within
custom: dynamodbAutoscaling: tablesConfig: # Disable autoscaling for tableName1 table entirely tableName1: false # Disable autoscaling just for indexes of tableName2 table tableName2: indexes: false # Tweak minCapacity setting for all tables that start with tableName # (glob patterns can be used) tableName*: minCapacity: 10 tableName4: # Tweak maxCapacity setting for tableName4 (just table) table: maxCapacity: 300 # Tweak targetUsage setting for tableName4 indexes indexes: targetUsage: 0.5 tableName5: indexes: # Do not autoscale index 'foo' foo: false tableName6: indexes: # Do not autoscale any indexes but 'foo' and 'bar' "*": false foo: true bar: # Tweaking one of the configuration option will also whitelist the index minCapacity: 100
If you prefer white list instead of black list approach you can handle configuration as below
custom: dynamodbAutoscaling: tablesConfig: # Disable autoscaling for all "*": false # but enable for tableName1 tableName1: true
200) refers to
5) refers to
0.75) refers to
ScalingPolicy.TargetTrackingScalingPolicyConfiguration.TargetValue(value is multiplied by
100when assigned to
ScalingPolicy resources are chained via
DependsOn property, so they’re deployed sequentially and not in parallel. It’s to avoid reaching eventual CloudWatch rate limits.
Still it has a downside of slowing down the deployment. If number of tables in your stack is not large, or you’ve lifted rate limits on AWS side, then you can safely turn off that option to ensure more robust deployments:
custom: dynamodbAutoscaling: chainScalingPolicies: false
By default existing lambda IAM role is reused (if recognized) or new dedicated IAM role is created. Still it’s possible to handle IAM configuration outside of this plugin, for that just pass ARN of externally configured IAM role via
custom: dynamodbAutoscaling: iamRoleArn: "arn-of-iam-role-to-handle-tables"
If at first deployment you’re faced with one of the following errors:
Unable to assume IAM role
Role is missing the following permissions
The security token included in the request is invalid
It can be result of a race condition issue described as following by AWS team:
It’s a known situation and confirmed by the internal team that manages CloudFormation that the propagation of IAM policies and resources might take longer than CloudFormation to launch the dependent resources. This race condition happens now and then, and unfortunately CloudFormation team is not able to determine programmatically when a role is effectively available in a region.
To workaround it, the stack with just IAM polices update (and no autoscaling resources yet) needs to be deployed first, and then further deployment may carry the autoscaling resources update (unfortunately just relying on
DependsOn brings no rescue)
To make handling of that case easier this plugin enables the IAM only deployment via
iamOnly option, you may refer to this option as one-time mean
custom: dynamodbAutoscaling: iamOnly: true