Your security operations center was built to monitor on-premises infrastructure. Firewall logs, endpoint detections, Active Directory events, and network flow data all fed into a central console. Then your organization moved workloads to the cloud. And then to a second cloud. And now your SOC has a visibility problem it was never designed to solve.
Cloud environments generate security-relevant telemetry in fundamentally different formats, through different APIs, with different retention policies, and using different identity models than on-premises infrastructure. The organizations that get cloud security monitoring right treat it as a SOC problem, not just a cloud engineering problem. The cloud team configures the environment. The SOC monitors it for threats. When those two functions are disconnected, misconfigurations go undetected, identity-based attacks fly under the radar, and the first sign of a cloud breach is often a billing alert for cryptocurrency mining on your account.
Why Cloud Security Monitoring Is Different
Three characteristics create unique monitoring challenges. First identity is the perimeter: in cloud environments, an attacker with valid cloud credentials can access any resource the identity is authorized to reach, regardless of where the attacker is physically located. Your SOC must shift from monitoring network traffic to monitoring identity behavior. Second everything is an API call: every action in a cloud environment is logged, but a moderately complex AWS environment generates millions of CloudTrail events per day. Third misconfiguration is the primary attack vector: publicly exposed storage buckets, overly permissive IAM policies, and unencrypted data stores create the conditions for an attack before any exploit occurs.
AWS: Critical Telemetry Sources
CloudTrail (critical logs every API call across all AWS services), GuardDuty (high pre-built threat intelligence findings), VPC Flow Logs (high network traffic metadata for lateral movement detection), S3 Access Logs (medium object-level access for exfiltration detection), IAM Access Analyzer (medium external access findings for misconfiguration detection). The most important data source is CloudTrail it logs every API call, including the identity, source IP, timestamp, and parameters. Your SOC can detect nearly every cloud attack through CloudTrail analysis alone if detection rules are properly tuned.
Azure: Critical Telemetry Sources
Azure Activity Log (critical subscription-level operations), Entra ID Sign-in Logs (critical authentication and conditional access events), Entra ID Audit Logs (high directory changes including role assignments and app registrations), NSG Flow Logs (high network traffic between Azure resources), Key Vault Audit Logs (medium access to secrets, keys, and certificates). For Azure environments, Entra ID logs are arguably more important than the activity log because identity-based attacks against Azure AD are the most common cloud attack vector in the Microsoft ecosystem.
GCP: Critical Telemetry Sources
Cloud Audit Logs Admin Activity (critical resource configuration changes, always on and free), Cloud Audit Logs Data Access (high data read/write operations, must be explicitly enabled for sensitive services like BigQuery and Cloud Storage), VPC Flow Logs (high network traffic for lateral movement detection), Security Command Center (medium threat and misconfiguration findings). Ensure data access logging is enabled for sensitive services it is not on by default and generates high volume, but it is essential for detecting data exfiltration.
Five Cloud-Specific Detection Rules Every SOC Should Deploy
1. Root or Organization Admin usage alert on any API call made by the AWS root account, Azure Global Administrator, or GCP Organization Admin outside of documented break-glass scenarios. 2. IAM policy changes that expand access monitor for policies that attach administrative-level permissions; this is the cloud equivalent of adding yourself to Domain Admins. 3. Public exposure of storage resources alert on S3 bucket policies that include 'Principal: *', Azure Storage containers set to public access, and GCP Storage changes that add allUsers. 4. Unusual cross-region or cross-account activity maintain an allowlist of regions your organization uses and alert on resource creation outside those regions. 5. Mass data access patterns establish per-identity baselines and alert when any identity exceeds its 30-day rolling average data access volume by more than 5x.
Multi-Cloud Monitoring: The Normalization Challenge
Most organizations run workloads across at least two cloud providers. Creating a virtual machine is `RunInstances` in AWS, `Microsoft.Compute/virtualMachines/write` in Azure, and `compute.instances.insert` in GCP. Your analysts should not need to memorize three different vocabularies to investigate the same type of event. A unified SOC platform that normalizes cloud telemetry at ingestion allows analysts to write one detection rule that covers equivalent actions across all three providers. This normalization also enables cross-source correlation between cloud events and on-premises telemetry an attacker who phishes a credential through email, uses it to authenticate to AWS, escalates IAM permissions, and exfiltrates data creates a signal chain that spans both environments. Only a platform that normalizes and correlates across both can connect that full attack narrative.
Building Cloud Security Monitoring Into Your SOC
Weeks 1-2: Enable comprehensive logging in all cloud environments and route all logs to your SOC platform. Weeks 3-4: Deploy the five detection rules above. Month 2: Establish behavioral baselines for cloud identity activity. Month 3: Integrate cloud detection with your broader SOC automation workflows build playbooks that automatically revoke IAM credentials on confirmed compromise, revert public storage policies, and isolate compromised workloads. For organizations that need cloud security monitoring but lack internal expertise, Helxon's SOC as a Service includes cloud-native detection and response coverage across AWS, Azure, and GCP through the VORXOC platform. See the integrations page for the full list of supported cloud connectors.