-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scale down dynamo #27
Comments
Hi, thanks for the suggestion. Should be easy to implement, using these APIs:
We would need to identify any indexes on a table and scale those down too. Dealing with tables that have autoscaling enabled might a bit tricky, we would have to query other AWS resources to find those I think, this also goes for indexes that might have auto-scaling. |
For auto-scaled tables, we would need to query this API: Using a |
Could you not tag the tables themselves? |
Yeah we could definetly do that, good idea. 👍 |
For tables without autoscaling it should be fairly simple to record previous values:
For autoscaling I think we would need to store upto 6 values:
Looks like we would also have to query this API to get the scalable targets https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/ApplicationAutoScaling.html#describeScalableTargets-property as well as this to update the |
On second thought we might not have to store the read/write utilization values if we do not change them 🤔 |
Dynamo tables can also consume a lot of resource when not in use. Though you can use auto-scaling, you wont necessarily be scaling down to 1. So if hammertime reduced read and write capacity of tables to 1 outside business hours and set back to what it was (including autoscaling settings) when it restored this could save some money.
The text was updated successfully, but these errors were encountered: