AWS has 200-plus services, but you don't learn it service by service — you learn it through the one idea that runs underneath all of them: identity. Nothing happens on AWS until IAM says it can. Master that, then a small core of services — Lambda, ECS, API Gateway, S3, RDS, DynamoDB, VPC — covers most real builds. This leaf is the practical map for the 2nth stack: the identity model, the core services, the af-south-1 Cape Town region and what it actually runs, and the Cloudflare + AWS hybrid where egress cost decides the design.
Amazon Web Services is the largest public cloud by revenue and breadth: compute, storage, databases, networking, machine learning, analytics and contact-centre software, all rented by the second or the request, in data centres grouped into regions (geographic) and availability zones (isolated facilities within a region). You provision through a console, a CLI, an SDK, or infrastructure-as-code — never by buying a box.
Its strength is also its trap. The breadth means there's a service for almost everything, and the temptation is to use all of them. In practice a disciplined build touches a dozen services, wires them together with least-privilege identity, and treats the other 190 as available-if-needed rather than as a shopping list. The skill on AWS isn't knowing every service — it's restraint, and getting the identity boundaries right.
AWS competes with Microsoft Azure and Google Cloud. The honest summary for SA work: AWS has the deepest service catalogue and the Cape Town region; Azure has the only major in-country LLM inference region (South Africa North); GCP leads on data and certain AI surfaces. Most serious estates end up multi-cloud, and the architecture question becomes which workload lands where — and what the traffic between them costs.
A region (e.g. af-south-1, Cape Town) is a geographic location and the unit of data residency — data you put there stays there unless you move it. An availability zone is one of several isolated data centres inside that region; spreading across AZs is how you survive a single-facility failure. af-south-1 has three AZs. Residency is a region decision; resilience is an AZ decision.
IAM — Identity and Access Management — is the part of AWS you must understand first, because every other service routes through it. Every request is an identity asking to take an action on a resource, and IAM evaluates a policy to allow or deny it. Get this right and the rest is detail; get it wrong and you have either an outage or a breach.
Four concepts carry it:
// A least-privilege policy: read one S3 bucket, nothing else { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::reports-af-south-1", "arn:aws:s3:::reports-af-south-1/*" ] }] }
The single biggest AWS security improvement is to stop minting long-lived access keys. Human access goes through IAM Identity Center (AWS SSO) federated to your identity provider, issuing temporary credentials. Service access uses assumed roles — a Lambda gets its permissions from an execution role, not a secret in an env var. CI/CD authenticates via OIDC federation (e.g. GitHub Actions assuming a role), so there are no AWS keys in your pipeline at all. A leaked temporary credential expires; a leaked permanent key is a standing liability.
Grouped by what they're for. You can build the large majority of production systems from this core; everything else is reached for when a specific pressure demands it.
Functions, containers and VMs, plus the HTTP front door that fronts them.
Lambda · ECS/Fargate · EC2 · API GatewayObject storage for everything, block storage for VMs, shared file systems where needed.
S3 · EBS · EFSManaged relational (Postgres/MySQL), AWS-native Aurora, key-value at scale, and a cache.
RDS · Aurora · DynamoDB · ElastiCacheYour private network, DNS, load balancing, and AWS's own CDN.
VPC · Route 53 · ELB · CloudFrontFoundation models (including Claude) via one API, plus full ML tooling.
Bedrock · SageMakerCloud contact-centre as a service — telephony, routing, agent desktop, analytics.
Amazon ConnectQueues, pub/sub topics and an event bus — the backbone of event-driven designs.
SQS · SNS · EventBridgeLogs, metrics, alarms and the API-call audit trail every compliance review asks for.
CloudWatch · CloudTrailAmazon Bedrock is the managed way to call foundation models — including Anthropic's Claude family — behind one IAM-gated API, with no infrastructure to run. It's the natural AI surface if your data and apps already live on AWS. The caveat is regional: Bedrock's model availability is concentrated in larger regions (US, EU, parts of APAC) and has historically lagged in af-south-1. For SA workloads that means either calling Bedrock cross-region (accept the latency and the data-leaves-the-country question), or using Azure South Africa North for in-country LLM inference. Verify current region support before you design around it.
AWS opened the af-south-1 region in Cape Town in April 2020 — the first hyperscale AWS region in Africa, with three availability zones. For SA delivery it's a genuine advantage: low-latency local compute and, crucially, a place to keep data in-country. But it is not a full mirror of the big US and EU regions, and pretending otherwise causes late-stage surprises.
| In af-south-1 | What you get | Watch for |
|---|---|---|
| Core compute & storage | EC2, Lambda, ECS/Fargate, S3, EBS | Solid — the foundation is all here |
| Databases | RDS, Aurora, DynamoDB | Well supported for transactional work |
| Networking | VPC, Route 53, CloudFront edge presence | Cape Town & Johannesburg edge locations |
| Newest AI services | Limited — Bedrock model coverage lags | Plan cross-region or Azure SA North |
| Amazon Connect | Not a launch region historically | Confirm availability; may need another region |
| Pricing | Generally higher than us-east-1 | Newer/smaller regions cost more per unit |
The reason af-south-1 matters for POPIA isn't that AWS is "compliant" — it's that you can pin residency-sensitive data to South African soil and prove it. Keep personal and regulated data in af-south-1; let stateless compute and non-sensitive workloads run wherever's cheapest or has the service you need. The architecture deliverable is a data map that shows, per data store, which region holds it and why — the document a regulator actually wants to see.
The 2nth house pattern isn't AWS-only. It's Cloudflare at the edge — DNS, CDN, WAF, and Workers for latency-sensitive logic — in front of AWS for the heavy, stateful, long-running work that the edge isn't built for. The two halves play to their strengths; the one number that governs the design is data egress.
The division of labour, in practice:
af-south-1 for residency.If you serve large files or media, putting them in AWS S3 and streaming them to users means paying AWS egress on every download. Cloudflare R2 is S3-compatible storage with zero egress fees — so the common optimisation is to keep transactional data in AWS (where the database and residency are) but serve bulk objects from R2 at the edge. Decide what lives where by asking "how often does this data leave the cloud, and to whom?" The answer, not service preference, should draw the line. For FX-exposed SA budgets, a runaway egress bill is one of the most common and avoidable cloud-cost mistakes.
AWS is the safe default for stateful, heavy, or breadth-demanding work. It is not always the right or cheapest answer — especially for edge-shaped or purely AI-inference workloads in an SA context.
af-south-1AWS bills are rarely surprising on compute — they're surprising on egress, NAT Gateway, and idle provisioned capacity. Set budgets and alarms on day one, prefer scale-to-zero (Lambda/Fargate) over always-on EC2 for spiky work, and watch cross-AZ and cross-region data transfer. For rand-denominated budgets against USD billing, a cost anomaly alert is not optional — it's the difference between a managed line item and a month-end shock.
The Cape Town region changed what's possible for SA cloud delivery — but the gaps, the FX exposure and the multi-cloud reality all shape how AWS actually gets used here.
af-south-1 lets you keep personal and regulated data in South Africa and demonstrate it — the practical core of a POPIA data-residency posture. Pair it with CloudTrail for the audit log of who-did-what, and IAM Identity Center so access is named, temporary and revocable. The combination — local region, audit trail, least-privilege identity — is most of what an SA compliance review is looking for.
The common SA enterprise shape in 2026: AWS for stateful compute and databases in af-south-1, Azure South Africa North for in-country LLM inference (the one thing AWS can't yet do locally at the frontier), and Cloudflare at the edge for delivery and egress savings. Architecture's job is to draw which workload sits where and to keep the inter-cloud traffic — and its cost — deliberate rather than accidental.
Amazon Connect is a credible cloud contact-centre for SA operations — pay-per-use telephony, omnichannel routing, and a natural path to AI agents (Bedrock-backed bots, real-time transcription). Confirm regional availability and number-porting for South African telephony before committing; Connect's launch regions have not always included af-south-1, which can mean running it from another region with the latency and residency implications that brings.
South Africa North covers the in-country LLM inference that af-south-1 doesn't.Official AWS documentation and the canonical references behind this leaf. Regional service support changes — always confirm af-south-1 availability against the live region table before designing around a service. Last reviewed 2026-06-17.