Cloud Engineering
Infrastructure that scales without a midnight page, on the provider that fits your budget.
Before you read: Written from live engineering practice — the money-moving, million-user work our team runs on our own products, set down so anyone building something can learn from it.
01 · What it is
The right cloud setup is invisible: it scales when traffic spikes, it stays up while you sleep, and it bills you sanely. We engineer on AWS, GCP, Azure and Supabase — choosing the provider for the workload and the budget rather than brand loyalty — with serverless and container platforms that auto-scale, backups and regions that cover you, and disaster recovery with SLAs you can actually hold. Cost control and reserved capacity keep the bill predictable, and security groups and network isolation mean infrastructure doesn't become the vulnerability.
What a cloud engineering build covers:
- AWS, GCP, Azure & Supabase chosen by fit and budget
- Serverless & container platforms that scale automatically
- Autoscaling, backups & region redundancy by design
- Cost control & reserved capacity for predictable bills
- Disaster recovery & SLAs you can actually hold
- Security groups & network isolation on every workload
This is how we do Cloud Engineering
Cloud done right is invisible: traffic spikes and the platform absorbs them, a node dies and traffic reroutes, the month ends and the invoice surprises nobody. That invisibility is engineered, and it starts with matching each workload to the platform that fits it rather than the one that impresses. We treat cost as a design output, security groups and identity boundaries as deliberate containment, and recovery as something rehearsed until it is boring. If you never need Kubernetes, we will tell you plainly — and the platform will still behave like a much bigger one.
What we do
- Workloads matched to the right platform — serverless, containers or managed services chosen by fit, behaviour and wallet, with the reasons written down.
- Cost shaped at design time — budgets, tags, right-sizing and spend alerts are planned with the architecture, so the bill scales predictably instead of surprising you.
- Containment by default — private subnets, security groups, least-privilege identity and no-public-unless-justified keep any incident's blast radius small.
- Recovery proven, not promised — backups are restored on a schedule and disaster drills validate the runbook, the RPO and the RTO rather than the snapshot's existence.
- Observability with a human destination — structured logs, metrics, traces and alerts that know which person to reach before a user ever complains.
How we do it
- Right-size from the first commit — we match capacity to real traffic, using autoscaling and scale-to-zero where it fits instead of reserving for imagined peaks.
- Provision everything as code — networks, permissions, databases and policies are declared, versioned and reviewed exactly like product code.
- Enforce least privilege at every boundary — per-service IAM roles, scoped secrets and network rules that are short-lived by design, never a standing all-access key.
- Automate the failure response — health checks, failover, retries and rollback are designed in, so the platform reacts faster than any human can page.
- Keep the invoice transparent — every environment and team is tagged and budgeted, with alerts that fire while spend is still cheap to correct.
02 · The full discipline
The right cloud is invisible. It scales when traffic spikes, stays up while you sleep, and bills sanely.
Cloud infrastructure should fade into the background. When it is done well, teams ship features without thinking about servers; when it is done badly, teams think about nothing else. The difference is engineering for availability, security, cost and recoverability — not just provisioning resources.
We build cloud systems the way a live payments platform has to. Because KodiiPay runs real money across a multi-rail payments layer in production — M-Pesa/Daraja as the home-market lived example, plus PayPal, Stripe, PayStack, cards and bank transfers, our infrastructure must survive peak loads (rent day, payday, month-end), contain blast radius, be recoverable when things fail, and keep bills predictable even as traffic grows. We choose AWS, GCP, Azure or Supabase by fit and budget — not brand loyalty — and we are honest about when you do not need Kubernetes.
Below is how we engineer cloud so it stays invisible, resilient and affordable. From architecture and least-privilege IAM to multi-region, backups tested for restore, cost controls and runbooks — every layer is built so the worst moment is survivable and the monthly invoice has no nasty surprises.
03
Cloud engineering is product engineering
Infrastructure is not separate from the product — it directly affects reliability, security, developer velocity and cost. We design cloud architecture around the workloads that actually run (payments, ledgers, web/mobile APIs, analytics, search), with guardrails that prevent mistakes by default and make recovery boring (not heroic).
- Workload-fit over brand — AWS/GCP/Azure/Supabase chosen by performance, compliance, ecosystem and wallet, with reasons documented.
- Right-sized from day one — scale to match real traffic, not theoretical peaks; prefer serverless/managed where ops burden drops.
- Availability by design — redundancy, health checks, graceful degradation and clear SLAs for critical paths.
- Security by default — least privilege, network isolation, encryption in transit/at rest, no public-by-default unless justified.
- Cost is a design output — budgets, alerts, right-sizing and reservations planned at architecture time, not after the invoice.
- Recoverability rehearsed — backups tested for restoration, RPO/RTO defined, disaster recovery run periodically.
Our lived experience running KodiiPay (payments, wallets, ledgers) means we optimise for correctness and safety first, then cost and velocity — never the reverse.
The toolchain
The cloud engineering toolchain
We favour managed, boring, observable and reproducible tooling — reducing operational toil while keeping blast radius small and costs predictable.
01
Compute & platforms
Run workloads with the right amount of ops
- Serverless (Cloud Functions/Lambda)Event-driven, auto-scale to zero, pay-per-use — ideal for APIs, webhooks, jobs.
- Containers (ECS/Fargate/Cloud Run)Predictable, portable workloads with minimal cluster ops; prefer Fargate/Cloud Run over full K8s unless necessary.
- App hosting (Vercel/Render)Managed web/apps with preview envs, CDN, zero-config deploys where fit.
- Edge (Cloudflare/Workers)Low-latency routing, caching, WAF and edge compute close to Kenya users.
- Supabase/FirebaseBaaS for auth/db/storage/functions when speed-to-market and ops simplicity matter.
- Kubernetes (only when justified)Used only when complex scheduling/multi-tenant or portability demands outweigh ops cost.
02
Storage & databases
Durable, secure, performant
- Managed PostgresRDS/Cloud SQL/Supabase — transactional core with automated backups, PITR, read replicas.
- Object storage (S3/GCS)Encrypted, versioned, lifecycle policies for assets, exports, backups and raw data.
- Redis/MemoryStoreCaching, sessions, rate limits and job queues with high availability.
- Search (OpenSearch/Elastic)Managed clusters with snapshots, scaling and monitoring.
- Backups & PITRAutomated snapshots + point-in-time recovery tested for restore, not just taken.
- CDNCloudFront/Cloudflare for static assets, caching and TLS termination.
03
Networking & security
Isolate, encrypt, least privilege
- VPC/VPC-SCPrivate subnets, NAT, security groups/NACLs, no public DBs by default.
- WAF & DDoS protectionCloudflare/AWS WAF to filter malicious traffic and absorb attacks.
- TLS everywhereHTTPS enforced, certs auto-renewed, HSTS where appropriate.
- IAM/least privilegeRoles per service, short-lived creds, no root keys, access reviews.
- Secrets managerVault/SM/Secret Manager — no secrets in env files or git; rotation where possible.
- Zero-trust principlesService-to-service auth, IP allowlists only where necessary, bastion avoided or tightly controlled.
04
IaC & reproducibility
Infrastructure as code, not click-ops
- Terraform/OpenTofuDeclarative, versioned infra with workspaces/envs and plan/apply reviews.
- PulumiType-safe IaC when preferred in TS/other languages.
- TerragruntDRY module composition across environments/stages.
- GitOps (Flux/Argo)Declarative app delivery for K8s paths; optional when using K8s.
- Environment parityDev/staging/prod as close as possible; feature flags over long-lived branches.
05
Observability
Know before users complain
- Logging (CloudWatch/Loki)Structured JSON logs, retention policies, PII redaction, queryable.
- Metrics (Prometheus/CloudWatch)SLI/SLO dashboards: latency, error rate, saturation, uptime.
- Tracing (OpenTelemetry/Tempo)Trace requests across services to pinpoint latency/failures.
- APMSentry/DataDog/New Relic only where justified by incident reduction vs cost.
- Uptime & synthetic checksExternal uptime probes on critical money paths with alerting.
- Alerting (PagerDuty/OnCall/Slack)Actionable alerts to owners; paging only for user-impacting incidents.
06
Cost control & FinOps
Predictable bills as you grow
- Budgets & alertsMonthly/quarterly budgets per env with alerts at thresholds (e.g. 50/80/90%).
- Cost explorer/analysisPer-service, per-env, per-project spend visibility; anomaly detection on spend.
- Reservations & savings plansCommit strategically for steady workloads; avoid over-committing early.
- Right-sizing & idle cleanupAutoscaling, scheduled shutdowns (non-prod), orphaned resource cleanup.
- Lifecycle policiesArchive cold storage, expire logs/exports per retention to cut storage costs.
- Tagging strategyCost allocation tags (project/env/service/team) enforced in IaC.
07
CI/CD & security tooling
Ship safely, deploy often
- GitHub Actions/GitLab CIPR checks, lint, tests, security scans, plan reviews, automated deploys.
- Security scanningSAST/Dependency (Snyk/Dependabot), container scanning, IaC (Checkov/Terraform fmt/validate).
- Secrets scanningPrevent accidental secret commits; block on detection.
- Blue-green/canary/releasesSafer releases for critical APIs; rollback paths tested.
- DR drillsPeriodic restore-from-backup and disaster recovery rehearsals with documented outcomes.
Lifecycle
Cloud engineering lifecycle
We design for invisibility: choose fit, isolate by default, automate, observe, rehearse recovery and control cost continuously.
01
01 · Requirements & constraints
Map workloads, SLAs, RPO/RTO, compliance, expected scale and budget (KES-aware for Kenya realities).
02
02 · Provider selection
Evaluate AWS/GCP/Azure/Supabase by fit/wallet; document trade-offs and justify choice.
03
03 · Architecture design
Network topology, compute strategy, data/storage, multi-region, CDN, security boundaries.
04
04 · IaC foundation
Terraform/OpenTofu modules, envs (dev/staging/prod), tagging, state strategy and plan reviews.
05
05 · Security baseline
IAM least privilege, VPC isolation, secrets, WAF, TLS, logging, PII redaction.
06
06 · Data & backups
Backups automated + PITR; restore tested, lifecycle policies, encryption at rest/in transit.
07
07 · CI/CD
PR checks, security scans, plan/apply gates, blue-green/canary where needed.
08
08 · Observability
Logs/metrics/traces, uptime checks, SLOs/SLIs, actionable alert routing.
09
09 · Cost controls
Budgets/alerts, tagging, right-sizing, reservations strategy, non-prod schedules.
10
10 · HA & scaling
Autoscaling, health checks, read replicas, multi-AZ/region strategy, graceful degradation.
11
11 · DR & rehearsals
Runbook, restore test, periodic DR drill with documented RPO/RTO validation.
12
12 · Harden & iterate
Cost/perf reviews, access reviews, dependency updates, incident post-mortems feeding improvements.
Closing
More than development
We engineer cloud so it stays invisible — resilient, secure, affordable and recoverable when it matters most:
Good cloud disappears. Everything above exists so your platform stays up, stays safe, stays recoverable and stays affordable — while your team focuses on shipping, not firefighting.
Invisible infrastructure. Predictable bills. Survivable when it matters most.
Previous capability
Search Systems
Next capability
DevOps & CI/CD
Building something like this?
The discipline above is what we run on our own products every day. If it would help on yours, our door is open.