...

• 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 initial release of the Shared VPC will supply only private subnets to opted-in Cornell AWS accounts. Please contact Paul Allen with feedback about your potential interest in using public subnets in the Shared VPC.
• 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:

...

We are not aware of any AWS services that require VPCs and won't work with the Shared VPC.

Can I use Elastic IPs in the Shared VPC?

There is nothing stopping you from assigning Elastic IPs to your resources in the Shared VPC. However, since the initial release of the Shared VPC offers only private subnets, assigning an EIP to a resource deployed to the Shared VPC still won't allow that resource to offer services to the public internet. I.e., there is no point to assign an EIP to resources in the Shared VPC.

Guidelines (aka Rules)

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, and so should not be deployed to the Shared VPC.
  • Large AWS EMR deployments. EMR clusters with a handful of nodes are OK.
• We cannot customize the Network ACL used by the Shared VPC 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 and time efficiencyor latency efficiencies.

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

...