Platform

Cloud and infrastructure architecture

The platform underneath your product decides how bad your worst day is. We design and build it so that a compromise stays where it started, and so that the person on call can understand the system at three in the morning.

What this covers

The work itself.

Architecture and migration

Target-state design and a migration path that doesn't require a weekend of downtime and a rollback nobody has tested. Cloud-to-cloud, on-prem to cloud, and the increasingly common move back the other way.

Network segmentation and trust boundaries

Zones that mean something, with the traffic between them actually enforced rather than assumed. Identity boundaries designed alongside network ones, because a flat IAM model undoes a well-segmented network.

Infrastructure as code

Terraform or equivalent, structured so it's reviewable and so that state and privilege are handled deliberately. Includes untangling estates that were click-configured first and imported later.

Hardening and baseline review

Comparing what's running against a defensible baseline, then closing the gap in priority order. Includes the parts people skip: egress control, logging that would survive an incident, and backups someone has actually restored from.

How it runs

Engagement shape.

01

Discovery

We map what exists — accounts, networks, identity, data paths — and where the real dependencies are, which is rarely where the diagram says.

02

Design

Target architecture with the trade-offs written down. You get the reasoning, so the next person can tell which decisions were deliberate.

03

Build

Implemented as code, in increments that can each be reverted, rather than a big-bang cutover.

04

Handover

Architecture documentation, runbooks and the decision record. Your team should be able to extend it without calling us.

What you get

Deliverables.

Current-state map: accounts, network, identity, data flows
Target architecture with documented trade-offs
Terraform modules or equivalent, in your repositories
Segmentation and egress policy
Hardening gap analysis against a stated baseline
Runbooks, decision record and handover session

Context

Where this comes up.

We work across Azure, AWS and GCP, and — more often than the industry likes to admit — hybrid and self-hosted estates that are not going anywhere. Kubernetes both ways: managed on AKS, and fully self-hosted on VMware ESXi where sovereignty or procurement rules mean public cloud was never an option. Cost pressure and data-residency rules have made repatriation a real conversation again, and it needs the same rigour as the original migration did.

Data residency shapes a lot of EU work: keeping regulated workloads in-region, and being able to demonstrate it. For US engagements the constraint is more often audit scope — drawing boundaries so that the systems in scope for SOC 2 or HIPAA are a small, defensible subset rather than the whole estate.

Depth

Below the console.

Infrastructure consulting is a crowded field and most of it stops at the console. The background here runs lower: close to a decade of professional offensive security before the platform work, including reverse engineering, fuzzing and exploit development, 0-day discovery in commercial enterprise software, and network security architecture built on Cisco, Palo Alto, CheckPoint and ForeScout rather than on a managed service that hides them.

That matters when the problem is not in the documentation — when throughput collapses under one specific traffic pattern, when the managed abstraction is quietly lying about what the network is doing, or when the honest answer to "is this segmentation real?" requires someone who has spent years getting through segmentation for a living.

It also shapes the designs themselves. Threat modelling done by someone who has attacked comparable systems produces a different set of questions than threat modelling done from a framework document.

Common questions

Before you ask.

Which cloud providers do you work with?

AWS, Azure and GCP most often, plus hybrid and fully self-hosted infrastructure. We're not a reseller for any of them, which means we've no incentive to tell you the answer is more cloud.

Can you help us move off a cloud provider?

Yes, and it's a growing share of the work. The analysis is the same in both directions: what the workload actually needs, what the total cost really is, and what the migration risk looks like.

Do you do the implementation or just the design?

Both, and we prefer both — a design nobody implements teaches us nothing about whether it was right. If your team wants to build it themselves we'll review as they go.

What if our infrastructure was never managed as code?

That's the normal starting point. Importing a click-configured estate into Terraform is tedious rather than hard, and it's usually the highest-value thing we can do early because everything after it gets cheaper.