Hybrid Cloud Management Platform

Hybrid cloud environments are harder to manage than single-cloud environments because every component runs its own API, access model, and governance surface, and none of them share a control plane. A provisioning request that closes in minutes through AWS Service Catalog might wait three days in a ServiceNow queue for the equivalent VMware resource. Tagging policies defined for Azure don’t apply when the same team deploys to vSphere. These are the gaps where untracked resources, ungoverned spend, and audit failures accumulate.

A hybrid cloud management platform (CMP) is the software layer that governs how resources get requested, deployed, tracked, reclaimed, and delivered across all of these environments through a single control plane. It acts as an abstraction layer above each cloud platform, delivering consistent policy enforcement, access control, and lifecycle behavior whether the underlying infrastructure is public cloud or on-premises.

This article covers eight features that determine whether a hybrid CMP scales with organizational complexity: catalog architecture, inventory and discovery, access and ownership models, governance at the provisioning layer, version-controlled orchestration, tool integration, lifecycle automation, and ongoing resource management.

Summary of essential hybrid cloud management platform features

Feature	Description
Service blueprints and self-service catalog	Catalogs should be structured around deployment archetypes (web app, data pipeline, sandbox, etc.) rather than resource types. Nested sub-blueprints keep shared components like VPC configs and security baselines in one place; role-based visibility limits each team to the blueprints relevant to their environment.
Unified inventory and discovery	Scheduled discovery queries cloud and on-premises APIs to surface resources the platform didn’t provision. Unmanaged assets are reconciled against the managed inventory so they can be governed, lifecycle-tracked, and cost-attributed.
Role-based access and environment ownership	Each environment has an assigned owning group, an approved blueprint set, and a resource quota. Role separation (Requester, Approver, and Viewer) applies per environment, not per platform, and identity federation bridges on-premises AD and SAML2 providers with cloud IAM.
Governance embedded at the provisioning layer	Required tags, approved instance types, and budget thresholds are enforced at request time. Noncompliant deployments are blocked rather than flagged after the fact, and ITSM tickets are created before resources deploy rather than after.
Version-controlled orchestration and automation	Orchestration action definitions live in Git and are pulled into the platform from a remote source, so workflow changes go through PR review and can be promoted across environments like application code. Flow control supports conditional branching and explicit failure handling for each step.
Integrations with ITSM, CMDB, IPAM, and DNS	ITSM, CMDB, IPAM, and DNS integrations run at the orchestration layer, so every provisioned resource gets a change record, a CMDB entry, and a tracked network identity from the same workflow. The platform’s API provides programmatic access to the full provisioning and resource management surface.
Automated resource lifecycle management	Blueprints set expiry dates and owner assignments at creation time; recurring jobs trigger renewal notifications and decommission workflows on schedule. The decommission sequence covers CMDB deregistration, DNS cleanup, IP release, and resource deletion as a single orchestrated process.
Ongoing resource management	Management actions on live resources run through the platform: patching, application deployment updates, compliance checks, and user-initiated operations keep workloads in a governed state between provisioning and decommission.

Interactive Cloud Architecture Builder

See how CloudBolt fits your stack

Map out your clouds, tools, and platforms, then see exactly where CloudBolt CMP plugs in as your unified control plane.

Build your architecture

Service blueprints and self-service catalog

The flat-list problem

The most common catalog problem is structure, not complexity. When a CMP’s service catalog lists every resource type the platform supports, entries like “AWS EC2 instance,” “Azure VM,” and “VMware guest” sit in a flat list that functions as a resource browser rather than a self-service portal. Teams searching for a development environment scroll through dozens of entries, and most end up opening the cloud console instead. 

Structuring the catalog around deployment archetypes instead changes the experience. An archetype represents a complete deployable pattern: a three-tier web application, a data pipeline stack, a developer sandbox, and a database cluster with backup. Each encapsulates the resources, network configuration, and security baseline required for that workload type.

The archetype model also reduces developers’ cognitive load. Instead of navigating resource types across three or four cloud providers, a developer selects a pattern that matches their functional requirement, like a sandbox, a data pipeline stack, or a three-tier web app. Where multiple cloud targets support a given archetype, the catalog can surface cost and performance data side by side, letting teams pick an environment based on requirements rather than on familiarity with each provider’s terminology.

Nested template composition

Nested template composition makes the catalog maintainable at scale. Shared components, like a standard VPC configuration, a security group baseline, and a DNS registration step, live in sub-blueprints that parent blueprints reference by name. When your organization changes its standard VPC CIDR allocation, you update one sub-blueprint, and every archetype picks up the change. CloudBolt’s blueprint framework handles nested composition and parameterized service templates natively.

Unified inventory and discovery

The visibility gap

A CMP that only tracks resources it deployed has a visibility gap by definition. In most hybrid environments, a meaningful share of running infrastructure arrives through other channels: cloud console access, Terraform runs that bypass the platform, migration tooling, or legacy provisioning workflows that predate the CMP. An initial discovery run against a cloud account active for two or more years often reveals dozens or hundreds of unmanaged resources that consume budget and retain configuration state but don’t appear in the platform’s inventory or cost reports.

Scheduled discovery and reconciliation

A CMP should close this gap by periodically querying cloud-provider APIs and on-premises hypervisors, then reconciling the results with the platform’s managed inventory. The output is a single-pane-of-glass inventory that spans every connected cloud and on-premises environment, with managed and unmanaged assets in one place. 

CloudBolt’s Servers view surfaces the full managed resource inventory across connected environments, with summary breakdowns by resource handler, owner, group, and environment alongside per-resource metadata, including expiration date and custom tag fields. It also enables high-level standardization of an organization’s resource metadata, providing a complete picture across all cloud types. The next screenshot represents an example of such an inventory snapshot.

Resources that exist in a cloud account but are not in the platform should surface as unmanaged assets, with a clear path to import them into platform governance. CloudBolt’s resource handlers support scheduled discovery across AWS, Azure, GCP, and on-premises virtualization platforms, including VMware and Nutanix, with existing ownership and tagging data preserved on import. Azure Arc and AWS Systems Manager provide scoped discovery within Microsoft and AWS environments, respectively, but neither spans private cloud and on-premises from a single control plane.

Role-based access and environment ownership

Environment ownership as a first-class concept

Most CMPs offer user roles; fewer offer environmental ownership as a first-class concept. The distinction matters when you have ten teams sharing a platform and three of them are in regulated workload environments that shouldn’t see each other’s blueprints, quotas, or request histories.

Environment ownership means each environment has an assigned owning group, an approved blueprint set, and a resource quota. Teams within that owning group provision freely without requiring global admin involvement, since the approval rules are already encoded in the environment definition. CloudBolt’s groups and permissions model supports native per-environment role separation, with Requester, Approver, and Viewer roles that can be assigned at the environment level. Identity federation is the friction point most teams encounter after the platform is deployed: On-premises workloads authenticate against Active Directory or LDAP, while cloud workloads use provider-managed IAM or Okta, and platforms that bridge both through a single group model reduce this to a single set of role definitions that propagate across all environments.

Cross-cloud IAM extends this further. A team operating across AWS, Azure, and an on-premises VMware environment manages three separate identity systems that don’t share a policy model. An engineer might hold the correct permissions in AWS IAM and insufficient access in Azure AD for the same workload type, with no centralized view of that discrepancy. A hybrid CMP with cross-cloud IAM visibility surfaces the question of whether identities have the correct access across all environments, not just whether access exists somewhere. This matters most during security reviews and access audits, where the relevant question isn’t “does this user have an account” but “is this user’s access consistent, appropriate, and current across every environment they touch.”

Role assignments and environment scope

The Users tab in the following screenshot shows role assignments at the group level. Each row represents a group member, and each column represents a discrete permission: Requestor, Approver, Console Access, Delegate Server Owner, Group Admin, Resource Admin, and Viewer. A user can hold multiple roles simultaneously; an admin user carries both Approver and Requestor rights, while a viewer-only member has a single checkmark. This is where the “what you can do” half of access control is defined.

The Environments tab answers the other half of the question: “where those permissions apply.” Direct Environments lists the specific cloud targets the group has access to, in this case, environments spanning AWS, Azure, Hyper-V, OpenShift, OpenStack, Oracle Cloud Infrastructure, and VMware. Inherited Environments shows access passed down from a parent group (none here), and Unconstrained Environments lists targets where the group’s resource quotas don’t apply.

CloudBolt’s groups and permissions model supports native per-environment role separation, with Requester, Approver, and Viewer roles that can be assigned at the environment level. Identity federation is the friction point most teams encounter after the platform is deployed. 

For example, on-premises workloads authenticate against Active Directory or LDAP, while cloud workloads use provider-managed IAM or Okta. Platforms that bridge both through a single group model reduce this to a single set of role definitions that propagate across all environments.

Governance embedded at the provisioning layer

Proactive vs Reactive governance

Auditing for governance violations after deployment is expensive. Finding an untagged resource in a post-deployment scan means tracking down who deployed it, determining why tagging was skipped, and updating documentation. Finding the same issue at provisioning time costs a rejected request and a form correction.

Enforcement at the request layer

Required tags, approved instance types, and network constraints baked into blueprint definitions block noncompliant resources at submission. There’s nothing to remediate after the fact because the resource never deploys. Budget guardrails work the same way: A request above a spend threshold routes to a cost approver, and a request that would exceed a hard limit is rejected outright.

CloudBolt’s Automation and Orchestration layer handles this routing as part of the provisioning workflow, with native ServiceNow integration for pre-deployment ticket creation. 

Every governance rule runs before the resource exists. The form below shows what that looks like in practice: environment selection constrained to approved budget blueprints, network preassigned, expiration date required at submission, and a live cost forecast calculated against the active monthly budget.

The table below shows how the two approaches differ across the dimensions that matter most operationally.

Governance model	Tag compliance	Budget enforcement	Audit record
Post-deployment audit	Violations found after the fact; remediation cost grows with delay	Budget exceeded before detection	Change record created retroactively
Provisioning-layer enforcement	Noncompliant requests blocked at submission	Spend thresholds are checked before resource creation	Approval precedes deployment

Governance at the provisioning layer is not slower than post-audit governance. A properly configured blueprint deploys faster than a manual request that waits for an admin to review tags after the fact.

Version-controlled orchestration and automation

Git-backed action definitions

Storing orchestration action definitions in a Git repository solves the auditability problem before it develops. Hybrid CMP workflows accumulate technical debt quickly: A workflow is edited for a specific IPAM system, then again for a network constraint, and again for a new cloud region, and after 18 months, no one is sure what it does.

When those actions live in version control, changes go through pull request review, and the history of what changed and who approved it is part of the repository log. Remote source support takes this further: The platform pulls action definitions from a designated repository branch, and promoting a workflow change from staging to production follows the same branching model as application code. 

CloudBolt’s blueprints as code and remote source support handle this natively. Ansible Automation Platform and HashiCorp Terraform also support Git-backed workflow management, though a CMP attaches orchestration actions directly to provisioning lifecycle hooks rather than running as separate pipeline stages.

Integrations with ITSM, CMDB, IPAM, and DNS

The parallel provisioning problem

Every enterprise running hybrid cloud has accumulated a set of operational tools: a ServiceNow instance for change management, a Bluecat or Infoblox deployment for IPAM, a DNS system, and a CMDB. These tools predate the CMP and continue to receive provisioning events directly from engineers with console access, from automation scripts, and from cloud provider self-service interfaces. The result is parallel provisioning channels that each update a different system of record: Resources deployed outside the CMP don’t get CMDB entries, IPAM addresses, or DNS records.

Integration at the orchestration layer

A CMP functioning as the single control plane requires that ITSM, IPAM, DNS, and CMDB integration operate at the orchestration layer, not as separate post-deployment steps. A blueprint deployment triggers the full registration sequence in the same workflow: CMDB entry, IPAM address request, and DNS record, all completed before the requester receives confirmation. CloudBolt’s technology integration framework covers more than 200 connectors with a Python-based extensibility layer for custom integrations. 

Morpheus and Aria offer connectors and plugins, but they rely on scripting languages like Groovy and JavaScript, which aren’t as intrinsic to DevOps as Python. CloudBolt’s API v3 provides full programmatic access to provisioning and resource management, so teams can embed CMP operations directly into CI/CD pipelines.

The four integration categories below cover the systems most commonly in place before a CMP arrives. The third column is the one to focus on: It’s where unintegrated provisioning shows up operationally.

Integration category	What it connects	Risk if missing
ITSM (ServiceNow, Jira Service Management)	Change approval, incident creation, ticket lifecycle	Change records created retroactively or not at all
IPAM (Infoblox, Bluecat)	IP address assignment and tracking	Duplicate addresses, untracked network resources
DNS	Hostname registration, forward/reverse records	Resources accessible by IP only; no hostname-based access control
CMDB	Asset inventory, configuration item tracking	Shadow resources; no source of truth for infrastructure state

A resource that exists in the cloud provider but not in the CMP is invisible to all downstream tools that rely on the CMP as their data source. Discovery runs that reconcile provider inventory against platform inventory surface these gaps before they accumulate into a governance or billing problem.

Automated resource lifecycle management

Lifecycle starts at provisioning

Provisioning is the visible half of infrastructure management. What happens after a resource deploys often relies on manual processes: An engineer requests a VM for a short-term project, the project ends, and the VM keeps running because no one scheduled a decommission. A few orphaned instances quietly become a few dozen as teams turn over.

Automated lifecycle management starts at provisioning, not cleanup. When a blueprint creates a resource, it should also set an expiry date, assign an owner, and schedule a renewal notification. Recurring jobs handle the rest, like flagging resources approaching expiry, triggering escalating notifications, and initiating decommission workflows for resources whose owners don’t respond. The decommission workflow handles the full teardown as a single orchestrated process: CMDB deregistration, DNS cleanup, IP release, and resource deletion. CloudBolt’s recurring jobs run automatically and trigger notifications or multi-step decommission sequences without manual initiation.

Decommission as an orchestrated sequence

The example Python logic below shows how the expiry check works as a recurring job. Two details worth noting: The escalation flag at day seven routes the notification to a different recipient or channel than the first reminder, and the decommission function defines the teardown sequence as an ordered list rather than a script.

# Example: recurring job logic for expiry enforcement
# Runs daily; flags or decommissions based on expiry status

def check_resource_expiry(resource):
    days_to_expiry = (resource.expiry_date - today()).days

    if days_to_expiry == 14:
        send_renewal_notification(resource.owner, resource)
    elif days_to_expiry == 7:
        send_renewal_notification(resource.owner, resource, escalate=True)
    elif days_to_expiry == 0 and not resource.renewal_confirmed:
        trigger_decommission_workflow(resource)

def trigger_decommission_workflow(resource):
    steps = [
        deregister_from_cmdb(resource),
        release_ip_address(resource.ip),
        delete_dns_record(resource.hostname),
        delete_cloud_resource(resource.provider_id),
    ]
    run_orchestration_sequence(steps, rollback_on_failure=True)

The rollback_on_failure=True argument is the part that matters operationally. If CMDB deregistration fails, the IP release and DNS deletion don’t run. The resource stays in a known state rather than being partially torn down across systems.

Platform portability and vendor independence

A hybrid CMP governs infrastructure across multiple providers, but the platform itself can become the dependency that constrains your choices. Automation frameworks built on proprietary configuration formats, closed integration runtimes, or vendor-managed execution environments put workflow logic out of reach. When a vendor changes licensing terms, discontinues a connector, or ends support for a platform you rely on, the provisioning and governance logic you built inside it isn’t portable.

The Broadcom acquisition of VMware made this concrete for a significant portion of the enterprise market. Organizations that had built provisioning workflows inside VMware’s ecosystem found those workflows non-transferable when the terms changed. The infrastructure itself could move. The automation built to govern it could not.

CloudBolt’s orchestration layer runs on Python. Every action definition, workflow hook, and custom integration is code you control. A Python plugin written for a CloudBolt workflow can be extracted, adapted, or run in another context without rewriting it from scratch. 

Ongoing resource management

The gap between provisioning and decommission

Provisioning and decommissioning are the visible endpoints of a resource’s life. What happens between them is where most operational work actually occurs. A resource deployed for an application team will require patching cycles, configuration updates, application redeployments, and periodic compliance checks before it ever reaches end of life. Without platform-level management actions, those operations happen outside the CMP through console access, ad hoc scripts, or separate tooling — none of which feed back into the platform’s governance or audit trail.

Management actions as a platform capability

A hybrid CMP should support management actions that run on live resources through the same orchestration layer as provisioning. Platform teams can define actions for patching, application deployments, compliance remediation, and user-initiated operations, then expose them through the catalog with the same role-based access controls and approval workflows as resource creation. CloudBolt’s server actions support this model: actions are defined once, attached to resource types, and available to authorized users on any managed resource regardless of where it runs.

When a management action runs through the platform, it produces an audit record, respects the resource’s governance context, and notifies the owner on completion. The same action run directly against a cloud provider produces none of that. Over time, the gap between managed and unmanaged operations becomes a governance gap.

Conclusion

The features described here aren’t independent. A catalog that is organized by archetype only works if the blueprints inside it enforce governance rules. Governance rules remain current only if the orchestration actions behind them are version-controlled and promotable. Lifecycle automation only captures what the platform knows, so inventory coverage and discovery must come first. The mistake most organizations make is treating each layer as optional rather than as a dependency on the next one.

CloudBolt’s hybrid CMP brings these layers together as an integrated platform covering catalog management, group-based access, blueprint-embedded governance, version-controlled orchestration, broad tool integration, and automated lifecycle management into a single control plane. The starting point is the same: Surface what’s already running, define your deployment archetypes, map your team structure to environment ownership, and build governance into blueprints before traffic hits the platform.