[MUSIC] Hi everyone, this is Warby Warburton I'm a Technical Marketing Engineering Manager here at paloalto Networks. And I want to talk today about our solution called GlobalProtect. Specifically, I want to talk about how we can leverage the public cloud to make our GlobalProtect solution even more compelling. So in this example, let's talk about a large enterprise. They have employees all over the world with a large regional headquarters office, for example, maybe on the West Coast United States, but the employees are all over the world. They need to get to those corporate resources as well as to resources local to where they're actually connecting from. So I'll draw a pair of large firewalls at the corporate data center and I'm going to do some racks and racks of servers at this location and we'll add in panorama just to make things interesting so we can manage everything centrally. So if we have users sitting out, let's say, on the East Coast, And we've got some remote devices as well. But as well as maybe there's users here in Europe, Asia pack all over the world. So in a traditional model, we might have all these users remotely connect back to their corporate data center to get things like email. It's not very efficient if we want to use something like GlobalProtect where we want to actually inspect all of their traffic. So the other option is now we have regional data centers or regional colo space where we can deploy GlobalProtect closer to them. That becomes a very costly proposition to actually have physical infrastructure all over the world wherever your users might be. And that might shift and it's hard to keep up with that shift. As well, is also very difficult to scale as the need changes as different events happen. So what we would like to do is use the public cloud, which already has a global presence as well as our GlobalProtect solution on top of that, using our VM series or virtual firewall to get the best of both worlds. So in this case let's put some firewalls in the AWS public cloud, Wherever we have users. So now we have an infrastructure that's worldwide and as the users connect, they connect to the closest location for GlobalProtect when they're going to the Internet at that location, they can go directly to the resource they want. So for example, this user in Europe, they build the tunnel to the GlobalProtect gateway near them, they get to local resources that are Internet bound, but they can use the VPN tunnels back to corporate to get to all the corporate resources. So now we have a better user experience, we can get the best balance of performance between local and remote traffic back to corporate. And we can quickly spin up infrastructure in the AWS public cloud where we don't have to ship physical equipment. We don't have to wait for colo agreement and and hooking up hardware we can deploy in hours instead of weeks. So the other thing we can do with this global infrastructure by leveraging the public cloud is not only can we do faster deployments, but we can also scale as the need changes on demand. So if there's a snowstorm on the East Coast and a lot of users are suddenly working from home, we can actually respond to that in real time by scaling up the GlobalProtect infrastructure at that location. Equally as importantly when the event is resolved and the users are disconnecting and the traffic has dropped off, we can scale back down so we're not paying for that infrastructure when we don't need that. And we can create alarms that actually monitor the health and the sessions on these firewalls and automatically kick off new firewalls, running GlobalProtect, pre configured, using our usage based licensing in the AWS cloud. Okay, now I'm going to show some of the details of what AWS calls a virtual private cloud or a VPC and specifically how we leverage their redundancy and their auto scaling functionality to make our GlobalProtect solution scale as needed. Okay, so I have here a virtual private cloud in AWS, I have two availability zones in this case AZ1 and 2. And this gives me redundancy within this specific region in AWS. And so as my minimum footprint for my GlobalProtect solution, I have a VM series, virtual paloalto Network's firewall in each availability zone. So what I'm going to do is I'm going to collect metrics about the utilization of that firewall. AWS is able to monitor natively things like CPU and RAM usage of all the instances, including our virtual firewall running within a VPC. What I can also do is using our API I can collect metrics that are specific to PNLOS for example, number of sessions. And I can publish that as a what's called a custom metric to the AWS service called CloudWatch. Based on these native and custom metrics, I can make decisions about when to launch new virtual firewalls as well as when to remove unneeded ones. So what that looks like is we're going to get a peek in spike in demand, meaning lots of new sessions but lots of users connecting either because it's a time of day difference or there's some maybe a conference in town in that region and we have a lot of employees congregating at a point, all needing that region to scale up. So in this case we had a spike in demand. Maybe there was a conference in the region and there was a lot of employees from one specific location or some kind of weather event where a lot of people had to suddenly work remotely. And we've spun up new firewalls on demand using a combination of built in and custom metrics in the AWS cloud. So we call these autoscaling groups. And this lets us scale or define a group of firewalls that will scale, and we can set things like the minimum and the maximum, how conservative we want to be, do we want to be more responsive or more cost conscientious? And conversely, when the activity has died down, the weather is cleared up, or the end of the day and there aren't as many users because we're paying on demand for these resources. We can also remove those resources on demand and stop paying for those resources. So in this example, let's say three firewalls are going to be fine for the next few hours. So let's get rid of the unneeded firewalls. We stopped paying the per hour cost for those and we've really tuned our infrastructure to real time needs of the actual employees. So in addition, we can leverage Panorama to not only push central policy to all these firewalls that are coming up and down on demand, we can also send the logs from all those firewalls centrally to Panorama. So that we actually can see in a single point the entire infrastructure, what its behavior is, what users are experiencing and what threats, if anything that we're seeing as we enforce our policy. So now the same Panorama that's managing the physical firewalls at your local private data center is also managing this entire global infrastructure, including pushing some common elements like dynamic address groups where relevant. So next up, I'd like to show you a demo of an actual scaling event where we've built this infrastructure in AWS, we have GlobalProtect portal and gateway and we're actually going to connect to it, trigger an alarm, Watch AWS automatically scale up the firewalls and you can see what the entire solution looks like in a live demo. >> Okay, so in this case we're looking at a VPC running in an AWS region with two availability zones, one GlobalProtect gateway per AZ with an IPSEC tunnel, going back to the corporate firewalls for corporate destined traffic. What we want to do is look at what happens when there's a spike in demand. So lots of sessions, lots of users connecting to these gateways. We need to be able to respond automatically by creating new GlobalProtect gateways at the time they're needed. Conversely, when the demand drops off, we also want to delete the gateways that are no longer needed, so we're not paying for compute and capacity at a time when we don't require it. Here's what the solution looks like. We have the Auto Scale Group on the left where the GlobalProtect gateways will dynamically scale up and down. And the portal on the right where the gateways will be registered and unregistered as needed. And we're going to use a simple queuing service and CloudWatch service from AWS and we're going to create a worker note called the security controller that ties it all together using a combination of Panama, APIs and AWS APIs. Here's the view initially in the AWS console, the EC2 console, we have the Gateway, the portal, and the security controller. So initially these are the only instances running in the solution. And if we come over here to the GlobalProtect gateway, rather the GlobalProtect portal, we can see the initial gateway and these are named based on AWS and my IDs. So we're starting with just one Gateway and one portal. Next we're going to use the panel S API to collect metrics about the health and status of the portal and share that to CloudWatch. So if we come back to the console and we're looking at the CloudWatch, we have panelists custom metrics. So these are the metrics that the security controller is pulling for and sharing with CloudWatch. And we can look at historical data. So here we look at a few days of data and we can see spikes in demand. And next we'll look at what happens in real time. So we're going to simulate a spike in demand by creating lots of sessions on the existing Gateway, which should trigger an alarm. So if we go back to the CloudWatch console view, we can see the current chart and the scale on the left is 25 sessions max. So we just got an alarm, if we do a refresh now the skills 100 and we set the skill well below 100. So that triggered an alarm that's going to be shared with the Auto Scaling Group. And in the Auto Scaling Group view, We can see there's a new event. So that spike in demand has triggered an event in the Auto Scale Group. So CloudWatch has shared that alarm with the Auto Scaling Group and the Auto Scaling Group took action which was to spawn a new firewall. So returning to the EC2 view, We can see there are now four running instances. So we now have to GlobalProtect gateway firewalls. And instance ID ends in 343. So this is the brand new firewall that's initializing. ASG has pushed an event to the SQS, a Simple Queuing Service, the security controllers monitoring that event and now knows there's a new firewall, it's going to configure that new firewall and it's also going to register that new firewall as a GP gateway in the GP portal. So if we return to the GlobalProtect portal and look at the client config we now see there's a new gateway. Again the ID ending in 343. So this is a brand, the brand new gateway has already been registered to the portal automatically. So now when new clients get the latest list of gateways from the portal, they're aware of the new gateway and they automatically start connecting to it and using the increased capacity. If we look next at the client view and we will manually re trigger a refresh of gateways, this will happen automatically after a time out. We know we connect to an available gateway but we'll also see the updated list of available gateways in the GlobalProtect agent. So we've connected to the original one but we see there's also the 343 gateway available, so the client learns about it and new clients potentially will connect to that as well. So we've increased the capacity on demand. So all the steps have been automated, no action was required. We can monitor it, we can manage all the gateways and portal from Panorama if we choose, it's optional, but advantageous to do so. >> Thank you very much for watching, if you want more information about our public cloud integration or our GlobalProtect solution, check out our other videos on our Youtube channel and have a very nice day. Thank you.
