AWS from Nairobi in 2026: what the infrastructure actually looks like and how to design for it

There is no AWS Region in Nairobi and no live Nairobi Local Zone. What Nairobi has in 2026 is an AWS Direct Connect location at East Africa Data Centres NBO1, an Amazon CloudFront point of presence, an AWS development centre, and a full AWS Region three and a half thousand kilometres south in Cape Town. Designing well from Nairobi means accepting that geography and building for it with private connectivity, edge caching, hybrid infrastructure where residency or latency demand it, and asynchronous patterns everywhere else.

The inventory, stated precisely

A surprising amount of architecture goes wrong because someone believed a press release that announced something rather than delivered it. Here is what exists as of this writing.

Capability	Status	Detail
AWS Africa (Cape Town) Region, af-south-1	Live since April 2020	Three Availability Zones. AWS’s only full region on the continent.
AWS Local Zone, Lagos	Generally available since January 2023	Low-latency compute and storage for Nigeria.
AWS Local Zones, Nairobi and Johannesburg	Announced, not live	Still listed as planned. Do not design against them.
AWS Direct Connect, Nairobi	Live since 3 September 2025	At East Africa Data Centres NBO1. 10 Gbps and 100 Gbps dedicated connections with MACsec encryption.
Amazon CloudFront PoP, Nairobi	Live	Edge caching for static and dynamic content.
AWS development centre, Nairobi	Open since October 2023	Engineering presence; not customer infrastructure.
AWS Outposts, second generation	Orderable since January 2026 in Nigeria, South Africa, Morocco and Senegal	Kenya availability follows the KoTDA and AWS Konza agreement of August 2026.

The full and current list is on aws.amazon.com under global infrastructure. Check it before committing a design document to a client, because the list moves.

What the Cape Town distance means in practice

Nairobi to Cape Town round-trip latency over good fibre sits in the tens of milliseconds, with the exact figure depending on the carrier path and whether traffic routes down the east coast cable systems or takes a longer path. For most business applications this is fine. A web request that spends 40 to 60 milliseconds in transit is not what users notice; they notice the application making twelve sequential round trips to render one page.

Where the distance genuinely bites:

• Chatty protocols. Database-per-request patterns, synchronous microservice chains and ORM-generated query storms multiply the latency.
• Real-time interaction. Trading, gaming, industrial control and some payments authorisation flows have budgets that a cross-continent hop consumes.
• Large data movement. Backing up terabytes over the public internet from Nairobi is slow and unpredictable without dedicated connectivity.

Where it does not bite, and people assume it does: ordinary web and mobile applications, APIs with sensible batching, analytics, batch processing, machine learning training and most back-office systems.

Design pattern one: Direct Connect plus CloudFront

The NBO1 Direct Connect location is the most important infrastructure change for Nairobi in years. Before it, every byte between a Nairobi office and the Cape Town Region crossed the public internet, with the variability that implies. A dedicated connection gives you consistent latency, predictable throughput and a private path that does not depend on the peering decisions of intermediate carriers.

A typical design for an enterprise in Nairobi:

• A 10 Gbps dedicated connection at NBO1, or a hosted connection through an AWS Partner for smaller bandwidth needs, with MACsec enabled for link-layer encryption.
• A Direct Connect gateway attached to a transit gateway in af-south-1, so multiple VPCs share the connection.
• A site-to-site VPN over the internet as a failover path, with routing that prefers Direct Connect.
• Amazon CloudFront in front of every public-facing application, using the Nairobi PoP to serve cached content and terminate TLS close to users. Dynamic requests travel from the PoP to Cape Town over the AWS backbone rather than the open internet.

The combination means your staff and your systems talk to AWS over a private line, and your customers reach your applications through an edge that is physically in Nairobi. Most of the latency complaints we are brought in to fix are solved by this pair of changes and some application tuning, without any need for infrastructure in Kenya.

Design pattern two: hybrid with Outposts for the workloads that need it

Some workloads cannot tolerate the trip to Cape Town. Two reasons dominate: latency budgets below what the fibre allows, and data residency obligations such as the Restricted tier under Kenya’s Cloud Policy 2025 or the Regulation 26 list under the Data Protection Act.

AWS Outposts puts AWS compute, storage and a subset of services on racks in a facility of your choosing, managed from the parent region. The second-generation Outposts, orderable in several African countries since January 2026, improve on the first generation in capacity and supported services. The August 2026 agreement between KoTDA and AWS to deploy an Outpost at Konza Technopolis is specifically aimed at a hybrid government cloud, with data remaining within Kenya.

A hybrid pattern we recommend:

• Systems of record with residency requirements run on the Outpost: databases on Amazon RDS on Outposts, application tiers on Amazon EC2 or Amazon EKS on Outposts, local object storage on Amazon S3 on Outposts.
• Everything else runs in af-south-1: analytics, machine learning, development and test environments, archival storage and the control plane.
• Direct Connect links the Outpost’s facility to the region for management traffic, replication of non-restricted data and burst capacity.

The trade-off is cost and operational scope. An Outpost is a capital-style commitment with a defined capacity ceiling. It suits a well-understood steady-state workload, not an experimental one.

Design pattern three: asynchronous by default

The most durable fix for distance is architectural rather than physical. Systems that communicate through queues and events are indifferent to whether the consumer is 5 kilometres or 5,000 kilometres away.

Practical moves:

• Replace synchronous service-to-service calls with Amazon SQS queues or Amazon EventBridge events wherever the caller does not need an immediate answer.
• Use AWS Step Functions to orchestrate multi-step business processes so each step is a durable state rather than a held HTTP connection.
• Batch writes. A mobile money reconciliation that posts 10,000 records one at a time is a latency disaster; posted as 10 batches of 1,000 it is a non-event.
• Cache reads near the user. Amazon ElastiCache in the region for hot data, CloudFront at the edge for anything cacheable.
• Design mobile clients for offline-first operation with sync, which also suits the connectivity reality of many Kenyan users outside Nairobi.

These are good practices anywhere. From Nairobi they are the difference between an application that feels local and one that feels far away.

Resilience across a single region

With one region on the continent, resilience planning has a particular shape. Three Availability Zones in Cape Town give you good protection against data centre and zonal failures. Multi-AZ deployments for databases and load-balanced application tiers across at least two zones should be the default for anything production.

For regional failure, the realistic options are a warm standby in a European region such as Europe (Frankfurt) or Europe (Ireland), with the data classification work done to confirm which datasets may be replicated out of Africa, or an in-country Outpost for the subset that cannot leave. Many organisations will find that a European standby is acceptable for Open-tier data and that the Restricted tier is small enough to protect with in-country backup.

What to do next

If your Nairobi workloads currently reach AWS over the public internet, the single highest-value step is a Direct Connect assessment: measure your current latency and throughput, size a connection at NBO1, and model the cost against your egress and VPN spend. Pair it with a CloudFront review of your public-facing applications. Then classify your data to decide whether any of it needs an Outpost.

Shujaa.ai is an AWS Advanced Tier Services Partner headquartered in Nairobi, holding the AWS Migration and Modernization Competency and participating in the Well-Architected Partner Program. We design and run connectivity, hybrid and multi-AZ architectures for East African enterprises. See our migration and modernisation services.