Deploying Android Emulators on AWS EC2 [3/3] | Autoscaling Bare Metal Instances| Cost Optimizations for Organization
To condense this entire post into one sentence: It would be you can host a well-running android emulator on the AWS cloud for about $0.0325 per hour.
Got your attention? Good.
Welcome to the final post of a 3 part series Deploying Android Emulators on AWS EC2. In this post, I would like to introduce you to the wonders of spot instances and how can you exploit their cheapness to your own benefit. But before we dig into that, in case you somehow directly jumped to this post, I'd suggest you check out the last 2 ones too to get a recap of what we’ve been up to till now.
- Link to part 1 (ARM Architecture and Genymotion | Solutions for a Solo Developer)
- Link to part 2 (Bare Metal instances and Hardware acceleration| Solutions for an organization)
- You are at part 3.
So, what are Spot instances? 💳
Taking the definition off the AWS website “A Spot Instance is an unused EC2 instance that is available for less than the On-Demand price. Because Spot Instances enable you to request unused EC2 instances at steep discounts, you can lower your Amazon EC2 costs significantly. The hourly price for a Spot Instance is called a Spot price.”
Note, Spot instances are excellent for the use cases where you can afford your applications to be interrupted, or you have backup instances to complete unfinished jobs those applications hosted on that particular instance were supposed to handle. In addition to those, there are certain things I would recommend you to go through before considering Spot instances as your option:
- The hourly price of a Spot instance varies while that of the On-demand instance is static.
- If capacity is not available, the Spot Request continues to automatically make the launch request until capacity becomes available. This means it doesn’t guarantee that your instances are always up. i.e. there is always a possibility (however minuscule it might be) that your emulators are never up and running
Alright, now that we are done with the disclaimers, allow me to show you the price reduction chart, the entire reason why you are reading this post
As you can see there is about ~90% cost reduction in on-demand to spot instances. This, my dear friend, is
Why Autoscaling Groups? 🧑🏫
Looking over disclaimers, you would notice instance interruption. No, the question can be asked, what if I create a simple spot instance and it gets interrupted, will I get it back? No. You won’t.
So do you need to keep creating and configuring EC2 machines again and again? No, you don’t need to do that either.
This is where autoscaling groups come in handy. The ASG requires a Launch Template, which is essentially an image of the instance you have pre-configured to run on multiple new EC2 instances.
What does a launch config look like? 👀
Here you can see that sampleEmulatorTemplate specifies a specific instance type (m5.metal) and the AMI ID (the instance image to be deployed in auto scaler groups). You can specify key-pair logins, security groups, etc in this too.
Autoscaler Magic ✨
Now, for the money shot, you can deploy your EC2 instance image on a “desired” number of new machines. Using the following settings:
Here you can see three settings in your auto scalers tab, Desired capacity is the number of instances we want at all the time. Minimum Capacity is the minimum number of instances that should always be there regardless of the cost incurred. Maximum Capacity is the maximum number of instances you would want to spawn in the group.
The next important question to address is usually how to ensure that your scaler uses the spot instances only, for that you can make sure your instance purchase configurations look like this
- We are not adhering to the launch template because we want spot instances here, regardless of the type of instances our launch template is using (ex: on-demand / reserved)
- You always want 100% spot instances. NO MATTER WHAT.
- Don’t tick capacity rebalance, to gracefully shutdown your spot instances, it might replace them with on-demand instances to ensure a smooth transition.
Conclusion 🎩
This brings us to the conclusion of our cost optimization attempts. You can play around with your instance types and see what alternatives you can use, for example, m5.metal can be replaced with m5d.metal as per your needs and it might run just fine according to the instance demands. Rest assured, you can use the same configs shared here in other ASG deployments and it would optimize the costs in a similar basis.
