Personal data sits in cloud cost data wherever a row points to a human being: an email address in an owner tag, a first name in an account or resource name, the identity of whoever created a resource or called a model, or the contact on the invoice. The GDPR, Regulation (EU) 2016/679, covers any information about an identified or identifiable person, and cost data is exported, copied and shared widely in reports. This page shows in which AWS, Azure and Google Cloud fields such values can appear and how the providers describe their own processing of that data. How a company handles it is for the company to decide with its data protection adviser.
How it works
Article 4(1) defines personal data as any information relating to an identified or identifiable natural person, directly or indirectly, for example through a name, an identification number or an online identifier. Under recital 26, pseudonymised data that can be attributed to a person with additional information remains information about an identifiable person; the European Data Protection Board makes the same point in its Guidelines 01/2025 on pseudonymisation, published for consultation in January 2025. Three principles in Article 5(1) bear on cost data in particular: purpose limitation (point b), data minimisation (point c) and storage limitation (point e). Under Article 5(2) the controller must be able to demonstrate compliance with them. On the day read, EUR-Lex shows the Regulation unamended, with two Commission proposals to amend it.
Fields that can point to a person
| Where | AWS | Azure | Google Cloud |
|---|---|---|---|
| Free-form key-value pairs | cost allocation tags | tags | labels and tags |
| Free-form names | payer and usage account names in CUR 2.0 | subscription, resource group, resource name | project name, resource name in the detailed export |
| Who created or called a resource | tag aws:createdBy with a user name or role session; column line_item_iam_principal for Bedrock calls | no such field in the field list | no such field in the field list |
| Contacts on the account and invoice | account information such as names and email addresses | field AccountOwnerId with the email of the EA account owner; sold-to address on every invoice | account information such as names, contact details and job titles |
Two of the AWS fields exist only because the customer chose them: aws:createdBy is applied only after the management account activates it, and CUR 2.0 fills line_item_iam_principal only with the IAM principal data option, from 8 April 2026 at the earliest. Beyond the hyperscalers, AI providers sometimes group usage by person; OpenAI, for example, groups completions usage by user_id, as usage and cost exports of the AI providers describes.
How the providers describe their own processing
- AWS. The Data Processing Addendum covers personal data the customer uploads to the services, for which AWS is the processor. Under the data privacy FAQ, resource identifiers, metadata tags and access controls are not customer content, and AWS advises leaving details about people, and confidential or sensitive values, out of them. Account information, meaning names, user names, email addresses and billing information, falls under the AWS Privacy Notice.
- Microsoft. The Products and Services Data Protection Addendum, in its May 2026 edition, makes the customer the controller and Microsoft the processor. For business operations incident to delivering the service, billing and account management among them, Microsoft says it acts as an independent controller and commits to data minimisation. Its Appendix B lists pseudonymous identifiers among the categories of personal data.
- Google Cloud. Under the Cloud Data Processing Addendum, Google is the processor for personal data in customer data. The Google Cloud Privacy Notice, effective since 15 October 2026, lists account information, billing records and resource identifiers and attributes as Service Data, for which Google Cloud EMEA Limited is the controller where EU law applies, or for billing the Google affiliate the contract is with. Google keeps most Service Data for up to 180 days, and data for tax and accounting typically for at least five years.
In AWS's and Google's descriptions, then, a tag value or resource name is not customer content but part of the configuration, and it travels into the provider's billing and into every export. What follows for the company's own processing is for its data protection adviser to assess.
What it means for your cost
Cost allocation almost never needs the person, only the team, the product or the cost centre. A tagging policy that uses roles and teams instead of names allocates the same cost without putting a person into every export; the rules are in cloud tagging strategy: a policy that holds. Once a personal field is in the data, every copy costs effort: the export bucket, the BI tool, spreadsheets sent by email. A sequence of checks for each cost dataset keeps those copies small:
- Which columns can point to a person? Tags and labels, names, creator and caller identities, contacts.
- What is the dataset used for: allocation, chargeback, anomaly review?
- Does that purpose need the person, or is the team enough?
- Who receives the dataset? Roles and sharing are covered in cost data access control: roles by provider.
- How long is it kept, and does the history need the personal column? How far back the providers' data reaches is in history of billing data.
- Which provider terms cover the field? The list above names the documents.
The balance between a long history for finance and storage limitation is not settled on this page but by the company with its data protection adviser.
Where it goes wrong
- Email addresses as owner tags. The value appears in every export and every report showing the column (tags and labels); what the three providers say about personal details in tags is summarised in the tagging strategy.
- aws:createdBy activated without looking at its content. The value can contain user names and shows up in the billing console and reports for every member account of the organisation.
- Per-person usage shared widely. A dashboard of AI cost by user_id or IAM principal goes to the whole company, although managing it needs only team totals.
- Exports copied without access control. The export sits in a bucket or dataset whose permissions nobody reviews, and moves on into tools with their own sharing.
- A hash taken for anonymous. A hashed email address can be matched by hashing the known addresses the same way and comparing the values. The Board's guidelines describe this matching with hashed names as the example, and recital 26 treats pseudonymised data as information on an identifiable person.
- History without a deletion rule. Exports pile up for years without deciding which columns are dropped after which period.
Whether a particular processing of cost data is lawful and which periods apply is for the company's data protection adviser to judge.
Sources
Read on 2026-10-16. EUR-Lex Regulation (EU) 2016/679 (GDPR); European Data Protection Board Guidelines 01/2025 on pseudonymisation, consultation version and announcement of their adoption; AWS Data Processing Addendum, data privacy FAQ, AWS-generated tags and CUR 2.0; Microsoft Products and Services Data Protection Addendum, cost details fields and billing account contact information; Google Cloud Cloud Data Processing Addendum, Google Cloud Privacy Notice and structure of the detailed export; OpenAI completions usage.