About Author
Mark Duke
Mark Duke is CTO and co-founder of enhanced.io. He designed the company's SOC architecture and oversees all technical delivery.
enhanced.io, the channel-only Open XDR SOCaaS for MSPs
TL;DR
Fragmented visibility across AWS, Azure, and GCP creates blind spots that a single-cloud tool cannot close.
Ingestion and correlation work the same way across all three, once normalized into a common schema.
The monitoring layer sits alongside existing cloud-native tools, not in place of them.
Correlation across clouds catches lateral movement that cloud-native tools, scoped to one environment, miss.
This extends the same pipeline used across endpoint, network, and identity sources.
enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT. That correlation extends across cloud environments the same way it does across on-premises sources.
Most MSPs did not choose to support three clouds. Their clients did, one acquisition and one department at a time.
The multi-cloud visibility problem
Each cloud provider's native monitoring tool is scoped to that provider's environment. A client running workloads across AWS, Azure, and GCP ends up with three separate views, each blind to what is happening in the other two.
The pattern you will see is an attacker moving between cloud environments specifically because no single native tool is watching the transition.
How enhanced.io ingests and correlates
Before correlation | After correlation |
|---|---|
AWS activity visible only in AWS-native tooling | AWS, Azure, and GCP activity in one timeline |
Azure activity visible only in Azure-native tooling | Cross-cloud movement flagged as one event |
GCP activity visible only in GCP-native tooling | Identity and on-premises data included in the same view |
Ingestion pulls logs from each cloud provider's native APIs, normalizes them into a common schema, and correlates activity across all three alongside on-premises and identity data. This follows the same normalization and correlation pipeline used across the wider Open XDR architecture.
A common pattern: credentials compromised in one cloud environment get reused to access resources in a second cloud environment minutes later. Viewed separately, in each provider's own console, that looks like two unrelated logins. Correlated together, it is a single incident.
The result is a single timeline of activity, regardless of which cloud an action occurred in. This same principle underpins the wider threat visibility approach across AWS, Microsoft 365, and Azure.
Where enhanced.io sits in the architecture
The monitoring layer sits alongside the MSP's existing cloud-native tools and cloud security posture management, not in place of them. It adds cross-cloud correlation on top of what those tools already provide within their own scope.
What this means in practice is no migration of existing cloud tooling is required to add this layer.
Multi-cloud correlation is one piece of the same architecture covered in the technical case for Open XDR over legacy SIEM. See the full approach at enhanced.io.
If a client's environment already spans two or more clouds, that is worth a scoping conversation now, before the next cross-cloud incident makes the case for you.
About enhanced.io
enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT. It sells only through MSP partners, never direct to end clients, and integrates with the EDR or MDR an MSP already runs rather than replacing it.
FAQ
Does this replace AWS GuardDuty, Azure Defender, or Google Security Command Center?
No. It ingests from these native tools and correlates across them, rather than replacing any single provider's monitoring.
How does this handle clients who only use one cloud provider today?
What is the most common blind spot in multi-cloud environments?
Does multi-cloud monitoring increase alert volume?
How does this fit with compliance reporting across regions?
Can this scale across many client tenants with different cloud combinations?