Introduction

...

Introduction

Cornell AWS customers now have two new options for easy access to the private Cornell network in AWS. 

• The first option, opting into to use the Shared AWS VPC, is the simplest. As the name suggests, the Shared VPC gives Cornell AWS customers access to a set of large private subnets in us-east-1. These subnets reside on the private Cornell network and their use

...

• is shared with other Cornell AWS customers. We call this option the Multitenant Subnets option.
• The

...

• second option offers exclusive access to a set of private subnets that are customized for your use. These subnets in us-east-1 can be customized with respect to size and Availability Zone location and also reside on the private Cornell network.

...

• They can also be shared with other Cornell AWS accounts that you specify. We call this option the Exclusive Use Subnets option within the Shared VPC offering.

Resources deployed to subnets in either offering The resources deployed to the the Shared VPC have network access to other Cornell network resources, specifically:

• all Cornell Standard VPCs in AWS, via Transit Gateway
• on-campus Cornell networks, via Direct Connect
• private Cornell VNets VNETs in Azure, via Internet2 Cloud Connect

In the past, each Cornell AWS customer that required access to the private Cornell network in AWS received their own Cornell Standard VPC that provided an AWS VPC for their exclusive use. In contrast, the shared Cornell AWS VPC the Multitenant Subnets option described in this document provides similar network connectivity in a set of AWS subnets shared among multiple many Cornell AWS customers. The Exclusive Use Subnets option offers the same network connectivity but sharing is amongst a set of Cornell AWS customers that you specify.

...

...

...

...

Architecture

Features

• One private subnet in each of the sic Availability Zones available in us-east-1.
• One NAT Gateway in each Availability Zone. Each private subnet routes internet-bound traffic to the NAT Gateway in the same Available Zone, providing maximal resiliency.
• 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.)

Benefits of Using the Shared VPC

Cornell AWS customers that opt-in to use the Shared VPC will experience the following benefits:

...

Features and Benefits

The following table compares the new Shared VPC options with the traditional Cornell Standard VPC.

Benefit	Feature	Description	Cornell Standard VPC	Shared VPC
				Multitenant Subnets	Exclusive Use Subnets
Ease of use	AWS Account integration	Subnets are visible directly from your AWS account, via the web console or API.
	No VPC management	Customers do not have to worry about managing a VPC. Subnet, route table, NAT gateway, endpoint, and network ACL management is performed by the CIT Cloud Team.
Fault-tolerance and Flexibility	AZ flexibility	Use subnets in any us-east-1 Availability Zone.	not by default
	Fault-tolerant internet access	Each subnet uses a NAT Gateway in the same Availability Zone as the subnet to route outgoing traffic to the public internet. A NAT Gateway failure in one zone won't affect subnets in other zones.	not by default
Privileged network access	Private Cornell addressing	Resources are assigned IP addresses from the private Cornell network. As such, they reside on the Cornell network and

...

...

Public subnets	Ability to deploy resources to public subnets, directly accessible from the internet.
Access to on-campus Cornell networks	Subnets have private network connectivity to the on-campus Cornell network.
Access to Cornell networks in Azure	Subnet have private network connectivity to private Cornell networks (VNETs) in Azure.
Access to on-campus Cornell networks	Subnets have private network connectivity to the on-campus Cornell network.
S3 and DynamoDB gateway endpoints	Gateway endpoints for S3 and Dynamo DB in the VPC make communication with those services quick and private.	not by default
VPC Peering	Peer to arbitrary AWS VPCs
Security	Baseline network security	Subnets use the Cornell Baseline AWS Network ACL, managed by the CIT Cloud Team.
	Customer-defined security groups	Customers manage and control the Security Groups applied to their resources. Thus, they have the final say about what network connectivity is allowed.
	CIDR-based access control	Subnet size allows subnet CIDR blocks to be used for meaningful network access control by your collaborators.
	Known peers	Subnets are used only by teams you know.
Cost	"Free" NAT Gateways	NAT Gateways are managed and paid for by CIT. NAT Gateways run by customers typically cost at least $1/day.
	"Free" VPC Flow Logs	VPC Flow Logs are managed and paid for by CIT.
	Pay for what you use	Customers pay for resources deployed to the Shared VPC as if they were using their own VPC. There are no additional charges for opting into either Shared VPC option.

Use Cases

Both the Multitenant Subnets and the Exclusive Use Subnets options of the Shared VPC offering support many, many

...

• The Shared VPC can be used without the need to setup and manage your own VPC.
• The CIT Cloud Team manages manages the subnets, network ACLs, and Route Tables in the Shared VPC. Customers manage the Security Groups applied to EC2 instances and other resources deployed in the Shared VPC.

...

• Each Cornell Standard VPC contains at least one NAT Gateway, which typically costs about $1/day to run. In contrast, NAT Gateways deployed in the Shared VPC are managed and paid for by CIT.
• VPC Flow Logs in the Shared VPC are paid for by CIT.

...

• Customers using the Shared VPC have access to subnets in all of the Availability Zones in the us-east-1 AWS Region. In contrast, a Cornell Standard VPC is typically deployed only to two Availability Zones.
• Each private subnet in the Shared VPC utilizes a NAT Gateway local to the Availability Zone where the subnet is deployed. In contrast, private subnets in the Cornell Standard VPC typically utilize a single NAT Gateway in a single Availability Zone.

...

• Since the Shared VPC offers access to all Availability Zones in us-east-1, customers have the option to create resources in specific AZs if they are trying to deploy resources in the same AZs used by partners or vendors.

Caveats of Using the Shared VPC

There are a few caveats to be aware of when deciding whether to opt-in to use the Shared VPC:

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

Use Cases

The Shared VPC supports many, many customer use cases. A few of those are:

• Manual deployment of a few resources that require access to the Cornell private network
• Deployment of three-tier (or more!) applications in the Shared VPC
• Using Infrastructure as Code to create and manage AWS resources in the Shared VPC
• Standing up an RDS instance in the private Cornell network
• Deploying an API Gateway API or Lambda function with access to the Cornell network
• Deployment of resources which will be accessed only by users on the Cornell VPN

...

Misuse cases are situations where the Shared VPC should not Multitenant Subnets and the Exclusive Use Subnets option should not or cannot be used. Some of those are:

• 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 the initial release of the Shared VPC offers 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 AWS VPCs
• Ability to use a vast large number of private Cornell IP addresses in AWS
• Deploying Kubernetes or using EKS (Kubernetes consumes vast numbers of IP addresses, which is incompatible with the Shared VPC model)

FAQs

Is the VPC really shared?

No, the VPC itself isn't shared. Just the subnets within the VPC are shared. However, in most cases we use "shared VPC" instead of "shared subnets in the multi-tenant VPC" since the latter is cumbersome and people generally understand the idea.

How are the VPC subnets shared?

The subnets in the VPC are shared to your Cornell AWS account using the AWS Resources Access Manager.

Do I need an AWS account to use the Shared VPC?

Yes, you still need a Cornell AWS account to use the Shared VPC. When you opt-in to use the Shared VPC, you get visibility of and permission to deploy resources to it using your Cornell AWS account.

Where do resources deployed to the Shared VPCs reside?

From a management and financial standpoint, the resources you deploy to the Shared VPC reside in your AWS account. I.e., 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 have connectivity to the Shared VPC even though the VPC is owned by another Cornell AWS account.

Can other Cornell AWS accounts access the resources I deploy to the Shared VPC?

No. The resources deployed to the Shared VPC are visible and manageable only from the AWS account from which they were created.

Can I still manage and use other VPCs if I opt into using the Shared VPC?

Yes, you can continue to create and manage custom VPCs in your Cornell AWS account even after you opt in to use the Shared VPC. However, note that you will not be able to peer your custom VPCs to the Shared VPC.

I have a Cornell AWS account without Cornell networking. How do I opt-in to use the Shared VPC?

Contact Cloud Support.

I already have a Cornell Standard VPC in my AWS account. Can I opt-in to use the Shared VPC?

We encourage Cornell AWS customers to transition to using the Shared VPC 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.

What happens if my usage "outgrows" the Shared VPC?

If you are using the Shared VPC and it no longer meets your needs (e.g., due to a new need to deploy large clusters) 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 and meet networking/VPC needs in other ways.

Who is responsible for security in the Shared VPC?

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 (X) 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.

Am I charged for using the Shared VPC?

You are charged for the resources you deploy to the Shared VPC just like you would be charged for similar 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 shared by Cornell AWS accounts.

Are there quotas or limits associated with the Shared VPC?

No. While we don't want customers to make deployments to the Shared VPC that will gobble up IP addresses, as of 28 Aug 2023 we don't have specific quotas about how many addresses each customer can use.

We centrally monitor IP address utilization in Shared VPC subnets and will reach out to customers if their usage is unexpected.

What types of resources or AWS services can I deploy to the Shared VPC?

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, as long as the service supports deployment to private subnets.

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

Requesting Access to Shared VPC Offerings

Multitenant Subnets

Send a note to Cloud Support with the following information:

• Your AWS account ID. The Multitenant Subnets will be shared to this account.
• Whether you have existing VPCs (especially Cornell Standard VPCs) in your AWS account that you will be trying to retire after you begin using the Shared VPC offerings.
• Any questions you have about using the Shared VPC offering.

Exclusive Use Subnets

Before provisioning Exclusive Use Subnets we will probably need a short meeting to discuss details. But, get the process started by sending a note to Cloud Support with the following information:

• Your AWS account ID. 
• Specifics about the subnets you wish:
  • What other AWS accounts should have access to the subnets?
  • A list of AZs where the subnets should reside. We provision one subnet per AZ.
  • The size of the subnets.
  • A label to use as a prefix for names of the subnets and related resources.
• A list of people that should be invited to a brief meeting to confirm the subnet parameters.
• Whether you have existing VPCs (especially Cornell Standard VPCs) in your AWS account that you will be trying to retire after you begin using the Shared VPC offerings.
• Any questions you have about using the Shared VPC offering.

Anchor
guidelines guidelines

Guidelines

Customers using the Shared VPC offerings 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.

  Warning
  If you configure a deployment that consumes vast quantities of IP addresses

  . For example

  in the Multitenant Subnets, and it is negatively affecting other Multitenant Subnets customers, the resources created by the deployment may, in an urgent situation, be destroyed in order to remove or reduce the impact to othercustomers.

  Examples of services that could use lots of IPs from a subnet:

  • 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 in the shared VPC and 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 customersneed to move extremely large amounts of data (e.g, more than a TB) into or out of any Shared VPC offering, please contact Cloud Support so that we can assist in plotting the most time- and cost-efficient way to accomplish this.
• 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.

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

Roadmap

Potential Features for Future Releases

.

Roadmap — Potential Features for Future Releases

• Specifics about the Share VPC resources (e.g., VPC id, subnet ids, etc.) could be created in the Systems Manager Parameter Store in customer accounts. These details could them easily be referenced from CloudFormation templates; see Using dynamic references to specify template values

...

• .
• Indirect access to shared public subnets, allowing only deployment of Application or Network Load Balancers routing to targets in private subnetsany Shared VPC offering.
• Direct access to shared public subnets for deploying arbitrary resources that can be made public.

Appendix

Architecture

Usable IP Addresses in Subnets

AWS reserves 5 addresses in each subnet for its own use. See Subnet Sizing.

References

• Cornell
  • Shared AWS VPC FAQs
  • Using the AWS Shared VPC Offerings
  • Cornell AWS Direct Connect
  • The Cornell Standard VPC
• AWS
  • AWS Resource Access Manager
  • AWS Systems Manager Parameter Store
  • Subnet Sizing