Myths about Cloud Native Finance Management tools (2/3)
CPO AND CO-FOUNDER
Lead Product Developer
Organizations move to the cloud thinking that the flexible cloud environments would mean less cost for running their workloads. Oftentimes they find out the opposite is true.
In those cases they start to find opportunities to optimize their cloud deployments. They seek optimization opportunities in rightsizing, minimizing unused resources, buying new reserved instances and savings plans, implementing startup / shutdown schedules on non-production resources, consolidating their containers onto the same hosts, and more.
Can they maximize their cost optimization opportunities using the cloud native finance management tools? The answer is no. Let’s explore the reality in this blog post.
The myths around cost optimization
Optimizations are not created equal. The cloud native finance management tools, such as AWS Cost Explorer, Azure Cost Management, GCP Compute Engine, do provide cost optimization recommendations. And yet are they sufficient? Let’s read on…
Myth 1: Rightsizing recommendations are created equal
Reality is rightsizing recommendations are not created equal. As you can appreciate, the more abundant the data the more accurate the statistical analysis. AWS Cost Explorer uses 7 days of historical data, Azure Advisor uses 14 days of data. If your resource activities fluctuate outside of the 1 – 2 week window, the analysis can be off. You need recommendations created from longer history or a configurable amount of time window.
Furthermore, rightsizing analysis should include as much resource utilization data as possible including CPU, memory, bandwidth and more. AWS Cost Explorer only uses CPU utilization data for their analysis.
Myth 2: Cloud native finance management tools cover all grounds in terms of showing you the underutilized or unused resources, including virtual instances, storage, containers, and more.
Reality is: Depending on the cloud vendor, you may get different levels of information. Most of them focus on information around virtual instances. And yet resources can be in different categories such as virtual instances, storage volumes/snapshots, IP addresses, and more.
AWS Cost Explorer, for example, does not show the unused EBS snapshots. You will have to go to a different tool AWS System Manager to run an automation task to list out the unused EBS snapshots and delete them accordingly. This makes minimizing unused storage a difficult task, and hence your cloud cost cannot be easily reduced.
Besides unused storage volumes, unused IOPS can also be crucial in reducing your cloud costs. And yet unused IOPS are typically not surfaced by the cloud native finance management tools.
Now let’s switch gear to look at the containers, which are of increasing importance at organizations. AWS ECS, EKS, Azure AKS, Google GKE, and Kubernetes are being used for microservices. Recommendations such as changing the resource reservations and consolidating the hosting nodes to reduce costs are not surfaced by the cloud native finance management tools.
Myth 3: Recommendations can be easily put into action on cloud native platforms
Reality is: Cloud vendors provide cost optimization recommendations separately from their operation consoles. Customers typically have to download the recommendations and perform the actions manually in the operations consoles separately. For example, AWS Cost Explorer can give you the reports for rightsizing, but you will have to perform the rightsizing yourselves.
Myth 4: Scheduling startup and shutdown is easy with the cloud native finance tools
Reality is the cloud native finance management tools may provide you with a feature to create a schedule to startup and shutdown individual virtual instances. And yet there are no recommendations from these tools on when to startup and shutdown, and no visibility on the utilization trend of the virtual instances on an hourly basis. Without this information, how can you figure out a good schedule?
Scheduling for individual virtual instance startup and shutdown is likely not sufficient since virtual instances often are part of a cluster or a service. In that case you have to consider all the dependencies when you schedule startup and shutdown. Cloud native finance management tools won’t help you.
Myth 5: Scaling groups are the best you can do for cluster elasticity
Reality is Scaling Groups such as AWS Autoscaling groups provide you a way to configure the max, min and desirable number of nodes in your cluster, and they would help you with scaling up and down the number of nodes as your workload fluctuates in activities. The fact is that you can do better by changing the max, min, and desirable number of nodes according to different factors in your business needs. For example, retails may ramp up during the weekends, and taper off during the weekdays. You can have different configurations for those time segments and you want to schedule those changes automatically. Cloud native finance management tools offer no such schedules.
If you are hitting the pain points mentioned above, please find time to talk to us at Aquila Clouds. Our FinOps platform can address them for you, making cost optimization a much easier experience for you. Most importantly, you can put the saved costs into other revenue generating activities!
That being said, please stay tuned for the next part in this series of blog posts. Until then, hope you consider our free trial of Aquila Clouds FinOps
———-****** NOTES BELOW ******
Cloud consoles have restricted access as console access cannot be granularly controlled. All cloud consoles need multiple clicks to get to the details.Individual resource level billing details are not available at all.
Billing console – RBAC – Granularly view
Console is not even given to the leaders. No visibility. Tech Mahindra. Cloud head
You need to use cloudwatch for performance metrics and Billing console, Cost explorer for getting detailed cost data. Details are available at Service or Account level. Cannot be split into projects within Accounts or Services. Individual Resource level details cannot be found.
Myth 2: You can see the resource utilization trends and cost trends in the same pane of glass, without having to flip back and forth between different screens.
Realty is: Cost and Utilization are available in different views. It is cumbersome to switch views and check the relevant data as they are not enabled in the same flow.
Azure Monitor – monitoring
Azure Advisor for recommendations
Myth 3: Everyone has access to the same information.
Realty is: Billing is accessible only at the master/payee level. Department owners or Sub account level users either will be allowed to see all information or none.
Myth 4: You can easily download a current snapshot of your cloud resource list and feed into your Change Management system for inventory tracking.
Realty is: Resource level information listing across subscriptions/accounts/projects is not possible in a single view in the cloud native consoles.
Myth 5: You can get alerts for misuse of resources, e.g. an engineer spinning off cloud resources for bitcoin mining or a hacker stealing data from your cloud deployments.
Realty is: Chargeable per Alerts/Alarm. Nothing out of the box available by default. Need to configure at a low level such as CPU, Memory or Billing based. Billing based alerts can be too late to prevent significant damage.
Configuration – rule-based, metric-based. They need ML.
Curated use case. Applicable.
You need to get to shift to the new generation
XXX NOTES BELOW XXX
- List all the cloud native finance management tools
- AWS cost explorer
Top 10 myths
AWS Cost Explorer –
- Rightsize recommendations:
- To identify all instances for all accounts in the consolidated billing family, rightsizing recommendations look at the usage for the last 14 days for each account. If the instance was stopped or terminated, we remove it from consideration. For all remaining instances, we call CloudWatch to get maximum CPU utilization data, memory utilization (if enabled), network in/out, local disk input/ output (I/O), and performance of attached EBS volumes for the last 14 days. This is to produce conservative recommendations, not to recommend instance modifications that could be detrimental to application performance or that could unexpectedly impact your performance.