Skip to main content
zatersio

AWS Data Residency: Two Regions, APP 8 Duties for Australian Teams

AWS Data Residency: Two Regions, APP 8 Duties for Australian Teams

Sketch motifs frame an Australian cloud residency title

Yes, you can keep AWS hosted data in Australia by choosing the Sydney or Melbourne Region, but Region selection alone doesn’t satisfy the Privacy Act. Under APP 8, your organization stays accountable for how that data is handled, and you need to take and document reasonable steps. Replication settings, backup defaults and third-party connectors can quietly move data offshore even when your primary workload sits onshore.

TL;DR:

  • APP 8 requires reasonable steps before overseas disclosure of personal information, and section 16C makes your organization accountable for an overseas recipient’s breach.
  • Sydney is AWS’s more service complete Australian Region, while Melbourne offers geographic separation for resilience across Australian deployments.
  • Set customer managed KMS keys in an Australian Region and use organization policies to block other Regions, while checking backup copies and connector destinations.
  • Run quarterly configuration audits, maintain a data flow map and asset register, and secure contract audit rights for overseas recipients.
Zatersio
Build with Data Residency in Mind
Zatersio builds bespoke software with data residency options, helping Australian teams automate administrative work while considering compliance and privacy needs.
Explore Zatersio

Table of Contents

Which AWS Regions exist in Australia and what “Region” actually means

AWS runs two full Regions on Australian soil: Asia Pacific (Sydney), known as ap-southeast-2, and Asia Pacific (Melbourne), known as ap-southeast-4. Each Region is built from multiple isolated Availability Zones, so choosing an Australian Region places your content onshore by default, unless you or a service configuration explicitly move or copy it elsewhere.

Beyond full Regions, AWS also offers Local Zones and Outposts, which extend compute closer to specific cities or even inside your own data center. These are useful when a workload needs very low latency or a physical locality guarantee that a standard Region can’t match, but they come with their own procurement and operational overhead and aren’t a substitute for a proper Region when you need full service parity.

  • Sydney (ap-southeast-2): the original and most service-complete Australian Region.
  • Melbourne (ap-southeast-4): a newer Region, useful for resilience and geographic separation from Sydney.
  • Local Zones and Outposts: niche options for latency or physical locality needs, not full Region replacements.

How APP 8 and section 16C govern cross-border cloud storage

The Privacy Act 1988 doesn’t stop you from using cloud infrastructure, including infrastructure located overseas. What it requires is accountability. Under APP 8, before you disclose personal information to an overseas recipient, you must take reasonable steps to ensure that recipient handles it consistently with the Australian Privacy Principles. Section 16C then makes your organization accountable for a breach by that overseas recipient as if you had committed it yourself.

Overseas disclosure with Australian accountability retained

A significant portion of Notifiable Data Breach reports to the OAIC name third-party or supply chain failures as a contributing factor, which is part of why cross-border disclosure attracts close regulatory attention. See the OAIC’s guidance on reasonable steps and accountability.

What counts as “reasonable” is risk-based rather than fixed. The APP Guidelines point to a few consistent factors:

  • The sensitivity of the information and the harm a breach could cause.
  • The practical measures available, including contractual terms and audit rights.
  • Whether the recipient’s jurisdiction has protections substantially similar to the APPs.

The Act applies whenever an entity has an “Australian link,” a test defined in the legislation itself, which is why offshoring infrastructure doesn’t remove your obligations under the Notifiable Data Breaches scheme.

A step-by-step checklist for keeping AWS data in Australia

Technical controls and paperwork need to move together. Here’s a practical sequence IT and compliance teams can run through:

  1. Lock region settings in your account configuration and infrastructure-as-code templates so new resources default to Sydney or Melbourne.
  2. Audit replication and backup jobs for Cross-Region Replication, snapshot copy rules, or scheduled backups that quietly target another Region.
  3. Use customer-managed KMS keys created in an Australian Region, and restrict key policies so they can’t be used cross-region.
  4. Apply Organization-level Service Control Policies through Control Tower to block resource creation outside approved Regions, and tag resources for ongoing drift detection.
  5. Add enforceable contract clauses with cloud suppliers and integration partners, requiring APP-consistent handling and giving you audit rights.
  6. Build an evidence pack: a data-flow map, signed contract addenda, and a configuration export you can hand to an auditor or regulator on request.

Pro Tip: Run the SCP audit quarterly, not just at launch. Teams add new services and third-party integrations constantly, and a Region guardrail set up a year ago won’t catch this month’s new connector.

Which AWS services and settings actually determine residency

Region selection sets the default, but individual services have their own settings that can override it. A few deserve specific attention:

  • Amazon S3: choose Region-scoped buckets and review replication rules, especially cross-account replication, which can send copies to a bucket owned by a different team in a different Region.
  • AWS KMS: use customer master keys created in an Australian Region, and monitor grants so a key isn’t being called by a resource outside that Region.
  • AWS Backup, EC2 snapshots and RDS snapshots: confirm backup vaults and snapshot copy settings stay within Australia, since default snapshot policies sometimes replicate for disaster recovery purposes without an explicit Region lock.
  • DataSync, Transfer Family and third-party connectors: check that both source and destination endpoints sit inside Australian infrastructure.
  • Control Tower, Organizations and tagging: these give you the enforcement layer, letting you catch a misconfigured resource before it becomes a compliance incident rather than after.

Common pitfalls and the governance habits that prevent them

Most accidental offshore transfers don’t come from a deliberate decision. They come from defaults nobody checked. S3 replication rules, AMI copy policies, and third-party analytics or CRM connectors are frequent culprits, quietly sending a copy of data to a Region nobody chose on purpose. Shadow IT, where a team spins up a tool without informing the people who own data governance, compounds the problem.

Contract gaps cause the same issue from a different angle: missing audit rights, vague service-level agreements, or a subprocessor list that’s never updated means you can’t actually verify what your APP 8 reasonable steps obligations require.

  • Maintain an information asset register that tracks where each dataset lives and who can move it.
  • Run periodic configuration and cross-region audits rather than relying on a one-time setup review.
  • Keep a documented Notifiable Data Breach playbook so your team knows the reporting timeline before an incident happens, not during one.

How Zatersio approaches onshore AWS deployments for client projects

When we scope a project for an Australian client, data residency is a decision we make at the start, not something bolted on later. We build MVPs and automations with the option to host on Australian infrastructure, and because our engineers scope the work directly rather than passing it through account managers, Region and key placement decisions get locked in early rather than discovered during an audit. You can see how we think about this in more detail on our data sovereignty page.

Clients working with us can request a few specific deliverables alongside the build itself:

  • A data-flow map showing where each piece of information is stored and processed.
  • A KMS placement plan confirming which Region holds the encryption keys.
  • A contractual addendum covering handling obligations and audit rights.
  • A runbook for backups and incident response that keeps both resilience and residency intact.

Three priorities for Australian IT and compliance leads right now

If you take one thing from this guide, make it this: Region selection is the easy part. The harder work is knowing exactly where every copy of your data lives, including the ones created by a backup job or a forgotten integration nobody audited this year.

Start by mapping and classifying your data assets, then lock down Region and key settings so new resources can’t drift outside them. Document your contractual and technical reasonable steps now, while you have time to do it properly, and keep that documentation current as vendors and services change. Finally, test your recovery and incident workflows under real conditions, because a backup that restores fast but restores from the wrong Region solves nothing.

— Lakitha

Need an onshore build without the guesswork?

If you’re planning a new MVP, an automation, or a custom AI agent and data residency is part of the brief, we scope that from day one, not as an afterthought. Our fixed-price projects (from workflow automations through to custom AI agent builds) include Region and key placement as part of the initial engineering conversation, and because the build is engineer-led from the start, decisions about where data lives get made once, correctly.

Zatersio

  • Fixed pricing across single workflow automations, multi-step automations and custom AI agent builds.
  • Engineer-led scoping means Region, KMS placement and contract requirements get decided early.
  • A documented approach that supports your APP 8 reasonable steps requirements, not just a working app.

Check our MVP development page for how a two-week build fits your timeline, or request a free automation blueprint to see what a residency-aware scope looks like for your project before you commit to anything.

FAQ

Where are AWS data centres in Australia?

AWS operates two full Regions in Australia: Sydney (ap-southeast-2) and Melbourne (ap-southeast-4). Each Region contains multiple physically separate Availability Zones, and AWS also offers Local Zones for workloads needing very low latency in specific cities.

What are the data residency requirements in Australia?

There’s no blanket law forcing all personal data to stay inside Australia. Instead, APP 8 of the Privacy Act requires you to take reasonable steps before disclosing personal information overseas, and section 16C holds you accountable for how an overseas recipient handles it.

Is Amazon building data centers in Australia?

AWS already operates established Regions in both Sydney and Melbourne, giving organizations a choice of two onshore locations for their workloads. Both support the full range of standard AWS services needed for most production deployments.

Does Australia have a GDPR equivalent?

Australia’s core privacy framework is the Privacy Act 1988 and its Australian Privacy Principles, which cover similar ground to the GDPR but differ in structure and specific obligations. The Act applies to entities with an “Australian link,” as defined in the legislation, rather than applying universally to all data processing globally.

Sources