Cost Saving Methodology
Following the guidelines below will allow you to use our free tool to make sure you do not pay for what you do not use. This will work well for anyone using AWS in any case
Tag ALL resources. Use the following system:
prod-XXX is a production service, not to be touched!
up/down/duration - will start or stop the service on cue
up-Fri-09:00 - start the service every Friday at 9 am.
down-Day-22:00 - stop the service every day at 10 pm.
up-2017-12-31-00:00 - start the service on the 31st of Dec 2017 at midnight.
down-Month-15-18:00 - stop the service on the 15th of every month at 6 pm.
dur-5h - stop the service after 5 hours of uptime. It also works with 5d (days) or 5m (months).
SnapOnShutDown - after instance shuts down, this tag creates a snap of this volume then detaches & deletes it.
del-2017-10-10 - terminate an object or delete a bucket
ren-Day-00:00 - this will add the date to the name (of the bucket for example)
Auto Scaling Groups ASG
SpotASG - this tag will convert any Auto Scaling (ASG) to an ASG running on Spot instances (spots). Place the SpotASG tag on your OnDemand ASG. CloudHawk will create a matching spot based ASG. When the spots become available and desired capacity is reached in the spot ASG, the original OnDemand ASG will be automatically shut down. If the spots will be taken away, CloudHawk will automatically re-launch the OnDemand ASG. This will save you approximately 75% of your EC2 usage.
To learn more about spot pricing, please visit spot pricing
SetMDM - this tag allows you to reset the Minimum Desired and Maximum values of an ASG. This allows you to "shutdown" "start" or simply resize the ASG for multiple purposes. E.g. change the Desired value ahead of time to avoid the impact of the warm up time.
Format: Set-MDM-Time/Freq where Time/Freq is similar to the EC2 tags above. E.g. SetMDM-2-3-4-Day-08:00.
CloudHawk will automatically execute all the above tags for you.
How to choose an EC2 instance
Counter-intuitively, instances should not be chosen by CPU cores or memory, but rather network bandwidth. So first, get that right. Then look at other parameters.
Then figure out, are you CPU bound or Memory bound and why.
- If you are CPU bound
- Make sure you understand different Intel processors have different capabilities to process different CPU bound efforts, like encoding/decoding and vector processing.
- Choose from the instances with the right type of CPU.
- If you are memory bound, choose the cheapest instance that provides the memory you need. and... be ready to switch if that changes.
Many times there are applications that require neither excessive CPU nor memory. In this case try the minimal one that satisfies your bandwidth requirements. In this case it's preferable to place it in an auto-scaling group.
It does not matter which container you use, just use them. Containers like Docker are a great way to use your resources more efficiently. This allows you to spin up and shut down more instances of your application as required across multiple types of computing resources. This can work automatically (preferred) or manually.