Setting up a non-default VPC with a public and a private subnet and without using the "Create VPC" wizard

Question

I set up a non-default VPC using the "Create VPC" rather than the "Create VPC Wizard" command button on the VPC service's home page in the AWS Management Console - that's because I will eventually automate the process using CloudFormation. I set up an Internet Gateway for the Public subnet and a NAT gateway to serve the private subnet. Then I created an Amazon Linux instance for each subnet.

I was able to ping www.columbia.edu on the Public subnet but my "sudo yum update" command within the instance on the Private subnet - the execution of that command returned a message that the repo couldn't be found.

What went wrong?

Answer 1

1. The Internet Gateway was not the problem. It was attached to the correct VPC and its status was { State: attached, Attachment state: available } By default, the Internet Gateway will point to the Public subnet of the VPC at the time the Internet Gateway is created.

The Custom Route Table for the Public subnet aka { Main: No } includes in the "Routes" tab as its last line the default route 0.0.0.0/0 igw-**** where igw-**** is the ID of the Internet Gateway. In the "Subnet Associations" tab, the Public subnet is explicitly associated with the Custom Route Table.

At this point, verification by pinging www.columbia.edu from the instance on the Public subnet should be successful.

2. The NAT Gateway needs to point to the correct VPC, you need to assign it an EIP (Elastic IP address), and you need to specify needs its location as the Public subnet at the time of creation. If you misconfigured the NAT gateway, you may have no choice but to delete the misconfigured NAT Gateway, create a new NAT Gateway with the correct configuration and restart your public and instances so that your instances can call on the right NAT Gateway.

The Main Route Table { Main: yes } includes in the "Routes" tab as its last line the default route 0.0.0.0/0 nat-**** where nat-**** is the ID of the NAT Gateway. One more time: the private IP address of the NAT Gateway must be one of the private addresses of the Public subnet.

At this point, running "sudo yum update" on the instance on the private subnet - that command should be successful.

3. If you are adding more public subnets, make sure to associate each newly added public subnet with the Internet Gateway - I think the Internet Gateway automatically does that but it doesn't hurt to verify.

4. If you are adding more private subnets, make sure to assign a brand new NAT Gateway to each newly added private subnet. Remember, if the AZ (Availability Zone) goes down, so does the NAT Gateway that serves the AZ.