...
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
Features
Features Available at Initial Release
- One private subnet in each Availability Zone
- One NAT Gateway in each Availability Zone. Each private subnet routes internet-bound traffic to the NAT Gateway in the same Available Zone.
- Direct Connect connectivity to private and public campus networks, and to private Cornell VNets in Azure
- Connectivity to all Cornell Standard VPCs in AWS, without leaving the us-east-1 AWS Region.
- Gateway endpoints for S3 and Dynamo DB reside in the VPC making VPC communication with those services quick and private.
- If you have need for other AWS service endpoints deployed to the Shared VPC, please contact Cloud Support.
- A slightly modified version of the Baseline AWS Network ACL is applied to all private subnets. The single change is that the inbound rule allowing traffic to port 22 from the internet is removed. (Inbound traffic on port 22 is still allowed from Cornell private and public networks.)
Potential Features for Future Releases
- Indirect access to shared public subnets, allowing only deployment of Application or Network Load Balancers routing to targets in private subnets.
- Direct access to shared public subnets for deploying arbitrary resources that can be made public.
Benefits of Using the Shared VPC
...
- Deployment of resources that don't need access to the Cornell network
- Deploying a public web site or API. (Public subnets would be required to deploy a publicly accessible web site, but which the initial release of the Shared VPC does not provideoffers only private subnets.)
- Cornell private network access in regions other than us-east-1 (N. Virginia)
- Need to directly customize Network ACLs, Route Tables, or other VPC configuration
- Peering to non-Cornell VPCs
- Ability to use a vast number of private IP addresses in AWS
- Deploying Kubernetes or using EKS (Kubernetes consumes vast numbers of IP addresses, which is incompatible with the Shared VPC model)
...