12.3 AWS and Google Cloud Platform SOC Architectures

AWS SOC Telemetry and Threat Detection Architecture

Building a mature Security Operations Center capable of monitoring Amazon Web Services (AWS) environments requires configuring and ingesting foundational telemetry streams across the control plane, virtual network fabric, and managed compute services. Understanding the operational purpose, logging formats, and detection capabilities of AWS-native security services is a core requirement for certified SOC analysts.

1. AWS CloudTrail: Management vs. Data Events and Log Validation

AWS CloudTrail is the primary audit logging service for AWS. It records supported API and non-API account activity as CloudTrail events. Coverage depends on the service, event type, Region, trail or event-data-store configuration, and selectors; data and network-activity events are not enabled in trails by default. CloudTrail categorizes events into two distinct logging types:

• Management Events (Control Plane): Records management operations performed on or within an AWS account. Examples include configuring security groups (AuthorizeSecurityGroupIngress), provisioning compute instances (RunInstances), attaching IAM policies (AttachUserPolicy), and administrative console logins (ConsoleLogin). CloudTrail Event history provides the past 90 days of management events in each Region without a charge for viewing that history. For an ongoing centralized record, organizations configure an appropriately scoped trail or CloudTrail Lake event data store and protect the destination; S3 is one common trail destination, not the only design.
• Data Events (Data Plane): Records high-volume resource operations performed within or on specific AWS resources. Examples include Amazon S3 object-level API calls (GetObject, PutObject, DeleteObject), AWS Lambda function invocations (Invoke), and DynamoDB table queries. Because data events generate immense volume, they are disabled by default and incur additional ingestion costs; however, they are critical for detecting data exfiltration from sensitive object storage.

Multi-Region Trails: A common SOC best practice is deploying a Multi-Region Trail when broad commercial-Region coverage is required. Adversaries who obtain compromised administrative credentials frequently launch malicious resources (such as cryptomining instances) in obscure or dormant commercial regions (e.g., af-south-1 or ap-northeast-3) where the organization has no active business operations. A multi-region trail automatically records API activity across all commercial regions and delivers logs to a centralized S3 bucket in the designated security account.

Log File Integrity Validation: To defend against adversaries who attempt to delete or alter CloudTrail logs in S3 to cover their tracks, CloudTrail provides Log File Integrity Validation. Every hour, CloudTrail generates a Digest File that cryptographically hashes the log files delivered during the preceding hour using SHA-256 and signs the digest with an asymmetric private key. SOC analysts use aws cloudtrail validate-logs to validate the digest chain and detect missing or modified delivered log files within the configured trail, time range, and available digest history. Validation does not prove that every relevant event was enabled, generated, delivered, or retained.

2. AWS VPC Flow Logs: Cloud Network Traffic Analysis

AWS VPC Flow Logs captures metadata regarding IP traffic flowing to and from network interfaces (Elastic Network Interfaces, or ENIs) within a Virtual Private Cloud (VPC). VPC Flow Logs can be published directly to Amazon CloudWatch Logs or Amazon S3.

Each flow log entry contains a standard 5-tuple alongside cloud metadata fields:

<version> <account-id> <interface-id> <srcaddr> <dstaddr> <srcport> <dstport> <protocol> <packets> <bytes> <start> <end> <action> <log-status>

• Action Field (ACCEPT vs. REJECT): A sudden surge in REJECT records on an internal database interface can be a lead for scanning, misconfiguration, or attempted lateral movement. ACCEPT records on an unexpected outbound port can likewise support a command-and-control or exfiltration hypothesis, but flow metadata alone does not establish application content or malicious intent.
• VPC Flow Log Limitations: VPC Flow Logs capture network metadata only; they do not capture packet payloads or HTTP headers. For deep packet inspection (DPI), SOCs deploy AWS Network Firewall or traffic mirroring to open-source IDS sensors (such as Suricata or Zeek).

3. AWS GuardDuty: Intelligent Threat Detection

AWS GuardDuty is a managed threat detection service that continuously monitors AWS accounts and workloads without requiring host agents. GuardDuty’s baseline and optional protection plans analyze several AWS telemetry sources. The exact set evolves; important examples include:

1. AWS CloudTrail Management & Data Events (evaluating administrative API anomalies and S3 object tampering).
2. VPC Flow Logs (detecting outbound communication with known malicious IPs, Tor exit nodes, or mining pools).
3. DNS Query Logs (detecting domain generation algorithms [DGA] and DNS data exfiltration).
4. EKS Audit Logs (evaluating Kubernetes control plane interactions).

GuardDuty combines threat-intelligence context and anomaly or behavioral models over its enabled foundational sources and protection features. The exact sources, models, finding types, and severities evolve, so analysts should consult the current finding details and documentation.

AWS GuardDuty Finding Types & SOC Triage Guide

4. AWS Security Hub and Amazon Detective

• AWS Security Hub: Serves as the central security posture management (CSPM) and alert aggregation console. It ingests findings from GuardDuty, Amazon Inspector (vulnerability scanning), Amazon Macie (sensitive data discovery), and AWS IAM Access Analyzer, normalizing all alerts into the standard AWS Security Finding Format (ASFF).
• Amazon Detective: An automated forensic investigation service. Detective uses supported AWS telemetry to construct an interactive behavior graph that links entities and activity across time. It helps analysts investigate root cause and scope, but conclusions still require validation against source evidence, coverage, and context.

---

Google Cloud Platform (GCP) SOC Telemetry & Detection Architecture

Google Cloud Platform organizes security operations around centralized logging infrastructure, perimeter defense mechanisms, and hyper-scale security analytics.

1. GCP Cloud Audit Logs: Four Distinct Logging Streams

Google Cloud Audit Logs capture administrative and data interactions across all GCP projects. The architecture categorizes audit events into four distinct streams:

1. Admin Activity Logs: Records API calls that modify resource configuration or metadata (e.g., creating a Compute Engine instance, modifying Cloud Storage bucket permissions, or altering IAM roles). Admin Activity logs are enabled by default and stored in the system-created _Required bucket, whose current 400-day retention cannot be changed. The bucket’s protected behavior is stronger than ordinary storage, but “immutable” should be reserved for a specifically locked retention design.
2. Data Access Logs: Records API calls that read or write user-provided data within GCP resources (e.g., querying a BigQuery dataset, reading an object from Cloud Storage, or accessing a secret in Secret Manager). Data Access logs are divided into Admin Read, Data Read, and Data Write. Because of massive volume, they are disabled by default (except for BigQuery) and incur log ingestion costs.
3. System Event Logs: Records automated configuration changes executed by Google infrastructure systems on the customer's behalf (e.g., automated VM live migration during hardware maintenance or autoscaling events).
4. Policy Denied Logs: Generated when a principal is denied access by certain security-policy mechanisms, including VPC Service Controls; coverage varies by service and policy type.

2. VPC Service Controls & Google Cloud Armor

• VPC Service Controls (VPC SC): Allows security engineers to define a service perimeter around supported Google-managed services (e.g., Cloud Storage, BigQuery, Cloud Bigtable). Even if an attacker possesses legitimate service account credentials with administrative IAM permissions, any API call originating from outside the designated perimeter or unauthorized network boundary is rejected and logged in Policy Denied audit logs, reducing exfiltration risk for requests that violate the configured perimeter. It does not replace IAM, data governance, logging, or controls on permitted paths.
• Google Cloud Armor: Enterprise edge protection deployed at Google's global load balancers. Cloud Armor provides enterprise Distributed Denial of Service (DDoS) defense and a Web Application Firewall (WAF) that mitigates OWASP Top 10 web vulnerabilities and enforces geo-fencing and custom IP rate limiting.

3. Security Command Center (SCC)

Security Command Center (SCC) is Google Cloud's centralized risk, posture, and threat-management platform. Feature and detector availability varies by service tier and configuration; current documentation should be checked because tier names and availability change over time.

• Security Health Analytics (SHA): The CSPM engine that automatically audits GCP assets against CIS benchmarks (detecting open ports, unencrypted disks, and public buckets).
• Event Threat Detection (ETD): Analyzes the Cloud Logging stream in real time using proprietary threat intelligence and machine learning to detect active attacks (e.g., cryptocurrency mining, malware installation, brute-force SSH, and anomalous IAM grant additions).
• Container Threat Detection (CTD): Uses low-level instrumentation in the guest kernel of supported GKE nodes and a user-mode DaemonSet that sends event and container context to a detector service. Enabled modules can detect supported runtime behaviors such as added-binary execution, suspicious scripts, and other container attacks; findings and coverage depend on tier, platform, and module state.

4. Google Cloud Chronicle / Security Operations (Google SecOps)

Google Security Operations (formerly Chronicle) is a cloud security-analytics platform for normalized telemetry, search, investigation, and detection. Key operational components include:

• Unified Data Model (UDM): Chronicle ingests raw multi-cloud and on-premises logs and normalizes them into structured UDM entities. UDM standardizes naming conventions across all vendors into universal nouns (principal, target, network, security_result, about).
• YARA-L 2.0 Detection Language: A specialized detection modeling language created by Google for authoring threat detections over normalized UDM data. YARA-L enables multi-event correlation, thresholding, and sliding time windows over normalized telemetry; performance depends on the query, data, retention tier, and platform configuration.

---

Multi-Cloud SOC Integration & Detection Strategies

Most modern enterprises operate across multiple cloud providers simultaneously (e.g., running production workloads in AWS, enterprise identity and collaboration in Azure/M365, and machine learning analytics in GCP). The SOC must avoid creating operational silos by implementing cross-cloud telemetry normalization and centralized log lake architectures.

Multi-Cloud Telemetry & Service Mapping Matrix

Multi-Cloud Log Aggregation Architecture

To achieve unified detection, organizations aggregate multi-cloud telemetry into a central repository:

1. AWS Forwarding Pipeline: CloudTrail and GuardDuty findings are delivered to an S3 bucket in a central AWS Log Archive account. An Amazon Simple Notification Service (SNS) topic and Amazon Simple Queue Service (SQS) queue notify external collectors. The central SIEM (e.g., Sentinel or Chronicle) reads from SQS and pulls logs over an encrypted HTTPS connection.
2. Azure Forwarding Pipeline: Azure Event Hubs streams Entra ID logs, Azure Activity logs, and Defender alerts to third-party endpoints or central workspaces in real time.
3. GCP Forwarding Pipeline: GCP Cloud Logging routes audit logs via a Log Sink to a Cloud Pub/Sub topic, which streams messages to the enterprise SIEM collector.

Cross-Cloud Identity Tracking

Attackers operating in multi-cloud environments frequently traverse cloud boundaries using single sign-on (SSO) credentials. A threat actor who compromises an on-premises or Entra ID user account may leverage SAML 2.0 federation to authenticate into an AWS IAM role or a GCP Google Cloud Identity account. SOC analysts correlate cross-cloud activity by tracking stable identifiers and documented federation mappings across disparate log streams: matching the UserPrincipalName (UPN) or Federated Subject Identifier (sub) in Entra ID sign-in logs with the assumed-role session name in AWS CloudTrail and the principalEmail in GCP Cloud Audit Logs.