How Cloud Networking Is (and Isn’t) Different from On-Prem

A lot has changed about networking over the recent years, and cloud networking may at first feel somewhat foreign to someone who is used to dealing with traditional on-prem data center networks. If that sounds like you, you’re not alone. A lot of the world’s computing still takes place on premises, yet organizations increasingly add cloud services to replace or augment their existing IT infrastructure. The important thing to keep in mind is that the fundamental principles of networking remain the same, which means that much of the knowledge you have gained will translate as your organization embarks on its cloud journey.

Let’s take a look at the ways in which cloud networking is different from traditional data center networking and how to use those differences—and similarities!—to your advantage.

More on cloud networking:

• The ABCs of Cloud Network Design

The Rise of Network Virtualization

If I had to pick one development that changed the course of networking, it would be the rise of network virtualization. I don’t think I realized at the time what was about to happen. I had a solid fundamental understanding of networking in the data center, and I was working with server virtualization on a daily basis.

Making the case for server virtualization was easy. Abstracting hardware by decoupling it from the functionality had all kinds of benefits, such as simplified management and greater utilization of expensive compute resources. It also provided a layer of protection against downtime caused by hardware failures.

Server virtualization did take some explaining in those days, however, especially the part where a virtual machine was no longer tied to a specific piece of hardware sitting in a specific rack in the data center. Some folks struggled to understand this concept. But it also impacted things like ticketing systems and troubleshooting workflows. (Admins were very used to just walking up to a server in a rack when it wasn't working.)

Network virtualization changed the paradigm even further. We would have to learn not to care about what physical switch and switch port a server was connected to. We would start building logical constructs on top of hardware, greatly simplifying deployment and management.

My favorite example of basic network virtualization are VLANs. Virtualizing LANs had huge benefits, because I could put my hardware wherever it made the most sense to put it in the data hall, without worrying that I wouldn’t be able to keep it all connected to the same network. As network virtualization matured, more things became easier and easier.

Then came the concept of Network Functions Virtualization, or NFV, which had major parallels with server virtualization. Costly proprietary networking equipment—your routers, firewalls, load balancers—could now be replaced by software running inside virtual machines on standard servers. As with server virtualization, this enabled much faster provisioning and greater scalability than was possible with physical hardware constructs. This freedom from physical constraints—be they compute, storage, networking, or the data center building itself—is what made the cloud so revolutionary.

Cloud Networking Is Still Networking

There are many different types of clouds, of course, so to keep things simple, when I mention the word “cloud” in this article I’ll be referring to the big public clouds, such as AWS, Azure and Google Cloud.

You can’t have a cloud without a physical network, obviously. Cloud components and applications need to communicate with each other, so there is a physical network layer underneath the virtual constructs that make cloud networking so powerful. Instead of you racking and cabling routers, switches and load balancers, however, it's taken care of by the cloud provider.

Cloud networking speeds up deployment of your services. No more waiting for hardware to arrive and be installed and no more moving switch ports around while troubleshooting. These benefits are amplified in more complex cloud deployments that cross regions and availability zones. Things that could take months to deploy on premises are now often as simple as performing basic configuration in the cloud console. This frees up networking teams to focus their attention elsewhere.

When using cloud services, it is important to remember that your relationship with a cloud provider is based on a “shared responsibility model.” There’s a common misconception that the cloud is this magical platform where all the “boring” infrastructure and security details are taken care of for you. As organizations learn (the hard way) time and time again, this is not the case, so it’s important to understand where in the stack the delineating line between the cloud provider’s responsibility and your own is drawn. 

This is especially important as you get into cloud networking. Not unlike on-prem data centers, the cloud network is where many security threats can be thwarted. While we don’t need to worry about securing the physical network in the cloud, we are responsible for securing the logical network sitting on top.

A Basic Cloud Networking Building Block

AWS is the most widely used cloud, so I’ll use it as an example for this next concept, but all major clouds have the same basic capabilities that I’ll be describing here—albeit, different providers have different names for them and have implemented them in slightly different manners.

The fundamental cloud networking building block within AWS is a Virtual Private Cloud, or VPC. It is a simple logical construct that other components within your cloud, such as EC2 instances, are connected to.

A simple yet powerful concept, the VPC is where the basic networking components, such as your IP address range and subnets, are configured. It’s also where the more advanced security features, such as Access Control Lists and Security Groups, live (part of the reason why taking the time to get a fundamental understanding of VPCs is so important).

There are multiple VPC options (a single public subnet, public and private subnets, public and private subnets and site-to-site VPN access and so on). They’re ready out of the box and cover just about any use case you can think of. There is a simple wizard that will guide you through VPC creation. Importantly, AWS does not charge extra for creating or operating a VPC, so there is no reason to take shortcuts. You can use as many or as few as you need to design your cloud deployment in a way that makes sense for your organization.

Private Connections to the Cloud

The VPC is the basic construct for just about everything related to AWS networking, and if your workload runs entirely in the cloud, VPCs will have you covered. But if you are looking at a hybrid cloud deployment, combining your own data center with the cloud, there is another important concept: private network onramps to the cloud. AWS’s version of this is Direct Connect. Azure’s is ExpressRoute. Google’s is Cloud Interconnect.

Continuing to use AWS as an example, Direct Connect allows you to link your internal network to Amazon’s cloud with a “standard Ethernet fiber-optic cable.” Yes, you read that correctly. You can plug your own network into the cloud. You may then connect to one of your VPCs or even directly to an AWS service like S3. The same can be done in Azure with ExpressRoute and Google Cloud with Cloud Interconnect.

The trick here is being in one of the colocation sites that host AWS Direct Connect onramps. There are many such sites to choose from in almost every region. Many of them are Equinix data centers, where Equinix Fabric allows you to access all of the major cloud providers' private onramps in all major markets around the world. You can search for your provider and map them to your metro locations using this tool.

For many use cases this is the best of both worlds, especially if you are working in a hybrid configuration—or a hybrid multicloud one—or have large amounts of data. Private cloud onramps make cloud networking even more flexible, adding to the ability to set up multiple different VPCs the ability to get a private and reliable dedicated connection to that part of your infrastructure that may not lend itself well to being in the cloud.

While cloud consoles may take some getting used to, cloud providers also have robust sets of APIs that can be integrated into application workflows. This is where it becomes important for the networking team to work with the application team to understand requirements for networking and deployment ahead of time. By integrating network configuration into these workflows, operations can be even further streamlined in a way that just isn’t always possible in an on-prem data center. (Gone are the days of running out of or misconfiguring switch ports!)

Tips for a Smoother Transition to the Cloud 

Now that we have covered some of the very basic cloud networking concepts, here are a few tips for ensuring that your transition from an on-prem only environment to one with an element of cloud is a success.

The good news is that a network is still a network! All the things you know about networking remain valid in cloud networking. You just don’t have to deal with the physical side of things. The troubleshooting skills you have developed over time will serve you well in the cloud, too, except that you can now skip the step of turning it off and on again.

Follow Good Network Design Practices

All the good network design practices still apply in the cloud, and the best thing you can do when adding cloud infrastructure into the mix is taking the time to create a proper network design. 

Engineers often skip this step, thinking that since they don’t need to worry about data center constructs like power, cooling, or hardware, they can let the cloud provider worry about network design, too. But some upfront planning can go a long way when it comes to your cloud networking configuration.

Learn Network Virtualization Concepts

The best way to further your cloud networking chops is to spend some time with network virtualization concepts. 

Try applying network virtualization in the context of your daily work. If you work with Cisco networking, for example, start with exploring Cisco network virtualization concepts. Adding new concepts into the context you already understand is often the quickest path to grokking them.

Learn Your Cloud Platform’s Lingo

I used AWS as an example to break down some core cloud networking concepts. As you saw, AWS has its nomenclature for things and other cloud providers have theirs. A big hurdle networking pros often face when moving to the cloud is simply translating the different terms different platforms use for similar things.

Take the time to learn the lingo before you start deploying your networking configuration and be ready to do that again if you eventually add another cloud platform.

An Opportunity to Fix What’s Broken

As a bonus, the period of cloud adoption is a great time to improve existing processes. What do you find yourself doing on a daily basis that makes your life as a network administrator difficult? Maybe you are manually configuring a lot of things, or maybe the way application and network teams work on requests together isn’t ideal. Cloud adoption can provide a true clean slate for streamlining and improving the operation.

Adopting a new technology doesn’t have to be overwhelming, no matter how different it may seem. The cloud is simply someone else’s data center. That means much of the stuff you learned working in your own data center will translate. This is especially true with networking, which remains a fundamental building block of every system and application—no matter where you deploy it!