You have deployed a three-tier web application in a VPC with a CIOR block of 10 0 0 0/28 You initially deploy
two web servers, two application servers, two database servers and one NAT instance tor a total of seven EC2
instances The web. Application and database servers are deployed across two availability zones (AZs). You also
deploy an ELB in front of the two web servers, and use Route53 for DNS Web (raffle gradually increases in the
first few days following the deployment, so you attempt to double the number of instances in each tier of the
application to handle the new load unfortunately some of these new instances fail to launch.
Which of the following could De the root caused? (Choose 2 answers)
A.
The Internet Gateway (IGW) of your VPC has scaled-up adding more instances to handle the traffic spike,
reducing the number of available private IP addresses for new instance launches.
B.
AWS reserves one IP address In each subnet’s CIDR block for Route53 so you do not have enough addresses
left to launch all of the new EC2 instances.
C.
AWS reserves the first and the last private IP address in each subnet’s CIDR block so you do not have enough
addresses left to launch all of the new EC2 instances.
D.
The ELB has scaled-up. Adding more instances to handle the traffic reducing the number of available private
IP addresses for new instance launches.
E.
AWS reserves the first tour and the last IP address in each subnet’s CIDR block so you do not have enough
addresses left to launch all of the new EC2 instances.
Hi,
I would go for the answers D and E.
See also: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html
Any thoughts on this are welcome.
Thanks,
Frank
Yes, I agree with you. It should be D and E
Yes Frank you are right. Amazon reserves 5 IP address, the subnet can only provide 11 different IP address based on its subnet configuration. Already we have 7 instances and they want to double those instance which means there will be total of 14 instances and the subnet can provide only 11 IP. That’s the reason it can’t scale up the instances.
Absolutely right..!
The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP addresses are reserved:
10.0.0.0: Network address.
10.0.0.1: Reserved by AWS for the VPC router.
10.0.0.2: Reserved by AWS for mapping to the Amazon-provided DNS.
10.0.0.3: Reserved by AWS for future use.
10.0.0.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.
DE
DE
D and E
D however is a little vague as ELB cant scale up, there should have been an autoscaling grp mentioned behind ELB in question for D to make sense. But D is the best of rest. E is 100% correct
The question is wrong For those who understand IP addressing
It says /28 VPC which means each subnet in each AZ would be maximum /29
Which is 6 usable IP address in each subnet (8 IP 1st IP is network , Last IP is broadcast)
Of usable IP 1st IP is used for Default Gateway
2nd is used for DNS.
3rd IP is reserved for future use.
Which means 3 usable IPs remain
1 used for ELB
1 used for Web
1 used for DB
1 used for NAT
Which means the current deployment itself isn’t feasible in the subnet which has NAT instance, DNS and reserved IP you have already oversubscribed.
The closest answers are C and E, though it doesnt make sense. I haven’t seen ELB scale up but worth a try
Also you cannot create a /29 subnet. Below error when I tried creating the
The CIDR ‘172.16.9.0/29’ is invalid. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidSubnet.Range; Request ID: b3b430fe-4342-454f-98d9-3c380f10f22a)
Nope, a subnet can have the same address space as its VPC – i.e. a VPC with 10.0.0.0/28 can have a single subnet with 10.0.0.0/28.
But note that there are two AZs in above info. Each AZ should have a subnet. So it means you can’t take all the IP range of the VPC. Thus, /29 make sense.
Good catch by Amit. Two /29s have 8 addresses each. However with AWS reserving the first 4 and last IP in the range it means that there are only 6 available as each AZ needs a separate subnet. They list more IPs than that in the question.
Agree with Amit, the question is wrong.
Each subnet must reside entirely within one Availability Zone and cannot span zones.
You can assign a single CIDR block to a VPC. The allowed block size is between a /16 netmask and /28 netmask. In other words, the VPC can contain from 16 to 65,536 IP
addresses.
The CIDR block of a subnet can be the same as the CIDR block for the VPC (for a single subnet in the VPC), or a subset (for multiple subnets). The allowed block size
is between a /28 netmask and /16 netmask. If you create more than one subnet in a VPC, the CIDR blocks of the subnets cannot overlap.
The initially deployment is not feasible
Q. Is there a limit on how large or small a subnet can be?
The minimum size of a subnet is a /28 (or 14 IP addresses.) for IPv4. Subnets cannot be larger than the VPC in which they are created.
For IPv6, the subnet size is fixed to be a /64. Only one IPv6 CIDR block can be allocated to a subnet.
Q. Can I use all the IP addresses that I assign to a subnet?
No. Amazon reserves the first four (4) IP addresses and the last one (1) IP address of every subnet for IP networking purposes.
10.0.0.0/28
is the IP range of 16. So the Qs is ok and DE seems to be the valid answers
In regards to answer D – As traffic to your application changes over time, Elastic Load Balancing scales your load balancer and updates the DNS entry. Note that the DNS entry also specifies the time-to-live (TTL) as 60 seconds, which ensures that the IP addresses can be remapped quickly in response to changing traffic.
This means that the load balancer can scale and consume more than one IP due to load.
https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html