Networking components - Amazon Web Services (AWS) Tutorial

- [Instructor] Let's now talk about the required infrastructure to run our project. We're looking at app_dev.py which is the entry point to our CDK project, and right away line six and seven you can see development deployment and also production deployment. What I like to do is create my own entry points and not use just app_dev.py as my entry point cause in this case I'm able to create separate files going into separate environments, in this case development and production. Let me show you what one of these is going to look like. This is development. The first thing I do is I set a value, line 14, to make sure to set environment name to dev. So if I go down here, you'll see that I'm creating various stacks which you can see line 21, line 26, and line 32 right here. And each one of those is going to be using that variable. It's going to be using m_name. What that's going to do is whenever I run any of these, they're going to be populated with the word dev in their name. So actually let me show you. I'll just type cdk ls to see the available list of stacks. And in this case we should see both development and production. So for example, EC2 IM profile dev and EC2 IM profile prod. The same for networking. So again, you have this flexibility. Let's say for example that in the prod class you need to include encryption at rest or encryption in transit. You can do it here without having to include it in development as well. We're not going to be building a production environment, but I wanted to show you that you have this flexibility in case you wanted to do so. Moving on to CDK.json. As you know, this file contains settings created and managed by the CDK, and that's fine, but if you looked here at the bottom, I included my own settings, and there's nothing wrong with that. This is actually a good convenience and practice that you can have. This is WP config dev and WP config prod. I can have various settings. In here for example, I have the vpc.cidr, availability sense, public subnets and private subnets. Any values that you need to distinguish between one environment or the other, you can set them here. Finally, moving over to network.py, which is where we're actually building the network components. Right away you'll notice on line 10 that I'm using environment name, so whether this is called from dev or prod, this will be reflected here. You can also notice that I'm pulling CDK.json on lines 12 and 13. The reason why is because in this case, let's say for example line 18, I'm actually pulling the vpc_cidrs from that file. Let me show you again. This is cdk.json, and I have a vpc.cidr value for dev. In this case the same as production 10.13.0.0/16. You can see it here in line 41 and line 50. Back to our code, again, of course these values could be different depending on your needs, but know that you can put them there in the cdk.json and then pull them here. Moving on from there, line 19 now, I'm setting the maximum availability zones to two and then some other required BPC settings. I'm also creating a set of public subnets and also private subnets with NAT gateway attached. Keep in mind, I'm setting NAT gateways to one. You can see that here on line 34, the reason why is because I declare two availability zones on line 19, and if I don't specify the number of NAT gateways, it's going to create two. And then this infrastructure is going to get expensive, and I don't need redundancy for NAT gateways at this time, especially if I'm building this just for practice purposes. So make sure to set them to one, which is done right here in line 34. And finally, the last component that we're creating here is an ECS cluster. In this case, we're going to be doing a fargate cluster, and we just call these ECS cluster functionality and passing the name of the vpc. And that should do it for our required network infrastructure for our project.