Why MCM Orchestration
The problems with provisioning cloud infrastructure per provider and how MCM Orchestration solves them.
Why MCM Orchestration
Provisioning cloud infrastructure involves learning different tools for every provider — AWS CloudFormation, Azure Resource Manager, and Terraform each have their own syntax, state model, and workflow. Teams that operate across both AWS and Azure are effectively maintaining two separate IaC disciplines, with no shared plan-and-apply workflow, no unified drift detection, and no visibility into cost impact before a change is applied.
Challenges & How MCM Solves Them
Each challenge below is a real friction point teams face when provisioning infrastructure across providers without a unified layer.
1. Multiple Learning Curves
CloudFormation YAML, ARM JSON, and Terraform HCL are three distinct languages with different abstractions, state models, and debugging approaches. Teams must maintain expertise in all of them.
How MCM solves it: The same Stack → Workspace model handles AWS and Azure resources. Teams learn one interface and one workflow instead of maintaining expertise across multiple toolchains.
2. No Unified Workflow
Provisioning on AWS and Azure means navigating entirely different consoles, CLIs, and pipelines with no common interface or approval model.
How MCM solves it: MCM provides a single interface for defining, deploying, and managing infrastructure on both AWS and Azure. The same plan-and-apply workflow and execution history apply regardless of which provider a workspace targets.
3. Configuration Drift
Manual changes made in the cloud console are invisible to the IaC state. Over time, live infrastructure silently diverges from what the templates describe.
How MCM solves it: MCM runs scheduled drift checks comparing live cloud resources against recorded Terraform state. Any manual change outside MCM moves the Workspace to a Drifted status immediately, making divergence visible rather than silent.
4. No Structured Review
Changes go live as soon as apply is run. There is no built-in step to review a plan before resources are created or destroyed.
How MCM solves it: Every plan produces a reviewable diff showing resources to add, change, or destroy along with an estimated cost delta. Nothing is touched until someone reviews the pending plan and chooses to apply it.
5. No Cost Visibility
Provisioning a new environment gives no indication of what it will cost per month until the first bill arrives.
How MCM solves it: Before applying any change, MCM shows the estimated monthly cost delta, calculated from AWS and Azure's own published pricing, so teams make cost-aware decisions at provisioning time, not after the bill arrives.
6. Template Reuse Is Fragile
Reusing infrastructure patterns means copy-pasting files and adjusting variables manually, with no versioning or parameterisation model.
How MCM solves it: Infrastructure patterns are captured as versioned, parameterised Stacks. Deploy the same Stack to dev, staging, and production with different variable values — no copy-pasting, no manual variable editing.
7. No Audit Trail
Who ran what plan, when, and against which environment is not tracked in a centralised way.
How MCM solves it: Every init, plan, apply, and drift detection run is logged with who triggered it, when, duration, and outcome. A single execution history covers all Workspaces across both providers.
MCM vs Managing Infrastructure Individually
| Aspect | Individual Provider Tools | MCM Orchestration |
|---|---|---|
| Learning curve | CloudFormation + ARM Templates + Terraform | Single unified Stack → Workspace model |
| Template creation | Manual HCL/YAML/JSON authoring | Visual canvas, file upload, or AI-drafted Terraform |
| Multi-cloud workflow | Different tool per provider | One workflow for AWS and Azure |
| Cost visibility | Estimated in each console separately | Integrated cost delta shown before every apply |
| Drift detection | Manual or per-provider tooling | Scheduled and on-demand MCM drift detection |
| Change review | No built-in review step | Pending plans reviewed before you apply |
| Audit trail | Separate per provider | Unified execution history across all Workspaces |
| Template reuse | Copy-paste with manual variable editing | Versioned parameterised Stacks with variable groups |
Features
| Feature | Description |
|---|---|
| Stacks | Versioned, parameterised Terraform templates for common infrastructure patterns |
| Built-in Stacks | 21 pre-built templates for AWS and Azure resources (VPC, EC2, S3, VNet, VM, Storage Account, and more) |
| Stack and workspace access | Give individual users access to specific Stacks and Workspaces |
| AI-drafted Terraform | Ask the AI Assistant to draft a workspace or Terraform for you to review before anything is saved |
| Blueprint canvas | Visual drag-and-drop editor to place and connect AWS and Azure resources |
| File upload | Import existing .tf, .tfvars, or .zip files directly into a Stack |
| Workspaces | Live deployments of Stacks with full state, history, and variable values |
| Pending plans | Review add/change/destroy diffs and estimated cost delta before applying |
| Drift detection | Scheduled and on-demand detection when live resources diverge from Terraform state |
| Cost estimation | Estimated monthly cost delta, based on AWS and Azure pricing, shown before every apply |
| Execution history | Full audit log of every plan and apply with status, duration, and trigger |
| Terraform outputs | View output values (VPC IDs, IPs, endpoints) from the last successful apply |
| Auto-deprovision | Schedule automatic workspace deprovisioning on a cron schedule |
Standard AWS/Azure Templates (Stacks)
MCM ships with a library of 21 built-in Stacks covering the most common infrastructure patterns on AWS and Azure, including networking, compute, storage, and security building blocks. These are production-ready, parameterised Terraform templates that can be deployed immediately without writing any IaC.
AWS examples include VPCs, subnets, security groups, EC2 instances, EBS volumes and snapshots, S3 buckets, and key pairs. Azure examples include Virtual Networks, VMs, VM disks, network interfaces, Storage Accounts, and Resource Groups. Each template exposes a set of input variables (region, instance size, naming prefix, tags) that are filled in at workspace creation time.
What you get: Infrastructure that would take hours to author from scratch, ready to deploy in minutes. Standard patterns are consistent, tested, and follow provider best practices — reducing the risk of misconfiguration from copy-pasted templates.
Custom Stack & Workspace Based on IaC
Beyond the built-in library, MCM lets teams bring their own infrastructure definitions. A custom Stack can be created by:
- File upload — import existing
.tf,.tfvars, or a.ziparchive of a Terraform module - Writing directly — author or edit Terraform HCL in the built-in editor
You can also create a Workspace straight from the visual Blueprint canvas (see below) or from your own Terraform files.
Built-in Stacks are shared across the platform. You can also give specific users access to individual Stacks and Workspaces, rather than to everything in Orchestration.
Once a Stack is defined, any number of Workspaces can be created from it — each with its own variable values for different environments. Every workspace has full Terraform state, a plan/apply workflow with cost estimation, drift detection, and a complete execution history.
What you get: Your existing Terraform investment works inside MCM without migration. Teams that prefer a visual approach can use the canvas. Either way, every deployment gets the same plan review, cost visibility, and audit trail.
AI Based Workspace & Terraform Drafts
For teams who want to describe what they need rather than write it, the MCM AI Assistant can draft a Workspace and its Terraform for you. Describe the infrastructure in plain English — for example, "create a VPC with two public subnets and an S3 bucket for logs" — and the assistant prepares a draft for you to review. You can also use Generate with AI when working on Terraform files.
Nothing is saved until you have reviewed the draft, and the resulting Workspace goes through the same plan review as any other: inspect the plan, check the estimated cost delta, and apply. The AI step only replaces the authoring phase — it does not bypass any controls, and it works only inside your own access.
What you get: A path from idea to deployed infrastructure that requires no Terraform expertise for initial drafts. Teams can generate a working starting point, review it, and deploy — lowering the barrier to adopting IaC.
Drag-and-Drop Multi-Cloud Orchestration
MCM includes a visual Blueprint canvas for building infrastructure — no HCL or manual wiring required. When you create a Workspace, choose Blueprint Canvas, place resource blocks on the canvas, and draw connections between them.
Visual Canvas
Drag AWS and Azure resource blocks onto the canvas and connect them by drawing edges between ports. You work at the level of what connects to what, not how to express that in code.
What you get: A way to design infrastructure visually, making the structure immediately legible to anyone on the team — not just the engineer who wrote it.
Multi-Cloud Support
Mix AWS and Azure resources on a single canvas, so a design that includes an AWS VPC and an Azure VM lives in one place.
What you get: Multi-cloud design in one view, without separate tools for each provider.
Live Validation
As you draw connections, the canvas checks that the two resource types can be connected. Incompatible connections are rejected immediately with a message, instead of failing later during a plan.
What you get: Fast feedback during design so issues are caught at authoring time rather than mid-deployment, reducing wasted plan-apply cycles.