The workloads a network engineer connects have moved. Some are still in a data centre you can walk into; many are in a public cloud you will never see; most enterprises are somewhere in between, running both at once. Designing for that reality means understanding what changes when the servers are someone else's, what stays the same, and where the new failure modes and cost traps hide. The ENCOR blueprint asks you to reason about this, not to become a cloud architect.
This article covers on-prem versus cloud network design for network engineers. It extends the QoS cluster guide and the campus design article.
What Actually Changes in the Cloud
The fundamentals of IP, routing, and segmentation do not change; a subnet is a subnet. What changes is who operates the underlay and how you express intent:
The mental shift: on-prem, you build and own the whole stack, cables to config. In the cloud, you consume a virtual network the provider operates, and you express your design as software (route tables, security groups) against their infrastructure. Your job moves from building the network to designing and governing it.
The Cloud Building Blocks (In Familiar Terms)
Every cloud provider's networking maps onto concepts you already know, with different names:
The security group is the one that most changes how you think. On-prem, you filter at chokepoints (a firewall between zones). In the cloud, the filter attaches to the workload itself and moves with it, so segmentation is expressed as "which instances can talk to which," everywhere, rather than "what passes through this firewall." It is microsegmentation as the default, and it is stateful, so you allow the request and the return is automatic.
The Hybrid Reality: Connecting the Two Worlds
Almost no enterprise is purely one or the other. The interesting design work is the interconnect, and there are two main ways to bridge on-prem and cloud:
The choice mirrors the classic MPLS-vs-internet trade-off: the VPN is fast to deploy and cheap but best-effort; the direct interconnect is predictable and performant but costs more and takes weeks to provision. Many designs use both, a direct interconnect for production with a VPN as backup. And routing between the two worlds is typically BGP over the interconnect, so your BGP knowledge transfers directly.
The Traps That Catch On-Prem Engineers
The failure modes and cost surprises that differ from on-prem thinking:
- Data transfer costs. This is the big one. Moving data out of the cloud (egress) and between availability zones costs money, per gigabyte. A design that would be free on-prem (chatty cross-zone traffic) can generate a large bill. Network design in the cloud is partly cost design, and this has no on-prem equivalent.
- No broadcast or multicast. Cloud virtual networks generally do not support broadcast or multicast the way a physical LAN does. Applications and protocols that assume them (some clustering, some discovery) break or need workarounds.
- Availability zones are your redundancy unit. Resilience in the cloud means spreading across availability zones, not redundant cables. A subnet lives in one AZ; designing for failure means multi-AZ placement, which is a different discipline from redundant links.
- The shared responsibility model. The provider secures the underlay; you secure your configuration (security groups, route tables, access). A misconfigured security group is your fault and your breach, not the provider's. Cloud security failures are overwhelmingly customer misconfigurations.
- Static routing by default. Route tables are static. Dynamic routing exists (via virtual routers or the interconnect BGP) but the intra-VPC model is static route tables, which surprises engineers expecting an IGP.
What Stays the Same
It is worth ending on reassurance, because the cloud can feel alien. The fundamentals are unchanged: IP addressing and subnetting work identically, routing logic (longest match, next-hop) is the same, segmentation is still about controlling who talks to whom, BGP is still BGP over the interconnect, and the design goals (redundancy, segmentation, performance, cost) are the same goals in different clothing. A network engineer's core knowledge transfers directly; what you learn is a new set of building blocks and a new bill to watch. The instinct that made you good at on-prem design, thinking in terms of failure domains, segmentation, and predictable structure, is exactly what makes you good at cloud design.
FAQ
What is a VPC?
A Virtual Private Cloud (VNet in Azure): your isolated virtual network in the cloud, containing subnets, route tables, and security groups. Conceptually like a routing domain or VRF that you own.
How is cloud security different?
Security groups attach to instances and move with the workload, so filtering is stateful and everywhere, rather than at chokepoint firewalls. It is microsegmentation by default. And it is a shared responsibility: the provider secures the underlay, you secure your config.
VPN or direct interconnect for hybrid?
VPN (IPsec over the internet) is quick and cheap but best-effort. Direct interconnect (Direct Connect/ExpressRoute) is predictable and performant but costs more and takes longer to provision. Many use both, interconnect for production, VPN as backup.
What is the biggest cost surprise?
Data transfer, especially egress out of the cloud and traffic between availability zones. It is metered per gigabyte and can be large. Cloud network design is partly cost design, with no on-prem equivalent.
Does my networking knowledge transfer?
Yes, directly. IP, subnetting, routing logic, segmentation, and BGP all work the same. You learn new building blocks (VPC, security group, route table) and a new cost model, but the core design instincts are exactly what cloud design needs.
Key Takeaways
- In the cloud you consume a virtual network the provider operates, expressed as software (route tables, security groups) rather than built from cables and CLI.
- The building blocks map onto familiar concepts: VPC/VNet (your network), subnet (tied to an AZ), route table (static routing), security group (stateful per-instance firewall).
- Security is distributed and instance-level (microsegmentation by default), under a shared responsibility model, most cloud breaches are customer misconfigurations.
- Hybrid connectivity is VPN (cheap, best-effort) or direct interconnect (predictable, costly), the same trade-off as MPLS vs internet, usually with BGP routing.
- The traps: data-transfer costs (the big one), no broadcast/multicast, availability zones as the redundancy unit, and static route tables by default.
- The fundamentals are unchanged: IP, routing, segmentation, and BGP transfer directly. Your on-prem design instincts are what make you good at cloud design.
This closes the QoS and Architecture cluster. Back to the QoS cluster guide for the full reading order.
