VPC Fundamentals
An Amazon Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you launch your resources in a virtual network that you define. Every VPC is associated with a specific AWS Region and spans all Availability Zones within that Region. You choose the IP address range using CIDR notation, typically a /16 block giving you 65,536 addresses to divide across subnets.
When you first create an AWS account, AWS provisions a default VPC in each Region to simplify getting started. For production workloads, you should create custom VPCs with carefully designed CIDR ranges that do not overlap with your on-premises network, as overlapping ranges prevent you from establishing VPN or Direct Connect connectivity later.
A common enterprise VPC layout looks like this:
- VPC CIDR: a /16 range (for example 10.0.0.0/16) gives you 65,536 addresses.
- Subnets: /24 subnets per tier, per Availability Zone, so 9 subnets across 3 AZs for a 3-tier app.
- Public subnets: only load balancers and bastion hosts.
- Private subnets: application servers, databases, internal services.
- Reserve space: leave at least 30% of the CIDR unused for future growth.
Subnets, Route Tables, and Internet Gateways
A subnet is a range of IP addresses within your VPC, scoped to a single Availability Zone. Subnets come in two flavours, and the difference is determined entirely by their route table.
Public subnet
Reaches the internet directly
- •0.0.0.0/0 route → Internet Gateway (IGW)
- •Resources get a public IP if requested
- •Only load balancers and bastion hosts belong here
Private subnet
No direct internet route
- •Outbound traffic routes through a NAT Gateway
- •No inbound from internet possible
- •App servers, databases, internal services live here
Route tables decide where network traffic goes. Each subnet is associated with one. The best-practice design is to keep separate route tables for public and private subnets — never share a single table across both tiers.
Security Groups and Network ACLs
AWS provides two mechanisms for filtering network traffic at the VPC level: Security Groups and Network Access Control Lists (NACLs). They sit at different layers and behave differently, so production designs use both.
| Feature | Security Group | Network ACL |
|---|---|---|
| Applies at | Resource interface (ENI) | Subnet boundary |
| Stateful? | Yes — return traffic auto-allowed | No — return must be explicit |
| Rule types | Allow only | Allow and Deny |
| Rule evaluation | All rules evaluated | Numbered order, first match wins |
| References other SGs? | Yes — reduces IP hardcoding | No — only CIDR ranges |
| Best for | Per-workload access control | Subnet-wide deny rules |
The pattern we recommend: use Security Groups as your day-to-day access control mechanism and reach for NACLs when you need a broad subnet-level deny rule — for example, blocking known-bad IP ranges or temporarily isolating a compromised subnet.
Transit Gateway for Multi-VPC Connectivity
AWS Transit Gateway (TGW) acts as a regional virtual router that connects multiple VPCs, VPN connections, and Direct Connect gateways through a single managed service. Before Transit Gateway, connecting more than a few VPCs required a full mesh of VPC peering connections, which does not support transitive routing and becomes exponentially complex as the number of VPCs grows.
With Transit Gateway, you attach each VPC to the gateway and define route tables that control which attachments can communicate with each other. A common pattern creates separate TGW route tables for production, non-production, and shared-services VPCs, ensuring that development environments cannot reach production databases while still sharing DNS and security tooling from the shared-services VPC.
Transit Gateway also supports inter-region peering, allowing you to build a global network spanning the Cape Town (af-south-1), Ireland (eu-west-1), and Bahrain (me-south-1) regions with consistent routing policies managed from a single configuration.
AWS Direct Connect in East Africa
AWS Direct Connect establishes a dedicated private network connection between your on-premises data centre and AWS, bypassing the public internet entirely. The result: consistent network performance, lower data-transfer costs for high-volume workloads, and the predictable latency that SAP HANA and trading workloads demand.
| Connection type | Speed | Best for |
|---|---|---|
| Dedicated circuit | 1 Gbps or 10 Gbps | High-volume production, SAP, ERP |
| Hosted connection | 50 Mbps to 10 Gbps | Smaller orgs via Direct Connect Partner |
| Site-to-Site VPN | Up to ~1.25 Gbps | Interim solution or failover path |
Direct Connect locations in Nairobi are available through several local carriers and colocation providers including Liquid Telecom and EADC. A common production design pairs a Direct Connect circuit for primary traffic with a Site-to-Site VPN tunnel as an automatic failover path — so connectivity stays up even if the dedicated circuit is disrupted.
AWS PrivateLink and VPC Endpoints
By default, traffic to AWS services like S3 or DynamoDB from an EC2 instance in a private subnet hops through the NAT Gateway and across the public internet. That burns NAT Gateway data-processing costs and exposes traffic to internet routing. VPC Endpoints and AWS PrivateLink route that traffic through the AWS backbone instead — it never leaves AWS infrastructure.
| Endpoint type | Supports | Cost |
|---|---|---|
| Gateway Endpoint | S3, DynamoDB only | Free |
| Interface Endpoint (PrivateLink) | 100+ AWS services and AWS Marketplace partners | Hourly per endpoint + data processed |
For organisations with strict network-isolation requirements, combining VPC Endpoints with S3 bucket policies that deny non-VPC-endpoint access creates a strong control: your data can only be accessed from within your approved VPC — not from any external source, not even from other AWS accounts.
Frequently Asked Questions
Most organisations use at least three VPCs per environment: one for shared services (DNS, Active Directory, logging), one for the application workload, and one for data services. Separating these reduces the blast radius of a security incident and makes network policy enforcement simpler. Use AWS Transit Gateway to connect VPCs rather than VPC peering once you have more than three, as the routing tables become unmanageable at scale.
VPC peering creates a direct, non-transitive connection between two VPCs. Traffic cannot flow from VPC A through VPC B to reach VPC C. Transit Gateway acts as a central hub that connects multiple VPCs and on-premises networks through a single managed gateway. It supports transitive routing and route table segmentation, making it the right choice for organisations with more than three interconnected VPCs.
Yes. AWS Direct Connect is available in Nairobi through several local carriers and colocation providers. A dedicated circuit provides consistent latency and bandwidth that is not subject to internet congestion, which is particularly valuable for SAP, database replication, and other latency-sensitive workloads. Kitsilano Technologies works with approved Direct Connect partners to provision circuits for enterprise customers across East Africa.
AWS PrivateLink enables private connectivity between VPCs, AWS services, and on-premises networks without exposing traffic to the public internet. Use it when you need to access AWS services like S3 or DynamoDB from a private subnet, or when you want to expose your own services to other VPCs or accounts without opening public endpoints. It is the recommended approach for any workload with strict compliance requirements.
