7.2 VPC Lab - Part 1
Last updated
Was this helpful?
Last updated
Was this helpful?
Create your own VPC.
Go to Networking & Content Delivery part, and select VPC. You can see there are lots of default things AWS has created for you when you create your AWS account.
Don't use VPC Wizard, you need to create VPC by your own manually.
Select Your VPC tab, and click Create VPC.
You need to give it a name tag: acloudguruVPC, and give it a IPv4 CIDR block: 10.0.0.0/16 which will give you the biggest address range possible for a VPC. Enable IPv6 CIDR block (to learn more). For the Tenancy, you can select Default. Another option is dedicated, it means you will be dedicated hardware and no other AWS customers would be sharing the hardware with you, but this is expensive.
Click Yes, Create. During this process, the following things will be created: route tables, network ACL, security group. It won't create any subnet, you have to create subnets by yourself. Everything else is still empty. What we have for now is:
Go to create subnets. Click Create Subnet. You need to give it a name tag using this convention: [subnet IPv4 block address]-[AZ name], for example, 10.0.1.0-us-east-1a. For VPC, select the VPC you created just now. For AZ, select a AZ you like. A interesting thing is that for different AWS accounts, same AZ name may randomly refer to different actual AZ data center, because Amazon need to solve the problem that almost all of people will select US-EAST-1a as their first choice for convenience. For the IPv4 CIDR block, you can type in 10.0.1.0/24 which gives you 256 IP addresses but you can only use 251 of them, because the first 4 IP address and the last address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. The first one is network address, the second one is reserved for VPC router, the third one is reserved for DNS, the fourth one is reserved for future use, the last one is broadcast address (AWS do not support broadcast so they reserve this address). Don't need to assign an IPv6 CIDR. Click Yes Create, which will create a subnet inside your VPC.
For highly available, go to create your second subnet. Name tag: 10.0.2.0-us-east-1b. VPC: the VPC you created in this lab. AZ: us-east-1b. IPv4 CIDR block: 10.0.2.0/24.
Click Yes, Create. For now, what we have is:
Next step is to add Internet Gateway so that we get Internet connectivity. Go to Internet Gateways and click Create Internet Gateway. Give it a name tag, for example, MyIGW. Click create.
By default, your Internet Gateway now is detached. So select the Internet Gateway you created just now, click Attach to VPC. Attach to the VPC you created in this lab.
You cannot attach multiple Internet Gateways to one VPC.
Go to Route table. You can see AWS provides you a default route table when you create your VPC, and it is Main route table. Every single time we create a new subnet, it is going to associated by default to our main route table. We don't want our main route table to have a way out to the Internet, because if so, every single time we provision a subnet, it will be Internet accessible. So what we really want to do is to create a new route table.
Click create route table. Name tag: MyInternetRouteOut. VPC: the VPC you created in this lab. Click Create. Next step is to add Internet access for this new route table. Select the route table you newly created, and go to Routes tab of it, and click Edit. Add a new entry to rules. Destination: 0.0.0.0/0. Target: the ID of your Internet Gateway. This will allow all of the traffic. Everything that sits within this route or every subnet that is associated to this route will now be a public subnet. Save. For consistency, we add a IPv6 to the rules as well. Destination: ::/0. Target: the ID of your Internet Gateway. Save.
Go to subnet associations tab of the newly created route table. Click Edit. Select 10.0.1.0/24 and click Save. This will make this subnet to be our public subnet and the other subnet will be our private subnet.
Go to Subnets tab, you will notice that the Auto-assign-Public IP of both of our public subnet and our private subnet are No. For our public subnet, we want to auto assign a public IP address to EC2 instance when we create it, otherwise we won't be able to access the EC2 instances sit in this subnet through the Internet. So select the public subnet, and go to Subnet Actions -> Modify auto-assign IP settings to change it.
Go to provision some EC2 instances in public subnet and some in private subnet to prove the the subnet is public or private.
Configure your EC2 instances in public subnet. Network: the VPC you created in this lab. Subnet: 10.0.1.0/24, the public one. The security group: you have to create a new security group. The security group will only exist within the VPC that you create. So create a new security group and call it Web-DMZ. DMZ here means demilitarized zone -- lay down your arms :). Add rules: SSH, HTTP, HTTPS. Select a key pair and launch the instance.
Create another instance in your private subnet. Network: the VPC you created in this lab. Subnet: 10.0.2.0/24, the private one. The security group: select the default security group instead of the one that you created when you create the public EC2 instance. Because we don't want it to be open to the world. Select a key pair and launch the instance.
Go to your EC2 console, you can see that your public instance has a IPv4 public IP address, and your private instance doesn't. Also, for the AZ, the public instance is in us-east-1a, and the private instance is in us-east-1b, because the public subnet is in us-east-1a and the private subnet is in us-east-1b.
You can use SSH to go into the public instance. If you are using MAC laptop: ssh ec2-user@[public-ip-address] -i [key-pair-name].pem
What we have now:
For now, the two instances in two subnets cannot communicate with each other. Because they are behind two different separate security groups in two different availability zones that we haven't allowed permissions for them to talk to each other. This is what we are going to do in the next lecture.
