Securing multicloud (Azure, AWS & GCP) with Microsoft Defender for Cloud: Connector best practices

Many organisations operate across various cloud providers, and it’s crucial to maintain strong security while ensuring everything works together seamlessly. Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP) that aids in securing these environments, providing cohesive visibility and protection for resources in AWS and GCP alongside Azure.

As users begin utilising Microsoft Defender for Cloud in multicloud setups, Microsoft offers numerous resources to aid in planning, deployment, and scalable onboarding.

With proper planning and adoption strategies, transitioning to Microsoft Defender for Cloud can be straightforward and predictable. That said, support cases reveal that certain common issues may arise during or after setting up AWS or GCP environments. Below, we’ll explore common multicloud scenarios, their symptoms, and suggested troubleshooting steps.

1. Issue: Deleted cloud account still visible in Microsoft Defender for Cloud

Sometimes, when you delete or remove an AWS or GCP account, it still appears in Microsoft Defender for Cloud under connected environments. You might even see security suggestions for resources linked to the deleted account on the recommendations page.

Why This Happens

Microsoft Defender for Cloud doesn’t automatically remove a cloud connector when the external account is deleted. The security connector in Azure is a separate entity that remains unless you remove it manually. It doesn’t receive updates from AWS or GCP when an account is closed, so that connector and its last known data will linger until you take action.

Solution

To tidy up this stale entry, delete the connector using one of these methods:

Option 1: Through the Azure portal

1. Log in to the Azure portal.
2. Navigate to Microsoft Defender for Cloud > Environment settings.
3. Select the AWS account or GCP project you wish to remove.
4. Click Delete to remove the connector.

Option 2: Using the REST API

1. Delete the connector via the REST API: Security Connectors – Delete – REST API (Azure Defender for Cloud).

Note: If your multicloud organisation had multiple connectors set up and some accounts were later decommissioned, you’ll need to clean up several connectors. Start with the management account connector, and then remove any remaining child connectors. This sequence helps avoid leftover dependencies.

For more guidance, see: What you need to know when deleting and re-creating security connectors in Defender for Cloud.

2. Issue: Identity provider is either missing or partially configured

If you run the AWS CloudFormation template and the connector setup fails, Microsoft Defender for Cloud may show an error state for the AWS environment. This occurs because the identity link between Azure and AWS hasn’t been established correctly.

Although the CloudFormation stack exists on AWS, the necessary OIDC identity provider or the IAM role trust policy that permits Microsoft Defender for Cloud to assume the role via web identity federation may be missing or incorrectly configured.

Why This Happens

The AWS CloudFormation template may not correspond to the correct Azure subscription or tenant. This can occur if:

• You were logged into the wrong Azure directory when generating the template.
• The template was deployed to a different AWS account than intended.

In either scenario, mismatched Azure and AWS IDs will cause the connector setup to fail.

Solution

1. Check your Azure directory and subscription.
   • In the Azure portal, go to Directories + subscriptions and ensure the correct directory and subscription are selected before setting up the connector.

2. Fix the incorrect configuration.
   • In AWS, delete the CloudFormation stack and any associated IAM roles or identity providers.
   • In Microsoft Defender for Cloud, remove the failed connector from Environment settings.

3. Recreate the connector.

4. Check the connection.
   • Once the connection is successful, the AWS environment will show as Healthy in Microsoft Defender for Cloud. You should see resources and recommendations appearing within about an hour.

3. Issue: Duplicate security connector is obstructing onboarding

If you try to add an AWS or GCP connector in Microsoft Defender for Cloud and onboarding fails with an error indicating a duplicate connector exists with the same hierarchy ID, you’ll find the environment marked as Failed in the Azure portal, and no resources will show in Microsoft Defender for Cloud.

Why This Happens

Only one connector is allowed per cloud account within the same Microsoft Entra ID tenant in Microsoft Defender for Cloud. The hierarchy ID uniquely identifies the cloud account (like an AWS account ID or GCP project ID). If the account was previously onboarded in another Azure subscription within the same tenant, you won’t be able to onboard it again until the existing connector is deleted.

Solution
Locate and remove the existing connector, then retry onboarding.

Step 1: Find the existing connector.

1. Log in to the Azure portal.
2. Go to Microsoft Defender for Cloud > Environment settings.
3. Inspect each subscription in the same tenant for a pre-existing AWS account or GCP project connector.

If you have access, you may also use Azure Resource Graph to find existing connectors:

| resources
| where type == "microsoft.security/securityconnectors"
| project name, location, properties.hierarchyIdentifier, tenantId, subscriptionId

Step 2: Remove the duplicate connector.
Delete the connector with the duplicated hierarchy ID. Follow the instructions from the earlier troubleshooting section about deleting security connectors.

Step 3: Retry onboarding. After removing the connector, try adding the AWS or GCP connector in the target subscription again. If the error persists, confirm that all duplicate connectors are deleted and allow a short time for the changes to take effect.

Microsoft Defender for Cloud provides robust support for multicloud security strategies, but maintaining cloud security is an ongoing process. Onboarding multicloud environments is simply the first phase. After you’ve onboarded, it’s essential to consistently review security recommendations, alerts, and compliance status across all connected clouds. With the right setup, Microsoft Defender for Cloud acts as a single source of truth, helping you maintain visibility and control as threats evolve.

Further Reading:

We trust this guide will aid you in successfully implementing end-to-end ingestion of Microsoft Intune logs into Microsoft Sentinel. If you have any questions, feel free to leave a comment below!