Security, access and residency

The decisions, in order

1. 01 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. →
2. 02 Where should code nobody reviewed run? Where does code written by a model or a customer run, so it can't reach your credentials, your network or the next user's files? A sandbox is for code nobody on your team reviewed: code a model writes at runtime, or code a customer uploads. Reviewed code, even an agent's, runs in a normal Lambda, Worker or Fargate task. Unreviewed code must never run where your credentials live: a Lambda carries its role and environment variables, and its /tmp survives into the next invocation. Give each session its own walls (a container on Cloudflare Sandbox by default; a microVM on Lambda MicroVMs when the code must stay in Australia, reach a private VPC, use a bigger machine or keep its processes for hours) and put nothing secret inside: its traffic leaves through a proxy that adds the credentials, to the destinations it needs and no others. →
3. 03 One AWS account, or many? Should everything run in one AWS account with careful policies, or behind walls of accounts, one per environment and workload, with the backups in an account of their own? An account is the hardest wall AWS has: two accounts can't touch each other unless someone allows it. Inside one account, only IAM policies stand between a leaked key or a wrong command and production, and some limits are shared by everything in it: Lambda's concurrency pool, SES's sending reputation. So put a wall wherever one thing must not be able to hurt another: production apart from dev and staging, a workload that can damage a shared limit in its own account, a client's systems in the client's accounts, and the backups in an account production can't write over. Organizations costs nothing extra and Savings Plans still apply across the accounts, so the cost of the walls is setup, not the bill. →
4. 04 Who holds your keys, and for how long? Should people, pipelines and apps carry long-lived keys or borrow short-lived roles, where does each secret live, and which code you didn't write runs next to them? Every credential answers three questions, usually by accident: who holds it, how long it works, and what else runs next to it. A long-lived key works from anywhere until someone revokes it, and outlives the person who made it. A borrowed role works for one session: a person through SSO, a pipeline through OIDC, a function through its own role, so there's nothing stored to leak. The secrets that can't be a role (a database password, a Stripe key, a model provider's key) go in the secret store, one job per key, read at runtime by reference. And the code you pull runs with all of them: a tag can be moved, so pin it to a SHA, a digest or a hash. →
5. 05 Coming in, or going out? Should your people come into the private network, or should one service go out to the public, and is anything still listening on a public address? Private access is a question of direction. What the public must reach gets a public endpoint, on purpose, and only one per job. Your own machines (laptops, CI runners, agent boxes) come in over a mesh network that opens no port; a VPN or a bastion does the same job at more cost and with more to run. A service the public or a client's staff must see, on a box with no open port, goes out through a tunnel: the box calls out, nobody calls in. Decide the direction per connection, then list what still answers on a public address. Most boxes need a way in and a way out, and the two don't compete. →

If you chose this, use this

The data may go anywhere

The global tools: Cloudflare Workers, OpenRouter, Resend

It must stay in Australia

Neon or S3 in Sydney, SES for email, Claude through Bedrock's AU profile: Anthropic API, Bedrock or OpenRouter?

Code nobody reviewed

Cloudflare Sandbox by default, Lambda MicroVMs in Sydney when it must stay in Australia or reach a VPC, nothing secret inside either: Where should code nobody reviewed run?

Walls between environments

AWS Organizations and Identity Center: an account per environment, and a backup account production can't write over: One AWS account, or many?

Keys and secrets

SSO and OIDC roles instead of keys, Secrets Manager read at runtime, every action pinned to a commit SHA: Who holds your keys, and for how long?

People in, a service out

Tailscale for your own machines coming in, Cloudflare Tunnel for a service going out: Coming in, or going out?

GPUs on the client's data

SageMaker in the client's account: Runpod or AWS for a GPU?