Cloud Evidence: Getting Data from AWS, Azure and Google Cloud
How to get evidence from the major cloud providers: the shared-responsibility boundary, identifying the account behind an IP, preservation, the AWS, Azure and Google law-enforcement portals, the US CLOUD Act and bilateral agreements, and the India, US, UK and EU framework compared.
Cloud investigations follow a different logic from serving a warrant on a local internet provider. Every major cloud platform draws a clear operational boundary between what the provider controls and what its paying customer controls. Knowing which side of that boundary holds the evidence you need, and drafting a request that respects it, is the difference between a productive return and months of fruitless correspondence.
- In IaaS, the cloud provider is not the data controller for your target's application content. Use the provider to identify the customer account; direct content demands at that account holder.
- The most actionable inputs for an account-identification request are an IP address with a precise UTC timestamp, plus any resource or instance identifier visible in your logs.
- Send a preservation request before you secure the warrant. US law requires providers to freeze records for 90 days on request. Major providers extend equivalent courtesy to foreign agencies for serious offences.
- AWS, Microsoft Azure, and Google Cloud each publish law enforcement guidelines and operate dedicated submission portals. Emergency pathways for imminent risk to life exist at all three.
- The US CLOUD Act (2018) means data physically stored in Europe or Asia by a US-headquartered provider is still reachable under a valid US warrant. Direct-access bilateral agreements with the UK and Australia now bypass the MLAT process for those countries.
- India, the EU, and most jurisdictions without a CLOUD Act agreement must still route content requests through mutual legal assistance. A domestic court order alone does not compel a US-headquartered provider to disclose content.
The cloud ownership problem
When an actor rents a virtual machine on Amazon Web Services, runs a phishing panel on it, and stores stolen credentials in a cloud storage bucket, Amazon is the landlord, not the operator of that panel. Amazon knows who signed up for the account, which payment instrument was used, which IP addresses accessed the management console, and which resources were provisioned under the account. Amazon does not know, and in most configurations cannot access, what the customer placed inside those resources.
The industry term for this division is the shared responsibility model. Under Infrastructure-as-a-Service (IaaS), the cloud customer is responsible for, and is the data controller for, any application data they create, store, or process. The provider operates the physical hardware, the network fabric, and the virtualisation layer, and retains logs of that infrastructure tier. This is an operational reality, not a legal technicality. The rule for investigators follows directly: go to the provider to establish who the customer is, then direct content demands at the customer or their account.
Service models and evidence scope
The higher up the technology stack a customer sits, the more data the provider holds on their behalf. The table below maps each service model to the realistic evidence split between provider and customer.
| Model | Common examples | Provider holds | Customer controls (target for content) |
|---|---|---|---|
| IaaS | AWS EC2, Azure Virtual Machines, Google Compute Engine | Account and billing records, subscriber identity, IP connection logs, API audit logs, resource inventory metadata | Everything inside the instance or storage bucket: databases, files, application logs, communications |
| PaaS | Google App Engine, Azure App Service, AWS Elastic Beanstalk | Account and billing records, deployment metadata, platform-level access logs | Application code, application data, user-generated content created by the application |
| SaaS | Microsoft 365, Google Workspace | Account records, metadata, access logs, and often the content itself (emails, documents) subject to the appropriate legal authority | User credentials, some configurations, data the customer has exported or stored outside the platform |
What the major IaaS providers actually hold
A lawfully served IaaS request will typically produce records in the following categories and no more:
- Subscriber and account identity: legal name, organisation name, email address on the account, payment method and last digits, account creation date, and the provider-assigned account identifier.
- IP access history: the IP addresses from which the account management console was accessed, with UTC timestamps. These records are the most direct link between a cloud account and a physical person or connection and are the primary tool for identifying the human behind the account.
- Resource inventory: a list of cloud resources provisioned under the account, including virtual machines, storage buckets, database instances, and load balancers, with creation and deletion timestamps and the deployment region for each.
- Infrastructure audit logs: records of API calls made to the provider's management plane. AWS calls this CloudTrail; equivalent services exist on Azure and Google Cloud. These logs record administrative actions such as launching or stopping instances, modifying access permissions, and creating storage resources, each tied to an origin IP and a timestamp. They are distinct from application logs the customer may have configured inside their environment.
- Billing records: usage data broken down by service type, region, and time period. These establish the operational timeline and scale of infrastructure used in a campaign.
Providers do not hold and cannot produce the contents of a storage bucket, the rows of a customer-managed database, communications routed through an application the customer built, or encryption keys the customer manages independently of the provider.
Identifying the account behind an IP address or resource
The most common starting point in a cloud investigation is an IP address observed in a victim's logs or captured through traffic analysis. The goal of the first request is to translate that IP into an account identity. Requests that lack the right inputs are routinely returned incomplete or sent back for clarification.
- Convert every timestamp to UTC before drafting. Cloud providers store logs in Coordinated Universal Time. A timestamp in Indian Standard Time (UTC+5:30), Eastern Time (UTC-5), or any other local zone that is not explicitly labelled will produce no match, or a wrong-account match at a different moment in the log. Write the exact UTC value into the request document.
- Assemble every identifier you hold. The ideal package is: the source IP address, the precise UTC timestamp of the relevant activity to the second where possible, the protocol or destination port, and any resource identifier visible in your evidence such as an EC2 instance ID, an Azure resource name, or a Google Cloud project number. Instance identifiers are decisive in multi-tenant environments where IP addresses are dynamically allocated and rotate between customers.
- Specify the exact data categories you need. A request for "all information associated with this IP address" is overbroad and will be narrowed or returned. Name what you are seeking: subscriber identity, billing contact, IP login records for the specified UTC window, and resource inventory tied to that IP at the stated time.
- State the legal authority explicitly. Identify the offence, cite the statute or treaty basis for the request, and specify whether you are seeking non-content subscriber data or content. Mismatching the request type to the level of legal process causes avoidable delay at the compliance team.
- For agencies outside the US, address the legal process gap directly. A domestic court order or production notice does not legally bind a US-headquartered provider in its home jurisdiction for content. Attach or reference the applicable MLAT or bilateral agreement. For subscriber and non-content account data, major providers may apply discretion in serious cases, but this should not be relied on as a substitute for formal process.
Send a preservation request first
Cloud providers apply short log retention cycles as a matter of course. By the time an investigation identifies a relevant account and a warrant is prepared, API audit logs, console access records, and resource metadata may already have been overwritten. Preservation requests are the mechanism to prevent this.
Under 18 U.S.C. Section 2703(f) of the US Stored Communications Act, an electronic communications service or remote computing service must preserve existing records upon a government request for 90 days, extendable on a renewed request. In practice many providers will honour successive renewal letters, so re-serve rather than assume an automatic extension. Major non-US providers extend equivalent courtesy preservation to foreign law enforcement agencies on serious offences, though outside the US this is discretionary rather than a statutory obligation.
AWS accepts preservation requests through its ALERT portal (Amazon Law Enforcement Request Tracker), which requires a registered law enforcement account. Microsoft accepts them through its law enforcement portal at leportal.microsoft.com. Google accepts them through LERS (Law Enforcement Request System). All three require the request to identify the account, the relevant time window in UTC, and the categories of data to be preserved. Emergency submissions attesting to imminent risk to life can be submitted without a pre-registered account on AWS, provided the submitting officer explicitly declares their authority.
Serving legal process on the three major providers
| Provider | Submission portal | Non-content subscriber data | Content data | International agencies |
|---|---|---|---|---|
| Amazon AWS | ALERT (Amazon Law Enforcement Request Tracker) | Subpoena or equivalent; yields name, address, billing contact, registration IP address | Search warrant required; under Amazon's published guidelines a subpoena alone does not produce content | Via MLAT to US DOJ, which routes to Amazon; or directly under a CLOUD Act bilateral agreement where one is in force |
| Microsoft Azure | leportal.microsoft.com | Subpoena or equivalent for IP access history, account metadata, and non-content records | Court order or warrant required; Microsoft does not provide governments with its own encryption keys or the ability to break encryption | Via MLAT or CLOUD Act bilateral agreement; Microsoft publishes bi-annual transparency reports covering all jurisdictions |
| Google Cloud (GCP) | LERS (Law Enforcement Request System) | Subpoena or equivalent for subscriber and non-content data | Search warrant or equivalent required; Google reviews all requests for legal sufficiency before producing data | Via MLAT or CLOUD Act bilateral agreement; Google publishes enterprise cloud transparency data separately from its consumer product requests |
All three providers publish their law enforcement guidelines publicly and update them periodically. Read the current version of the applicable guidelines before drafting a request, since process details and addresses for physical service of legal documents change.
The US CLOUD Act and data location
Before 2018, whether a US court order could compel disclosure of data stored by a US company on a server physically located in another country was genuinely unsettled. The Clarifying Lawful Overseas Use of Data Act, enacted by the US Congress on 23 March 2018, resolved this: a provider subject to US jurisdiction must produce data it controls regardless of where that data is physically stored. A customer who stores data in AWS Mumbai or Azure Frankfurt does not thereby place it beyond the reach of a valid US warrant.
The Act also established a framework for bilateral agreements. A foreign government whose laws provide robust privacy and due-process protections can negotiate a direct-access agreement, allowing its agencies to serve legal process on US providers without routing through the MLAT process. Two agreements are in force as of mid-2026:
- The US-UK Agreement on Access to Electronic Data for the Purpose of Countering Serious Crime entered into force on 3 October 2022. UK law enforcement agencies can serve production orders directly on US-based providers for qualifying serious crime and terrorism investigations.
- The US-Australia CLOUD Act Agreement entered into force on 30 January 2024. Australian federal law enforcement has equivalent direct-access rights for serious offences.
India does not have a CLOUD Act bilateral agreement in force as of mid-2026. Indian law enforcement must use the existing India-US Mutual Legal Assistance Treaty for content held by US providers. Research has documented MLAT processing times for complex cases running to many months or more, creating a significant operational gap for time-sensitive investigations.
Comparative legal framework
| Jurisdiction | Primary legal basis | Threshold to obtain content | Mechanism for US-held data | Current status |
|---|---|---|---|---|
| United States | Stored Communications Act (18 U.S.C. 2701 et seq.); CLOUD Act 2018 | Search warrant issued by a judge on probable cause | Direct; providers are in-jurisdiction under US law | CLOUD Act bilateral agreements with UK and Australia operational; no EU-wide or India agreement concluded |
| India | Section 94 Bharatiya Nagarik Suraksha Sanhita 2023 (BNSS), which replaced Section 91 CrPC from 1 July 2024 and expressly covers electronic records; Section 67C IT Act 2000 (preservation obligation on intermediaries) | Court order or BNSS Section 94 summons; no statutory probable-cause warrant standard equivalent to the US model | India-US MLAT (functional but documented as slow for complex cases); no CLOUD Act agreement in force | Policy discussion on an executive agreement reported in the literature; nothing concluded as of mid-2026 |
| United Kingdom | Investigatory Powers Act 2016; Crime (International Co-operation) Act 2003 for MLAT requests | Production order (non-content) or warrant (content), authorised by a court or designated senior official | US-UK CLOUD Act Agreement in force since 3 October 2022 allows direct service on US providers for qualifying serious crime | Direct-access operational for serious crime and terrorism; MLAT remains available for other cases |
| European Union | Law Enforcement Directive (EU 2016/680); GDPR Article 48 for third-country transfers; national criminal procedure codes | Judicial authorisation required for content in all member states; the specific standard varies by national code | Bilateral MLATs between individual member states and the US; no EU-wide CLOUD Act agreement in force as of mid-2026 | Under GDPR Article 48, a foreign court order not grounded in an international agreement does not automatically bind EU-based processors |
Working with providers: what to expect
Major cloud providers receive substantial volumes of law enforcement requests and publish bi-annual transparency reports accounting for them. AWS, Microsoft, and Google each report the total number of requests received, the proportion that resulted in disclosure, and the count accompanied by non-disclosure orders. Their compliance teams handle requests as a routine function, not an exception.
Several patterns recur consistently across provider guidelines and published practice:
- Overbroad requests will be narrowed or returned. A request for all data associated with an IP address across several years, with no defined account, date range, or data category, will be reduced to what the provider considers reasonable or sent back for revision. Scoping to a specific account identifier, a defined UTC time window, and named data categories produces faster and more useful returns.
- Customer notification is the default. Unless you include a legally valid non-disclosure order, major US providers may notify the account holder that legal process has been served. Where notification would compromise the investigation, include a court order prohibiting disclosure in the same package as the production request.
- Emergency procedures handle imminent risk to life. All three providers maintain emergency pathways for situations where delay would risk serious bodily harm or death. These are not a permanent bypass of legal process; they are a mechanism to obtain data urgently while formal process is completed in parallel.
- No provider offers direct system access, but stored keys are a different matter. Microsoft has published that it does not provide any government with direct or unfettered access to customer data, nor its own encryption keys. It has, however, confirmed publicly (January 2026) that it will release a customer's BitLocker recovery key held in its cloud when served with a valid legal order, which it reports doing a small number of times each year. The lesson for investigators: provider-managed key escrow is sometimes reachable through legal process even where the provider will not break its own encryption.
Frequently asked questions
The suspect used a VPN before connecting to their cloud account. Does a cloud provider request still yield anything useful?
Yes, partially. The provider will return the IP address that was used to access the account management console, which will be the VPN exit node. That gives you a new target: the VPN provider, whose subscriber and payment records may identify the customer. Preservation requests should be sent to both the cloud provider and the VPN provider as early as possible, before either service deletes its logs under its standard retention cycle.
What if the account was registered with a disposable email address and a prepaid card?
Subscriber identity records will reflect whatever the account holder supplied at registration, which may be false or anonymised. The more durable investigative asset in this scenario is IP access history. The IP addresses used to access the account console, particularly early in the account's life before the actor applied full operational security, frequently resolve to residential internet providers, mobile networks, or commercial VPN services that maintain their own subscriber records. Each hop in that chain requires its own preservation and production request served promptly.
If data sits in an Indian or EU data centre but the provider is US-headquartered, which country's law governs the request?
Under the CLOUD Act, it is the provider's connection to US jurisdiction, not the physical location of the server, that determines whether a US warrant applies. A valid US warrant served on AWS, Microsoft, or Google in the US compels production of data those companies control regardless of which region's data centre it sits in. Whether the provider also has separate obligations to the country where the data centre is located is a distinct legal question, and providers may in some circumstances seek modification of a US order before complying, particularly where local data-residency requirements exist. Investigators from jurisdictions with data-localisation laws should flag this complexity early in any coordinated cross-border request.