FAQs about the Multitenant Subnets and the Exclusive Use Subnets option within the Shared VPC offering. |
No, the VPC itself isn't shared, but we use the "shared VPC" term as a shortcut and generalization to make this easier to discuss.
The subnets in the VPC are shared to your Cornell AWS account using the AWS Resources Access Manager.
Yes, you still need a Cornell AWS account to use either Shared VPC option. When you opt-in to use the Shared VPC, you get visibility of and permission to deploy resources to its subnets using your Cornell AWS account.
Yes, you can continue to create and manage custom VPCs in your Cornell AWS account even after you opt in to use either of the Shared VPC options. However, note that you will not be able to peer your custom VPCs to the Shared VPC.
Contact Cloud Support.
We encourage Cornell AWS customers to transition to using the Shared VPC offerings if they are looking for simplicity and cost-effectiveness. Such customers can opt-in to use the Shared VPC and vacate their Cornell Standard VPC, which would be decommissioned. Contact Cloud Support if you are in this position.
There are three options to connect to EC2 instances deployed to a Shared VPC subnet:
From a management and financial standpoint, the resources you deploy to the Shared VPC subnets reside in your AWS account. You have full access to manage the resources via the AWS console or APIs, and you have full responsibility to pay for those resources via the standard Cornell AWS billing process.
From a networking perspective, those resources reside in the Shared VPC even though the VPC is owned by another Cornell AWS account.
No. The resources deployed to the Shared VPC are visible and manageable only from the AWS account from which they were created.
From a network perspective, your resources are as accessible to other resources on the Cornell network (including other resources deployed to the Shared VPC) as you allow (via settings in the Security Groups you apply to your resources). |
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.
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.
You are charged for the resources you deploy to the Shared VPC just like you would be charged for such 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 cost-shared by Cornell AWS accounts.
Probably. If you switch to a Shared VPC offering, you can probably retire NAT Gateways that you currently run to support private subnets in your own VPC(s). Similarly, you will save the costs of VPC Flow Logs if you can stop using your own VPC(s).
No. While we don't want customers to make deployments to the Shared VPC that will gobble up IP addresses, as of we don't have specific quotas about how many addresses each customer can use.
We centrally monitor IP address utilization in both Multitenant Subnets and Exclusive Use Subnets in the Shared VPC offering. We will reach out to customers if their usage seems excessive or unprecedented.
If you are using one or both of the Shared VPC options and that no longer meets your needs contact Cloud Support to request consultation about deploying a Cornell Standard VPC, which provides more flexibility than using the Shared VPC. There may also be alternatives where you could continue to use the Shared VPC offerings and meet networking/VPC needs in other ways.
Here are some indications that you are outgrowing the Shared VPC offerings:
Any resource type or AWS service can be used in the Shared VPC, as long as it does not consume large numbers of IP addresses. For example, Amazon Elastic Kubernetes Service (EKS) should not be used in the Shared VPC since it uses large number of IP addresses, even for modest deployments.
We are not aware of any AWS services that require VPCs and that won't work with the Shared VPC offerings, as long as the service supports deployment to private subnets.
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 offerings supports only private subnets, assigning an EIP to a resource deployed to the Shared VPC won't allow that resource to offer services to the public internet. I.e., there is no point to assigning an EIP to resources in the Shared VPC.