This past March, the Cloud Native Computing Foundation (CNCF) hosted KubeCon+CloudNativeCon Europe 2024, a conference that focused on the latest cloud-native technologies and drew over 12,000 attendees. I had the opportunity of co-presenting a session titled “To Infinity and Beyond: Seamless Autoscaling with in-Place Resource Resize for Kubernetes Pods,” which delved into Kubernetes resource management, a subject of importance for efficiently running applications on this platform.

In the last blog post in this series on AWS billing we began looking at AWS billing and CUR files. In that post we discussed the intricacies of how AWS calculates an instance’s usage, and in this post we want to continue talking about these files, but this time, focus on savings plans.

At CloudNative Days Tokyo 2023, one of Japan's largest tech conferences dedicated to cloud-native technologies and development, I had the opportunity to give a talk on the topic at the Kubernetes cost optimization: “FinOps! The Path to Kubernetes Cost Optimization with Karpenter”.

When setting up a Kubernetes cluster, you need to specify the type of node instances and the quantity of nodes for each type. Alternatively, you can configure autoscaling for the node count. However, determining the correct configuration can be challenging due to the abundance of tuning options. For example, there are usually hundreds of instance types available.

In the first post in this series, I detailed how AWS CUR files calculate an instance’s usage along with an interesting quirk of the system. In the last blog post in this series, I dove into detail of how Savings Plans appear in AWS CUR files. In this post I will walk through how the processes laid out in the other two posts are combined in AWS and lead to significantly unexpected behavior.

In the last blog post in this series on AWS billing we began looking at AWS billing and CUR files. In that post we discussed the intricacies of how AWS calculates an instance’s usage, and in this post we want to continue talking about these files, but this time, focus on savings plans.

At CloudNatix we are developing integration of billing data directly into our recommendations (big things to come).

Autoscaling is key for a cost-effective and scalable platform. However, autoscaling increases the frequency of Pod eviction. This can lead to availability issues.

The team at Cloudnatix is especially excited to announce our partnership with Datadog.

We are pleased to announce that Intel Ignite has selected CloudNatix for their fall 2023 U.S. cohort of selected startups.

At CloudNatix we aim to provide highly automated and efficient computing environments for our customers.

Last week we learned how our design system makes infrastructure management easier for our customers. We will continue that discussion and look at some additional benefits of our design system.

At CloudNatix, we have utilized design systems from the beginning of our product. They allow us to make infrastructure management easier for our customers.

CloudNatix now available on Azure Marketplace

Spot rebalancing helps users offset the cost of on-demand nodes and leverages spot instances when they become available for cloud resource and cost optimization.

Allocating cost and resources to different teams across cloud environments can be really challenging in cloud-native environments. Learn how to gain an accurate picture of your kubernetes environments across teams.

AWS customers can now deploy the CloudNatix platform through the AWS marketplace

Eliminate the need to cut cloud costs with continuous optimization.

CloudNatix reaches Soc 2 Type II compliance, a new milestone on its journey to eliminate cloud waste.

Designing and creating a UI to manage the complex world of Kubernetes, VMs and other advanced technologies is no easy task; however, democratizing access to powerful technologies is something that we’re passionate about. One of the most powerful tools we use to accomplish this is the User Centered Design process.