Multicloud Defense - Deploy AWS Centralized Gateway

Welcome back. If you were here in the last video, we deployed this services VPC within AWS, as well as the transit gateway.00:06That the multi cloud defense gateways once deployed will be able to leverage as like their underlying infrastructure. Again, all of that was handled through the multi cloud defense SaaS controller's orchestration capabilities. Now similarly in this video, we're gonna use those same orchestration capabilities to deploy those EC two instances.00:15Is that are essentially our firewalls, right? We call them gateways within our platform, but for all intents and purposes, they're firewalls.00:35We're gonna use that to deploy the firewalls within your infrastructure, within the customer's infrastructure, so that, you know, from a data sovereignty perspective, everything's staying under the control of the customer within their environment.00:41So, let's take one look again within multi cloud defense. We have this services VPC set up. We can see everything's running, there are NO currently any spoke vpcs attached to it. So what we want to do is we wanna deploy those firewall instances within AWS. Now normally, if, if you're.00:57You know a customer and you're deploying a virtual machine. Typically, you're gonna come within, you know, EC two, you're gonna launch an instance, you know, you're gonna give it a name, you're gonna find out, you know, which version or flavor of OS you want. If you wanted like a custom engine, even like a firepower, like in a Cisco FTD, right?01:17You're gonna look that up and you're gonna select and deploy it as an EC two, you know, image within your account. We handle all of this natively through our SaaS controllers so NO more going to like the marketplace and accepting Eulas and and all that RAS, right? We're gonna go directly in here.01:37We'll go back to infrastructure. Fun fact within this new UI, you can hit the little pin icons here, and it will pin those to your favorites. So I'm gonna go to gateways. We are going to add a gateway, I'll select the account.01:54We'll call this one AWS egress, East two. Now we offer a couple of what we call vertical scaling options, so two, four, and eight virtual CPU. What's nice is our licensing.02:11Does not take any of this into into effect, right? So we don't look at which version of machine you're running and charge you based on that. We charge based on gateway hours. We don't care whether that's a two virtual CPU hour or an eight virtual CPU hour. We, we don't charge differently. The only time you have to.02:26You use one over the other is if you're using the anti malware engine, and that's simply because of the amount of resources that that that engine actually utilizes or VPN. Both of those require the A virtual CPU, but otherwise you can pick two or four depending on what you want.02:46Now those do differ a little bit in terms of like the amount of bandwidth, CPU and memory that they can, they can, handle. So what happens if, you know, for some reason you go over the throughput capabilities of a four virtual CPU? Well remember, we're actually deploying one in each AZ that you.03:06Support so we're, we're actively spraying traffic across those three azs.03:25So if one of those azs happens to get overwhelmed from a traffic or throughput perspective, these two minimum and maximum instances numbers, that's where these start to come into play because these are horizontal auto scaling parameters that the SAS controller uses.03:30So, let's let's take a look at one of these diagrams. Let's say we're in this testing diagram and we've got these two gateways set up and we're we're spraying traffic to them and all of a sudden this top one becomes a little bit overwhelmed, right? From a traffic throughput standpoint.03:47It's constantly sending health checks to our SaaS controller, and the SAS controller has these predefined SLAs for things like throughput, CPU memory, things of that nature. If it sees in those health checks that any of those are being exceeded, and they're roughly 75 %. So let's just let's.04:04Let's pick an easy number here. Let's say this thing has a a gigabit of throughput. It hits 751 mbps for, you know, two, 2 min or more. The SAS controller notices that and says, oh, you know what, this gateway in AZ one is actually in trouble. What horizontal auto scaling parameters does it have? And it'll look at these two numbers.04:24So if the minimum's one, that's gonna be the minimum deployed, but it can scale within that AZ up to a maximum of ten. So what it what the SAS controller would do in that case is it would just blast another gateway within that AZ. Once it had the policies and it passed all the health checks.04:44It would add it to the target group on the load balancer, and that's gonna be, you know, either a gateway load balancer or a public network load balancer depending on the use case, and then we would start spraying traffic to it as well because it's now a member of that target group. Once that traffic condition subsides, again, the SAS controller would be monitoring, it would say alright, you know what?05:02Everything looks to be kind of stabilized. We're gonna go back and scale back into that minimum instance, and it would delete that instance and then remove it from the target group on the load balancer. So again, there is a, a kind of delicate dance there that the SaaS controller is playing.05:22But it handles all of that without any user intervention. So as you deploy, just kind of keep that in mind. That's where these min and maxes come. Now, if we never wanted to auto scale, we could just do one in one. Health check port 65 534I do not recommend changing that. It's a, it's a good default, this is what we're gonna program into these two.05:39Security group.05:59The packet capture profile, log profile, metrics profile, and NTP profile, we will cover all these, but they are exactly that. The the PCAP profile lets us to select certain rules and be able to run pcaps when those rules are hit. And this basically profile allows the gateway to send that PCAP to a.06:00Destination like an S3 bucket.06:20Similarly for like a log profile, if we wanted to offload some logging to Splunk, this would allow us to do that. We will cover that in a lot greater detail in future. Same thing with metrics profiles, you want to send things off to like datadogs or Grafanas, and then NTP as well allows you to sync to custom time clocks.06:22We will select next. Now we're deploying an egress gateway here. There are two distinct gateway types, right? So the egress gateway will actually handle all traffic going from a workload out towards the internet. The egress gateway also handles any east west traffic, so that could be.06:42You know, in this case VPC to VPC, it could be VPC across like an express route or a direct connect to an on prem device. All of those would be treated like East west flows. So that's, that's essentially what we're deploying here. There's also an ingress option. This is gonna be for traffic coming from the internet to a workload.06:59So say you have like within a VPC, a workload hosting a public web server, that reverse proxy gateway would be what we call an ingress gateway, and it's just a different gateway image, so a different EC two virtual machine I guess.07:19That we would deploy within the same VPC, and we will cover deploying the ingress and testing it as well, but in this case we're deploying the egress, the gateway image, unless you're directed otherwise, I would always try to stick with the the recommended release, so in this case it's 2308 17.07:36We can provide blue green updates. We'll talk a little bit more about the gateway infrastructure automation, how, how those upgrades are marshaled here pretty, pretty soon. The policy, so we could create a new one, which is actually what we're gonna do here. There are a couple of sample policies in here that we can mess with, but I wanna, I wanna create a net new one that we can we can play with.07:53The region we're looking at is East two. The VPC or Vnet. So we are gonna look for the infrastructure VPC that we created with our automation. So that was this SE demo AWS East two. So we'll go ahead and select that.08:13Key pair, go ahead and give it the key pair that I use. This gateway and and again this key pair is just essentially anytime you deploy an EC two image, you're deploying a key pair so that they can program that prob public key within that so that you can SSH and whatnot to that without having to use you know username and password. So that's exactly what this is.08:32Used for it. Now, we should never have to SSH directly to that gateway unless something's going on. In that case TAC or, you know, the, the actual SRE engineers would be doing that.08:52The gateway I AM role. This is going to be the, we actually call it the gateway role now, it used to be called the firewall role depending on which version you're using. So this was the, the one that I just deployed to the J load MCD gateway role. And again, this is gonna give the gateway itself I AM permissions so that it can.09:03To do things like access, you know, key stores if it has to S3 buckets, things of that nature.09:23That it needs to communicate with. Now because we're using a VPC that we orchestrated from the SaaS controller, notice the management security group, the data pass security group, all of that has been automatically programmed in here for us, as well as all the instance details for the availability zones including the management and data path.09:28Subnets. Had I gone in and selected a VPC?09:48That was something that I built as a customer that we didn't orchestrate from this controller. These are all details that you have to manually fill in, and these are what we would, you know, quote unquote call prerequisites that have to be in place prior to running through this wizard. But again, because we're using a controller orchestrated services VPC, all of these.09:52Sales were known, so it goes ahead and fills all those in for us.10:12Had we had a NAT gateway or deployed one ourselves, we could disable the public IPs, but by default these gateways will get public IP or elastic IPs. A lot of people are choosing to use the NAT gateways now because Amazon has chosen to start charging for each each elastic IP that.10:17They dish out. So to save a little bit of money, a lot of people are disabling the public IPs and going with the NAT gateway approach. Again, we'll cover that.10:36But we're not going to right now. We'll select next. It kind of gives you all the details. You'll notice down here it's looking at the resources, so again it's looking at these quotas and making sure that everything we're gonna deploy will fall within the limits of those quotas. If anything was gonna be exceeded, it would tell us here and we'd have a warning, we could go.10:44Asked for, you know, a quota increase and then we could come back and deploy this.11:04So a lot of things like global accelerator, I I will dedicate a video to that in the future. We do have the the ability to integrate with a global accelerator, and that solves a couple problems that you will see kind of exposed as we go through these with regards to just the public network load balancer that we deploy by default.11:09So I'm gonna go ahead and click finish here. It will say creating the multi cloud defense gateways successfully created. It was not that fast though. What you'll see is it does take a while for these to come in, because we have three availability zones, we're saying 1 min at a minimum.11:29Per availability zone, what we'll see within our account is three different gateways being instantiated. So right now there's, there's nothing under this instances. One of the things I like to urge customers to do as these are deploying, if you click on this little bell icon up here.11:49And click view all. You will get all of the alerts as they're coming into the system. As new ones come in, you'll see a little red icon next to this refresh. But you could sit here and kind of watch, make sure if anything's gonna go wrong, it's gonna be exposed in these system logs, so we can kind of watch those if anything from a permissions perspective is a little bit off, it'll show up.12:06In here. Okay, so it's been probably about 8 min now, and we can see if I'm looking at the gateway line item that we have three running instances, the state is active, policy rule status, meaning the policy that is within the rule set, we, we attach these gateways.12:26Is synced with the device and then we're running 2308 17 egress east, west, and hub mode. So we can look at the details of these and it usually starts off, I must have clicked on instances a minute ago, but the summary screen is gonna give you a summary.12:45Three of all the, you know, the different VPC endpoints that we're using from a gateway load balancer perspective, the load balancer ID, name, image that we're pulling. So if we go through these tabs, we can see, you know, cloud details is going to be the accounts, the aazs, and then the firewall.13:04Role that we attached. Interfaces is merely, you know, the, the network semantics. This is really where I spend most my time as the instances tab. We can see the number of instances that we've deployed in each AZ, and you can see all of the details. So every one of them now is showing active. We can see, you know, the last heartbeat too.13:23The SAS controller, the policy that's applied. You can see all of the public and private IP associations to these gateways, everything looks to be in place, they're all active.13:43Once you start attaching different policies and different profiles, you'll start seeing sections show up under this policy updates. Right now it's pretty simple, we have address groups and connections lists, and as you can see, if I kind of highlight over these.13:54You can see the update status, so basically are they synced currently with the device? This is a nice place to come when you're doing like large policy changes to see which one is hanging up like is it IPS IDS that's taking a long time? Is it maybe the anti malware agent updates?14:09I really like this view. Settings is going to, again, these are some kind of custom settings that you have. There are some options if you work with like tack on any like maybe specialized timeout values, those will show up under the settings tab.14:25Troubleshooting allows you to go in and troubleshoot, right? So it'll allow you to look at the, again, VPCV net details, the management, security group, inbound, outbound details, all of that's within here, and then terraform export. So again, you have the ability to export and utilize the Terraform from the.14:42Gateways directly. Another thing I will mention, if you're ever asked to send, you know, the diag or diagnostics to TAC, you can click this button up here. Send diagnostics will send diagnostics to, you know, through a back end connection to Cisco TAC.15:02They will be able to reach into the S3 bucket where we dump those and grab that diagnostic bundle out of there for you. So it looks like the gateway's deployed from within multi cloud defense. Let's look at what happened within AWS. So I don't even have to refresh here, but I will. We can see that we've got three gateways deployed.15:20I always get asked about the name, so I'll go ahead and just address it here. This is the name of the services.15:39Actually, that's not the services VPC. This is the name that we gave the gateway during the wizard, which was Cisco MCD, AWS egress East two, and then a random string of characters that will ensure that these are unique within AWS. So that's what this kind of grouping of of characters is at the end.15:47And I always get asked about it. We really have NO control. It's just a way where we can make the different gateway instances actually unique.16:07We can see they're in azs, A B, and C You can see all the details around them. I mentioned in the last video the security group. Let's check that out and make sure that it did provision the data pass security group with those additional rules. So we'll say MCD.16:13We'll check that box. Oops, MCD. We'll look at the data path, and yeah, we could see the inbound rules that dynamically went ahead and created UDP 6081 from a source, this is our our services VPC source cause basically we're expecting.16:32Getting these to come in from the gateway load balancer.16:51So that gateway load balancer was placed in the same services VPC subnet as the gateways themselves, but we now have these security group inbound rules on the data path subnet that are applied. If we go back to EC two, we can see the last component of this deployment, which was the load balancer.16:55So, for the egress gateway, it actually deployed a gateway load balancer. So if I look and check this box here, we can see it is a, a gateway load balancer. We can see that it deployed essentially three gateway load balancer endpoints in these azs.17:15So we see it's attached to AZ one two and three. We can see, you know, the VPC, we can look at the different listeners that it has, so it's forwarding to this target group. We'll pivot to that. And again, should be NO surprise here, but you're, you can see the Geneve tunnel that it's connected to our.17:33Gateways again, you didn't have to do any configuration. The controller handled all of that, but it's using all three of those registered targets to spray traffic against.17:53And if we continue to look through the network mapping, we'll see the subnets that it was assigned to. You can actually go in, I thought there was a place here. Yeah, the VPC private endpoint service, we could see the services ID, the VPC services endpoints.18:02That are being used. So again, everything was set up. This guy's using three different azs. So the VPC services endpoints that are associated to that. Again, all of this is typically infrastructure things that customers have to take on their own plate. And if you don't have a lot of underlying knowledge.18:21Knowledge of how everything pins together with AWS.18:41That can be very cumbersome. So we've handled all of this through our controller orchestration so that you don't have to. And we also, you know, just to boot, right, we're multi cloud solutions, so we do this consistently across multiple cloud providers. Now, not every cloud provider, you know, Azure doesn't have a gateway load balancer. So we address.18:44Sit in a different way within Azure.19:04But again, we do it very consistently within the constraints that the cloud service provider is handing to us. So with all that said, we now have actual EC two instances deployed that are our firewalls within that services VPC. So if we look back at our testing architecture essentially, and let me kind of delete.19:06Get these lines here because these aren't, these aren't attached yet, right? We have deployed everything that you see right here, including the internet gateway that they're attached to. So these guys, these gateways are actively sending health checks out to the SAS controller. Everything is looking good.19:26So in the next video, what we're gonna do is we will actually connect the spoke vpcs to the transit gateway. We'll modify their underlying route tables to move the default route through the transit gateway and subsequently through multi cloud defenses egress gateways, and we will test some.19:44Basic internet connectivity from those boxes. As always, if you found this video useful, keep a key eye on this channel as we will be releasing more and more content around the deployment and uses of multi cloud defense and how you can use it to protect your cloud infrastructure. Thank you for watching, we look forward to seeing you in the next video.20:05