Should Your Data Live in Cape Town? The Real Tradeoffs of AWS af-south-1

Every few months a South African business owner asks us the same thing. Should our data live in Cape Town? The honest answer is not a slogan. Yes, AWS has a region here. Yes, it helps with POPIA and with latency. But location alone is not compliance, and the most expensive mistake we see has nothing to do with where your database sits. It is where your data goes the moment your software calls an AI model. So treat this as a decision tree, not a flag on a map.

Three real costs of af-south-1

AWS Africa (Cape Town), API name af-south-1, opened on 22 April 2020 with three Availability Zones. It was the first AWS region on the continent. That is genuinely useful. It also carries three costs nobody mentions in the sales pitch.

The first is the opt-in trap. Cape Town launched after March 2019, which makes it an opt-in region. It is disabled by default. You have to enable it in your account before you can create a single resource. Teams who assume every region is switched on out of the box lose a morning to this.

The second is egress. Moving data out to the internet from Cape Town sits around 0.154 USD per GB, against as low as 0.09 USD per GB in most US regions. That is roughly a 70 percent premium per terabyte. Cross-region transfer is worse, and it is lopsided. Pushing 1 TB into af-south-1 from us-west-2 runs about 20 USD. Sending that same terabyte back out runs closer to 150 USD. If your architecture shuttles data in and out of Cape Town all day, you pay for the privilege.

The third is general pricing. Compute and storage in Cape Town tend to run above the US baseline, in the same elevated band as Sao Paulo. Lower infrastructure density and higher local costs for power, property and cooling drive that. You are not imagining the bill.

The residency win is real but narrow

So why pay more at all? Latency and residency. For local users, af-south-1 cuts round trips to low double-digit milliseconds, against roughly 150 to 250 milliseconds when you route to Virginia or Europe. For anything a person waits on, like a checkout, a login or a support chat, that gap gets felt in the body. And keeping personal information physically in the country makes your POPIA story much simpler to tell.

The win is narrow because it does not cover everything. Development, testing and overnight batch jobs do not care about 200 milliseconds, and they do not hold live customer records. Those run materially cheaper offshore. Paying the Cape Town premium for them just lights money on fire.

Pay the Cape Town premium for latency-sensitive and personal-information workloads. Keep dev, test and batch offshore, where it is cheaper.

The agentic-software trap

Here is the part that catches careful teams. You can host your database in af-south-1, encrypt it, lock it down, and still ship every customer message offshore the second your software calls a frontier model.

For the region's first five years there was no local Amazon Bedrock at all. That changed on 19 November 2025, when Bedrock went live in Cape Town. By early 2026 the newer Claude models were reachable from af-south-1. Good news, with a catch. They arrive through global cross-region inference, not local hosting. The model sits behind a global inference profile, and the actual inference can be processed in AWS regions anywhere in the world.

AWS is upfront about this. Data at rest, your logs, knowledge bases and stored configs, is designed to stay in the source region, and CloudWatch and CloudTrail logs stay in Cape Town. But the request itself, the customer's actual message, can be processed offshore during inference. AWS tells customers in its own guidance to check whether this fits their obligations, and it names POPIA directly. The data in transit is encrypted and stays inside the AWS network. It can still leave South Africa.

That is the gap. Ticking a hosted in South Africa box on your storage while your AI layer routes personal information across borders is not residency. It is residency theatre. Closing that gap, designing the whole path and not just the front door, is the work we build for.

What POPIA actually requires

POPIA does not demand blanket data localisation. Section 72 permits transferring personal information outside the country when a lawful ground applies. That means adequate protection at the recipient through law or a binding agreement substantially similar to POPIA, or the data subject's consent, or contractual necessity, or a transfer made for their benefit. A few things make this trickier than the GDPR version people half-remember.

• Section 72 is triggered by access, not just movement. Remote admin, offshore support and view-only analytics run from outside the country all count as cross-border transfers that need controls.
• There is no adequacy list and no POPIA certification. The burden sits with you, the responsible party, to assess each recipient jurisdiction and document it. ISO 27001 and SOC 2 are useful signals, not a free pass.
• POPIA protects companies and trusts, not only natural persons. GDPR-based Standard Contractual Clauses do not cover a company's data, so you need jurisdiction-specific schedules bolted onto the transfer agreement.
• Your cloud provider is an operator. You stay the responsible party. The legal duty to ensure adequate security and no unlawful offshore transfer remains yours, usually evidenced by a signed data processing agreement.

The Information Regulator has signalled a forthcoming guidance note on transborder flows, advisory rather than binding. Worth watching, not worth waiting for.

A rule of thumb you can use on Monday

Pay the Cape Town premium for latency-sensitive and personal-information workloads. Keep dev, test and batch offshore, where it is cheaper. And treat both offshore access and offshore inference as a Section 72 transfer that needs a lawful ground and a signed agreement. If you call a frontier model on personal data, either keep that inference onshore or strip the personal information out before the request leaves.

That last line is where most of the real engineering happens. We design the whole path: af-south-1 data stores, POPIA-aligned operator agreements, and inference routing that either keeps personal information in the country or removes it before a request crosses a border. The region question is the easy part. The path is the job. In 2026 the question is no longer whether Bedrock is available here. It is whether your inference routing keeps personal information onshore, and whether you have the paperwork to back that up.