5 Considerations for Public Cloud Networking
Transcript
>> Hey, what's up everybody? This is Ned Bellavance, Ned1313 on Twitter and I am here to talk to you today about five considerations for public cloud networking. I'm actually going to cover both hybrid cloud networking as well as public cloud networking, but the real focus is going to be on how you can properly design your public cloud networking strategy to take advantage of what's available in each public cloud as well as connect it to your existing on premises locations as well as remote users 'cause those are all important considerations.
Now we're going to be approaching design from a couple different factors. The first one is traffic management. How do you understand and manage the traffic that is going through your public cloud networking. Then we're going to move into the performance planning aspect of things and the information that you're going to want to collect and need to know, in order to properly plan for performance within your public cloud. Then we'll talk about applying security. So obviously applying security is eh, it's sort of important.
People get a little twitchy about the public cloud when it comes to security. How can we make sure that our public cloud networking is secured appropriately? Then, the other thing that people get a little twitchy about is cost, because there is a cost when you're using network in the public cloud and it's generally egress cost but there's other costs that you might want to consider. And then finally we're going to talk about the process by which you deploy your public cloud networking and maintain it ongoing, because day one is when you deploy yourself but day two is when you actually have to continue to manage that networking especially as it becomes more complicated.
First, let's talk about what the public cloud vendors talk about when they talk about your network. It's usually represented a bit like this. One might say it's simplified, idealized, marchitecture, you know, whatever you want to call it. Basically as far as they're concerned, you have a data center of some kind and it's connecting to their cloud and only their cloud through some amazing magic connection. I don't know, maybe a unicorn is transporting the packets magically back and forth and everything is fine, that's all you need to set up.
Maybe you need a little more bandwidth and less latency so you'll go with an express route or direct connect or whatever their flavor of a direct circuit is to their cloud, but really as far as they're concerned this is how complex your network currently is. And we know that's not exactly the reality. When you're looking at your network, it probably looks a little bit more like this. You don't just have one data center, you have multiple data centers in multiple regions. And those data centers are interconnected.
Maybe they're using some type of MPLS cloud for that data center interconnect, but they definitely have it. So that's one layer of connectivity that you already have to deal with. And then you also have branch offices and those branch offices, how are they connecting to your data centers and also how are those branch offices connecting to the internet? Are you forcing all traffic from those branch offices to go back to one of your data centers and then out to the public internet or do they have some device at the branch location that allows for that local internet breakout instead of back hauling it to your DC?
I don't know, and hopefully I don't know if you know, but if you do, you know that's another design characteristic that you have to think about. Now we get to the cloud layer. Now, when you look at the marketecture for any of the individual public clouds they generally assume that you are using just one cloud. Even though they talk about multi-cloud in some other slides, it's almost like the two teams aren't talking. So they will just show their cloud and their connectivity to your data center.
But we know that is not the case. There's a really good chance you're in more than one if not all of the public cloud providers. And the connectivity to those public cloud providers may be different depending on the provider. So maybe for GCP and AWS, you've got some direct circuits into those that are coming out of North America whereas Azure, you're using site-to-site VPNs that are terminating somewhere in APAC. And you might have inter cloud connectivity as well because mainly you are collecting data from IOT sensors in AWS and then shipping that data over to GCP to apply machine learning or AI modeling.
That's a real world example that I've seen. So with that in mind, there's a lot of connectivity here and there's one more layer that we haven't even dealt with and that additional layer is the people. Your remote workers that are on mobile devices of some kind. Are they going through a VPN that's going to one of your data centers? Are they directly connecting to one of the public clouds? I have no idea. That's yet another layer that you have to think about when you're considering your approach to public cloud networking is how is the endpoint actually connecting to your public cloud?
What sort of pathways does it have to go through? And that's how we get to traffic management. So with traffic management, there's a few different aspects that I would encourage you to consider. One is the origin of the traffic. Traffic that's hitting your public cloud deployment. Where did that traffic originate from? Is it originating from a data center? From a branch office? Or from an end user device? Is someone hopping on your public cloud through a WiFi hotspot and that's going to be the typical way that they're connecting into the cloud.
That's something that I've certainly seen when it comes to edge style computing cases or something where you have a whole bunch of branches that don't have good network connectivity so they're literally using a hotspot to connect into Microsoft Azure for instance. So thinking about the origin of that network traffic, if that's your use case, then you don't need a site-to-site VPN, you don't even need an express route either, you just need to find a way to maximize that connectivity for the end user. The other thing to consider is the flow of traffic.
Is this a connection that's going to be very heavy with ingress traffic or very heavy with egress traffic? Which direction and how are things flowing? So for instance, if you know that it's something where they're going to be consuming a lot of content but not uploading and creating it, then you might plan your public cloud networking a little bit differently using something like a CDN to provide closer localized access to that data. Whereas if it's something where they're going to be streaming lots of data up, you're probably going to want some sort of queuing mechanism to happen at the local site and then have a way to get that data in in a timely manner without costing you too much money.
So you really need to analyze the traffic flows of what's going to your public cloud and what's coming out. Then, you need to figure out how you want to approach internet egress for anything running in your public cloud. Now obviously you can just go straight out of that public cloud to the internet. And for instance, in AWS you might be using something like a NAT gateway or just the public IP addresses of the EC2 instances running in a public subnet. They might just go straight out to the internet.
That may not be great from a security perspective and we'll talk about security in a little bit, but that's how they might be getting there. Or, you might do something like what I saw. I had a client where they had an APAC region but they didn't have the security stack they wanted in place so the traffic instead of going out the internet egress point in APAC was actually being back hauled all the way to North America to one of their data centers to go out through that security stack 'cause they wanted to do all the inspection that was part of their normal protocol.
So you need to think about how you want to approach internet egress for anything running in your public cloud. You also need to consider how your branch and remote devices are going to connect to the public cloud and I kind of covered that a little bit already, but it just bears repeating. Your branch offices might be connecting to the public cloud through one of your existing data centers, but that might not be the most effective or efficient route for them to go. So you have to consider does it make more sense for me to create some sort of internet breakout point at that branch location or even public cloud breakout point let's say where maybe their internet bound traffic still back hauls to the DC to go through my security stack, but anything that's public cloud related it's consuming one of those applications now it goes over some sort of site-to-site VPN or it goes through, it's still hitting the public internet, but it's doing so in such a way that only things that are destined for this one application that runs in the public cloud will go straight there and everything else still gets back hauled.
So there's a lot of options there on how you could approach traffic management. So I'd definitely, that would be one big consideration to take into account. The second one is performance planning. So we have to think about how we want to optimize for performance when it comes to the applications we're going to run in the public cloud and one of the primary things to consider is application placements. So when we did our traffic analysis, we in theory know where the requests are going to be coming from for our various applications and what sort of traffic flow there's going to be.
Ideally, you would place the application in a public cloud end region that is closest to those who are going to consume it and now you get better network performance by doing that. So that is one thing to consider. Where are you even going to put this application to begin with? You also have to know what your bandwidth and latency requirements are and that's where you do get into a need for some sort of private circuit. Depending on your use case. So if you know you need a guaranteed amount of bandwidth and really low latency connection between your existing data center and one of the public clouds, then a circuit might actually make sense.
But remember that is a very expensive investment so you want to make sure you've justified it from a business perspective by actually analyzing the traffic flows for your application. There's a good chance you might be able to handle the necessary throughput through some sort of SD-WAN product and most of the public clouds can snap into those SD-WAN products now and use the public internet rather than one of these private circuits which makes it easier to scale up and scale back on demand whereas setting up an additional private circuit is, it's a lot of work.
It also gives you additional redundancy because if you're going to have multiple private circuits then you have to buy all those private circuits and each one should probably go out of a different data center and there's a whole lot of planning going on there. So there's definitely a reason why you would want to use these private circuits, but you need to be able to justify it from a bandwidth and latency cost. The next one is global load balancing. One of the nice things about the public clouds is they all have some sort of global load balancer option.
So if you are consuming this application, from multiple different regions of the globe, now you can use the GSLB that's built into one of these public clouds and determine where the traffic's coming from and maybe respond using an instance of the application that's closest to your user. That's a big opportunity especially if you're running your application from a data center today and you want to spread the reach of that application to users who are in a different region. For instance, I worked on a project where the primary group of people working on a particular application that this law office was using.
They were all located in the United States, but then they opened up a satellite office in APAC and now these poor APAC people were trying to pull across the wire these documents. And what they ended up doing was creating a replicated instance of this document's management system that was closer to APAC and then using GSLB to determine which version of the application a particular user should be connecting to. It also gave them failover as well. So, they were optimizing for performance by adding in GSLB.
Another thing and this is relatively new and not something you might necessarily think of is at what point do you get on the public cloud provider's backbone? Right now, if you're using something like Microsoft Azure or Office 365, they tried to get you on their internal backbone as quickly as possible and that's generally true for the ingress traffic for GCP as well. The advantage to that is rather than riding the public internet and dealing with the vagaries of that, you get on their managed backbone faster and in theory you should have a dramatically better experience or at least incrementally better experience I should say.
And many of these public cloud providers have some additional service now where you can get prioritized traffic across their backbone meaning you get better bandwidth and less latency and priority from a QuAS perspective over other traffic that might be traveling on their backbone. Not to say that their backbones are saturated, they're probably not, but they're finding a way to prioritize your traffic. And isn't that nice if it's something you need. I think Azure's is called global peering and AWS has global accelerator and I'm sure GCP has something along those lines as well.
So you might want to consider how you want to get on that public cloud backbone quickest. Another good example of this is if you're using the CDN products from any of these major public cloud providers, let's just use AWS for example, and you're using CloudFront, anything that hits a CloudFront endpoint and then has to travel back to the origin, that traversal is happening across the AWS backbone and it's not happening across the public internet. So even if the information is not at the CloudFront endpoint, because it's hitting the endpoint, now you're getting the increased performance of going across that public, that private backbone.
So that's yet another example where you could potentially get better performance by planning out when your traffic gets to that cloud backbone. That's performance. Now, another key thing and this is something that people get very concerned about is security. How do you properly apply security in this sort of distributed public cloud environment, because you know, if you're used to your data center and your approach there, you had this hard exterior guarded by your firewalls and your IDSs and IDPs and that is how you mostly protected your environment.
You probably had like a DMZ and then your internal servers and maybe there were some zones in there as well, but I mean honestly a lot of organizations it was like the firewall, the DMZ, and then everything else is open, have fun. That's the security model that doesn't work very well for cloud deployments. Now you have multiple edges. How do you deal with that? Well, you really want to take the approach and you've heard this before, right? Defense in depth.
So you want multiple layers that traffic has to go through and at those layers it's inspected and given the green flag you're good to go or the red x, nope you will proceed no further because you do not match whatever rule set I have. And that requires an analysis of traffic at multiple endpoints. And the good news is, that you can use a combination of the native products that exist in the public clouds as well as bring your own type solutions in the form of like a network virtualized appliance let's say.
Now looking at what's available from the public cloud providers, they all have some sort of web application firewall now. So if the application you're hosting is web-based and let's face it a lot of applications are today, you can have the web application firewall on the front end doing that initial layer of inspection to make sure that the traffic is not containing anything that was untoward your application. It's not trying to do a SQL injection attack or something like that. So you weed out that traffic right away.
And then you can do a deeper inspection of that traffic as it passes through various load bouncers. So if you think about a typical three tier application, you might have a web front end. So that is going through a web application firewall and then some sort of load balancer and then it's hitting your front end web servers. Those web servers are going to send that information depending on what it is, there might make a request to an application server. And that's where micro-segmentation comes into play.
You're going to want to apply micro-segmentation between all the various components of that system. That's something that was relatively difficult to achieve in a traditional data center but you could do it if you had NSX in place but not everybody had NSX. And I would say a lot of people didn't have NSX so it wasn't a particularly easy concept to apply micro-segmentation in a traditional data center. The big difference is, in any of these public cloud providers you have firewall rules that function both at an instance or a virtual machine level as well as at a subnet level.
So you can create through policy these micro-segmentation borders for your application. So that web server that would traditionally be able to talk to the application server over whatever port it felt like it, now you can have a rule that basically says only accept traffic from the web server and only accept traffic that's on these ports. So now you've locked it down a little bit more. And if you want to get it a little more complicated, add that defense in depth. You can actually put an additional web application firewall or some other inspection engine between your application servers and your web servers to inspect that traffic as it travels through.
So even if something got through to your web servers, you're now inspecting that traffic a second time to make sure it's traffic that's valid for your application servers and then you can do the same thing with your database servers. And each of those groups of servers is in their own segment in the network so you have that true and clear delineation between the various components of your application. That's something that is relatively easy to do in the cloud and highly recommended. The other thing that I'll say is you can use the native cloud tooling to do some of this, but there are some reasons why you may want to bring your own inspection engine in the form of a network virtualized appliance.
And that could be especially if you're doing multi-cloud. You don't want to have to manage the intricacies of these inspection engines across all the different public clouds. It's much easier to create network virtualized appliances in each of your public clouds and do the traffic inspection there and then have a centralized management console that is managing all of these inspection engines across multiple clouds. That allows you to create clear and consistent policies that are applied the same across all your different clouds. That's another thing to consider when you're doing the security side of things for the public cloud is use the native tooling when it makes sense, but also be aware of the additional administrative burden that you're adding when you do use the native tooling and maybe an existing product that you have in your data center has a virtualized version that you can manage through the same management plane for all of them.
So definitely something to consider. In addition to security, usually the other top thing that people worry about is cost. How much is the public cloud going to cost me and the answer is variable. It's really hard to say sometimes. There's a lot of things that go into the cost. One of them is networking, though. The main thing that you get charged for is egress traffic and that can be a little tricky when you're talking about egress traffic because traditionally you would think okay, egress traffic is just traffic that's leaving the public cloud provider.
So if I'm downloading a whole bunch of files from Azure Blob Storage, that's egress traffic. I'm getting dinged for that. Sure, absolutely true. But you also have to keep in mind that there's egress costs for traffic that goes from one AWS availability zone to the other. So when you're architecting a solution that uses two AWS availability zones, you're getting charged for the traffic that is egressing from one AZ to another. Now I believe that the charge is half the cost of egress traffic leaving the region, but still, if you're replicating a database let's say from one AZ to another, you're getting charged all that replication traffic.
So when you're doing your design, it's important to understand that and think about ways that you can minimize that traffic or at least take it into account when you're planning your egress. That's one way to keep your costs under control. Another thing to consider is CDNs and edge traffic. So when I gave that example before of CloudFront and using that as a on ramp to AWS for anything that's being consumed at the edge, you get the advantage of it riding the backbone.
You also get the advantage of the lowered egress costs because the data is living at that endpoint and being cached there. So there's less data that's traveling across the network from your origin point to that edge point, because it's being cached to that layer and sure you're getting charged for your CloudFront egress data, but it's probably going to be less than if it was all going back to the origin and being pulled from there. So there's ways that you can reduce your costs by properly caching the data in your application in locations that are closer to whoever's consuming that application.
So that's another way to control or at least lower the cost associated with your network charges. Another common cause for charges is that example I gave where data was being moved from AWS to GCP. The data that was egressing from AWS, you were being charged for, because that is egress traffic even though it's going to another cloud, there's no direct connection there. You can set up a site-to-site VPN between the two clouds, sure. But as far as they're concerned, that's egress traffic and you're going to get charged for it.
What's another creative way that you could potentially go about that? Well, you could potentially upload that data to AWS and if you had a direct connect, download it back to your data center at a lowered egress charge and then upload it to Google cloud for AI and ML modeling. And that way instead of transferring the data directly from AWS to GCP, you've used your data center as an intermediary and reduced your cost. Have you increased the amount of bandwidth you're using? Absolutely, 'cause you have to pull that data back down and then upload it somewhere else, but you have to balance that against the costs of moving it directly from one cloud to another.
So there may be an advantage to using your cloud as an intermediary. Another solution that I have seen is to place some sort of data collection point or storage point in something like an Equinix data center that sits right next to the public cloud you're using and rather than pushing the data actually into AWS, or a GCP or Azure, it lives in that storage. And then it's just grabbed by whatever cloud needs that data at that particular time. And again, it's a way to reduce your egress cost if that's the thing that costs you the most money, bearing in mind that there are going to be performance trade offs for that as well as security trade offs and the cost of maintaining that storage device is an additional cost that you need to justify.
The last thing that you need to think about when you're comparing the native security and network constructs within a cloud is what would the costs be if I was running this just using a VM that has a network virtualized appliance format to it. So rather than hosting a firewall, what would happen if instead of hosting the firewall, I used the native firewall tooling. Is that going to reduce my cost, but is it going to increase my operational burden? So there's definitely a trade off there, but it's something to consider.
The last thing I want to go through quickly is deployment consideration. So we have this architecture and now we actually need to deploy and manage that thing. There's a lot of different things to think about here. One is how are you going to manage your IP addresses and DNS across all these different clouds? That is a pretty considerable problem, because each of those clouds has its own internal DNS service and manages its own IP addresses to a certain degree, but you still need to assign a range to them.
So you need some sort of centralized tool just to do that. The next thing is how are you going to deploy this network architecture out and then maintain its configuration ongoing? And there's a whole bunch of good tools that's out there for doing that infrastructurous code deployment as well as the ongoing configuration. So think of tools like Terraform and Ansible that are able to stand up the architecture and then maintain it ongoing from a configuration perspective. Along with those tools, you really need to put in place automation and compliance checking.
There's going to be configuration drift. People are going to go in and manually change things even though they're not supposed to. You need something that can detect configuration drift and set things back to the way they're supposed to be. And also especially when you're doing micro-segmentation, things can get complicated really fast. That's just the nature of public cloud and having these large distributed type environments. The only way to approach it and make sure things are done consistently and repeatably is through automation.
So, make sure whatever tools you selected in the previous option, work really well with automation and hopefully some sort of CICD pipeline deployment model. It's the most common that I've seen for successful organizations so far. And lastly, you really, really need to consider how you're approaching your role-based access and control of the environment. All the different public cloud providers have some sort of identity and access management built in to the provider. But none of them are federated and they all have role-based access control.
Again, none of them are federated so what you really need is to find something that can be the overlay to all these different identity and access management tool sets and provide the correct amount of management for each of the public clouds that you're going to use that makes it very easy to say hey, Jim just came on board or Sally just came on board and she's our new network admin and she needs junior level access in these three clouds. Okay, I go into my management and orchestration piece of software, put that information into there and then it correctly configures all the public cloud providers to give Sally or Jim the right level of access for network changes and control.
So, those are the five different considerations for public cloud networking. Thank you everybody, I'm Ned Bellavance. You can find me on Twitter, I'm Ned1313. com and I'd like to thank Keith Townsend and all the team at CTO Advisor for giving the opportunity to speak today. (swooshing) (modern sounds)
