Enterprise DevOps & Cloud Infrastructure

Configuring an AWS Network

Erik Reinert

Erik Reinert

Enterprise DevOps & Cloud Infrastructure

Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Configuring an AWS Network" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik configures an AWS network automation. The configuration code is copied from the example repo, and the options are discussed including subnet address space calculations and the organization of variables.


Transcript from the "Configuring an AWS Network" Lesson

>> So again, we have two new repos, one for network and one for cluster. I'm gonna preface really quickly with what we're about to do with saying, I do not expect you guys at all to understand that interest cities of an Amazon network. So we're going to basically just make a network that I kind of already configured for you.

I'm not gonna go deep into what it is, I'll let you guys look at the resources later to understand it. But basically just know that we are going to create a pretty standardized enterprise Amazon network, okay? So now that we have that-
>> By the way, I'll just mention we have a course on Frontend Masters, AWS for front-end engineers.

>> Perfect.
>> There's a lot of-
>> Be sure to check out the course on AWS front-end engineers. It's a good one, it'll help you out. I didn't know that, that was there, that's awesome. Okay, cool. So what we wanna do now really, is we wanna clone those repos because we wanna start making automation.

So I'm gonna say, gh pr or gh clone, or, repo clone. And for me, mine are gonna be AWS network, And AWS cluster. So now I have four automation repos, right? Cool, okay. So let's go into network, okay? Now, I highly, highly, highly recommend every single one of you going to the network repo, so let's go to the network repo together.

AWS network. And I'm gonna click on the branch setup AWS automation. And you'll notice that this is the only branch in this repo. This is because we only need to set up the network once, [LAUGH] you know what I mean? And we're just gonna keep making networks this way.

Make a file for each of these locally, just do that for me. So, go to the locals file, copy that new file, locals.tf, paste it in. I'll explain it all in a second, but let's just get all the code in here so that we save time. So we're gonna go to main.

I'm gonna click the copy button right here, name file main.tf. Paste it, close it, right? Go to the next one. Security group, copy it, name file security_group.tf Paste it in, right? Variables, copy it. Paste it in, okay? So we should have four files, locals, main, security group, and variables, okay?

Now, while you guys do that, I'm going to explain what you're looking at. So we always want configuration. Always, always. Even if it may seem that there's nothing that you can configure, try and at least identify something that might make your life easier. One of the most challenging parts of creating infrastructure and networking in specific is understanding how to separate IP addresses and IP spacing.

This is one of the reasons why I'm doing this for you. What I have done is I have essentially created an enterprise network in Amazon for you, which includes a database network with a specific amount of IP address space. It includes an elastic cash network with a subset of address space.

It has an intra network or an intra subnet, sorry, these are all subnets. Intra subnet with an address space, private and public. So what a lot of this does is it leans on the idea that you might need databases in the future, you might need caching in the future.

You might need completely isolated resources in the future, you might need a private network in the future, and you might need a public network in the future, okay? We're not gonna use all of these subnets but they're there for you to experiment with and, take a look at as you want.

The next file is our main.tf, this thing's huge. [LAUGH] Well, it's actually not huge but it's got a decent amount of stuff in here. If you are curious as to how I am able to calculate via bits, [LAUGH] the address spaces of subnets, I'm not. I'm using a very nice module to do that for me which is the subnets hashicorp module.

Now you might be like, well does that mean that it's gonna create the subnets? Actually no. [LAUGH] It's a module literally just there for computation, that's it. And you can do that with Terraform. If you wanted to, you could have a repository that just does computations for you, and then you can reuse that module in other places so that it will do those computations for you.

In this case, what we're really doing is we're essentially saying, okay, I wanna use the module subnets, I'm gonna give it a base cidr_block, right? And then every network, I'm gonna do a little bit of four for four here, and it's going go through my configuration in local subnets and azs.

Now, why do I have subnets local, but I have azs in vars? Can anyone guess why I might have my availability zone in vars but my subnets locally?
>> Because your availability changes more often than your subnets?
>> Exactly, yeah. So the idea is that whenever you create an availability zone going forward, it's gonna take an exact copy of the subnet or all the subnets in these availability zones and put it in this one, right?

So then you'll have elastic cache in a and b, but then later on maybe you go, man, I really wish we had c as well. Well, do you want to go in and update all of that automation? No, what we can do, and we can go to our next file, is in our variables file, we can make it so that we can really manipulate our networks when we want to.

So say if in the future I wanna go from 1AZ to 4, it's one code change, right? Now you'll notice I don't have defaults here, there's a reason for that and I'm gonna show it to you in a second. But don't put the defaults in, do not put anything in here, right?

We're simply telling Terraform we want these externally configurable. Anything else in the main is really just all related to the network creation itself, you can look at that logic and get an idea of how I did it. But just to note, as you used my modules, right? There are also as I mentioned before official Amazon modules that can help.

My modules are wrapped modules that do not have existing code, essentially. So I don't recommend going out and creating automation modules you don't need. You know there's 1,000s of developers in the world who are willing to help and there's great repositories out there that can help you get there quicker.

And honestly, I do think the module for vpc is really good. As you see, it's got the things we care about zass, cidr, or database subnets. It's just calculating these for me to make it a little easier. Cool, okay, so we've got our main.tf, our security group. If you've ever used Amazon before, this is all security group stuff, I basically wired this up for you.

So that if you do wanna play around and provision a database on a specific subnet, you can still access it and stuff. So take a look at that later, you're more than welcome to. And again, the last one is variables, okay? Now one of the things we're gonna wanna do is we're gonna wanna to init.

So we're gonna do terraform init. Now again, you don't need Doppler here because there's no back end and this is actually going to be a reusable module, so we're never gonna connect this directly to Terraform. This is not a one to one repo, I'll explain why in a second, so let's keep moving.

But do an init for me and then do a validate. If you init and validate fine, you should be good to go. I'll give you guys a second to catch up on that cuz we're actually moving pretty quick now.
>> So not changing to a different branch wouldn't have been a problem?

>> It would not be a problem, no, we're gonna change your branch in a second, yeah, yeah.
>> I'm noticing now that you're still in main-
>> Mean, yeah.
>> As well, so I did not mess up.
>> Good catch, good catch. That's good, you're getting the rhythm now.

And that's important. That's important. So, as mentioned, we are still on main, if you notice, in my repo, right? So I do wanna quickly check out a branch. And in this case, we'll say add-resources or something like that, the name doesn't matter, right? But we are just gonna create a nice little branch.

And then I'm gonna do git status, git add, locals, main, security_group, and variables. Again, we don't ever really need to add the terraform.lock, it's up to you if you wanna do it. I'm gonna hit enter, git status, and then git commit- m, feat: added network resources. Great, I'm gonna push it up.

Wait, no, this was just add-resources, sorry. Okay, so now we're gonna create a PR, right? We're gonna follow the same process we did with the other repos. So again, I did ghpr create, gave it a title, which it might auto-populate for you. If it does, then that's awesome.

Or, again, you can go to GitHub itself. And then I'm gonna go to the PR. So now I'm in my PR, and at this point really you should give this to someone else there's so much stuff in here you don't wanna do this on your own. So I'd recommend going to a teammate, saying, hey, can I get an approval?

I just made an entire network, can you please look at it and let me know it looks good? So then somebody approves it, check, check, check, all looks good. Great, okay, cool. Let's go ahead and merge it in. So we'll go here, and we'll go Squash and Merge.

Yeah, did you have a question? Okay, no.
>> I had to say squash.
>> Got you, yeah. Squash, cool. So what did we just do? Well, we know we want an Amazon network, but we actually know we want a lot of Amazon networks. So why didn't we go to workspaces and [SOUND]?

Well, because this is kind of like a many-to-many scenario. Where we know that we wanna create a lot of networks, right? So let's get the automation in place to where we can make this network as dynamic as we want, right? AZs, all the other things that we added, right, CIDR, all of that.

And then we're gonna do the exact same thing for the cluster. So we're basically setting up these resources before we connect them to Terraform Cloud, right? So realistically, if you wanted, you could do like a local plan and apply with your AWS credentials, and you could actually create a network locally, right?

But we don't wanna do that. We don't wanna create it locally, however GitOps is our source of truth, right? So if GitOps is our source of truth then the repo has got to be there first before we tell the workspaces to start synchronizing.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now