Data Residency in AWS af-south-1: What "Hosted in South Africa" Actually Means

"Hosted in South Africa" appears on a lot of vendor pages. It is a claim worth interrogating, because residency is not a single switch — it is a property that has to hold across compute, storage, model inference, logs, backups, and every managed service in between. A system can be 95% in-region and still leak the 5% that matters. This is what genuine residency in AWS af-south-1 requires, and where it usually breaks.

What af-south-1 is

af-south-1 is the AWS Africa (Cape Town) region, opened in 2020. Resources provisioned there run on infrastructure physically located in South Africa. That physical location is what underpins a data residency claim and, for POPIA Section 72 purposes, means data kept in-region is never transferred across a border — so the cross-border-transfer question simply does not arise for that data.

Where residency quietly leaks

Most residency failures are not the primary database — that part teams get right. The leaks are in the components nobody puts on the architecture diagram:

• Model inference. The database is in Cape Town but the LLM endpoint is in Virginia. Every prompt is a cross-border transfer. This is the most common leak in AI systems specifically.
• Logs and traces. Application logs containing personal information shipped to a logging service in another region.
• Backups and snapshots. Replicated to a second region for durability — sensible for availability, a residency breach if that region is offshore.
• Managed-service fallback. A service unavailable in af-south-1 silently served from the nearest region.

Genuine residency means auditing every one of these and confirming it stays in-region — or making the cross-border element lawful and documented under Section 72, as covered in the Section 72 piece.

Keeping model inference in-region

For AI systems, the inference step is the residency battleground. The clean pattern is to run the model in af-south-1 so prompts never leave the country. That is the core reason our architecture defaults to in-region inference — it removes the single largest cross-border surface an AI workload has. Where a workload genuinely needs a model only available offshore, the transfer is minimised and made lawful by agreement rather than left implicit.

Residency is necessary, not sufficient

Choosing af-south-1 removes the cross-border question, but it does not make a system POPIA-compliant on its own. POPIA still requires a lawful basis for processing (Section 11) and appropriate security safeguards (Section 19). Residency is one leg of a three-legged stool; the other two are covered in the POPIA sections deep-dive. Treating residency as the whole answer is a common and expensive mistake.

How we build for residency

Our default landing zone is af-south-1 primary, with compute, storage, inference, logs, and backups verified in-region, and residency enforced at the IAM and VPC boundary rather than left to convention. The full build is in Cloud Architecture & DevOps, and our standing security and residency posture is on the security page.