Microsoft Defender for Cloud now protects Amazon Web Services and Google Cloud Platform resources as natively as it protects Azure, and the onboarding path changed meaningfully over the summer. As of the August 4, 2026 update to Microsoft’s own documentation, the AWS and GCP connector flows both moved fully to federated, short-lived credentials, dropped long-lived secrets from the setup process, and added new “least privilege” versus “default access” toggles that change what gets deployed into your cloud account. If you last set this up a year ago, several steps below will look different.
This tutorial walks through connecting an AWS account and a GCP project to Microsoft Defender for Cloud, choosing the right plans for your budget, verifying the connection actually works, and avoiding the mistakes that leave teams staring at an empty inventory pane three days after “onboarding successfully.” It also covers the newer container security and Kubernetes enforcement features that shipped in mid-2026, plus how Microsoft Sentinel fits into the picture once your multicloud data starts flowing.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Microsoft Defender for Cloud Actually Does Across AWS, Azure, and GCP
Microsoft Defender for Cloud is a cloud-native application protection platform, or CNAPP, that combines cloud security posture management (CSPM) with cloud workload protection (CWPP) in a single console hosted in the Azure portal. It was originally an Azure-only tool, but the native AWS connector and GCP connector now let one team run posture assessments, vulnerability scans, and threat detection across all three major clouds from the same dashboard.
The practical reason this matters in 2026: most mid-size and large organizations are no longer single-cloud. A security team that only watches Azure-native alerts is blind to whatever is running in a marketing team’s AWS account or a data science group’s GCP project. Defender for Cloud’s multicloud connectors close that gap without requiring a second security tool, a second dashboard, or a second on-call rotation, provided the onboarding is done correctly.
Under the hood, when you connect an AWS account, Defender for Cloud authenticates using federated trust and short-lived credentials rather than storing an access key. For GCP, it uses workload identity federation and service account impersonation. Neither integration stores a long-lived secret in Azure, which is a deliberate design choice Microsoft highlights in its authentication architecture documentation for AWS.
Prerequisites: What You Need Before You Start
Gather these before opening the Azure portal. Missing any one of them is the single biggest reason onboarding attempts stall halfway through the wizard.
- An active Microsoft Azure subscription with Defender for Cloud enabled at the subscription level (pay-as-you-go or Enterprise Agreement both work; a free trial subscription is enough to complete this tutorial).
- Contributor role at minimum on the target Azure subscription; Owner role if you plan to enable Defender for Servers or Defender CSPM autoprovisioning, since those features deploy Azure Arc automatically.
- If you plan to enable Cloud Infrastructure Entitlement Management (CIEM) as part of Defender CSPM, the onboarding user also needs the Security Admin role plus Application.ReadWrite.All permission in Microsoft Entra ID.
- An AWS account you can administer, ideally the AWS management account if you’re onboarding an entire AWS Organization rather than a single account.
- A GCP project or organization with the ability to run scripts in Google Cloud Shell, since the GCP connector generates a
gcloudscript you execute yourself. - Five GCP APIs enabled on the project you onboard from:
iam.googleapis.com,sts.googleapis.com,cloudresourcemanager.googleapis.com,iamcredentials.googleapis.com, andcompute.googleapis.com. The onboarding script can enable these for you if they’re missing. - For Defender for Containers on AWS, at least one Amazon EKS cluster with API server access, and the ability to create an SQS queue, a Kinesis Data Firehose delivery stream, and an S3 bucket in the cluster’s region.
- For Defender for Servers on AWS EC2 instances, the AWS Systems Manager (SSM) Agent installed with the
AmazonSSMManagedInstanceCoremanaged policy attached, since Azure Arc autoprovisioning depends on it. - About 100 minutes if you’re connecting both an AWS account and a GCP project and validating both connections end to end. Budget more if you’re onboarding an entire AWS Organization with dozens of member accounts.
One environment note: the AWS and GCP native connectors are not available on Azure Government or Azure operated by 21Vianet. If your organization runs in a national government cloud, you’ll need Azure Arc-based onboarding instead, which is a separate process outside the scope of this guide.
Step 1-2: Enable Defender for Cloud on Your Azure Subscription
Before you can connect a single AWS account or GCP project, Defender for Cloud needs to be active on the Azure subscription that will host the connector.
- Sign in to the Azure portal with an account that has Contributor or Owner rights on the target subscription.
- Search for Microsoft Defender for Cloud in the top search bar and open it.
- In the left navigation, select Environment settings, then choose the subscription you want to protect.
- If Defender for Cloud isn’t already enabled, select Enable all plans (or pick individual plans if you want tighter cost control from day one — more on plan selection below).
Foundational CSPM is free and turns on automatically. Everything else — Defender CSPM, Defender for Servers, Defender for Containers, Defender for Databases, Defender for APIs — is a paid add-on you enable per plan, per subscription, or per connector. That granularity is exactly why the next step matters before you touch AWS or GCP at all.
Step 3: Choose Your Plans — Foundational CSPM vs Defender CSPM vs Workload Plans
This is where most of the cost decisions happen, and it’s worth understanding before you connect a single cloud account, because switching plans later means redeploying the CloudFormation stack or rerunning the GCP script. Foundational CSPM ships free with every subscription and gives you basic asset inventory and a subset of security recommendations. Defender CSPM is the paid posture management tier that adds attack path analysis, agentless vulnerability scanning, and the CIEM identity entitlement features. On top of that sit workload-specific plans for servers, containers, databases, storage, and APIs.
| Plan | Typical billing unit | What it adds |
|---|---|---|
| Foundational CSPM | Free | Asset inventory, baseline recommendations, secure score |
| Defender CSPM | Published rate ~$5.11/billable resource/month | Attack path analysis, agentless scanning, CIEM, data-aware security |
| Defender for Servers Plan 1 | Published rate ~$0.007/server/hour (≈$5/server/month) | Threat detection, Microsoft Defender for Endpoint integration |
| Defender for Servers Plan 2 | Published rate ~$0.02/server/hour (≈$15/server/month) | Adds agentless scanning, file integrity monitoring, adaptive controls |
| Defender for Containers | Published rate ~$0.0095/vCore/hour | Kubernetes posture, runtime threat detection, registry scanning |
| Defender for APIs | Tiered Plans 1-5 | API discovery, posture, and runtime protection |
| Defender for AI Services | Priced per 1,000 tokens/month | Prompt injection and AI workload threat detection |
Treat the dollar figures in that table as directional. Azure’s own pricing page renders exact numbers through a calculator that varies by region and currency, so before you commit budget, open the Defender for Cloud pricing page and plug in your subscription’s region. For a mid-size AWS estate — say 200 EC2 instances and one EKS cluster — Defender for Servers Plan 2 plus Defender for Containers is the combination most teams land on, since Plan 1 alone doesn’t include agentless vulnerability scanning.
Step 4-9: Connect Your AWS Account via the Native Connector
With plans decided, connect AWS first — most teams have more AWS footprint than GCP, and the AWS wizard surfaces plan-specific prerequisites you’ll want to see before repeating the process for GCP.
- In Defender for Cloud, go to Environment settings and select Add environment > Amazon Web Services.
- Enter a name for the connector and choose the account type: Management account (onboards an entire AWS Organization, with new member accounts auto-discovered) or Single account.
- Select which AWS regions Defender for Cloud should scan. All regions are selected by default — narrow this if you know your workloads live in specific regions, to reduce noise.
- Choose the Azure subscription, resource group, and location where the security connector resource itself will live.
- Set a scan interval: 4, 6, 12, or 24 hours. Some data collectors run on a fixed schedule regardless of this setting.
- Enter your AWS account ID (or, for management account onboarding, note that delegated administrator accounts are not supported — you must use the actual AWS management account).
- On the next screen, select the Defender plans to enable for this AWS environment, mirroring the decision you made in Step 3.
- Choose a permissions type: Default access grants what’s needed now plus room for future capabilities, while Least privilege access grants only what’s required today and may prompt you again later if a new feature needs broader access.
- Pick a deployment method — AWS CloudFormation or Terraform — and follow the on-screen instructions to run it in your AWS account.
The CloudFormation path is the one most teams pick for a first connector. If you choose “Upload a template file,” AWS auto-creates an S3 bucket to store it, which can trigger the “S3 buckets should require requests to use Secure Socket Layer” finding in your own posture score. Microsoft’s own docs give the fix as a bucket policy you attach after the fact:
{
"Id": "ExamplePolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Action": "s3:*",
"Effect": "Deny",
"Resource": [
"<S3_Bucket_ARN>",
"<S3_Bucket_ARN>/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
},
"Principal": "*"
}
]
}Defender CSPM queries AWS resource APIs several times a day to keep recommendations current. These are read-only calls and don’t incur extra AWS charges by themselves, but if you have a CloudTrail read-event trail enabled and export logs to an external SIEM, the added call volume can increase ingestion costs on that side. The default IAM role name Defender for Cloud creates for this is CspmMonitorAws — confirm the actual name on your account, since it can be customized during onboarding, and filter it out of SIEM ingestion rules if the extra volume becomes a cost issue.
If you’re onboarding an AWS management account and hit the error You must enable organizations access to operate a service managed stack set, it means trusted access for AWS Organizations isn’t turned on. Go to the CloudFormation StackSets page in the AWS console, enable trusted access when prompted, then rerun the template.
Step 10: Connect Your GCP Project via Workload Identity Federation
GCP onboarding follows the same shape as AWS but authenticates differently — there’s no IAM access key or CloudFormation stack. Instead, Defender for Cloud generates a gcloud script that you run yourself in Google Cloud Shell, and that script sets up workload identity federation so Azure never touches a long-lived GCP credential.
- In Defender for Cloud, go to Environment settings and select Add environment > Google Cloud Platform.
- Choose the Azure subscription, resource group, and location for the connector resource, and set a scan interval (note that resource types like ComputeInstance, ArtifactRegistryImage, and ContainerCluster always scan on a fixed 1-hour interval regardless of what you set here).
- For organization-level onboarding, enter the GCP organization ID and optionally exclude specific project numbers or folder IDs. For single-project onboarding, enter the GCP project number and project ID instead.
- Select the Defender plans to enable for this GCP environment.
- Choose Default access or Least privilege access, same as the AWS flow.
- Copy the generated
gcloudscript and run it in GCP Cloud Shell against the project or organization you’re onboarding.
The script provisions a workload identity pool, a workload identity provider per enabled plan, the necessary service accounts, and project-level policy bindings scoped only to the project you’re connecting. A representative snippet of what it enables looks like this (the actual script is generated per-tenant, so don’t hand-copy this — always use the one Defender for Cloud generates for your connector):
gcloud services enable iam.googleapis.com \
sts.googleapis.com \
cloudresourcemanager.googleapis.com \
iamcredentials.googleapis.com \
compute.googleapis.com \
--project=YOUR_PROJECT_ID
gcloud iam workload-identity-pools create defender-for-cloud-pool \
--project=YOUR_PROJECT_ID \
--location=global \
--display-name="Defender for Cloud"If you’re onboarding at the organization level, enable those five APIs on the management project, not on every member project — the script only needs to run once against the project that owns the organization-level service accounts.
Step 11: Automate Onboarding with Terraform (Optional but Recommended at Scale)
If you’re onboarding more than a handful of AWS accounts or GCP projects, clicking through the portal wizard repeatedly doesn’t scale. Both connectors support Terraform as an alternative to the portal-generated CloudFormation stack or gcloud script, which lets you version-control the onboarding configuration and roll it out through your existing CI/CD pipeline.
resource "azurerm_security_center_subscription_pricing" "defender_cspm" {
tier = "Standard"
resource_type = "CloudPosture"
}
resource "azurerm_security_center_subscription_pricing" "defender_containers" {
tier = "Standard"
resource_type = "Containers"
}
# AWS and GCP connector resources are provisioned via the
# Defender for Cloud multicloud connector Terraform modules
# referenced in Microsoft's onboarding guidance — run
# `terraform plan` against a non-production subscription first.Note that if you select Management account during AWS onboarding, the Terraform tab isn’t shown in the portal UI, even though Terraform onboarding for management accounts is still supported. You’ll need to reference Microsoft’s separate Terraform onboarding guidance rather than the portal wizard for that specific combination.
Step 12: Configure Container and Kubernetes Security Across Clouds
Defender for Containers works the same way regardless of which cloud hosts the cluster — Amazon EKS, Google GKE, or Azure AKS all report into the same posture and runtime protection views once connected. Two features that matured in mid-2026 are worth configuring deliberately rather than leaving on defaults.
The first is Kubernetes misconfiguration enforcement, which reached general availability on July 1, 2026. It evaluates Kubernetes resource configurations at admission time — before a pod or deployment is actually created — and can either audit non-compliant requests or block them outright. This is a meaningfully different posture than the older model of scanning after the fact and generating a recommendation you might not see for hours. Enable it in audit mode first on any cluster with active deployments; switching straight to block mode on a production cluster without a dry-run period is one of the more common ways teams accidentally break their own release pipeline.
The second is serverless container workload discovery, which entered preview in June 2026. It extends posture management beyond traditional VM-backed containers to serverless container platforms like AWS Fargate and Cloud Run, which previously showed up as blind spots in the inventory even when the rest of the account was connected. If your workloads lean heavily on Fargate or Cloud Run rather than EC2 or Compute Engine, this preview feature is worth turning on explicitly rather than waiting for general availability — our comparison of AWS Fargate, Cloud Run, and Azure Container Apps covers how these serverless container runtimes differ if you’re deciding where new workloads should even live.
Step 13: Validate Connector Health and Coverage
A connector that shows as “Connected” in the portal isn’t proof that data is actually flowing. Validate it properly before you tell anyone the multicloud rollout is done.
- In Defender for Cloud, go to Environment settings and locate your AWS account or GCP project in the list.
- Check the Connectivity status column. A healthy connector shows “Connected”; anything else links to a details page describing the specific configuration or permission problem.
- Open the coverage workbook (under Azure Workbooks inside Defender for Cloud) to see exactly which plans are enabled on which subscriptions and resources — this is the fastest way to spot a plan you thought you enabled but didn’t.
- Check the asset inventory for your newly connected AWS or GCP resources and confirm the “last assessed” timestamp is recent, not blank.
- Give it a few hours. Security recommendations don’t appear instantly — Microsoft’s own guidance says to expect them within a few hours of a successful connection, not minutes.
If a resource never shows a recent assessment timestamp, that’s a stronger signal than the connector status badge — a connector can report “Connected” while a specific plan silently fails to scan due to a missing permission on one resource type.
Step 14: Wire Up Microsoft Sentinel for Multicloud Threat Detection
Once AWS and GCP data is flowing into Defender for Cloud, Microsoft Sentinel can consume it for broader threat hunting and correlation. The key data source here is the CloudAuditEvents table, which reached general availability alongside Defender XDR’s June 2026 update and normalizes cloud audit activity — including GCP audit logs — into a single hunting schema alongside your Azure and AWS signals.
A basic hunting query to confirm GCP audit data is actually landing in Sentinel looks like this:
CloudAuditEvents
| where CloudProvider == "GCP"
| where TimeGenerated > ago(24h)
| summarize EventCount = count() by OperationName, ActorUsername
| order by EventCount descIf that query returns nothing after 24 hours, the GCP connector itself may be healthy while log forwarding to Sentinel specifically is misconfigured — check the GCP Cloud Logging ingestion preview setup separately from the base connector, since they’re two different onboarding steps that are easy to conflate.
Sentinel is also mid-transition into the unified Defender portal as of 2026, so depending on when your tenant was provisioned, you may be running hunting queries from the classic Sentinel workspace or from the merged Defender portal experience. Both read from the same underlying tables, so the query above works in either.
Common Pitfalls When Onboarding AWS and GCP to Defender for Cloud
These are the mistakes that show up repeatedly in support threads and in teams’ own postmortems after a rollout goes sideways.
- Connecting an AWS account that’s already linked to Microsoft Sentinel. Defender for Cloud and Sentinel can’t both own the same AWS account connection — if Sentinel has it, you need the separate “Sentinel-connected AWS account” migration path, not the standard AWS connector wizard, or the new connector will simply fail.
- Using Contributor when Owner is required. Contributor is enough to create the connector itself, but Defender for Servers and Defender CSPM autoprovisioning — which deploys Azure Arc automatically to EC2 instances — needs Owner on the subscription. Teams frequently get partway through onboarding, hit a silent autoprovisioning failure, and don’t realize the role was the cause.
- Forgetting the SSM Agent on EC2 instances. Azure Arc autoprovisioning for AWS depends on the AWS Systems Manager Agent already running with the
AmazonSSMManagedInstanceCorepolicy attached. Without it, instances never get an Arc identity and never show up as protected, even though the AWS connector itself reports healthy. - Choosing “Upload a template file” for CloudFormation without checking the resulting S3 bucket policy. This auto-created bucket can trip the SSL-enforcement finding in your own posture score minutes after onboarding — apply the bucket policy fix immediately rather than treating it as a false positive.
- Enabling Kubernetes misconfiguration enforcement in block mode on day one. Skipping the audit-mode dry run is the fastest way to have a security rollout blamed for breaking an unrelated deployment pipeline. Audit for at least a week before switching to block.
- Assuming GCP organization-level onboarding covers projects created afterward automatically. It does, but only if autoprovisioning is left enabled — teams that disable it to control costs often discover months later that new GCP projects were never actually protected.
- Not distributing connectors across multiple Azure subscriptions at scale. Microsoft explicitly recommends keeping each portal view under 10,000 resources for AWS and GCP connectors alike. Cramming a large multicloud estate into one subscription’s view makes the portal sluggish and can hide resources from filtered views.
Troubleshooting: 8 Issues You’ll Likely Hit and How to Fix Them
| Symptom | Likely cause | Fix |
|---|---|---|
| Connector shows “Connected” but no resources appear | Initial scan hasn’t completed yet, or scope is misconfigured | Wait a few hours for first assessment; verify region/project scope in connector settings |
| CloudFormation stack fails with organizations-access error | Trusted access for AWS Organizations not enabled | Enable trusted access on the CloudFormation StackSets page, then rerun the template |
| New S3-SSL-required finding right after onboarding | Auto-created S3 bucket from “Upload a template file” lacks a TLS-only policy | Attach the AllowSSLRequestsOnly bucket policy shown in this guide |
| EC2 instances never get an Arc identity | SSM Agent missing or lacks AmazonSSMManagedInstanceCore policy | Install/update SSM Agent and attach the managed policy, then wait for autoprovisioning to retry |
| GCP connector fails at script execution | Required GCP APIs not enabled on the onboarding project | Enable iam, sts, cloudresourcemanager, iamcredentials, and compute APIs, then rerun the script |
| AWS connector creation blocked entirely | Target AWS account already connected to Microsoft Sentinel | Use the Sentinel-to-Defender-for-Cloud migration path instead of a fresh connector |
| CloudAuditEvents query returns zero GCP rows | GCP Cloud Logging ingestion (Preview) not separately configured | Set up Pub/Sub-based log ingestion in addition to the base GCP connector |
| Portal feels slow or resources missing from filtered views | Single subscription holding more than 10,000 connected resources | Distribute connectors across multiple Azure subscriptions and use the global subscription filter |
For anything not covered above, Microsoft maintains a dedicated troubleshooting guide for multicloud connectors that includes a full CloudFormation error resolution table for AWS-specific deployment errors like AccessDenied and EntityAlreadyExists.
What’s New in Defender for Cloud for 2026
Beyond the connector changes already covered, Microsoft expanded multicloud coverage significantly in the June-July 2026 window. Defender for Cloud added support for dozens of additional AWS and GCP resource types spanning data services, identity and access management, networking, compute, and containers — including AWS services such as Amazon EMR, Amazon Neptune, AWS DMS, Amazon FSx, Amazon Kinesis, AWS AppSync, AWS CodeBuild, Amazon Cognito, and Amazon Comprehend, alongside a large batch of new security recommendations across those categories.
Defender for Open-Source Relational Databases also reached general availability for AWS RDS, giving native threat protection for engines like Aurora PostgreSQL, Aurora MySQL, PostgreSQL, MySQL, and MariaDB running on RDS — a gap that previously forced teams to bolt on a separate database activity monitoring tool for AWS-hosted databases. Check the official release notes page regularly, since Microsoft ships Defender for Cloud updates on a near-monthly cadence and a feature that’s “Preview” this quarter can reach GA the next.
Defender for Cloud vs AWS Security Hub vs Google Security Command Center vs Wiz vs Prisma Cloud
Defender for Cloud rarely gets deployed in a vacuum — most security teams evaluating it are also running or considering a native cloud-specific tool, or a dedicated third-party CNAPP.
| Tool | Native to | Free tier | Multicloud from one pane |
|---|---|---|---|
| Microsoft Defender for Cloud | Azure | Foundational CSPM, free | Yes — AWS and GCP via native connectors |
| AWS Security Hub | AWS | 30-day trial | Limited; built for AWS-centric estates |
| Google Security Command Center | GCP | Standard tier, free | Limited; premium tier adds more recommendations |
| Wiz | Cloud-agnostic third party | No | Yes — designed multicloud-first |
| Prisma Cloud (Palo Alto Networks) | Cloud-agnostic third party | No | Yes — designed multicloud-first |
The practical decision point is usually organizational, not technical: if your team already lives in the Microsoft security stack — Sentinel, Defender XDR, Entra ID — Defender for Cloud’s multicloud connectors let you extend that stack to AWS and GCP without adding a new vendor relationship. If you’re AWS-first with light Azure and GCP footprint, native AWS Security Hub with GuardDuty may cover more ground with less onboarding friction. Dedicated CNAPPs like Wiz and Prisma Cloud tend to win on agentless scanning depth and graph-based attack path visualization, at the cost of a separate console and a separate bill. If you’re weighing dedicated identity and entitlement tooling as part of this decision, our breakdown of CrowdStrike Falcon versus Microsoft Defender XDR covers the adjacent endpoint side of that same platform-versus-best-of-breed tradeoff, and our look at Defender EASM versus CyCognito versus Tenable ASM covers external attack surface management specifically.
Advanced Tips: Least-Privilege Access, Cost Control, and CI/CD Integration
A handful of practices separate a rollout that stays maintainable from one that quietly rots after the initial onboarding push.
Default to least-privilege access, then loosen deliberately. The “Default access” option is easier at setup time, but it grants permissions for capabilities you may never turn on. Starting with “Least privilege access” means you’ll occasionally get a notification that a new feature needs broader permissions — which is a better failure mode than an over-permissioned role sitting unused in your AWS account for a year.
Use the cost calculator before enabling a plan tenant-wide. Defender for Cloud includes a built-in cost calculator specifically for estimating multicloud plan costs before you commit. Run a connected AWS account through it with Defender CSPM and Defender for Servers Plan 2 enabled before flipping those plans on for every account in an Organization at once.
Update your CloudFormation template whenever you change plan configuration. Enabling a new Defender plan, changing regions, or toggling autoprovisioning after the fact requires regenerating and reapplying the CloudFormation template — the original stack doesn’t pick up plan changes automatically. The same logic applies to the GCP gcloud script: rerun it after any plan or scope change.
Pipe onboarding through Terraform once you’re past a handful of accounts. Manual portal onboarding is fine for a pilot with one AWS account and one GCP project. Past that, the Terraform path keeps connector configuration in version control, reviewable in pull requests, and consistent across environments — which also makes audits considerably less painful. If your broader cloud governance already leans on infrastructure-as-code for account provisioning, our guide to AWS Control Tower versus Azure Landing Zone versus GCP is a useful companion for deciding where security connector onboarding fits into that automation.
Treat Kubernetes enforcement as a phased rollout, not a flag flip. Between the EKS, GKE, and AKS clusters most multicloud teams run, admission-time enforcement policies rarely behave identically across all three. Roll audit mode out cluster by cluster, review the flagged violations for false positives specific to each cluster’s workloads, and only then move each cluster to block mode independently. If you’re setting up Kubernetes across AWS specifically, our Kubernetes on AWS EKS setup guide covers the cluster-level prerequisites this enforcement layer sits on top of.
Building a Complete Multicloud Security Baseline: Putting It Together
A working end-to-end setup looks like this: Foundational CSPM active tenant-wide at no cost, Defender CSPM enabled on subscriptions holding production workloads, Defender for Servers Plan 2 on any subscription with EC2 or Compute Engine instances handling customer data, Defender for Containers on every EKS, GKE, and AKS cluster, and Defender for Open-Source Relational Databases on any RDS instance running Postgres or MySQL. AWS and GCP connectors are onboarded via Terraform for repeatability, permissions are least-privilege by default, Kubernetes enforcement runs in audit mode on new clusters for at least one release cycle before block mode, and Sentinel’s CloudAuditEvents table is actively queried as part of a weekly threat-hunting routine rather than left to accumulate unread.
None of that is exotic — it’s the same plan-by-plan, connector-by-connector process covered above, applied consistently across every account instead of just the first one you connected during the pilot. The gap between “we onboarded AWS to Defender for Cloud” and “we have working multicloud security posture management” is almost always in that consistency, not in any single step being technically hard.
Frequently Asked Questions
Does Microsoft Defender for Cloud require an AWS or GCP subscription of its own?
No. You need an active AWS account or GCP project you already administer, plus a Microsoft Azure subscription to host the connector configuration and Defender for Cloud itself. There’s no separate AWS or GCP product to purchase.
Is Foundational CSPM really free for AWS and GCP resources?
Yes, Foundational CSPM is free across connected Azure, AWS, and GCP resources and is enabled by default once a connector is created. It gives you asset inventory and a baseline set of security recommendations; the paid Defender CSPM tier adds attack path analysis, agentless scanning, and CIEM.
Can I connect the same AWS account to both Microsoft Sentinel and Defender for Cloud?
Not through two independent connectors. If an AWS account is already connected to Microsoft Sentinel, you must follow Microsoft’s specific migration path to connect that same account to Defender for Cloud, rather than creating a fresh connector, which will fail.
How long does it take for security recommendations to appear after connecting AWS or GCP?
Microsoft’s own guidance sets the expectation at a few hours after a successful connection, not minutes. If a resource’s inventory entry still shows no assessment after a full day, treat that as a signal to check connector health rather than waiting longer.
What’s the difference between Default access and Least privilege access during onboarding?
Default access grants the permissions needed for currently enabled capabilities plus room for future ones, so you won’t need to reconfigure access as new features ship. Least privilege access grants only what’s required right now, which is more conservative from a security standpoint but may prompt additional permission requests later when you enable new plans or features.
Does Defender for Cloud support serverless platforms like AWS Fargate and Cloud Run?
Support is expanding. Serverless container workload discovery entered preview in June 2026, extending posture visibility to platforms like Fargate and Cloud Run that previously fell outside standard container scanning. Since it’s a preview feature, expect it to mature and possibly change behavior before reaching general availability.
Do I need Azure Arc to protect my AWS EC2 instances?
Yes, for Defender for Servers and Defender for SQL on EC2, Azure Arc is the mechanism that extends Azure’s management plane to those instances. Autoprovisioning handles the Arc installation automatically, provided the AWS SSM Agent is already installed with the AmazonSSMManagedInstanceCore policy and the onboarding user has Owner rights on the Azure subscription.
Can I onboard a single GCP project without connecting the whole organization?
Yes. The GCP connector wizard supports both organization-level onboarding, which auto-discovers current and future projects under that organization, and single-project onboarding, where you enter a specific GCP project number and project ID instead of an organization ID.
Related Coverage
- AWS Control Tower vs Azure Landing Zone vs GCP: $913 Gap [2026]
- Kubernetes on AWS EKS Setup: 12 Steps, 100 Min [2026]
- CrowdStrike Falcon vs Microsoft Defender XDR: $925K Gap [2026]
- Defender EASM vs CyCognito vs Tenable ASM: 19x Gap [2026]
- AWS Fargate vs Cloud Run vs Container Apps: $29.55 Gap [2026]
- Vulnerability Management Program: 12 Steps, 100 Min [2026]
- More Cloud Computing Coverage
