April 4, 2026 · Tim Fraser, Cloud Operations Lead

AWS Data Sovereignty in Australia — What You Need to Know

AWS has had a Sydney region (ap-southeast-2) since 2012. That means you can keep all your data in Australia. But "can" and "do" are very different things. Data residency on AWS requires deliberate choices at every layer of your stack, and there are several common gotchas that quietly move data offshore without anyone noticing.

Here's a practical guide to keeping your AWS data in Australia — and how to verify it.

Start with region selection

The most fundamental decision is launching all resources in ap-southeast-2. This sounds obvious, but it goes wrong in practice:

• Default region in the console — AWS often defaults to us-east-1. If someone on your team creates a resource without checking the region selector, it ends up in Virginia.
• CloudFormation and Terraform defaults — if your IaC templates don't explicitly set the region, they may inherit a default from the CLI profile or environment variable that points elsewhere.
• SDK and CLI configuration — check ~/.aws/config on every developer machine and every CI/CD runner. A missing or incorrect region setting is one of the most common causes of resources ending up in the wrong region.

S3 bucket policies and replication

S3 buckets are region-specific, but several features can move data across regions:

• Cross-Region Replication (CRR) — if enabled, your data is automatically copied to a bucket in another region. Check every bucket: S3 console → Management → Replication rules.
• S3 Transfer Acceleration — uses CloudFront edge locations to speed up uploads. The data still lands in your chosen region, but transits global edge infrastructure. For most compliance frameworks this is acceptable, but verify with your compliance team.
• Bucket policies — ensure your bucket policies don't grant access to principals in other accounts that might copy data to other regions.

CloudFront and edge locations

CloudFront caches content at edge locations globally. Cached copies of your content can exist outside Australia. For static assets (HTML, CSS, JS), this is generally fine. For dynamic API responses containing customer data, consider whether edge caching is appropriate.

A practical approach: ensure CloudFront only caches static, non-sensitive content, and route API calls directly to regional endpoints.

Services that are not region-scoped

Several AWS services operate globally: IAM (policies, roles, users), Route 53 (DNS), CloudFront (distributions), AWS Organizations/SCPs, and S3 bucket names (globally unique, though data is regional).

These are generally acceptable under Australian data sovereignty frameworks because they contain configuration data rather than customer data. But be aware of it, and document it in your compliance artifacts.

Common gotchas

How plainfra helps with data residency audits

plainfra can do this audit for you. Connect your AWS account with read-only access and ask:

> "Do I have any resources running outside ap-southeast-2?"

> "Are any of my S3 buckets configured for cross-region replication?"

> "Show me all backup plans with cross-region copy rules."

plainfra makes the API calls across your account, checks each service, and gives you a clear answer. It runs entirely in AWS Sydney — so even the act of auditing your data residency doesn't move data offshore.

The weekly health reports also flag new resources that appear outside your expected region, so you catch configuration drift before it becomes a compliance issue.