Exam ANS-C00 topic 1 question 375 discussion

Answer A has all the packets going out the Direct Connect to be routed by the on-premises router. That would be expensive and unnecessary. You can use VPC Peering. Go with answer D.

Ans is A . This scenario comes from the following document https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/ VPCs Connected with AWS Direct Connect This approach is a good alternative for customers who need to connect a high number of VPCs to a central VPC or to on-premises resources, or who already have an AWS Direct Connect connection in place. This design also offers customers the ability to incorporate transitive routing into their network design. For example, if VPC A and VPC B are both connected to an on-premises network using AWS Direct Connect connections, then the two VPCs can be connected to each other via AWS Direct Connect.

Cannot access a peered VPC through private VIF connect to another VPC. Connection between VPC's can be through peering (that's cheaper than connect them through DX link), but to connect them to on-prem DC you need VIF for each VPC. That's D over A of course.

C is possible. Technically you can set NAT in the Management VPC adn this way the traffic will be allowed on the peering connections as it will appear as originated from the management VPC. However. it is not something that you can just "enable", but require to use NAT instance or NAT GW (even though for the NAT GW I am not sure if it would work). Still it requires more effort and activities than described in the answer, so maybe it is D.

A is out since DX can't be used to route packet betwen VPCs B and C are out since VPC peering is not transitive Answer D

Answer is A, it is saying AWS Direct Connect must be configured to facilitate data transfer from on-premises to each VPC, no data transfer from peers.

In this case, I think all others traffic will be transferred to Mgt. VPC. And at Mgt. VPC, customer software will collect metrics from instances on other VPCs. Mgt. VPC looks like a star-hub, where other VPCs connect to it then transfer the traffic to. Then I go with C. My idea: Management VPC will have VIF to connect to on-premise though DX. Other VPCs transfer metrics to Management VPC. Customer software running on Mgt VPC.

Both A and D works However, D is better, because: - creating VPC peering is free of charge - traffic costs ~0.01€/GB for VPC peering (IN + OUT) and ~0.02€/GB for direct connect (OUT only). As the communication involved in monitoring will never have IN == OUT, then 0.01 * (IN + OUT) will always be lower the 0.02 * OUT, ergo VPC peering will be cheaper Besides, you will get far better performance using VPC peering, as the traffic will stay in the same AWS zone, without going back and forth between AWS and your router

A is not right. To route traffic between VPC through the DX, the traffic goes through your on-prem router. This is fine but the DX cost is higher than Peering (2cents vs 1cent) I think

A would be insane in term of cost when transfer data out of AWS, it's definitely D

C is the correct one. Transitive routing does not apply in this case as NAT will be used for source/destination translation. ON-PREMISES -> NAT ADDRESS IN MANAGEMENT VPC -> VPC A OR VPC B

People arguing based on 2018 whitepaper perhaps don't understand VPC peering. VPC Peering happens within AWS infrastructure - performance perspective it is always going to be better. There are no bandwidth bottleneck. Here is latest whitepaper - check out the last line of VPC Peering section - "VPC peering offers the lowest overall cost when compared to other options for inter-VPC connectivity". https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf Answer is D

A. Correct, is the most accurate answer. D. It says enable VPC peering between all VPCs, which is not required at all since only Management VPC needs to talk to all other VPCs

I will go with A.

A looks good to me. If you read the following paragraph carefully and also take a look at the figure on Page 24 of the document referred to by 2aldous, it becomes very clear. By the way, the figure caption on Page 24 is: Intra-region VPC-to-VPC routing with AWS Direct Connect. AWS Direct Connect makes it easy to establish a dedicated network connection from your premises to your Amazon VPC or among Amazon VPCs. This option can potentially reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than the other VPC-to-VPC connectivity options."

Answer is "A" Please check this: https://d1.awsstatic.com/whitepapers/aws-amazon-vpc-connectivity-options.pdf Page: 22,23,24 (AWS Direct Connect) "AWS Direct Connect makes it easy to establish a dedicated network connection from your premises to your Amazon VPC or among Amazon VPCs. This option can potentially reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than the other VPC-to-VPC connectivity options. You can divide a physical AWS Direct Connect connection into multiple logical connections, one for each VPC. You can then use these logical connections for routing traffic between VPCs"

Looking into this... B. Nope. Transitive. C. Nope. Transivite+. A. 4x PVIFs = good. DX routing - there is zero documentation supporting such a solution. If you cant find anything in Google then it probably does not exist - so no go. D. Overkill solution but technically it is accurate. 4x PVIFs = on-prem routing done. VPC Peering to all = mgmt can reach each VPC. Yes its overkill but I think this is the point of the question. Will the test taker go for the convulted option (A) or something the guy/gal has seen in some form already (D). D is the right option.