This chapter covers multi-cloud strategy, an important concept in the Cloud Concepts domain of AZ-900. You will learn what multi-cloud means, why organizations adopt it, how it differs from hybrid cloud, and the key considerations for managing multiple cloud providers. This objective area (Cloud Concepts) typically carries 25-30% of the exam weight, and multi-cloud questions often appear as scenario-based items testing your ability to distinguish multi-cloud from hybrid cloud and to identify benefits and challenges.
Jump to a section
Imagine you run a chain of restaurants that needs to serve customers 24/7. You have your own central kitchen (on-premises data center) that handles most orders, but during peak hours you also use a cloud kitchen service (Azure) for extra capacity. Now, to reduce risk and get better deals, you decide to also partner with another cloud kitchen service (AWS) and a local catering company (Google Cloud). This is a multi-cloud strategy. Each kitchen has its own recipes, pricing, and delivery routes. Your job is to coordinate orders across all kitchens so that customers get their meals on time, even if one kitchen has a fire or runs out of ingredients. You use a central order management system (multi-cloud management tools) that knows each kitchen's menu, current stock, and delivery times. If Azure kitchen is overloaded, the system automatically routes orders to AWS. If AWS has a power outage, orders go to Google. The challenge is that each kitchen uses different ovens and ingredient suppliers, so your management system must translate orders into each kitchen's format. This is exactly how a multi-cloud strategy works: you use multiple public cloud providers to avoid vendor lock-in, improve resilience, and optimize costs, but you need specialized tools to manage the complexity of different APIs, security models, and pricing structures.
What is Multi-Cloud Strategy?
Multi-cloud strategy refers to the deliberate use of two or more public cloud computing services from different providers (e.g., Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP)) to meet an organization's IT needs. Unlike hybrid cloud, which combines a public cloud with a private cloud (on-premises), multi-cloud involves multiple *public* clouds. The key business problem it solves is reducing dependency on a single vendor, which can lead to vendor lock-in, higher costs, or limited innovation. By using multiple providers, organizations can choose the best services from each, negotiate better pricing, and ensure higher availability.
How Multi-Cloud Works – Step by Step
Assessment and Planning: An organization evaluates its workloads and identifies which cloud provider offers the best services for each workload. For example, a company might use Azure for its Active Directory integration and AI services, AWS for its extensive compute options, and GCP for its data analytics tools.
Architecture Design: The IT team designs a distributed architecture where different applications or components run on different clouds. This often involves using containers (e.g., Kubernetes) to abstract the underlying infrastructure, making it easier to move workloads between clouds.
Connectivity Setup: To ensure low-latency communication between clouds, organizations set up dedicated network connections (e.g., Azure ExpressRoute, AWS Direct Connect) or use VPNs. They also implement a centralized identity management system (e.g., Azure AD with federation) so users can access resources across clouds with a single set of credentials.
Management and Monitoring: Specialized multi-cloud management platforms (e.g., Azure Arc, VMware CloudHealth) provide a unified view of resources across clouds. They enable cost tracking, security policy enforcement, and performance monitoring from a single pane of glass.
Data Synchronization: For applications that need consistent data across clouds, organizations set up data replication using tools like Azure Data Factory or cloud-to-cloud replication services. This ensures that if one cloud fails, another can take over with minimal data loss.
Key Components of Multi-Cloud
Multiple Public Cloud Providers: At least two of the major cloud providers (Azure, AWS, GCP) or smaller ones.
Unified Management Tools: Solutions like Azure Arc extend Azure management to resources running on other clouds. For example, Azure Arc allows you to manage Kubernetes clusters running on AWS or GCP as if they were Azure resources.
Identity Federation: A single identity provider (e.g., Azure Active Directory) that authenticates users across all clouds.
Networking Interconnects: High-speed connections between clouds to reduce latency and ensure secure data transfer.
Cost Optimization Tools: Services like Azure Cost Management + Billing that can track spending across multiple clouds.
Pricing Models in Multi-Cloud
Each cloud provider has its own pricing model. Azure uses pay-as-you-go, reserved instances, and spot VMs. AWS has similar options. In a multi-cloud strategy, organizations must compare costs across providers for each workload. Tools like Azure Cost Management can ingest AWS cost data to provide a unified view. However, transferring data between clouds (egress fees) can be significant, so organizations must account for these costs.
Comparison to On-Premises Equivalent
In a traditional on-premises environment, all hardware is owned and managed by the organization. There is no concept of multiple providers because the organization controls everything. Multi-cloud is the opposite: it uses external providers, and the organization must manage the complexity of different APIs, security models, and billing systems. The advantage is that the organization is not locked into a single vendor and can leverage the best of each cloud.
Azure Portal and CLI Touchpoints
Azure Portal: Navigate to "Azure Arc" to see resources from other clouds. Use "Cost Management + Billing" to view multi-cloud costs.
Azure CLI: Use commands like az connectedmachine connect to onboard an AWS EC2 instance to Azure Arc.
PowerShell: New-AzConnectedMachine registers a non-Azure machine for management.
ARM Templates: Deploy Azure Arc agents to other clouds using templates.
For example, to connect an AWS EC2 instance to Azure Arc using CLI:
az connectedmachine connect --name myAwsVM --resource-group myRG --location eastusThis command installs the Azure Connected Machine agent on the AWS VM, allowing Azure to manage it.
Concrete Business Scenarios
Scenario 1: A retail company uses Azure for its e-commerce platform because of its AI recommendation engine and AWS for its inventory management due to AWS's DynamoDB. The company uses Azure Arc to manage both environments from a single console.
Scenario 2: A financial services firm uses Azure for its primary workloads but has a disaster recovery site on GCP to avoid vendor lock-in. They use Azure Site Recovery to replicate VMs to GCP.
Scenario 3: A startup uses AWS for compute and Azure for Office 365 integration. They use a third-party multi-cloud management tool to monitor costs and security across both clouds.
What Goes Wrong When Set Up Incorrectly
Security Gaps: Inconsistent identity management can lead to unauthorized access.
Cost Overruns: Without unified cost tracking, organizations may overspend on egress fees.
Performance Issues: Poor network connectivity between clouds can cause latency.
Compliance Violations: Data may be stored in regions that violate regulations if not properly managed.
Assess Workload Requirements
Begin by evaluating each application or workload to determine its specific needs: compute, storage, networking, compliance, and cost constraints. For example, a workload requiring GPU compute might be best on AWS, while one needing tight integration with Office 365 might go to Azure. Document these requirements in a workload analysis spreadsheet. This step is critical because it drives all subsequent decisions. Without a clear assessment, you risk placing workloads on clouds that don't meet their needs, leading to poor performance or high costs.
Select Cloud Providers
Based on the assessment, choose two or more public cloud providers that best match the workload requirements. For instance, you might select Azure for its AI services and AWS for its serverless offerings. Consider factors like geographic presence, service maturity, and pricing. It's common to start with two providers to avoid complexity. Ensure each provider offers the services you need in the regions you operate. This step sets the foundation for the multi-cloud architecture.
Design Connectivity and Identity
Set up secure, high-speed connections between clouds using services like Azure ExpressRoute or AWS Direct Connect. Also, implement identity federation so that users can log in once and access resources across all clouds. For example, use Azure AD as the identity provider and configure federation with AWS IAM. This step is crucial for seamless user experience and security. Without proper connectivity, data transfer between clouds can be slow and expensive.
Deploy Unified Management Tools
Use tools like Azure Arc to manage resources across clouds from a single control plane. Install the Azure Connected Machine agent on non-Azure VMs (e.g., AWS EC2) to enable Azure management. This allows you to apply Azure policies, monitor performance, and track costs centrally. For example, you can enforce that all VMs, regardless of cloud, must have a specific tag. Without unified management, you'll have to log into each cloud's portal separately, increasing operational overhead.
Implement Data Replication and DR
For critical workloads, set up data replication between clouds to ensure high availability and disaster recovery. Use services like Azure Site Recovery or native replication tools. For example, replicate Azure VMs to AWS for failover. This step ensures that if one cloud goes down, the other can take over with minimal data loss. Without it, you risk extended downtime and data loss during a provider outage.
Scenario 1: E-commerce Company with Seasonal Spikes
An online retailer uses Azure for its main e-commerce platform because of Azure's AI recommendation engine and Cosmos DB for global distribution. However, during Black Friday, they need additional compute capacity. They also use AWS for burst compute with EC2 Spot Instances to handle traffic spikes cost-effectively. The team uses Azure Arc to manage both environments, applying consistent tagging and security policies. They also use Azure Traffic Manager to route traffic between Azure and AWS based on latency. Common issues: if the cost management tool is not configured to track AWS spending, they might overspend on spot instances. Also, if data synchronization between Azure SQL Database and AWS RDS is not set up correctly, the recommendation engine might serve outdated products.
Scenario 2: Financial Services Firm with Compliance Requirements
A bank uses Azure for its customer-facing applications because of Azure's compliance certifications (e.g., SOC 2, PCI DSS). However, they also use GCP for its big data analytics tools to analyze transaction patterns. They implement identity federation using Azure AD, so employees can access GCP resources with their corporate credentials. They use a third-party multi-cloud security tool to ensure consistent firewall rules. Cost considerations: egress fees from GCP to Azure can be high, so they optimize data transfer by using compression. What goes wrong: if the identity federation is misconfigured, users might be locked out of GCP, or worse, unauthorized access could occur.
Scenario 3: Startup with Limited Budget
A startup uses AWS for its core compute because of AWS's free tier and extensive documentation. Later, they need Office 365 integration for email and collaboration, so they adopt Azure. They use Azure Cost Management to track spending across both clouds and set budgets. They also use Azure Policies to enforce tagging standards. Common mistakes: they might not account for data transfer costs between AWS and Azure, leading to unexpected bills. Also, without a unified management tool, they might miss security alerts from one cloud.
What Goes Wrong When Set Up Incorrectly
Security Gaps: Inconsistent identity management can lead to unauthorized access. For example, if Azure AD is not federated with AWS IAM, users may have separate passwords, increasing the risk of credential theft.
Cost Overruns: Without unified cost tracking, organizations may overspend on egress fees. For instance, moving large datasets between clouds can cost thousands of dollars monthly.
Performance Issues: Poor network connectivity between clouds can cause latency. If ExpressRoute is not set up, data transfer over the public internet may be slow and unreliable.
Compliance Violations: Data may be stored in regions that violate regulations if not properly managed. For example, a European company might accidentally store data in a US region on GCP.
Exactly What AZ-900 Tests
The objective code for this topic is "Describe cloud concepts" and specifically under "1.3 Describe the benefits of cloud services". The exam may ask you to identify a multi-cloud strategy in a scenario. You will need to distinguish multi-cloud from hybrid cloud and from a single-cloud strategy. Common question: "A company uses Azure for some workloads and AWS for others. This is an example of which type of cloud strategy?" Answer: Multi-cloud.
Common Wrong Answers and Why Candidates Choose Them
Hybrid Cloud: Candidates often confuse multi-cloud with hybrid cloud. They see multiple environments and think "hybrid." But hybrid cloud specifically involves a mix of public and private (on-premises) cloud. Multi-cloud involves multiple public clouds.
Single Cloud: Some candidates think using multiple providers is not a strategy; they think it's just separate deployments. But the deliberate use of multiple public clouds is a recognized strategy.
Community Cloud: This is a different concept (shared infrastructure for several organizations). Candidates might pick this because it involves multiple entities.
No Strategy: Some think multi-cloud is just accidental. The exam tests that it is a deliberate strategy.
Specific Terms and Values
Multi-cloud: Use of two or more public cloud providers.
Hybrid cloud: Combination of public and private cloud.
Azure Arc: Microsoft's tool for managing resources across clouds.
Vendor lock-in: A key reason to adopt multi-cloud.
Egress fees: Data transfer costs between clouds.
Edge Cases and Tricky Distinctions
Multi-cloud vs. Hybrid cloud: The exam loves to present a scenario where a company uses Azure and also has on-premises servers. That is hybrid cloud, not multi-cloud. If the scenario says Azure and AWS, it's multi-cloud.
Multi-cloud vs. Polycloud: Some vendors use "polycloud" to mean using multiple clouds for different purposes. The exam uses "multi-cloud."
Accidental multi-cloud: If a company uses multiple clouds without planning, it's still multi-cloud, but the strategy is intentional.
Memory Trick
Use the acronym "M.A.H." - Multi-cloud = Multiple public clouds (Azure, AWS, GCP). Hybrid = Public + Private (on-premises). If you see "on-premises" in the scenario, it's hybrid. If you see two or more public cloud names, it's multi-cloud.
Decision Tree
Does the scenario mention on-premises data centers? Yes → Hybrid cloud. No → Go to 2.
Does the scenario mention two or more public cloud providers? Yes → Multi-cloud. No → Single cloud.
Multi-cloud strategy uses two or more public cloud providers (e.g., Azure, AWS, GCP) to avoid vendor lock-in and leverage best-of-breed services.
Multi-cloud is different from hybrid cloud, which combines public and private cloud.
Azure Arc is a key Azure service for managing resources across multiple clouds.
Common challenges include increased complexity, data transfer costs (egress fees), and security management.
The exam tests your ability to identify multi-cloud in scenarios and distinguish it from hybrid cloud.
Vendor lock-in is a primary reason organizations adopt multi-cloud.
Unified management tools like Azure Arc and third-party solutions are essential for effective multi-cloud operations.
These come up on the exam all the time. Here's how to tell them apart.
Multi-Cloud Strategy
Uses two or more public cloud providers (e.g., Azure + AWS).
No on-premises infrastructure required.
Reduces vendor lock-in by distributing workloads.
Requires multi-cloud management tools like Azure Arc.
Data transfer between clouds incurs egress fees.
Hybrid Cloud Strategy
Combines public cloud with private (on-premises) cloud.
On-premises infrastructure is a key component.
Provides consistency between on-prem and cloud (e.g., Azure Stack).
Uses tools like Azure Site Recovery for DR.
Data transfer between on-prem and cloud may have lower latency if connected via ExpressRoute.
Mistake
Multi-cloud is the same as hybrid cloud.
Correct
Multi-cloud involves multiple public cloud providers, while hybrid cloud combines a public cloud with a private (on-premises) cloud. They are distinct strategies.
Mistake
Using multiple clouds automatically means you have a multi-cloud strategy.
Correct
A multi-cloud strategy is deliberate and planned. Simply using multiple clouds without coordination is often called 'accidental multi-cloud' and lacks the benefits of a true strategy.
Mistake
Multi-cloud eliminates all vendor lock-in.
Correct
Multi-cloud reduces vendor lock-in but does not eliminate it entirely. Each provider has proprietary services and APIs, so moving workloads between clouds can still be complex and costly.
Mistake
Azure Arc only manages Azure resources.
Correct
Azure Arc can manage resources outside Azure, including servers on AWS, GCP, and on-premises. It extends Azure management to any infrastructure.
Mistake
Multi-cloud always costs less than using a single cloud.
Correct
Multi-cloud can increase costs due to data transfer (egress) fees, management overhead, and the need for specialized tools. It can be cost-effective if you leverage each cloud's strengths, but it requires careful planning.
Multi-cloud involves using multiple public cloud providers (e.g., Azure and AWS). Hybrid cloud combines a public cloud with a private (on-premises) cloud. The key differentiator is the presence of on-premises infrastructure. If the scenario includes on-premises, it's hybrid; if it includes multiple public clouds, it's multi-cloud.
Companies adopt multi-cloud to avoid vendor lock-in, use the best services from each provider, improve resilience (if one cloud fails, another takes over), and optimize costs by choosing the most cost-effective provider for each workload. It also allows them to negotiate better pricing.
Azure Arc is a service that extends Azure management to any infrastructure, including servers running on AWS, GCP, or on-premises. It allows you to manage resources across clouds using Azure tools like Azure Policy, Azure Monitor, and Azure Security Center, providing a unified control plane.
Challenges include increased complexity in management, higher data transfer costs (egress fees), inconsistent security policies across providers, and the need for specialized skills. Without proper tools, organizations may face cost overruns and security gaps.
Yes, through Azure Arc, you can manage AWS EC2 instances as if they were Azure resources. You install the Azure Connected Machine agent on the AWS VM, and then you can apply Azure policies, monitor performance, and more.
Not necessarily. Multi-cloud can be cost-effective if you use each provider's strengths (e.g., using AWS Spot Instances for cost savings). However, data transfer fees and management overhead can increase costs. It requires careful planning and cost monitoring.
Vendor lock-in is when an organization becomes dependent on a single cloud provider's proprietary services, making it difficult and expensive to switch. Multi-cloud reduces lock-in by distributing workloads across providers, so you are not tied to one vendor's ecosystem.
You've just covered Multi-Cloud Strategy — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?