Cloud Logging — The Seven Log Sources & Centralised Architecture

Why Logging Comes First

You cannot investigate what you cannot see. In cloud environments, where no physical access is possible and resources are ephemeral, logs are the primary — and often only — source of forensic evidence. Before you deploy any workload, your logging architecture should already be running.

A common mistake is treating logging as a post-deployment optimisation. In practice, an incident that occurs before logging is configured may leave no recoverable evidence. Enable logging on day one.

The Seven Cloud Log Sources

Every cloud workload generates logs across seven distinct categories:

#	Log Source	What It Records	AWS Service	Azure Service
1	Management/Control Plane	API calls to create, modify, delete resources	CloudTrail	Activity Log
2	Data Plane	Read/write operations on data services	S3 Access Logs, CloudTrail data events	Storage Analytics Logs
3	Network Flow	IP traffic between resources	VPC Flow Logs	NSG Flow Logs
4	Application/Service	Application errors, performance, custom events	CloudWatch Logs	Application Insights
5	Authentication	Login events, MFA, token issuance	CloudTrail (IAM events), Cognito logs	Azure AD Sign-in Logs
6	Change/Configuration	Resource configuration changes over time	AWS Config	Azure Policy / Resource Graph
7	Billing/Usage	Service consumption and cost anomalies	Cost and Usage Report	Azure Cost Management

The Three Most Critical Logs for Security

CloudTrail (Management Plane): Records every API call made against your AWS account — who made it, from where, when, on what resource, and what the result was. This is the primary forensic data source for any AWS incident. It must be enabled in all regions, including opt-in regions, and the log bucket must be protected with S3 Object Lock.

VPC Flow Logs: Records metadata (not packet content) for every network flow in your VPC: source IP, destination IP, ports, protocol, bytes transferred, and accept/reject decision. Essential for detecting lateral movement, data exfiltration, and C2 communication.

AWS Config: Continuously records the configuration of your AWS resources and evaluates them against compliance rules. If an S3 bucket is accidentally made public, Config records the before/after state and can trigger automated remediation.

Centralised Logging Architecture

Centralising logs from all accounts, regions, and services into a single location gives security teams unified visibility and prevents attackers from covering their tracks by deleting logs in a compromised account.

Reference Architecture

Account A CloudTrail → S3 Log Archive Bucket (central, dedicated account)
Account B CloudTrail ↗                          ↓
Account C CloudTrail ↗               Amazon Athena (SQL queries over logs)
                                               ↓
VPC Flow Logs → CloudWatch Logs → Kinesis Firehose → OpenSearch / SIEM
                                               ↓
Application Logs → CloudWatch Logs →      GuardDuty findings

Key Design Principles

1. Dedicated logging account: Keep logs in a separate AWS account with restricted access. Compromising the production account should not give access to logs.
2. Object Lock on log buckets: WORM (Write Once, Read Many) protection prevents even account administrators from deleting log files — critical for tamper-evident logging.
3. Cross-region log aggregation: CloudTrail must be enabled in all regions, including regions you do not actively use (attackers may provision resources in unused regions).
4. Log integrity validation: CloudTrail includes a hash-based validation mechanism that detects any modification or deletion of log files after they are written.
5. Retention policy: CERT-In 2022 mandates 5-year log retention. RBI IT Framework requires similar periods for financial institutions. Set S3 lifecycle policies to transition logs from S3 Standard to S3 Glacier for cost-efficient long-term retention.

What to Alert On

Not all log events are equal. High-priority alerts to configure from day one:

Event	Log Source	Risk
root account login	CloudTrail	Root should never be used operationally
DeleteTrail or StopLogging	CloudTrail	Attacker covering tracks
CreateUser + AttachUserPolicy rapid sequence	CloudTrail	New admin account creation
Mass GetObject from S3 bucket	S3 Access Logs	Data exfiltration
SSH from new source IP	VPC Flow Logs	Potential unauthorised access
GetSecretValue from Lambda with no recent invocations	CloudTrail	Credential harvesting
Security group modified to allow 0.0.0.0/0:22	Config	SSH exposure

Key Takeaway

Logging is not a compliance checkbox — it is the foundation of cloud security operations. The seven log sources together give you visibility from the API layer to the network layer to the data layer. Centralise them, protect them with Object Lock, retain them for five years, and alert on high-priority events from day one.