# Where may the data go?

> Must the data, the prompts and the logs stay in Australia, and what does each service do with them by default? Residency is a property of every hop a request takes, not of the app: the database, the files, the email, the analytics, the logs and the model. Most global platforms send data wherever they like by default; some keep it in Australia if you choose a region or a profile, sometimes for a premium; some have only a best-effort hint, or nothing. List every hop, check each one, and the answer is the weakest hop. Where it must stay, keep it in the client's own AWS account in Sydney; where it needn't, the global tools are simpler.

- A concept by Nicolas Dao (Cloudless Labs, Sydney): the decision before the tool
- Area: [Security, access and residency](https://cloudlesslabs.com/concepts/areas/security/index.md)
- Last reviewed: 1 November 2026, by Nicolas Dao
- Web page: https://cloudlesslabs.com/concepts/data-residency/

## What you'll be able to decide

Whether a system's data must stay in Australia; which of its services keep it there by default, which only when you ask (and at what price), and which can't at all; and how to prove where it went.

## In short

### The options

- **A. Global by default:** The platform runs the request and keeps the data wherever it likes: the nearest edge, the US, the EU. The simplest option, and the full product. Tools: [Cloudflare Workers](https://cloudlesslabs.com/stack/cloudflare-workers/index.md) (My default), [OpenRouter](https://cloudlesslabs.com/stack/openrouter/index.md) (My default), [Anthropic API (for client systems)](https://cloudlesslabs.com/stack/anthropic-api/index.md) (Skip), [Resend](https://cloudlesslabs.com/stack/resend/index.md) (My default), [PostHog](https://cloudlesslabs.com/stack/posthog/index.md) (My default).
- **B. In Australia, if you ask:** The service can keep it in Sydney or Melbourne, but only once you choose the region, the profile or the setting, sometimes at a premium. A location hint isn't one of these. Tools: [Amazon Bedrock](https://cloudlesslabs.com/stack/aws-bedrock/index.md) (Watching), [Neon (serverless Postgres)](https://cloudlesslabs.com/stack/neon/index.md) (My default).
- **C. In the client's own AWS account in Sydney:** Every hop in ap-southeast-2, inside an account the client owns: residency you can prove, at AWS prices and with more to build. Tools: [Amazon S3](https://cloudlesslabs.com/stack/aws-s3/index.md) (My default), [Amazon SES](https://cloudlesslabs.com/stack/aws-ses/index.md) (Use when it fits), [Lambda MicroVMs](https://cloudlesslabs.com/stack/aws-lambda-microvms/index.md) (Watching), [SageMaker](https://cloudlesslabs.com/stack/aws-sagemaker/index.md) (Use when it fits), [EC2](https://cloudlesslabs.com/stack/aws-ec2/index.md) (Use when it fits).
- **D. Nowhere at all:** The work runs on the user's device and nothing is sent, so there is nothing to keep anywhere.

### The rule of thumb

The default and the global endpoint route anywhere in the world. Australian residency only happens if you ask for it. From [Amazon Bedrock](https://cloudlesslabs.com/stack/aws-bedrock/index.md).

### How the answer changes with scale

- **No personal or client data: a marketing site, public docs, a prototype on made-up data:** Global by default. Residency would cost something and protect nothing.
- **Personal data, or a client or privacy policy that names Australia:** Every hop that carries the personal data in Sydney; keep that data out of the global tools rather than replacing them all.
- **Government or health work:** Everything in the client's own AWS account in Sydney, on services in scope for IRAP PROTECTED, checked service by service.

## The problem, in plain words

When a client says "the data must stay in Australia", they mean all of it. The database, yes, but also the uploaded files, the emails, the analytics events, the logs, and the prompts sent to a model, which often hold the same customer record word for word. Each of those goes to a different service, and each service has its own default.

So residency isn't a property of the app. It's a property of every hop a request takes, and the answer is the weakest hop. A database in Sydney doesn't help when the support assistant sends the same record to a model in the US.

Most global platforms are built the other way round: they run each request wherever it's fastest or cheapest. Keeping it in one country is an option you have to find, choose, sometimes pay for, and sometimes can't get at all.

## The picture

The same patient question, three ways. The database is the hop everybody checks; the ones after it are where the data leaves.

**Diagram:** One patient's question through a booking app, three ways: with only the database in Sydney, while the email, the analytics and the model still send it abroad; with every hop in the client's AWS account in Sydney; and on the device, where nothing is sent.

- **Only the database in Sydney:** Patient in Sydney → Database: Sydney → [Email: stored in the US / Analytics: the US or the EU / Model: the US or global]. The hop everyone checks. The answer is the weakest hop.
- **Every hop in Sydney:** Patient in Sydney → API: Lambda, Sydney → [Database: Sydney / Email: SES, Sydney / Model: Bedrock, AU profile]. The client's own AWS account: residency you can prove.
- **On the device:** User's browser → File processed in the tab → Nothing sent. Nothing to keep in Australia: nothing is sent.

## The options

**Global by default.** [Cloudflare Workers](https://cloudlesslabs.com/stack/cloudflare-workers/index.md) run wherever the request lands. [OpenRouter](https://cloudlesslabs.com/stack/openrouter/index.md) routes globally: in-region routing exists only for the EU and the US, on the Business plan. [Anthropic's API](https://cloudlesslabs.com/stack/anthropic-api/index.md) processes requests in the US or globally. [Resend](https://cloudlesslabs.com/stack/resend/index.md) and [Postmark](https://cloudlesslabs.com/stack/postmark/index.md) store data in the US, and [PostHog](https://cloudlesslabs.com/stack/posthog/index.md) Cloud runs only in the US or the EU. None of that is a flaw. For data that may go anywhere, they're simpler and complete, and I use them.

**In Australia, if you ask.** Some services keep the data onshore, but only once you choose it. [Neon](https://cloudlesslabs.com/stack/neon/index.md) is available in Sydney: you pick the region when you create the project. Claude on [Amazon Bedrock](https://cloudlesslabs.com/stack/aws-bedrock/index.md) stays in Sydney or Melbourne with the AU inference profile, for 10% more than global routing. Two things come with it: Bedrock lacks some of Anthropic's features (no batches, no Files API, no Managed Agents), and residency is per model. Fable 5.1's regional endpoint is US-only today, so it can't stay in Australia at all.

**A hint isn't a guarantee.** Cloudflare's storage offers jurisdictions for the EU, the US and FedRAMP only. For Oceania, [R2](https://cloudlesslabs.com/stack/cloudflare-r2/index.md), [D1](https://cloudlesslabs.com/stack/cloudflare-d1/index.md) and [Durable Objects](https://cloudlesslabs.com/stack/cloudflare-durable-objects/index.md) take a location hint, which is best effort, and a [Cloudflare Sandbox](https://cloudlesslabs.com/stack/cloudflare-sandbox/index.md) container can't be pinned to Australia. A hint says where the data will probably go. [S3](https://cloudlesslabs.com/stack/aws-s3/index.md)'s region says where it goes: the bucket's region is a guarantee, not a hint.

**In the client's own AWS account in Sydney.** The strictest answer: every hop in ap-southeast-2, inside an account the client owns. [S3](https://cloudlesslabs.com/stack/aws-s3/index.md) for files, [SES](https://cloudlesslabs.com/stack/aws-ses/index.md) for email, Lambda for the API, [Lambda MicroVMs](https://cloudlesslabs.com/stack/aws-lambda-microvms/index.md) for code nobody reviewed (in Sydney since 19 August 2026; I'm still watching it), [SageMaker](https://cloudlesslabs.com/stack/aws-sagemaker/index.md) or [EC2](https://cloudlesslabs.com/stack/aws-ec2/index.md) for GPUs. You can prove it: the Region of every resource, a service control policy that blocks the others, CloudTrail for every call. The price is building more yourself. SES is a sending engine, not an email product.

**Nowhere at all.** Data that never leaves the user's device needs no residency answer. [BobNinja](https://cloudlesslabs.com/work/bobninja/index.md), my own product, compresses PDFs and extracts their images in the browser, with no application server: users' files never leave their device. It only works for what a device can do, but when it fits, it's the strongest answer there is.

## A concrete scenario

A clinic in Sydney runs a booking app, and its privacy policy says health information stays in Australia. Here's each hop, as first built and as I'd fix it:

| Hop | As built | Where the data goes | The fix |
|---|---|---|---|
| The database | Neon, Sydney | Sydney | None: already right |
| The API | Workers | Wherever the request lands | Lambda in Sydney, for every route that touches patient data |
| Confirmation emails | Resend | Stored in the US | SES in Sydney |
| Analytics | PostHog Cloud | The US or the EU | Keep personal data out of the events, or self-host |
| The assistant | Claude on Anthropic's API | The US or global | Claude on Bedrock, AU profile: 10% more |
| The assistant's logs | Cloudflare AI Gateway | Can't be pinned to a jurisdiction | Log in the API, in Sydney |

Five of the six hops could send patient data abroad, and the database, the one everybody checked, was the only one that was certainly right. The model's fix is cheap: on a support assistant answering 2,000 chats a day, Bedrock's Australian routing adds about $66 a month.

## The trade-offs

| | Global by default | In Australia, if you ask | In the client's account in Sydney | Nowhere at all |
|---|---|---|---|---|
| Where the data goes | Wherever the platform sends it | Sydney or Melbourne, once you choose it | ap-southeast-2, in an account the client owns | It stays on the device |
| What it costs | Usually the least | Sometimes a premium (10% on Bedrock) | AWS prices, and more to build | The engineering to fit a browser's limits |
| What you give up | Nothing | Some features, and some models | The ready-made product around the service | Anything a device can't do |
| How you prove it | You can't | The setting, checked from every Region you call | Resource Regions, a service control policy, CloudTrail | Nothing is sent |

## The rule of thumb

**Residency only happens if you ask for it, one hop at a time.** List every service a request touches, the logs, analytics, email and model included. Check where each one keeps the data, not where its company is. Where the data must stay, keep it in the client's own AWS account in Sydney. Where it needn't, don't pay for residency: the global tools are simpler.

## When the answer changes with scale

- **No personal or client data:** global by default.
- **Personal data, or a policy that names Australia:** every hop that carries it in Sydney. Keeping personal data out of a global tool (analytics events without names or emails) is often cheaper than replacing the tool.
- **Government or health work:** everything in the client's account in Sydney, on services in scope for IRAP PROTECTED. SageMaker is, in Sydney and Melbourne. Check each service with the client: new AWS services take time to join the assessed list.
- **GPUs:** the strictest case costs the most. In Sydney, SageMaker has T4, A10G and L4 instances, and A100 and H100 machines. Runpod's Australian data center has L40S only, without network volumes, and Google Cloud has no L4 in Australia. [Runpod or AWS for a GPU?](https://cloudlesslabs.com/stack/guides/runpod-or-aws/index.md) has the prices.

## Before you promise it

- **Check per model and per feature, then pin them.** A model ID set to "latest" can move you to a model that routes overseas.
- **Block the other Regions** with a service control policy, so nobody creates a resource outside Australia by mistake.
- **Keep the evidence.** On Bedrock, run get-inference-profile from every source Region you use and keep the list of destination Regions for the client's compliance file.
- **Decide at creation.** Many of these settings can't change later: an R2 bucket's jurisdiction can never be changed afterwards, PostHog's region is chosen at sign-up, and a Neon project's region is chosen when it's created.
- **Check the list of locations, not the label.** OpenAI's regional processing covers only the US and Europe, not Australia. Hostinger has no VPS location in Australia. The closest are Malaysia, Indonesia and India.

## Questions that change the answer

- Does any of it identify a person, or belong to a client? If not, residency rarely matters.
- Does a contract or the privacy policy name a country? That decides, not anyone's preference.
- Where do the logs, the analytics, the emails and the model calls go? They carry the same data as the database, and they're the hops nobody checks.
- Must you prove it? Then keep the evidence: the Region of every resource, and where each inference profile sends requests.

Doesn't cover:

- What the law requires (the Privacy Act, health records rules, a client's contract): this page is about where the data goes. Ask a lawyer what applies.
- Sovereignty, which government can compel a provider to hand data over, is a different question from where the data sits.

## Check your call

- **A marketing site with a contact form. Nothing is kept but the messages, which go straight to the owner's inbox.** Global by default: Workers, Turnstile and Resend. Residency would cost something and protect nothing.
- **An HR app for Australian employers: Neon in Sydney, emails by Postmark, PostHog for analytics, and a Claude assistant through OpenRouter. Its contracts say employee data stays in Australia.** Three hops leave: Postmark stores data in the US, PostHog Cloud runs in the US or the EU, and OpenRouter routes globally. Email through SES in Sydney, keep personal data out of PostHog (or self-host it), and call Claude through Bedrock's AU profile.
- **A government agency wants an open model fine-tuned on its documents, on GPUs.** SageMaker in the agency's own AWS account in Sydney, in scope for IRAP PROTECTED. Not Runpod: the work must stay inside the client's account, and Runpod's Australian data center has L40S cards only.

## The technology on this site

- [Anthropic API, Bedrock or OpenRouter?](https://cloudlesslabs.com/stack/guides/anthropic-bedrock-or-openrouter/index.md): the decision guide
- [Resend or SES?](https://cloudlesslabs.com/stack/guides/resend-or-ses/index.md): the decision guide
- [Cloudflare Sandbox or Lambda MicroVMs?](https://cloudlesslabs.com/stack/guides/sandbox-or-microvms/index.md): the decision guide
- [Runpod or AWS for a GPU?](https://cloudlesslabs.com/stack/guides/runpod-or-aws/index.md): the decision guide
- [Cloudflare AI Gateway, OpenRouter or LiteLLM?](https://cloudlesslabs.com/stack/guides/ai-gateway-choice/index.md): the decision guide
- [Cloudflare or S3 and CloudFront for a website?](https://cloudlesslabs.com/stack/guides/static-hosting/index.md): the decision guide
- [Sending email](https://cloudlesslabs.com/stack/use-cases/email/index.md): the use case
- [An AI chat or LLM feature](https://cloudlesslabs.com/stack/use-cases/ai-chat/index.md): the use case
- [AI that runs the code it writes](https://cloudlesslabs.com/stack/use-cases/ai-code/index.md): the use case
- [A GPU for models and experiments](https://cloudlesslabs.com/stack/use-cases/gpu/index.md): the use case
- [A database](https://cloudlesslabs.com/stack/use-cases/database/index.md): the use case
- [BobNinja, serious software that runs entirely in your browser](https://cloudlesslabs.com/work/bobninja/index.md): in our client work
- [Week 44: OpenAI Decisions API](https://cloudlesslabs.com/weekly/2026-w44/index.md): in The Stack Weekly

## Related

- [Ask an LLM, or call a decision API?](https://cloudlesslabs.com/concepts/llm-or-decision-api/index.md): read next
- [Where should code nobody reviewed run?](https://cloudlesslabs.com/concepts/sandboxing/index.md): the decision after it
- [Security, access and residency](https://cloudlesslabs.com/concepts/areas/security/index.md): the area, and the technology for each answer
- [Every concept](https://cloudlesslabs.com/concepts/index.md)
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)