Deployment and Provisioning
In this group of lectures we run a hands on deployment of the next iteration of the Pizza Time solution. The Pizza Time business has been a success. It needs to support more customers and wants to expand to meet a global market.
We define our new solution, then walk through a hands on deployment that extends our scalability, availability and fault tolerance.
Hi and welcome to this lecture.
In this lecture we are going to do the VPC deployment. I will start by showing you the proposed architecture. And then we are going to have a demo on how to deploy a VPC.
So, this is the proposed architecture. I will take advantage of the Oregon and some other regions. Both of these regions have three of the availability zones. So, I'll take advantage of all three availability zones. And inside these availability zones, I will create one public subnet on each of the availability zone, and one private subnet on each availability zone.
And remember that what makes a subnet public or private is the route table. So, if you have a public subnet, this subnet should be associated with a route table that will forward all the requests going to the internet through an Internet Gateway.
And if you have a private subnet, that subnet should be associated with a route table that will forward all the requests going to the internet through a NAT gateway or a NAT instance, or sometimes you don't want to forward any traffic to the internet, so you simply won't forward traffic to the internet. That is a private subnet.
You can also have a different kind of scenario where, for example, you have your business in here, you have your private data center, and you have a VPN connection to your data center. And what you can say is that all traffic from a private subnet that should go to the internet, you will instead forward that traffic to your company data center. And inside your data center, you can have a firewall or some networking appliance of any kind that will evaluate that request and decide whether or not to send that request to the internet.
Another cool thing to have and we will deploy in our VPC is a VPC endpoint. A VPC endpoint works more or less the same as an internet gateway, but it won't forward traffic to the internet. Instead it will forward traffic to a particular AWS endpoint.
So in this case, we only have VPC endpoints available for S3. So in this case, we will also say to our Private Route Table to forward all the requests going to the S3 service to the VPC endpoint. And the VPC endpoint will send this request securely. It won't go through the public internet. And will reach the S3 service.
So it's a great way to manage your connection and to make sure that you won't send this kind of request to the internet. Do you have a secure connection with a address?
So, in short, what you are going to deploy in this lecture is basically:
A whole VPC with the CIDR block and we are going to deploy one private subnet on each availability zone and one public subnet on each availability zone.
We are going to deploy a NAT gateway.
We are going to deploy two route tables.
And we are going to deploy an internet gateway and an VPC endpoint. Then we are also going to configure all that in order to work properly.
So, enough talking, let's go to the AWS console and learn how to deploy a VPC. So, here in the AWS console, let's go to the VPC console.
And we have two ways of creating a VPC. We have the easy way by using the VPC Wizard. We can select a template. If we select a VPC for Single Public Subnet, that's self-explanatory. If we select a VPC with Public and Private Subnet, that will create a VPC with a public and a private subnet. And that will also create either a NAT instance or a NAT gateway, you can choose that.
But, I don't like to use that option. I think it's great when you just need a quick thing, but when you want to do things right, you should do it in the other way, you should do it in the right way.
So, let's click on Your VPCs and in here we can Create a new VPC. I will name it “Pizza-time-oregon” and our CIDR block will be this one. And we want the Default Tenancy. We don't want Dedicated Tenancy because although that will increase our networking performance, but that will also cost us more. So, we don't want that. We will stick with the Default Tenancy.
So now we have a VPC. But we only have a VPC now, we don't have any subnets inside this VPC. We don't have an internet gateway. We don't have a net gateway. We need to configure out that. The things that are created for us when we create a VPC is a Network ACL, that will be the default network ACL. A Route table, that will also be the default route table and a DHCP option set. We can customize all that and we can create more of those things. But that's also a bit helpful to have those created by default.
So, let's now create our subnets. We want a public subnet and a private subnet on each of the availability zone. So, let's start creating our subnets.
So, this will be the Public A because that will leave the us-west-a availability zone that will live inside our VPC. The pizza-time VPC and yes, we have a preference for an Availability Zone. We want A.
And this will be our CIDR block. And we can click on Create.
So, it is created and now we have to do the same thing for the other ones. We choose public B. Same thing here.
But, yeah, I really don't like this approach because as you can see, it's all a bunch of repetitions and for me, when you need to do repetitions it's better to do with a Command Line Interface.
So, let's use the AWS CLI instead. So here in the AWS CLI, we need to do more or less the same thing that we did in the AWS console. So, let's start typing our command. It's “aws ec2 create-subnet” and we need to specify a vpc-id. So we specify that. And also, we need to specify the cidr-block. And since we want to have our subnets on a specific availability zones, we also need to define an availability zone. If we don't specify that, AWS will choose one randomly. So, we also need to type that.
Our subnet was created. And it was created in the availability zone that we specified. And now if we want to create another subnet, we can simply repeat the command. So we press Up. We change the things that we need to change. And we can very quickly create new subnets.
So it's much faster to create these things using the AWS CLI. The only downside of using the AWS CLI is that we can't specify the name of our subnets. So we need to do it manually. But that's not really a big of an issue. We can do that easily using the console. So, I'll pause the video and fill the names of the subnets in. I'll get back once it's done.
Okay, I finished specifying the names for our subnets. Let's now create some Route Tables. And I'll click Create Route Table. And that'll be the Private Route Table that will live inside our pizza-time VPC and we want to Create that.
I won't configure any routes yet. I will just leave it with the default route. And I will create the Public Route Table.
Now let's start creating our assets. I will create an Internet Gateway. And again, that will live inside our VPC. We need to Attach it to our VPC. Now, I will create a new Endpoint to live also inside our VPC. Select the right VPC. This is the only one available, which is s3. And we can specify a Policy in here. We could, for example, just allow get requests. We would not allow put requests through this endpoint. But, I will use Full Access because it's easier that way. We can go to the next step.
We now need to associate our VPC Endpoint with our Route Table. I will associate it with the Private Route Table. We could associate with more than one, but I just want to associate this endpoint with the Private Route Table. And our endpoint was created. We can see here that it looks more or less the same as an internet gateway. And in fact, it behaves more or less the same as an internet gateway.
Let's create now a NAT Gateway. We click in here. And we need to specify a subnet where this NAT Gateway will live. So, I will select the last Public subnet and we need to associate this NAT Gateway with an Elastic IP. So I'll click in here to create a new one. And we can see our NAT Gateway is already created.
And now it's time to finish the configuration of our Route Tables. So go to the Route Tables. And we need to specify a few things in here. I would start with the Public Route Table. And I will say that all the requests going to the internet will be forwarded to the internet gateway. That's super easy. And for the Private Route Table, I need to say that all the requests going to the internet will be forwarded to the NAT Gateway instead.
The last thing that we need to do in here is to associate our subnets to the Route Tables. So, we need to specify to each subnets this Route Table is associated with. Since it's the Private, I will select all the private subnets. And for the Public, I need to select all the public subnets. Otherwise, if we don't associate these Route Tables, they will be associated with the default route table that we created when we created also our VPC.
And let's take a look at the default Route Table. The default Route Table only has a route every time you create a new VPC and you create subnets inside this VPC and if you don't create any Route Table, if you don't change the Route Table associations, you have a Route Table pointing to local. And what that means is, that by default, all subnets inside the VPC can talk with each other.
Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.