<img height="1" width="1" style="display:none;" alt="LinkedIn" src="https://px.ads.linkedin.com/collect/?pid=1310905&amp;fmt=gif">

Discover

Explore CloudZero


Overview Icon
Overview

Discover the power of cloud cost intelligence.

Services Icon
Services

Give engineering a cloud cost coach.

Pricing Icon
Pricing

Learn more about CloudZero's pricing.

Demo Icon
Demo

Request a demo to see CloudZero in action.

About Icon
About

Learn more about CloudZero and who we are.

Connect With Us

Got questions? We have answers.


Questions Icon

Speak with our Cloud Cost Analysts and get the answers you need.

Get in touch arrow-right

Featured

How SeatGeek Decoded Its AWS Bill and Measured Cost Per Customer

Read customer story arrow-right
User Icon

By Role


Engineering

Enable engineering to make cost-aware development decisions.

Finance

Give finance the context they need to make informed decisions.

FinOps

Decentralize cloud cost and mature your FinOps program.

Use Case Icon

By Use Case


Provider Icon

By Provider


Amazon Web Services (AWS)

Measure, monitor, and optimize cloud spend on AWS.

Snowflake

Combine cloud cost intelligence from AWS and Snowflake.

Resources Icon

Learn


Blog

Discover the best cloud cost optimization content in the industry.

Content Library

Browse helpful webinars, ebooks, and other useful resources.

Case Studies

Learn how we’ve helped happy customers like SeatGeek, Drift, Remitly, and more.

Featured

5 Tactical Ways To Align Engineering And Finance On Cloud Spend

Read blog post arrow-right

Architectural Decisions That Impact Kubernetes Costs

One of the mistakes organizations make related to Kubernetes costs is addressing them primarily after-the-fact, once the application is running successfully.

Is your current cloud cost tool giving you the cost intelligence you need?  Most tools are manual, clunky, and inexact. Discover how CloudZero takes a new  approach to organizing your cloud spend.Click here to learn more.

One of the mistakes organizations make related to Kubernetes costs is addressing them primarily after-the-fact, once the application is running successfully. There are certainly changes that can be made to improve efficiency once the application is running, but cost-control measures are best considered at the beginning, not middle or end, of the application lifecycle. 

Addressing kubernetes costs appropriately requires treating it more like security. Organizations are encouraged to address security earlier and earlier in the lifecycle — ideally it should be baked-in to the entire development process. Cost controls are the same. They are most effective when considered at the outset, because decisions related to the application architecture — some of which are hard to change later — can have a big effect on overall costs. 

Here are some of the top ways that architectural decisions can make costs go up… or down. 

Networking

Understanding in advance how network traffic is going to move through your application and what the cost implications of that traffic will be can help reduce kubernetes costs or, at the very least, ensure that when you’re paying for inter-zone or inter-region traffic, it’s because you’ve made a conscious decision that having a cluster that spans zones or regions is important. 

The same goes for choosing to use a network address translation (NAT) gateway. These can get expensive, so organizations should use them only when actually needed and ensure they are properly configured

Scaling down

Every organization thinks about how to manage auto-scaling… as long as we’re talking about scaling up. Demand for your service will not stay 100% stable, though, nor is it likely to be growing steadily upward every minute of every day. The reason auto-scaling is so attractive is that it allows organizations to only provision the resources they actually need at the moment, but this strategy depends on the ability to scale down as soon as those resources aren’t needed. 

Don’t think this is only something struggling companies should worry about. Even if your user base is increasing steadily, there is probably fluctuation in usage based on time of day, day of the week and season. If you’re a retailer, you expect to scale up on Black Friday… but have you thought about how you’ll scale back down?

Keep Cluster Contents Differentiated

To the extent possible, organizations should rely on managed services, whether from a cloud provider or a third-party vendor, to supply everything that doesn’t create additional value for the company. The only code that should be inside the cluster should be differentiated workloads that are unique to your organization. This approach saves engineering time during development and operations, but also gives the organization more flexibility in the types of instances to run on and ultimately keeps cloud costs down. 

Keep Workloads Stateless

As long as workloads are stateless, there’s no reason not to use spot compute instances, which can reduce costs dramatically. The biggest argument against spot instances is that they can disappear — but as long as the workload is kept stateless, this isn’t a problem. If organizations are diligent about keeping only differentiated services in the cluster and storing data elsewhere, this shouldn’t be a problem. 

Avoid Multi-Cloud

The tendency to think of Kubernetes as a tool to achieve a truly portable application, one that can move seamlessly between clouds, leads many organizations to waste both time and money. Making applications portable is very difficult — the level of skill required to succeed does exist, but in almost every case would be better used creating more value for the organization. Chasing a multicloud strategy also prevents teams from taking advantage of individual cloud providers’ managed services, leaving them responsible for installing and operating a much wider range of services, usually much less efficiently than if the cloud provider had done it. 

It’s unlikely that people will start talking about DevCostOps anytime soon, but perhaps they should. We live in a time when compute resources, at least in the cloud, are near infinite. You can always scale up — as long as you can pay for it. Now compute resources aren’t limited by the number of machines in the data center, but they are still limited by the organization’s bank account. Taking costs into account as soon as possible in the development process helps organizations get more value out of the resources they do pay for. CloudZero’s Kubernetes cost monitoring can help organizations look at kubernetes costs sooner in the development process and make better decisions about how to allocate their financial resources. 

STAY IN THE LOOP


Join thousands of engineers who already receive the best AWS and cloud cost intelligence content.