Enough talk! It's time to get into some action! In this section, we are going to look at how AWS facilitates the easy deployment of VPCs using something called as the VPC wizard as well as how to create your very first, fully fledged and operational VPC! So, what are we waiting for? Let's get started!
VPC provides a simple, easy-to-use wizard that can spin up a fully functional VPC within a couple of minutes. All you need to do is select a particular deployment scenario out of the four scenarios provided and configure a few basic parameters such as subnet information, availability zones in which you want to launch your subnets, and so on, and the rest is all taken care of by AWS itself.
Let's have a quick look at the four VPC deployment scenarios:
VPC with public and private subnets and hardware VPN access: This deployment scenario is very much similar to the VPC with public and private subnets, however, with one component added additionally, which is the Virtual Private Gateway. This Virtual Private Gateway connects to your on premise network's gateway using a standard VPN connection. This type of deployment is well suited for organizations that wish to extend their on premise datacenters and networks in to the public clouds while allowing their instances to communicate with the Internet.
With this understanding, let's go ahead and deploy our very first, fully functional VPC using the VPC wizard!
Before we go ahead and deploy our VPC, let's first have a quick look at our use case. We need to create a secure website hosting environment for our friends at All-About-Dogs.com
, complete with the following requirements:
US-WEST-PROD-1 - 192.168.0.0/16
) with separate secure environments for hosting the web servers and database servers.US-WEST-PROD-WEB - 192.168.1.0/24
) should have direct Internet access.US-WEST-PROD-DB - 192.168.5.0/24
) should be isolated from any direct access from the outside world.The following is what the proposed environment should look like:
To get started with VPC, we first have to log in to the AWS Account using your IAM credentials. Next, from the AWS Management Console, select the VPC option from under the Networking group, as shown in the following screenshot:
This will bring up the VPC Dashboard using which you can create, manage, and delete VPCs as per your requirements. The VPC dashboard lists the currently deployed VPCs, Subnets, Network ACLs, and much more under the Resources section.
You can additionally view and monitor the health of your VPC service by viewing the status provided by the Service Health dashboard, as shown in the following screenshot. In my case, I'm operating my VPC out of the US West (Oregon) region.
The VPC Dashboard also lists any existing VPN connections that you might have set up earlier. You can view the VPN Connections, Customer Gateways information as well as the Current Status of the VPN connection by using this dashboard. Remember that a VPN connection has a cost associated with it when it is provisioned and in the available state. You can additionally use this dashboard and even launch your instances directly into a VPC using the Launch EC2 Instances option. These instances will most probably be launched in your default VPC in case you haven't already created another one.
With all this said and done, let's go ahead and create our VPC using the VPC Wizard. Select the Start VPC Wizard option. The wizard is a simple two-step process that will guide you with the required configuration settings for your VPC. You will be prompted to select any one out of the four VPC scenarios, so with our use case in mind, go ahead and select the VPC with Public and Private Subnets option. Do note that this will create a /16 network with two /24 subnets by default, one public subnet and the other a private subnet. You can always create more subnets as required once the VPC is created.
Also worth mentioning here is that this VPC scenario will create and launch a NAT instance as well in the public subnet. This instance will be powered on automatically once your VPC is created, so be aware about its existence and power it down unless you want to get charged for it.
The second step of the wizard is where you get to configure your VPC network and subnets. Fill in the following details as required:
<REGION>-<DEV/PROD Environment>-<UNIQUE_ID>
; so in our case, this translates to US-WEST-PROD-1
.us-west-2c
. So, even in case us-west-2a
suffers an outage, which by the way can happen, your failover subnets will still be functioning out of the us-west-2c AZ. Refer to the following screenshot:Next up, we specify the details of our NAT instance:
Moving on, we now add the S3 endpoints to our particular subnet. You can add the endpoint to either your private or public subnets, or both of them, depending on your requirements.
Pricing for a dedicated instance is slightly different than your traditional EC2 instances. Check out the complete pricing details for a dedicated EC2 instance at http://aws.amazon.com/ec2/purchasing-options/dedicated-instances/.
Once all the required information is filled out, go ahead and click on the Create VPC option. The VPC creation takes a few seconds to complete. You can even view your new VPC's default routes, security groups, and Network ACLs being created. Toward the end you will notice your NAT instance powering on, and after a few seconds of deployment your VPC is now ready for use!
Here's a handy tip for all first timers! As soon as your NAT instance is created, you can go ahead and change its default instance type to t1.micro from the EC2 Management Dashboard.
To do so, first open up the EC2 Management Dashboard in a new tab on your browser. You should see an instance in the running state, as shown in the following screenshot. First up, stop your instance using the Actions tab. Select the Instance State option and click on Stop. Wait for the instance state to change to Stop before you proceed any further. Next, select the instance, and from the Actions tab, select Instance Settings and then Change Instance Type.
From the Change Instance Type dialog box, select the t1.micro option and click on Apply. Voila! Your NAT instance is now officially a part of your free tier as well! Simple, isn't it!
Let's have a quick look at what actually happens behind the scenes when you create a VPC using the VPC Wizard. First up, let's look at the VPC itself.
Once the VPC is created and ready, you can view it from the VPC Management Dashboard as well. Simply select the Your VPCs option from the Navigation pane provided on the left-hand side of the dashboard.
You should see your newly created VPC, as shown in the following screenshot. You can use the search bar to filter out results as well. Select the particular VPC to view its details.
Use the Summary tab to view the description of your selected VPC. Here, you can view the VPC's default DHCP options set as well as the Tenancy and DNS hostnames and DNS resolution options. You can optionally change these values by selecting the particular VPC and from the Actions tab, selecting either Edit DHCP Options Set or Edit DNS Hostnames.
You can create additional VPCs as well using the Create VPC option; however, as a good practice, always keep things simple and minimal. Don't go over creating VPCs. Rather use and create as many subnets as you require. Speaking of subnets, let's have a look at newly created VPC's two subnets!
You can view, add, and modify existing subnets using the VPC Management Dashboard as well. Simply select the Subnets option from the Navigation Pane. This will list out all the subnets present in your account, so use the search bar to filter out the new ones that we just created. Type in the name of the subnet in the Search bar until the particular subnet gets listed out, as shown in the following screenshot:
You can view additional information associated with your subnet by simply selecting it and viewing the Summary tab. The Summary tab will list out the particular subnet's associated Route table, Network ACL, CIDR, and State as well. Besides these values, you can also configure your subnet's ability to auto assign public IPs to its instances. By default, this feature is disabled in your subnet, but you can always enable it as per your requirements. To do so, simply select your Public Subnet, and from the Subnet Actions tab, select the option, as shown in the following screenshot:
In the Modify Auto-Assign Public IP dialog box, simply select the Enable auto-assign public IP option and click on Save to complete the change setting. Do note that you can always override this behavior for each individual instance at its launch time.
Besides the Summary tab, the Subnet Dashboard option also provides additional tabs such as Route Table, Network ACL, and so on. You can use these tabs to view the subnet's associated route table as well the network ACL; however, you cannot add or modify the individual rules from here. To add or modify rules, you need to go to the Network ACL option or the Route Tables option from the navigation pane. Let's have a quick look at the route tables created for our VPC.
As discussed earlier in this chapter, VPCs come with a default route table (Main Route Table) associated with a subnet. So, since we have two subnets created in this VPC, we get two route tables as well, out of which one is the main route table. How do you tell whether a route table is the main one? Quite simple, actually! Just look for the Main Column in the Route Table Dashboard, as shown in the following screenshot. If the value in that column is Yes, then that particular route table is your VPC's main route table. Now, here's a catch! If you do not explicitly associate a route table with a subnet, then the subnet ends up using the main route table. In our case, both the route tables created do not have any subnets associated with them by default, so let's first get that done.
To associate a route table with a subnet explicitly, first you need to select the particular route table from the dashboard. In this case, I have selected the public subnet's router (US-WEST-PROD-WEB-RT). Next, from the Subnet Associations tab, click on the Edit button, as shown in the following screenshot. From here, you can select either of the two subnets that are listed down; however, since this is a public subnet's route table, let's go ahead and select the listed public subnet (US-WEST-PROD-WEB) as shown. Click on Save to save the configuration changes.
With this step completed, your subnet is now explicitly attached with a particular route table. But what about the individual route rules? How do we list and modify them? That's simple as well. Simply select the Routes tab to list your route table's existing rule set. Here, you should see at least three route rules, as shown in the following screenshot. The first rule is created by VPC for each and every route table, and it basically allows communication within the VPC itself. You cannot delete this rule, so don't even try it!
The next rule is basically a VPC endpoint route rule. Remember the S3 endpoint that we configured earlier with the public subnet? Well this rule will basically allow communication to occur between the instances belonging to this subnet and Amazon S3, and the best part is that this rule is auto-populated when you create a VPC endpoint!
The final rule in the list basically allows for the instances to communicate over the Internet using the Internet Gateway as the target. You can optionally choose to edit these rules by selecting the Edit option. Once you have made your required changes, be sure to Save the configuration changes before you proceed with the next steps. Don't forget to associate the private subnet (US-PROD-WEST-DB) with the remaining route table (US-WEST-PROD-DB-RT) as well.
As discussed earlier in this chapter, Internet Gateways are scalable and redundant virtual devices that provide Internet connectivity for your instances present in the VPC. You can list currently available Internet Gateways within your VPC by selecting the Internet Gateways option from the VPC's navigation pane.
The VPC wizard will create and attach one Internet Gateway to your VPC automatically; however, you can create and attach an Internet Gateway to a VPC at any time using the Internet Gateway. Simply click on the Create Internet Gateway option and provide the VPC to which this Internet Gateway has to be attached, that's it! You can list down available Internet Gateways and filter the results using the search bar provided as well. To view your Internet Gateway's details, simply select the particular Internet Gateway and click on the Summary tab. You should see your Internet Gateway's ID, State (attached or detached), as well as the Attachment state (available or not available), as shown in the following screenshot:
Also remember that to really use the Internet Gateway, your public subnet's route table must contain a route rule that directs all Internet-bound traffic from the subnet to the Internet Gateway.
The VPC is all about providing your applications a much more secure environment than what your traditional EC2 service can offer. This security is provided in two layers in the form of security groups and Network ACLs. The security groups can be used to set rules that can control both inbound and outbound traffic flow from the instance and hence work more at the instance level. The Network ACLs on the other hand operate at the subnet level, either allowing or disallowing certain type of traffic to flow in and out of your subnet. Important thing to remember here is that the Network ACLs are actually optional and can be avoided altogether if your security requirements are at a minimal. However, I would strongly recommend that you use both the security groups and Network ACLs for your VPC environments. As the saying goes - better safe, than sorry!
Coming back to your newly created VPC, the VPC wizard creates and populates a default Security Group and a default Network ACL option for you to use in an as-is condition. The default Security Group has a single inbound and outbound rule, as explained in the following:
Default inbound security rule | |||
---|---|---|---|
Source |
Protocol |
Port Range |
Remarks |
Security_Group_ID |
All |
All |
Permits inbound traffic from instances belonging to the same security group |
Default Outbound Security Rule | |||
---|---|---|---|
Destination |
Protocol |
Port Range |
Remarks |
0.0.0.0/0 |
All |
All |
Permits all outbound traffic from the instances |
You can add, edit, and modify the rules in the default Security Group; however, you cannot delete it. As a good practice, it is always recommended that you do not use this default Security Group but rather create your own. So, let's go ahead and create three security groups: one for the web servers in the public subnet, one for the database servers in the private subnet, and one for the specially created NAT Instance.
To create a new Security Group using the VPC Dashboard, select the Security Groups option from the navigation pane. Next, from the Security Groups dashboard, select Create Security Group, as shown in the following screenshot:
Using the Create Security Group wizard, fill in the required information as described in the following:
Once your Security Group has been created, select it from the Security Groups dashboard and click on the Inbound Rules tab. Click on the Edit option to add the following rule sets:
Web server inbound security rule | |||
---|---|---|---|
Source |
Protocol |
Port Range |
Remarks |
0.0.0.0/0 |
TCP |
22 |
Permit inbound SSH access to web server instance |
0.0.0.0/0 |
TCP |
80 |
Permit inbound HTTP access to web server instance |
0.0.0.0/0 |
TCP |
443 |
Permit inbound HTTPS access to web server instance |
Similarly, click on the Outbound Rules tab and fill out the Security Group's outbound rules as described in the following:
Web server outbound security rule | |||
---|---|---|---|
Destination |
Protocol |
Port Range |
Remarks |
DB_SECURITY_GROUP |
TCP |
1433 |
Permits outbound Microsoft SQL Server traffic to the database servers |
DB_SECURITY_GROUP |
TCP |
3306 |
Permits outbound MySQL traffic to the database servers |
Replace DB_SECURITY_GROUP with the Security Group ID of your database server's Security Group. Remember to save the rules by selecting the Save option, as shown in the following screenshot:
Similarly, let's go ahead and create a Security Group for our database servers as well. Populate the inbound rules as described in the following:
Database server inbound security rule | |||
---|---|---|---|
Source |
Protocol |
Port Range |
Remarks |
WEB_SECURITY_GROUP |
TCP |
1433 |
Permits Web Server instances to access the Microsoft SQL Server |
WEB_SECURITY_GROUP |
TCP |
3306 |
Permits Web Server instances to access the MySQL Server |
Replace WEB_SECURITY_GROUP with the Security Group ID of your web server's Security Group ID and save the rules before you continue with the outbound rules additions:
Database server outbound security rule | |||
---|---|---|---|
Source |
Protocol |
Port Range |
Remarks |
0.0.0.0/0 |
TCP |
80 |
Permit outbound HTTP access to database server instance |
0.0.0.0/0 |
TCP |
443 |
Permit outbound HTTPS access to database server instance |
Note that here we are permitting only the outbound Internet access to the database servers so that they can receive important patches and updates from the net. In reality, the Internet bound traffic from these servers will be routed through the NAT instance, which will forward the traffic to the Internet via your Internet Gateway.
Finally, go ahead and create the NAT instance's Security Group. Populate the inbound security rules as mentioned in the following:
NAT instance inbound security rule | |||
---|---|---|---|
Source |
Protocol |
Port Range |
Remarks |
0.0.0.0/0 |
TCP |
22 |
Permits inbound SSH access to the NAT Instance |
192.168.1.0/24 |
TCP |
80 |
Permit inbound HTTP access to the NAT instance |
192.168.1.0/24 |
TCP |
443 |
Permit inbound HTTPS access to NAT instance |
NAT instance outbound security rule | |||
---|---|---|---|
Source |
Protocol |
Port Range |
Remarks |
0.0.0.0/0 |
TCP |
80 |
Permit outbound HTTP access to NAT instance |
0.0.0.0/0 |
TCP |
443 |
Permit outbound HTTPS access to NAT instance |
With the security groups created, you are now ready to launch your instances into the VPC. Let's have a quick look at the steps required to do so!
Once your VPC is ready and the security groups and Network ACLs have been modified as per requirement, you are now ready to launch instances within your VPC. You can either launch instances directly from the VPC Management Dashboard or from the EC2 Management Console as well. In this case, let's go ahead and use the EC2 Management Console.
From the EC2 Management Console, select the Launch Instance option. This will bring up the Instance Wizard, using which you can create and launch your web server instances. In my case, I'm using the AMI (US-P-WebServer-Image-v1.0) that we created earlier in Chapter 4, Security, Storage, Networking, and Lots More! Click on My AMIs and you should see the custom-created AMI listed there, as shown in the following screenshot. Select the AMI and continue with the instance creation process.
From the next page, select any instance type for the new web server instances. In my case, I went ahead and used the default t1.micro instance type.
Next, from the Configure Instance Details page, select the newly created VPC (US-WEST-PROD-1) from the Network dropdown list and provide the web server's public subnet (US-WEST-PROD-WEB), as shown in the following screenshot. You can optionally choose to change the Auto-assign Public IP setting; however, in this case, make sure that this setting is set to Enable otherwise your web server instances will not receive their public IPs.
Add the required Storage, Tag the instance, and provide it with the web server Security Group that we created a while back. Once you have completed the formalities, review your instance's settings and finally launch it in your VPC!
Once the instance starts, verify whether it received both the private and the public IP or not. Log in to your web server instance and check whether it can reach the Internet or not by simply pinging to one of Google's DNS servers like 8.8.8.8. If all goes well, then your web server instances are all ready for production use!
The same process applies for the database servers as well. Simply remember to select the correct subnet (US-WEST-PROD-DB) for the database servers, as shown in the following screenshot:
Also note the Auto-assign Public IP setting for the database server's private subnet. By default, this should be disabled for the private subnet as we don't want our database instances to communicate with the Internet directly. All Internet-bound traffic from the database servers will pass via the NAT instance only. But how do you test whether your database servers are working correctly? By design, you cannot SSH into the database servers directly from your local desktops as the private subnet is isolated from the Internet. So, an alternative would be to set up something called as a Bastion Host. A Bastion Host is a special instance that acts as a proxy using which you can SSH into your database instances. This Bastion Host will be deployed in your public subnet and will basically only route SSH traffic from your local network over to the database server instances. But remember, this feature comes with its own set of security risks! Running a weak or poorly configured Bastion Host can prove to be harmful in production environments, so use them with care!