Identity comes first
In the cloud, a stolen credential does more damage than an open port. I design identity, roles and guardrails before the first network.
Cloud
The foundations cloud workloads sit on
I design landing zones, hybrid connectivity, resilience and automation across AWS, Azure and Google Cloud. This page shows how those pieces fit together and the decisions I make along the way.
Overview
Who looks after which layer
Every cloud decision I make starts with the shared responsibility model. The provider takes over more layers as you move from infrastructure as a service (IaaS) to platform as a service (PaaS) and software as a service (SaaS), but some layers always stay with the customer.
Swipe sideways to see the whole diagram.
On premises. The customer owns every layer, from the building and the power to the data. Full control and full responsibility, including every hardware refresh.
Infrastructure as a service. The provider runs the facilities, physical network, storage and hypervisor. The customer still owns the operating system, patching, network design and firewall rules, and everything above them.
Platform as a service. The provider also runs the operating system and the runtime. The customer focuses on the application, its data and who can reach it.
Software as a service. The customer only owns the data and identity: who has access, how it is protected and how it is governed. Those two never move to the provider.
Foundations before workloads
Accounts, addressing, connectivity, logging and policy go in first. Retrofitting them after teams have built on top costs far more.
Cost is part of the design
Data transfer, idle capacity and duplicated services add up quietly. I treat cost like resilience: designed in, measured and reviewed.
Placement
Where each workload should live
Cloud is a placement decision, made one workload at a time. I weigh five things: latency and where the data sits, recovery needs, the cost model, regulation, and what the teams can run. Most estates end up hybrid, and the boundary between the two is designed, not left to chance. Pick a workload to see how it lands.
Swipe sideways to see the whole diagram.
Trading engine: on premises. Every microsecond to the exchange counts, the load is steady all day, and the regulator expects tight control, including clocks traceable to UTC (Coordinated Universal Time). A colocated data centre wins on latency and on cost at that steady load.
Customer website: public cloud. Users are everywhere and demand jumps during sales. Managed services, edge caching and paying for peaks only make the cloud the natural home.
Plant analytics: hybrid. Data is made at the plant in large volumes and control must stay local, so collection and first processing run at the edge. Training and group dashboards run in the cloud, fed outbound through the DMZ (demilitarised zone).
Disaster recovery: public cloud. Data replicates continuously, but servers are built by code only when needed, a pilot light. The organisation pays for full capacity only on the day, and tests it at least once a year.
Why not everything in public cloud
Regulation and data residency, the cost of steady heavy loads, latency to people or machines, and concentration risk. UK financial firms also have to manage reliance on a few providers, which is why the UK now has a critical third parties regime.
Cloud patterns on premises
I borrow the hyperscalers' ideas for private data centres: a data hall acts like an availability zone, a pod like a cell, and a pair of data centres like a region. Blast radius stays small, and running workloads carry on even if management tools fail.
The building blocks
How each provider names and builds networks, security groups, gateways and load balancers is on the AWS, Azure and Google Cloud page.
Landing zones
A landing zone, layer by layer
A landing zone is the ready made structure that every workload lands in. I build it in a fixed order, because each layer depends on the one before.
Swipe sideways to see the whole diagram.
I start with the account structure, not the network. Separate accounts, subscriptions or projects for security, networking, production and non production give clean boundaries for access, billing and blast radius.
One identity source with single sign on (SSO), roles and multi factor authentication (MFA) reaches every account. Access is granted to roles, not individuals, and nobody works with long lived keys.
A transit hub joins the workload networks and on premises: AWS Transit Gateway, Azure Virtual WAN or a hub virtual network (VNet), or Google Cloud Network Connectivity Center (NCC). Each spoke often uses a shared VPC (virtual private cloud). I plan addressing across every cloud and site up front, because overlapping ranges are expensive to fix once workloads are live.
Traffic between spokes, and to and from on premises, passes a firewall in the hub. One policy point and one set of logs, while the spokes stay simple.
Every account sends audit logs, flow logs and configuration history to a protected logging account that workload teams cannot change or delete.
Guardrails block bad configuration before it is deployed: service control policies, Azure Policy or organisation policies, written as code and reviewed like any other change.
Hybrid connectivity
Four ways in, chosen on purpose
How sites reach the cloud decides performance, resilience and cost. I choose the pattern per workload, and production almost always gets more than one path.
Swipe sideways to see the whole diagram.
Site to site VPN (virtual private network). IPsec (IP security) tunnels over the internet. Quick to set up and fine for small or temporary needs, but performance follows the internet and throughput per tunnel is limited.
Private connection. AWS Direct Connect, Azure ExpressRoute or Google Cloud Interconnect gives a dedicated, predictable path with private BGP (Border Gateway Protocol) peering. On its own, though, one connection in one location is a single point of failure.
Resilient pair. Two private connections in two separate locations, ideally from diverse carriers, with BGP steering traffic and a VPN as the last resort. This is my default for production workloads.
SD-WAN on ramp. A virtual SD-WAN edge in the region lets branches reach cloud workloads directly over the fabric, with the same segmentation and application policy as every other site. More on the SD-WAN page.
One border for every connection
WAN, internet and cloud connections all land in one controlled place, a border or edge pod, never in a compute pod. WAN links use VRF (virtual routing and forwarding) lite per zone, the internet has two providers, and cloud private connections arrive in pairs.
Routing between cloud and site
Private connections use BGP. I set local preference and AS (autonomous system) path prepending so both directions use the same path, and filter what each side may advertise, so a mistake in the cloud cannot pull traffic away from a site.
Branches straight to the cloud
With an SD-WAN on ramp, branches reach cloud workloads over the fabric. The same segments and policies apply, and the data centre stops carrying traffic it does not need to see.
Resilience
Recovery matched to what it costs
Every service needs a recovery time and a recovery point, and every option has a price. Pick a pattern, then take region A offline and watch how quickly the service comes back.
Swipe sideways to see the whole diagram.
- Recovery time
- Hours
- Data loss
- Hours
- Relative cost
- £
- Suits
- Internal tools that can wait
- Recovery time
- Tens of minutes
- Data loss
- Seconds to minutes
- Relative cost
- ££
- Suits
- Important systems that can be down for up to an hour
- Recovery time
- Minutes
- Data loss
- Seconds to minutes
- Relative cost
- £££
- Suits
- Customer facing services
- Recovery time
- Near zero
- Data loss
- Near zero
- Relative cost
- ££££
- Suits
- Services where any outage costs real money
Region A is serving users.
These are typical ranges. The right pattern comes from each service's agreed recovery objectives, and it is only real once it has been tested.
Active and active data centres
Both sites serve live traffic. Global load balancing answers DNS with health checks and short time to live values, and anycast suits stateless services such as DNS resolvers. Data is the hard part: either one writer with synchronous copies within a metro area, or asynchronous copies further away.
Beyond one metro area
Past about 100 km, or about 5 ms round trip, synchronous replication usually slows writes too much, so replication becomes asynchronous. Some data loss is then possible and must be agreed. Regions are joined at Layer 3 only, never by stretching a Layer 2 network.
Each region stands alone
Every region has its own management, DNS, identity and time services, so it keeps running if the link to the rest of the estate fails. Circular dependencies, such as DNS needing a server that needs DNS, are found and broken before go live.
Automation
Changes that go through the pipeline
I treat cloud and network configuration as code. Every change follows the same path, so it is visible, reviewed and repeatable, and the console stays read only for day to day work.
Swipe sideways to see the whole diagram.
Every change starts as code in Git: accounts, networks, policies and firewall rules. The repository is the source of truth, not the console.
Terraform shows exactly what will be created, changed or destroyed before anything happens. The plan goes with the change record.
Automated checks block risky changes, such as public storage, wide open security groups or overlapping address ranges, before a person even looks.
A peer reviews the code and the plan. Small, frequent changes are easier to review and easier to roll back than big ones.
The pipeline applies the change to AWS, Azure or Google Cloud with its own service identity, not a person's credentials. Ansible handles configuration on network devices and servers.
A scheduled check compares what is running with what is in code. Any difference becomes a new change through the same pipeline, never a quiet fix in the console.
Multi cloud
Same pattern, different names
The three big clouds offer the same building blocks under different names. I design to the pattern first, then map it to each provider.
| Building block | AWS | Azure | Google Cloud |
|---|---|---|---|
| Network hub | Transit Gateway | Virtual WAN or hub VNet | Shared VPC and Network Connectivity Center |
| Private connection | Direct Connect | ExpressRoute | Cloud Interconnect |
| Internet VPN | AWS Site-to-Site VPN | VPN Gateway | Cloud VPN |
| Identity | IAM Identity Center | Microsoft Entra ID | Cloud Identity and IAM |
| Private DNS | Route 53 Resolver | Azure DNS Private Resolver | Cloud DNS |
| Inspection | Network Firewall or partner firewalls | Azure Firewall or partner firewalls | Cloud NGFW or partner firewalls |
| Guardrails | Service control policies | Azure Policy | Organisation policies |
| Infrastructure as code | Terraform across all three, so one way of working covers every provider | ||
When multi cloud is worth it
- Only with a clear reason. A specific service, a regulator, an acquisition or a customer need. Spreading by default doubles the work.
- Standardise the edges. One identity source, one way of writing infrastructure as code, one network pattern and one logging approach.
- Mind the data. Moving data between clouds costs money and time. Keep processing close to where the data lives.
- Regions before clouds. Most resilience needs are met by two regions of one provider. A second cloud is rarely the cheapest way to get it.
- Plan addressing once. Non overlapping address ranges across every cloud and site keep future connections simple.
- Use what each does best. Designs that use only what all three clouds share give up the managed services that make each one worth using.
Engagement
How I run a cloud programme, from placement to migration waves
This is the programme view: which workloads move, where they land, in what order and at what cost. The building blocks of each provider, and how packets flow through them, are on the AWS, Azure and Google Cloud page.
Swipe sideways to see the whole diagram.
I start with the reason for moving: speed, cost, resilience, exiting a data centre or a specific service. I agree the measures of success, the principles, such as which providers and regions, and who decides what.
Functional requirements cover what each workload needs from the platform. Non functional ones set recovery point and recovery time objectives, availability, latency to users and sites, data residency, and the cost each workload may carry.
I gather what really runs today with discovery tools rather than old spreadsheets and memory: servers, sizes and use, and above all the dependencies between them. Applications that talk constantly move together, in the same wave.
Each workload gets a placement and a migration pattern: rehost, replatform, refactor, replace, retain or retire. Workloads that talk constantly are grouped into the same wave, and the landing zone and hybrid patterns are chosen to suit them.
A pilot workload proves the path. Migration waves follow, each with a cutover plan, a rollback point and a go or no go decision. After each wave I compare performance and cost with the baseline, and retire what was left behind.
Every wave gets a short hypercare period with the application team. I track performance and cost against the forecast, agree who supports each layer, and feed what we learn into the plan for the next wave.
After the move, sizes and commitments are adjusted to real use, and rehosted workloads join a modernisation backlog. Placement is reviewed when costs, regulation or the business change, and exit plans stay current for critical services.
Functional requirements
What it must do.
- Give every workload a home in a governed account or subscription, built from a standard landing zone.
- Connect sites and data centres to the cloud over resilient private links, with a VPN as backup.
- Inspect traffic between zones, to the internet and to on premises, through a central hub.
- Resolve names both ways between cloud and on premises with private DNS.
- Use one identity source with single sign on and multi factor authentication.
- Recover each critical workload in a second zone or region, as its tier requires.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Availability
- Production across at least two availability zones, and 99.95% or better for critical services.
- Recovery
- Recovery point and recovery time objectives (RPO and RTO) agreed per tier, for example under 15 minutes and under 4 hours for tier one.
- Latency
- Round trip from main sites to the region within an agreed limit, such as under 20 ms in the UK.
- Security
- Guardrails enforced by policy, logs kept centrally, and no public endpoints without review.
- Data
- Data stays in agreed regions, encrypted at rest and in transit.
- Cost
- A budget and alerts for every account, and monthly review of waste and commitments.
- Operability
- Every change through the pipeline, with drift detected and reported.
Typical starting targets. Each workload's tier sets its real numbers, and each one is checked again after its wave.
Who I talk to
- Application owners and product teams
- Infrastructure, network and security teams
- Data protection and compliance
- Finance and procurement, for contracts and licences
- Current hosting and managed service providers
How I find out
- Workshops with each application owner
- Automated discovery of servers, usage and dependencies
- Network flow analysis between applications
- Licence and contract review, including software that cannot move
- Readiness scoring, then grouping into move waves
Discovery tools
| Tool or source | What it tells me |
|---|---|
| Azure Migrate | Server inventory, performance based sizing, dependencies and cost estimates for Azure. |
| AWS Transform, fed by Application Discovery Service data | Server inventory, dependencies, sizing and wave plans for AWS. It replaced Migration Hub for new customers in November 2025. |
| Google Cloud Migration Center | Inventory, sizing and cost estimates for Google Cloud. |
| RVTools or LiveOptics | What the VMware estate really runs: VMs, CPU, memory, storage and use. |
| NetFlow and firewall logs | Which applications talk to which, so chatty dependencies move together. |
| Configuration management database (CMDB) and licence records | Owners, criticality, support hours and licence terms for each service. |
After a migration the faults are rarely about packets. They are about placement, dependencies, cost and licensing. Packet path faults inside a cloud follow the method on the AWS, Azure and Google Cloud page.
My approach
- Placement. Is the workload where the plan said, in the right region and zone, and does that still fit its latency and data needs?
- Dependencies. Did a chatty dependency stay behind on premises, or move in a different wave?
- Performance. Compare response times and resource use with the baseline taken before the move.
- Cost. Compare spend with the forecast, line by line: compute, storage, egress and licences.
- Licensing. Check the licence terms allow the new host, region and core counts.
- Fix and record. Fix through the pipeline, update the wave plan, and record the lesson for the next wave.
Faults I see most
- Latency after a move because a chatty dependency stayed on premises
- Egress charges higher than forecast
- Licences that do not allow the new host
- A wave rolled back because a dependency was missed
- Instances sized from peaks rather than real use
- A backup or monitoring agent missing after the move
Layer by layer
| Layer | What I check |
|---|---|
| Placement | Region, zone and service choice against the latency, recovery and data rules for the workload. |
| Network path | The hybrid link, routing and DNS between the workload and what it depends on. |
| Data | Where the data now lives, how it replicates and what it costs to move. |
| Cost | Compute, storage, egress and licences against the forecast and the budget. |
| Operations | Backup, monitoring, patching and support in place, as before the move. |
Packet path faults inside a cloud are on the AWS, Azure and Google Cloud page, and my general method is on the troubleshooting page.
Support changes most during a migration, so I agree it wave by wave and make the split between provider, platform and application teams explicit.
Shared responsibility
A written split of who owns what for each service type, from infrastructure as a service to SaaS.
Platform team
Owns the landing zone, the hub, connectivity, DNS, identity integration and guardrails.
Monitoring
Health of connections, hub firewalls and key services, plus provider service health alerts.
Runbooks
Failing over a private connection, restoring a workload in a second region, and rotating credentials.
FinOps
Cost reports by owner, budgets with alerts, and a monthly review of waste and commitments.
Provider support
The right support plan and named contacts, with escalation tested before it is needed.
A cloud estate drifts and grows unless someone keeps it in shape. I plan that work from the start.
- Review. Regular reviews against the provider's well architected guidance, workload by workload.
- Rightsize. Sizes and commitments adjusted to real use, and anything unused removed.
- Update. Images, runtimes and managed services kept within support, with deprecation notices tracked.
- Test. Recovery tested at least once a year, with evidence kept for audit.
- Guardrails. Policies updated as new services are approved, and exceptions reviewed.
- Exit. An exit plan for each critical service, kept current, as regulators increasingly expect.
Projects
Where I have delivered it
Cloud work for me has always been joined up with networks, security and the data centre, never treated as a separate project.
AWS Solutions Architect Professional
My cloud architecture certification. I have also trained in Microsoft Azure and Google Cloud Platform.
Multi cloud transformation
Led network and security transformation from discovery to provisioning across Cisco Nexus, Catalyst SD-WAN, SD-Access and AWS, Azure and Google Cloud environments.
Plant data to the cloud
For Dyson, supported secure MQTT data paths from production lines to MES (manufacturing execution systems) and cloud data platforms, with industrial network segmentation and OT (operational technology) security controls around them.
Industrial data, secured
Shaped network security for AVEVA Historian and, during the OSIsoft acquisition, the PI System, moving process data for oil and gas, chemicals and food customers securely to data centre and cloud.
Cloud and disaster recovery
Cloud, SDN (software defined networking), disaster recovery and security architecture for enterprise clients, then directed architecture and delivery across AWS, Google Cloud, Azure and disaster recovery while leading and mentoring a team of 4 engineers.
How I build it
Hybrid and multi cloud design, Terraform, Ansible and Python, with VMware on premises as a VMware Certified Professional in data centre virtualisation.
Backed by AWS Certified Solutions Architect Professional. I have also trained in Microsoft Azure and Google Cloud Platform. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.