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:

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:

Similarly, click on the Outbound Rules tab and fill out the Security Group's outbound rules as described in the following:

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:

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:

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:

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!

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!