Multi-Cloud Consulting
One governance model for every cloud you run
We design the foundation your workloads land in: account or subscription hierarchy, policy, network, identity and cost controls, defined in Terraform. The same governance model applies on AWS, Azure, Google Cloud and on-premises, and your platform team owns the code.
Services
What this practice covers
Each service has its own page: the problems it addresses, what we set up, what you keep and how the work runs.
AWS foundations and governance
A multi-account AWS organisation with OUs, service control policies and account vending in Terraform, so new workloads start governed.
Azure landing zones
Azure landing zones in Terraform: management groups, policy at scale and a hub-and-spoke network that every subscription inherits.
Google Cloud foundations
A Google Cloud hierarchy with folders, organisation policies and Shared VPC, plus Google Kubernetes Engine clusters your pipeline deploys to.
On-premises and hybrid cloud
Private connectivity, one identity boundary and shared governance between your data centres and the cloud, with each side kept operable.
What you keep
What your team keeps when the work ends
Code, pipelines, runbooks and decision records that outlast the engagement, held in your repositories and owned by your team.
Governance model and resource hierarchy
The management group, organisational unit or folder structure, who owns each level, and the policy set assigned there. Every new workload inherits it instead of negotiating its own.
Network topology and connectivity
Hub-and-spoke or shared network design, the address plan, private connectivity to your data centres and egress control, written down so a new workload has one supported way to attach.
Identity boundaries and policy as code
Identity boundaries, privileged access and preventive guardrails written as policy code, reviewed in merge requests like any other change, and agreed while the design is still open.
Cost allocation, budgets and tagging
Budgets and alerts per workload, with naming and tagging conventions enforced by policy, so every line of the bill traces back to an owner and a cost centre.
Recovery design and continuity runbooks
Recovery objectives agreed with the business for each workload tier, designed into the topology, with runbooks your operations team rehearses rather than a document nobody has tried.
Terraform modules and the deployment pipeline
Reusable Terraform modules for the foundation, and the pipeline that plans, reviews and applies them, so every change to the landing zone is reproducible and leaves an audit trail.
How we work
How the work is sequenced
Short phases, each closed by a review your team signs off, so priorities can change between phases without reopening finished work.
01
Map the estate and its obligations
We review the accounts, subscriptions and projects you already run, the regulatory and audit obligations they sit under, and the workloads the foundation must carry next. Existing tooling stays unless it blocks the design.
02
Design the governance model
Hierarchy, policy, network and identity are designed together, because each decision constrains the others. Every choice, and the options set aside, goes into a decision record your architects review and sign off.
03
Build the foundation in Terraform
Your engineers work beside ours on the modules, the pipeline and the policy set. Each change produces a Terraform plan posted to the merge request, so review happens before anything reaches the cloud.
04
Land the first workloads
One or two real workloads move in first, to test the network, access and cost model in use. Whatever they expose is fixed in the modules, not worked around inside the workload.
05
Hand over and step back
Your platform team takes over the modules, pipeline, runbooks and decision records, and extends the foundation for the next workload. We stay available to review their changes while the reasoning stays written down.
Technology we work in
Technology we work in
Cloud & Platform
Run in production
- Azure
- Google Cloud
- Terraform
- Azure DevOps
Offered, not in published work
- AWS
DevSecOps
Run in production
- Google Cloud
- Terraform
Published work
Write-ups from this practice
Engagements documented in full, with architecture figures and the stack as delivered.
A governed Azure foundation a bank could build on
We designed and built an Azure landing zone for a bank: governance, hub-and-spoke networking, security policy and Terraform-delivered infrastructure.
We delivered a scalable, secure and efficient Azure landing zone that accelerated the bank's cloud adoption. Application teams deploy into subscriptions that already carry networking, policy, monitoring and backup, which…
- Azure
- Terraform
- Azure DevOps
Omnichannel banking on Microsoft Azure, private by default
An omnichannel banking platform on Azure: one controlled edge for every channel, workloads on AKS, and data services reached only through private endpoints.
We delivered a scalable, secure and efficient application architecture on Microsoft Azure. Every channel enters through one controlled edge and every data service is reachable only through a private endpoint,…
- Azure
- AKS
- Front Door
- Keycloak
Next step
Plan a foundation for the clouds you run
Tell us which platforms you run and what the next workload needs. We will come back with where to start, and what your team would own.