Cloud Operations Best Practices: Multi-Cloud Guide

Organizations rarely adopt a cloud management platform (CMP) proactively. By the time the operational pain is obvious, the sprawl is already significant. Resources provisioned through multiple cloud providers have become business dependencies, governance has lagged behind growth, and engineering teams are spending most of their time on provider-specific interfaces with no consistent operating model.

CMPs address this by sitting above all cloud providers as a unified control plane, centralizing orchestration, governance, and visibility. The six practices below reflect how to get the most out of that model, from standardizing day-2 actions to reconciling inventory against provider state.

Summary of cloud operations best practices

Multi-Cloud Management Platform:
Automation, Infrastructure-as-Code & FinOps

Learn More

Customizable guardrails to embed governance policies when provisioning workloads

Self-service catalogs to provision compliant, cost-efficient resources in private and public clouds

Accountable FinOps workflows with task assignment, chargeback reports, and scorecards

Standardize day-2 actions across cloud providers

Multi-cloud is rarely a deliberate architecture choice. Some teams need provider-specific technology, others want to reduce lock-in risk, and acquisitions bring their own estates. Whatever the path, the result is the same: engineers responsible for operations across providers that share no common interface.

Initial provisioning is a solved problem. With tools like Terraform and Ansible, cloud engineers can automate infrastructure creation reliably. Day-2 operations are the harder part: running, operating, patching, resizing, rotating credentials, and decommissioning resources at scale, across multiple providers, consistently.

Each cloud provider has its own APIs, IAM model, and console. Relying on provider-native tooling for day-2 operations means every action requires provider-specific knowledge, and governance becomes difficult to enforce uniformly. This compounds as organizations span AWS, Azure, GCP, and on-premises environments like OpenShift or vSphere simultaneously.

A CMP addresses this by presenting a provider-agnostic interface for standard operations. A resize action looks and behaves the same way to an engineer regardless of whether the target resource is on AWS or vSphere. The platform handles the provider-specific API translation internally. Actions can also be constrained to pre-approved options, such as permitted instance sizes, applying cost and performance governance without manual review of every request.

These day-2 actions work best as a platform-level catalog that other teams consume through self-service. The platform team defines and maintains the actions; application teams run them without filing tickets or learning provider APIs.

CloudBolt-managed VMs can also be resized using the CloudBolt API:

$ curl -XPOST -H 'Content-Type: application/json' -d '{"new_size": "Basic_A2"}' -H "Authorization: Bearer [encrypted_token_value]" http://localhost:8000/api/v2/servers/45/actions/2/ 

The orchestration platform should enforce role-based access control (RBAC) for these day-2 actions, extending consistency to permissions. The same team gets the same rights and capabilities regardless of the identity and access management (IAM) conventions each cloud provider uses. Role-based assignments then apply one governance model to the full resource lifecycle across all clouds.

These orchestration functions should be stored in version control, customized, and extended as the organization’s needs evolve.

Monitor orchestration workflow health

Orchestration workflows are the backbone of day-2 operations. They provision resources, enforce compliance, execute maintenance routines, and respond to operational events. As they grow in scope and complexity, monitoring their health becomes critical.

At minimum, track three metrics for every recurring and on-demand workflow:

• Job success rate: identifies workflows that are degrading over time
• Average execution time: can signal a problem before it becomes an outage
• Failure step: the most diagnostically useful metric; workflows that consistently fail at the same step almost always point to a dependency or credential issue, not a code defect

Remediation logic for failed steps can also clean up incomplete resources. Monitoring workflow output in this way surfaces noncompliant or partially deployed infrastructure that would otherwise go undetected.

A unified cloud management platform can centralize orchestration action logs, significantly reducing detection and analysis times. CloudBolt, for instance, records execution history for workflows and actions, allowing operations teams to review patterns across runs rather than treating each failure as an isolated incident. Implementing generous log retention periods helps build a longer-term picture. Regular review of these logs, combined with alerting, converts what would otherwise be reactive incident response into proactive maintenance.

Alerts should be routed to the team responsible for the affected workflow, with enough context (workflow name, failure step, affected resources, environment) for the team to investigate and remediate immediately.

In CloudBolt, alerts can be managed and configured in the interface, as shown below.

And custom alerts can be sent via the CloudBolt API, as shown in the following code.

from alerts.methods import alert

def run(job, **kwargs):
  alert(
    message='Something good has happened',
    category='rak.good_news'
  )
  
  alert(
    message='Something bad has happened',
    category='rak.bad_news'
  )
  
  return '', '', ''

Use cost data as an operational input

Cost data is typically treated as a reporting concern: something finance reviews in a monthly billing summary. This is too late to be useful for operational decision-making.

A CMP brings cost data forward, before infrastructure even exists. Provisioning blueprints can show cost forecasts before resources are created, comparing instance types, operating systems, or cloud providers so engineers make cost-aware decisions before committing. Team or department budgets can be integrated directly into provisioning forms, making financial context a standard part of the workflow rather than an afterthought.

Cost data should also be visible in day-2 operations. Cost visibility for operational actions helps inform decision-making and removes guesswork. It also helps guide appropriate decisions for right-sizing, backups, retention policies, and more, even before the changes are implemented. 

CloudBolt’s hybrid cloud reporting, which supports the FinOps Foundation’s FinOps Open Cost & Usage Specification (FOCUS) open-source standard, is designed around this principle. It exposes cost data directly within the management layer rather than in a separate FinOps tool, even accounting for savings plans and configurable power control settings. This means cost visibility is available to engineers making deployment and operational decisions, in the same interface where those decisions are made, without requiring a context switch to a separate platform.

Consider how the cost implications of a CloudBolt operations job could be surfaced in the job interface itself and enforced using a policy. This could be done with a custom Python action as shown below:

def run(job, *args, **kwargs):
    server = kwargs.get("server")
    new_cpu = kwargs.get("cpu_count")

    # Example cost model (simplified)
    current_cost = server.cpu_count * 10
    new_cost = new_cpu * 10

    delta = new_cost - current_cost

    job.set_progress(f"Current cost: £{current_cost}/mo")
    job.set_progress(f"New cost: £{new_cost}/mo")
    job.set_progress(f"Change: +£{delta}/mo")

    # Governance rule
    if delta > 50:
        raise Exception("Cost increase exceeds allowed threshold without approval")

Cost alerting and anomaly detection can also be set at the CMP level. Teams can set cost anomaly thresholds by environment and guard against unexpected or runaway costs, so the people responsible for investigating and remedying a spike are notified immediately. Cost spikes in development environments can easily go unnoticed and are nearly always an operational issue with an operational remediation path.

Cost data should also inform reclamation decisions because not all idle resources are equally worth reclaiming. A resource that is idle and expensive should be prioritized in the reclamation queue over one that is idle but cheap. CloudBolt’s platform surfaces cost alongside utilization data, so reclamation workflows can be prioritized by financial impact rather than treating all idle resources as equivalent. 

Here is an example custom Python action in CloudBolt to highlight cost savings from idle resources:

def run(job, *args, **kwargs):
    server = kwargs.get("server")

    if server.cpu_usage < 5:
        job.set_progress("Low utilisation detected")

        # Suggest action
        job.set_progress(
            f"Consider downsizing to save ~£{server.cpu_count * 5}/mo"
        )

Enforce tagging compliance continuously

Tagging is how cloud resources get assigned ownership, cost allocation, and policy. Most organizations enforce tagging at provisioning time, which is insufficient. Resources can arrive untagged or incorrectly tagged through several common paths:

• Imported into the CMP from a pre-existing cloud estate
• Cloned or snapshotted from existing resources, but stripped of tags
• Provisioned directly through the cloud provider console
• Subject to an ownership change after deployment
• Using tags from an older tagging specification

These situations can result in significant portions of an organization’s cloud estate being untagged or incorrectly tagged.

CMPs aim to solve this by continually monitoring and enforcing tags. Continuous enforcement means running scheduled tagging audits using recurring jobs that check every resource, managed or otherwise, against the latest required tagging specification. CloudBolt’s recurring job framework supports this model: organizations can define the required tag schema, schedule regular audits, and highlight violations with owner attribution directly within the platform.

Attribution is critical here. A tagging violation should trigger a notification directly to the resource owner, not a central queue. Tags applied by the platform itself keep departments, accounts, environments, and namespaces tagged as a matter of course through platform orchestration.

Here is an example CloudBolt job applying new tags to multiple (current and future) resources, across clouds if necessary.

Organizations can even convert compliance from a state to a metric. Remediation SLAs can guide behavior, while compliance metrics can report status by team, environment, or department. This orchestrated approach makes tagging a routine operational process applied consistently across all cloud environments.

Build runbooks as executable platform workflows

Most engineering teams maintain runbooks, but documentation and execution are separate activities. A runbook that describes a procedure still requires a human to follow each step, introducing variability and the potential for error.

A CMP enables those procedures to be implemented as executable workflows: orchestrated sequences invoked on demand. A central platform also turns runbooks into a shared library. Platform and application teams can contribute workflows, private or public, and the best ones become worked examples of how the organization handles a given procedure. Critically, everything runs from a single interface.

CloudBolt, in particular, emphasizes extensibility as a key platform feature. Because CloudBolt is Python-based, custom automation can be implemented and deployed by the platform team without waiting for vendor features. Business-specific logic can be built and shipped immediately, by developers who understand the requirements. This allows teams to replace documented procedures with an orchestrated workflow that runs routines reliably, handles failure conditions consistently, and produces audit trails of who did what and when, and with what result. 

Teams can build and extend their workflow libraries as needed over time. They can start with the most common maintenance and incident response procedures that deliver the most value to them: disk cleanup, certificate renewal, credential rotation, log archiving, service restarts, collecting usage statistics, and so on.

CloudBolt’s flow control Orchestration Actions also support the conditional logic that makes executable runbooks robust, fault-tolerant, and intelligent across clouds. Consider a credential rotation workflow that handles both cases: when the rotation succeeds immediately and when the dependent service needs a restart before the new credential takes effect. Workflows should handle the manual tasks so that the common paths through an incident or maintenance procedure run without human intervention.

Centralized runbooks should also be treated like any other piece of code: version-controlled and peer-reviewed. Procedures change, APIs get updated, and logic can differ over time, so runbook workflows need to adapt and mature accordingly. These workflow definitions should be updated in source control, reviewed, and promoted through environments before going live.

Runbooks for common tasks across clouds, hosted and executed in this way, let teams rapidly implement organization-specific logic and reduce implementation and resolution times for repeatable tasks. 

Reconcile the CMP inventory against the cloud provider state

A CMP’s value depends on the accuracy of its resource inventory. Resources it does not know about cannot be governed, tagged, cost-allocated, or included in reclamation workflows. 

Resources unknown to a CMP can be expensive to govern and remediate retroactively. They tend to be the ones provisioned outside the standard workflow without the tagging, ownership attribution, and cost allocation that the platform would otherwise enforce for resources provisioned through it.

This gap between what the CMP is aware of and what the cloud provider reports will not be static, either. It will grow continuously as engineers provision resources directly through provider consoles, cloud provider services create dependent resources automatically, and resources are cloned, snapshotted, or migrated outside the CMP’s visibility. 

It is essential to have a reconciliation process through regular and scheduled discovery. Scheduled discovery runs comparing the CMP’s inventory against each cloud provider’s API on a daily basis capture the delta of unregistered resources that need owner assignment and governance registration. 

CloudBolt’s discovery, sync, and reconciliation capabilities automate this comparison, removing the need for manual inventory audits. The output is a structured list of discrepancies: resources that exist in the cloud provider but not in the CMP, ones that exist in the CMP but have been deleted from the provider, and ones whose attributes have changed in ways the CMP has not recorded. Unregistered resources can then be routed to the team most likely to own them based on account, region, and any existing or inferred resource tags. This is far preferable to raising a ticket in a queue with a separate support team unrelated to the resources in question.

The maximum age for unregistered resources can also be managed. For example, any resource not claimed and registered within 30 days can automatically enter a decommission review workflow, which prevents indefinite accumulation in the reconciliation list. Without this time limit, unregistered resources tend to persist because no individual team feels sufficiently responsible for resolving them. An automatic escalation after 30 days converts a passive queue item into an active process with a defined outcome.

CloudBolt’s reconciliation data also supports calculating governance coverage ratios. By socializing this data, platform teams can detect if provisioning bypass is happening at scale while also encouraging best practices. This transforms reconciliation from a periodic audit into a continuous governance mechanism.

Summary

The core problem of multi-cloud operations is consistency: consistent governance, consistent automation, consistent visibility across environments that are otherwise completely heterogeneous. Without a unified control framework, this is an engineering problem that grows faster than teams can address it manually.

A CMP addresses this by centralizing the control plane, abstracting provider-specific implementation details, and making operations at scale the default rather than the exception. Extensible architectures like CloudBolt’s shorten the path further: teams can build and ship organization-specific operational logic in days rather than waiting for vendor releases. The practices above reflect how to structure that operational model so it stays accurate, cost-aware, and governable as the environment grows.