Hybrid and Multicloud Security

The Multicloud Reality

Almost no enterprise runs exclusively on a single cloud provider. The reasons are practical: acquisitions bring in AWS accounts, specific teams chose GCP for machine learning workloads, manufacturing plants still run on-premises servers that can’t move to the cloud, and regulatory requirements sometimes mandate data residency in specific locations.

The security challenge isn’t “how do I secure Azure” — it’s “how do I secure everything with a consistent baseline when my resources are scattered across four different environments.”

This is where Azure Arc and Defender for Cloud’s multicloud capabilities become architectural cornerstones.

Azure Arc: Projecting Resources into Azure

Azure Arc installs a lightweight agent (the Connected Machine agent for servers, or the Arc-enabled Kubernetes agent for clusters) on non-Azure resources. Once connected, these resources appear in the Azure portal with an Azure Resource Manager (ARM) identity.

This means you can:

• Apply Azure Policy to on-premises servers exactly as you would to Azure VMs
• Enable Defender for Cloud on AWS instances through the Arc agent
• Use Azure Monitor to collect logs from GCP workloads
• Manage SQL Server instances running anywhere as Arc-enabled SQL Server

Arc-enabled Resource Types

Arc-enabled servers — Physical or virtual machines running Windows or Linux, anywhere. Once the Connected Machine agent is installed, the server gets an ARM resource ID and can be managed through Azure. Guest configuration policies can audit OS settings, Defender for Endpoint can be deployed, and the server appears in your Defender for Cloud inventory.

Arc-enabled Kubernetes — Any CNCF-conformant Kubernetes cluster (EKS, GKE, on-prem, edge) can be connected to Azure. This enables Azure Policy for Kubernetes (Gatekeeper-based), GitOps configuration management, and Defender for Containers monitoring.

Arc-enabled SQL Server — SQL Server instances anywhere get Azure management capabilities: Azure Active Directory authentication, Microsoft Purview integration for data governance, and Defender for SQL threat detection.

Arc-enabled data services — Run Azure SQL Managed Instance or PostgreSQL Hyperscale on your own infrastructure, managed through Azure.

Defender for Cloud Multicloud Connectors

Defender for Cloud connects natively to AWS and GCP through cloud-specific connectors that don’t require Arc agents on every resource:

AWS Connector

The AWS connector uses an IAM role with read permissions to assess your AWS environment. It provides:

• CSPM for AWS — Assesses AWS resources against security benchmarks (mapped to MCSB)
• Defender for Servers on EC2 — Uses the Arc agent installed on EC2 instances for runtime protection
• Defender for Containers on EKS — Monitors Elastic Kubernetes Service clusters
• AWS-specific recommendations — S3 bucket public access, IAM policies, security groups

GCP Connector

Similarly, the GCP connector uses a service account to assess GCP resources:

• CSPM for GCP — Assesses Compute Engine, GKE, Cloud Storage against benchmarks
• Defender for Servers on GCE — Runtime protection for Compute Engine VMs
• Defender for Containers on GKE — Monitors Google Kubernetes Engine clusters

Azure-native vs Arc-enabled vs Third-party Multicloud Management

Aspect	Azure-native (Defender for Cloud)	Azure Arc + Defender for Cloud	Third-party Multicloud Tools
Coverage	Azure resources only	Azure + AWS + GCP + on-prem	Varies by vendor
CSPM	Full Azure MCSB assessment	MCSB mapped to AWS/GCP + on-prem policy	Vendor-specific benchmarks
Runtime protection	Defender plans for Azure workloads	Defender plans extend via Arc agent	Separate agent per vendor
Policy enforcement	Azure Policy native	Azure Policy via Arc for all environments	Vendor-specific policy engine
Single pane of glass	Azure portal for Azure only	Azure portal for everything	Vendor's console
Agent requirement	Some plans agentless	Connected Machine agent for servers	Typically requires agents
Identity integration	Entra ID native	Entra ID for Arc-managed resources	May require federation
Cost model	Per-resource Defender plans	Per-resource + Arc has no base cost	Vendor licensing
Best for	Azure-only organisations	Microsoft-centric multicloud/hybrid	Multi-vendor shops preferring vendor-neutral

Designing Unified Governance

The architectural challenge is creating a consistent security baseline across environments with fundamentally different management planes. Here’s the design pattern:

Layer 1: Visibility (Week 1-4)

• Deploy AWS and GCP connectors in Defender for Cloud
• Install Arc agents on critical on-premises servers
• Enable foundational CSPM for all connected environments
• Result: unified asset inventory and Secure Score across all environments

Layer 2: Assessment (Week 4-8)

• Enable Defender CSPM for attack path analysis across clouds
• Apply Azure Policy via Arc to on-premises servers
• Map all environments to a common compliance framework (e.g., MCSB)
• Result: consistent security recommendations regardless of hosting location

Layer 3: Protection (Week 8-12)

• Enable Defender for Servers on critical EC2 and GCE instances
• Enable Defender for Containers on EKS and GKE
• Deploy Defender for Endpoint across all servers via Arc
• Result: runtime threat detection everywhere

Layer 4: Response (Week 12+)

• Integrate all alerts into Microsoft Sentinel for unified SIEM/SOAR
• Create unified incident response playbooks
• Automate remediation through Logic Apps triggered by Defender alerts
• Result: single incident response workflow regardless of source cloud

🌐 Scenario: Elena Extends to AWS

Meridian Global Industries acquired a European subsidiary last year — and with it, 40 AWS accounts hosting manufacturing logistics systems. Elena needs to bring these under the same security umbrella as Meridian’s Azure estate.

“We’re not migrating to Azure,” Elena clarifies to Li Wei. “These AWS workloads serve European factories and they work well. But we need the same security visibility and baseline we have in Azure.”

Elena’s design:

Phase 1: Connect and assess. She configures the AWS connector in Defender for Cloud using an organisation-level CloudFormation StackSet. This creates the necessary IAM roles across all 40 accounts in one deployment. Within a day, AWS resources appear in Defender for Cloud’s asset inventory alongside Azure resources. The Secure Score now reflects both environments.

Phase 2: Protect critical workloads. The logistics application runs on 12 EC2 instances. Elena deploys the Arc agent and enables Defender for Servers Plan 2 on these instances. They now have the same EDR (Endpoint Detection and Response) capabilities as Meridian’s Azure VMs.

Phase 3: Unified policy. Elena applies the same Azure Policy definitions to Arc-enabled AWS servers that she uses for Azure VMs: audit for missing patches, deny public IP assignment, require specific tagging conventions.

When Marcus Chen asks “How secure is our AWS environment?”, Elena shows the same Defender for Cloud dashboard he’s already familiar with — one Secure Score, one set of recommendations, one attack path analysis that now spans both Azure and AWS.

🏛️ Scenario: Torres and the On-Premises Mandate

Commander Torres faces a constraint most commercial architects don’t: the Department of Federal Systems has servers in classified environments that cannot connect to the public cloud. But the agency still needs consistent security governance.

Torres designs a tiered approach:

Tier 1 — Azure-connected workloads: Standard Defender for Cloud with all Defender plans.

Tier 2 — On-premises servers with internet access: Arc-enabled servers connecting through an Azure Private Link scope. The Arc agent communicates through a private endpoint, so traffic never traverses the public internet. These servers get Azure Policy, Defender for Servers, and appear in the central Defender for Cloud dashboard.

Tier 3 — Air-gapped classified systems: No Arc agent possible. Torres designs a separate security monitoring solution using on-premises SIEM that exports sanitised compliance reports. These reports are manually reviewed alongside Defender for Cloud data.

“The goal isn’t to force everything into one tool,” Torres tells Colonel Reeves. “It’s to maximise consistent governance where technically possible and design compensating processes where it isn’t.”

Exam Strategy: Hybrid and Multicloud Questions

SC-100 loves to test multicloud scenarios because they require architectural thinking, not just product knowledge. Watch for these patterns:

• “Unified visibility across AWS and Azure” → Defender for Cloud with AWS connector. Not “migrate to Azure” — the question asks for visibility, not migration.
• “On-premises servers that need Azure management” → Azure Arc with the Connected Machine agent. If the question mentions network restrictions, look for Private Link scope.
• “Consistent policy across all environments” → Azure Policy applied through Arc. The key word is “consistent” — it implies a single policy engine, not multiple.
• “Kubernetes clusters in multiple clouds” → Arc-enabled Kubernetes for unified management.
• Don’t confuse connectors with Arc agents. AWS/GCP connectors provide CSPM (configuration assessment). Arc agents on individual VMs provide runtime protection (Defender plans). Questions may test whether you know when each is needed.
• Cost efficiency with multicloud: Defender for Cloud connectors are the CSPM tier cost. Defender plans on Arc-enabled servers are per-server. The exam may present cost-constrained scenarios where you must decide what to protect.

Question

What does Azure Arc actually do, and why does it matter for multicloud security?

Click or press Enter to reveal answer

Answer

Azure Arc installs a lightweight agent on non-Azure resources (servers, Kubernetes clusters, SQL instances) that gives them an Azure Resource Manager identity. This 'projects' the resource into Azure, enabling Azure Policy, Defender for Cloud, Azure Monitor, and other Azure management services to work on resources running in AWS, GCP, or on-premises — creating a single management plane for heterogeneous environments.

Click to flip back

Question

How does Defender for Cloud connect to AWS — via Arc agents or via a cloud connector?

Click or press Enter to reveal answer

Answer

Both, for different purposes. The AWS cloud connector uses IAM roles for agentless CSPM assessment of AWS resources (configuration scanning, recommendations). For runtime protection (Defender for Servers, Defender for Endpoint), you install the Arc agent on individual EC2 instances. The connector provides visibility; the agent provides protection.

Click to flip back

Question

What is an Azure Arc Private Link scope, and when would an architect specify it?

Click or press Enter to reveal answer

Answer

An Azure Arc Private Link scope routes Arc agent traffic through Azure Private Link instead of the public internet. An architect specifies it when on-premises or hybrid servers must connect to Azure Arc without public internet exposure — common in government, financial services, or any environment with strict network egress controls. The agent communicates through a private endpoint in your VNet.

Click to flip back

Question

In a multicloud environment, what's the architect's sequence for implementing unified security?

Click or press Enter to reveal answer

Answer

1) Visibility — deploy cloud connectors and Arc agents for asset inventory and CSPM. 2) Assessment — enable Defender CSPM for attack path analysis across clouds. 3) Protection — enable Defender plans on critical workloads for runtime detection. 4) Response — integrate all alerts into a unified SIEM (Sentinel) for single incident response workflow. Each layer builds on the previous one.

Click to flip back

Knowledge Check

A manufacturing company has 200 servers in Azure, 50 EC2 instances in AWS running supply chain applications, and 30 on-premises servers in two factories. The CISO wants unified security visibility and consistent policy enforcement across all environments. The on-premises factories have internet access but strict firewall policies. What architecture should the security architect design?

AA. Migrate all AWS and on-premises workloads to Azure, then use Defender for Cloud nativelyBB. Deploy the AWS connector in Defender for Cloud for CSPM, install Arc agents on on-premises servers through Private Link scope, and enable Defender plans on critical workloads in each environmentCC. Deploy separate security tools for each environment — Defender for Cloud for Azure, AWS Security Hub for AWS, and a third-party SIEM for on-premisesDD. Install Arc agents on all AWS and on-premises servers without the AWS cloud connector, relying solely on agent-based assessment

Check Answer

Knowledge Check

A company uses Arc-enabled Kubernetes to manage clusters in Azure (AKS), AWS (EKS), and on-premises. They want to enforce that no container can run as root across all clusters. What is the most architecturally sound approach?

AA. Write a custom admission webhook for each cluster type and deploy it separatelyBB. Apply Azure Policy for Kubernetes through Arc, which deploys Gatekeeper constraints uniformly across all connected clustersCC. Use Defender for Containers alerts to detect containers running as root and remediate after the factDD. Configure each cluster's native policy engine separately — OPA for on-premises, AWS pod security for EKS, Azure Policy for AKS

Check Answer

🎬 Video coming soon

---

Next up: Endpoint Protection Strategy — design endpoint security architecture covering servers, clients, mobile devices, and their integration with Conditional Access.