Why Cloud Threat Detection Is Different from On-Prem
On-premises threat detection is fundamentally network-centric. You instrument firewalls, switches, and routers; you deploy IDS sensors at choke points; you watch for anomalous traffic crossing known boundaries. The perimeter is a real physical thing you can draw on a diagram.
Cloud environments do not work this way. The "network" is a software abstraction that changes constantly as resources are provisioned and deprovisioned. The IAM layer — identity and access management — is effectively the new perimeter: a compromised identity can move from S3 to Lambda to RDS to a completely different AWS account using nothing but valid API credentials, generating no suspicious network traffic whatsoever.
This creates three fundamental differences in how cloud threat detection must work:
- API calls are the primary signal, not network packets. In AWS, almost every action a human or service takes generates a CloudTrail API event. Monitoring CloudTrail is the equivalent of watching every command a user executes — it is the primary telemetry plane for cloud security.
- Identity is the attack surface. Overprivileged IAM roles, long-lived access keys, missing MFA, and federation misconfigurations are the cloud equivalents of open firewall ports. Detecting their abuse requires behavioral analysis of API call patterns, not network traffic inspection.
- The environment is ephemeral. A workload that spins up, gets compromised, exfiltrates data, and terminates within 20 minutes may not be running by the time a signature-based alert fires. Real-time threat detection is a hard requirement, not a nice-to-have.
AWS: The Log Sources That Actually Matter
AWS generates an enormous volume of telemetry — too much to monitor without prioritization. Security engineers evaluating AWS security monitoring should focus on four primary sources that provide the highest signal-to-noise ratio for threat detection.
CloudTrail: Your Primary Detection Plane
AWS CloudTrail records every API call made to your AWS account — authentication events, resource creation and deletion, configuration changes, and data access. It is the single most valuable data source for cloud threat detection. Critical event categories to alert on include:
- Console logins without MFA from root or privileged IAM users
- IAM policy changes — new policies attached, existing policies made more permissive, new IAM roles created
- GetCallerIdentity calls in rapid succession from a new or unusual source — a classic reconnaissance pattern
- AssumeRole across accounts — especially to roles with administrative permissions in other AWS accounts
- Security service modifications — CloudTrail trail deletion, GuardDuty disable, Config rule changes, S3 bucket logging disabled
- CreateAccessKey for existing IAM users, particularly if the user is not the one making the call
GuardDuty: ML-Based Anomaly Detection
AWS GuardDuty applies machine learning to CloudTrail, DNS, and VPC Flow Logs to surface behavioral anomalies — cryptocurrency mining, C2 communication patterns, credential exfiltration. It produces moderate-fidelity findings that are valuable as enrichment signals but should not be your only detection layer. GuardDuty findings should feed into a centralized SIEM rather than be treated as standalone alerts, because they lack the cross-account and cross-service correlation context that reveals attack chains.
VPC Flow Logs: Network Context for API Detections
VPC Flow Logs capture accepted and rejected network connections within your VPC. They are most valuable as corroborating evidence for API-layer detections: if a compromised EC2 instance is making outbound connections to unusual destinations at the same time CloudTrail shows unusual API calls, the combination is a high-confidence incident. On their own, VPC Flow Logs generate substantial false-positive noise.
S3 Access Logs and Data Events
S3 data events in CloudTrail record individual GetObject and PutObject operations at the object level. Enabling data events for sensitive buckets lets you detect mass download operations — a common data exfiltration pattern — and access from unexpected IAM principals. Pair this with bucket policy auditing: a bucket that had its public access block removed quietly is a critical misconfiguration that most teams never alert on.
Azure: Key Detection Sources in Microsoft Environments
Azure threat detection centers on the identity plane (Azure AD / Entra ID) and the management plane (Azure Activity Log), with supplementary signals from Microsoft Defender for Cloud and individual service logs.
Azure AD / Entra ID Sign-In Logs
Azure AD sign-in logs are the most critical source for identity-focused threat detection in Microsoft environments. Key indicators to monitor include: sign-ins from impossible travel (two authentications from geographically separated locations within a physically impossible time window), sign-ins from Tor exit nodes or anonymizing VPN services, MFA bypass events (legacy authentication protocols like POP3/IMAP don't support MFA and are frequently targeted), and conditional access policy failures followed by a successful authentication (suggesting an attacker is probing for policy gaps).
Azure Activity Log
The Azure Activity Log records every management-plane operation — resource creation, deletion, RBAC changes, policy modifications. High-value detection events include new role assignments at the subscription or management group level, deletion of audit diagnostic settings, Azure Policy modifications that loosen compliance rules, and creation of new service principals with owner-level permissions.
Microsoft Defender for Cloud
Defender for Cloud provides its own set of security alerts across Azure services — SQL injection detection, suspicious access patterns in storage accounts, anomalous outbound network traffic from VMs. These alerts are useful enrichment signals but are typically lower fidelity than purpose-built detection rules. Feed them into a centralized detection platform rather than treating Defender findings as your primary detection mechanism.
GCP: What to Monitor in Google Cloud
Google Cloud's primary detection surfaces are Cloud Audit Logs, Security Command Center (SCC), and IAM activity — with network telemetry from VPC Flow Logs filling in the network layer.
Cloud Audit Logs
GCP Cloud Audit Logs are the equivalent of CloudTrail — they record Admin Activity, Data Access, and System Event logs across all GCP services. Admin Activity logs are enabled by default and capture all resource configuration changes. Data Access logs must be explicitly enabled per service and generate high volume — enable them only for services containing sensitive data (Cloud Storage, BigQuery, Cloud SQL) to keep costs and noise manageable.
Security Command Center
GCP's Security Command Center aggregates findings from its built-in threat detection services: Event Threat Detection (cloud-native threat detection using audit logs), Container Threat Detection (runtime anomaly detection for GKE), and Virtual Machine Threat Detection. SCC findings should be exported to a centralized SIEM — the native SCC interface lacks the cross-project correlation context needed to identify multi-project attack chains.
IAM and Service Account Monitoring
GCP's service account model is a common attack surface. Service account keys — especially long-lived, widely distributed JSON key files — are the most frequently compromised credential type in GCP breaches. Monitor for: new service account key creation, service accounts granted project-owner or organization-level IAM bindings, impersonation of high-privilege service accounts via the Service Account Token Creator role, and workload identity federation misconfigurations that allow external identities to assume GCP service accounts.
Data exfiltration via misconfigured S3 buckets and GCS buckets is the most commonly missed cloud threat vector — not because detection is difficult, but because most teams never enable the data event logging required to see it. An attacker who discovers a publicly accessible bucket can exfiltrate terabytes of data without generating a single alert in a default monitoring configuration. Enabling S3 data events and GCS data access audit logs for sensitive buckets, and alerting on access from unexpected principals or unusual volume patterns, closes this blind spot completely.
The Multi-Cloud Problem: Unified Detection Across Providers
Eighty-three percent of organizations use multiple cloud providers. The security problem with multi-cloud is not monitoring each environment individually — it is connecting the dots across environments when an attacker moves between them.
A sophisticated attacker who compromises an AWS IAM user may pivot to an Azure AD account via a federated identity connection, then exfiltrate data through a misconfigured GCP Cloud Storage bucket. If you're running three separate monitoring stacks — one per cloud — this attack chain is invisible in any single console. Each provider's events look benign in isolation. The attack only becomes visible when you correlate identity, API activity, and data access events across all three providers in a unified timeline.
This is the architectural requirement for effective cloud security monitoring in multi-cloud environments: a single normalized telemetry layer that ingests events from all providers, maps them to a common data model, and enables cross-provider correlation rules and behavioral baselines.
Real-Time vs Batch Detection in Cloud Environments
Cloud infrastructure is ephemeral in a way that on-prem infrastructure is not. An attacker who compromises a Lambda function or a Kubernetes pod in a CI/CD pipeline may complete their attack objective — credential theft, data exfiltration, cryptominer deployment — within minutes of initial access. By the time a batch detection job runs four hours later, the compromised resource may no longer exist.
Real-time detection is not optional in cloud environments. Streaming architectures — consuming cloud provider log streams directly via services like AWS Kinesis, Azure Event Hubs, or GCP Pub/Sub — enable detections that fire within seconds of an event occurring rather than hours. The tradeoff is cost and complexity: streaming at scale requires careful architectural planning. But for high-priority detection use cases — root account usage, security control modification, mass data access — the response time difference between real-time and batch detection is the difference between catching an attacker in progress and discovering them after they're gone.
How ZonForge Sentinel Ingests Cloud Telemetry
ZonForge Sentinel was designed from the ground up for multi-cloud environments. Rather than building separate monitoring stacks per provider, the platform normalizes all cloud telemetry into a unified data model on ingest — so a user identity event from AWS, Azure AD, and Okta are represented the same way and can be correlated in a single detection rule or behavioral baseline.
Conclusion
Cloud threat detection requires a fundamentally different approach from on-premises monitoring. The primary attack surface is the API and identity layer, not the network. The primary telemetry source is management-plane API logs, not packet captures. And the detection architecture must be real-time, not batch — because cloud infrastructure is too ephemeral to wait hours for a detection to fire.
AWS CloudTrail, Azure AD sign-in logs, and GCP Cloud Audit Logs are your highest-value detection sources. But monitoring each cloud provider in isolation creates the multi-cloud blind spot that sophisticated attackers deliberately exploit. Effective cloud security monitoring requires a unified platform that normalizes and correlates telemetry across all providers into a single detection layer.
ZonForge Sentinel's multi-cloud architecture handles exactly that — ingesting, normalizing, and correlating cloud telemetry from AWS, Azure, GCP, Okta, and M365 into unified behavioral baselines and cross-provider detection rules, so your team sees the full attack chain rather than isolated events in three separate consoles.
Frequently Asked Questions
Cloud threat detection centers on API call monitoring and identity behavior rather than network traffic inspection. In cloud environments, there is no physical network perimeter to monitor — the primary attack surface is IAM and API credentials. Attackers who compromise valid API keys or IAM roles can move laterally and exfiltrate data without generating suspicious network traffic. This means CloudTrail, Azure AD logs, and GCP Audit Logs — not network sensors — are the primary detection telemetry in cloud environments.
The highest-signal CloudTrail events for threat detection are: console logins without MFA (especially root), IAM policy modifications (new policies, privilege escalation), AssumeRole cross-account calls, security service modifications (GuardDuty disable, CloudTrail trail deletion), CreateAccessKey for existing users, and mass S3 GetObject operations from unexpected principals. GetCallerIdentity calls in rapid succession are a reliable reconnaissance signal. Security group modifications that open broad inbound access are also worth monitoring in real time.
Lateral movement in cloud environments typically occurs through role assumption (AssumeRole), service account impersonation, or using compromised credentials to access services beyond the initial entry point. Detection requires correlating API activity across accounts and services: an IAM user that normally only accesses S3 and suddenly begins assuming EC2, Lambda, and IAM management roles is exhibiting lateral movement behavior. Cross-account role assumption chains, particularly those that terminate in accounts with organizational admin permissions, are especially high-risk patterns to monitor.
Unified multi-cloud threat detection requires a centralized platform that normalizes telemetry from all providers into a common data model. Each provider uses different field names, event formats, and identity representations — an IAM user in AWS, a service principal in Azure, and a service account in GCP are conceptually equivalent but structurally different in the raw log format. A platform that normalizes these into a unified identity entity model can run cross-provider correlation rules that identify attack chains spanning multiple cloud environments, which is impossible with per-provider native monitoring tools.
Cloud-native tools (AWS GuardDuty, Azure Defender, GCP SCC) provide useful baseline detection with zero configuration overhead, and you should run them. But they have significant limitations: they only see their own provider's telemetry, lack cross-provider correlation, and are difficult to customize with environment-specific detection logic. A cloud SIEM or dedicated cloud threat detection platform provides the unified normalized layer needed for multi-cloud correlation, custom detection rules, behavioral baselines, and the investigation workflow your analysts need to respond effectively. Use cloud-native tools as enrichment signal sources, not as your primary detection architecture.