Good news for everyone who have been over provisioning DynamomDB!
1 Like
I published a plugin to remove all the overhead from the Auto Scaling configuration:
3 Likes
Nice add @sbstjn
Works great with one table.
Trying to use it with multiple tables, CloudFormation fails creating the CloudWatch alarms with the following Error:
An error occurred while provisioning your stack: TableReadScalingPolicymytable - Unable to create alarms for scaling policy TableReadScalingPolicymytable due to reason: Rate exceeded (Service: AmazonCloudWatch; Status Code: 400; Error Code: Throttling;
Request ID: abababab-abab-abab-abab-abababababab).
Is there any way you can include DependsOn clauses in the CloudFormation template where each alarm depends on the previous alarm to override the default parallelism of CF attempting to create the CW alarms?
Just a thought.
But great work. Thanks!
Hey Brett,
thanks for trying out the plugin!
How many tables do you try to update? I just created five tables with Auto Scaling and everything works fine. Can you provide an example serverless.yml so I can reproduce this?
Hi @sbstjn
It appears to work fine with one, but fails with any more than one.
Here is a gist of a simplified serverless project.
If you comment out tables 2-5 in the autoscale.yml it will deploy fine, but fail if you have more than 1 uncommented.
Hope it helps.
1 Like
Thanks for the configuration files. I created a GitHub issue for this. Hopefully, I can find a solution for this soon.
1 Like
I just released v0.2.0 which should prevent this. But there is a breaking change in the configuration API. Would be awesome if you can try the new version and check if your configuration still fails.
1 Like
Just gave it a go with the sample config I shared with you the other day and it all went smoothly.
Going to update the stack I’m working on at “DayJob01” and see how that goes…
Great work!
edit:
Looks like I spoke too soon.
Worked well when creating the stack fresh. ie. Included the building of the Tables.
But Updating a stack to Add Autoscaling to a stack that already had the Tables created is falling over.
Here’s the error message from sls deploy:
An error occurred while provisioning your stack: TableReadScalingPolicyMyTable3 - Unable to create alarms for scaling policy TableReadScalingPolicyMyTable3 due to reason: Rate exceeded (Service: Amazon
CloudWatch; Status Code: 400; Error Code: Throttling; Request ID: b5e3013a-6e33-11e7-9a26-596460447a11).
1 Like
Getting a strange intermittent error:
Not sure if it’s in your code or in CF’s implementation of the scaling functionality.
An error occurred while provisioning your stack: AutoScalingTargetReadMyTable3 - Validation failed for resource: table/dev-table3, scalable dimension: dynamodb:table:ReadCapacityUnits. Reason: The security token included in the request is invalid..
And it’s random as to what element it fails on… Can be any of the 5 tables, and either Read or Write. and sometimes it actually succeeds.
Having another issue with trying to deploy to different stages as well. But still trying to nail down precisely where it’s happening. Will add that when I nail it down.
Based on the AWS docs I think the expired token is a general problem , but not directly related to the plugin. Maybe the CloudFormation deploy process takes too long, so a temporary token may expire?
I added more values to the DependsOn list in an open Pull Request. Hopefully this will prevent the Rate exceeded errors. Feel free to check out the branch or wait until a next release 
Regarding the API rate error: I think you should request an inrease of the CloudWatch rate limit: http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html
The other issue I was trying to pin down.
Seems that the Role the plugin creates, ‘DynamoDBAutoscaleRole-< table>’ isn’t stage specific. so when trying to deploy to another stage, it burps trying to create a Role that already exists.
True. I will add the stage to the namings …
1 Like
I installed the plugin and configured. When I deploy I do not get any errors but the auto scaling properties of the tables do not change. I am trying to set auto scaling for two tables and there are no indexes. Any ideas?
Did you include the following in your serverless.yml?:
plugins:
- serverless-dynamodb-autoscaling
I only ask because I ran into this at first as well.
Hope it helps.
Having the same problem as @bfieber, @sbstjn… upon stack update, I think it’s still hitting the PutMetricAlarm limit:
An error occurred: irhbackendTableScalingPolicyReadSponsorshipsDbThorndikeUseast1 - Unable to create alarms for scaling policy irhbackendTableScalingPolicyReadSponsorshipsDbThorndikeUseast1 due to reason: Rate exceeded (Service: AmazonCloudWatch; Status Code: 400; Error Code: Throttling; Request ID: dad4cc23-d376-11e7-842b-a3d7d952d5ce).
Looks like the dependencies you currently have are all logical dependencies … I think you need illogical dependencies, i.e. dependencies to the other scaling policies and scaleable targets being created simultaneously, because those are the ones that add up to the rate limit.
Hi sbstjn,
When executing sls package I have this error:
Serverless plugin “serverless-dynamodb-autoscaling” initialization errored: Unexpected token …
It is strange because the only things I did was
$ npm install serverless-dynamodb-autoscaling
serverless-dynamodb-autoscaling@0.6.2 node_modules/serverless-dynamodb-autoscaling
├── md5@2.2.1 (charenc@0.0.2, crypt@0.0.2, is-buffer@1.1.6)
└── lodash@4.17.5
and added
plugins:
– serverless-dynamodb-autoscaling
to the serverless.yml file.
Adding this configuration doesn’t solve the problem:
custom:
capacities:
- table: applicationsTable # DynamoDB Resource
index: # List or single index name
read:
minimum: 1 # Minimum read capacity
maximum: 5 # Maximum read capacity
usage: 0.75 # Targeted usage percentage
write:
minimum: 1 # Minimum write capacity
maximum: 5 # Maximum write capacity
usage: 0.5 # Targeted usage percentage
Do you have any idea what might cause this error?
Pieter