aks kubernetes usage report

Kubernetes Chargeback (splitting the bill made easy!)

Kubernetes (K8s) has become an extremely popular technology. With that Kubernetes chargeback and cost management have become pressing challenges: A recent survey by CNCF shows that there are 5.6 million Kubernetes developers today. A 67% increase compared to 12 months ago. 31% of all backend developers now use Kubernetes. This wide adoption of Kubernetes as an orchestration technology for containers makes challenges apparent - especially in larger organizations: Automated Kubernetes billing and cost management becomes more important.

What is Kubernetes exactly?

Kubernetes - aka K8s for short - is an orchestration technology for containers. You can use it for automating deployment, scaling, and management of containers. It works declerativly in a master and worker node setup. The master node checks the status and health of the worker nodes that run the actual containers. Everything is checked against a defined desired state and K8s makes sure to make this desired state come alive and stay alive.

K8s Challenges for Cloud Governance

Cost management for Kubernetes clusters is a pressing topic for many operations departments. Enabling cloud teams to work with the latest technology like Kubernetes is an important part of leveraging the cloud. But this has cloud governance implications: Cost management, security and compliance.

When running Kubernetes in a scenario in which you share Kubernetes clusters you run into billing issues. An example would be running Azure’s Kubernetes Service (AKS) as a multi-tenant cluster. There is no standard way of knowing how to split up the bill for the resource consumption of the Kubernetes cluster.

Onboarding internal customers and giving them a way to manage their Kubernetes namespaces, quotas and access rights is another cloud governance issue you might run into.

That’s quite a lot to tackle in terms of cloud management.

So here’s a short overview:

  • Kubernetes cost management
  • Security and compliance of shared K8s clusters
  • Kubernetes namespace management
  • Quota management
  • Managing access rights

Splitting the K8s Bill with meshcloud

With the cloud foundation platform meshStack, meshcloud makes it easy to split the bill from shared K8s clusters. Many of our customers use cloud-native K8s services like Azure’s Kubernetes Service (AKS): They get one big bill from Azure every month and have not been able to fairly split the bill and charge their application teams based on actual usage. In order to do this, you can define a pricing catalog for AKS resource usage (like based on Persistent Volume Claims or the number of created Pods), that will be used to calculate a per month pricing for individual customers.

aks kubernetes usage report

meshcloud makes accurate Kubernetes metering and billing possible and much more:

  • Managing multiple projects,
  • authorizing users on projects,
  • charging the cost for projects to different teams, and
  • setting usage quotas for projects.

Application developers want to (and should) develop applications

Application teams should do what they’re good at: Develop new applications and innovate. Administrative tasks often hold them back. DevOps teams want a managed K8s service where they don't have to set up the cluster themselves. They just want to develop applications. Typically we see OpenShift used for this type of scenario - OpenShift metering and management is also fully supported by meshcloud.

With meshcloud it is possible to lessen the administrative effort even more. An Openshift or AKS cluster can be shared easily across multiple customers for more effective resource usage. Project namespaces and access will be automatically set up so your teams are able to start deploying pods within minutes.


Cloud cost dashboard build in google data studio displaying cloud billing information in tables and charts.

Open Source Cloud Cost Dashboard in under 10 Minutes

Cloud cost dashboard build in google data studio displaying cloud billing information in tables and charts.
You can build a cloud cost dashboard like this in under 10 minutes.

Three easy steps to get to your cloud cost dashboard

Everyone loves good dashboards. If done well, cloud cost dashboards can give you all the vital information that you need in a single overview. This is incredibly important with managing your cloud costs.

In this blog post, we will show you how you can build a cloud cost dashboard. See your cloud expenditure at a glance in AWS, Microsoft Azure & (soon to be) Google Cloud. The best part: it is completely free and doesn't take longer than 10 minutes. This is thanks to our open-source multi-cloud CLI Collie which we recently launched on GitHub. To get to your cloud cost dashboard, we will follow along with these steps:

  • Step 1: Preparing cloud cost data with metadata using tags
  • Step 2: Extracting the data from the clouds
  • Step 3: Building a cloud cost dashboard

At the end of this guide, you will have a cloud cost dashboard that looks something like this.

To follow along with this blog post, you need a license for Google Data Studio. It should be included for free in G-Suite. You could also use another dashboard tool such as Microsoft PowerBI. As long as it supports CSV files as data import.

Step 1: Preparing cloud cost data with metadata using tags

Your cloud cost dashboard is only as good as the data it is built upon. That's why the first and most important step is to prepare the necessary cost data with the right metadata. Without proper metadata, it is going to be difficult to filter and view information from certain angles. One vital part of building good cost data from the public cloud providers is the use of tags. The more tags you use, the more questions you can answer for yourself or your management:

  • Which team (or department) is spending the most in the cloud?
  • Which cost center is spending the most in the cloud?
  • Which cloud platform has the highest usage?
  • How much are we spending on development stages?
  • How is the expenditure of cloud-native projects vs. lift-and-shift projects?
  • Whom do I need to contact for more information about this project?

Step 2: Extracting the data from the clouds

Once you are happy with the metadata you applied to your projects, it is time to export the cost data. This allows it to be imported into your cloud cost dashboard later on. To make the export as easy as possible, we will use our recently launched Collie CLI. Collie can export all cost data with one single command in a CSV file. We will then prepare this CSV file using Google Sheets so it can be used as a data source for the dashboard.

To do this export with Collie we need to execute the following steps:

  1. Before installing: make sure you have properly set up the CLIs of the cloud platforms.
  2. Install Collie as explained here.
  3. Run the cost export command for a given time interval. Make sure to use whole months as the cost data is on a monthly basis. The following command would work for Q1 & Q2 of 2021:

collie tenant costs --from 2021-01-01 --to 2021-06-30 -o csv > q1_q2_2021_export.csv

  1. You should now have a CSV export with the cost data of your cloud(s). The metadata tags are provided as extra columns, which is important for when we build your cloud cost dashboard.

Next up, we will import the CSV data into a Google Sheets spreadsheet. Follow these steps:

  1. Create a new Google Sheet (hint: navigate to https://sheet.new/).
  2. At the menu at the top, open "File" and click "Import". Navigate to the "Upload" tab in the dialog and upload the CSV file from before in this dialog.
  3. Make sure to untick the checkbox that says "Convert text to numbers, dates, and formulas". Confirm the import by clicking "Import Data".
  4. Open the new spreadsheet by clicking "Open now". Make sure to name this new spreadsheet something that you can remember later.

That's it! We now have a well-prepared spreadsheet that we will use to power your new cloud cost dashboard.

Step 3: Building your cloud cost dashboard!

Okay, the data is ready! We can start building your cloud cost dashboard now. To make things easier, we have already prepared a template for you. You can find it here. Let's link it to the data source that we set up before. Follow along the next steps to do so:

  1. Open the dashboard link mentioned above and make a copy of the dashboard. To do so, click the settings icon and click "Make a copy" as shown in the screenshot below.

Google Data Studio screenshot showing how to make a copy.

  1. Data Studio will now ask you to enter a new data source. We will use the Google Sheet from before. To do so, click the dropdown below 'New Datasource' and click 'Create new data source'.
  2. Select the connector called 'Google Spreadsheets' and a new window should pop up that allows you to search for Google Sheets in your Google Drive. Try to find the one you created before and confirm the connection by clicking the blue 'Connect' button at the top right.
  3. Before creating this new data source, we need to clean up our data types a tiny bit. In the menu that just opened in front of you, scroll to the 'from' dimension and change its type from 'Date & Time' to 'Date & Time → Year Month'.
  4. Confirm the creation of the data source. Click the "Add to Report" button at the top right.
  5. At last, copy over your new report by clicking "Copy report".

That's it! You're looking at your new cloud cost dashboard. The cloud cost dashboard template we created offers various features:

  • Viewing total costs on a monthly basis
  • Viewing costs per cloud platform
  • Filtering on dates
  • Viewing costs across various tags, in our case:
    The owner (who owns this cloud account)
    Cost Center (a way of allocating costs to budgets)
    Environments (development, production, etc)
    Zone (is it a cloud-native or lift-and-shift project)
    Departments (which unit owns the project)
  • Viewing tenants (and their metadata) with the highest cost.

There is a good chance that you have different metadata than what we used in the dashboard template, which might break one or more charts. We recommend tweaking your cloud cost dashboard to your needs, but we hope that this template helps you off to a great start 🚀

Get Started with your own Cloud Cost Dashboard!

Now that you have reached the end of this post, you see that it doesn't have to be rocket science to build a powerful cloud cost dashboard. Leverage the power of our open-source Collie CLI and you have the necessary cost data extracted within minutes. Duplicate our Google Data Studio Dashboard, connect it to the CSV export and you're done!

What questions are you going to answer with your new cloud cost dashboard? Let us know in the comments below!

What's next?

Collecting costs isn't the only thing that Collie can do 😉 Curious what else Collie CLI can do for you? Head over to our meshcloud GitHub page and find out!

OR

Want to move your cloud financials to the next level? Head over to our cost management solution and learn how we can help you!


Collie open-source CLI for Cloud Governance

Launching Collie – Your Open-Source CLI for Cloud Governance

If you've been in touch with meshcloud, you'll know that we love sheep. And that's because clouds and sheep have a lot in common:

  • They love to be free, rather than locked in a barn
  • They love to be together, rather than wandering alone
  • And they need a shepherd, to protect them from lurking dangers

With Collie, we're launching an open-source CLI tool that helps you as an enterprise architect or platform engineer to assume your shepherd responsibilities, giving you the control to steer your flock towards the next pasture.
Collie open-source CLI for Cloud Governance

More specifically, Collie enables you to:

  • View all cloud tenants in one single overview - View your AWS Accounts, Azure Subscriptions, and Google Cloud Projects with their metadata with only one command.
  • View billing information across all clouds - See what you spend per day, month, or week in all cloud platforms, including the right metadata. Includes support for CSV, YML and JSON.
  • Analyze tag inconsistencies - See at a glance what tags are used, by which tenants (and which not), and what potential inconsistencies are in place to fix any governance issues.
  • Track your cloud history - Collie CLI is built on the principles of GitOps and its data can easily be written to git repositories for tracking changes in your cloud environments.

The development is based on our in-depth experience with meshStack: Our multi-cloud governance platform for the enterprise. It provides you with an easy and lightweight entry to cloud governance.

Let's have a look into Collie and how it empowers you to manage your multi-cloud landscape!

Is your Cloud Landscape a Mess?

Did you ever get the feeling that you are losing track of what is happening in your cloud landscape? You have multiple environments (AWS accounts, Azure Subscriptions, or GCP projects) running across different clouds. They started as playgrounds and now more and more serious stuff is running in there, making it harder to keep track every day.

Your sheep are basically wandering off from the flock.

No matter which cloud you use: AWS, Azure, or GCP, they all provide capabilities on the org-level to see what cloud environments are running in there, and what costs they cause.

What is missing though is a comprehensive overview. It's all hidden behind different screens and settings, across multiple cloud consoles or CLIs, not allowing you to get that single picture you're looking for.

Cloud Transparency is Key!

For a proper overview, you would need to have different types of information, consolidated in a single view. It could be fairly easy, all you need are answers to these questions:

  • Which cloud environments do exist in my multi-cloud landscape?
  • Who do these cloud environments belong to?
  • What costs do these cloud environments cause?
  • Are they consistently tagged and documented?

Having this information at hand, enables you to bring things into order (= Cloud Governance) and herd your sheep.

Collie – Open-Source Multi-Cloud CLI Tool

This has never been as easy. All you need, is to have the native cloud CLI tools installed on your machine. From there it's just a couple of commands to shed light into the dark.

See for yourself:
Collie CLI Demo

If you are wondering how to use that information, here are some common use cases that people implement with Collie.

1) You want to delete cloud environments that aren't used anymore to reduce complexity.

2) You want to implement a consistent tagging strategy and need to know which cloud environments are still missing

3) You want to make sure that there are no idle environments (Sandboxes, etc.) raising your cloud bills every month

4) You want to implement a consistent tagging strategy and need to know which tags are currently used within your cloud environments

5) You want to map cloud environments to IT products, applications or cost centers within your organization

6) You want to analyze cloud costs based on their tags to build multi-cloud cost reports with nice dashboarding tools like PowerBI or Google Data Studio

How to get started with Collie

If you're looking for full transparency on your growing cloud landscape, Collie is just right for you.
Collie is open-source and available on GitHub. You only need to have the native cloud CLIs installed on your machine and are ready to go.

We hope you find it useful. Please reach out with any contributions, feedback, ideas or requests for help.

We're looking forward to herding our clouds together.


business credit card

Saving Cloud Costs: 3 Proven Strategies

Learn how to cut down cloud costs on a strategic level. Deleting unused instances is fine, but here are 3 organizational-level strategies to start saving cloud costs.

From our customers - large multi-cloud enterprises - we learned the top 3 strategies to save on cloud costs:

  1. They predict and commit to cloud usage to save cloud costs.
  2. They use multiple cloud platforms to leverage the competitiveness of the cloud market in negotiations
  3. They use Enterprise Contracts to crack down on cloud spending

If you are an executive or manager responsible for cloud cost management at your business this blog post is for you.

Let’s kick things off with strategy #1

1. Commit to cloud usage to save cloud costs

Why cloud consumption prediction results in discounts

You are familiar with cloud computing and have heard of something called reserved instances:

You, the customer, promise the vendor that you will use a certain service for a given amount of time. Let's say a small virtual machine for an entire year.

The cloud provider is thrilled! Your commitment helps them predict the demand for cloud computing for the upcoming year.

In return for this prediction, you receive a discount from the cloud provider and can save cloud costs.

Predicting cloud consumption is a win-win for both you and the cloud provider.

Commiting to cloud usage on an organizational level

This same concept applies on an organizational level:

If an enterprise knows they will spend ~1 million euros a month on cloud computing, the provider is much better aware of what demand is coming. This also results in a significant discount.

The risk of such a commitment is that your organization will pay that amount of money - regardless of what the actual consumption is in the end.

The more accurate your cloud consumption prediction is as an organization, the more costs you will save. Anything below the ~1 million euros can be considered "wasted", and anything above that is charged with a (usually higher) on-demand fee.

2. Go multi-cloud to apply negotiation pressure

Be aware that the cloud providers want you!

Even though cloud computing is a new development, cloud providers know they will keep your business for years. This is why they're eager to onboard you on their cloud platform.

Once your business-critical applications are on their cloud, they know it is very tough to reverse that decision and they have locked you into their platform.

Show you (can) run on multiple clouds

By showing that you are capable of running your cloud business on one of the other platforms you strengthen your position as a potential client. Let them know you can move your business-critical applications to one of the competitors. They will include even more benefits or discounts to get you to sign as a client. By adopting a multi-cloud strategy, you show that you do not need that particular cloud provider and that you can switch to one of the others if needed.

3. Get Started with Enterprise Contracts

What is an enterprise contract and why do I need one?

When starting with one of the clouds, it will be straightforward to get going and book your first services. While doing so, you will pay the so-called on-demand fee.

When trying out a cloud platform and evaluating whether you want to build here, the on-demand fee is a great option. Not so great when you want to take it to the next level.

When building or migrating business-critical applications you will most likely need an enterprise contract with the provider.

An enterprise contract gives you the possibility for a volume discount and opens the door for negotiations. They are also easier to process for your financial department.

We will provide concrete steps you can take for the "big three": Microsoft Azure, Amazon Web Services, and Google Cloud.

Azure Enterprise Agreement

It is possible to create an Enterprise Agreement (EA) with Microsoft for the sole purpose of using Azure. But you most likely already have an EA in place for other services such as Windows or Office.

If this is the case, add Azure to the existing EA by making an upfront monetary commitment for a minimum three-year period.

This monetary commitment is quite low: it starts at $100 per month.

Be aware though as this is intentional. Microsoft knows that once your enterprise is on their cloud platform, they have their foot in the door and you're likely to grow a lot more from there.

The EA offers built-in savings ranging from 15 percent to 45 percent, based on the committed spend. The more you buy - the better the discount.

Lastly, be aware that there is a minimum user requirement for Azure. You will need at least 500 or more users committed to using the EA. The only exception is the public sector, which has a requirement of 250 users.

If you want, you can also talk directly with an Azure Sales representative here.

AWS: Enterprise Discount Program

AWS does not state it anywhere, but when searching for it online, you will find it: The AWS Enterprise Discount Program (EDP). This is the enterprise contract of AWS that allows you to get volume discounts by doing annual prepayment commitments.

As an EDP comes with an NDA, there is no information known on what the smallest size is nor the estimated discount you can receive with it.

But it is always better to use than paying the on-demand fee, especially if you're an enterprise that (plans to) operate at a large scale. You can get started by contacting AWS sales.

Google Cloud: contact sales

As of writing, Google does not advertise for an enterprise contract. There is also no information online to be found on them having some kind of enterprise contract and discount program.

Yet, there is a good chance that you're able to have an enterprise contract with them anyway.

The best thing you can do is get in contact with their sales team and discuss potential options.

Conclusion

There is no need to pay for the regular on-demand pricing that cloud providers offer. There are multiple levers you can pull to improve your enterprise's negotiation position. Do this by either committing to scale and receiving a "scale discount" using one of the enterprise agreements and/or adapting to a multi-cloud strategy. The cloud market is highly competitive and cloud providers would love to do business with you: Use this to your advantage.


Cloud Cost Management

The 2021 Guide to Multi-Cloud Billing and Cost Management

This is a comprehensive guide to multi-cloud billing and cost management.

If you work as a CIO, CFO, in IT financial management, as a Cloud Architect, in DevOps or you are just interested in cloud billing and cost management, this guide is for you.

We'll look at how to establish an automated end-to-end cost management process as part of an organization's cloud governance.

In this new guide you will learn:

  • What cloud cost management is
  • Why cloud cost management is becoming more important
  • What strategies you can use to manage cloud cost
  • The ins and outs of chargeback and showback
  • About the challenges of cloud metering and pay-per-use in the private cloud
  • What to expect and where to go on your cost management journey

Let's get started with the basics:

What Is Cloud Cost Management?

The cloud promises a simple, cost-effective, highly scalable alternative to running your own servers in a data center. But as cloud infrastructure becomes more complex - a lot of companies use multi-cloud architectures - the costs associated become difficult to track and evaluate:

Cloud cost management or cloud cost optimization is the effort to gain valuable insights into the costs of cloud usage within the enterprise and finding effective ways to maximize cloud usage and efficiency.

Multi-Cloud Cost: 4 Expensive Factors That Are Easy To Miss

Without proper cloud cost management in place, things can get out of hand and more expensive than they need to be.

Here are 4 factors that drive cloud cost and are easily overlooked:

  1. Un- or underused cloud resources

    Provisioning cloud resources may be difficult or not in your organization - but de-provisioning is forgotten easily. With the public clouds, pay-per-use model costs can spiral out of control.

  2. Third-party cloud services

    The usage of complementary cloud services like cloud monitoring or backend connectivity is necessary for DevOps teams. The cost of these services is often not attributed or monitored closely enough to detect the potential for significant savings.

  3. Provisioning and organizational support

    For developers, it's not always easy to get the cloud environments they need for their projects. Manual processes for approving and provisioning their requests are time-consuming and costly.

  4. Projects exceeding budget

    Budgeting cloud projects is common; Without the right cost management, it might not be possible to get an early warning on projects that might run out of budget. Shutting down cloud resources on a project because it's exceeding budget is no option and so it drives cloud costs up.

Why Cloud Cost Management is so Important

Cloud usage is an ever-increasing factor in most enterprises. The advantages seem clear - and they are - but the organization needs to adapt to and keep up with these advantages: Rapid scalability, pay-per-use, automation, overall agility - all this needs proper cloud governance to come into effect without exploding costs.

DevOps teams consuming cloud resources like they are free. Multi-cloud architectures that add extra complexity, and private cloud components that don't follow the pay-per-use model make effective cloud cost management an absolute necessity.

At the beginning of an organization's cloud transformation, the topic might not seem as pressing - but that's actually the right time to lay the organizational and technical foundation for cost-effective growth to avoid costly surprises further down the road.

Is Cloud Cost Management an Issue for Businesses?

A recent survey revealed that cutting cloud costs is the top priority for companies' cloud strategy. They face growing invoices from their cloud service providers and the lack of insight into those costs has considerable financial consequences. Most companies expected their cloud budget to increase by 10 to 25 percent in 2020 while considering the applications they deploy to the cloud as "mission-critical". That makes it critical for business success to put the budget increase to good use and not waste it on hidden and avoidable costs in their cloud organization.

Why a lot of Companies are Struggeling with Cloud Costs

Not utilizing the advantages of the cloud means real competitive disadvantages and poses a risk to business success - that's for sure. But going on that journey to the cloud, transforming the organization, and moving workload out of data centers is not an easy task and must not be rushed.

Some companies ran for the cloud and with time came the shocking suprise of mounting costs.

Here are some reasons for that (and for you to avoid):

  • No proper cloud governance
  • Not adopting the cloud-native mindset
  • Overlooking the risks of the pay-per-use model
  • Poor visibility of cloud costs (build a cloud cost dashboard)

6 Levers to Pull to Reduce Cloud Costs

There are a number of levers businesses can pull on to manage cloud costs.

Here are 6 of the most promising:

  1. Right-sizing:

    Ensure that the public cloud instances you choose are the right fit for your organization’s needs.

  2. Automatic scaling:

    This allows organizations to scale up resources when needed and scale
    down the rest of the time, rather than planning for maximum utilization at all times (which can be needlessly expensive).

  3. Reserved Instances:

    Reserved Instances offer a significant discount over on-demand instance pricing (for example, up to 72% on AWS). To make full use of them you have to know what you actually need.

  4. Power scheduling:

    Not all instances need to be used 24/7. Scheduling non-essential instances to shut down overnight or on weekends is more cost-effective than keeping them running constantly.

  5. Removing unused instances:

    If you’re not using an instance, there’s no need to keep it around (and paying for it!). Removing unused instances is also important for security since unused resources can create vulnerabilities.

  6. Discount instances:

    Since discount instances usually do not guarantee availability, they’re not
    appropriate for business-critical workloads that must run constantly but for occasional use, they can result in a significant cost reduction.

The most effective lever is the organizational transformation to fit the requirements of the cloud: We'll get to the why and how later in this guide.

Multi-Cloud Billing: Showback vs. Chargeback

Strategic considerations aside showback and chargeback are pretty similar on an operational level. They share the same structure - but of course, there are essential differences:

  • The showback approach does not contain bills or invoices that need to be paid. IT reports costs and usage, while also paying for the cloud service provider invoices, services, and so on. There is no charging of the actual source of these costs. A DevOps team won't be charged for a VM or a third-party cloud service it uses.
  • In the chargeback approach, each consumer of cloud resources and services is actually billed for what they used. That can mean that money flows from one department to another within a company or just an entry in accounting charging the consuming department.

The Strategic Differences of Showback and Chargeback Models

On a strategic level, showback and chargeback are quite different. The question here is why should you use one over the other? What implications does that have on usage behavior and accountability?

Showback does not have any enforcement mechanisms to guide usage behavior. It is basically providing cloud cost transparency and visibility - which is great and useful - without encouraging users to pay attention and be proactive about the costs they produce.

In a chargeback, model users are incentivized to consider the cost of the cloud resources they request and use.

The Pros and Cons of Showback vs. Chargeback

On a scale of detail required, effort and cost showback requires less and is easier and faster to execute.

For a chargeback model more detail and effort are required and therefore it can be more expensive.

Both models expose levers to reduce cloud costs and optimize usage. They are both fit to demonstrate the value that the cloud brings to the business.

Chargeback offers total accountability and allows IT to recover costs across all DevOps teams and departments that use IT services.

Metering in the Private Cloud

The private cloud needs a little extra treatment when it comes to cloud billing and cost management. There is no large bill at the end of the month that lists the cloud costs on a pay-per-use basis. To get that you have to make or buy a metering implementation that does this for you.

Metering is the process of collecting and calculating cloud resource usage. It involves pricing resource usage to calculate the cost.

Cloud platforms record events and other information about deployed cloud resources. Some of these events are relevant for metering. For example, starting and stopping a virtual machine may
generate a corresponding stream of events that describes for how long the virtual machine was running. This data from the cloud platform can be used to calculate how much RAM-hours and vCPU-hours a virtual machine consumed in a given period.

Cloud resources have many different traits like a virtual machine has RAM and vCPU. In the public cloud, it is common to provide t-shirt sizes for cloud resources. You can build the same for the private cloud and offer VMs in S, M and L instead of giving exact quantities for RAM or vCPU.
A product catalog defines which of these traits are relevant for metering and how their usage is calculated. Typically usage is the product of a quantity and a duration, i.e. a single vCPU used for an hour. But there may be other usage units as well that consist only of quantities (i.e. bytes transferred over the network) or a duration (i.e. resource usage hour).

A product catalog also contains pricing rules that determine the cost for particular resource usage.

This way private cloud usage can be accounted for in a pay-per-use model like it is common with the large public cloud providers.

Cloud Billing and Cost Management Maturity Model

At meshcloud, we came up with a six-stage maturity model for cloud billing and cost management. We see these stages when we look at where our customers are on their cloud journey - but not necessarily in that order:
The six stages of cloud billing and cost management maturity:  Private cloud metering, One large bill per cloud provider, Per project cloud consumption, Tenant fee for cloud governance, Charge for cloud services and Cooperation and cost allocation with external partners

  1. Private cloud metering

    The private cloud does not come with a pay-per-use-based invoice at the end of the month like it is standard with the public cloud providers. A private cloud metering has to be built and implemented to get to the pay-by-consumption model.

  2. One large bill per cloud provider

    Every month or quarterly there will be one large bill for all cloud services that are used across the organization. There is no way of getting around that - a black box.

  3. Per project cloud consumption

    Allocating cost to the consumption in each project is a big leap for cost transparency and visibility. Projects exceeding their budget can be identified early on and adjusted accordingly.

  4. Tenant fee for cloud governance

    A cloud foundation team or a cloud center of excellence takes care of cloud governance: Security and IAM are centralized and the team aims to deliver a good user experience for the DevOps teams. They can focus on their actual work and pay a tenant fee for the services of the cloud foundation team.

  5. Charge for cloud services

    Since not only cloud-native services are used in development and operations additional cloud services (monitoring, CI/CD tooling, connectivity) are provided by the cloud foundation team and other DevOps teams that can then charge for them.

  6. Cooperation and cost allocation with external partners

    The internal transformation into a service organization with full chargeback makes it possible to offer the same services to external partners. This is the peak of the cloud billing mountain everybody strives to climb.

The 7 Steps to Multi-Cloud Cost Management Perfection

Let's take our maturity model and see how to get from where you are now in terms of cloud billing and cost management to where you would like to be.

We have 6 stages in our model, but we'll start with step #0 to get the very basics covered:

Step #0 - Laying the Foundation for Cloud Billing and Cost Management

This step is all about making the right choices and laying the foundation. It has nothing to do with cloud billing and cost management directly.

There are two things you need to consider:

  1. Account structure: Projects, folders, subscriptions, resource groups, accounts - all these entities you are confronted with in the cloud need to be mapped to your organizational structure with teams, departments, and products. For example map an IT product (organizational construct) to a customer and an application stage like dev, QA, or production to a tenant (Azure subscription, AWS account, or GCP Project).

    At meshcloud the meshProject is central to assigned project users and team leads, cloud tenants with landing zones, the service marketplace and approved budget and chargeback

  2. Metadata and Tagging - Tags or labels are custom to every organization. Common tags are data classification, cost center, and environment. Defining a tagging schema helps with scaling and automating cloud usage. Resource tags and labels can be used to control and analyze costs.

Step #1 - Splitting up the Cloud Bill

This step is about getting from one big bill to allocated per project costs.

Central to this step is proper showback to increase transparency and visibility for cloud costs.

Why is that important?

For DevOps teams:

For central IT:

  • negotiating better contract conditions with cloud providers
  • defining service portfolio and seeing if certain cloud services drive costs to find alternatives
  • taking cost optimisation steps

meshcloud offers usage reports on the projects with according costs to increase transparency. For example meshcloud makes it easy to split the bill from shared Kubernetes clusters.

Step #2 - Charging the Right People

After raising awareness with proper showback, chargeback is the next logical step.

The large bill that goes to central IT is something you can't avoid. In a worst-case scenario, it is allocated manually to teams and projects: A model that is not sustainable.

Automation is key when it comes to allocating cloud costs:

Aggregate cost per customer → create monthly chargeback statements per project → provide detailed tenant usage reports per platform. This can then be exported to SAP or other tools. The tags and labels from step #0 come into play here. Without them, automation is not possible.

Step #3 - Staying within Budgets

This step is about keeping projects in budget by mapping budgets to projects.

For that, you need an end-to-end integration: A project is created and approved with a budget before a single cloud resource is used. As cloud resource consumption can vary greatly over the lifecycle of a project it is not easy to plan a budget that fits exactly and keep it in check.

A common setup we see is a DevOps team lead requests a cloud account and the cost center manager and central IT approve. The estimated budget for the project is mapped to the project as it is created. The resources are tagged and tracked as the team works on the project and consumes cloud resources.

All stages of the product - e.g. development, staging, and production - have to share the overall budget for the project. Since you can't cut off a project when the budget is exceeded you need to implement processes that regulate the costs beforehand.

Excursion: Multi-Cloud Organization Done Right

To utilize the cloud to the fullest enterprises have to transform their internal organization to fit the new cloud-native approach. What we at meshcloud see most with our customers is a transformation from a silo-like organization to a centralized cloud foundation team or cloud center of excellence that takes care of cloud or multi-cloud governance.
Visualization of a modern multi-cloud governance. Centralized in a cloud foundation team providing DevOps with good user experience, cloud environments, landing zones and so on.
They integrate platforms, define landing zones, organize provisioning, ensure continuous compliance and provide cross-cloud transparency. All this is centralized in a tool and highly automated. Manual processes are not scalable when DevOps grows. Self-service is implemented to decouple DevOps from cloud governance and the cloud foundation team. That accelerates time-to-cloud for DevOps and time to market for the business.

Step #4 - Cloud Governance to Boost Development

Traditionally DevOps teams have a lot of non-functional things to take care of (compliance, security, general organization, and governance) if not provided by a cloud foundation team. The cloud foundation team should take care of all of that and it can charge for the value it provides with what we call a tenant fee.

This model transforms the cloud foundation team from a cost to a profit center because they charge internally and there is a detailed cost allocation.

Step #5 - The Service Organization

Cloud-native resources from the cloud service providers need to be complemented by other building blocks like backend connectivity, CI/CD-tooling, or multi-cloud monitoring. These cloud services can be provided by the cloud foundation team, other DevOps teams, or by third parties as managed services.

To integrate these services you need cloud-native provisioning (self-service on-demand) and cloud-native billing (pay-per-use) to not destroy the advantages provided by the cloud. The goal is to avoid manual processes.

A service marketplace is a solution to keep the cloud-native processes and bring service owners and cloud users together. Provisioning of cloud services can be done with a service marketplace with plans and pricing as a basic setup to keep track of usage and costs. The service marketplace can also include third-party cloud services like datadog or a managed MongoDB.

A system like this incentivizes teams to provide services for others as well as paying attention to their own consumption.

The goal here is: No emails, no phone calls but a fully automated provisioning with costs showing up on the monthly chargeback statement that also contains the cloud costs.

Step #6 - Running IT Like a Business

This is the last step to fully integrated end-to-end cloud billing and cost management. With the service economy set up internally, it is now possible to offer and purchase cloud services to and from external organizations like start-ups or cooperation partners.

The service economy built in this step is based on the foundations you lay in step #0 to get proper isolation, be compliant with regulatory and internal rules.

With a cloud ecosystem like this, you have everything you need to boosts business success in the cloud-native way!


To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to get in touch with you.


Sticky notes on a whiteboard symbolizing a tagging strategy workshop.

Your Path to a Winning Multi-Cloud Tagging Strategy

This is an introduction to cloud resource tagging and labeling: If you are concerned with building a cloud architecture, then this blog post is for you! Tagging and labeling is an early stage topic of your cloud journey. It forms the foundation of organized and structured growth.

In this post we will cover:

  • Why tagging is an integral part of every cloud journey
  • 5 steps to a winning cloud tagging strategy
  • Common use cases of cloud resource tagging
  • How to stay consistent across multiple platforms
  • How meshcloud takes tagging to the next level

What are Cloud Resource Tags?

A tag is a label assigned to a cloud resource to apply custom metadata. Anything is taggable - from the cloud tenant on the top level to resource groups to single resources like virtual machines and databases.

Tags come as key value pairs:

The key describes the kind of tag that is then further specified by its value. For example, the key could be environment and the values could be development, staging, or production.

There are two different kinds of tags: The ones that are automatically generated by the cloud service provider - e.g. instance or subnet IDs - and user-defined tags.

For this post, we'll focus on the user-defined tags since they enable us to freely enrich our cloud resources with the information we consider relevant.

Why a tagging strategy is an absolute must-have

One central advantage of using the cloud is rapid scalability. And with this comes the necessity to keep track of what is going on in your cloud infrastructure while it is constantly growing and changing. That's where tags come in: You will need a consistent set of tags to apply globally across all of your resources following a consistent set of rules. Tagging is the cornerstone to effective cloud governance: Cost allocation, reporting, chargeback and showback, cost optimization, compliance, and security - all these aspects can only be managed with proper tagging in place.

For example, you can build a cloud cost dashboard in under 10 minutes.

Everything can be put into this mnemonic: Tag early, tag often.

Five steps to a winning tag management strategy

Tagging early and tagging often requires a tag management strategy that streamlines tagging practices across all teams, platforms, and resources.

The cloud governance team - or cloud foundation team - should take the lead in defining your global tagging strategy.

Here are 5 steps to get you started:

  1. Bring the stakeholders together

    Get everyone involved in the process who will be using tags or might have something to contribute to the integration of the strategy in the overall company processes. Of course, these are DevOps representatives, but also non-technical roles from accounting or marketing or any other group using cloud resources. Meet as a group to get the full picture, hear everybody's concerns, avoid misunderstandings and save yourself the trouble of making changes later. If your organization already uses tags, start with auditing what is there.

  2. Understand the purpose

    It is important to have a common understanding of what problems cloud resource tagging is supposed to solve. Define these questions early on in the process - here are some examples of what they could be:

    Which business unit within the organization should this cost be charged to?

    Which cost centers are driving my costs up or down?

    How much does it cost to operate a product that I’m responsible for?

    Are there unused resources in my dev/test environment?

  3. Focus and keep it simple

    You will not be able to set up an all-encompassing tagging strategy that will be valid for eternity. So don't make that your objective - keep it simple and set your focus. To get started, choose a small set of required tags you will need in the short term and build on them
    as needed. Choose three to five pressing areas you want to understand. For example, focus on cost reporting and align these tags with internal reporting requirements. Aim for an intuitive system to build on - more layers and granularity can be added further down the road.

  4. Define the naming convention

    You will need to decide on a naming convention for your tagging system. This is the backbone of everything you're trying to accomplish with your tagging strategy and must be enforced globally. If your company uses multiple cloud platforms or is planning on doing so, take into account that the platforms have different requirements for character count, allowed characters, case-sensitivity, and so on. You can consult our tags and labels cheat sheet to help you with that.

  5. Document everything and make it count

    Make sure to document everything you agree upon in this cross-sectional team working on the tagging strategy. This documentation should cover the naming convention, the policies when to use which tags, and the reasoning behind these decisions.

An organization-wide tagging strategy should make sure that tagging stays consistent on a global level. But take into account that individual teams or applications may add additional tags for their specific needs as well.

Common Use Cases for Cloud Resource Tagging

We've been talking about how tagging is essential and coming up with a tagging strategy should be an early stage step in setting up your cloud governance.

Here are the most common use cases to show you why:

  1. Cloud Cost Management

    Gain transparency when it comes to cloud usage and costs: Tagging cost centers, business units, and specific purposes help you keep track.

  2. Cloud Access Management

    Proper tagging enables administrators to control the access of users or user groups to resources or services.

  3. Cloud Security Management

    Tags are essential to identify sensitive resources and keeping them secure. For example, tagging the confidentiality classification helps to find the S3 bucket that's public and definitely shouldn't be or prevent that from happening in the first place (we'll come to that later).

  4. Automation

    The added metadata of tags enable a whole new level of automation: Many different automation tools can read these tags and utilize them to make your life easier in almost every regard concerning the previously mentioned use cases.

Challenges of Tagging in Multi-Cloud Architectures

Most companies use multiple cloud platforms and - in one way or another - struggle with the governance of their cloud architecture. Tags are here to help! BUT there are a few caveats that you need to be aware of to actually make things better.

Each cloud platform has its own tagging constraints - Google doesn't even call them tags but labels.

These questions will come up:

  • How many tags per resource are possible?
  • How many characters per tag and which characters are not allowed?
  • Is there a difference in requirements for keys and values?
  • What exceptions are there?

To help you with that we've created our Cheat Sheet for Tags and Labels on Cloud Platforms. There you can look up the differences in Azure, AWS, and GCP tagging and labeling.

Consistency in the usage and naming of tags becomes even more important when working in a multi-cloud architecture. It is extremely critical if you want to do queries based on tags - inconsistencies and typos can ruin the whole point of what you were trying to achieve.

Making the Most of Tagging with meshcloud

Now that we've covered what tags are, what they are good for and how to create a tagging strategy to drastically expand the possibilities for cloud governance, we'll talk about how meshcloud takes this to a whole new level:

With meshcloud cloud governance or cloud foundation, teams can define tags globally in one single place. This is incredibly helpful in keeping tags consistent across all platforms, teams, and resources.

meshcloud enables you to set and enforce tag formats, patterns, and constraints globally and make them work with all cloud platforms. With meshcloud, you define your tags as JSON and these can be entered in the UI either by employees themselves, or only administrators.

A code example that shows tag definition in meshcloud.
Tag definition example, in this case for classifying the environment of a project.

UI showing tags previously defined as JSON
The JSON you define will render into UI for your users

meshcloud enables cloud foundations teams to enforce possible tag values to a very granular level. You'll never have to worry if team members make typos or use different values for your tags. It is even possible to enforce the format of values using RegEx. For example, if your cost centers look like ACME-12345, you can enforce this format globally for all clouds.

And, remember when we discussed tag constraints on cloud platforms? We got you covered here. If a tag value is not valid in a cloud platform, meshcloud automatically converts this value to a valid value inside of the cloud. For example, GCP would not allow www.meshcloud.io as a value. It will automatically be converted to www_meshcloud_io, which is a valid GCP value.

Implementing your global tagging strategy across all clouds is not the only value meshcloud has to offer. With our policies we enable our customers to set and enforce rules based on tags across all platforms, teams, projects, and landing zones. This gives cloud foundation teams even more control over who has access to what. For example, you could enforce a certain Azure blueprint to be only used for production projects. Or you enforce that teams can only create projects for the environment they have been approved for. This makes sure that teams will not create production projects without being approved first.

Authors: Wulf Schiemann and Jelle den Burger


To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to get in touch with you.