...
Customers cannot use the Shared VPC to deploy systems that utilize large quantities of IPv4 addresses.
Warning If you configure a deployment that 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, in an urgent situation, be destroyed in order to remove or reduce the impact to othercustomers.
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.
...