Introduction

Cornell AWS customers have the option to opt-in to use an AWS VPC that is shared with other Cornell AWS customers. The subnets in this Shared VPC have CIDR blocks in the private Cornell network.

The resources deployed to the the Shared VPC have network access to other Cornell network resources, specifically:

• all Cornell Standard VPCs in AWS, via Transit Gateway
• on-campus Cornell networks, via Direct Connect
• private Cornell VNets in Azure, via Internet2 Cloud Connect

In the past, each Cornell AWS customer that required access to the private Cornell network in AWS received their own Cornell Standard VPC that provided an AWS VPC for their exclusive use. In contrast, the shared Cornell AWS VPC described in this document provides similar network connectivity in a set of AWS subnets shared among multiple Cornell AWS customers.

Benefits of Using the Shared VPC

Cornell AWS customers that opt-in to use the Shared VPC will experience the following benefits:

• Privileged Network Access
  • Resources using the Shared VPC are assigned private IP addresses from the private Cornell network. As such, they reside on the Cornell network and potentially can reach other resources on the Cornell network.
•  Ease
  • The Shared VPC can be used without the need to setup and manage your own VPC.
  • The CIT Cloud Team manages manages the subnets, network ACLs, and Route Tables in the Shared VPC. Customers manage the Security Groups applied to their EC2 instances and other resources deployed in the Shared VPC.
• Cheaper
  • Each Cornell Standard VPC contains at least one NAT Gateway, which typically costs about $1/day to run. In contrast, NAT Gateways deployed in the Shared VPC are managed and paid for by CIT.
  • VPC Flow Logs in the Shared VPC are paid for by CIT.
• Increased resiliency
  • Customers using the Shared VPC have access to subnets in all of the Availability Zones in the us-east-1 AWS Region. In contrast, the Cornell Standard VPC is typically deployed only to two Availability Zones.
  • Each private subnet in the Shared VPC utilizes a NAT Gateway local to the Availability Zone where the subnet is deployed. In contrast, private subnets in the Cornell Standard VPC typically utilize a single NAT Gateway in a single Availability Zone.
• Availability Zone matching
  • Since the Shared VPC offers access to all Availability Zones in us-east-1, customers have the option to deploy resources in specific AZs if they are trying to deploy resources in the same AZs as deployed by partners or vendors.

Caveats of Using the Shared VPC

There are a few caveats to be aware of when deciding whether to opt-in to use the Shared VPC:

• Customers using the Shared VPC still require their own Cornell AWS account. The Shared VPC is accessible from that AWS account, once opted-in to use it.
• The Network ACLs used by the Shared VPC may be a bit more permissive than ones a Cornell AWS customer might design for a VPC of their own. Since the Shared VPC supports a plethora of use cases and resource deployment architectures, it cannot be customized (i.e., "locked down") for a single customer. Note that customers do manage the Security Groups applied to their EC2 instances and other resources deployed in the Shared VPC so they still decide the ultimate connectivity and access to their resources.
• To be continued...

Use Cases

The Shared VPC supports many, many customer use cases. A few of those are:

• Manual deployment of a few resources that require access to the Cornell private network
• Deployment of three-tier (or more!) applications in the Shared VPC
• Using Infrastructure as Code to create and manage AWS resources in the Shared VPC
• Standing up an RDS instance in the private Cornell network
• Deploying an API Gateway API or Lambda function with access to the Cornell network
• Deployment of resources which will be accessed only by users on the Cornell VPN

Misuse Cases

Misuse cases are situations where the Shared VPC should not or cannot be used. Some of those are:

• Deployment of resources that don't need access to the Cornell network
• Cornell private network access in regions other than us-east-1 (N. Virginia)
• Need to directly customize Network ACLs, Route Tables, or other VPC configuration
• Peering to non-Cornell VPCs
• Ability to use a vast number of private Cornell IP addresses in AWS
• Deploying Kubernetes or using EKS (Kubernetes consumes vast numbers of IP addresses, which is incompatible with the Shared VPC model)

FAQs

Is the VPC really shared?

No, the VPC itself isn't shared. Just the subnets within the VPC are shared. However, in most cases we use "shared VPC" instead of "shared subnets in the multi-tenant VPC" since the latter is cumbersome and most people immediately understand.

How are the VPC subnets shared?

The subnets in the VPC are shared to your Cornell AWS account using the AWS Resources Access Manager.

Do I need an AWS account to use the Shared VPC?

Yes, you still need a Cornell AWS account to use the Shared VPC. When you opt-in to use the Shared VPC, you get visibility of and permission to deploy resources to it using your Cornell AWS account.

Where do resources deployed to the Shared VPCs reside?

From a management and financial standpoint, the resources you deploy to the Shared VPC reside in your AWS account. I.e., you have full access to manage the resources via the AWS console or APIs and you have full responsbility to pay for those resources via the standard Cornell AWS billing process.

From a networking perspective, those resources have connectivity to the Shared VPC even though the VPC is owned by another Cornell AWS account.

Can other Cornell AWS accounts access the resources I deploy to the Shared VPC?

No. The resources deployed to the Shared VPC are visible and manageable only from the AWS account from which they were created.

Can I still manage and use other VPCs if I opt into using the Shared VPC?

Yes, you can continue to create and manage custom VPCs in your Cornell AWS account even after you opt in to use the Shared VPC. However, note that you will not be able to peer your custom VPCs to the Shared VPC.

I have a Cornell AWS account without Cornell networking. How do I opt-in to use the Shared VPC?

TBD

I already have a Cornell Standard VPC in my AWS account. Can I opt-in to use the Shared VPC?

TBD

Who is responsible for security in the Shared VPC?

While the CIT Cloud team manages the Network ACL associated with the Shared VPC, you are completely responsible for managing the overall network access to the resources you deploy to the Shared VPC (e.g., by using Security Groups and host firewalls) and to managing the resources themselves (e.g, EC2 instances) according to best practices and Cornell policy.

Do my resources deployed to the Shared VPC automatically have access to a target resource (X) which is also on the Cornell network?

From an access (reachability) perspective, a resource deployed to the Shared VPC is no different from any other AWS resource deployed to a VPC connected to the Cornell network. You may still have to work with the team that manages the target resource to allow your resource to access the target.

Am I charged for using the Shared VPC?

You are charged for the resources you deploy to the Shared VPC just like you would be charged for similar resources deployed to a VPC that you owned. You are also charged for the network traffic (bandwidth) attributable to those resources, again as if you deployed them to a VPC you owned. 

However, the overhead costs of the VPC (e.g. NAT Gateway costs, VPC Flow Log costs) are not charged to or shared by Cornell AWS accounts.

Are there quotas or limits associated with the Shared VPC?

No. While we don't want customers to make deployments to the Shared VPC that will gobble up IP addresses, we don't have specific quotas about how many addresses each customer can use.

Guidelines

Customers using the Shared VPC must agree to abide by the following guidelines:

• Customers cannot use the Shared VPC to deploy systems that utilize large quantities of IPv4 addresses. For example:
  • Kubernetes clusters and the Amazon Elastic Kubernetes Service (EKS) both use large numbers of IP addresses, even for trivial deployments.
  • Large AWS EMR deployments. (EMR clusters with a handful of nodes are OK.)
• TBD

Best Practices

• Use Security Groups applied to resources deployed in the Shared VPC to restrict ingress to those resources, even by traffic from the local VPC and subnets. You don't want to be affected by something dumb another team does when they are using the Shared VPC.
• When deploying replicas of a specific resource, be sure to spread them out across multiple subnets and multiple AZs.
• Be especially careful about configuring resources that automatically scale up (e.g., EC2 Auto Scaling Groups).
• If you are managing Elastic Network Interfaces directly, be sure to delete them once they are no longer needed.

References

• Cornell
  • Cornell AWS Direct Connect
  • The Cornell Standard VPC
• AWS