For network administrators who have spent their entire careers configuring and maintaining on-premises networks, the thought of performing those same networking tasks within public cloud infrastructures can be vexing. The good news is — after a small learning curve — most administrators will discover that working on networks inside and between clouds is nearly identical to their on-premises counterparts.
In this article, we’ll cover some cloud networking basics, including some important network terminology used by the two most popular cloud providers in the United States: AWS and Microsoft Azure. Additionally, we’ll discuss some of the basic tasks required to configure your cloud network for any enterprise application.
Cloud networking terms
The first thing to understand when configuring cloud networks is the terminology used by the service provider. This new vocabulary may seem intimidating at first, but the words are easy to comprehend once you dive in. Additionally, most IaaS cloud providers use slightly different wording to describe similar networking services.
VPN gateway is another important term in the world of cloud networking basics. This term refers to the connection and corresponding routing required to join a VPC or VNet to one of the following:
- another cloud segment within the same service provider cloud;
- a private LAN for hybrid cloud connectivity; or
- a different cloud service provider for multi-cloud
Note the use of the word VPN when describing these gateways. This is because the connection between segments is provided across an encrypted VPN tunnel either within the same cloud or across the internet to corporate LANs or other third-party cloud providers.
If the applications, data and services you manage in a public cloud require dedicated bandwidth and low network latency backed by a service-level agreement, a VPN tunnel across the public internet won’t cut it. Thus, instead of a VPN gateway, you’ll want to use a dedicated cloud connection, which is essentially a private WAN connection that leads directly to your public cloud provider.
It’s also helpful to be aware of other cloud nomenclature that’s not exclusively related to networking. For example, consider the following terms:
- AWS Route 53 and Azure DNS are domain name system services;
- AWS CloudFront and Azure Content Delivery Network are content delivery networks; and
- AWS CloudWatch and Azure Application Insights are built-in performance and analytics tools.
Knowing the service names — and what they do — will go a long way in helping you refine your cloud networking basics as you work alongside application and server administrators to build your cloud instance.
Basic configuration options
Seasoned network engineers might be surprised to learn that out-of-the box networking configuration options within an IaaS cloud are far more limited compared to on-premises alternatives. For the most part, an administrator can natively configure and manage the following within an IaaS cloud:
If you need to build more complexity into your cloud network, there are a few ways to augment the options the provider offers you natively. The first is to use vendor-specific virtual appliances found in the provider’s cloud marketplace. These virtual appliances can be deployed in the cloud as substitutes for the basic networking services the cloud provider offers.
For example, you can spin up a Cisco Cloud Services Router 1000V Series software router in place of the standard VPN gateway. Doing so allows an administrator to configure more complex technologies, such as Cisco’s SD-WAN framework, directly into the public cloud, extending the organization’s SD-WAN infrastructure. Keep in mind, however, that there is an added license and usage cost when purchasing these types of specialized appliances.
A second option that’s useful in very large hybrid cloud or multi-cloud architectures is to deploy a multi-cloud management platform throughout all public and private clouds. This creates a software-based overlay network where network administrators can create and manage universal network and security policies. These universal policies can then be pushed across multiple third-party cloud service providers and within the corporate LAN itself. Again, be aware that added licensing and usage costs will apply.