Designing a cloud-based network includes a number of technical challenges. In this video, you’ll learn about network function virtualization, VPC endpoints, network security lists and groups, and much more.
Cloud computing has undeniably changed the way we approach technology. With one click of a button, we can deploy an application and multiple services, all seemingly with unlimited resources. We’re able to scale up and scale down these applications as we need, providing elasticity, especially in times when we have large demand, and then scale it back down when that demand goes away.
We also have applications that we can now scale up or scale down and access those applications from anywhere in the world. Cloud computing also uses multitenancy, where many different customers are using the same cloud infrastructure. This allows for efficiency in the use of technology and efficiency in how much it costs to use this technology.
Not only do we have virtual servers that can live in that cloud computing infrastructure, we can also have virtual networks. Let’s take the scenario where we might have 100 individual servers that are running in our data center. That’s a relatively large farm of servers.
We’ve designed this infrastructure to have redundancy in the network. There are multiple servers, we’ve got load balancers and multiple firewalls, and we’ve designed it for uptime and availability. But now let’s take this entire physical infrastructure, and let’s move this infrastructure to the cloud. We’re going to migrate 100 physical servers to effectively one very large physical server. Inside that one very large physical server, we will run 100 virtual servers inside of it.
Now that we’ve taken these 100 physical servers and migrated them to a cloud infrastructure, what do we do with our networking infrastructure? Not surprisingly, we will virtualize this network infrastructure as well. This is referred to as Network Function Virtualization, or NFV, where we can replace our routers and our switches and our other networking devices with virtual versions of those networking devices that are running in this virtualized environment.
Although our firewall and our switches and our routers are no longer physical, they still have the same functionality. We can see those devices, our network interfaces, and everything about the network configuration, all from our hypervisor. So we have the same functionality. It’s just now in a virtual appliance.
Just as we’re able to push a button and deploy a new server, we can push a button and deploy a new firewall or a new switch or make a router configuration, all within this virtualized world. This gives us a lot of flexibility for deploying applications, designing the network connectivity for those applications, and connecting our different cloud infrastructures wherever they might be in the world.
A common application instance inside of a cloud infrastructure might include a web server, a database server. There could be load balancers, virtual switches and routers, and virtual firewalls. All of these will run inside of a Virtual Private Cloud, or a VPC.
It’s very common, especially in larger environments, that you would have separate VPCs for different application instances or different parts of the company. This allows you to keep all of these systems separated but still allow you to manage all of them as individual virtual appliances. Although these VPCs may be different application instances, we might still want to have devices within those separate VPCs be able to communicate with each other.
To provide that communication, we need a device in the middle called a transit gateway to be able to connect all of these VPCs together. You can think of this transit gateway as a cloud router that allows us to connect and allow communication between all of our different VPCs.
If you need connectivity to these VPCs from the outside, you may need to add additional security in the form of a VPN connection. This allows someone who may be at a remote site to be able to bring up a VPN tunnel, connect to the transit gateway, and effectively have communication to all of your different VPCs.
It’s very common to use a VPN at a remote site or from a user’s workstation to be able to gain access to these private VPCs. But there may be times when you want to make your application instances available to anyone on the internet. In that scenario, you might want to use a VPC gateway, or what we refer to as an internet gateway, so that users anywhere in the world will have access to your applications.
We might also want to have these devices in each of our VPCs communicate outbound over the internet to other resources. We would use a VPC NAT gateway to provide this communication, and the NAT stands for Network Address Translation. Our VPCs and the private networks that we’re running inside of those VPCs can translate to a public IP address to be able to communicate out over the internet.
This includes security rules so that your VPCs can connect outbound to internet resources, but you may not necessarily allow inbound access from external devices. And it’s not uncommon for many organizations to use multiple cloud providers but still require connectivity between those cloud providers. We can provide that connectivity through the use of a VPC endpoint, where we create a direct connection from a VPC on one cloud provider to a VPC on another cloud provider.
Here’s an example that has a number of different VPCs. We’ve got a virtual private cloud with a public subnet for public applications that people can access from anywhere on the internet. We also have a private subnet on this same cloud provider, where we have a private virtual machine.
Well, if we have a different storage network, which certainly could be at a different cloud provider, that cloud storage can easily connect to the public subnet over the existing internet and using a VPC internet gateway. But our private subnet is not accessible from the internet. So we need to add a VPC endpoint that will allow our cloud storage to communicate directly to what is a private subnet and virtual machine.
Many cloud providers will include additional security that you can layer on top of your VPCs. Security groups and lists are effectively a firewall that’s created for your cloud-based services. This allows you to control what traffic can go outbound and inbound to your VPCs. Most of these are based around a series of port numbers and protocols. So you can define a TCP or UDP port number and add that to your inbound or outbound rules in your security groups.
You can also add layer 3 addresses to this. So you can add IP addresses that are individual addresses, maybe an entire block of addresses using CIDR block notation, or specify IPv4 or IPv6 ranges directly within your security groups. This is very similar to configuring a traditional firewall which operates looking at TCP or UDP port numbers. In this example, the inbound rules have a number of predefined rules, but you can customize these as well with your own port numbers specific to your application.
In your cloud provider’s front end, you would include in your network security list the list of rules that you would like to assign. For example, I have a rule that is inbound using TCP port 443, and any IP address is allowed to communicate inbound with that rule. I have another rule that’s an inbound rule for TCP port 22, and it’s the same broad range of any IP address.
Once you define your network security list, it will be applied to all of your virtual private clouds. And you can see that I have a virtual cloud network for Subnet X, Subnet Y, and Subnet Z. And these very broad network security lists will automatically be assigned to each one of those individual networks.
One of the challenges with these network security lists is that they don’t provide a lot of granularity. When you configure a network security list, it’s automatically assigned to all of your virtual cloud networks, even if you don’t need that particular rule in that cloud network and even if you need additional rules for one of the individual cloud networks.
Fortunately, there are ways to add additional granularity using a network security group. With a network security group, I can assign rules to individual Virtual Network Interface Cards, or VNICs. So you can see I have similar security rules that I’ve defined as a network security group. I have Network Security Group A, which is inbound TCP to port 443, and I have a Network Security Group B, which is also an inbound rule to TCP port 22.
I’ve identified these as the Network Security Group A with the green shield and the Network Security Group B with the blue shield. And you can see that I can assign those network security groups to individual network interface cards that may be inside of a virtual cloud network. This one is on a single subnet, where I’ve defined different rules for different interface cards within the same virtual cloud network subnet.
You can see by using these network security groups that we do have additional granularity that we could bring down to the individual interfaces. But this also increases the amount of administration required to manage all of these different lists. If you find that you need additional security above this, you might want to look into a virtual firewall or other virtualized platform to include additional security to your application instances.