Cloud Consulting and Infrastructure Design in Kenya
CloudSpinx does cloud infrastructure design, migration and managed cloud on AWS, Azure and Google Cloud for businesses in Kenya and across East Africa, with everything provisioned as code so you can read, audit and take over what we built. Design work is quoted as a fixed piece, migration per engagement, and running it afterwards as a monthly figure. Where the honest answer is that a workload should stay on your own hardware, we say so before you sign.
Who we build for
- 14organizations, from ISPs and payment platforms to a national regulator
- 6flagship engagements published in full, with the numbers counted
- 4thof all contributors to the open-source payment switch national systems run on
Everything in Our Cloud Consulting Service
Every engagement covers the full scope: no hidden extras, no upselling.
Cloud infrastructure design
The architecture before the build: account and network topology, identity, availability targets, storage and backup shape, and a costed target you can take to a board. Sold as a fixed piece of work whether or not we build it.
Landing zone and account structure
Separate accounts, subscriptions or projects for production, non-production and shared services, with a network hub, centralized logging and guardrails set before the first workload lands rather than untangled after.
Cloud migration
Assessment, target architecture, dependency mapping and a staged cutover with a rollback point at every wave. Lift-and-shift, re-platform or refactor, chosen per workload rather than as a policy.
Infrastructure as code
Every resource provisioned with Terraform or OpenTofu, in your repository, peer-reviewed and reproducible. No click-ops, and no environment that exists only in one engineer's memory.
Cost engineering
Right-sizing against measured utilization, committed-use and reserved purchases where the term fits, idle and orphaned resource cleanup, storage tiering, and budget alerts before the invoice.
Kubernetes and containers
EKS, AKS and GKE, or self-managed where that fits better. Node sizing, autoscaling, ingress, secrets management and the honest advice on whether you need Kubernetes at all.
GitOps delivery
Argo CD pipelines with drift detection, Helm chart management, and deployments that are auditable and revertible rather than a person with production credentials.
Cloud security and IAM
Least-privilege roles, no long-lived keys, encryption at rest and in transit, network segmentation, and logging that satisfies an auditor rather than a dashboard.
Hybrid and multi-cloud
Site-to-site connectivity, consistent identity, and unified monitoring where workloads genuinely have to span your building and a provider. Built only when there is a real reason.
Monitoring and on-call
Prometheus and Grafana or the provider's native stack, alerts that route to a person, and dashboards showing capacity and spend rather than decoration.
Backup and recovery
Cross-region or cross-account copies, retention matched to what the business can actually lose, and a restore rehearsal on the calendar. Snapshots in the same account are not a backup.
Disaster recovery design
A recovery target agreed with the business first, then the cheapest shape that meets it: backup and restore, pilot light, or a warm standby in a second region. Written up as a runbook a tired person can follow at 03:00.
Technologies we use
What a cloud design actually looks like
Three of the drawings that come out of a design engagement: the landing zone every workload lands in, the shape of a migration that can be reversed, and the three lawful places your data can sit when the provider has no region in this country. Account naming, address plan and sizing come out of your workloads.
The landing zone: account structure, identity and network hub
The part almost nobody builds first, and the part that is expensive to retrofit. Separate accounts give you a blast radius, a readable bill and somewhere to put a guardrail. Doing this after two years of production means moving live workloads between accounts, which is a project rather than an afternoon.
- Inherited policy and billing
- Routed network paths
- Link back to your own premises
A cloud migration you can reverse, wave by wave
Nothing gets deleted while the way back is still needed. The old environment stays standing through every wave and past the last one, which costs you a few weeks of double running and buys you the only rollback that actually works. The shape below is an example: your wave count comes out of the dependency map, not out of a template.
Where Kenyan data is allowed to live, and what each shape costs
The honest figure. There is no AWS, Azure or Google Cloud region in this country, so every public cloud design here is a cross-border transfer with a paper trail attached. That is usually fine. When it is not, the alternatives are real rather than a consolation, and each one hands you a different problem to own.
Which of these do you actually need?
No card is marked as the recommended one, because there is no answer that survives contact with your workloads. What the design phase does is work out which row you are in, and it is worth saying that a meaningful number of the businesses who call us belong in the last one.
One provider, everything on it
Right when your load varies, when you are building something new, or when the team you have is small and would rather write software than replace disks.
Costs you: a documented transfer basis for personal data, and an egress bill that only shows up at production volume.
Regulated data stays, the rest moves
The usual answer in financial services, health and public sector work, where one dataset carries conditions and the other ninety percent of the estate carries none.
Costs you: two platforms to run and a link between them that has just become production infrastructure.
Your own hardware, run properly
For a hard residency requirement, or a steady workload big enough that renting it costs more than owning it. Built on OpenStack or Proxmox rather than a pile of servers.
Costs you: capital up front, capacity planning as a real job, and someone who answers the phone at 02:00.
Stay where you are for now
If the estate is stable, the workload never scales and the actual problem is that backups are untested, moving it to rented compute solves nothing and costs more.
Costs you: nothing, which is the point. Fix the backups, then have this conversation again in a year.
These are shapes, not build sheets. Instance families, address plans, storage classes and the recovery targets that drive all three come out of your workloads during design, and that is the first piece of work rather than a free extra attached to a migration.
What cloud actually costs, and where the money goes
Cloud pricing is public, which makes this the one area where you can check the arithmetic yourself. That is also why so many Kenyan cloud bills are wrong: the list price is transparent, and the waste is not. What we find on almost every account we inherit is the same handful of items, and none of them are exotic.
What we quote on
Migration is priced per engagement: workload count, how tangled the dependencies are, data volume against the bandwidth you have, and how much refactoring you want against a straight move. Ongoing management is a monthly figure driven by the number of environments, whether you need out-of-hours cover, and whether we run the platform or support your team running it. We do not take a percentage of your cloud spend, because a provider paid more when your bill grows should not be the one advising you on cost.
- Instances sized from a guess. Someone picked a shape at launch and nothing has been measured since. Right-sizing against real utilization is the largest single line, every time.
- Non-production running at night and at weekends. Development and staging environments left on for the two thirds of the week nobody is using them.
- Orphaned storage. Unattached volumes, old snapshots with no lifecycle policy, and load balancers pointing at nothing.
- On-demand where the workload never stops. A steady baseline running at on-demand rates while committed-use and reserved pricing sits unused.
- Egress nobody modeled. Data transfer out is the charge that surprises Kenyan businesses most, because it does not show up in a pilot and does show up at production volume.
Cloud infrastructure design, before anything gets built
Most of the cloud estates we are asked to fix were never designed. Someone needed a server, opened a console, and a year later everything lives in one account, several people hold administrative keys, and nobody can explain the bill by line. Design is the cheapest hour in an engagement because it is the only point where changing your mind is free. We sell it as a fixed piece of work on its own, and you are welcome to have somebody else do the building.
Design without the build
Plenty of clients take the design and hand it to their own team, or to whoever already holds the contract. We price it that way on purpose. A design that only works if we are the ones building it is a sales document, and you can usually tell which one you have been given by page ten. Everything we produce is written to be executed by any competent engineer, the same reason our advisory work ends in artifacts rather than in a retainer.
The design is where we tell you not to buy
Design is also the stage where a workload gets sent back. A steady database that has run at the same size for years, a system whose vendor will not support it off-premises, an application whose egress would cost more than its hosting: these surface when someone models the target properly, and they are much cheaper to find on paper than in a cutover window. Roughly the ones listed further down under when we tell clients not to move, and we would rather lose the migration than sell you one that makes your position worse.
- Account and network topology. How production is separated from everything else, what the address plan is, where the boundary sits, and how your office and any remaining on-premises kit reach it.
- Identity and access. Who can do what, through which roles, with no long-lived keys, and a leaver process that takes minutes instead of somebody remembering every system that person touched.
- Recovery targets agreed with the business, in numbers. How long you can be down and how much data you can lose, signed off before an architecture is picked rather than discovered during the first outage.
- The costed target. A modeled monthly run rate at your real volumes, with the assumptions written next to it so your finance team can argue with them.
- The build plan. What gets created in what order, expressed as Terraform or OpenTofu module boundaries rather than as a slide.
Migration without pretending there is no risk
We plan a staged cutover with a rollback point at every wave, and the old environment stays standing until the new one has been through a full business cycle. Most workloads move in a short window while the final data sync completes. Some do not: a large transactional database, a system with a license pinned to hardware, or an application whose vendor will not support it off-premises will need a planned window agreed with the business, and we tell you which of your systems those are during assessment rather than on the night.
The dependency nobody documented
Migrations slip on discovery, not on engineering. The scheduled task on someone's desktop that produces the month-end file. The hard-coded IP address in an integration. The certificate that expires during the cutover weekend. The vendor who needs six weeks' notice to re-point a payment integration. We spend real time on this before quoting because a migration plan built on an incomplete inventory is a plan to discover things at 02:00.
Bandwidth is the Kenyan constraint
Moving several terabytes over a shared office link is measured in weeks and will make the office unusable while it happens. The fix is normally incremental sync over a period, a dedicated circuit for the transfer, or physical media, and the choice depends on how much data you have and how much of it changes daily. This gets modeled during assessment, because it is the item most likely to move the timeline. Where the link itself is the constraint, the connectivity work comes first.
Where your data is allowed to live
None of the three major providers runs a region in Kenya. The nearest are Cape Town and Johannesburg, then Europe and the Middle East (AWS and Google both publish the current list), so a workload serving Nairobi users answers from one of those. For most businesses that is fine and the latency is unremarkable. Build for the regions that exist rather than the one that was announced: the Microsoft and G42 campus at Olkaria was to carry an Azure East Africa region and has stalled over grid capacity and government offtake guarantees. It stops being fine when a regulator, a client contract or the Data Protection Act attaches conditions to where personal data sits and how it crosses a border. Financial services, health data and public-sector work are the usual cases. When that applies, the honest architecture is often a private cloud on hardware in a Nairobi facility, or a hybrid where the regulated data stays local and everything else does not. We build both, and a private cloud on OpenStack is a genuine option rather than a consolation prize.
Everything as code, and why it matters to you commercially
Every resource we provision is defined in Terraform or OpenTofu, held in your repository, and reviewed before it applies. The technical arguments are the usual ones: reproducible environments, no configuration drift, a diff before every change. The commercial argument is the one that should matter more to you. Infrastructure defined in code is infrastructure another firm can take over. If we disappear tomorrow, you hand the repository to anyone competent and they can read exactly what exists and why. A cloud estate that was clicked together by hand is a hostage situation with an invoice attached, and it is the single most common form of lock-in we are asked to unpick.
When we tell clients not to move to the cloud
Cloud is a good default and it is not a universal answer. These are the cases where we have advised against it and would again.
- A steady, predictable workload that never scales. A database that runs at the same size every day for five years is cheaper on hardware you own, often substantially. Cloud pricing rewards elasticity, and if you have none you are paying for an option you never exercise.
- Heavy egress. If your product pushes large volumes of data out to users, data transfer charges can dominate everything else. Model it honestly at production volume before committing.
- A hard residency requirement with no local region. If the data legally cannot leave Kenya, the answer is local hardware or a local facility, not a creative reading of the rules.
- A lift-and-shift with no other change. Moving an unmodified estate to rented compute usually costs more per month than the servers did, and it buys you nothing except somebody else's hardware failures. Either re-platform enough to use what the cloud is good at, or stay where you are.
- No one to own it. Cloud shifts work from racking to engineering. If nobody will own cost governance and access management, the bill and the attack surface both grow quietly. Either resource it, or let someone manage it for you.
What you own at handover
The Terraform or OpenTofu repository with its state, in your source control. The architecture diagrams, the runbooks, the monitoring and alerting configuration, and the cost baseline with the assumptions written down. Accounts, subscriptions and projects are created under your organization with your billing relationship, never resold through ours, so you keep the direct provider relationship and any credits or discounts attached to it. Whether we then manage it or your team does is a decision you get to make again every year.
Tell us what you are running today
Enough for a readiness view and a real figure rather than a range. Every field has an escape hatch, so answer what you know and leave the rest to the assessment.
Ready to discuss Cloud Consulting?
A 30-minute scoping call, free, and it commits you to nothing.
How Every Cloud Consulting Engagement Starts
Readiness assessment
Workload inventory, dependency mapping, data volumes against your actual bandwidth, residency constraints and a cost model for the target. This is the free part, and it frequently changes the plan.
Design and cost it
Target architecture, network and identity design, the migration wave plan with rollback points, and one figure for the work plus a modeled monthly run rate.
Build and migrate
Landing zone built as code, workloads moved in waves, each wave verified before the next, and the old environment kept standing until a full business cycle has passed.
Optimize and hand over
Right-sizing against real post-migration data, commitment purchases once usage is proven, documentation and training, then either your team runs it or we do.