A private subnet within a VPC has no access to or from the Internet; however, it is by default accessible and can access all other private and public subnets in the VPC because the default routing in the VPC targets the entire VPC CIDR range. You can connect private subnets via VPN or Direct Connect connections to on-premises environments or other VPCs via VPC peering. You can also allow indirect access from the private network to the Internet via a NAT gateway or NAT instance or appliance that will allow instances in the private subnet to reach the Internet while remaining private and inaccessible from the Internet.
Any private subnet can also be easily converted into a public subnet, by creating a route table entry to an Internet gateway (IGW) attached to the VPC where the subnet is created. The IGW automatically allows traffic to be sent to and from all instances running in the public subnet that have a public or Elastic IP attached.
Public IP addresses can be attached to the instance automatically at startup, but they are selected randomly from an AWS-owned pool of public addresses and are changed every time the instance is shut down or restarted. If you would like to assign a static public IP to an instance and have the public IP assigned to the instance or application persistently through reboots, you can also choose to assign and attach an Elastic IP address to an instance. Elastic IPs are persistent regardless of the state of the instance, and they can also be detached and reattached to any instance in your VPC. This capability can be very useful in case of a failure of a stateful application that needs to be accessed via IP. When a replacement of the failed instance is deployed, the same Elastic IP can be detached from the failing instance and reattached to the new instance, and the application can be recovered with minimal downtime.
Figure 5.1 demonstrates the differences in the routes of a public subnet, a private subnet, and a subnet connected to the VPN.
FIGURE 5.1 Public and private subnets of a VPC
Answer these questions. The answers follow the last question. If you cannot answer these questions correctly, consider reading this section again until you can.
1. Which of the following subnets would you use to deploy a highly available application running on a maximum of 2000–3000 hosts?
A. 10.20.30.0/23
B. 10.20.30.0/22
C. 10.20.30.0/21
D. 10.20.30.0/20
2. You have been asked to deploy an application into production. The production requirement is that four nodes must always be available in the VPC. Which of the following deployments would ensure you meet the requirements?
A. Deploy four instances into two VPC subnets and span them across two availability zones.
B. Deploy four instances into three VPC subnets. Ensure subnets are created in two availability zones.
C. Deploy six instances into four VPC subnets in one availability zone.
D. Deploy six instances into three VPC subnets. Ensure the subnets are created in three availability zones.
1. Answer: C is correct. Although multiples of any of the network subnets could be used to achieve this goal, a /21 range would be appropriate in this scenario. In a /21, 2043 addresses are available for hosts. To be highly available, you need two subnets, which will give you more than 4000 addresses combined. The application should comfortably fit into these two subnets plus leave a bit of room for future growth or changes. You could argue that three /22 addresses would be close enough, but with just barely over 3000 addresses, it leaves little room to grow the application within the existing subnets. The /23 addresses in A would introduce at least six subnets, whereas a minimum highly available deployment of /20 in D would give you over 8000 addresses, meaning it could be wasteful.
2. Answer: D is correct. Having six instances across three availability zones ensures you always have four instances available, even if a complete availability zone is lost.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
