Technology
Get the cloud foundation right before everything depends on it
Accounts, identity, networks and regions are the hardest decisions to change later. We design them on AWS, Azure or Google Cloud, write them as code and move workloads across in stages.
- Duration
- 4 to 12 weeks per stage
- Model
- Staged programme
- Output
- Landing zone as code and decision records
Signs you need this
Most began as sensible shortcuts in the first months.
- Production, staging and experiments share one AWS account, Azure subscription or Google Cloud project, so one mistake or leaked key reaches everything.
- Engineers still use long-lived access keys or owner rights, because single sign-on and role-based access were never finished.
- Address ranges overlap between environments, regions or the office network, and every new connection needs a workaround.
- Part of the estate is in Terraform, part was built by hand, and a plan shows changes nobody can explain.
- Everything runs in one availability zone, or a multi-region design was started without a stated recovery target.
- An auditor asks where personal data, backups and logs are stored, and the answer takes a week.
- There are no budgets, quotas or tagging rules, so a forgotten test cluster is found on the next invoice.
Why rebuilding is not the answer
Cloud estates are rarely designed; they accumulate. The account created for a proof of concept becomes production, networks are added one project at a time and permissions go to whoever needed them that week. Each step was reasonable. Together they make an estate that is hard to secure, audit and change.
The obvious fixes do not help. A security tool on top of a flat account structure reports the problem without fixing it. Rebuilding everything at once stops delivery for months. Going multi-region or multi-cloud for resilience adds a second copy of every problem before the first region is reliable. We fix the foundation in place instead: a landing zone is built next to the current estate, and workloads move onto it in stages.
This is architecture for the estate as a whole: structure, identity, networks, regions and guardrails. The platform your teams deploy through, such as Kubernetes and delivery pipelines, is Cloud and Platform Engineering, and reducing an existing bill is Cloud Cost Optimisation.
What is included, and what is not
Included
- Account, subscription or project structure by environment and team
- Identity and access: single sign-on, roles, break-glass access and removal of long-lived keys
- Network design: address plan, hub and spoke, private connectivity and egress control
- Landing zone and guardrail policies as code, for example with Terraform
- Resilience: multi-AZ by default, multi-region only against a stated recovery target
- Managed service selection and data residency for the UK, the EU and Türkiye
- Cost guardrails: tagging rules, budgets, quotas and alerts
Not included
- Kubernetes clusters and delivery pipelines
- Line-by-line reduction of an existing bill
- Buying or reselling cloud contracts and licences
- Legal opinions on data transfer or residency rules
- Round-the-clock operation of the estate after handover
How the work runs
- Weeks 1 to 2Map the estate. With read-only access to your cloud organisation, networks and billing data, we map accounts, identities, networks and where data lives, and write down recovery targets, residency rules and audit needs.
- Weeks 3 to 4Decide the foundation. Account structure, identity model, address plan, region strategy and guardrails are decided and recorded with their trade-offs, before anything is built.
- Weeks 5 to 12Build it beside what runs. The landing zone is built as code next to the current estate and proven with one real workload. Write access granted for the build is removed when the stage ends.
- Following stagesMove workloads across. Workloads move in groups, each with a rollback plan. The old structure is retired only when nothing depends on it.
- ThroughoutKeep it explainable. Every decision is written down, so an auditor or a new engineer can see why the estate looks as it does.
What you get
All outputs belong to you, including the code and the source files of every diagram.
When this is not the right service
- A single application with a small estate, where one well-configured account with single sign-on and budgets is enough.
- Organisations whose main problem is the size of the current bill. Cloud Cost Optimisation finds savings faster than a redesign.
- Security programmes that need a threat model and control mapping first. That starts with Security and Compliance Architecture.
- Teams that want multi-cloud as a goal in itself rather than an answer to a stated requirement.
Frequently asked questions
Which provider do you recommend?
The one that fits your workloads, skills and residency needs, often the one you already use, with the alternatives written down. Our overviews of AWS, Azure and Google Cloud cover each platform in more detail.
Do we need multi-region?
Usually not at first. Availability zones in one region cover most failures. A second region is justified by a recovery target one region cannot meet, a regulatory requirement or distant users, and it adds a second copy of everything to design, test and run.
Can our data stay in the UK, the EU or Türkiye?
Where the provider offers suitable regions and services, yes, if backups, logs and support tooling stay in scope too; for Türkiye, availability is checked first. Rules such as UK GDPR, the GDPR and KVKK set conditions on transferring personal data abroad, and sector rules, such as BDDK’s information systems regulation for banks in Türkiye, can go further. We design with these requirements in mind and keep evidence easy to produce; the legal reading stays with your advisers.
What happens after the engagement?
Your team owns the code, decision records and runbooks. Some run the remaining migrations alone; others keep an embedded architect 2 to 3 days a week while they do.
Start with a short technical conversation
Thirty minutes. You describe your cloud estate, and we tell you where we would start.