Where may the data go?

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.

The options

Global by default. Cloudflare Workers run wherever the request lands. OpenRouter routes globally: in-region routing exists only for the EU and the US, on the Business plan. Anthropic's API processes requests in the US or globally. Resend and Postmark store data in the US, and PostHog 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 is available in Sydney: you pick the region when you create the project. Claude on Amazon Bedrock 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, D1 and Durable Objects take a location hint, which is best effort, and a Cloudflare Sandbox container can't be pinned to Australia. A hint says where the data will probably go. S3'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 for files, SES for email, Lambda for the API, Lambda MicroVMs for code nobody reviewed (in Sydney since 19 August 2026; I'm still watching it), SageMaker or EC2 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, 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:

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

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? 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.