Multi-Cloud SIEM with Microsoft Sentinel

Ingest AWS CloudTrail and Azure Activity logs into a single Sentinel workspace.

Introduction

30 Second Summary

Organizations today run workloads across multiple cloud providers. When a security incident spans AWS and Azure simultaneously, security teams need a single place to see everything happening across all their environments.

In this project, you will build a multi-cloud SIEM lab where Microsoft Sentinel ingests security telemetry from both AWS and Azure into a single workspace, then write cross-cloud detection queries that correlate activity across both environments.

What You'll Build

A fully functional multi-cloud SIEM lab with Microsoft Sentinel as the central detection engine, receiving real security events from both AWS and Azure.

By the end of this project, you'll have:

  • A Microsoft Sentinel workspace with the 31-day free trial active, ingesting up to 10 GB/day of security telemetry.
  • Azure Activity logs flowing as native telemetry into your workspace.
  • AWS CloudTrail management events flowing through an S3/SQS/OIDC pipeline into the same workspace, with cross-cloud KQL queries and a scheduled analytics rule for detection.
  • Secret Mission: Add AWS GuardDuty findings as a second data source and build a workbook visualizing multi-source security data.

Are there any prerequisites?

No prior cloud experience is required. This guide walks you through creating both your AWS and Azure accounts from scratch, installing all CLI tools, and configuring everything step by step.

Set Up Accounts and CLI Tools

Microsoft Sentinel can only correlate security events across cloud boundaries if it has access to telemetry from each cloud. Before you can send data to Sentinel, you need active accounts on both AWS and Azure, plus CLI tools to configure the data pipeline.

In this step, you will create free-tier accounts on both clouds, then install the two command-line tools the rest of the project depends on: AWS CLI v2 and PowerShell 7.

In this step, get ready to:
  • Create an AWS free-tier account with an IAM user for CLI access.
  • Create an Azure free account with a Pay-As-You-Go subscription.
  • Install and configure AWS CLI v2 and PowerShell 7 on macOS.
Create your AWS account and IAM user

AWS offers a free tier that covers everything you need for this lab. You will create a root account and then an IAM user for day-to-day CLI access.

  • Open https://aws.amazon.com in your browser and click Create an AWS Account.
  • Enter your email address, choose an account name, and verify your email.
  • Complete the signup by entering a payment method (for verification only, you will not be charged) and selecting the Basic (Free) support plan.
  • Once signed in, search for IAM in the AWS Management Console search bar and open it.
  • In the left navigation pane, click Users, then click Create user.
  • Enter a user name (for example, sentinel-lab-admin) and click Next.
  • On the Set permissions page, select Attach policies directly.
  • Search for AdministratorAccess and check the box next to it.
  • Click Next, review the user details, then click Create user.

Now generate an access key pair for this user so you can authenticate from the terminal.

  • Click the user name you just created to open its details page.
  • Select the Security credentials tab.
  • In the Access keys section, click Create access key.
  • On the Access key best practices & alternatives page, select Other and click Next.
  • Click Create access key.
  • Click Download .csv file and save the file somewhere secure on your computer.

Keep your credentials safe

This is the only time you can view or download the secret access key. Store it in a password manager or another secure location. Never share it or commit it to source control.

What is IAM?

IAM (Identity and Access Management) lets you create users with specific permissions instead of using your root account for everything. The AdministratorAccess policy gives this user full control over your AWS account, which is what you need to set up CloudTrail, S3, and SQS later.

Create your Azure free account

Azure provides a free account that includes a Pay-As-You-Go subscription. Microsoft Sentinel's 31-day free trial (10 GB/day ingestion) covers this entire lab at no cost.

  • Open https://azure.microsoft.com/free in your browser.
  • Click Start free and sign in with a Microsoft account (or create one).
  • Complete the signup with your details and payment method (for verification only).
  • Once complete, confirm you can reach the Azure portal at portal.azure.com.

Why do I need both AWS and Azure?

The whole point of a multi-cloud SIEM is to see security events from different cloud providers in one place. AWS generates the security telemetry (via CloudTrail), while Azure hosts the Sentinel workspace that ingests and correlates it alongside native Azure logs.

Install AWS CLI v2 and PowerShell 7

AWS CLI v2 lets you manage AWS resources from your terminal. PowerShell 7 is required to run the Sentinel connector setup script later in the project.

  • Press Cmd+Space to open Spotlight, type Terminal, and press Enter to open it.
  • Download the official AWS CLI v2 installer by running this command:
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
  • Install the package by running:
sudo installer -pkg AWSCLIV2.pkg -target /

What do these commands do?

The curl command downloads the official macOS installer package from AWS. The sudo installer command runs the macOS package installer system-wide, which places the aws binary at /usr/local/bin/aws.

Your Mac will prompt you for your password because sudo requires administrator privileges. Type your Mac login password and press Enter (the characters will not appear as you type).

  • Verify the installation by running:
aws --version

Check what you see in your terminal output:

✔️ I see version 2.x

You should see output like aws-cli/2.27.41 Python/3.11.6 Darwin/... (your exact numbers may differ, but the major version should be 2). AWS CLI v2 is installed correctly.

ⓧ I see version 1.x

You have an older version of the AWS CLI installed. The version 2 installer should overwrite it, but the old version may still be first in your PATH.

  • Check which binary is being used by running:
which aws

If it points to something other than /usr/local/bin/aws, you need to remove the old version or update your PATH.

  • Try running the full path directly:
/usr/local/bin/aws --version

If this shows version 2.x, add /usr/local/bin to the front of your PATH or remove the old CLI version, then restart your terminal.

ⓧ Command not found

The installer may not have completed successfully.

  • Confirm the downloaded file exists by running:
ls AWSCLIV2.pkg

If the file is there, re-run the install command. If the file is missing, re-run the curl command first. Make sure you enter your Mac password when prompted by sudo.

  • After re-installing, close and reopen Terminal, then try aws --version again.

Now configure the CLI with your IAM user credentials. The aws configure command will prompt you for four values in sequence.

  • Start the configuration wizard by running:
aws configure

What will aws configure ask me?

The command prompts you for four pieces of information, one at a time:

  • AWS Access Key ID - paste the access key ID from the CSV you downloaded earlier.
  • AWS Secret Access Key - paste the secret access key from the same CSV.
  • Default region name - type us-east-1.
  • Default output format - type json.

These values are stored in ~/.aws/credentials and ~/.aws/config on your Mac.

  • Verify your credentials are working by running:
aws sts get-caller-identity

You should see JSON output containing your account ID, user ARN, and user ID. This confirms the CLI can authenticate with AWS.

Seeing an authentication error?

If you see a message about invalid credentials, double-check that you pasted the access key ID and secret access key correctly from your CSV file. Re-run aws configure and carefully paste each value again.

If you accidentally closed the access key page without downloading the CSV, go back to the IAM console, delete the old key, and create a new one.

Help me fix my AWS CLI authentication error.

Now install PowerShell 7 using Homebrew.

  • Install PowerShell 7 by running:
brew install powershell

What does this install?

Homebrew downloads and installs PowerShell 7, which is Microsoft's cross-platform command shell. You need it because the Sentinel AWS S3 connector setup script is a PowerShell script.

  • Verify the installation by running:
pwsh --version

Check what you see in your terminal output:

✔️ I see version 7.x

You should see output like PowerShell 7.6.0 or similar (any 7.x version works). PowerShell is ready to use.

ⓧ I see an older version

If you see version 6.x or lower, you have an outdated PowerShell install.

  • Upgrade to the latest version by running:
brew upgrade powershell
  • After the upgrade completes, verify again with pwsh --version.

ⓧ Command not found

The Homebrew install may not have completed successfully.

  • Check for errors in the Homebrew output above. A common cause is a stale Homebrew cache.
  • Try updating Homebrew and reinstalling by running:
brew update && brew install powershell
  • If you previously installed PowerShell as a cask, uninstall it first by running brew uninstall --cask powershell, then re-run the formula install above.

You can now clean up the installer file you downloaded earlier.

  • Remove the downloaded package by running:
rm AWSCLIV2.pkg

Your accounts are created and your CLI tools are ready. Next up, you will deploy a Microsoft Sentinel workspace in Azure and connect your first data source.

Deploy Sentinel Workspace and Connect Azure Activity Logs

Your accounts are created and your CLI tools are installed. Now it's time to deploy the central piece of your multi-cloud SIEM: the Microsoft Sentinel workspace.

Microsoft Sentinel is a cloud-native SIEM that runs on top of a Log Analytics workspace. In this step, you'll create that workspace, enable Sentinel with its 31-day free trial, and connect Azure's own activity logs as your first data source.

In this step, get ready to:
  • Create a Log Analytics workspace and enable Microsoft Sentinel.
  • Connect Azure Activity logs as your first data source.
  • Generate telemetry by creating a test resource and verify data is flowing.
Create a Log Analytics workspace and enable Microsoft Sentinel

Before Sentinel can ingest any security data, it needs a Log Analytics workspace to store that data. You'll create a dedicated resource group and workspace, then enable Sentinel on top of it.

  • Return to the Azure portal at portal.azure.com.
  • In the search bar at the top, type Resource groups and select Resource groups from the results.
  • Click Create.
  • Select your subscription from the Subscription dropdown.
  • In the Resource group field, enter rg-sentinel-lab.
  • Set Region to East US.
  • Click Review + Create, then click Create.

Now create the Log Analytics workspace inside this resource group.

  • In the search bar, type Log Analytics and select Log Analytics workspaces.
  • Click Create.
  • Select your subscription from the Subscription dropdown.
  • Select rg-sentinel-lab from the Resource group dropdown.
  • In the Name field, enter sentinel-multicloud-lab.
  • Set Region to East US.
  • Click Review + Create, then click Create.
  • Wait for the deployment to complete.

What is a Log Analytics workspace?

A Log Analytics workspace is a data store for collecting log data from Azure and non-Azure resources. It's where Microsoft Sentinel stores all the security telemetry it ingests, and where you'll run KQL queries to analyze that data.

Now enable Microsoft Sentinel on the workspace.

  • In the search bar, type Microsoft Sentinel and select Microsoft Sentinel.
  • Click Create.
  • Select the sentinel-multicloud-lab workspace from the list.
  • Click Add.

What happens when you add Sentinel?

Adding Sentinel to a workspace enables the 31-day free trial, which includes 10 GB/day of data ingestion at no charge. Both Log Analytics data ingestion and Sentinel analysis charges are waived during this period.

As a new customer, your workspace is automatically onboarded to the Microsoft Defender portal at security.microsoft.com. You will be redirected there for all subsequent Sentinel operations. If this is your first time using the Defender portal, there will be a delay of a few minutes while the process completes.

  • When you see the redirect prompt or link to the Defender portal, follow it to security.microsoft.com.
  • Sign in with the same Azure credentials.
  • Wait a few minutes for the onboarding process to finish.

Bookmark the Defender portal

From this point forward, all Sentinel operations happen in the Defender portal at security.microsoft.com. Bookmark it now so you can return quickly.

Connect Azure Activity logs as your first data source

With Sentinel running in the Defender portal, you'll now install the Azure Activity solution from the Content hub and configure it to stream your subscription's activity logs into Sentinel.

  • In the Defender portal, navigate to Microsoft Sentinel in the left sidebar.
  • Select Content management, then Content hub.
  • Search for Azure Activity and select the Azure Activity solution.
  • In the solution details pane on the right, click Install.
  • Wait for the installation to complete.

Now configure the data connector to start forwarding activity logs.

  • Navigate to Microsoft Sentinel > Configuration > Data connectors.
  • Search for and select the Azure Activity data connector.
  • Click Open connector page.
  • On the connector page, click Launch Azure Policy Assignment Wizard.

What is the Azure Policy Assignment Wizard?

This wizard creates an Azure Policy that automatically configures Diagnostic Settings on your subscription. Those settings stream Azure Activity logs directly into your Log Analytics workspace, where Sentinel can analyze them.

  • On the Basics tab, click the scope selector (the button with three dots) and select your subscription. This scopes the policy to your entire subscription.
  • Click the Parameters tab.
  • Set Primary Log Analytics workspace to sentinel-multicloud-lab.
  • Click Review + create, then click Create.

Connector still showing Disconnected?

The Azure Activity connector can take 5-10 minutes to show as Connected after policy assignment. If it still shows Disconnected after 15 minutes, check that your Azure account has Owner permissions on the subscription. The policy assignment requires Owner role to create Diagnostic Settings.

help me troubleshoot why my Azure Activity connector is still Disconnected after running the Policy Assignment Wizard

Generate Azure activity to start telemetry flowing

The connector is configured, but you need to generate some activity in Azure so there are events for Sentinel to ingest. Creating a resource is the easiest way to produce telemetry quickly.

  • Return to the Azure portal at portal.azure.com.
  • In the search bar, type Storage accounts and select Storage accounts.
  • Click Create.
  • Select rg-sentinel-lab as the resource group.
  • Enter a unique name for the storage account (for example, sentineltestXXXX where XXXX is a random number).
  • Leave all other settings at their defaults.
  • Click Review + Create, then click Create.

Why create a storage account?

Creating any Azure resource generates activity log events (resource creation, role assignments, provider registrations). These events flow through the Diagnostic Settings you just configured and land in the AzureActivity table in your Sentinel workspace.

Now verify that Azure Activity telemetry is reaching Sentinel. This takes 5-10 minutes after creating the resource.

  • Return to the Defender portal at security.microsoft.com.
  • Navigate to Investigation & response > Hunting > Advanced hunting.
  • In the query editor, enter the following KQL query and click Run query:
AzureActivity | take 10

What does this query do?

AzureActivity is the table where all Azure subscription activity events land. The take 10 operator returns the first 10 rows. If you see results, telemetry is flowing successfully from Azure into Sentinel.

✔️ I see Azure Activity events

Your Azure Activity data connector is working. Telemetry from your subscription is now flowing into Sentinel.

ⓧ I see no results or an error

Data can take 5-10 minutes to appear after creating a resource. Wait a few more minutes and run the query again.

If you still see no results after 15 minutes, navigate back to Microsoft Sentinel > Configuration > Data connectors and confirm the Azure Activity connector shows a green Connected status. If it shows Disconnected, re-run the Policy Assignment Wizard and ensure you selected the correct subscription and workspace.

Your Sentinel workspace is live and ingesting Azure telemetry. Next up, you'll build the AWS CloudTrail pipeline to bring AWS security events into this same workspace.

Build the AWS CloudTrail Pipeline

Your Sentinel workspace is now receiving Azure Activity logs. That covers one cloud, but your goal is a multi-cloud SIEM.

To detect threats that cross cloud boundaries, you need telemetry from AWS as well. CloudTrail is the AWS equivalent of Azure Activity logs. It records every API call made in your AWS account and delivers those events as gzipped JSON files to an S3 bucket. In this step, you will create a CloudTrail trail, generate some real AWS activity, and confirm the logs land in S3.

In this step, get ready to:
  • Create a CloudTrail trail that captures management events to an S3 bucket.
  • Generate AWS activity that produces real security telemetry.
  • Verify CloudTrail log files are arriving in S3.
Enable CloudTrail in AWS

CloudTrail records management events like creating users, launching instances, and modifying security groups. The first copy of management events in each region is free from CloudTrail (you only pay minimal S3 storage costs for the log files).

  • In the AWS Management Console, use the search bar at the top and type CloudTrail.
  • Select CloudTrail from the results to open the CloudTrail dashboard.
  • In the left sidebar, click Trails.
  • Click Create trail.

On the Create Trail page, configure the following settings:

  • For Trail name, enter sentinel-lab-trail.
  • For Storage location, select Create new S3 bucket.
  • For the bucket name, enter sentinel-lab-cloudtrail- followed by your AWS account ID (e.g., sentinel-lab-cloudtrail-123456789012). S3 bucket names must be globally unique, so appending your account ID ensures uniqueness.
  • Leave Log file SSE-KMS encryption at the default setting (Enabled is fine, or you can disable it for simplicity).
  • Click Next.

On the Choose log events page:

  • Under Event type, confirm Management events is checked.
  • Under Management events, confirm both Read and Write are selected.
  • Do NOT check Data events. Data events incur additional charges and are not needed for this lab.
  • Click Next.
  • Review your settings on the summary page and click Create trail.

What is a management event?

Management events are API calls that modify or read the configuration of your AWS resources. Examples include creating an IAM user, launching an EC2 instance, or modifying a security group. These are the events that security teams monitor most closely.

Data events (which we disabled) track object-level operations like reading or writing individual S3 objects. They generate far more volume and cost extra.

Trail creation failed?

If you see an error about insufficient S3 bucket policies, the bucket name may already be taken (S3 bucket names are globally unique). Try a different name variation with your account ID.

If you see a permissions error, confirm your IAM user has AdministratorAccess attached.

help me troubleshoot my CloudTrail trail creation error

Generate AWS activity to populate the trail

CloudTrail delivers log files to S3 within 5-15 minutes of an API call. To give the trail some real events to capture, you need to perform a few actions in the AWS console.

  • Navigate to the IAM service using the search bar.
  • Click Policies in the left sidebar, then click Create policy.
  • Switch to the JSON tab, paste any simple policy (the default template is fine), and click Next.
  • Name the policy sentinel-test-policy and click Create policy.
  • Navigate to the EC2 service using the search bar.
  • Click Launch instance.
  • Give it any name (e.g., sentinel-test), keep the Amazon Linux AMI selected, and set the instance type to t2.micro (free tier eligible).
  • Under Key pair, select Proceed without a key pair.
  • Click Launch instance.
  • Once the instance reaches the Running state, select it and click Instance state > Terminate instance.
  • Navigate to S3 using the search bar.
  • Click Create bucket.
  • Name it sentinel-test-deleteme (or any unique name), leave all defaults, and click Create bucket.
  • Select the bucket you just created, click Delete, type the bucket name to confirm, and click Delete bucket.

Why all these random actions?

Each of these actions (creating an IAM policy, launching/terminating an EC2 instance, creating/deleting an S3 bucket) generates management events that CloudTrail records. These are the same types of events that a SIEM monitors for suspicious activity in production environments.

CloudTrail delivers log files within 5-15 minutes, so give it some time before checking the S3 bucket in the next substep.

Verify CloudTrail delivery to S3

After 5-15 minutes, CloudTrail will have delivered at least one batch of log files to your S3 bucket. The logs are stored as gzipped JSON files organized by account ID and region.

  • Navigate to S3 in the AWS console.
  • Click on your CloudTrail bucket (sentinel-lab-cloudtrail-{accountid}).
  • Navigate into the folder structure: AWSLogs/ > your account ID > CloudTrail/ > us-east-1/ > today's date folder.
  • Confirm you see .json.gz files listed. These are your CloudTrail log files.

What should I see?

You should see one or more files with names ending in .json.gz inside the path AWSLogs/{account-id}/CloudTrail/{region}/. These compressed JSON files contain the management events from the actions you just performed. Sentinel will ingest these files in the next step.

Don't see any log files yet?

CloudTrail can take up to 15 minutes to deliver the first batch of logs. Wait a few more minutes and refresh the S3 console.

Make sure you are looking in the correct bucket (the one you specified during trail creation, not the test bucket you created and deleted).

Verify the trail is active by going back to CloudTrail > Trails and confirming the Logging column shows On for sentinel-lab-trail.

help me find my CloudTrail logs in S3

Your AWS CloudTrail pipeline is now generating real security telemetry and storing it in S3. Next up, you will connect this S3 bucket to Microsoft Sentinel so both clouds feed into a single SIEM.

Connect AWS CloudTrail to Sentinel

Your CloudTrail trail is delivering security telemetry to S3. Now you need to build the bridge that lets Microsoft Sentinel read those logs from across the cloud boundary.

The AWS S3 connector uses an event-driven pipeline: your S3 bucket sends notifications to an SQS queue, and Sentinel assumes an IAM role via OIDC federation to pull the log files. A PowerShell script automates the creation of all these AWS resources for you.

In this step, get ready to:
  • Open the Amazon Web Services S3 data connector in the Defender portal.
  • Run the automated PowerShell setup script to create AWS resources.
  • Add the CloudTrail connection using the Role ARN and SQS URL.
Open the Amazon Web Services S3 connector page

The AWS S3 connector is the current-generation connector for ingesting CloudTrail, VPC Flow Logs, and GuardDuty findings into Sentinel. It replaces the legacy CloudTrail-only connector.

  • Switch back to the Microsoft Defender portal at security.microsoft.com.
  • Navigate to Microsoft Sentinel > Configuration > Data connectors.
  • Search for Amazon Web Services S3 in the data connectors gallery.
  • Click Open connector page in the details pane.

Don't see the connector?

If the Amazon Web Services S3 connector is not listed, you need to install the Amazon Web Services solution from the Content hub first. Search for it under Content hub in the Defender portal and click Install.

Run the PowerShell setup script

Microsoft provides an automated PowerShell script that creates all the AWS-side resources Sentinel needs. This includes an OIDC identity provider, an IAM role, an SQS queue, and S3 bucket event notifications.

  • On the connector page, expand the Configuration section.
  • Under 1. Set up your AWS environment, expand Setup with PowerShell script (recommended).
  • Copy the Workspace ID (External ID) shown on the connector page. Save this in a text file for the next step.
  • Click the AWS S3 Setup Script download link to download the zip file containing the main setup script and helper scripts.
  • Extract the downloaded zip file to a location you can find easily, such as your Desktop.

Now you will open PowerShell, verify your AWS credentials, and run the setup script.

  • Open PowerShell 7 by running this command in your Terminal:
pwsh
  • Confirm your AWS credentials are configured by running:
aws configure

What does this command do?

Running aws configure shows your current credentials (access key, secret key, region, output format). Press Enter through each prompt to keep your existing values. If the fields are blank, re-enter the credentials from Step 1.

  • Navigate to the folder where you extracted the setup script.
  • Copy the command shown on the connector page under Run script to set up the environment and paste it into your PowerShell prompt.
  • When the script prompts you for your Workspace ID, paste the Workspace ID (External ID) you copied earlier from the connector page.

What does the script create?

The script automates four things in your AWS account:

  • An OIDC identity provider that lets Microsoft Entra ID authenticate to AWS.
  • An IAM role named with the prefix OIDC_MicrosoftSentinelRole that grants Sentinel read access to your S3 bucket and SQS queue.
  • An SQS queue that receives notifications whenever new log files land in S3.
  • S3 bucket event notifications on your CloudTrail bucket that send to the new SQS queue.

The script may take up to 30 minutes

The setup script creates multiple AWS resources and configures permissions. Be patient and let it run to completion. Do not close the PowerShell window.

  • When the script finishes, it outputs a Role ARN and an SQS URL. Copy both values and save them in a text file.

Script failing with a credentials error?

Make sure you ran aws configure inside the same pwsh session and that your access key and secret key are correct. Run aws sts get-caller-identity to verify the credentials resolve to your IAM user.

Help me troubleshoot the AWS S3 setup script failing in PowerShell.

Add the CloudTrail connection

With the AWS resources created, you now register the connection on the Sentinel connector page so it knows where to pull CloudTrail logs from.

  • Return to the Amazon Web Services S3 connector page in the Defender portal.
  • Scroll down to 2. Add connection.
  • Paste the Role ARN into the Role to add field.
  • Paste the SQS URL into the SQS URL field.
  • Select AWSCloudTrail from the Destination table drop-down list.
  • Click Add connection.

What does the Destination table do?

The Destination table tells the connector which AWS service's logs this connection collects and which Log Analytics table stores the ingested data. Selecting AWSCloudTrail routes CloudTrail management events into the AWSCloudTrail table in your workspace.

  • Verify that the connector status changes to green (Connected).

Data takes 20-30 minutes to appear

A green connector status means a collection rule exists. It does not mean data has been ingested yet. It takes around 20-30 minutes from the moment the connector is connected until data appears in the workspace.

While you wait, you can check the connector's health by running this KQL query in the Logs blade:

  • Confirm the connector health by navigating to the Logs blade and running this query:
SentinelHealth | where SentinelResourceKind == "AmazonWebServicesS3" | take 10

What does this query do?

The SentinelHealth table tracks the operational status of your data connectors. Filtering by AmazonWebServicesS3 shows health events specific to your AWS S3 connector. If you see rows appearing, the connector is actively polling your SQS queue.

Connector status not showing Connected?

Double-check that the Role ARN starts with arn:aws:iam:: and the SQS URL starts with https://sqs.. Make sure you copied the full values from the script output without trailing spaces.

Help me troubleshoot my AWS S3 connector not showing Connected status in Sentinel.

Your multi-cloud pipeline is live. Sentinel is now pulling CloudTrail management events from AWS alongside your Azure Activity logs. Next, you will write KQL queries that correlate activity across both clouds and create an analytics rule for cross-cloud detection.

Build Cross-Cloud Detection with KQL

Your multi-cloud SIEM now has telemetry flowing from two independent cloud environments into a single workspace. The real power of this setup is the ability to query, correlate, and alert on activity spanning both clouds from one place.

In this step, you will write KQL queries that pull from both data sources simultaneously and create a scheduled analytics rule that detects suspicious cross-cloud activity in real time.

In this step, get ready to:
  • Confirm both AWS and Azure data sources are flowing with KQL queries.
  • Write a cross-cloud correlation query that finds shared IP addresses.
  • Create a scheduled analytics rule for real-time cross-cloud detection.
Query both data sources

Before writing complex correlation queries, you need to confirm that both data sources are actively delivering events to your workspace.

  • In the Defender portal (security.microsoft.com), navigate to Microsoft Sentinel > Configuration > Logs.
  • Run the following KQL query to confirm AWS data is flowing:
AWSCloudTrail
| take 10

What does this query do?

This pulls the 10 most recent events from the AWSCloudTrail table. If rows appear, your AWS S3 connector is successfully delivering CloudTrail management events to Sentinel.

  • Run this query to confirm Azure data is still flowing:
AzureActivity
| take 10
  • Run this union query to visualize data from both clouds in a single result:
union AWSCloudTrail, AzureActivity
| summarize count() by Type
| render piechart

What does this query do?

The union operator merges rows from both tables into a single result set. The summarize count() by Type groups events by their source table name, and render piechart visualizes the distribution as a pie chart.

This is your first "single pane of glass" view across both clouds.

You should see a pie chart with slices for both AWSCloudTrail and AzureActivity data.

Not seeing AWS data?

The AWS S3 connector takes 20-30 minutes from the time you connected it for data to appear. If your previous step was recent, wait and try again.

You can check connector health by running:

SentinelHealth
| where SentinelResourceKind == "AmazonWebServicesS3"
| take 10

help me troubleshoot why my AWSCloudTrail table is empty in Sentinel

Write a cross-cloud correlation query

A compromised credential might be used across multiple cloud environments. Finding IP addresses that appear in both AWS and Azure activity within the same time window is a powerful detection signal.

  • Run the following cross-cloud correlation query in the Logs blade:
// Cross-cloud IP correlation: find IPs active in both AWS and Azure within 24 hours
let timeframe = 24h;
let AWSIPs = AWSCloudTrail
| where TimeGenerated > ago(timeframe)
| where isnotempty(SourceIpAddress)
| summarize AWSEventCount = count(), AWSFirstSeen = min(TimeGenerated), AWSLastSeen = max(TimeGenerated) by SourceIpAddress;
let AzureIPs = AzureActivity
| where TimeGenerated > ago(timeframe)
| where isnotempty(CallerIpAddress)
| summarize AzureEventCount = count(), AzureFirstSeen = min(TimeGenerated), AzureLastSeen = max(TimeGenerated) by CallerIpAddress;
AWSIPs
| join kind=inner (AzureIPs) on $left.SourceIpAddress == $right.CallerIpAddress
| project IPAddress = SourceIpAddress, AWSEventCount, AWSFirstSeen, AWSLastSeen, AzureEventCount, AzureFirstSeen, AzureLastSeen

What does this query do?

  • The let statements create two temporary tables: one summarizing IP addresses from AWSCloudTrail (using the SourceIpAddress column) and one from AzureActivity (using the CallerIpAddress column).
  • The join kind=inner finds only IP addresses that appear in both tables.
  • The final project outputs the matched IP with event counts and time ranges from both clouds.
  • An IP appearing in both environments could indicate legitimate shared infrastructure, or a compromised credential being used across cloud boundaries.

If you see results, those are IP addresses (likely your own) that have been active in both AWS and Azure within the last 24 hours.

No results yet?

If your query returns zero rows, that is normal. It means no single IP address has appeared in both clouds within your 24-hour window yet. The analytics rule you create next will catch future matches automatically.

Create a scheduled analytics rule

An analytics rule takes your correlation query and runs it automatically on a schedule. When it finds matching results, Sentinel creates an incident for investigation.

  • In the Defender portal, navigate to Microsoft Sentinel > Configuration > Analytics.
  • Click Create > Scheduled query rule.
  • On the General tab, enter Cross-Cloud Suspicious Activity as the rule name.
  • Set the Severity to Medium.
  • Click Next: Set rule logic.
  • In the Rule query field, paste your cross-cloud correlation query:
// Cross-cloud IP correlation: find IPs active in both AWS and Azure within 24 hours
let timeframe = 24h;
let AWSIPs = AWSCloudTrail
| where TimeGenerated > ago(timeframe)
| where isnotempty(SourceIpAddress)
| summarize AWSEventCount = count(), AWSFirstSeen = min(TimeGenerated), AWSLastSeen = max(TimeGenerated) by SourceIpAddress;
let AzureIPs = AzureActivity
| where TimeGenerated > ago(timeframe)
| where isnotempty(CallerIpAddress)
| summarize AzureEventCount = count(), AzureFirstSeen = min(TimeGenerated), AzureLastSeen = max(TimeGenerated) by CallerIpAddress;
AWSIPs
| join kind=inner (AzureIPs) on $left.SourceIpAddress == $right.CallerIpAddress
| project IPAddress = SourceIpAddress, AWSEventCount, AWSFirstSeen, AWSLastSeen, AzureEventCount, AzureFirstSeen, AzureLastSeen
  • Under Query scheduling, set Run query every to 5 minutes.
  • Set Lookup data from the last to 24 hours.

Why 5 minutes and 24 hours?

The 5-minute frequency means Sentinel re-runs the query every 5 minutes looking for new matches. The 24-hour lookup period is the time window the query searches through.

This combination catches cross-cloud activity quickly while giving enough historical context to correlate events that happen hours apart.

  • Click Next: Incident settings and leave the defaults (incident creation enabled).
  • Click Next: Automated response and skip automation for now.
  • Click Next: Review and create.
  • Review your settings, then click Save.

Your rule now appears in the Active rules list with the name Cross-Cloud Suspicious Activity.

What about entity mapping?

During rule creation, Sentinel may prompt you to map entities. Map the IP address entity to the IPAddress column from your query results. This allows Sentinel to enrich incidents with IP context and connect related alerts.

Rule not appearing in Active rules?

Make sure you clicked Save on the final review page. If the rule shows as Disabled, toggle it to Enabled from the Active rules list.

help me get my Sentinel analytics rule to show as active

Your multi-cloud SIEM is now fully operational. You have real security telemetry from two independent cloud environments flowing into a single workspace, with automated detection running every 5 minutes.

Secret mission

Add GuardDuty as a Second AWS Data Source

You have CloudTrail management events flowing into Sentinel, but real SOC teams monitor threat intelligence feeds too. Amazon GuardDuty generates security findings that detect suspicious activity like cryptocurrency mining, credential exfiltration, and anomalous API calls. Can you add GuardDuty as a second AWS data source and build a workbook that visualizes both pipelines?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses resources in both AWS and Azure that stay within free tiers for approximately 30 days.

Cost warning

The Microsoft Sentinel free trial covers 10 GB/day ingestion for 31 days. AWS CloudTrail includes one free management events trail per region. S3 storage for logs costs only pennies.

After 31 days, Sentinel begins charging for data ingestion and analysis. If you are not actively using the lab, choose Pause or Delete to avoid unexpected charges.

Resources you used:

  • Azure: Resource group rg-sentinel-lab (contains Log Analytics workspace sentinel-multicloud-lab and Microsoft Sentinel).
  • AWS: CloudTrail trail sentinel-lab-trail.
  • AWS: S3 bucket sentinel-lab-cloudtrail-{accountid} (plus GuardDuty findings bucket/prefix if you completed the Secret Mission).
  • AWS: Two SQS queues (CloudTrail and GuardDuty).
  • AWS: IAM role with prefix OIDC_MicrosoftSentinelRole.
  • AWS: OIDC identity provider (for Sentinel federation).
  • AWS: Amazon GuardDuty (if enabled for the Secret Mission).

Keep everything running

No action needed. Choose this if you are still actively exploring the lab and want to keep ingesting telemetry.

  • Your Sentinel free trial covers ingestion for 31 days from activation.
  • CloudTrail's first management events trail is free in each region.
  • S3 storage costs will remain minimal (pennies per month for log files).
  • AWS CLI and PowerShell remain installed on your machine.

Pause - I'll come back to this later

Shut down active log generation to free up ingestion capacity without deleting your workspace or connector configuration.

  • In the AWS Management Console, navigate to CloudTrail, select sentinel-lab-trail, and click Stop logging.
  • If you enabled GuardDuty for the Secret Mission, navigate to GuardDuty and choose Suspend GuardDuty to pause finding generation.
  • Your Sentinel workspace and connector configurations remain intact. When you resume, re-enable CloudTrail logging and GuardDuty.

Delete - I don't want to use this again

Remove all project resources from both clouds and start fresh. Follow these steps in order.

Delete Azure resources
  • Deleting the resource group removes the Log Analytics workspace, Sentinel, all connectors, analytics rules, and workbooks in one step.
  • In the Azure portal, search for Resource groups, select rg-sentinel-lab, and click Delete resource group.
  • Type the resource group name to confirm, then click Delete.
Delete AWS CloudTrail trail
  • Delete the trail by running:
aws cloudtrail delete-trail --name sentinel-lab-trail
Empty and delete the S3 bucket
  • Empty and remove the CloudTrail S3 bucket by running:
aws s3 rb s3://sentinel-lab-cloudtrail-{accountid} --force
  • If you created a separate bucket for GuardDuty findings, empty and remove it the same way using its bucket name.
Delete the SQS queues
  • Delete each SQS queue using its URL (replace the placeholder with the URL you recorded earlier):
aws sqs delete-queue --queue-url https://sqs.us-east-1.amazonaws.com/YOUR_ACCOUNT_ID/YOUR_QUEUE_NAME
  • Repeat for the second SQS queue (GuardDuty) if you completed the Secret Mission.
Delete the IAM role and OIDC provider
  • In the AWS Management Console, navigate to IAM then Roles.
  • Search for OIDC_MicrosoftSentinelRole, select it, and click Delete. The console automatically detaches managed policies before deletion.
  • Navigate to IAM then Identity providers.
  • Select the OIDC provider created for Sentinel, then click Delete and type delete to confirm.
Disable GuardDuty (Secret Mission only)
  • If you enabled GuardDuty, navigate to the GuardDuty console, open Settings, scroll to the bottom, and choose Suspend GuardDuty or Disable GuardDuty.

That's a Wrap!

That's a Wrap!

Nice work! You've just built a fully operational multi-cloud SIEM lab where Microsoft Sentinel ingests real security telemetry from both AWS and Azure in a single pane of glass.

This is the exact architecture enterprise security teams use to detect threats across cloud boundaries. You now have hands-on proof that you can operate a SIEM at multi-cloud scale.

You've learned how to:

  • Deploy a Microsoft Sentinel workspace and ingest security telemetry from both AWS CloudTrail and Azure Activity logs simultaneously.
  • Configure the AWS S3 connector pipeline using S3 bucket event notifications, SQS queues, and OIDC IAM federation to securely stream logs into Sentinel.
  • Write cross-cloud KQL queries correlating events across cloud boundaries and create a scheduled analytics rule for real-time detection.
  • Secret Mission: Added GuardDuty as a second AWS data source and built a Sentinel Workbook visualizing both CloudTrail and GuardDuty data.

Ready to quiz yourself?