These diagrams show different routing options over the Cornell Direct Connect to AWS VPCs and corresponding design considerations.

Glossary

Direct Connect Routing Options

Private Network Extension

This is our preferred routing configuration for VPCs that have no specific requirements to directly address Cornell Public Network addresses via Direct Connect.

In this configuration, the Cornell campus network will route network traffic to the VPC's private address space over the Direct Connect. In conjunction, the Virtual Private Gateway in the AWS VPC will route any Cornell Private Network traffic not destined for the VPC itself or any configured VPC peering connections back to the Cornell campus network via Direct Connect. This effectively leverages the Direct Connect as an extension of the Cornell Private Network.

Design Decisions

When using the Private Network Extension model:

• All VPC subnets that use the VGW should incorporate propagated routes from the Direct Connect
• Both Private and Public subnets in the AWS VPC will be unable to address services or clients in Cornell Public Space directly over Direct Connect
  • AWS Public Subnets may still be able to reach Cornell Public Network services over the Internet via the IGW.
    • Cornell network ACL or Managed Firewall policy updates may be required.
    • Consideration should be taken when transferring sensitive data over the public Internet. Use of transport encryption is strongly suggested and may be required by policy.
• Services deployed in the VPC should be configured to use AWS public addresses (EIP, ELB, etc).
  
  • Exposing production services to clients over Direct Connect is not advised and will not work for clients in Cornell Public Network space.

Network Diagram

In the diagram below, Client 2 (Cornell Public Network) and Client 3 (Internet User) cannot reach Service A or Service B via their Cornell Private Network (10.0.0.0/8) addresses without use of a Cornell departmental VPN. Leveraging a Cornell departmental VPN connection would give either client an IP address and routing configuration for Cornell Private Network space, allowing them to directly contact the private IP addresses of Service A and Service B. This configuration is not shown in the diagram.

Hybrid Routing

This is our preferred routing configuration for VPCs that have a requirement for AWS Private Subnets to directly address Cornell Public Network addresses via Direct Connect.

In this configuration, the Cornell campus network will route network traffic to the VPC's private address space over the Direct Connect. In conjunction, the Virtual Private Gateway in the AWS VPC will route both Cornell Private Network and Cornell Public Network traffic back to the Cornell campus network via Direct Connect. As in the Private Network Extension configuration discussed earlier, VPC traffic destined for the VPC itself or any configured VPC peering connections will remain within AWS and not sent back to campus over the Direct Connect.

To prevent asymmetric routing from occurring, this configuration leverages a distinct set of routing tables in the AWS VPC for Public and Private subnets.

Design Decisions

When using the Hybrid Routing model:

• You will require a routing table for Private subnets and another for Public subnets.
  • Subnets can share common routing tables, so multiple "private" or "public" subnets can reference the same routing configuration.
• AWS Private Subnets that use the VGW should incorporate propagated routes from the Direct Connect.
  • This brings in advertised routes to both Cornell Private and Cornell Public networks via Direct Connect.
• AWS Public Subnets that use the VGW should incorporate a route table that only sends Cornell Private Network addresses back through Direct Connect.
  • This configuration involves manually disabling Route Propagation in the Public Subnet route table and adding an entry for 10.0.0.0/8 to the VGW.
  • Allowing AWS Public Subnets to send Cornell Public Network traffic over Direct Connect can create asymmetric routing conditions.
• AWS Public subnets will be unable to address services or clients in Cornell Public Space directly over Direct Connect
  • AWS Public Subnets may still be able to reach Cornell Public Network services over the Internet via the IGW.
    • Cornell network ACL or Managed Firewall policy updates may be required.
    • Consideration should be taken when transferring sensitive data over the public Internet. Use of transport encryption is strongly suggested and may be required by policy.
• Services deployed in the VPC should be configured to use AWS public addresses (EIP, ELB, etc).
  
  • Exposing production services to clients over Direct Connect is not advised.

Network Diagram

In the diagram below:

• Client 2 (Cornell Public Network) cannot reach Service B via its Cornell Private Network (10.0.0.0/8) address without use of a Cornell departmental VPN.
• Client 3 (Internet User) cannot reach Service A or Service B via their Cornell Private Network (10.0.0.0/8) addresses without use of a Cornell departmental VPN.

Leveraging a Cornell departmental VPN connection would give either client an IP address and routing configuration for Cornell Private Network space, allowing them to directly contact the private IP addresses of Service A and Service B. These configurations are not shown in the diagram.

"All Campus" Routing

This configuration, though similar to Hybrid Routing, is not preferred since it allows for the possibility of asymmetric routing on AWS Public Subnets. Given the similarity to Hybrid Routing and the potential to serve similar use cases, we strongly recommend against using this option.

In this configuration, the Cornell campus network will route network traffic to the VPC's private address space over the Direct Connect. In conjunction, the Virtual Private Gateway in the AWS VPC will route both Cornell Private Network and Cornell Public Network traffic back to the Cornell campus network via Direct Connect. As in the Private Network Extension and Hybrid Routing configurations discussed earlier, VPC traffic destined for the VPC itself or any configured VPC peering connections will remain within AWS and not sent back to campus over the Direct Connect.

There is no inherent protection against asymmetric routing from occurring as all advertised routes from Cornell campus are presented in the subnet routing tables.

Design Decisions

When using the Hybrid Routing model:

• AWS Public and Private Subnets that use the VGW incorporate propagated routes from the Direct Connect.
  • This brings in advertised routes to both Cornell Private and Cornell Public networks via Direct Connect.
• AWS Public Subnets that use the VGW risk introducing asymmetric routing when presenting services to clients on Cornell Public Networks.
  
  • Leveraging Elastic Load Balancers, since they essentially act as a proxy, as a level of indirection on the network may be an acceptable work-around.
• AWS Public subnets will be able to address services or clients in Cornell Public Space directly over Direct Connect.
• Exposing production services to clients over Direct Connect is not advised.

Network Diagram

In the diagram below:

• Client 2 (Cornell Public Network):
  • Can reach Service B via its Cornell Private Network (10.0.0.0/8).
  • Can not reach Service B via its public IP address (return traffic denoted by dashed blue line)
    • Client 2 initiates a connection to Service B at 55.44.33.22. Service B responds, via its Cornell Private Network address over the Direct Connect. Client 2, not expecting return traffic from 10.92.104.200, drops the packets and the connection is never established.
    • Introducing an Elastic Load Balancer, or other proxy/indirection device, instead of directly attaching an AWS public IP address to Service B could potentially work around this problem.
• Client 3 (Internet User) cannot reach Service A or Service B via their Cornell Private Network (10.0.0.0/8) addresseswithout use of a Cornell departmental VPN connection.
  • VPN configuration for Client 3 is not shown in the diagram.