What is a Cloud Management Platform?
A school cafeteria has to know who is allowed to take what, and which account it bills to. Some students take the set meal off the serving line, some bring lunch from home and buy a drink, some order at the a la carte counter, and the register has to sort prepaid cards from guest vouchers from the free lunch program. Infrastructure requests in a large enterprise raise the same questions, at a volume where nobody can answer them by hand.
A cloud management platform (CMP) is a governance and orchestration layer that sits above infrastructure-as-code tools and native cloud consoles. It coordinates approvals, policy, cost controls, ITSM, IPAM, DNS, CMDB, and lifecycle operations across hybrid and multi-cloud estates.
From there, a CMP can orchestrate several execution methods within governed workflows, including Terraform and Ansible, without requiring either one.
Platform teams encounter the operational gap when a production request must cross budget approval, IPAM, DNS, CMDB, and lifecycle controls before and after provisioning. A CMP coordinates that path while each underlying tool keeps its existing role.
What a cloud management platform is
A cloud management platform orchestrates the tools you already own and weaves higher-order processes through them. Those processes cover approval chains and ITSM registration, IPAM and DNS actions, CMDB entries, cost controls, and lifecycle management from request through decommissioning. Gartner’s 2022 Market Guide for Cloud Management Tooling covers the same ground, describing tooling that provides “governance, life cycle management, brokering and automation” for hybrid and multicloud resources.
CloudBolt CMP models the request in six stages: request, govern and approve, orchestrate, provision, configure, and close the loop. Budget checks, compliance policies, and approvals execute inside that path, so a request that reaches Terraform has already passed them.
Where Terraform and Ansible stop
Most teams already run Terraform, Ansible, or both, so that is where the coordination gap first becomes visible. Start with what those tools claim for themselves. HashiCorp’s Terraform documentation states that “Terraform is not a configuration management tool.” Its provisioner documentation also recommends “purpose-built solutions to perform post-apply operations.” Terraform’s role is provisioning infrastructure, while Ansible’s is configuration. Ansible can also handle provisioning in limited cases. The key difference is that Ansible holds no state: when a user asked about drift detection, an Ansible maintainer explained that Ansible uses target resources as its current source of truth.
Neither Terraform CLI nor Ansible Core natively coordinates enterprise governance. When a user asked for permission enforcement in Terraform, a core maintainer answered that “architecturally this sort of permissions enforcement is outside of Terraform CLI’s intended scope and instead we delegate it to other software which wraps Terraform.”
Neither tool provides the full enterprise self-service path on its own, since each one only automates within its own domain and does not reach into the other’s operations or beyond them. A developer requesting a production service needs more than a plan and an apply: an approval matched to cost, a CMDB record, an IP allocation, a DNS entry, required tags, a budget check, and an eventual decommission date. Terraform CLI and Ansible Core do not natively coordinate this end-to-end path.
Organizations that hit this ceiling build the missing layer by hand. DoorDash layered Atlantis over Terraform. It used OPA/Conftest for policy and Pull Approve for approvals, raising resource-tagging coverage from 20% to 97.9% (InfoQ, 2023). Coinbase built an approval bot, Heimdall, because “no single system in our ecosystem should be able to tear everything down” (QCon San Francisco 2018, via InfoQ). The IaC you wrote is necessary and does a specific job. A higher-order coordination job sits outside the native scope of Terraform CLI and Ansible Core, and that job is the CMP category.
If you want to test that claim against your own toolchain, CloudBolt CMP is free for up to 100 resources.
Governance requirements in hybrid estates
Inherited hybrid estates tend to follow a familiar pattern, and the details compound quietly before anyone notices how serious they’ve become. Staging and production drift apart in ways nobody can reconstruct from the load-bearing runbooks, the ones only two people can execute, so when something breaks, the investigation into who deployed a given resource and which approver signed off on it takes hours rather than a single query.
Each of those gaps is manageable in isolation, but together they create an environment where governance depends entirely on people choosing to follow a process, and governance that lives in a review meeting is a step someone under deadline can decline. The alternative is to engineer that consistency deliberately, so that approvals, tags, CMDB entries, and budget checks live in the request path itself, where skipping them is not an option.
The VMware disruption is making the estate more heterogeneous, not less. In CloudBolt’s CII Reality Report 2026, The Mass VMware Exodus That Never Was: The Squeeze Is Just Beginning, 86% of the 302 surveyed IT decision-makers reported that their organizations were actively reducing their VMware footprint. CloudBolt fielded the research in January 2026 and announced it on 17 February 2026; those surveyed organizations are responding by moving workloads to public clouds and alternative hypervisors while continuing to run vSphere.
The reference architecture puts the control layer above everything that executes:
Six capability clusters and their tradeoffs
CMP capabilities fall into six operational clusters. Each pairs what a tool does with what it makes harder, and in a vendor demo the question worth asking is whether your team can accept the tradeoff.
Governance and access control
Policy in a CMP executes at provisioning time, before spend happens. The mechanism is a rules engine plus RBAC: catalog items carry cost and tagging controls alongside security requirements and approval chains, and every action lands in an audit trail. Policy as code stores those rules in version control and makes them auditable. Identity stays where it is under the shared responsibility model you already run, and the CMP integrates with IAM and SSO primitives such as SAML instead of replacing them.
None of this enforcement happens automatically. Platform teams must write the policy before the CMP can act on it, and every catalog item you introduce becomes an artifact your team is responsible for keeping current.
Cost controls before provisioning
Budget enforcement at provisioning inverts the usual sequence, where teams reconcile overages after requesters and approvers have made every provisioning decision. Requesters see a pre-deployment cost estimate at order time, and the CMP routes requests over a budget threshold to approval while processing requests within it. Chargeback bills actual consumption to a business unit’s budget, showback provides the same visibility without the billing transfer, and both depend on platform teams enforcing tags during provisioning instead of backfilling them later. Rightsizing recommendations then apply to the running estate.
Estimates are only as accurate as the rate cards behind them, and private-cloud costs need explicit rate cards because no bill arrives to correct you.
Service packaging and end-to-end self-service
The catalog is the developer-facing surface that ties everything together, giving teams a single path from request to running workload. A CMP can package resources, request parameters, orchestration actions, and policy controls into one orderable catalog item. Vendors name that construct differently. CloudBolt calls it a blueprint, and in CloudBolt’s implementation blueprints compose, so a governed-database blueprint can sit inside a three-tier application blueprint while remaining independently orderable, and teams get both the complete stack and its parts. When infrastructure teams require approvals, the CMP routes them through ServiceNow or Jira.
CloudBolt’s implementation illustrates one way this path can work end to end. Platform teams define a cost threshold, the platform escalates requests above it and auto-approves routine requests below it, and the IP allocation, DNS record, CMDB entry, and required tickets are handled before the developer receives a complete governed production build.
The catalog is only as good as the service definitions behind it, and those need owners.
Orchestrating the tools you already run
A CMP can coordinate several execution methods within a single governed workflow, including Terraform, Ansible, native integrations, Python plugins, and Bash or PowerShell scripts, using whichever tools the team is already familiar with. It also connects to GitOps pipelines where they exist, then handles the connective steps in between: updating the ServiceNow ticket, requesting the IPAM address, registering DNS, and recording the result.
Some CMPs can synchronize orchestration logic with Git, so teams manage automation like application code, with review and rollback, and production can run on read-only synchronization. CloudBolt ships this as Actions as Code.
The tradeoff is that the orchestration layer is now itself something you operate, which is why portability matters. In CloudBolt’s approach, teams can take workflows they write in plain Python with them, while a proprietary runtime makes workflows harder to move.
Inventory and day-two operations
Unified visibility creates one inventory spanning cloud and datacenter environments, including Kubernetes clusters. Agentless discovery and continuous state sync pick up brownfield resources that teams created outside the platform while preserving ownership and tagging, which turns orphaned assets and shadow provisioning from a suspicion into a count. Day-two work, including resizing, script execution, snapshots, power scheduling, and decommissioning, runs inside administrator-defined guardrails with a full audit trail instead of scattered across tools and runbooks.
Connector depth varies across the category. Your least common infrastructure, the platform you provision once a quarter, is where the gaps show up, so run discovery there first. A clean result against AWS proves very little, because every vendor in the category covers AWS well.
CloudBolt CMP extends this with role-based visibility controls and policy-driven remediation workflows that act on discovered resources directly.
Migration without stranding your automation
A CMP serves migration as a use case, and you do not need a migration underway to adopt one. The platform orchestrates workload moves and enforces the same policy on both sides of the transition. A VMware exit can strand the automation layer as well as the VMs, a risk migration teams often overlook. Platform teams typically encode service definitions, orchestrator workflows, approval logic, naming templates, and IPAM and CMDB integration in platform-specific formats that do not come along. Teams weighing an upgrade to VMware Cloud Foundation Automation hit that question first.
Broadcom’s 2026 technical deep dive documents the 8.18.1-to-9.1 path as a 16-stage migration that stands up a new environment alongside the old, with downtime beginning at stage 9. Only 4% of the organizations in CloudBolt’s CII Reality Report 2026 had completed a full migration away from VMware. A CMP with cloud endpoints for OpenShift Virtualization and Hyper-V lets policy and workflows persist while the hypervisor underneath changes, and Azure Local support extends that portability to another target.
Native consoles govern only their own cloud
Cloud providers design their native governance tools to govern their own environments. That boundary is the problem for any organization running workloads across more than one cloud, because an estate spanning several providers leaves teams without consistent policy enforcement or a combined view of cost and inventory.
AWS
AWS documentation states that a registered OU’s controls apply only when Account Factory creates the account. Control Tower governs AWS resources only.
Azure
Azure Arc manages servers outside Azure, though Microsoft’s own prerequisites documentation says it “isn’t optimized for scenarios where you are regularly creating and deleting servers.”
Google’s GKE on AWS and GKE on Azure are in maintenance mode, with a documented shutdown on 17 March 2027.
Writing for Forrester in 2023, Tracy Woo made the same point: “Unified visibility is a nice idea but hard to deliver.”
Using your existing Terraform and Ansible as the execution engine
A CMP can use IaC as an execution engine within its governed workflow, alongside native integrations, plugins, or scripts. Catalog items can reference the Terraform modules you already wrote, along with other provisioning methods, and teams can adopt the CMP in stages while retaining their existing modules.
CloudBolt’s implementation reflects this model across several layers. CloudBolt publishes a Terraform provider in HashiCorp’s public registry (CloudBoltSoftware/cloudbolt, currently v1.1.7). CloudBolt CMP natively orchestrates Ansible within governed workflows. Customers can connect GitOps tools such as Argo CD and Flux through customer-built extensibility. CloudBolt also connects surrounding systems through integrations spanning ITSM, IPAM, DNS, identity, and CMDB.
CloudBolt’s extensibility uses plain Python, which keeps orchestration logic portable and Git-backed. A team can build an unsupported capability itself instead of waiting on a vendor roadmap.
When a cloud management platform is overkill
A control layer earns its keep at a certain size and shape of estate, and below that it is overhead. One cloud, one team, and a few dozen resources do not need approval routing and a service catalog, because the people who would approve requests already know everyone asking. The same holds when every workload runs on one hypervisor through one provisioning path, where Terraform and a pull request cover the job.
The threshold is heterogeneity more than headcount. Two or more execution environments, teams that do not share a runbook, and an audit or chargeback obligation someone has to answer for are what turn governance into an engineering problem. If nobody has yet had to work out who deployed a given resource and which approver signed off on it, the estate has not reached the point where a CMP pays back the service definitions it asks you to write.
Cloud management platform vendors worth a shortlist in 2026
The options differ most in hybrid provisioning depth, deployment model, asset-management scope, extensibility, and dependence on a broader vendor ecosystem.
CloudBolt CMP
Best fit: Teams that need governance and lifecycle orchestration across public clouds, private infrastructure, virtualization, and Kubernetes while retaining their existing Terraform, Ansible, and ITSM systems.
Advantages: CloudBolt CMP has resource handlers for vSphere, Nutanix, OpenStack, Hyper-V, SCVMM, OpenShift Virtualization, Proxmox, Azure Local, and Oracle Linux Virtualization Manager, alongside AWS, Azure, GCP, and Oracle Cloud Infrastructure. Hyper-V connects either directly or through SCVMM, so an enterprise estate already standardized on SCVMM keeps the management layer it runs today.
CloudBolt is a self-hosted application, meaning it runs wherever you have compute, public cloud or datacenter, which is what makes it workable for air-gapped networks and sovereign cloud.
Its biggest differentiator is an easy-to-implement extensibility layer built on Python, the language of automation, that runs throughout the platform, so teams can add capabilities the platform lacks, including custom UI components, and tailor their instance to their own requirements without waiting on a vendor roadmap. Insight Partners backs the independent company. GigaOm named it a Leader and Fast Mover in the GigaOm Radar for Cloud Management Platforms v4, 2025 (GigaOm recognition).
Limitations: Teams must maintain the orchestration logic and catalog content they add to the platform.
Selection criterion: Test whether the platform can complete a governed build across your least common infrastructure and surrounding ITSM, IPAM, DNS, and CMDB systems.
HPE Morpheus Enterprise
Best fit: Organizations prioritizing broad hypervisor coverage, especially for VMware displacement on HPE infrastructure.
Advantages: HPE Morpheus Enterprise manages VMware and HPE’s HVM alongside other private- and public-cloud targets. HPE acquired Morpheus Data in August 2024. VM Essentials licenses per socket against Broadcom’s per-core model, at roughly $600 per socket per year. HPE added migration incentives at Discover in June 2026, including a free first year of VM Essentials for new customers. Hypervisor coverage runs deep, and bare metal integrates with HPE OneView.
Limitations: HPE delivers Morpheus Enterprise as a software appliance; a fully managed SaaS service is unavailable. Any migration to a new hypervisor introduces application downtime, a caution HPE’s own documentation states explicitly. HPE’s roadmap and go-to-market also reflect the company’s hardware ambitions. That same June 2026 announcement describes a single control plane built on Morpheus spanning edge to datacenter, so buyers should weigh how much of the roadmap serves hypervisors outside HPE’s own portfolio. Extensibility is comparatively limited, and deep platform extension relies on Groovy, a backend developer language, which raises the skill bar compared with platforms that expose a plain-Python model. Buyers should verify support quality and roadmap continuity directly with HPE and reference customers.
Selection criterion: Evaluate the product when socket-based licensing and HPE OneView integration align with your infrastructure strategy. Include VMware-to-HVM migration in that assessment.
VMware Cloud Foundation Automation
Best fit: Organizations committed to a VMware Cloud Foundation estate and the vSphere Supervisor Platform.
Advantages: Broadcom renamed Aria Automation as VMware Cloud Foundation Automation with VCF 9.0 in June 2025. For a committed VCF estate, its coverage is native rather than connector-based: cloud templates, a self-service catalog, native multi-tenancy, and Terraform integration.
Limitations: Broadcom no longer sells the product separately. Hybrid depth stops at the edge of the VCF estate because the product runs on the vSphere Supervisor Platform and requires a Broadcom VCF subscription. The product does not reach public clouds or non-VMware hypervisors. Teams that are not committed to VMware alone therefore face severe lock-in.
Selection criterion: Shortlist it when VCF remains the long-term control plane and native integration matters more than portability across unrelated infrastructure stacks.
Ownership and roadmap risk
Ownership shapes these commercial options as much as features do:
- IBM: Reuters reported in 2023 that IBM bought Apptio for $4.6 billion. IBM closed the HashiCorp acquisition for $6.4 billion in February 2025, according to the 2025 SEC filing.
- Flexera: Flexera acquired Snow Software in February 2024, NetApp’s Spot FinOps portfolio in March 2025, and ProsperOps with Chaos Genius in January 2026.
- DoiT: DoiT acquired PerfectScale in February 2025.
- HPE: HPE acquired Morpheus Data in 2024.
Owners and company leaders set roadmap priorities, approve support investment, and decide whether a product remains a standalone offering, so ownership belongs on the evaluation scorecard alongside features.
How to evaluate and choose a cloud management platform
Verify six things before shortlisting:
| Criterion | What to verify | Signal to watch for |
|---|---|---|
| Deployment model | SaaS and self-hosted options, including air-gapped deployment | SaaS-only excludes air-gapped and sovereign-cloud estates |
| Licensing model | Subscription structure and the unit of pricing | Per-socket and per-core pricing change the math at scale; per-resource pricing does too |
| Integration depth | Native ITSM, IPAM, DNS, CMDB, IaC connections | CMDB and IPAM implemented as workflow steps without custom scripting per request |
| Extensibility | Language and runtime; code portability | Missing capability means a roadmap request or code you write yourself |
| Hybrid and on-prem depth | Provision and day-two on vSphere, Nutanix, OpenStack, Hyper-V | Real cloud endpoints vs. shallow API inventory wrappers |
| Scalability | Concurrent request handling, multi-site management | Test behavior at your production estate size because demo environments may be smaller |
For a team that builds its own tooling, the extensibility row is the one to weight heavily. When the platform lacks something you need, the difference between vendors is whether you file a roadmap request or write the capability yourself. CloudBolt addresses that gap with a plain-Python extensibility layer that runs against the platform and stores the team’s code in Git.
Run the evaluation in this order:
- Inventory the systems a governed request must touch today: ITSM, IPAM, DNS, CMDB, identity, and every IaC repository.
- Pick one workload path, ideally your most-requested VM or service build, and define what complete governed build means for it.
- Reproduce that path in each shortlisted vendor’s sandbox against your own toolchain, not a demo environment. Have the engineer who owns today’s runbook conduct the test. If the governed build completes without hand edits, move that vendor to a paid evaluation.
- Measure two numbers before and after: request-to-running time, and the time it takes to identify who deployed a given resource and which approver approved it.
A production request has to cross budget approval, IPAM, DNS, CMDB, tagging policy, and eventual decommissioning before anyone can call it governed. Terraform and Ansible were built for provisioning and configuration, and their maintainers say so; coordinating those handoffs sits outside their scope. That coordination is the job a CMP does, above the tools you already own. CloudBolt CMP runs that path across hybrid infrastructure while your existing automation and ITSM systems keep their roles, and it is now free for up to 100 resources, counting any cloud object the platform manages, from VMs and storage to clusters, databases, and networks. That is enough to run one of your own workload paths through it end to end.
Run one governed build through CloudBolt CMP
CloudBolt CMP free
Frequently asked questions
Can one platform enforce governance and compliance across every cloud we run?
A CMP can apply shared governance across supported platforms, but enforcement depth varies by connector and resource type. Platform teams encode policy in catalog items, and the CMP enforces it in the request path through RBAC and a rules engine, with audit trails recording enforcement across platforms. Verify depth per platform: several products enforce well on public clouds while treating on-premises infrastructure as read-only discovery.
How should we choose a CMP deployment model?
Choose the deployment model based on your data-sovereignty requirements, because SaaS-only products rule out air-gapped and sovereign-cloud estates before the evaluation starts. CloudBolt is a self-hosted application, so it runs wherever you have compute, in a public cloud or your own datacenter, and the control plane stays inside your boundary. Air-gapped deployment is supported, and the upgrade path is the same one every other customer runs: download the update, move it to the CloudBolt appliance, run the upgrader. How that transfer happens is governed by your own transfer policies rather than by the vendor.
If we already run FinOps tooling, why do cost controls belong in the CMP?
FinOps reporting reconciles spend after requesters and approvers have made every provisioning decision. The CMP governs the request before spend happens, through cost estimates at order time and budget thresholds that route approvals. It also enforces the tags that make later chargeback and showback accurate. The two work together, but only one of them can prevent an overage.
Where does hybrid coverage differ from multi-cloud coverage?
Multi-cloud describes several public providers under one control plane. Hybrid puts datacenter virtualization and private cloud on that same plane, and that is where products separate. Plenty of them cover several public-cloud providers, yet cannot provision or run day-two operations on vSphere, Nutanix, OpenStack, or Hyper-V. Test both halves of your estate before you shortlist anything.
Related Blogs
Where GPU waste hides on Kubernetes
GPUs are the most expensive resource most teams run, and the hardest to account for. On Kubernetes, where pods share…
