I remember in the early days the Core/Distribution/Access model was the bible to design Local Area Networks. It provided a great way to “separate complexity from complexity”, one of my favorite architecture design principles, while at the same time it allowed to collapse different tiers together to save costs. And the best of all it is that it wasn’t specific to Cisco, it was a model you could apply when building networks with any hardware vendor. If you don’t know what I am talking about, here a picture cortesy of Cisco Press:
Alas along came Clos networks (apologies, I mean “fabrics”) and the need to push functionality to the edge for better scalability, with hypervisor-based overlays taking this approach to the extreme by even removing functionality from the traditional network, moving it into the server virtualization layer. Hence the Core/Distribution/Access model fell into oblivion for many folks, especially if you were focused on Data Center networks design.
Fast forward 5 years: public cloud networking is in! However, there is no common network architecture paradigm for public cloud networking. Not even for a single cloud provider! Every cloud network design is hand-crafted, and this process reminds me more to the pet than to the cattle model. It is difficult comparing network designs to each other, and I see many architects who are not aware of the trade-offs they make when they choose a certain design option over another one.
Would it be possible to apply a similar design pattern than the old Core/Distribution/Access design to public cloud networking architectures? Here we go!
Multi-cloud network design tiers
Obviously the public cloud network tiers need to be different, but they still need to have specific functions, following the principle “separate complexity from complexity”. This is the way I look at it:
- Access: this is where you connect your VMs/instances to VNets/VPCs. It provides fabric-based traffic segmentation (NACLs, NSGs) and private connectivity to managed services (Private Link).
- Regional Aggregation: it provides regional network-centric services such as firewalling, Internet access or DNS. Ideally it should summarize the routes of different VNets/VPCs to the next layer
- Core: the main functionality of this layer is providing inter-regional communication, and optionally networking slicing, for designs that require some level of multitenancy. This is the goal of services such as Azure Virtual WAN, AWS Cloud WAN or Google Network Connectivity Center
- Hybrid Aggregation: here is where you connect your onprem sites or other clouds, either via dedicated connections (ExpressRoute, Direct Connect, etc), VPN or 3rd-party appliances that will typically provide some sort of SD-WAN functionality.
Here is what the model looks like when applied to Azure and AWS (my AWS knowledge is quite limited, so I would appreciate any feedback about the diagram:
“Ah, this looks like an awful lot of boxes, my cloud vendor is trying to sell me as much stuff as it gets”. No, that is not it. The purpose of the model is to identify the different functional requirements that your network design needs to fulfill. If that is too many boxes, you can collapse tiers together, knowing that you are deviating from the principle “separate complexity from complexity”, and hence your design would be operationally more expensive. Long story short, you can collapse tiers trading cost by complexity.
For example, a relatively typical collapsed design is when the Core and Hybrid Aggregation are collapsed into the Regional Aggregation level. This is the design that we commonly know in Azure as the “Do-It-Yourself Hub and Spoke”, since you need to implement the functionality of the Core tier in your regional aggregation, hence making your design cheaper but more complex:
You could take your collapsing further, and merge everything into the Regional Aggregation layer. There are not so many benefits from this design, and rather disadvantages: at least in Azure, having a single VNet per region will mean that all your VMs are in the same subscription. However, it is perfectly possible following our networking design architecture model:
By the way, the fully-collapsed model in AWS wouldn’t impose the same restrictions than in Azure, since AWS has the concept of “Shared VPC” spanning multiple accounts. The corollary is that you still need to consider the particularities of your specific cloud when you do your design.
Collapsing into the Core
The Core services provided by the public cloud providers (the ones I am aware of are AWS Cloud WAN, Azure Virtual WAN and Google Network Connectivity Center) offer some network services, so it might be that if your requirements around this topic are not too sophisticated. In that case, you can collapse the Regional Aggregation layer into the core. For example, at the time of this writing Azure Virtual WAN doesn’t support multi-regional firewalling. Hence, if you don’t need firewalling in Azure (because you do network segmentation with NSGs), your design might look like this:
With time, these network core services like Virtual WAN will enhance their functionality, so core-collapsed designs will become more and more frequent, depending on the network services that are required in each project.
In AWS this design is probably the most obvious one when using Cloud WAN, since Cloud WAN is very much based on TGW technology. Hence, in the majority of Cloud WAN diagrams you will probably see a picture similar to this one:
This is the way I structure my network architecture sessions, and I thought it might help others. Network architecture is one of those topics where everybody has their own opinion, and everybody might be right at the same time, so I would really love your comments around this. Thanks for reading!
13 thoughts on “Is the Core/Distribution/Access design dead?”
Great article… Really helpful and much needed.
Thank you for sharing
Thanks Shahrukh, I am so glad it is useful!
Nothing changed but the names, in the spine/leaf fabrics you have another layer on top on a fabric that allows you to connect to other fabrics and the rest of the network, we don’t call it core/dist/access but it’s the same
Hey Paul, not sure if your comment refers to public cloud networking (Azure/AWS), which is the main topic for this post?
Connectivity pattern in a well designed “connectivity fabric” preserves CLOS characteristics – full mesh within plan (equidistance between end points) and a such is a stage in a multi-stage fabric (and not a core layer that has quite different connectivity model).
[…] design options and recommendations using the 3-tier cloud netowrk architecture that I described in this post. If this sounds interesting to you, keep […]
What if we replace Cloud CORE layer (Azure vWAN or AWS Cloud WAN or similar) directly with the SDWAN? The good thing is that you can integrate your DC and Branch Offices SDWAN strategy with Cloud and Multicloud Environments. So one single technology to manage all the COREs. You will not need to build up S2S and set up complex redundancy strategies. SDWAN will do it t for you once you have more then one underlay available. Maybe i am wrong or missing something but i can only see benefits in terms of operations and a much more simple architecture.
LikeLiked by 1 person
Good thinking, finally a good question on this article! 😀 Yes, that would essentially be my first example of a collapsed design, where VWAN functionality is merged in the hub VNet. In the diagram I only have Azure VPN and ExpressRoute gateways, but from a design perspective it is the same as having SDWAN appliances.
Found my new favorite blog! I was in my cloud architecture class, designing network architecture where remote offices would aggregate connections from remote retail sites that would feed into the cloud, and my instructor mentioned the “core/distribution/access model”. I did some googling to find out more to see if someone had reframed it from a cloud perspective and was led to your blog!
I am so glad you liked it! I would say it is not a “reframing” but more an “inspiration”, but anyway I am happy that the comparison holds!
[…] pattern is applicable. Using the Azure Network architecture framework that I first published in this post, you initially start from the most flexible design which is Virtual WAN with indirect spokes […]
Great article! Thank you for this! Seeing the Core/Dist/Access model brings back memories! Great to see you talk about a cloud networking model that aligns to that thinking.
What do you think about the current VWAN preview of Routing Intent/Inter-Hub security? Once cross region, inter-hub inspection is more widely available, do you see the model with regional aggregation collapsing into the core being the go to model?
Hey so glad you liked the article? With every new feature, Virtual WAN becomes more flexible, and will be able to cover more use cases. I still see the fully expanded design staying relevant for those designs or NVAs that VWAN doesn’t address.