Multi-Cloud Management: Identity, Inventory and Power States
Running on two or three clouds is easy. Operating them as one estate means reconciling how each one authenticates, lists resources, and turns things off.
Multi-cloud management is operating infrastructure across two or more cloud providers with shared processes: one way to grant access, one inventory, one set of policies, and one view of cost. The providers do not make this easy, because each has its own identity system, its own resource model, and its own definition of common operations. This guide covers the layers that have to line up, and where their differences bite. For the cost side specifically, see multi-cloud cost strategy.
Layer 1: identity and access
Every tool that touches more than one cloud needs credentials for each. The safest pattern is the same on all three providers: federation instead of stored secrets.
- AWS recommends not storing long-term AWS credentials in applications outside AWS, and instead using OIDC federation to request temporary credentials mapped to a role with only the permissions required.
- Google Cloud Workload Identity Federation lets external workloads access resources without a service account key, removing the security burden that keys carry.
- Microsoft Entra workload identity federation gives access to Entra-protected resources without managing secrets.
Pair federation with least privilege per task: a read role for inventory and cost, and a separate, narrower write role for actions such as start and stop.
Layer 2: inventory
Each provider has a native cross-service inventory: AWS Resource Explorer for search and discovery, Google Cloud Asset Inventory for resource metadata, and Azure Resource Graph for querying resources at scale across subscriptions. They return different shapes, use different type names, and model hierarchy differently (accounts, projects, and subscriptions with resource groups). A multi-cloud inventory maps these into one resource model with common fields: provider, account, region, type, status, owner, and tags.
Layer 3: operations that sound the same
“Stop” is the clearest example of a shared verb with different effects:
| Provider | Operation | What stops billing | What keeps billing |
|---|---|---|---|
| AWS EC2 | StopInstances (EBS-backed only) | instance usage and data transfer | EBS volumes, Elastic IPs; instance store data is erased |
| Compute Engine | instances.stop | VM usage | persistent disks and static IP addresses |
| Azure VM | Deallocate | compute | disks and networking |
| Azure VM | Power off | nothing for compute; still charged | everything |
A policy that says “stop dev VMs at night” is only correct on Azure if it deallocates. Managed databases differ again: RDS restarts a stopped instance after seven consecutive days, Cloud SQL stops by activation policy, and Azure SQL Database only pauses in the serverless tier.
Layer 4: policy and metadata
Tags and labels carry the ownership that policies depend on, and each provider restricts them differently (see cloud tagging best practices). Enforcement tools differ too: AWS Organizations tag policies and IAM conditions, Azure Policy, and provisioning-time checks on Google Cloud.
How ZopNight approaches it
ZopNight connects AWS accounts through a keyless WIF assume-role (recommended), static keys, or temporary credentials; GCP projects through a one-click OAuth flow that provisions a managed service account, or a service account key; and Azure through a service principal or workload identity federation. Each account is read-only, which allows discovery and recommendations, or read and write, which adds start and stop and remediation; actions on read-only accounts are refused before any cloud call. Discovery uses Resource Explorer, Cloud Asset Inventory, and Resource Graph, and schedules handle provider-specific operations such as Azure deallocate versus stop. Related: multi-cloud cost strategy and RBAC.