I welcome back. Today I want to talk about how we can deploy and orchestrate the underlying infrastructure from Cisco multi cloud defense within an AWS account. So a little background here and.00:02Just to be clear, one of the great things about multi cloud defense is that it can help standardize.00:20An architecture, security architecture across multiple cloud providers. So here we're just kind of showing, you know, from a SaaS controller, we can actually control and manage security across, you know, really the big four, right? Azure, AWS, Google Cloud, and Oracle. But what we also do really well is we help.00:26Ease the burden of creating that infrastructure that a firewall or a virtual machine would have to reside upon and we can orchestrate what we call a services VPC very consistently across all of these different providers. So that means creating like, you know, the VPC or vnet creating the underlying.00:45Subnets, the route tables, all of that can be handled from the multi cloud defense controllers orchestration. Now, that said, we do also have the ability to deliver our gateways or our firewalls directly on top of infrastructure that maybe you provide. Maybe you're already using your Terraform for the AWS provider and you're like, hey.01:05You know what, we already deploy all our infrastructure in a very standardized method. Can you just deploy your gateways on top of that? And the answers are resounding yes. We can deploy the gateways pretty much anywhere as long as the little couple prerequisites are met.01:25But we for, you know, the customer who don't currently handle any of the underlying infrastructure or maybe just don't know enough about that specific provider to do it consistently, we can provide the orchestration capabilities for you. So what we're gonna do today within AWS.01:37Is based around this topology, so everything to, you know, basically to the right of this transit gateway exists today. So I've got a spoke VPC up here called test spoke one, another one called test spoke two. They both have a basic, you know, AWS workload in them. They both currently just access the internet directly. So if I, if I actually modify the.01:55Program a little bit. We'll kind of put this internet over here. Right now, all of these workloads are just.02:15Going out to the internet directly through their attached internet gateway. And, and we'll show that access today. We'll kind of prove out that they're using their public IPs. But what we wanna do is we wanna start protecting them with multi cloud defense. So the 1st step of that is to really create.02:20The infrastructure that will support the multi cloud defense virtual machines or EC two instances in this case that we're gonna deploy. So what I really want to drive home in this video is how we can deploy this infrastructure, basically all of this stuff that the multi cloud defense gateways will reside upon once we deploy them.02:37Again from our SAS controller. So let's go through and just do a little validation within AWS of, of what's out there.02:57Go back a couple of screens here. The two vpcs were primarily concerned with here this test spoke one and test spoke two. Both are are very similar, so if we look at, actually look at test spoke one because it's got a pretty good POC tip in it. As you go to test multi cloud defense and want to like.03:06Maintain connectivity to your EC two instances.03:25So we'll go into this routing table and I'm gonna obscure my public IP, but this bottom line going out the internet gateway is my home public IP. And I put this in here because when we, we do transition traffic through multi cloud defense, that would kill my SSH session that I'm testing with. So in order to retain that connectivity I just.03:29It's kind of hanky, but I I put my, my home IP in here and I say, hey.03:49Anything destined with this home IP, we're gonna go through the the internet gateway. That way when we move this default route to a transit gateway, it doesn't affect my connectivity to that testing box. So, again, the other, the other VPC in its subsequent route table looks very, very similar.03:53And then from an EC two perspective, we're really gonna be using the spoke test Linux which is in that VPC one and this one that is in VPC two. So what I want to do really quick is try to connect to this and just validate. So I'll bring up.04:09My window here again, and we will, you can see I'm just SSH into that public IP of this box. We'll hit enter here, and we can see I'm in there. One of the mechanisms I like to use to test these is just a simple curl command, so if I, if I curl I can has.04:26IP.com. We should get back the IP address that that we're connected to on the public side and we do see that those two correlate. So everything there looks looks pretty good. So what we wanna do next is really just deploy the infrastructure and go through those steps.04:46Within multi cloud defense, to deploy the vpcs, to deploy the transit gateways if necessary, the NAT gateways if necessary. So I'm going to go back into the multi cloud defense controller here, which, which timed out, which is ok, it's a security precaution, right?05:04And then I, there's two ways you can do this, right? You can go through the setup wizard. This 3rd step here will take you through and it will create basically we could do centralized, which is where we want to orchestrate all the, the vpcs and subnets or distributed where maybe you're providing those vpcs and subnets for us to put the gateways on.05:22I like to show this. It works very, very well. It's a very simple wizard, but we can get the same wizard through this infrastructure and service VPC vnet section. So I do like to show both methods. Either one works, it's gonna give you the same result in the end. But what I wanna do is click create here.05:41We're gonna give this a name, so I'm gonna call this, you know, SE demo, AWS. I believe this is East two. Let's validate that. So we do typically provide, you know, regional protection, so this is US East two. CSP accounts gonna be the only one I have in here. So the AWS SE demo.06:00My region is gonna be in East two and I like to I like to type it out because it'll filter that, that huge list for you. And then we get, again, this is, this is where everything's kind of driven by the context that we're presenting to this wizard. So we told it East two, so our controller actually went out and said alright, which availability zones are within the east?06:20Two, and which ones do you want to use?06:40What's nice about this and what differentiates us from a lot of other vendors is that if I start selecting these, we are gonna deploy or we're basically telling the system that we intend to deploy active active active gateways. So gateways that are active in each of these availability zones, and and AWS does a really good job at trying to maintain zone.06:43For flows, meaning if you have a resource of workload in US East two A and then you have a firewall in US East two A.07:03AWS is gonna do its best to keep that traffic flow pinned within that availability zone so it's not having to go to these disparate data centers. It makes it from a latency perspective a little bit more attractive. So I'm gonna go ahead and leave all three. I'm gonna give it a cider block. I can't exactly remember, so it looks like I did.07:12101-821-0183. So we'll make this 110184, just, just to be consistent. So we'll say 10.184.0.0, and you could do a 24. I'm gonna go ahead and do like a.07:30Yeah, I'll just do a 204I believe it should be good even with three availability zones. If it's not, we'll go back and give it a little bit more space. Network type, this is how, how do we want to get traffic between the multi cloud defense VPC and the spoke vpcs. So our our traditional option is gonna be by transit gateway.07:46Cloudwan, which we'll cover in another video was added very recently. So I'm gonna go with the more traditional approach with the transit gateway.08:06I'm gonna say, hey, create me a new transit gateway since none obviously exists right now or they'd show up in that list. We can give it a name, so we'll call this, you know, SE demo AWS East two TGW. I'm gonna put my, my name at the end of this.08:14So other people using this environment know it's me. And then we can auto accept shared attachments from that gateway, meaning if somebody or another, you know, multi, another account actually wants to attach this, we could, we could allow that by default, so we're gonna select that, and then the NAT gateway, I'm actually gonna cover the NAT gateway.08:33In another video, so I'm gonna leave this blank right now, but this is a way that we could privatize, meaning not give these gateways that we're gonna deploy public IPs within this environment and instead kind of obscure them behind a nat gateway.08:53But I'm gonna leave that unchecked for now and we're gonna click save. So what it's gonna do, it's gonna validate a few things, make sure that we have enough resource quota limitations within that VPC, and then if everything passes, we can see the service VPC or vnet depending on which provider you're using has created successfully.09:06And through the magic of video editing, we are back. We can see that this deployed, it is currently in an active state. You can look at some of the details, right? Through clicking on the name of the device, it brings up all the core corresponding details, what availability zones.09:25If we had any spoke vpcs currently routing through this, they would show up in this list here. We'll show that later. Another tidbit is anything you do through our UI, you can get the corresponding Terraform output for. So the service VPC, if you wanted to do the exact same thing using Terraform.09:45All of that would be right here. Again, we're gonna deep dive into Terraform in a later video, but this is a very easy way to get into using Terraform around multi cloud defense infrastructure. So with this active, what actually happened?10:00Within AWS. Let's go take a look. So I will close out some of these just to clean up. I get little OCD, but right now it was one of five. I'll refresh that. We see now one of six. So what happened is we created.10:16This service VPC SE demo AWS East two. We have the VPC ID, it's using the ten.one 80 four.00/ 24 address space that we assigned it. If we look at the resource map, there's a lot going on.10:31So, from a subnet perspective, we deployed subnets in each of the three availability zones that we selected previously. We can see there is a management subnet. So this is going to be used for the management interfaces of those multi cloud defense gateways, the data path subnet, this is where the actual data will.10:48Ingress and egress these gateways. The NAT ingress and egress subnets, I actually.11:08As an engineer I don't like the name of these, but think of these as the landing zones for the transit gateway attachments and the gateway load balancer endpoints. So each of these availability zones has those corresponding subnets attached to them. They all correlate to a route table that each of these all.11:13So uses. We'll talk a little bit more about those as we start to deploy the gateways and showcase the routing.11:33But what else happened within here? We actually went in, we created some security groups, so you'll see if I look for MCD, we'll see the two security groups that were created, the SE demo AW East management and data path security groups. These are gonna be attached.11:40Directly to the gateways.12:00They're pretty simple right now, so if we look at, so this is the management one, by default, we are not gonna allow anything into the management interface, not SSH, not anything. But outbound, we do allow traffic to go out so that that management interface can continue to send the heartbeats, the health checks.12:02Things of that nature to the SAS controller. The data path is a little bit different, but still it's pretty simple. So outbound, we, we, again, we allow all. Inbound on the data path right now is empty, but you'll see once we deploy the gateways, we'll come back and validate this.12:22That we allow UDP 6081 for the Geneve tunneling and we allow 65 05:34 TCP for the health checks from the gateway load balancer. But that all will get provisioned on the fly as we deploy the multi cloud defense gateways.12:40Into this infrastructure. No EC two instances were deployed. Transit gateway would have been deployed, so let's take a look. We'll look at transit gateways. We'll see a couple deleted in here that I cleaned up earlier, but this one, the SE demo AWS East two transit gateway, this.12:55Is now sitting here waiting for us to attach the spoke vpcs to it.13:15We should have a transit gateway attachment for this SE demo and we do. So it is currently attached. Again, everything at this point is pretty basic though because we haven't onboarded any spokes into the solution, nor have we deployed the gateways on top of this infrastructure. But in the next video, that's exactly what we're gonna do. We are going.13:21Going to deploy the multi cloud defense gateways within the centralized AWS services VPC.13:41And hopefully we can start routing some traffic through. 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.13:46
