“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).
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.