...
Consolidating and simplifying configuration and management of Direct Connect for Cornell AWS accountsImproving flexibility and bandwidth of Direct Connect connectivityAllows private Cornell network traffic in AWS and Azure to flow between those clouds without transiting campus
Scope
As of , 65 Cornell AWS accounts were configured to use Direct Connect. During this migration, all those AWS accounts will have their existing Direct Connect connectivity updated to use new pathways and AWS resources to connect the Cornell campus network to AWS.
Within those 65 Cornell AWS accounts, only the network resources within VPCs using Direct Connect will be affected. Other VPCs in those Cornell AWS accounts will not be affected.
For VPCs using Direct connect, the following table identifies the impact of this migration on specific types of network traffic
| |
Terminology
We use the following terminology in this document:
- customer – Cornell AWS account owners/administrators
- Version 1 (v1) architecture – This is the network architecture used by Cornell AWS Direct Connect networking prior to the 2023 migration.
- Version 2 (v2) architecture – This is the network architecture used by Cornell AWS Direct Connect networking after the 2023 migration.
- VPC – Virtual Private Cloud
- DC – Direct Connect
- TGW – Transit Gateway
- VGW – Virtual Private Gateway
Architectures
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)
draw.io source: dc-arch-legacy.customer.v2.drawio
Paths and Traffic Filtering in Version 1 Architecture
Inbound Traffic – From Direct Connect to EC2 Instance
|
Version 2 (2023)
dc-arch-2023.customer.ALTERNATE.10-8.v2.drawio
Paths and Traffic Filtering in Version 2 Architecture
Inbound Traffic – From TGW to EC2 Instance NOT Residing in a Subnet Attached to TGW
|
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 and any resource deletion that affects their AWS accounts.
Anchor tagging tagging
Tagging
Anchor | ||||
---|---|---|---|---|
|
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.
|
| ||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
| |||||||||
| |||||||||
‡ Only the NACL created for use by utility subnets will be tagged.
Direct Connect Gateways are also involved in the migration but cannot be tagged.
New Resources
A few new resources will be created as part of this migration.
New Resource Groups are an easy way to see the lists of affected resources.New Route Tables will have routes that replace Virtual Private Gateway destinations with Transit Gateway Attachments destinations.New utility Subnets, one for each AZ where the VPC is active.New permissive Network ACL to be used only by the new utility Subnets.Transit Gateway Attachments will connect VPCs to the v2 architecture.
If you use Terraform or other infrastructure-as-code tools to manage your VPC, let us know. We can work directly with you to allow your tools to create or import these new resources.
Resource Groups
New AWS resource groups collect references to relevant AWS account resources in one place (per Cornell AWS account) for easy reference and review:
Resources can and will appear in multiple resource groups!
cit-dc-arch-migration-affected-resources – These resources will be directly affected by this migration. These resources include:new resources that support the v2 architectureresources that support the v1 architecture and will no longer be needed for the v2 architectureresources that will remain, but will have their configuration changed to support the v2 architecture
cit-dc-arch-version-1-resources – All network resources that support or utilize the v1 architectureAfter the v1 → v2 migration is complete, v1 resources will either be deleted (if they are not used in the v2 architecture) or relabeled as v2 resources (if they continue to be used in the v2 architecture).
cit-dc-arch-version-2-resources – All newly-created resources that support the v2 architecture
These Resource Groups will be created during the Preparation phase of the migration. See Migration Process.
If you use Terraform or other infrastructure-as-code tools to manage your VPC, you may need to add configuration to instruct those tools to ignore these new tags. For example, we have specific guidance for Terraform: Terraform Configuration Guidance for 2023 Direct Connect Architecture Migration.
Note |
---|
|
Route Tables
The AWS Transit Gateways used in the v2 architecture require different routing rules than the Virtual Private Gateways (VGW) used in the v1 architecture. Each VPC Route Table that references a Virtual Private Gateway will be duplicated and, in the new Route Table, rules referencing a VGW will be replaced with rules referencing a TGW Attachment. The new Route Tables will not include "blackhole" routes (i.e. routes to resources, like old peering connections, that no longer exist) from the original Route Tables.
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.
These Route Tables will be created during the Migration phase of the migration. See Migration Process.
Utility Subnets
New "utility" subnets will be created in each VPC. The sole purpose for these subnets is to be used to make TGW Attachments. One new subnet will be created for each AZ where the VPC has private or public subnets. (This provides the best resiliency for the Direct Connect connectivity through the TGW.)
In order to create these subnets, VPCs will have an additional CIDR block associated with it. The new subnets will be created with /28 CIDR blocks from the new CIDR attached to the VPC. These tiny subnets (~16 IPv4 addresses) should not be used for anything else. The Route Tables and NACLs associated with these subnets make them unsuitable for general use.
Network ACL
The Network ACLs already in customer VPCs will not be affected by this migration. However, a new NACL will be created in each VPC and associated with the new utility subnets. The NACL will be permissive (allowing all traffic in and out) and named in such a way to discourage use for other purposes.
Transit Gateway Attachments
Transit Gateway Attachments are the mechanism that VPCs 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 the utility subnets in VPCs which were specifically created for this purpose.
TGW Attachments will be created during the Migration phase of the migration. See Migration Process.
Resource Deletion
After migration is complete, a few resources will be deleted during the Cleanup phase of the migration. These are:
Virtual Private Gateways (VGWs)Direct Connect Virtual Private Interfaces (DCVIFs)Direct Connect Gateways that supported the v1 architecture.
Neither VGWs nor DCVIFs have a role in the v2 architecture.
Info |
---|
|
Anchor | ||||
---|---|---|---|---|
|
The management and routing simplification offered by the v2 architecture comes with a shift in costs seen by Cornell AWS accounts using Direct Connect, but the overall impact to Cornell AWS account costs should be negligible.
...