Skip to main content
zatersio

5 Point AWS Sydney Checklist for APP 8 Compliance in Australia

5 Point AWS Sydney Checklist for APP 8 Compliance in Australia

Decorative AWS compliance checklist title card

Yes, AWS lets you keep data inside the Asia Pacific (Sydney) Region, but compliance is never automatic. It depends on how you configure Control Tower guardrails, where you place your KMS keys, and what your contracts say. AWS handles the infrastructure; you handle the setup, the paperwork, and the OAIC’s “reasonable steps” test under APP 8.

TL;DR:

  • Storing data in the Sydney Region confirms residency, but regulatory compliance relies on proper configuration of control guardrails, key placement, and contractual commitments.
  • AWS local infrastructure includes multiple Availability Zones and local extensions, but control planes can operate globally, affecting sovereignty considerations.
  • Protecting data sovereignty requires enforceable contracts and documented risk assessments, not just geographic placement of data.
  • Technical guardrails such as region-deny guardrails, regional KMS key storage, and controlled data flow via Direct Connect are essential to prevent accidental data localization breaches.
  • Building data residency into projects from the start is more efficient than retrofitting, with local development options available for compliance and cost control.
Zatersio
Build Privacy Into Your Software
Zatersio combines bespoke engineering and AI driven automation with data residency options for businesses handling sensitive information.
Explore Zatersio

Table of Contents

What the AWS Sydney Region Actually Gives You

The Asia Pacific (Sydney) Region is a real, physical footprint, not a marketing label. AWS operates multiple Availability Zones there, each a cluster of physically separate data centers with independent power and networking, so a fault in one doesn’t take down your workload. Beyond Sydney, AWS has expanded its Australian presence with Local Zones and Direct Connect locations that push compute and low-latency connectivity closer to specific cities, plus a new Direct Connect site (SY5) opening in 2026.

That infrastructure matters because not every AWS service runs the same way everywhere:

  • Most services are Region-scoped: your data stays where you put it.
  • Some control planes, the systems that manage configuration rather than store your data, operate globally, which matters for strict sovereignty reviews.
  • Local Zones extend Sydney’s footprint for latency-sensitive workloads without creating a second full Region.

AWS is explicit on the core promise here: customers choose the Region where content lives, and AWS won’t move or replicate that content outside the chosen Region without agreement, except where the law requires it. That exception clause is the whole game. It’s why “my data is in Sydney” is a starting point for compliance, not the finish line.

Data Residency vs. Data Sovereignty: The Distinction That Trips Up Most Teams

Residency answers a physical question: where does the data sit? Sovereignty answers a legal one: who can compel access to it, and under which country’s laws? A file sitting in the Sydney Region satisfies residency. It says nothing about whether a foreign court order, a vendor’s support process, or a misconfigured backup could expose that same file to a jurisdiction you never agreed to.

The Australian Privacy Principles, specifically APP 8, govern this directly. Before disclosing personal information to an overseas recipient, including cases where support staff or subprocessors access Sydney-hosted data from outside Australia, an organization must take reasonable steps to ensure the recipient doesn’t breach the APPs. The OAIC doesn’t hand you a checklist with a pass mark. It expects a documented, defensible process. In practice, that means:

  • Enforceable contractual clauses binding any overseas party to APP-equivalent protections.
  • Privacy policy updates that name the categories of overseas disclosure, even indirect ones.
  • A documented risk assessment showing you actually considered where support, logging, or failover could send data offshore.

Storing data in Sydney reduces your exposure. It doesn’t remove the obligation to prove you’ve managed the legal risk around it, which is where a lot of otherwise well-architected projects fall short during audits.

The AWS Controls That Actually Enforce Residency

Good intentions don’t stop a developer from spinning up a resource in the wrong Region at 11 p.m. Technical guardrails do. Here’s the stack Australian teams should be building, roughly in order of impact:

  1. Control Tower region-deny guardrails. Applied at the Organization or OU level, these preventive and detective controls block resource creation outside Sydney, closing off the accidental cross-Region mistake that no policy document ever prevents.
  2. KMS key placement. Keep customer-managed keys (CMKs) created and stored in the Sydney Region. For the strictest cases, AWS KMS External Key Store (XKS) lets you hold key material outside AWS entirely while still using it for encryption operations inside Sydney.
  3. S3 and IAM hardening. Block public access by default, disable cross-Region replication unless a regulator has explicitly approved it, and attach IAM policies with location conditions so access itself is geographically constrained.
  4. CloudTrail and AWS Config. These generate the audit trail regulators and auditors will eventually ask for, turning “we believe we’re compliant” into “here’s the log.”
  5. Direct Connect over public internet paths. Routing traffic through dedicated connections reduces the chance that data transits infrastructure outside your control.

Pro Tip: Region-deny guardrails catch infrastructure mistakes, but they won’t stop a CI/CD pipeline from deploying to the wrong Region if your build scripts hardcode a different one. Add a Region check as a pipeline gate, not just an account-level policy.

Where the control plane itself, not just the data, needs to stay local, standard Regions aren’t enough. That’s when AWS Outposts or Dedicated Local Zones earn their cost, keeping management operations physically in-country rather than reaching back to a global control plane.

Local and global cloud control structures

Choosing a Recovery Strategy Without Breaking Residency Rules

Disaster recovery is where a lot of otherwise solid residency setups quietly fail, because the backup plan often gets designed after the compliance review, not during it. AWS outlines three recognized approaches, and each suits a different risk appetite:

  • Cryptographic boundary: Encrypt everything with Australia-resident CMKs, and only allow cross-Region replication of the encrypted payload if a regulator has signed off. The data may technically leave, but it’s unreadable without keys that never do.
  • Data-bound recovery via Outposts: Keep primary data in-country while using Outposts or an on-premises parent Region for failover, avoiding a second cloud Region entirely. Choosing a parent Region different from your primary avoids losing both control planes in a single regional event.
  • Strict local autonomy: A fully on-prem or multi-cloud lifeboat that never touches infrastructure outside Australia, at the cost of higher operational complexity and duplicated engineering effort.

Pick the strategy that matches what your regulator will actually accept, test the failover end to end before you need it, and write down every assumption. Auditors trust tested runbooks far more than architecture diagrams.

What Auditors and Regulators Actually Check

Certifications don’t replace configuration, but they carry weight with government and regulated buyers. AWS has undergone IRAP assessment up to the Protected level, and reviewers increasingly look for alignment with the Australian Hosting Certification Framework when evaluating cloud vendors for sensitive workloads.

None of that shifts your responsibility, though. The shared responsibility model draws a clean line: AWS secures the physical infrastructure, the hypervisor layer, and the global network. You control configuration, encryption key management, identity policies, and who gets access to what. An IRAP assessment tells you AWS’s side of that line holds up. It says nothing about whether your S3 bucket is still publicly readable.

When an auditor comes knocking, expect them to ask for:

  • CloudTrail logs showing account activity over the relevant period.
  • AWS Config snapshots proving resource configuration at a point in time.
  • Records confirming CMK creation, location, and rotation history.
  • Contracts and subprocessor agreements demonstrating APP 8 cross-border risk was assessed, not assumed.

A Quick Validation Checklist for Your Team

Before you tell a client, a board, or a regulator that your AWS environment meets Australian residency expectations, run through this:

  1. Confirm region-deny SCPs are active across every account and OU, not just the production account.
  2. Verify KMS key location and review key policies for anyone with unnecessary decrypt permissions.
  3. Check Direct Connect configuration to confirm data paths avoid unnecessary public internet transit.
  4. Set up CloudTrail and Config alerts with retention policies that match your industry’s record-keeping obligations.
  5. Assemble the APP 8 paper trail: signed contracts, any data protection impact assessments, and documented vendor commitments.

Pro Tip: Run a test failover at least once a year and keep the results. “We have a disaster recovery plan” and “we proved our disaster recovery plan doesn’t leak data offshore” are very different answers to give an auditor.

How Zatersio Approaches Australian Data Residency

We build Australian-resident MVPs and automation projects with data residency chosen up front, not retrofitted later. That means applying the same Control Tower guardrails, KMS key placement, and audit logging covered above, and handing clients the evidence trail as part of delivery, not as a favor after the fact. If you’re planning an AWS-based build, our data sovereignty guidance walks through what that setup looks like in practice.

— Lakitha

Build It Right the First Time, With Residency Baked In

Retrofitting data residency into a system that was never architected for it is expensive and slow. Data residency can be built into projects from day one, providing engineer-delivered software with pricing and Australian-resident infrastructure as a standard option, not an add-on negotiated after launch.

Zatersio

Some teams scope and deliver projects directly by Melbourne-based engineers rather than passing through account managers or offshore teams, helping keep fixed pricing and consistent Control Tower, KMS, and audit-logging setups. If you’re weighing an MVP build or a workflow automation project that needs to satisfy APP 8 and residency reviews, our MVP Development page outlines how a typical build runs from scoping to delivery. Teams further along, already sold on the architecture and ready to talk numbers, can check fixed pricing across our automation and agent builds. Either way, the next step is a conversation about your specific residency requirements before a single line of infrastructure gets provisioned.

Sources

FAQ

Where Are AWS Data Centers Located in Australia?

AWS operates the Asia Pacific (Sydney) Region across three Availability Zones, along with Local Zones and Direct Connect locations that extend its footprint into other Australian cities. Amazon has also committed to investing AU$20 billion in Australian data center infrastructure between 2025 and 2029.

What Are the Availability Zones for AWS Sydney?

The Asia Pacific (Sydney) Region runs on three Availability Zones, each made up of physically separate data centers with independent power and networking. This structure lets workloads fail over within the Region without any data leaving Australia.

Is Amazon Building More Data Centers in Australia?

Yes. Amazon has announced plans to invest AU$20 billion in Australian data center infrastructure between 2025 and 2029, aimed at expanding capacity and AI capability in-country.

Does Storing Data in AWS Sydney Guarantee Compliance With Australian Privacy Law?

No. Storing data in the Sydney Region satisfies residency, but the Privacy Act’s APP 8 still requires reasonable steps around any overseas disclosure, including support access or subprocessor arrangements. You need Control Tower guardrails, KMS key placement, and contractual terms working together, not just a Region selection.

Can Zatersio Set Up AWS Data Residency for My Project?

Yes. Australian-resident MVPs and automations can be built with data residency selected at the start of the project, using Control Tower and KMS controls as described above. Current pricing for automation builds is listed on the pricing page.