Cloud Forensics

Cloud forensics is the analytical discipline applied to systems where the examiner does not own the hardware, the storage is multi-tenant, the compute is ephemeral, and the evidence acquisition runs through provider APIs rather than physical access. The methodology has compressed from the early-2010s framing where cloud was a special case of on-premises forensics into a parallel discipline with its own primary artifacts, its own acquisition workflows, and its own structural limitations. The traditional forensic question (what happened on this system) translates to cloud as a multi-layered question: what happened in the user’s account, on which resources, through which API calls, by which principals, with which permissions, observed through which provider audit log. The answer almost always involves the provider’s logs more than the workloads themselves.

This page covers the discipline as it actually exists in 2026: the control plane / data plane distinction that organizes most cloud forensic work, the audit logs that are the primary forensic surface (CloudTrail, Azure Activity Log, Google Cloud Audit Logs), the AWS / Azure / GCP forensic surfaces in detail, container and Kubernetes forensics, serverless forensics, SaaS forensics (Microsoft 365, Google Workspace, Slack, GitHub, Salesforce), the IAM “who could do what” analysis that drives most cloud incident response, the cloud-native forensic tools, and the jurisdictional and legal framework that constrains cross-border cloud evidence. The methodology assumes familiarity with the on-premises forensic surface covered in the other subpages.

The shared responsibility model assigns different layers of the stack to the customer and to the provider; the forensic visibility runs along the same lines. The customer has full visibility into their own workloads (the EC2 instances, the data on their EBS volumes, the contents of their S3 buckets) and into the audit logs of the actions they performed (CloudTrail). The provider has visibility into the infrastructure layer (the hypervisor, the storage substrate, the network fabric), and the customer’s forensic access to that layer is restricted to whatever the provider exposes through APIs and logs. The forensic methodology adapts to the boundary: the customer-side surface is rich, the provider-side surface is opaque, and engagements that require provider-side data follow a legal-process workflow rather than a technical one.

The cloud forensic surface

The cloud forensic surface organizes into several distinct layers, each with its own data sources, retention characteristics, and acquisition mechanisms.

The control plane is the management layer where cloud resources are created, modified, and destroyed. Every cloud action (launching an EC2 instance, modifying an IAM policy, accessing an S3 object when configured, assuming a role, modifying a Lambda function) produces a control plane log entry. The control plane logs are the single most important forensic surface in cloud environments. They preserve the chain of API calls that produced the observed state, the principals that made those calls, the source IP addresses, the timestamps, and (in most cases) whether each call succeeded.

AWS’s control plane log is CloudTrail, which records nearly every AWS API call. Azure’s equivalent is the Activity Log (for resource-level actions) plus the Microsoft Entra ID audit and sign-in logs (for identity actions). GCP’s equivalent is the Cloud Audit Logs, divided into Admin Activity, Data Access, System Event, and Policy Denied streams.

The data plane is the layer where the workloads themselves operate. EC2 instances run their workloads, S3 buckets serve content, RDS databases process queries, Lambda functions execute. Data plane forensic visibility is the customer’s responsibility. The customer enables the appropriate logging, captures the appropriate snapshots, and configures the appropriate telemetry. The provider’s view of the data plane is restricted to what the customer has configured the provider to observe.

The network plane sits across both, covered in detail in the Network Forensics subpage. VPC Flow Logs (AWS), NSG Flow Logs (Azure), VPC Flow Logs (GCP), and the equivalent products preserve connection-level metadata for cloud-internal traffic. The flow logs are the network forensic baseline for cloud environments.

The identity layer is its own surface. IAM is the foundation of cloud access control, and IAM-related forensics (who has which permissions, who used which credentials when, which roles were assumed and by whom) is a substantial fraction of cloud incident response. The identity logs (CloudTrail for AWS IAM, Microsoft Entra ID sign-in and audit logs for Azure, Cloud Audit Logs for GCP IAM, plus the role-assumption records each provider maintains) constitute the identity forensic surface.

The storage layer has its own audit surface. S3 access logs, Azure Storage Account logs, GCS audit logs, and the equivalent products record per-object access where enabled. The logs are typically opt-in (not enabled by default in some providers’ configurations) and the historical visibility is whatever the customer enabled before the activity of interest.

Configuration history. AWS Config, Azure Resource Graph (with change history), and GCP Cloud Asset Inventory record the configuration state of cloud resources over time. The forensic value is substantial (establishing what a resource’s configuration was at a specific point in the past), but the surface depends on the service being enabled and configured.

A modern cloud forensic engagement typically pulls from several layers in parallel: CloudTrail (or equivalent) for the API-level activity, VPC Flow Logs for network observations, IAM records for the identity context, configuration history for the resource state, S3 / storage access logs where enabled, application logs from the workloads themselves, and any provider-side security findings (GuardDuty, Microsoft Defender for Cloud, Security Command Center).

The ephemerality problem

The single largest methodological challenge in cloud forensics is that the resources of interest may not exist by the time the investigation begins.

Auto-scaling groups terminate instances when load decreases. The instance that hosted a compromised process at 14:00 may have been replaced by a different instance at 14:30 in response to a scaling event. The disk, the memory, and the local logs of the original instance are gone.

Container instances exit. A Docker container that ran for ten minutes and was replaced by a fresh container has no persistent state outside of what it explicitly wrote to durable storage. The container’s filesystem is gone; the running processes are gone.

Serverless functions execute and terminate, often in under a second. AWS Lambda, Azure Functions, and Google Cloud Functions instances may exist for the duration of a single invocation. The function’s runtime state survives only in whatever the function logged to CloudWatch Logs (or equivalent) and whatever it persisted to external storage.

Spot instances can be terminated by the provider with two minutes’ notice when capacity is reclaimed. The forensic visibility into spot instance state at the moment of termination depends on whether the customer captured the relevant artifacts before the termination signal fired.

The mitigations are entirely architectural. There is no acquisition technique that recovers a Lambda function that exited two days ago. The methodology has to either ensure the forensic surface lives outside the ephemeral resource (logs to a durable destination, snapshots taken on a schedule, telemetry shipped to a SIEM in real time), or accept that the historical view of ephemeral compute is restricted to what the persistent layer captured.

The practical implication is that cloud forensic readiness is more about the architecture than about the acquisition tooling. An environment where Lambda functions log nothing has minimal forensic visibility into Lambda activity; an environment where Lambda functions log to a structured destination retained for 90 days has substantial visibility. The architectural decisions made before the incident determine what the forensic engagement can recover.

AWS forensics

AWS is the dominant cloud provider and the forensic surface is the most developed. A working tour.

CloudTrail is the central artifact. The service records nearly every AWS API call across the account: who called it (the IAM principal: user, role, federated identity), when, from which source IP, against which resource, with what parameters, and what the outcome was. The default configuration covers management events (resource creation, modification, deletion, access); the optional data event logging covers per-object access (S3 GetObject, Lambda invocations, DynamoDB queries) at substantial volume and cost. CloudTrail logs ship to S3 by default and can also stream to CloudWatch Logs and EventBridge for real-time processing.

The CloudTrail log structure is JSON, with fields including eventTime, eventSource (the service), eventName (the API call), userIdentity (the principal), sourceIPAddress, requestParameters, and responseElements. The schema is documented and stable enough that custom analytical tools (AWS Athena queries against CloudTrail in S3, Splunk/SIEM ingest pipelines, jq-based command-line analysis) work reliably.

The forensic limitations of CloudTrail are worth knowing: data events are off by default (and expensive to enable across all resources); the retention in CloudWatch Logs is whatever the customer configured; the log delivery has a delay (typically minutes, occasionally longer); and the historical CloudTrail is limited to 90 days through the management console (the long-term retention is in S3, where the customer manages it).

VPC Flow Logs cover the network plane, addressed in Network Forensics.

S3 access logging records per-object access against an S3 bucket: the requester, the operation (GET, PUT, DELETE), the object, the time, the source IP, the bytes transferred. The logging is configured per-bucket and ships to a designated logging bucket. S3 access logs are the primary forensic record for “who accessed which objects when” in S3-resident data. CloudTrail data events for S3 cover the same surface with slightly different structure and at additional cost.

AWS Config records configuration history for AWS resources. Every change to a resource’s configuration produces a Config item that records the new state, the change, and the time. The service is the source of truth for “what was this resource’s configuration on date X” questions, which come up routinely in cloud forensic engagements (was this security group open to the internet on the date the intrusion began? was this S3 bucket public? was MFA enforced on this user?).

GuardDuty is AWS’s managed threat detection service. The service ingests CloudTrail, VPC Flow Logs, and DNS logs and produces structured findings (compromised credential indicators, suspicious instance behavior, cryptocurrency mining detections, port scan observations). GuardDuty findings are themselves a forensic artifact: they record what AWS-side detection observed, with timestamps and resource attribution.

Detective is AWS’s investigation-oriented service. The service correlates CloudTrail, VPC Flow Logs, GuardDuty findings, and other sources into a graph-based view that supports pivoting through related activity. Detective is positioned for the investigation phase rather than the detection phase; the forensic workflow uses it to trace the lateral movement and the chain of API calls associated with a suspected incident.

EBS snapshots are the standard mechanism for forensic acquisition of EC2 instance disks. The acquisition workflow:

1. Snapshot the EBS volume of the suspect instance through the AWS API.
2. Optionally copy the snapshot to a different region or a forensic AWS account for isolation.
3. Create a new EBS volume from the snapshot and attach it to a dedicated forensic instance.
4. Image the volume from the forensic instance using standard imaging tools (dc3dd, dd), producing a portable forensic image.
5. Record the snapshot ID, the CloudTrail entries for the snapshot operations, and the hash of the resulting image as part of the chain of custody.

The snapshot-based acquisition workflow is the AWS equivalent of “image the disk” in on-premises forensics. The chain of custody includes the CloudTrail records of the snapshot, copy, and attach operations. The provider’s audit log substitutes for the physical chain that a hardware-write-blocker workflow would provide.

EC2 instance memory acquisition. Memory acquisition from EC2 instances is harder than disk acquisition. The provider does not generally expose hypervisor-level memory dumps. The available techniques are: install a memory acquisition tool on the instance (the standard Linux/Windows tools from the Forensic Acquisition and Imaging page), use AWS Systems Manager to run the acquisition remotely, or use AWS’s coredump features for instance crash dumps.

Lambda forensics. Lambda execution leaves traces in CloudWatch Logs (whatever the function logged), CloudTrail (the invocation records and any AWS API calls the function made), X-Ray (if enabled, the execution traces), and the function’s effects on downstream resources. The Lambda runtime itself does not survive the function’s exit. Forensic reconstruction of Lambda activity depends entirely on the structured logging that the function code performed.

S3 object forensics. Examining an S3 object preserves an object’s contents at the time of acquisition; the S3 object versioning (when enabled) allows historical versions of the object to be examined. The chain of custody for S3-resident evidence pulls from CloudTrail (the acquisition’s API calls) and from the object’s metadata (the ETag is the MD5 of the object’s content).

IAM artifact analysis. The IAM Credential Report records when each user’s password and access keys were last used and last rotated. The IAM Access Analyzer surfaces resources accessible from outside the account. The role assumption records in CloudTrail trace which roles were assumed by whom and when. The combination is the forensic surface for the IAM “who could do what” question.

Azure forensics

Microsoft’s forensic surface is structurally similar to AWS but with different naming conventions and integration patterns.

The Activity Log is the Azure equivalent of CloudTrail at the resource level. Records control-plane operations against Azure resources: who initiated, what resource, what action, what outcome. The Activity Log is accessible through the Azure portal, the REST API, and the various Azure CLI / PowerShell tools, and can stream to Event Hubs and to Storage Accounts for retention.

Microsoft Entra ID (formerly Azure AD). The identity layer is Entra ID, which produces audit logs (configuration changes: user creation, group membership changes, application registrations) and sign-in logs (authentication events: successful and failed sign-ins, conditional access policy evaluations, MFA outcomes). The sign-in logs are particularly forensically valuable because they include the user-agent, the source IP, the device used, the application accessed, and the conditional access verdict. For incidents involving compromised credentials or session hijacking, the sign-in logs are the primary forensic surface.

Microsoft Defender for Cloud is Azure’s managed security service. The service ingests Activity Log, Defender for Server agents, network telemetry, and various other sources and produces security findings and recommendations. The findings are forensically useful as Azure-side observations of suspicious activity.

Microsoft Sentinel is Azure’s cloud-native SIEM. The service is positioned for both detection and investigation; the analytical workflow uses Sentinel to query across Azure logs (Activity Log, Entra ID, Defender, application logs), correlate observations, and produce structured incidents. Sentinel’s KQL (Kusto Query Language) is the analytical language for the Azure forensic surface.

Managed disk snapshots are the Azure equivalent of EBS snapshots, with similar acquisition methodology: snapshot the disk, copy if necessary, create a new disk from the snapshot, attach to a forensic VM, image the disk.

Storage Account logs. Azure Storage logs per-blob access when configured; the logs are the equivalent of S3 access logs and serve the same forensic purposes.

Azure Resource Graph and Resource Manager change history record the configuration history of Azure resources. The surface is the rough equivalent of AWS Config; the analytical tooling is different.

The Office 365 / Microsoft 365 surface is connected to Azure but operates as a separate forensic discipline. The Microsoft 365 Unified Audit Log is the central artifact for tenant-level activity (Exchange, SharePoint, Teams, OneDrive, the Compliance Center). Covered in the SaaS forensics section.

GCP forensics

Google Cloud’s forensic surface is the most aggressively logged of the major cloud providers by default. A substantial fraction of activity is logged without explicit configuration. It is structured differently from AWS and Azure.

Cloud Audit Logs are GCP’s equivalent of CloudTrail, divided into four streams:

• Admin Activity logs record administrative actions (resource creation, IAM changes, configuration modifications). Always on, cannot be disabled.
• Data Access logs record reads of user data. Off by default for most services (because of volume), configurable per-service.
• System Event logs record system-driven actions (automated retention deletions, system maintenance events).
• Policy Denied logs record IAM denials: actions that were attempted but rejected by the policy framework.

The four-stream model is more granular than CloudTrail or the Activity Log. The Admin Activity log alone covers most of what CloudTrail does; enabling Data Access logging brings additional visibility but at significant volume.

Cloud Logging is the GCP log management service (formerly Stackdriver). All audit logs, plus application logs from GCP workloads, flow through Cloud Logging. The Logs Explorer is the primary analytical interface; the Log Analytics feature provides SQL-based querying over indexed log data.

Cloud Asset Inventory records the configuration state of GCP resources over time. Asset history queries return the state of a resource (or class of resources) at any point in the retention window. The surface is roughly equivalent to AWS Config.

VPC Flow Logs, addressed in Network Forensics.

Security Command Center is GCP’s managed security and compliance service. The service surfaces vulnerabilities, misconfigurations, and threat findings; the findings are forensically useful as GCP-side observations.

Chronicle (now Google Security Operations) is Google’s cloud-native SIEM and SOAR platform. The service ingests Cloud Audit Logs, VPC Flow Logs, and other security telemetry (both GCP-native and from other sources) and provides the investigation workflow.

Persistent Disk snapshots are GCP’s equivalent of EBS snapshots, with the same general acquisition methodology.

Cloud Storage audit logs record object access where enabled. GCS bucket access logs are an opt-in configuration; the Data Access logs in Cloud Audit Logs cover the same surface for the services that support it.

IAM analysis on GCP uses the IAM Recommender (for surfaced unused permissions), the Policy Analyzer (for determining what permissions a principal has), and the Access Context Manager for context-aware access patterns. The forensic surface is the combination of these tools plus the Cloud Audit Logs entries that record actual IAM usage.

Container and Kubernetes forensics

Container and orchestrated container forensics is its own discipline within cloud forensics, addressing workloads that run on top of the cloud’s compute primitives.

Docker container forensics. A Docker container is an isolated process or process group running on a shared kernel, with a layered filesystem that overlays the writable container layer onto the read-only image layers. The forensic surface includes:

• The container image layers (docker inspect, examination of the image layer chain).
• The container’s writable layer (the changes the container has made since it started, accessible at /var/lib/docker/overlay2/<id>/diff/ for overlay2-driven storage).
• The container’s runtime configuration (docker inspect produces this; the JSON output includes the command line, environment variables, mounted volumes, network configuration).
• The Docker daemon logs (in /var/log/docker.log or via journalctl -u docker.service).
• The container’s own logs (docker logs <id> on the host, or the container’s stdout / stderr captured by the runtime).

Tools like docker-explorer (Google) and container-explorer parse Docker artifacts for forensic analysis, producing structured output of running and exited containers.

Kubernetes forensics adds the orchestration layer to the container forensic surface. The Kubernetes forensic artifacts include:

• etcd state, the cluster’s distributed key-value store, which holds the authoritative state of all Kubernetes objects (pods, services, deployments, secrets, configmaps). Acquiring an etcd snapshot captures the entire cluster state.
• kubelet logs on each worker node, which record the kubelet’s view of pod lifecycle events.
• The API server audit logs (kube-apiserver audit log, when configured), which record API calls to the cluster: who created what, who deleted what, who exec’d into what pod. The kubelet and API server audit logs are the Kubernetes equivalent of CloudTrail.
• Container runtime logs (containerd, CRI-O), which record container start / stop events at the runtime level.
• Pod and container forensics as covered above, scoped to the containers running within Kubernetes.

Runtime security tools. Falco, Tracee, Sysdig, and the various commercial runtime security products generate detailed event streams from container workloads using eBPF or similar mechanisms. The event streams are forensically valuable because they capture syscall-level activity that the standard logs miss: process executions, file accesses, network connections at the per-process level. The retention is whatever the customer configured.

Managed Kubernetes (EKS, AKS, GKE) adds the cloud provider’s audit layer. The control plane logs (EKS audit logs in CloudWatch, GKE audit logs in Cloud Logging, AKS audit logs in Azure Monitor) provide the API server audit equivalent without requiring self-management of the audit configuration.

The Kubernetes forensic workflow typically captures: an etcd snapshot of cluster state, the API server audit logs for the time window of interest, the runtime telemetry from any deployed runtime security tools, and the standard cloud audit logs for the underlying infrastructure. The combination supports reconstruction of “what was running, what was deployed, who did what to the cluster” for the period under investigation.

Serverless forensics

Serverless function forensics is the most ephemeral corner of cloud forensics. The function runtime exists for the duration of the invocation; the visibility is whatever the function or the platform logged.

AWS Lambda. The forensic surface includes CloudWatch Logs (whatever the function wrote to stdout / stderr), CloudTrail (the invocation records and any AWS API calls the function made), X-Ray traces (when enabled, including downstream service calls), and the function configuration (the code, environment variables, IAM role) as it existed at the time. Lambda Layers and the function’s deployment package are recoverable from the configured S3 location.

Azure Functions. The Application Insights telemetry is the primary forensic surface: function execution records, exception traces, dependency calls. The Azure Functions runtime logs to Application Insights by default for most function apps. The Activity Log records configuration changes.

Google Cloud Functions. Cloud Logging captures function output; Cloud Audit Logs record administrative actions on the function. Cloud Trace provides distributed tracing.

The forensic methodology for serverless is preventive rather than reactive: structure the function code to log enough context to reconstruct activity, retain those logs for an adequate window, and accept that anything not logged is unrecoverable. The acquisition phase is reading the logs; there is no equivalent of a disk image.

SaaS forensics

SaaS forensics is the analysis of activity in cloud-hosted applications that the customer does not control at the infrastructure level. The customer has access to the application’s audit logs and to the customer-visible data; everything else is the provider’s domain.

Microsoft 365. The Unified Audit Log is the central artifact for Microsoft 365 forensics, covering Exchange (mail flow, mailbox access), SharePoint and OneDrive (file activity), Teams (messages, channel activity, calls), Power Platform, Defender, and the platform-level identity events. The Unified Audit Log is searchable through the Microsoft Purview portal and through PowerShell (Search-UnifiedAuditLog). The retention is 90 days for E3 licenses and one year for E5; long-term retention requires additional Microsoft 365 add-ons or export to a customer-managed destination.

The Microsoft 365 eDiscovery workflow is the legal-discovery-oriented surface: holds, searches, and exports of mailbox and SharePoint content. The forensic workflow uses eDiscovery for content acquisition and the Unified Audit Log for activity reconstruction.

Microsoft Sentinel and Defender for Cloud Apps layer detection and investigation on top of the underlying audit logs.

Google Workspace. The Admin SDK Reports API is the equivalent surface, providing audit logs for Admin Console actions, Drive activity, Gmail activity, Calendar, and the other Workspace applications. The Reports API covers approximately 180 days of history; Google Vault provides longer-term retention and eDiscovery.

The Google Workspace Investigation Tool (Security Center) provides an analytical interface for the underlying audit logs.

Slack. The Audit Logs API is available for Slack Enterprise Grid (not Standard or Business plans), recording administrative actions, channel events, and message-level activity for the workspace. The Slack forensic surface is largely dependent on the plan; lower-tier plans have substantially less audit visibility.

GitHub. The Audit Log API provides organization-level audit history. The forensic value is substantial for software-supply-chain investigations: who modified which repository’s settings, who accessed which secrets, who pushed which commits, who created which deploy keys. The Audit Log API is available on GitHub Enterprise plans (Team and lower have reduced audit access).

Salesforce. The Event Monitoring product provides detailed user activity logs (login events, report exports, API calls). The Setup Audit Trail covers administrative actions. The forensic surface depends substantially on the customer’s Salesforce subscription level.

The general SaaS forensic pattern. Identify the SaaS application’s audit log surface, determine the retention window, query the logs for the activity of interest, correlate with identity-side artifacts (Entra ID for federated identities, the SaaS-side identity provider where applicable). The methodology is consistent across SaaS applications; the specific log structures and APIs vary.

IAM forensics: who could do what

A substantial fraction of cloud forensic work centers on the IAM question: who had the permissions to do the observed activity, who actually did it, and what were the policy decisions that produced the observed permissions.

The principal investigation. Cloud audit logs identify the principal that made each call: the IAM user, IAM role, federated identity, service account, or cross-account principal. The forensic work traces from the call to the principal, then expands the picture: which other calls did this principal make in the relevant window? Which other resources did it access? Which other roles did it assume? The output is a per-principal activity timeline that supports reconstruction of an adversary’s session.

The policy investigation. What permissions did the principal actually have? IAM policies are layered (identity-based policies, resource-based policies, permission boundaries, service control policies in AWS Organizations, conditional access in Azure, organization policies in GCP). The effective permission for a principal at a moment in time is the result of the policy evaluation across all the layers. The IAM analysis tools (AWS IAM Access Analyzer, Azure’s Microsoft Entra Privileged Identity Management, GCP IAM Recommender and Policy Analyzer) compute effective permissions; the forensic analysis uses them to establish what the principal could do, which constrains what they may have done.

The credential investigation. Where did the principal’s credentials come from? The forensic trail includes: the IAM Credential Report (when the credentials were issued, when last used, when last rotated), the AssumeRole calls in CloudTrail (which trace role-assumption chains), the federation events (which identify the upstream identity provider that authenticated the user), and the source IP and user-agent of the credential-using calls. For investigations into compromised credentials, the credential trail establishes when the compromise occurred and what activity is attributable to the compromised credentials.

The privilege escalation analysis. When an adversary’s initial access provides limited permissions, the next phase of an intrusion typically involves escalating to higher permissions: through IAM policy modifications, through role assumptions, through exploitation of trust relationships. The forensic analysis traces the chain of permission grants that produced the eventual elevated access. Tools like Pacu (the AWS penetration testing framework) document the common escalation paths and serve as a checklist for what to look for in the audit logs.

The IAM forensic surface in cloud is one of the strongest analytical surfaces in the discipline. The audit logs preserve the actions; the policy state preserves the constraints; the combination supports detailed reconstruction of what was possible and what was done. The forensic limitation is that the policy state at a past point in time has to be reconstructable, which requires the configuration history services (AWS Config, Azure Resource Graph change history, GCP Cloud Asset Inventory) to have been capturing it.

Acquisition and chain of custody in cloud

The chain-of-custody principles from Evidence Handling and Chain of Custody apply to cloud evidence with adjustments for the API-driven acquisition model.

API-driven acquisition. Cloud forensic acquisition runs through provider APIs rather than physical access. The chain of custody for cloud evidence includes the API calls that produced the evidence (recorded in CloudTrail or equivalent) and the timestamps, principals, and outcomes of those calls. The provider’s audit log substitutes for the physical chain that hardware-based acquisition would produce.

Snapshots as the imaging primitive. EBS snapshots, managed disk snapshots, and Persistent Disk snapshots are the cloud equivalent of disk images. The snapshot is taken through the provider’s API; the snapshot ID and the CloudTrail entry are recorded as part of the chain; subsequent operations on the snapshot (copies, attachments, exports) are similarly recorded.

Hash verification. The exported disk image is hashed using standard methods (SHA-256 alongside the provider-side ETag or content hash). The hash is recorded in the chain of custody; subsequent transfers re-verify the hash.

Log export and integrity. Cloud audit logs are typically exported to durable storage (S3, Azure Storage, GCS) for forensic retention. The exported logs inherit the storage system’s integrity properties; the access logs from the storage destination become part of the chain. Some providers (AWS CloudTrail with log file integrity validation) sign the log files with the provider’s keys, which provides additional integrity proof against tampering.

Provider transparency reports. The major cloud providers publish transparency reports describing the law enforcement requests they have received and complied with. The reports are not forensic evidence per se but are useful context for understanding how the provider responds to legal process.

The “who has access to the cloud evidence” question. Cloud evidence is more accessible than physical evidence. Multiple analysts can access the same logs through the API simultaneously. The methodology has to account for this: who accessed the evidence, when, and for what purpose. The cloud-provider access logs to the forensic data themselves become part of the broader chain.

Legal and jurisdictional considerations

Cloud forensics has more active legal context than most other forensic disciplines, reflecting the cross-border data flow that cloud computing produces.

The CLOUD Act (2018). The Clarifying Lawful Overseas Use of Data Act addressed the question of whether U.S. legal process applies to data stored outside the U.S. by U.S.-based providers. The Act provides that U.S. providers must produce data in response to U.S. legal process regardless of where the data is stored, and establishes a framework for foreign governments to enter agreements for direct access to data held by U.S. providers. The forensic implication is that data in U.S.-provider cloud accounts is reachable by U.S. legal process regardless of region.

GDPR Article 48. EU data protection law restricts the transfer of personal data to third-country authorities (including U.S. legal process) without a basis in EU law. The tension with the CLOUD Act has produced ongoing legal complexity for cross-border cloud forensic engagements involving EU data subjects.

Schrems II (2020) and the Data Privacy Framework (2023). The 2020 Schrems II decision invalidated the EU-U.S. Privacy Shield, the framework that had supported EU-to-U.S. data transfers. The 2023 EU-U.S. Data Privacy Framework re-established a transfer mechanism; the durability of the new framework is the subject of ongoing litigation. The forensic implication is that cross-border evidence transfer between EU and U.S. depends on legal frameworks that have been periodically invalidated.

Data sovereignty and regional restrictions. Some jurisdictions (China, Russia, certain Middle Eastern countries) require certain data to be stored within the jurisdiction. Cloud providers have addressed this with regional offerings (AWS China is operated by Sinnet, Azure China by 21Vianet, similar arrangements elsewhere). The forensic implication is that cloud evidence in these regions may not be accessible to the customer’s home jurisdiction without local legal process.

Provider response to legal process. Each major cloud provider has documented procedures for responding to law enforcement requests. The procedures distinguish between voluntary requests (the provider may comply at its discretion), subpoenas (typically supported for basic subscriber information), and warrants (required for content access in U.S. jurisdiction). The provider’s transparency reports document the volume and outcomes of these requests at an aggregate level.

The customer-provider boundary for legal process. The customer’s own legal process applies to the customer’s accounts; the provider’s legal process applies to the provider-managed infrastructure. The boundary occasionally produces complexity: a customer may be required to produce data that is in the provider’s infrastructure but not accessible to the customer (provider-side observability data, infrastructure-level logs the customer never had access to).

What still gives the discipline trouble

The structural problems cloud forensics is currently working through:

Log retention windows. Cloud audit logs typically have default retention windows that are shorter than many investigations require — 90 days for CloudTrail through the console, 90 days for the Microsoft 365 Unified Audit Log on E3 licenses, 180 days for the Google Workspace Admin SDK Reports API. Longer retention requires either explicit log export to durable storage (which the customer has to configure proactively) or higher-tier licenses. Investigations that begin after the default window often find the relevant audit history aged out.

The cloud account discovery problem. Modern organizations frequently have more cloud accounts than they fully track — separate accounts for development environments, accounts inherited through acquisitions, “shadow IT” accounts created without central IT oversight, SaaS accounts that pre-date the formal procurement process. The forensic methodology has to account for the possibility that the activity of interest occurred in an account the customer does not initially identify.

Ephemerality. Covered earlier. The forensic visibility into ephemeral compute is whatever the persistent logging captured.

Multi-tenancy and provider opacity. Cloud providers do not expose the multi-tenant infrastructure layer to customers. Forensic questions that would require provider-side visibility (was there a co-tenant whose activity affected this workload? did the hypervisor experience anomalous behavior at the time in question?) are not generally answerable without provider cooperation, which is rare outside specific high-impact incidents.

Provider cooperation limits. The provider’s response to forensic requests is constrained by the provider’s policies, the legal framework, and the operational reality. Provider response times can be substantial, the scope of what the provider will produce is bounded, and the format of provided data may not match the customer’s analytical workflow.

The cloud-native forensic tool lock-in. AWS Detective, Azure Sentinel, GCP Chronicle, and the equivalent products are powerful within their respective cloud. The lock-in is that workflows built on cloud-native tools do not transfer across providers — a multi-cloud forensic capability requires either separate tool investment per cloud or a third-party tool that abstracts across them. The third-party tools (Wiz, Lacework, Orca, the various CNAPP platforms) have improved but cover the major providers unevenly.

Cross-cloud correlation. When an incident spans multiple cloud providers (the AWS-hosted application talked to an Azure-hosted database, both authenticated through Okta), the forensic correlation requires pulling evidence from all involved providers and stitching it together. The provider-side identifiers don’t naturally cross-reference; the analytical work is manual or requires specialized tooling.

The SaaS visibility gap. Many SaaS applications provide less audit visibility than the customer’s IT compliance posture assumes. The “log everything” presumption that applies to on-premises systems does not transfer cleanly to SaaS, where the audit surface is whatever the provider exposes at the customer’s subscription tier. Engagements that involve SaaS forensics often discover the visibility gap during the engagement, not before.

Encryption-at-rest as a forensic gap. Customer-managed keys (CMK) in AWS KMS, Azure Key Vault, and GCP Cloud KMS encrypt cloud-resident data with keys the customer controls. The forensic implication is that disk snapshots of CMK-encrypted volumes require the customer’s keys to be examined, which is a customer-side dependency that the cloud-side acquisition methodology has to account for. If the customer’s KMS keys are unavailable (rotated, deleted, in a different account), the snapshot is examinable only as ciphertext.

Cloud forensics is the part of the discipline that has had to reorganize itself most aggressively over the last decade. The methodology that worked for on-premises systems (image the disk, capture the memory, walk the file system) does not translate cleanly to environments where the customer does not own the hardware, the compute is ephemeral, the storage is multi-tenant, and the primary forensic surface is the provider’s audit log rather than the workloads themselves. The discipline has organized around the new surface: the control plane as the central artifact, the data plane as the secondary surface, the IAM analysis as the analytical engine, and the architectural decisions made before the incident as the determinant of what the engagement can recover. The shift will continue as the workload mix moves further toward serverless and SaaS; the forensic methodology adapts to each evolution.

The connected pages cover the related work this work depends on and overlaps with: Forensic Acquisition and Imaging covers the snapshot-based acquisition methodology that the cloud-specific techniques fit within; Network Forensics covers the VPC Flow Logs, service mesh telemetry, and other network-side cloud forensic sources; Disk and File System Forensics covers the analysis of the disk images that cloud acquisition produces; Memory Forensics covers the analysis of memory acquired through cloud-native mechanisms; Mobile Forensics covers the cloud account surface (iCloud, Google) that overlaps with mobile forensic engagements; and Evidence Handling and Chain of Custody covers the procedural framework that the cloud-specific chain integrates with. The Digital Forensics hub covers the discipline as a whole.