Kubernetes at Scale for African Government Workloads

Running production Kubernetes for a government client in West Africa is a different exercise from running it for a fintech startup in London. The infrastructure constraints are different. The compliance requirements are different. The failure modes are different. This is a technical account of what we built, why we built it that way, and what we would change.

The Architecture Decision: EKS Auto Mode

We chose Amazon EKS with Auto Mode for our government platform deployment. Auto Mode abstracts node provisioning using Karpenter under the hood, which means we do not manage EC2 instances directly — the cluster scales worker nodes in response to pending pod demand. For a government workload with highly variable traffic patterns (large spikes around legislative events, quiet periods in between), this was the right call.

We provisioned two custom NodePools: one for general application workloads, and one for our translation service, which requires dedicated CPU resources and has a different scaling profile. The translation NodePool has a NoSchedule taint that requires explicit toleration — this prevents general application pods from landing on translation nodes and degrading throughput.

Multi-AZ and the NAT Problem

We initially deployed with a single NAT gateway in staging to reduce cost. This was fine until we discovered that inter-AZ data transfer charges were significant for our use case, which involves frequent cross-service communication. In production, we moved to multi-AZ NAT — one gateway per availability zone — which also improved resilience.

The lesson: do not optimise NAT topology based on staging traffic patterns. Government production workloads have different communication profiles than you would expect from your staging environment.

Secrets and Compliance

Government clients in Nigeria have emerging data sovereignty requirements that influenced several architectural decisions. We encrypt all secrets at rest using KMS with customer-managed keys, use IRSA (IAM Roles for Service Accounts) to avoid storing AWS credentials in pod environments, and maintain comprehensive audit logs of all secrets access through CloudTrail.

Parameter Store is our primary mechanism for application configuration — it provides a clean separation between infrastructure and application config, with IAM-controlled access at the path level.

Observability in Constrained Environments

When your operations team is in Lagos and your infrastructure is in AWS us-east-2, observability is not optional. We run CloudWatch for infrastructure metrics and logs, with alert routing to PagerDuty. We built custom dashboards for the metrics that matter most in our deployment context: translation job queue depth, API p95 latency, and cross-AZ traffic costs.

The monitoring setup we have today took three iterations to get right. We started with too many alerts (alert fatigue), moved to too few (missed a degraded translation service for six hours once), and arrived at a tiered severity model that pages humans only for issues requiring immediate human judgment.

What We Open-Sourced

Our Kubernetes manifests for the translation service NodePool configuration, the IRSA setup scripts, and the CloudWatch dashboard templates are available in our public GitHub organisation. We believe the African tech ecosystem benefits when government-facing infrastructure patterns are shared openly.