Cost Optimization Using Launch Template in AWS
Posted on Jun 28, 2019 by Govind Kumar
“When It comes to cloud computing then, Amazon Web Services is well known for offering substantial solutions for any IT company. You don’t need to have any hardware and it gives the opportunity to focus directly on a product rather than infrastructure, maintenance, or upgrades. But using this solution in the absence of planning can be very dangerous. It can be very expensive, making constant cost optimization a critical necessity. Let us discuss the cost optimization techniques for an EC2 instance.”
- Strategic planning while selecting an instance class.
The first and foremost rule to use EC2 instance is to identify the application demand and its purpose. AWS offers a number of different EC2 instance types based on the desired uses. Eg. General purpose, Compute-optimized, Memory-optimized, storage-optimized et cetera. First, analyze your application and make sure that what is the requirement in terms of capacity else you will end up paying for over-provisioned resources.
- Implementation of Autoscaling for those instances:
AWS EC2 auto-scaling monitors application and scale if needed to provide the best performance at the lowest possible cost. There are can be several metrics that can be used to scale EC2 up or down (Memory, CPU etc).
AWS EC2 Autoscaling Management Console[/caption]While creating auto-scaling group we get two options through which we can start the proceedings of Auto-Scaling group creation.
- Launch Configuration
- Launch Template
Launch Configuration is an instance configuration template that an auto-scaling group uses to launch EC2 instances. In the launch configuration, we specify the AMI, Instance type, purchasing option, key pair, et cetera. We can specify our launch configuration with multiple ASG. However, we can specify only one launch configuration for an ASG at a time, you can’t modify a launch configuration after you’ve created. To change the launch configuration you must create one and update that with ASG.
. . .
Launch Template: An eye-catching feature that recently came into the discussion is Launch Template. A launch template is similar to Launch Configuration, in that it has specified instance configuration information. Included are the ID of the AMI, the instance type, a key pair, security groups and the other parameters that we specify while launching an EC2 instance. However, defining a launch template instead of a launch configuration allows you to have multiple versions of a template with versioning. We can create a subset of the full set of parameters and then reuse it to create other templates or template versions.
- Earlier, the ASG used to grow and shrink in response to changing conditions, now adding to it, it will also have a combination of EC2 instance types and pricing models defined by us. It gives us the full control of instance types that will be used to build our group, along with the ability to control the mix of on-demand and spot instances. While configuring the ASG with launch template it gives the option to select the fleet composition. Fleet composition works with two options.
- In the first option, it will directly adhere to the launch template. It means, whatever we specify in the Launch template, either it is purchasing option or instance types, it will directly follow that.
- The second option is to combine the purchasing option and instance types in one fleet. We need to specify the instance types depending upon the pricing strategy and resource requirement. The order in which we specify the instance type will also decide the launch priority of the instances one we specify. Once we are done with that, it asks for the instance distribution strategy. It specifies the allocation of on-demand and spot instances, the maximum price for spot instances we willing to pay, and the strategy for diversifying spot instances across the instance type specified. Thereafter, we specify the desired number of instances then It gives us the freedom to define a baseline of on-demand instances. Baseline instances mean it will keep the count of that much on-demand instances and thereafter it will decide to depend upon the specified value(in terms of percentage) how much on-demand and how much spot instance need to be launched over the baseline to fulfil the desired capacity.
An Example to Understand the Scaling Behaviour[/caption]
Q. How Autoscaling will behave if no spot instance is present within the specified bid price?
A. Let us understand a scenario where we need 12 Instances in an ASG. We defined On-demand base is equal to 2. Now the On-demand percentage above the base is 30% and the rest 70% are Spot Instances. Our specified bidding price is also very less and hence there is no spot instance falling inside that bid, how the autoscaling will behave? In such cases, autoscaling will launch 2 On-demand base instances, 3 (i.e 30% of 10 Instances) more On-demand instances as we specified above the base and will keep on trying with the spot instances, if it finds any instance within that range then it will launch else it will keep on trying until it succeeds.
Q. How much cost can be saved by implementing this Launch Template with ASG?
A: Let us take a use case, where we have an ASG with (Min = 4, Max= 10, Desired = 4). The previously defined instance class in launch configuration is t2.xlarge, Now let us check to how much savings can be made using the various permutations and combinations in that.
Scenario 1:
All Ondemand Instances are present.
Number of Instances in ASG = 4;
Instance Capacity = t2.xlarge (4 vCPU and 16GiB memory)
In such cases the calculation will look like this: Price of t2.xlarge = $0.1984/hr = 0.1984 x 24 x 30= $142.9/month. Total cost for 4 instances = $142.9 x 4 = $572/month
Scenario 2:
All reserved instances are present.
Number of instances in ASG = 4;
Instance Capacity = t2.xlarge (4 vCPU and 16GiB memory)
Use of Reserved Instances: Price for t2.xlarge reserved instances = $0.118/hr = 0.118 x 24 x 30 = $84.96/month Total cost for 4 instances = $84.96x4 = $339.84/month So, a total saving of $572-$339.84 = $232.16/month
Scenario 3:
A combination of reserved instances and Spot Instance of t2.xlarge capacity is present.
Number of instances in ASG = 4;
Number of Reserved Instance = 2; Number of Spot Instance = 2
Price of two t2.xlarge instances = 0.118x24x30x2 = $169.92 Bidding price of t2.xlarge spot instance = $0.06/hr Calculation for a month = 0.06x24x30 = $86.4 Calculation for 2 spot instances = $86.4 x 2 = $172.8 Total Cost = $ 172.8 + $ 169.92 = $256.32 Tatal Savings from Ondemand = $572 - 256.32 = $315.68
Scenario 4:
Highly Available plus cost Optimized fleet
To make our application highly available, let us make use of fleet composition:
Let us specify the instance types like this: Base Instances = 2 reserved instance Other instance composition t2.xlarge (Spot price = $0.06/hr) t3.xlarge (Spot price = $0.0538/hr) M5.xlarge(Spot price = $0.078/hr) Let us take an extreme case where no instances of t2.xlarge capacity are available, so is with t3.xlarge) hence the ASG launched the instances of M5.xlarge capacity. The calculation will look like this: Price of two t2.xlarge instances = 0.118x24x30x2 = $169.92 Bidding price of M4.xlarge spot instance = $0.078/hr Calculation for 2 spot instances = $0.078x24x30 x 2 = $112.32 Total Cost = $ 169.92 + $ 112.32 = $282.24 Tatal Savings from Ondemand = $572 - 282.24 = $289.76
Conclusion: So, here in this fleet composition although we are using the instances of another family with diverse instance capacity still we are saving almost 52–54% of the cost that we were spending over on-demand.
Q. What combination can help us in achieving highly available and cost-optimized ASG?
A. Using a combination of reserved instances along with the spot instances and defining the instances of diverse types with almost near computing capacity (eg. another instance of almost same CPU or Memory or near to that from a different family) will make sure that the maximum chances of the spot instances will be there. If in case, one instance of the t2 class is not under the budget then it will go for t3, m4 and so on, causing the maximum chances of getting the spot instances. Sometimes the cost for the better resource may be less than the one with a lesser capacity in case of spot pricing model.
Q. How difficult it is to migrate from Launch Configuration to Launch template in an ASG?
A. It is very simple, just create a launch template by directly selecting the option (Copy as a launch template) in the launch configuration window. Go and update the ASG by selecting the option of launch instance using from Launch Configuration to Launch template and specifying the various purchasing option followed by the fleet combination.
Q. Where else we can use Launch template?
A. Launch template can be used while:
i) Launching an EC2 instance.
ii) Creating and Autoscaling group
iii) In a spot fleet.
iv) In an EC2 fleet.
Q. What is EC2 fleet and how it is different from spot fleet?
A. Spot fleet —
i) Created through the console, API, AWS CLI.
ii) Can use spot instances but can keep an optional baseline of on-demand instances if selected.
iii) Uses automatic scaling for scaling procedure (Such as step, scheduled, and target tracking scaling)
iv) Only operates in 1 Availability zone.
v) Primary capacity handled by less expensive spot instances.
B. EC2 Fleet —
i) Only created through API and AWS CLI
ii) Can use on-demand, spot and reserved instances.
iii) Can’t span regions or subnets, need a separate fleet for each region. Can span multi AZs.
iv) EC2 instance themselves are configured through fleet configurations.
v) Manages the scaling based on configuration and pricing.
Q. How EC2 fleet is different from ASG fleet combinations and its use cases?
A. EC2 fleet’s underlying tech uses Application Auto Scaling. This suite is generic in nature so that the scaling feature can be implemented across other AWS services (eg. ECS, Spot, DynamoDB). The missing features are dependent on the service (EC2 in this case) to fill in any feature gaps that Application Auto Scaling has.
The EC2 auto-scaling option is designed just for EC2s and has a more robust suite and more features.
EC2 Auto Scaling, however, is strictly for the EC2 service only. This means it has its own API suite and is more robust compared to Application Auto Scaling. An example of something available in EC2 Auto Scaling which Application Auto Scaling doesn’t have is EC2 health checks to monitor and replace if the instance ever becomes unhealthy.
