Cloud Forensics: How DFIR Differs in AWS, Azure, and GCP Environments

When organisations move workloads to cloud environments, their assumptions about digital forensics often come with them. Those assumptions are wrong in important ways. On-premises forensics relies on persistent disk images, local log stores, and physical access to hardware. Cloud forensics relies on log data that may not have been enabled, may be stored in a separate account or tenant, and may be subject to retention periods the organisation never configured.

The result is that cloud incident response has a different threat model for evidence loss than on-premises. In an on-premises breach, the risk is that an attacker covered their tracks. In a cloud breach, a significant risk is that the organisation simply never had the logs to begin with. We see this regularly in engagements where a cloud environment was provisioned for speed rather than security.

AWS: What Logs Exist and What You Need to Enable

In AWS environments, the primary audit log source is CloudTrail, which records API calls across the account. CloudTrail is not enabled by default for all regions or for all event types. Management events are logged by default in most configurations, but data events covering object-level operations in storage services and function invocations must be explicitly enabled. If data events were not enabled before the incident, evidence of what an attacker read, copied, or deleted from storage buckets may not exist.

Additional log sources include VPC Flow Logs, which capture network traffic metadata at the subnet or interface level, and service-specific logs from load balancers, database services, and container platforms. In our AWS investigations, we typically find that management-plane activity is well-logged but data-plane activity is not. That distinction matters a great deal when the investigation question is what data the attacker accessed, not just how they got in.

Azure: Tenant-Level Logs and Retention Defaults

Azure environments use a combination of the Activity Log, sign-in logs, audit logs from the identity service, and resource-level diagnostic logs. The Activity Log captures subscription-level operations and is retained for 90 days by default. Sign-in and audit logs from the identity service have a default retention of 30 days for standard licences and 90 days for higher-tier licences. If an investigation is triggered more than 30 days after the initial compromise, identity-related evidence may already be gone.

The pattern we see in Azure investigations is that centralised log collection to a log analytics workspace was planned but not fully implemented. Individual resource diagnostic logs must be configured to stream to the workspace; they do not arrive there automatically. This means that in a multi-resource environment, coverage is often patchy. Investigating which resources had diagnostic logging enabled, and for what period, is itself a significant step in the early triage of an Azure incident.

GCP: Project-Level Logging and the Importance of Data Access Audit Logs

Google Cloud Platform separates audit logs into three categories: Admin Activity logs (always enabled, retained for 400 days), Data Access logs (disabled by default for most services, retained for 30 days when enabled), and System Event logs (always enabled). The absence of Data Access logging is the most common forensic gap we encounter in GCP investigations. Without it, there is no record of who read what data, only of who changed configuration or permissions.

GCP also offers organisation-level log sinks that can route audit logs to long-term storage. Where these sinks exist and are correctly configured, the forensic picture is significantly better. Where they do not, investigation scope may be limited to the last 30 days of Data Access logs at best, and no data access history at worst. Cloud forensics in GCP often involves as much archaeology of the logging configuration as it does analysis of the logs themselves.

Cloud Forensics Across Providers: Common Themes

Despite their differences, cloud forensic investigations share common challenges regardless of provider:

• Logs must be enabled in advance; they cannot be reconstructed retroactively
• Default retention periods are often too short for meaningful incident investigation
• Centralised log collection requires deliberate configuration, not just deployment of the logging service
• Identity and access logs are among the most valuable sources in cloud investigations but are frequently the most poorly retained
• Multi-account and multi-tenant environments require investigation across multiple log sources that may not be aggregated
• Evidence preservation in cloud environments requires snapshot and export procedures different from on-premises imaging

The practical implication is that cloud forensic readiness is a configuration question, not just a response question. Organisations that have enabled comprehensive logging, extended retention, and centralised collection will have far better forensic outcomes than those that have not. We recommend reviewing cloud logging configuration as a standard part of any security baseline assessment.

If you are responding to a cloud security incident or want to assess your cloud forensic readiness before one occurs, contact Cyberlinx at info@cyberlinx.com.au. We work across all major cloud environments and can help you understand what evidence would exist if an incident happened today.