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.

by Jelle den Burger

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:

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:

• be aware of costs
• rightsizing of cloud resources
• staying in budget
• identifying undesired use of cloud resources (Tesla had unauthorized bitcoin miners in their cloud environments)
• avoiding zombie resources: Its easy to provision resource but deprovisioning can be forgotten.

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.

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.

by Wulf Schiemann

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.

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.

by Wulf Schiemann