...
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.
Do my resources deployed to the Shared VPC automatically have access to a target resource
...
which is also on the Cornell network?
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 similar 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.
...
No. While we don't want customers to make deployments to the Shared VPC that will gobble up IP addresses, as of 28 Aug 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 subnets and offering. We will reach out to customers if their usage is unexpectedseems excessive or unprecedented.
What types of resources or AWS services can I deploy to the Shared VPC?
...
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 offers 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 assign assigning an EIP to resources in the Shared VPC.