Cost Optimization: Resize the VM based on its Utilization with Kubiya

Introduction

In an era where cloud infrastructure serves as the backbone of enterprises, managing operational costs effectively has never been more critical. Cost optimization is not merely about reducing expenses but about maximizing efficiency and resource utilization. This is particularly relevant where resources like virtual machines (such as AWS EC2, Azure VMs, and Google Compute Engine) can scale dynamically with demand.

Enterprises achieve benefits from cost optimization techniques that emphasize:
Cost Reduction: Businesses save significantly on costs without overspending on unused or overprovisioned resources.
Reduced Idle resources: Ensuring that resources match the workload demands means companies only pay for what they need, eliminating overspending on underutilized resources for VMs (such as unused RAM, storage, and CPU processors).
Enhanced performance: Heavy workloads can't be run on VMs with insufficient specs. Therefore, by dynamically resizing VMs to meet real-time demand, costs align more closely with actual usage, and application performance remains optimal.

Cost optimization often primarily includes right-sizing your resources based on your workload. Therefore, manually resizing multiple resources (like VMs, database instances, and Kubernetes clusters) via the cloud provider’s management console (AWS, Azure GCP, etc.) entails a time-consuming, error-prone process comprising multiple steps. In contrast, Kubiya automates resizing with just one probe, eliminating deep knowledge of the cloud management console.

In this write-up, we delve into effective strategies for achieving cloud cost optimization, examine the repercussions of neglecting best practices for cloud cost management, and introduce how Kubiya intelligently automates tasks involving cost optimization.

Strategies for Cloud Cost Optimization

Let us discuss various strategies we can use to optimize our costs in the cloud.

Effective Resource Management

Effective resource management is about ensuring that cloud services are appropriately sized to meet your business growth and workload demands without overprovisioning. This involves analyzing your usage patterns and adjusting your resources to match those patterns as closely as possible.

To make it more clear, take an e-commerce platform that experiences varying levels of traffic throughout the day, with peaks during noon hours and in the evening. The cloud platform automatically adjusts the number of active instances based on the current load by implementing auto-scaling. Additional instances are spun up during peak times to handle the increased traffic. Once the traffic sets low, the extra instances are terminated. This approach ensures the platform performs optimally during high demand while keeping costs low during off-peak hours.

Budgeting and Cost Visibility

Budgeting and cost visibility are crucial for tracking cloud spending and ensuring it aligns with your organization's financial budget. This strategy involves setting up budgets for different projects or departments (in your organization) and monitoring spending against these budgets in real time.

For instance, a company allocates a monthly budget for its cloud services in development, testing, and production environments. Cloud cost management tools like AWS Cost Explorer or Azure Cost Management can track spending in real-time for each environment. The tool alerts the finance or development team if the testing environment is nearing its budget limit. They can then decide whether to increase the budget based on necessity or reduce resource usage in the testing environment to stay within the budget.

Selecting the Right Pricing Options

Choosing the right pricing models for your cloud services can significantly impact your costs. Cloud providers (like AWS, Azure, GCP) offer various pricing options. For this context, AWS offers on-demand, reserved, and spot instances, each with advantages and cost-saving potential.

On-demand: You pay for computing capacity by the hour or the second with no long-term commitments. This is ideal for workloads with unpredictable usage patterns.
Reserved instances: Committing to a specific amount of compute capacity for a 1-year or 3-year term can result in a significant discount compared to on-demand prices. Suitable for workloads with predictable usage.
Spot instances: You can bid for unused cloud capacity at potentially lower prices. Best for short-term flexible workloads that can handle interruptions.

In a DevOps-focused team, utilizing reserved instances for consistent CI/CD pipeline operations ensures cost savings for predictable workloads. Conversely, spot instances are ideal for handling the variable short-term workloads seen during intense development sprints, such as batch processing, testing, or deployment tasks. This strategic combination of reserved and spot instances can significantly lower costs compared to relying on on-demand instances.

Current Challenges with Cost Optimization

Companies risk encountering significant challenges by neglecting cost-optimization strategies that are essential for saving costs efficiently and within their business or organizational operations.

The challenges outlined below involve considerable manual effort to monitor and optimize cloud costs effectively, a task that becomes particularly daunting when over 1000 resources provisioned in your cloud environment. Thus, this is where ChatOps tools like Kubiya come into the picture to tackle the below challenges.

1. Unchecked Cloud Spending and Underutilized Resources

Unchecked cloud spending is when a company's cloud computing costs escalate beyond anticipated or budgeted amounts due to lack of oversight, poor resource management, or inadequate cost-control measures. This can happen when businesses rapidly scale their cloud resources to meet operational demands without properly assessing the cost implications or when they fail to delete underutilized resources.

Example: Consider a scenario where a tech startup sets up an Amazon EKS cluster to deploy their microservices architecture. They overestimate their resource requirements, neglecting nodes' right-sizing, and provisioning a cluster with multiple m5.large nodes, expecting high traffic volumes. Without proper cost monitoring and examining Cloudwatch metrics for these nodes, the company fails to notice that many of these nodes are underutilized during off-peak hours. This leads to resource wastage and unchecked cloud spending, as they are billed for compute capacity that far exceeds their actual needs.

Kubiya: Rather than manually tracking CPU utilization to identify underused cloud resources, simply prompt Kubiya to list all resources operating below 30% CPU utilization. You can further prompt Kubiya to terminate the resources that are below 30% CPU utilization.

2. Not Automating Cost Optimization

Optimizing cloud costs isn't a single event but an ongoing process, involving constant monitoring and examination. Manually managing the resources to reduce your costs can be time-consuming and error-prone. This leads to increased operational complexity, reduced productivity, and business value. This can manifest in several ways, including spending excessive time on routine cloud management tasks, manual intervention for scaling operations, etc.

Example: A company uses Amazon EC2 instances to run a web application, with manual scaling procedures to adjust capacity during different traffic periods. The operations team manually increases the number of instances during expected traffic spikes and decreases them afterward. This manual intervention consumes significant time and effort and introduces delays and potential errors, leading to inefficiencies.

Kubiya: You can prompt Kubiya to check for underutilized resources which has CPU utilization less than 40%, and resize those instances instead of manually scaling them every time.
Overlooking Right Plans

3. Overlooking Right Plans

Leveraging reserved instances or savings plans is a highly efficient cloud cost optimization strategy. These options, offered by cloud service providers (like AWS, Azure, GCP), offer a business-focused opportunity to commit to a specific usage level in return for lower rates.

Example: An enterprise relies heavily on computing resources for data analysis and customer service platforms, consistently using a fleet of Amazon EC2 instances. Despite a predictable and stable demand for computing power, the company continues to use on-demand pricing for all its EC2 instances. This approach overlooks the potential cost savings that could be achieved through Reserved Instances (RIs) or AWS Savings Plans. Not committing to Reserved Instances or Savings Plans misses out on discounts of up to 75% compared to on-demand pricing.

Kubiya: You can consult Kubiya for recommendations on cost-saving strategies for your workloads. It will also guide you through implementing the most effective cost-optimization practices.

For example, We deployed 10 EC2 instances running and 5 S3 buckets.

Then, we prompted Kubiya to identify and list all the resources within my AWS account that should be terminated to reduce expenses. It systematically listed all relevant resources that could potentially incur costs.

After Kubiya listed all the active resources in our cloud environment, we asked Kubiya to recommend which resources should be deleted from our environment, and it efficiently pinpointed resources that were infrequently used or underutilized for potential deletion.

How to Leverage Kubiya when it comes to Cost Optimization

#Use Case 1: Right-sizing instances using Kubiya

Now, let us see a use case where Kubiya can be helpful in optimizing your cloud expenditures.

• First, we can list all the EC2 instances that are running in our environment. We see an instance named kubiya-large-instance, which has an instance type of t2.large deployed in the us-west-1 region.

• We can reflect instance information in our AWS console.

• We can analyze the instance's Cloudwatch metrics, focusing on CPU utilization, to determine if any instance is experiencing a high CPU load. Kubiya offers the capability to display CPU utilization for all instances; however, our interest specifically lies in assessing the largest EC2 instance. By instructing Kubiya Jr. to examine the CPU utilization of kubiya-large-instance, it retrieves the instance ID and CPU utilization metrics for this particular instance.

• Observing that our CPU utilization is suboptimal for a large instance, we decided to downsize to a t2.micro. Upon instructing Kubi Jr, it efficiently outlines the necessary steps to change our instance type from t2.large to t2.micro.

Kubi.Jr starts with the process of stopping the instance, changing the instance_type from t2.large to t2.micro, and finally starting the instance.

• We received confirmation from Kubi Jr. that our instance has now started. Shortly after, it was successfully resized to a t2.micro and is now fully operational.

#Use Case 2: Running Scheduled Tasks for your Resources with Kubiya

Consider a scenario where a company's development team starts their day at 7:00 AM UTC and wraps up at 5:00 PM UTC. Once the workday concludes at 5 PM, it's practical to halt the operational instances to conserve resources and reduce costs. To streamline this process and minimize manual intervention, we employ Kubiya to automate the start and shutdown of instances, similar to executing scheduled cron jobs.

Utilizing Kubiya's Scheduled Tasks feature, we can seamlessly automate these processes for the development team, ensuring that instances are operational only during necessary hours.

• The development team uses the instance Dev-kubiya-instance for their development tasks, which is now in the stopped state.

• To begin creating a Scheduled task, Type /agent on Slack >Select Scheduled Task > Create a Scheduled Task.

• The first thing we do is describe the task (what task should Kubiya perform). In our case, we mentioned that we should start the Dev-kubiya-instance deployed in the us-west-1 region. We also selected the agent that we deployed on the local Kubernetes cluster that we set up.

• We have to select at the respective time and how often the task will be repeated. We set the time as 7:15 AM UTC and repeat the task Daily. Click on Submit to create the Scheduled task.

• Once our task is configured, Kubi Jr. is automatically activated to execute the task as soon as the specified time criteria are met. We observe that Kubi Jr. initiates the instance named Dev-kubiya-instance. This action is simultaneously updated and visible on our console.

• We can further create a Scheduled task to stop the instance at 5:00 PM UTC daily.

#Use Case 3: Cutting down third-party dependencies

Kubiya is designed to consolidate licensed users across third-party systems, thanks to its agents that act as facilitators for various tasks, including those requiring elevated permissions, running Kubernetes deployments, and managing DevOps workflows. Kubiya effectively replaces the need for subscribing and managing multiple user licenses that platforms like GitLab, ServiceNow, Freshworks, etc. adopt for leveraging their services.

Organizations can achieve more unified and efficient operations by centralizing all the activities through Kubiya agents. This capability not only streamlines operations but also leads to significant cost savings by minimizing the number of required user licenses compared to third-party solutions like Gitlab and others.

Conclusion

In this write-up, we discovered that in the context of cost optimization, manual interventions and lack of oversight can lead to inflated costs and underutilized resources, highlighting the need for continuous, automated solutions.
Kubiya emerges as a powerful ChatOps tool, offering a streamlined approach to optimizing cloud costs by shifting from manual, error-prone processes to automated processes, enhancing overall business operations.

Written and published by:
Pratham Sikka
Full-Stack Developer
Infrasity