by Paul Allen
This post describes the standard AWS Virtual Private Cloud (VPC) provisioned for Cornell AWS customers by the Cornell Cloudification Service Team. This “standard” VPC is integrated with Cornell network infrastructure and provides several benefits over the default VPC provisioned to all AWS customers when a new AWS account is created.
So we don’t get confused, let’s call the VPC provisioned by the Cornell Cloudification Service Team the “Cornell VPC” and the VPC automatically provisioned by AWS the “default VPC”. AWS itself calls this latter VPC by the same name (i.e. default VPC). See AWS documentation about default VPCs.
Benefits of the Cornell VPC
Using the Cornell VPC when deploying instances from your AWS account has some distinct benefits compared to deploying to the default VPC:
- The Cornell VPC provides private subnets that are not reachable from the public internet. These private subnets are a great place to deploy database instances and other back-end services.
- Those private subnets are configured with a NAT gateway allowing instances to reach out to the public internet to get software updates, but they don’t allow traffic to the private subnets to be initiated from the public internet.
- Both the private and public subnets in a Cornell VPC have 10-space addresses integrated with (and not overlapping) the 10-space IP ranges used at Cornell.
- Traffic between your Cornell VPC subnets and campus 10-space IP addresses are routed through a VPN that connects campus to your Cornell VPC. Thus that traffic is very, very private. Eventually this same traffic will flow over an AWS Direct Connect path between campus and the AWS US Eastern region, providing lower latency and reduced bandwidth costs.
Let’s take a closer look at a typical Cornell VPC in AWS. In the AWS VPC documentation, the Cornell VPC configuration is very similar to Scenario 3: VPC with Public and Private Subnets and Hardware VPN Access.
Some features of the Cornell VPC:
- Each Cornell VPC is provisioned in the US East AWS region, which is geographically closest to Cornell.
- Within each Cornell VPC, four subnets are provisioned across two different availability zones (AZs) within the US East region. One private and one public subnet in each of two AZs provides a fault-tolerance-friendly configuration, should you decide you want to guard against failure of a single AZ.
- Across all the Cornell VPCs in the US East region, we choose the AZ assignments arbitrarily. The subnets for your VPC could reside in any two of the following AZs: us-east-1a, us-east-1b, us-east-1c, us-east-1d
- Each Cornell VPC is configured with a Virtual Private Gateway in AWS and a Customer Gateway at Cornell that provide a secure communication channel between Cornell 10-space and VPC 10-space addresses. In fact, this VPN connection is fault tolerant, because two connections are established and in use at all times, for each VPC.
- The Cornell VPC private subnets are served by a NAT Gateway that allows services running on those subnets safe connectivity to the public internet. Only internally-initiated connections are allowed through the NAT Gateway.
- The Cornell VPC public subnets are connected to the public internet through an Internet Gateway, allowing connections that are both internally-initiated and externally-initiated.
Network ACLs and Security Groups
The AWS VPC infrastructure provides several features that can help provide a very secure configuration, if used properly. The diagram below shows two of those features: Network Access Control Lists (ACLs), and Security Groups. On the diagram above showing a typical Cornell VPC, security groups and Network ACLs are not shown.
- Each VPC subnet has an associated Network ACL (NACL) that provides rules allowing or denying inbound and outbound traffic. These operate similarly to a stateless firewall. The same NACL can be used for multiple subnets.
- Each Cornell VPC uses a single NACL applied to all subnets in the VPC. It allows all incoming and outgoing traffic. The NACL(s) for your Cornell VPC can be customized, depending on your needs.
- Each AWS EC2 instance can be associated with one or more security groups that define what incoming traffic is allowed to the instance. Unlike NACLs, security groups are stateful, meaning that return traffic is automatically allowed, if the security group allowed the incoming traffic.
- Cornell VPCs don’t define any security groups. Security groups are typically defined and assigned as you determine the specifics network and service needs for particular EC2 instances.
- Changes to security group configurations take effect immediately.
- You can add and remove security groups dynamically to instances, and those changes take effect immediately.
- The AWS documentation has a nice comparison between NACLs and security groups.
Frequently Asked Questions
While the private subnets in a standard Cornell VPC allow you to hide some of your AWS infrastructure from the world, they can lead to some challenges if you are not used to using them. Below Several scenarios that folks have run into are listed below. The EC2 documentation also has some tips for troubleshooting connectivity to your EC2 instances.
Q: I’ve launched an EC2 instance in a private subnet but I can’t access it (via ssh or RDP).
A: Since the instance is connected to a private subnet, the client you are using to connect to it must be in Cornell 10-space (or some other instance in your VPC). Additionally, the instance must be assigned a security group that allows traffic from the 10-space address of your client to the instance (over port 22 for ssh and port 3389 for RDP). If your client on the Cornell network is not natively assigned a 10-space address, one easy way to get a 10-space address is to connect to a Cornell VPN on that client.
Q: I’ve launched an EC2 instance in a private subnet and assigned a public IP during launch, but I can’t access it using the public IP (via ssh or RDP).
A: It doesn’t matter that your instance has a public IP assigned by AWS. That public IP address is not accessible if the instance is assigned to a private subnet in your VPC. Try using the private IP address to connect, and make sure that your client has a Cornell 10-space address as described in the first FAQ.
Q: I’ve launched an EC2 instance in a public subnet on my VPC, but I cannot ping it using the public IP address.
A: One of the security groups assigned to your instance must allow ICMP (i.e. ping) traffic from where ever you are pinging from.
Q: I’ve launched an EC2 instance in a public subnet on my VPC, but I didn’t specify that EC2 should assign a public IP address. What do I do now?
A: The best thing to do would be to terminate the instance and relaunch with your desired specification (i.e., that a public IP address is assigned). Alternatively, you could create an Elastic IP and assign the Elastic IP to the instance, providing a publicly accessible IP address for the instance. When you terminate the instance, the Elastic IP will still be yours and you must delete the Elastic IP separately. While Elastic IPs are handy in certain situations, they cost money and are a limited resource (there is a limit on how many any AWS account can create). In this scenario it would really be best to relaunch the instance with the configuration that you intended in the first place.
Q: I have multiple VPCs. How do I tell which is the default VPC and which is the Cornell-provisioned VPC?
A: In the AWS management console for VPCs, the AWS default gateway denoted (i.e., labeled “yes”) under the “Default Gateway” column. Only the default gateway provisioned by AWS can be labeled as default. The Cornell-provisioned gateway will have a name with pattern “cu-<unit>vpc”.
Conclusion
While the standard Cornell VPC provides a lot of flexibility and security, it may not be for everyone. If you are having trouble mapping your AWS infrastructure onto the standard Cornell VPC, please contact the Cloudification Services Team to see if your VPC may need to be customized.