...

These diagrams show the network resources within Cornell AWS accounts that connect a VPC to the Cornell campus network via Direct Connect.

Version 1 (pre-2023)

Image RemovedImage Added

draw.io source: dc-arch-legacy.customer.v1v2.drawio

Version 2 (2023)

Image RemovedImage Added

draw.io source: dc-arch-2023.customer.v1v2.drawio

What Is Changing?

Before the migration is executed, a set of resources in Cornell AWS accounts will be tagged with details about the migration. In addition, a small set of new resources that support the v2 architecture will be created in Cornell AWS accounts. After the migration is complete, a few resources not used in the v1 architecture will be deleted.

Cornell AWS customers will have the opportunity to provide feedback before migration execution and any resource deletion that affects their AWS accounts.

...

These new Route Tables will be created prior to the migration, but will not actually be utilized until the migration is executed. When migration is executed, subnets associated with the v1 Route Tables will be re-associated to the corresponding v2 Route Tables. Similarly, if the "main" Route Table for the VPC references a VGW, the corresponding v2 Route Table will be set as the "main" Route Table for the VPC.

Transit Gateway Attachments

Transit Gateway Attachments are the way mechanism that VPCs are connect to Transit Gateways. The Transit Gateways we use in the v2 architecture reside in a central AWS account, and a TGW Attachment is what links the VPC in a Cornell AWS account to those central TGWs.

Unlike Virtual Private Gateways, TGW Attachments connect to specific subnets in a VPC. We will be making these TGW Attachments to multiple private subnets in your VPCs. For best resiliency, we will select private subnets in multiple Availability Zones (AZs) for the TGW Attachments. In most Cornell AWS accounts, each private subnet resides in a unique AZ. If your VPC contains more than one private subnet in a given availability zoneAZ, we will consult with AWS account owners to determine the best private subnet to select for the TGW Attachments. This is because each AZ can accommodate exactly one TGW Attachment.

Tagging

For this migration, we are tagging AWS resources to provide information about how the each resource is involved in the migration itself, the v1 architecture, and the v2 architecture.

...

Tag Key	Tag Values	Description	VPC	Subnets	Route Tables	Transit Gateway Attachments	Virtual Private Gateways	Direct Connect Virtual Interfaces
cit:dc-arch-migration-target	yes/no	Will this resource itself be affected as part of the migration?
cit:dc-arch-migration-description	prose	Description of planned changes to this resource
cit:dc-arch-version	v1/v2	Is this a v1 or v2 architecture resource? After migration, v1 resources utilized in the v2 architecture will be relabeled as v2 resources.
cit:dc-arch-migration-new-resource	yes/no	Is this a new resource specifically created for the v2 architecture?	n/a	n/a			n/a	n/a
cit:dc-arch-migration-replaces	resource ID	If this v2 resource will be replacing a v1 resource, this ID references the resource that will be replaced.	n/a	n/a		n/a	n/a	n/a
cit:subnet-type	public/private	Is this a private or public subnet? Public subnets are those with a route to an Internet Gateway. Private subnets are all subnets that are not public.	n/a		n/a	n/a	n/a	n/a
cit:tgw-attachment-target	yes/no/guidance-required	Will a Transit Gateway be attached to this subnet? If If "guidance-required" then account owners will be consulted about the TGW Attachments.	n/a		n/a	n/a	n/a	n/a

...

After migration is complete, a very few number of resources will be deleted. These are:

...

Neither VGWs nor DCVIFs have a role in the v2 architecture. v1

Migration Process

Timeline

...