Introduction

This document provide information about using a AWS Shared VPC offering once its has been provisioned to your Cornell AWS account.

Guidelines

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.
• If you configure a deployment that does consume vast quantities of IP addresses using the Multitenant Subnets option, and it is negatively affecting other Shared VPC customers, the resources created by the deployment may be, in an urgent situation, destroyed in order to remove or reduce the impact to other Shared VPC customers.
• 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.

Best Practices for Using Shared VPC Offerings

• 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 thus 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.

What You'll See

References

• Cornell
  • DRAFT CUSTOMER DOC UPDATE - Shared AWS VPC for Cornell AWS Accounts
  • DRAFT CUSTOMER DOC UPDATE - Shared AWS VPC FAQs
  • Cornell AWS Direct Connect
  • The Cornell Standard VPC
• AWS
  • AWS Resource Access Manager
  • AWS Systems Manager Parameter Store