How to Automate Multi-Cloud Provisioning and Governance Without Hand-Syncing Four Copies of the Same Environment

Key points:

• Manual replication is the failure mode, and the workload spread is only the trigger. The fix is one declarative environment definition parameterized by region and provider, applied from a single source of truth, with policy evaluated before every apply.
• Four tool layers solve different parts of the problem: IaC languages (OpenTofu, Terraform, Pulumi), Kubernetes-native control planes (Crossplane), IaC orchestration and policy platforms (Spacelift, env0, HCP Terraform), and internal developer platforms that deploy into your own cloud accounts. Most compliance-driven teams need two layers, not one.
• Drift detection is the dividing line between the layers. Crossplane reconciles continuously through the Kubernetes control loop, Spacelift and env0 run scheduled drift checks with optional reconciliation, and plain OpenTofu or Terraform only surfaces drift the next time somebody runs a plan.
• Governance only counts if it runs before the apply: policy-as-code (OPA/Rego, HashiCorp Sentinel, Kyverno), per-environment RBAC, immutable audit logs and scheduled drift checks. A runbook nobody executes is documentation, and an auditor will not accept it as a control.
• An internal developer platform removes the per-provider module work for clusters and application environments across AWS, GCP, Azure, Scaleway or an existing Kubernetes cluster. It does not replace IaC for org accounts, network backbones or bespoke cloud services, so the realistic stack is OpenTofu, a policy layer, and a platform on top.

Four hand-synced copies of the same environment make you fragile in four places at once. Spreading workloads across clouds buys resilience only when every copy comes from one definition and one policy gate.

I talk to platform teams every week who got a multi-region, multi-provider mandate from compliance and answered it with copy-paste. This article covers what actually removes that manual replication, which tools do which part, and where each one stops.

Why does spreading workloads across clouds turn into manual replication?

Spreading workloads across clouds turns into manual replication because each provider exposes different primitives, so one logical environment becomes three or four unrelated codebases. Those codebases diverge within weeks of the first copy-paste, and you usually discover the divergence during the failover it was supposed to protect.

Compliance asks for regions, providers and provable failover. Engineering inherits N copies of one environment definition with no shared source of truth.

The primitives do not map one to one. Amazon RDS, Cloud SQL, Azure Database for PostgreSQL and Scaleway Managed Database each have different parameter groups, backup models and failover semantics. AWS IAM, Google Cloud IAM and Microsoft Entra ID disagree on how identity binds to resources. VPC, VNet and Scaleway Private Networks disagree on subnets and peering. Copied modules diverge at the first exception.

Drift is the measurable symptom. A security group change applied in eu-west-1 but not in us-east-1 is a latent outage, and nobody finds it until the failover test or the real incident.

The numbers back this up:

• IT and networking issues caused 23% of impactful outages in 2024, a rise Uptime Institute attributes to change management and misconfigurations (Uptime Institute, Annual Outage Analysis 2025).
• 85% of human-error outages stem from staff failing to follow procedures or from flawed procedures (same report). Hand-syncing four environments is a procedure that waits to be skipped.
• 57% of operators said their most recent major outage cost more than $100,000, and one in five reported more than $1 million (Uptime Institute, Annual Outage Analysis 2026).
• DORA found no evidence that formal external change review lowers change fail rates, and found these approaches hurt delivery performance (DORA, Streamlining change approval). Adding a review board on top of manual replication makes it slower without making it safer.

The cost is cognitive as much as temporal. Every engineer must know every provider to make a one-line change safely, which concentrates risk in two or three people and makes the on-call rotation fragile.

I split the problem into three words for the rest of this article: provisioning (create it everywhere), consistency (keep it identical), and governance (prove it is compliant).

What are the four categories of tools that automate multi-cloud provisioning?

Four layers automate multi-cloud provisioning: IaC languages describe resources, Kubernetes-native control planes reconcile them continuously, IaC orchestration platforms run and gate the code, and internal developer platforms generate and operate the per-provider definition for you. The expensive mistake is expecting one layer to do the job of the other three.

• Layer 1, IaC languages: OpenTofu, Terraform and Pulumi describe resources, and Ansible configures what already exists. They do not run themselves, gate policy, or detect drift between runs.
• Layer 2, Kubernetes-native control planes: Crossplane turns cloud resources into Kubernetes custom resources. A Composite Resource Definition defines the schema of your API, and a Composition is the template that creates the underlying resources (Crossplane docs). If someone edits a managed resource out of band, Crossplane reverts it to the declared state (Crossplane managed resources).
• Layer 3, IaC orchestration and policy: Spacelift, env0 and HCP Terraform add stacks and stack dependencies, scheduled drift detection, OPA/Rego or Sentinel gates between plan and apply, approval workflows and audit trails.
• Layer 4, internal developer platforms: a BYOC platform creates and operates Kubernetes clusters and application environments inside your own cloud accounts, so your team does not author or hand-sync the per-provider definition.

The trade-off fits in one line: maximum granular control at layer 1, minimum manual replication at layer 4, and the layers compose rather than compete.

The surface a layer-1-only team takes on is large. The public Terraform Registry lists 7,629 providers (Terraform Registry API, read 2 November 2026) and the OpenTofu Registry indexes 4,855 (OpenTofu Registry). Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML and HCL (Pulumi docs). Your team writes and maintains every module on top.

Single-provider tools deserve an honest mention. AWS CloudFormation StackSets creates, updates or deletes stacks across multiple accounts and regions in one operation, and with AWS Control Tower it is excellent inside AWS Organizations. It stops at the AWS boundary. Azure Deployment Stacks and Google Config Controller, a hosted Config Connector, are the equivalents on the other two hyperscalers.

Which platform should we use for consistent multi-cloud provisioning and governance?

Pick based on who maintains the abstraction. A platform team that wants to own every cloud resource should run OpenTofu or Terraform with Spacelift, env0 or HCP Terraform on top. A Kubernetes-first team that wants self-service APIs and continuous reconciliation should look at Crossplane. A team that needs the same environment reproduced across clouds without writing per-provider modules should look at an internal developer platform like Qovery. Most compliance-driven teams combine two of these.

My decision rules, in the order I would apply them:

• If you need to provision accounts, networks and bespoke cloud services, then you need a layer-1 IaC language, and OpenTofu is the license-neutral default.
• If your auditor wants every change gated, approved and logged, then put Spacelift, env0 or HCP Terraform between the plan and the apply.
• If you already run everything on Kubernetes and want continuous reconciliation, then Crossplane gives you one control loop across providers, as long as you staff the team that writes the Compositions.
• If the copies you hand-sync are mostly clusters and application environments, then push that part down to an internal developer platform and keep IaC for the foundation.

Each tool wins somewhere specific. Crossplane wins on continuous reconciliation and self-service platform APIs, and it reached CNCF Graduated status on 28 October 2025 (CNCF). Spacelift wins on policy depth and stack dependency graphs. env0 wins on cost guardrails and self-service templates. HCP Terraform wins on Sentinel enforcement levels and private registry maturity. Pulumi wins on real programming languages and unit-testable infrastructure. Ansible wins on configuring machines that already exist.

The OpenTofu fork matters to compliance teams assessing license and vendor risk. HashiCorp moved Terraform from MPL 2.0 to the Business Source License on 10 August 2023 (HashiCorp). OpenTofu joined the Linux Foundation on 20 September 2023 (Linux Foundation), shipped 1.6.0 GA on 10 January 2024 (OpenTofu), and entered the CNCF Sandbox on 23 April 2025 (CNCF). IBM completed its $6.4 billion acquisition of HashiCorp on 27 February 2025 (IBM).

Qovery does not fit everywhere, and I would rather say it here than in a sales call. Qovery is not a general-purpose IaC replacement. It does not provision org accounts, network backbones or bespoke provider services. It manages Kubernetes clusters, application environments and databases inside your AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster.

It composes with the rest through the official Qovery Terraform provider, which works with OpenTofu too (Qovery docs). My default stack for a mid-size team under a compliance mandate: OpenTofu for accounts and networking, Spacelift or env0 for drift checks and policy gates, and Qovery for the clusters and environments on top, all inside your own cloud accounts. That covers provisioning, consistency and governance with two vendors and one open-source core.

How do you keep infrastructure identical across regions and providers after it is provisioned?

Consistency is a runtime property, so you need three things together: one parameterized definition, drift detection on a schedule or a continuous loop, and automatic reconciliation. Drop any one of them and manual replication comes back as manual repair.

One definition, many targets. Parameterize region and provider instead of forking the code: Terraform workspaces and variable sets, Spacelift stacks, env0 templates, Crossplane Compositions.

Drift detection cadence differs by tool, and the docs are specific:

• Crossplane reverts out-of-band changes to managed resources continuously, on a poll interval you can override per resource (Crossplane).
• Spacelift runs drift detection on cron rules you define, only on private workers, and triggers a tracked run to reconcile if you enable it (Spacelift docs).
• env0 runs drift checks on a cron expression, with a minimum interval of one day on Free and one hour on Enterprise, and offers automatic or manual remediation (env0 docs).
• Plain OpenTofu or Terraform surfaces drift only when someone runs a plan.

Promotion has to be immutable. The same artifact and the same environment definition move from dev to staging to prod to the secondary region, and nobody edits them in place in a cloud console.

Version skew is drift too. Kubernetes ships a minor release roughly three times a year (Kubernetes), and each minor gets about 14 months of patches (Kubernetes patch releases). Amazon EKS gives 14 months of standard support, then 12 months of extended support at $0.60 per cluster-hour instead of $0.10 (AWS EKS pricing). GKE charges the same $0.60 total for its Extended channel past 14 months (Google Cloud). AKS long-term support requires the Premium tier (Microsoft).

A cluster left on EKS 1.34 in one region after its standard support ends on 2 December 2026 (AWS) costs six times the control-plane fee of its upgraded twin. That is drift with an invoice attached.

Qovery handles the consistency part for clusters and environments. You can clone an environment to a different project or a different cluster (Qovery docs), so the secondary in another cloud comes from the same definition. Qovery tests each new Kubernetes version internally for a month and rolls upgrades out over three weeks (Qovery clusters). Deployment rules stop non-production copies on a schedule, such as nights and weekends (Qovery deployment rules), which matters for copies that exist only for resilience testing.

A checklist you can lift:

• Per deploy: application config, environment variables, image tags, and policy checks on the plan.
• Weekly: scheduled drift detection on every stack in every region, plus a diff of IAM and network rules.
• Per quarter: Kubernetes, database engine and base image versions across all regions, plus a failover test.

How do you enforce governance and compliance across multiple clouds without slowing teams down?

Governance works when policy runs before the apply: policy-as-code gates between plan and apply, per-environment RBAC, immutable audit logs and automated evidence collection. A policy that fails in CI costs minutes, and one that fails in an audit costs quarters.

Policy engines run at different points:

• Spacelift evaluates OPA/Rego policies on plans, approvals, pushes and triggers (Spacelift policies).
• env0 evaluates OPA approval policies after the plan and cost estimation steps, and can block deployments that exceed cost thresholds (env0 approval policies).
• HCP Terraform runs Sentinel or OPA after plan and before apply. Sentinel has three enforcement levels: advisory (may fail), soft-mandatory (must pass unless overridden) and hard-mandatory (must pass) (HashiCorp Sentinel).
• Kyverno and OPA Gatekeeper enforce at Kubernetes admission, which is where Crossplane-managed resources get checked. Kyverno graduated in the CNCF on 16 March 2026 (CNCF), and OPA graduated in January 2021 (CNCF).

What I would encode first: allowed regions and providers, allowed instance families, mandatory encryption at rest, mandatory tags, no public ingress on data stores, and a cost ceiling per environment.

Separation of duties comes next. Decide who can plan and who can apply, scope RBAC per environment, and make break-glass access write to an immutable audit trail.

The evidence an auditor accepts is a log of every change: who approved it, which policy it passed, and when. That maps to the change-management criterion CC8.1 in the AICPA Trust Services Criteria behind SOC 2, and to the change management and logging controls in ISO/IEC 27001 Annex A. No tool makes you certified. Tools produce the evidence your auditor tests.

The regulatory driver behind many multi-provider mandates is DORA, Regulation (EU) 2022/2554, which applies from 17 January 2025 (EUR-Lex). Article 28(8) requires exit strategies for ICT services supporting critical or important functions, Article 29 covers ICT concentration risk, and Article 26 sets out threat-led penetration testing for EU financial entities.

Getting this wrong is expensive. The global average cost of a data breach reached $4.99 million in 2026 (IBM, Cost of a Data Breach 2026). In IBM's 2024 edition, 40% of breaches involved data stored across multiple environments, and those cost more than $5 million on average and took 283 days to identify and contain (IBM, 2024). Misconfiguration accounted for 29.4% of cloud initial access in H1 2025 and 21% in H2 2025 (Google Cloud Threat Horizons H1 2026).

BYOC matters under a compliance mandate. With Qovery, workloads and data stay in your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, under your own data-residency terms, cloud contracts and committed-spend discounts. Custom roles scope access per project and per environment type (Qovery RBAC), and audit logs record who did what, where and when. Retention runs up to 30 days on the Business plan, so export them to your SIEM for the full audit period.

What does a realistic multi-cloud setup actually look like in practice, and what does it cost?

Most teams that satisfy a multi-cloud mandate do not run one workload across three clouds at once. They keep one environment definition that can be instantiated on any of them, with one primary, a provable secondary and a failover tested on a schedule. True active-active across providers multiplies egress, duplicated managed services and on-call expertise.

Three patterns cover almost every mandate I see:

• Multi-region active-passive: one provider, a warm or cold secondary region. Justified for most availability targets.
• Multi-region active-active: one provider, traffic in both regions. Justified when a regional outage would breach an SLA you signed.
• Multi-provider: a second cloud, usually passive. Justified by regulation such as DORA or by vendor-concentration risk.

Egress is where active-active hurts. AWS charges $0.09 per GB to the internet after 100 GB free per month and $0.02 per GB between most regions (AWS EC2 pricing). Google Cloud Premium Tier charges $0.12 per GiB to the internet and $0.02 per GiB between regions on the same continent, rising to $0.05 between North America and Europe (Google Cloud network pricing). Azure charges $0.087 per GB from North America and Europe to the internet and $0.02 per GB between regions within a continent (Azure bandwidth pricing). Scaleway charges no egress fees for most services, including Object Storage and Kubernetes (Scaleway).

Exit costs are falling. The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025, and from 12 January 2027 providers may not charge switching fees at all (EUR-Lex). Google Cloud (January 2024), AWS (March 2024) and Azure (March 2024) already waive egress for customers leaving.

Benchmark your mandate against the market: 73% of organizations run hybrid estates, and only 14% run exclusively multi-cloud without a private cloud (Flexera 2026 State of the Cloud).

The pragmatic middle ground is a provider-agnostic application layer on Kubernetes with a provider-specific data layer. Failover then becomes a deploy plus a data restore, with no rewrite in the middle.

The reference stack I would copy: OpenTofu for accounts, networking and foundational resources; Spacelift or env0 for drift detection and policy gates; Qovery for the Kubernetes clusters and application environments on top, inside your own accounts. Provisioning, consistency and governance each have an owner.

Then test the failover on a schedule. A resilience plan nobody has executed is a document, and auditors increasingly ask for the test evidence instead of the plan. For a broader tool survey, see multi-cloud deployment automation tools compared.

How do I do this with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to provision or replicate an environment in your own cloud account. Every action is scoped, shown to you, and approved before anything runs.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scoped to this project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Qovery MCP Server in Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want it (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-terraform, qovery-preview, qovery-optimize, qovery-troubleshoot, qovery-speedup) handle setup and deploys, and the MCP Server operates what already exists.

Then ask, for example: "replicate this environment into my GCP cluster in europe-west1 with the same configuration as production". The agent proposes each step and waits for your approval. See the AI agent quickstart and the Claude Code integration.