Alright, class. You've decided to actually use Defender for Cloud. Now comes the fun part: connecting everything.

Your infrastructure is scattered. Azure here. AWS there. Some stuff is still on-premises because nobody finished the migration. Kubernetes clusters. VMs. Serverless functions. The entire mess.

The problem isn't "can Defender see it." It's "how do I get Defender to see all of it without screwing up my entire deployment."

Let me walk you through this.

Starting with Azure (The Easy Part)

If you're already in Azure and have a subscription, congratulations. You're halfway done.

Go to Microsoft Defender for Cloud > Environment settings. You'll see your Azure subscription listed. From here you can enable the Defender plans you actually need.

Don't enable everything. Seriously. I see teams blast every single plan on and wonder why their bill is insane next month.

Think about what you actually run.
Got servers? Enable Servers.
Running Kubernetes? Enable Containers.
Storing data in storage accounts? Anything actually important? Backups? Enable Storage.
API Management? Enable APIs.

The key thing: you can enable plans at the subscription level. This means all resources of that type in that subscription are protected. You can't carve out exceptions. It's all-or-nothing per plan per subscription.

So before you enable Servers Plan 2 on your production subscription, ask yourself: Do we have the budget for every server to be scanned?

The Plan 1 vs Plan 2 Thing (Where You Actually Make Decisions)

Microsoft gives you two server plans. People get confused. Let me clear it up with real scenarios.

Servers Plan 1 gives you the basics. Defender for Endpoint. Real-time malware protection. Threat detection. Vulnerability assessment. It costs $5/server/month.

You get the agent deployed automatically. It starts scanning. You get alerts when something's wrong. Perfect for most organisations.

Servers Plan 2 adds the fancy stuff. Agentless vulnerability scanning (scans your VMs without installing agents). Secrets scanning (finds hardcoded credentials in files). Just-in-time VM access (lock down RDP/SSH ports and open them on demand). Adaptive application control (only allows approved apps to run). File integrity monitoring. It costs $15/server/month, and it's where the real value is if you care about actual security.

Real-world scenario: Your team has a web server running. Plan 1 finds that it has SSH open from anywhere. Plan 2 goes further. It finds that someone hardcoded an AWS access key in a config file on that server. Plan 1 tells you you've got a problem. Plan 2 tells you exactly what the problem is and why it matters.

Here's the catch: you pick one plan per subscription. You can't say "production gets Plan 2, dev gets Plan 1." It's subscription-wide (that's also why initial architecture planning around Subscriptions is critical)

AWS (Where It Gets Real)

Onboarding AWS is straightforward, but there's a process.

In Environment settings, click Add environment > AWS. Azure gives you an onboarding flow. You'll need an AWS account with permissions to create IAM roles (your security team will love this conversation).

What's happening behind the scenes? Defender is creating a CloudFormation template that sets up an OIDC identity provider and IAM roles in your AWS account. This allows Defender to assume a role and scan your AWS resources without storing AWS credentials in Azure.

It's federated authentication. Your Azure tenant signs an Entra token. AWS validates it. Boom. Defender can now scan your AWS environment.

Here's the real question: which AWS account? If you're an enterprise with 50 AWS accounts (and let's be honest, you probably are), you need to connect them all. Defender can scan multiple AWS accounts. Yes, really.

Real-world scenario: Your AWS team has a management account and 20 production accounts. You connect the management account to Defender. It sets up the OIDC federation. Then you can onboard all the production accounts to the same setup without repeating the process. Defender now has visibility across your entire AWS organisation.

After onboarding, select which Servers plan you want. That's the same question you asked for Azure. Plan 1 or Plan 2. Do you want basic threat detection or the full thing?

GCP (Similar Process, Different UI)

Add environment > Google Cloud works nearly identically to AWS. Same federated auth approach. Google gives you the Terraform you need to apply in your GCP environment.

You'll need a GCP project with appropriate IAM permissions. Run the Terraform. Defender connects.

Then pick your plans. Same decision as AWS and Azure.

The tricky part with GCP? If you have multiple projects, you need to onboard them individually. Unlike AWS, where you can manage through an organisation account, GCP doesn't have that same aggregation model. You're connecting project-by-project.

On-Premises (Where Azure Arc Comes In)

Your on-prem servers aren't in Azure. They're not in AWS. They're physical hardware in your data centre.

Defender can't see them by default. You need to bring them into Azure's management plane first using Azure Arc.

Azure Arc lets you manage on-prem servers as if they were Azure resources. Install the Arc agent on your on-prem server (Windows or Linux). The agent connects to Azure. Boom. Your on-prem server is now visible in Azure, and Defender can manage it.

Here's what's great: Azure Arc is free. The agent is free. You only pay for what you actually use in Defender.

So you install the Arc agent on your on-prem server. Then, in Defender for Cloud, you enable Servers Plan 1 or Plan 2. Now your on-prem server gets the same protection as your cloud resources.

Real-world scenario: You've got 200 on-prem servers that haven't been migrated. You can't leave them unprotected. Install the Arc agent on all 200. Enable Servers Plan 1. Every one of those servers is now getting vulnerability scans and threat detection from Defender. You don't have to build a separate on-prem security solution.

The alternative? There's direct onboarding without Arc. You can deploy the Defender agent directly using Group Policy or scripts, bypassing Arc entirely. But then you lose the Azure management plane visibility. Azure Arc is the better long-term approach.

Monitoring Coverage: Full vs Partial vs Off

When you look at your resources in Defender, you'll see coverage status. Full. Partial. Off.

Full means this resource has every protection available for its type. Are servers getting both real-time scanning and vulnerability assessment? Full.

Partial means some protections are enabled, others aren't. You've got Plan 1 servers but not Plan 2? That's Partial. You've got Containers but not Malware Scanning? Partial.

Off means nothing. You haven't enabled any protection for this resource type. Maybe you don't have a Storage plan enabled. So all your storage accounts show Off.

Pay attention to this. Partial coverage is where bad things happen. You've got some protection, but not everything. It looks like you're protected when you're actually missing critical pieces.

Real-world scenario: You enable Defender plans, but you miss updating the networking rules to allow traffic. Some servers show Full coverage, others show Partial because they can't reach the Defender endpoints. You don't notice. Three months later, you find out you weren't getting threat detection from half your servers because they couldn't communicate.

Check this regularly. Don't assume coverage status is good just because you enabled plans.

Actually Checking If Things Are Working

Here's what most teams miss: after you onboard everything, they don't verify it's actually working.

Go to Defender for Cloud > Inventory. Filter by resource type. You should see your Azure resources, AWS resources, GCP resources, and on-prem resources. If anything is missing, you missed something.

Check the last assessment date. Resources should have been scanned recently. If a resource's last assessment is from three weeks ago, something's wrong. Either it's not reachable or it's been excluded for some reason.

Look at the recommendations. Do you have security recommendations? That means scanning is happening. If you have zero recommendations across hundreds of resources, something's definitely broken.

Common Mistakes (And How Not To Be That Team)

Enabling everything without understanding costs. You enable all plans on all subscriptions. Your bill will surprise you next month. Pick plans based on what you actually have and what you actually need to protect.

Not connecting on-prem properly. You have Arc agents installed, but they can't reach Azure due to firewall rules. You think they're connected. They're not. Verify network connectivity before assuming Arc is working.

Mixed environments without unified naming. You have Azure-prod, AWS-prod, and GCP-prod, but they're named differently or tagged differently. When you're looking at Defender's inventory, you can't correlate them. Use consistent naming and tagging across clouds.

Enabling Azure Arc but not Defender plans. You install Arc agents on on-prem servers. Nothing else. They're in Azure's inventory but getting no security protection. Arc is just the transport. You still need to enable Defender plans for actual protection.

Not excluding what shouldn't be scanned. You enabled Servers Plan 2, and now your test VM farm is getting expensive. You can't exclude individual servers. Pick which subscription-level plans matter.

Verification Checklist

Before you think you're done:

• Inventory shows resources from Azure, AWS, GCP, and on-prem
• Last assessment dates are recent (within the last 24 hours for most resources)
• Security recommendations are appearing
• Monitoring coverage shows Full or Partial (not Off) for plans you enabled
• You've checked networking to confirm resources can reach Defender endpoints
• Your bill is what you expected (no surprise charges)

If any of these are wrong, you've got a connectivity issue. Fix it before you move on.

Now What?

You've got everything connected. Defender is scanning. You're getting recommendations and alerts.

Next step? Actually use the data. Look at the attack paths. Investigate the alerts. Work with your engineering team to fix things. That's where the real work happens.

But that's the next post.

For now, you've built the foundation. Your infrastructure is connected. Defender is watching. You're ready.

Now make sure you're actually paying attention to what it's telling you.

Class dismissed.