By the Cycloid Platform Engineering team, practitioners building and operating enterprise IDPs since 2015.

Last updated: Q1 2026 – Refreshed with the 3 provisioning approaches, current tools comparison, and IDP-native positioning.

Cloud provisioning is the automated process of setting up and configuring cloud infrastructure resources – virtual machines, containers, databases, networks, and storage – on demand, across one or more cloud providers. It can be done manually (cloud console/CLI), through Infrastructure as Code (Terraform, Pulumi, Ansible), or via an Internal Developer Platform that provides self-service provisioning with policy guardrails built in. IDP-native provisioning is the most scalable approach for multi-cloud organisations, eliminating per-provider configuration overhead.

Cloud provisioning is one of the most searched terms in platform engineering, and one of the least well-defined. Vendors use it to mean different things at different layers of the stack. This guide sets a clear definition, walks through the three main approaches teams use today, compares the leading tools, and closes with the practical difference between IaC-only provisioning and an Internal Developer Platform that includes provisioning as one capability among many.

Cloud Provisioning: A Working Definition

Cloud provisioning is the process by which cloud resources are created, configured, and made ready for use. Historically, provisioning meant a system administrator clicking through the AWS or Azure console to spin up a virtual machine, attach storage, and configure networking. In 2026, provisioning at any real scale is automated, declared through code, and executed through a pipeline that also handles policy checks, cost estimates, and audit logs.

The scope is broader than just compute. A single cloud provisioning event typically creates or modifies:

• Compute resources (EC2 instances, Azure VMs, GKE nodes, containers)
• Storage (S3 buckets, Azure Blob, GCS, block volumes, databases)
• Network (VPCs, subnets, security groups, load balancers, VPN)
• Identity (IAM roles, service accounts, RBAC bindings)
• Application-level services (message queues, cache, secrets, monitoring)

Provisioning is distinct from configuration management (which handles what happens inside the VM after it exists) and from orchestration (which handles how multiple resources are coordinated together). The line between these gets blurry in practice – modern tools often cover more than one layer.

The 3 Cloud Provisioning Approaches

Every organisation running cloud workloads picks one of three approaches, or a combination of them.

1. Manual Provisioning (Console + CLI)

Engineers use the cloud provider console (AWS Console, Azure Portal, GCP Console) or command-line tools (aws, az, gcloud) to create resources one at a time. This is how everyone starts and how most small teams still operate for one-off tasks.

Strengths: fastest to start, no tooling investment, works for exploratory or ad-hoc work.

Weaknesses: not reproducible, no audit trail, no policy enforcement, impossible to scale beyond a handful of environments. Every manual change is a source of configuration drift and a compliance headache.

Best for: prototypes, individual learning, emergency changes when everything else is broken. Not viable as a production strategy.

2. Infrastructure as Code (IaC)

Resources are declared in code (Terraform HCL, Pulumi Python/TypeScript, Ansible YAML, AWS CloudFormation JSON/YAML) and applied through a CLI or CI/CD pipeline. IaC is the industry-standard approach in 2026 – the CNCF 2024 State of Cloud Native Development put Terraform adoption at roughly 58% of teams using IaC.

Strengths: reproducible, version-controlled, reviewable through pull requests, integrates with CI/CD, works across providers with the right provider modules.

Weaknesses: each cloud requires its own configuration, IaC alone does not enforce policy or estimate cost, the platform team owns pipeline maintenance forever, and application developers still cannot self-serve without either learning the IaC tool or opening a ticket.

Best for: teams with a dedicated platform engineering function that maintains IaC modules, particularly single-cloud teams or teams comfortable with per-provider configuration.

3. IDP-Native Provisioning

An Internal Developer Platform sits above the IaC layer, exposing self-service templates through a portal. Application developers request a resource through a form; the platform maps the form to IaC variables and runs the underlying Terraform, OpenTofu, Pulumi, or Helm. Policy checks (Policy as Code), pre-deployment cost estimation, and audit logging all happen automatically.

Strengths: developers self-serve without learning IaC, platform team enforces guardrails without gating every ticket, multi-cloud abstraction handled by the platform, cost and compliance built in from day one.

Weaknesses: platform investment cost, dependency on the vendor for orchestration depth, less flexible for highly bespoke provisioning workflows.

Best for: organisations with 50+ engineers, multi-cloud footprint, or a platform team that wants to remove itself from the critical path of every change. See our developer self-service portal analysis for the deeper mechanics.

Cloud Provisioning Tools Comparison

The five most-shortlisted tools in 2026, scored across the four criteria that matter for multi-cloud teams.

The honest read: Terraform, OpenTofu, and Pulumi are the raw IaC tools most enterprise platform teams standardise on. AWS CloudFormation is the AWS-native default but locks the team into one cloud. Cycloid does not replace those tools – it sits above them, providing the self-service portal, cost estimation, multi-tenancy, and policy layer that IaC alone does not deliver.

For deeper coverage of the IaC pipeline layer specifically, see our Terraform CI/CD and compliance guide.

How IDP-Native Provisioning Differs from IaC-Only

The most useful way to understand IDP-native provisioning is by what it removes from the platform team’s day-to-day workload.

Ticket removal. With IaC alone, application developers either learn HCL or open tickets. IDP-native provisioning through a self-service portal like Cycloid’s StackForms removes the ticket entirely – developers fill in a form, the platform generates the IaC variables, and the pipeline runs.

Multi-cloud abstraction. With IaC, each cloud provider has its own Terraform module structure, its own variable conventions, and its own state file. Application developers see this complexity. With an IDP, they see one form regardless of which cloud is being provisioned; the platform team maintains the per-cloud modules once, in one place.

Cost and policy at the point of decision. With IaC alone, a developer’s plan produces a diff of resources to be created. Whether that diff costs $50 or $50,000 a month is discoverable only by running it. IDP-native provisioning surfaces the cost estimate (via pre-deployment cost estimation) and policy result in the merge request, before the apply runs. This is one of the fastest-to-measure ROI arguments for an IDP.

Audit and multi-tenancy for free. With IaC, audit logging is something the platform team builds. Multi-tenancy is something the platform team builds. Both come standard with an IDP-native provisioning layer.

See the broader cloud management platform context for how provisioning fits alongside inventory, cost, and governance in a mature setup.

Cloud Provisioning Best Practices in 2026

• Start with IaC as the source of truth. Even if the IDP eventually generates the IaC, the IaC files remain reviewable, version-controlled, and portable.
• Enforce policy at the pipeline layer, not in review. Policy as Code (InfraPolicies, Sentinel, OPA) catches violations before humans have to.
• Estimate cost pre-deploy. Cost visibility after the invoice is not cost management. It is cost reporting.
• Tag everything at provisioning time. Tagging retrofit projects are the second-most-hated exercise in platform engineering. Enforce tags in the provisioning template, not after the fact.
• Track platform adoption alongside provisioning velocity. A fast pipeline that nobody uses is not a win. See the platform engineering metrics guide for the ratio of self-serviced provisioning to ticket-driven provisioning.

FAQ

What is cloud provisioning?
Cloud provisioning is the automated process of setting up and configuring cloud infrastructure resources – virtual machines, containers, databases, networks, and storage – on demand, across one or more cloud providers. It can be done manually (cloud console or CLI), through Infrastructure as Code (Terraform, Pulumi, Ansible), or via an Internal Developer Platform that provides self-service provisioning with policy guardrails built in. IDP-native provisioning is the most scalable approach for multi-cloud organisations.

What are the main cloud provisioning approaches?
Three main approaches. (1) Manual provisioning through the cloud console or CLI – fastest to start, impossible to scale beyond a few environments. (2) Infrastructure as Code (Terraform, OpenTofu, Pulumi, Ansible) – reproducible and version-controlled, but each cloud requires its own configuration and the platform team owns all pipeline maintenance. (3) IDP-native provisioning – self-service templates that abstract multi-cloud complexity, apply policy guardrails automatically, and let developers provision without opening tickets.

What are the best cloud provisioning tools in 2026?
The leading cloud provisioning tools in 2026 depend on the layer of abstraction needed. For raw IaC: Terraform (dominant, ~58% market share per CNCF 2024), OpenTofu (OSS Terraform fork), Pulumi (general-purpose languages), Ansible (config-focused), AWS CloudFormation (AWS-only). For self-service provisioning above IaC: Cycloid (IDP-native, multi-cloud, multi-tenant), Humanitec, Port, Roadie. Most enterprises combine one IaC tool with an IDP that orchestrates it.

What is the difference between cloud provisioning and cloud orchestration?
Cloud provisioning is the act of creating and configuring individual cloud resources. Cloud orchestration is the coordination of those resources into working systems – handling dependencies, sequencing, rollbacks, and lifecycle management. Provisioning creates a VM; orchestration ensures the VM is created in the right order alongside the database and network it depends on, with health checks and rollback if anything fails. Modern IDPs like Cycloid do both from one platform.

See Cycloid’s IDP-native cloud provisioning in action – multi-cloud self-service with pre-deployment cost estimation and policy guardrails built in.

Book a demo