Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Warning

This page is being retained for historical purposes, but is no longer maintained. All relevant Direct Connect information about the current (2023 and after) Direct Connect architecture has been migrated to primary customer Direct Connect documentation, Cornell AWS Direct Connect.


Info

Executive Summary

  • Cornell AWS accounts using Direct Connect will be migrated to a new network architecture in January 2023.
  • This new architecture simplifies Direct Connect configuration and management, and improves Direct Connect bandwidth and flexibility.
  • The migration process is designed to avoid interruption of Direct Connect connectivity, how brief interruptions may occur. 
  • Cornell AWS account owners/administrators will be solicited for feedback directly via email several times throughout this process. But, in most cases, this input is not required for the migration to proceed.
    • AWS accounts having VPCs using Direct Connect and with numerous subnets and route tables, or where network resources are configured by infrastructure-as-code will need to provide input to complete this migration.
  • While line items for charges to Cornell AWS accounts will change between the old and new Direct Connect architectures, the overall change in cost is negligible.
    • CIT will be paying for new costs of ~$36/mo for each customer VPC connected the new Direct Connect architecture.

...

Tag KeyTag ValuesDescriptionVPCSubnetsRoute TablesNACLs ‡

Transit Gateway
Attachments

Virtual Private
Gateways

Direct Connect
Virtual Interfaces
cit:dc-arch-migration-targetyes/no

Will this resource itself be affected as part of the migration?

(tick)(tick)(tick)(tick)(tick)(tick)(tick)
cit:dc-arch-migration-descriptionprose

Description of planned changes to this resource

(tick)(tick)(tick)(tick)(tick)(tick)(tick)
cit:dc-arch-versionv1/v2Is this a v1 or v2 architecture resource? After migration, v1 resources utilized in the v2 architecture will be relabeled as v2 resources.(tick)(tick)(tick)(tick)(tick)(tick)(tick)
cit:dc-arch-migration-new-resourceyes/noIs this a new resource specifically created for the v2 architecture?n/an/a(tick) (tick)(tick)n/an/a
cit:dc-arch-migration-replacesresource IDIf this v2 resource will be replacing a v1 resource, this ID references the resource that will be replaced.n/an/a(tick)n/an/an/an/a
cit:subnet-typepublic/private/utility

Is this a private or public subnet? Public subnets are those with a route to an Internet Gateway. Utility subnets will be created specifically to use for TGW Attachments. Private subnets are all subnets that are not public and are not utility subnets.

n/a(tick)n/an/an/an/an/a
cit:tgw-attachment-targetyes/noWill a Transit Gateway be attached to this subnet?n/a(tick)n/an/an/an/an/a
cit:dc-arch-exclude-tgw-attachment-guidanceroutesyestbd/attach/no-attachThis tag provides a place for a human reviewer to provide guidance about whether a TGW attachment should be made to the tagged subnet.
  • tbd → guidance has not yet been provided
  • attach → human guidance says to attach the subnet to the TGW
  • no-attach → human guidance says not to attach the subnet to the TGW

(warning) Of all these tags, this is the only tag whose value should be updated by customers.

n/a(tick)is applied only to the new Route Table that is created for use by the TGW Attachment utility subnetsn/an/a(tick)n/an/an/an/an/a
cit:dc-vgwyes/noDoes this Route Table contain rules referencing a VGW?n/an/a(tick)n/an/an/an/a
Cost CenterR524755This tag added to TGW Attachments will result in CIT paying for the $0.05/hr cost of attaching a VPC to a TGW.n/an/an/a(tick)n/a(tick)n/an/a

‡ Only the NACL created for use by utility subnets will be tagged.

(info) Direct Connect Gateways are also involved in the migration but cannot be tagged.

...

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.

...

Unlike Virtual Private Gateways, TGW Attachments connect to specific subnets in a VPC. We will be making these TGW Attachments to multiple private the utility 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 AZ, 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.

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

V1 Route Tables will not be deleted, but will not be used in the v2 architecture. Cornell AWS account owners can delete the v1 Route Tables if they wish. Once the VGWs are deleted, those v1 Route Tables will not be all that functional.

...

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

V1 Route Tables will not be deleted, but will not be used in the v2 architecture. Cornell AWS account owners can delete the v1 Route Tables if they wish. Once the VGWs are deleted, those v1 Route Tables will not be all that functional.

Anchor
costs
costs
Costs

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.

V1 Architecture

Cornell AWS

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.

V1 Architecture

Cornell AWS accounts using Direct Connect saw these Direct Connect-related charges:

...

draw.io source: direct-connect-migration-process.v2.drawio

Anchor
schedule
schedule

none
PhaseStageTimeframeStatusActivityImpact on Cornell AWS Account VPC Networks
Preparation

Data CollectionNovember 2022(tick)
  • Gather information about Direct Connect resources and connected VPCs in Cornell AWS accounts
none
Resource Tagging

 

(tick)
  • Add tags to existing resources in customer accounts to assist with targeting, identification, status, intended disposition
none
Resource Groups(tick)
  • Create Transit Gateway in CIT AWS account
  • Create Resource Groups for resources involved in the migration in customer accounts
none
Customer Input #1

-  

(tick)
  • Cornell AWS account owner/admin review
  • Cornell AWS account owner/admin feedback solicited
none
Migration

Transit Gateway Attachments

-  

(tick)
  • Utility Subnets
  • Transit Gateway Attachments created in customer accounts
  • v2 Route Tables created in customer accounts
  • NACLs for Utility Subnets
none
Customer Input #2

-  

(tick)
  • Cornell AWS account owner/admin review
  • Cornell AWS account owner/admin feedback solicited
  • Route Table and/or TGW Attachments adjusted according to customer input
noneVPC Routing Updated

 

  • v2 Route Tables activated
  • v1 Route Tables deactivated
VPC-to-campus traffic will be routed through the v2 architectureCampus Direct Connect Routes Updated

 

  • Campus-side routing updated to begin using the v2 architecture for campus-to-AWS traffic
campus-to-VPC traffic will be routed through the V2 architectureCleanupCustomer Account Cleanup

-  

  • VGWs and DC VIFs in customer accounts deleted
noneCampus Direct Connect Cleanup
  • Campus Direct Connect resources deleted or decommissioned
  • Route Table and/or TGW Attachments adjusted according to customer input
none
v2 BGP Updated

7am

(tick)
  • v2 Direct Connect infrastructure will have BGP configuration changed to begin advertising new routes via I2CC
Azure-to-AWS-VPC traffic may begin to use the v2 architecture (in just the one direction). This is limited only to Azure-to-AWS-VPC traffic due to Cornell's network architecture. 
VPC Routing Updated

9am

(tick)
  • v2 Route Tables activated
  • v1 Route Tables deactivated
  • VPC-to-campus traffic will be routed through the v2 architecture
  • Azure-to-AWS-VPC traffic may use the v2 architecture.
Campus Direct Connect Routes Updated

9am

(tick)
  • Direct Connect Virtual Interfaces in customer accounts will be disabled. This causes  DC traffic to begin using the v2 architecture for campus-to-AWS traffic
  • campus-to-VPC traffic will be routed through the V2 architecture
  • all Azure-to-AWS-VPC traffic will be routed through the v2 architecture
CleanupCustomer Account Cleanup

-  

(tick) 
  • VGWs and DC VIFs in customer accounts deleted
none
Campus Direct Connect Cleanup(tick)
  • Campus Direct Connect resources deleted or decommissioned
none

Anchor
custom-schedul
custom-schedul
Alternate Migration Days

Customers have the option to request that migration for their VPC(s) occur during the week of Jan 9-13 instead of the default migration dates of January 17 and 18. This is especially encouraged for customers that have a separate sandbox or development VPC that needs to be migrated. We can also support taking both migration steps on the same alternate day, but we'd like to leave a 1-4 hour gap between migration steps to confirm that the "VPC Routing Updated" step was successful before continuing to the "Campus Direct Connect Routes Updates" step.

Anchor
rollback
rollback
Rollback

Both the "VPC Routing Updated" and the "Campus Direct Connect Routes Updated" steps have simple rollback mechanism. If you discover problems with networking in your VPC after either step and think the change needs to be rolled back, send an email to cloud-incident@cornell.edu and ping Paul Allen (pea1) on Teams.

  • The rollback for the "VPC Routing Updated" step is to reassign the original Route Tables to the public and private subnets. This will rollback takes effect immediately.
  • The rollback for the "Campus Direct Connect Routes Updated" step is to the cancel the failover of the Direct Connect Virtual Interfaces that we triggered to initial the campus routing updates. This rollback takes 5-20 minutes to complete. 

FAQs

How do I tell if my AWS account will be affected by this change?

...

The exact pathways that Direct Connect traffic takes will change between the v1 and v2 architectures. But, the starting point (e.g., your VPC) and endpoint (e.g. a campus VLAN) of this traffic will constant.

When, specifically, will this migration occur?

...

VLAN) of this traffic will constant.

When, specifically, will this migration occur?

See detailed schedule above.

Is there any flexibility in migration dates?

Yes. See Alternate Migration Days above.

Can the migration be rolled back?

Yes. Each of the two active migration steps ("VPC Routing Updated" and "Campus Direct Connect Routes Updated") can be individually rolled back for each migrating AWS VPC. See Rollback above

...

.

What if I use Terraform or a similar tool to manage the network resources in my AWS account?

...

...