Page History

...

• The first option, opting into to use the Shared AWS VPC, is the simplest. As the name suggests, the Shared VPC gives Cornell AWS customers access to a set of large private subnets in us-east-1. These subnets reside on the private Cornell network and their use is shared with other Cornell AWS customers. We call this option the Multitenant Subnets option.
• The second option offers exclusive access to a set of private subnets that are customized for your use. These subnets in us-east-1 can be customized with respect to size and Availability Zone location and also reside on the private Cornell network. They can also be shared with other Cornell AWS accounts that you specify. We call this option the Exclusive Use Subnets option within the Shared VPC offering.

...

Benefit	Feature	Description	Cornell Standard VPC	Shared VPC
				Multitenant Subnets	Exclusive Use Subnets
Ease of use	AWS Account integration	Subnets are visible directly from your AWS account, via the web console or API.
	No VPC management	Customers do not have to worry about managing a VPC. Subnet, route table, NAT gateway, endpoint, and network ACL management is performed by the CIT Cloud Team.
Fault-tolerance and Flexibility	AZ flexibility	Use subnets in any us-east-1 Availability Zone.	not by default
	Fault-tolerant internet access	Each subnet uses a NAT Gateway in the same Availability Zone as the subnet to route outgoing traffic to the public internet. A NAT Gateway failure in one zone won't affect subnets in other zones.	not by default
Privileged network access	Private Cornell addressing	Resources are assigned IP addresses from the private Cornell network. As such, they reside on the Cornell network and can reach other resources on the Cornell network.
	Public subnets	Ability to deploy resources to public subnets, directly accessible from the internet.
	Access to on-campus Cornell networks	Subnets have private network connectivity to the on-campus Cornell network.
	Access to Cornell networks in Azure	Subnet have private network connectivity to private Cornell networks (VNETs) in Azure.
	Access to on-campus Cornell networks	Subnets have private network connectivity to the on-campus Cornell network.
	S3 and DynamoDB gateway endpoints	Gateway endpoints for S3 and Dynamo DB in the VPC make communication with those services quick and private.	not by default
	VPC Peering	Peer to arbitrary AWS VPCs
Security	Baseline network security	Subnets use the strict variant of the Cornell Baseline AWS Network ACL, managed by the CIT Cloud Team.
	Customer-defined security groups	Customers manage and control the Security Groups applied to their resources. Thus, they have the final say about what network connectivity is allowed.
	CIDR-based access control	Subnet size allows subnet CIDR blocks to be used for meaningful network access control by your collaborators.
	Known peers	Subnets are used only by teams you know.
Cost	"Free" NAT Gateways	NAT Gateways are managed and paid for by CIT. NAT Gateways run by customers typically cost at least $1/day.
	"Free" VPC Flow Logs	VPC Flow Logs are managed and paid for by CIT.
	Pay for what you use	Customers pay for resources deployed to the Shared VPC as if they were using their own VPC. There are no additional charges for opting into either Shared VPC option.

...

Customers using the Shared VPC offerings 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, and so should not be deployed to the Shared VPC.
Large AWS EMR deployments. EMR clusters with a handful of nodes are OK.

Warning
If you configure a deployment that

does consume

consumes vast quantities of IP addresses in the Multitenant Subnets, and it is negatively affecting other Multitenant Subnets customers, the resources created by the deployment may

be

, in an urgent situation, be destroyed in order to remove or reduce the impact to other

Shared VPC customers.

customers.

Examples of services that could use lots of IPs from a subnet:

• Kubernetes clusters and the Amazon Elastic Kubernetes Service (EKS) both use large numbers of IP addresses, even for trivial deployments, and so should not be deployed to the Shared VPC.

• Large AWS EMR deployments. (EMR clusters with a handful of nodes are OK.)

  
  

• If you need to move extremely large amounts of data (e.g, more than a TB) into or out of any Shared VPC offering, please contact Cloud Support so that we can assist in plotting the most time- and cost-efficient way to accomplish this.
• We cannot customize the Network ACL used by the Shared VPC offerings for arbitrary customer needs.
  • However, since the Shared VPC is a new offering, there may be adjustments needed to accommodate reasonable use-cases we had not envisioned. Please contact Cloud Support to discuss.
• We cannot peer the Shared VPC with arbitrary AWS VPCs, whether or not those VPCs are owned by Cornell AWS accounts. All Cornell VPCs on the private Cornell network are already accessible to the Shared VPC via the Direct Connect Transit Gateway architecture.
  
  • If you have a use case where massive quantities of data are being passed between the Shared VPC and a Cornell Standard VPC, contact Cloud Support to discuss whether a direct peering would be beneficial for cost or latency efficiencies.

...