Integrating AWS Security Hub into Microsoft Sentinel

Hello Milt

Thank you for reaching out to Microsoft Q&A.

It sounds like you’re wondering what role that Kinesis Firehose resource plays in the AWS→Sentinel pipeline. Here’s the short answer:

• In the Microsoft-published CloudFormation template, the Firehose delivery stream is what subscribes to your CloudWatch Logs and funnels them into an S3 bucket (in the right format)

• Microsoft Sentinel’s AWS connector then pulls those log files from S3—Sentinel itself doesn’t talk directly to CloudWatch Logs

• In other words, Firehose is the glue between CloudWatch Logs and the S3-based ingestion that Sentinel expects

If you already have all your CloudWatch Logs centralized in a Log-Archive account (and maybe even landing in an S3 bucket there), you can:

1. Modify or skip the CFN Firehose resource and instead point the ingestion Lambda/S3 connector at your existing bucket
2. Make sure you’ve set up the necessary cross-account IAM roles/policies so the Sentinel side (in the monitoring account) can read that bucket
3. Confirm your logs are in the supported format (CSV GZIP for CloudWatch, no header)—you can leverage the CloudWatch → Lambda conversion if needed

Reference docs

• Connect AWS data to Microsoft Sentinel (includes S3-based CloudWatch guidance):

https://learn.microsoft.com/azure/sentinel/connect-aws?tabs=s3#prerequisites

• CloudWatch → Lambda converter (CSV GZIP formatting for Sentinel):

https://learn.microsoft.com/azure/sentinel/cloudwatch-lambda-function

• Enable health monitoring on your Sentinel connector:

https://learn.microsoft.com/azure/sentinel/enable-monitoring?tabs=azure-portal#turn-on-auditing-and-health-monitoring-for-your-workspace

Let us know the above steps helps

Thanks

Hello Milt

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.

@Shubham Sharma (160015)

I have previously did the set up for S3 connector for VPC Flow Logs, CloudWatch Logs, CLoudTrail and GuardDuty. So I an existing S3 bucket for CW Logs.

The security hub connector is a separate connector in Microsoft; however, it references the CloudWatch logs that already exists and are going to an S3 bucket.

With this being said, would I be able to reference the same S3 bucket that's storing all the CW Logs and Sentinel S3 Connector references? Would Sentinel Security Hub Logs be able to differentiate between Security Hub Logs and the ones from CloudWatch logs with S3 connector?

What you posted here was set up already: https://learn.microsoft.com/en-us/azure/sentinel/connect-aws?tabs=s3#prerequisites

What would be the best solution this?

Milt

Thank you for your reply.

Yes, you can reuse the same S3 bucket that already stores centralized CloudWatch logs for Security Hub ingestion into Microsoft Sentinel — as long as the logs are stored in separate paths and wired to separate SQS queues / connections.

Microsoft Sentinel does not rely on bucket-level differentiation. It distinguishes log types by connector configuration (destination table + SQS path), not by “auto-detection” inside the bucket.

How Sentinel differentiates AWS log types (important)

According to Microsoft’s official AWS S3 connector documentation:

“Different types of logs can be stored in the same S3 bucket, but shouldn't be stored in the same path.”

https://learn.microsoft.com/en-us/azure/sentinel/connect-aws?tabs=s3

and:

“A single SQS queue can serve only one path in an S3 bucket.”

This means:

Sentinel does not inspect file contents to decide log type. The connector configuration tells Sentinel what those logs are.

Security Hub–specific clarification

1. Security Hub is not ingested via CloudWatch Logs

Security Hub findings are native Security Hub findings, not CloudWatch Logs.

In the Microsoft AWS integration model:

CloudWatch logs → CSV GZIP format in S3 → AWSCloudWatch table

Security Hub findings → JSON (via AWS service export) → AWSSecurityHub table

Sentinel treats these as separate data types, even if they land in the same bucket.

https://learn.microsoft.com/en-us/azure/sentinel/connect-aws

Do you need Kinesis Firehose?

No — not if your logs already land in S3.

From Microsoft’s point of view:

Sentinel never talks to CloudWatch Logs directly

Sentinel only pulls from S3 via SQS notifications

The Kinesis Firehose in the Microsoft-provided CloudFormation template exists only to help customers who do NOT already export logs to S3.

If you already have:

CW Logs → centralized S3

GuardDuty → centralized S3

Security Hub → centralized S3

Then Firehose is optional and can be skipped.

This aligns with Microsoft’s guidance that the connector pulls logs from S3, not CloudWatch or Security Hub APIs.

https://learn.microsoft.com/en-us/azure/sentinel/connect-aws?tabs=s3

Below is the recommended solution:-

Reuse the existing centralized S3 bucket

Ensure Security Hub findings export to:

s3://central-log-archive/securityhub/

Create:

1 SQS queue for securityhub/

1 Sentinel AWS S3 connector connection

In Sentinel:

Destination table → AWSSecurityHub

Keep CloudWatch, VPC Flow, CloudTrail, GuardDuty on their existing paths/queues

https://learn.microsoft.com/en-us/azure/sentinel/connect-aws?tabs=s3