Stefan Knight | Thu, 21 Feb 2019
Just like hundreds of happy customers, you could scale multiple Auto Scaling Groups settings to 0, cache their settings and separately restore each ASG to their previous settings (avoiding CloudFormation drift).
At GorillaStack we live and breathe cloud cost optimization as a key use case of our SaaS platform. Other use cases include purging wasted resources, custom code automation, ChatOps, automatic cloud backup and more. In the area of cost optimization we focus on what we call ARE: availability, retention and elasticity. This note will focus on elasticity.
Elasticity is a great feature of cloud. We see many customers use Auto Scaling Groups for their Dev EC2 instances & Azure VMs so that capacity scales up and demand as they work on their applications each day. The only issue with ASGs is that outside of business hours they will still run the minimum number of instances which costs money even though they aren’t being utilized. We’ve also seen production use cases where it would be ideal to scale an ASG down to 0 running instances. One such use case is a VDI farm that isn’t used on weekends. While you may not want to adjust the minimum number of instances all way down to 0 in this case, it would be worthwhile to reduce the minimum and desired values based on known traffic patterns.
Another elastic resource that we’ve seen customers want to adjust the throughput for in real time is AWS DyanmoDB. Responding to customer demand, we introduced a capability to adjust the read and write capacity on the fly. Whilst DynamoDB does scale up and down automatically, customers were finding that it took too much time to scale up which created performance issues and was too slow to scale down generating unnecessary costs.
We’ll highlight these great cost savings capabilities for tuning Elasticity.
In the screenshot below you can see the intuitive interface for adjusting ASGs on the fly. Customers are either invoking this capability based on a schedule or manually through the Web App or via a Webhook triggered from Slack which is a great way to turn on the ASG only when needed by a particular team.
You can adjust the values as well as cache the existing values so that later you can restore the ASG to the cached settings. There’s a helpful paragraph below the form in the Web App that explains all the ways to configure this key action.
In the screenshot below you can see the intuitive interface for adjusting DynamoDB throughput on the fly. Customers are either invoking this capability based on a schedule or manually through the Web App or via a Webhook triggered from Slack.
You can adjust both the read and write capacity of tables on the fly. Our customers adjust them up when the day begins and there’s a known minimum load threshold that will guarantee a good end user experience. Later they adjust them down, perhaps to 0 to avoid spending money on a very slow ramp down.