13.4 Connecting AWS and GCP Environments to Microsoft Defender for Cloud
Key Takeaways
- AWS connectors authenticate through an IAM role assumed via OpenID Connect federation with Microsoft Entra ID, deployed with a CloudFormation template.
- GCP connectors use workload identity federation with a dedicated service account, deployed with a provided gcloud or Terraform script.
- Connecting at the AWS management account or GCP organization level auto-onboards member accounts and projects as they are created.
- Defender for Servers on AWS and GCP machines depends on Azure Arc onboarding or agentless scanning provided by the connector.
- Multicloud recommendations are mapped to the Microsoft Cloud Security Benchmark, and CIS AWS and CIS GCP standards can be assigned per connector.
Why Multicloud Appears on an Azure Security Exam
The AZ-500 audience profile explicitly says the Azure security engineer implements and monitors security "for resources in Azure, multi-cloud, and hybrid environments". Defender for Cloud is the product that delivers that, so connecting AWS and GCP is a named objective. The pattern to internalize: Defender for Cloud reads the other cloud's configuration through a federated identity, evaluates it against the Microsoft Cloud Security Benchmark, and optionally deploys workload protection onto the machines.
Connecting an AWS Account
Authentication model. Defender for Cloud does not store AWS access keys. Instead:
- You create an AWS connector in Defender for Cloud (Environment settings → Add environment → Amazon Web Services), naming the account and selecting plans.
- Defender for Cloud generates a CloudFormation template (Terraform is also supported).
- Running it in AWS creates IAM roles with a trust policy that allows assumption by Microsoft's application through OpenID Connect (OIDC) federation with Microsoft Entra ID.
- Defender for Cloud assumes those roles to read configuration and, where enabled, to perform agentless scanning.
The security property: there is no long-lived AWS secret anywhere in the integration — the same workload identity federation idea used for GitHub Actions, applied to a cloud connector.
Onboarding scope:
| Scope | Behaviour |
|---|---|
| Single AWS account | One account only; repeat per account |
| AWS management account (organization) | Auto-provisions member accounts, including accounts created later, via StackSets |
Choose the management account when the scenario mentions many accounts or future growth — manually connecting accounts one by one is the wrong answer at scale.
Plans available on the AWS connector:
- Defender CSPM — agentless posture, attack path analysis, cloud security graph, and agentless VM scanning of EC2 instances.
- Defender for Servers — Microsoft Defender for Endpoint on EC2 instances. Requires the machines to become Azure Arc–enabled servers (the connector can auto-provision Arc), or to be covered agentlessly.
- Defender for Containers — EKS cluster discovery, audit log collection, and runtime protection with the Defender sensor.
- Defender for Databases — protection for supported managed database instances.
Connecting a GCP Project or Organization
Authentication model. GCP uses workload identity federation:
- Create a GCP connector in Defender for Cloud, naming the project (or organization) and selecting plans.
- Run the supplied gcloud CLI script or Terraform configuration in GCP.
- It creates a workload identity pool and provider plus a service account that Microsoft's identity can impersonate — again, no downloaded service account key file.
Onboarding scope: connect a single project or the GCP organization, where the organization scope auto-onboards existing and future projects.
Plans available on the GCP connector mirror AWS: Defender CSPM (including agentless VM scanning), Defender for Servers (via Arc onboarding), Defender for Containers (GKE), and Defender for Databases.
What You Get After Connecting
| Capability | Result across clouds |
|---|---|
| Unified inventory | AWS and GCP resources appear in Inventory alongside Azure resources |
| Recommendations | Multicloud recommendations mapped to MCSB, with cloud-native detail (for example, S3 bucket public access, GCS uniform bucket-level access) |
| Secure Score | Multicloud resources contribute through their MCSB-mapped recommendations |
| Compliance standards | CIS AWS Foundations Benchmark, CIS GCP Foundations Benchmark, PCI DSS, and custom standards assignable per connector |
| Custom recommendations | Authored as KQL over the cloud security graph (Defender CSPM required) rather than as Azure Policy |
| Attack paths | Cross-cloud attack path analysis in Defender CSPM |
| Alerts and export | AWS/GCP alerts flow into the same alert pipeline, exportable to Sentinel through continuous export or the Defender for Cloud connector |
Common Design Decisions
- Agent or agentless? Agentless scanning through Defender CSPM gives broad, low-friction coverage of EC2 and GCE disks with no software installed. Defender for Servers with the Defender for Endpoint sensor adds real-time behavioural detection and response. Regulated workloads usually need both; a first-pass posture assessment needs only the connector.
- Arc or not? Full Defender for Servers features on non-Azure machines require Arc onboarding, which the connector can automate. If a scenario says "endpoint detection and response on EC2 instances", expect Arc plus Defender for Endpoint in the answer.
- Permissions. Onboarding requires administrative rights in the target cloud (to run CloudFormation or the gcloud script) and Owner or Security Admin on the Azure subscription hosting the connector. A frequent failure mode is having one but not the other.
- Legacy connectors. The older classic cloud connectors have been superseded by the native connectors described here; new work should always use the native connector experience.
A security team must onboard an AWS organization with 40 member accounts to Microsoft Defender for Cloud, ensuring accounts created next quarter are also covered automatically. What should they configure?
How does Microsoft Defender for Cloud authenticate to a connected GCP project?
An organization wants endpoint detection and response coverage on EC2 instances managed through a Defender for Cloud AWS connector. What is required beyond enabling the connector?