...
However, since the Transit Gateway in the v2 architecture is configured to fully interconnect attached VPCs, most if not all VPC peering among Cornell AWS VPCs could be removed. When VPC peering is removed, VPC-to-VPC traffic that formerly used a peering connection would use the Transit Gateway instead. All traffic would remain in AWS, and the traffic would take two (2) hops to reach the target VPC instead of the one (1) hop that the peering connections support.
There is one case There are two cases where VPC peering would need to remain in place. :
- When Security Groups in
...
- one VPC reference Security Groups in a peered VPC, that peering cannot be removed without adjusting the security group to use CIDR blocks instead of the referenced Security Group. TGW Attachments do not support this type of cross-VPC Security Group referencing.
- Peering with among VPCs that are not using Cornell Direct Connect. VPCs not using Cornell Direct Connect cannot replace peering with the TGW Attachment in the v2 architecture.
Reducing the amount of peering amongst Cornell AWS VPCs will take place later and customers will be contacted separately about that. No peering changes are planned as part of the Direct Connect architecture migration.
Does this change affect which campus network CIDR blocks are routed to/from my private and public subnets?
Our goal with this migration is that the routing of traffic between your VPC and Cornell public and private CIDR blocks remains effectively unchanged between the v1 and v2 architectures. I.e. the Direct Connect routing option that you chose when your Direct Connect connectivity was established will remain in place. Those routing options are "private network extension", "hybrid", and "all campus" routing. For details on those options see Cornell AWS Direct Connect Routing Diagrams.
When, specifically, will this migration occur?
...