On this page:

• Overview
• Do I need VPC?
• Independent vs Enterprise VPC
• Core Services VPCs
• Subnet Types
• Detailed Example
• How to Build Your Own Enterprise VPC
• Frequently Asked Questions

Overview

Amazon Virtual Private Cloud (VPC) is a logically isolated virtual network in the AWS cloud which is dedicated to your AWS account. A single AWS account may have several VPCs.

Each VPC belongs to a single Region and may contain multiple subnets; each subnet belongs to a single Availability Zone within that region, and has a single route table.

This page focuses on VPC usage recommendations which are specific to the University of Illinois. For general topics, please consult Amazon's documentation.

Do I need VPC?

Your AWS account automatically comes with a default VPC in each region (and a default public-facing subnet in each Availability Zone) which you can use for many purposes without needing to know anything about Amazon VPC.  This includes interacting with University of Illinois services like Shibboleth which are designed to be reachable from the public Internet.

If you don't have any special requirements for accessing non-public resources either on the campus network or in other AWS accounts besides your own, the default VPC may be all you need (in which case you may safely skip reading the rest of this page).

Independent vs Enterprise VPC

Technology Services describes two categories of VPCs (these are University of Illinois terms not used by Amazon):

• Enterprise VPCs must be created in coordination with Technology Services, using private IPv4 space which is centrally allocated to ensure that it will not overlap with the campus network or with other Enterprise VPCs.  This makes it possible to enable some additional networking features (detailed below).
  
  
• Independent VPCs are created freely on your own, using any private IPv4 space you choose. The default VPC is also an example of an Independent VPC.

The following table summarizes the differences between Independent and Enterprise VPCs:

Notes:

• This table introduces several new terms that will be explained in the remaining sections of this page.
• As a standard best practice, Technology Services recommends deploying Enterprise VPCs in the us-east-2 (Ohio) region in order to minimize network latency and data transfer charges, but they can also be deployed in other U.S. regions if needed.  Talk to us if you want to use a region not listed in the table above.
• If desired, you may use Technology Services IPAM to manage the private IPv4 space for an Enterprise VPC (but not for an Independent VPC), e.g. creating Host records whose reverse-mapping DNS will be visible to University clients.
• Managing DNS for your Amazon-provided public IPv4 addresses and optional IPv6 addresses works the same way for both types of VPC; see Amazon Web Services, Authoritative DNS Guide for Illinois for more information.
• An attachment to a Core Services Transit Gateway enables your VPC to communicate directly with all other attached Enterprise VPCs (including Core Services VPCs), and also provides campus-facing connectivity for your VPC's campus-facing subnets.
• A VPC Peering Connection enables your VPC to communicate directly with one other Enterprise VPC, but for most use cases this is now deprecated in favor of Transit Gateway.  (Note: it is possible on an ad-hoc basis to create a peering between two Independent VPCs if you were fortunate enough to choose non-overlapping IP space, but Enterprise VPCs generally should not peer with Independent VPCs.)
• Dedicated Site-to-Site VPN connections provide campus-facing connectivity for your VPC's campus-facing subnets, but except in unusual circumstances this is now deprecated in favor of Transit Gateway.

Core Services VPCs

Core Services VPCs are special Enterprise VPCs maintained by Technology Services in us-east-2 (Ohio) to provide direct access to the following frequently needed services without leaving the AWS cloud:

• Active Directory (see Active Directory, U of I Resources in AWS)
• Recursive DNS resolution for DNS zones which are restricted to allow queries from University clients only (see Amazon Web Services, Recursive DNS Guide for Illinois)
• shared NAT Gateways for use by campus-facing subnets

Your Enterprise VPC must have either a Transit Gateway attachment or a peering connection to a Core Services VPC in order to use these services.  Some additional configuration may also be required.

Subnet Types

Technology Services describes three categories of subnets (the first two are terms also used by Amazon, the third is specific to the University of Illinois):

• Public-facing subnets support bi-directional communication (i.e. either party can initiate a connection to the other) with any host on the public Internet.  Interfaces on a public-facing subnet still use private IPv4 addresses internally, but the AWS Internet Gateway automatically maps each private IPv4 address to an associated public or Elastic IPv4 address using one-to-one Network Address Translation (1:1 NAT).  IPv6 addresses (if optionally used) are globally unique and do not require NAT.
  
  
• Private-facing subnets cannot receive inbound connections from the public Internet.  However, they can optionally utilize a NAT Gateway (attached to a public-facing subnet) for outbound-only IPv4 access with many-to-one NAT, and/or an Egress-only Internet Gateway for outbound-only IPv6 access without NAT.
  
  
• Campus-facing subnets support bi-directional communication without NAT to campus networks at all three universities in the U of I System (some exceptions apply, see the Detailed Example).  They are otherwise similar to private-facing subnets, but currently support only IPv4 (not IPv6).

The figure and table below summarize which communications are possible for each type of subnet:

Notes:

• "Outbound to Internet" includes any server or service which is publicly reachable, even if it happens to be located on campus or in another AWS VPC.
• "Inbound from Internet" includes an on-campus host (with outbound Internet connectivity from campus) acting as a client for a publicly reachable service located in your AWS VPC.
• IPv6 communication with another VPC is possible using the "to Internet" and "from Internet" behaviors, even though the direct path via Core Services Transit Gateway is currently IPv4 only.
• Security Groups and Network ACLs may further restrict which of the possible communications are actually permitted to take place.

Detailed Example

The diagram below shows an Enterprise VPC with IPv6 enabled, all three types of subnets duplicated across two Availability Zones, a Core Services Transit Gateway attachment, and several other optional components.  Most Enterprise VPCs will not need all the elements shown here.

Notes:

• The three subnet types are differentiated by their associated route tables:
  • Public-facing subnets have a default route to the Internet via an Internet Gateway; campus-facing subnets and private-facing subnets do not (but may instead target a NAT Gateway, Egress-only Internet Gateway, and/or Transit Gateway as appropriate).
  • If you don't deploy your own NAT Gateways, campus-facing subnets (but not private-facing subnets) may target the Transit Gateway in order to utilize shared NAT Gateways in the Core Services VPC for egress.
  • Campus-facing subnets route uofi-campus-ipv4 prefixes toward the Transit Gateway.  This shared prefix list encompasses the campus networks of all three universities (see also Networking, Guide to University of Illinois IP Spaces), including RFC 1918 private IPv4 space at Urbana and NCSA but not RFC 1918 private IPv4 space at Chicago and Springfield, and also including our cloud prefixes (described next).
    
  • Public-facing and private-facing subnets route only uofi-cloud-ipv4 prefixes toward the Transit Gateway.  This shared prefix list encompasses the private IPv4 space used by other Enterprise VPCs as well as Azure VNets (see Azure, Networking ExpressRoute), but does not include any on-premises campus networks, so traffic destined for on-campus hosts will take the default (Internet) route.
• The Transit Gateway itself routes campus prefixes toward campus (across multiple VPN connections with Equal Cost Multipath), 10.x.y.0/24 toward your VPC, 10.v.w.0/24 toward Other VPC, and default toward the Core Services VPC.  The Transit Gateway also propagates the route for your VPC (10.x.y.0/24) to our on-campus routers.
• If using dedicated VPN connections (deprecated), your VPN Gateway propagates individual campus routes (e.g. 128.174.0.0/16, not shown above) into your campus-facing route tables, and propagates the route for your VPC (10.x.y.0/24) to our on-campus routers.
• Each NAT Gateway has a network interface on a particular public-facing subnet and therefore depends upon that subnet's Availability Zone.  To achieve fault tolerance, this VPC includes two separate NAT Gateways; some of the route tables shown for subnets in Availability Zone B use NAT Gateway B, while the corresponding subnets in Availability Zone A have their own separate route tables (not shown) which use NAT Gateway A instead.
• The Internet Gateway, Egress-only Internet Gateway, VPN Gateway, VPC Peering, and Gateway VPC Endpoint are not tied to any specific Availability Zone, so only one of each is needed.
• The Transit Gateway VPC attachment MUST have a network interface on one subnet in every Availability Zone used by your VPC, to ensure that all of your subnets can successfully send traffic to the Transit Gateway (see also How transit gateways work).  Since the only traffic you receive from the Transit Gateway will be destined for your VPC, it doesn't matter whether you use public-facing, campus-facing, or private-facing subnets for the attachment.
• The Interface VPC Endpoint MAY have a network interface on one subnet per Availability Zone, but only if the underlying service exists in that Availability Zone (see also Interface endpoint Availability Zone considerations).  It doesn't matter whether you use public-facing, campus-facing, or private-facing subnets for the endpoint.

Here are some concrete examples of possible (though not necessarily permitted) communications involving this VPC, with fabricated but plausible IP addresses:

• An Internet host (198.51.100.17) can communicate bi-directionally with the public or Elastic IP (52.15.99.99) associated with instance J.  This public or Elastic IP is translated by the AWS Internet Gateway to the private IP of instance J (10.x.y.140).
• A Wi-Fi client in Urbana (10.192.17.17) can initiate a connection to the public or Elastic IP (52.15.99.99) associated with instance J.  The source IP is translated by the campus exit firewall to an Urbana public IP (130.126.255.17), and the destination IP is translated by the AWS Internet Gateway to the private IP of instance J (10.x.y.140).
  View Illustration
  
• This example also applies to a Wi-Fi client in Chicago or Springfield, although the source IP addresses will be different.
• A Wi-Fi client in Urbana (10.192.17.17) can communicate bi-directionally with the private IP of instance K (10.x.y.170).  This communication traverses the Transit Gateway's VPN tunnels between AWS and campus, and does not involve NAT.
• This example also applies to any campus host with a public IPv4 address in Urbana, Chicago, or Springfield.  It does not apply to a campus host with only a private IPv4 address in Chicago or Springfield; instance K cannot initiate a connection to such a host (though it can receive one, see next example).
• A Wi-Fi client in Chicago or Springfield can initiate a connection to the private IP of instance K (10.x.y.170); in this case the client's private IP is translated to a Chicago or Springfield public IP (by that campus network) before the communication traverses the VPN tunnel.  The private IP of instance K is not translated.
• Instance K (10.x.y.170) or instance L (10.x.y.200) can initiate a connection to an Internet host (198.51.100.17).  The source IP is translated by NAT Gateway B to the NAT Gateway's own private IP (10.x.y.139) and then translated again by the AWS Internet Gateway to the Elastic IP (52.15.87.87) associated with NAT Gateway B.
• If we do not deploy NAT Gateway B, instance K (but not L) can still initiate such a connection; in this case it traverses the Transit Gateway and is translated by a shared NAT Gateway (10.224.n.139) in the Core Services VPC.
• Any instance in this VPC (10.x.y.140, 10.x.y.170, 10.x.y.200) can communicate bi-directionally with an instance in the Core Services VPC (10.224.n.17).  This communication traverses the Transit Gateway and does not involve NAT.
• Any instance in this VPC (10.x.y.140, 10.x.y.170, 10.x.y.200) can communicate bi-directionally with an instance in Other VPC (10.v.w.17).  This communication traverses a VPC Peering Connection and does not involve NAT.  Note that the VPC Peering is superfluous, since without it we would still be able to reach Other VPC via the Transit Gateway.
• Any instance in this VPC (10.x.y.140, 10.x.y.170, 10.x.y.200) can communicate bi-directionally with any other instance in this VPC.
• Any instance in this VPC (10.x.y.140, 10.x.y.170, 10.x.y.200) can initiate a connection to Amazon SNS (sns.us-east-2.amazonaws.com).  Private DNS for interface endpoints causes this name to resolve to our local endpoint network interfaces (10.x.y.38 and 10.x.y.138), so from our point of view the connection is local and does not involve NAT.  Note that both interfaces are reachable from our instance; it does not have to use the one in the same Availability Zone.
• If we do not deploy this Interface VPC Endpoint, the name will resolve to a public IP address as usual; our instances can still connect to SNS, but e.g. instance L will need to use NAT Gateway B.
• Any instance in this VPC (10.x.y.140, 10.x.y.170, 10.x.y.200) can initiate a connection to Amazon S3 (s3.us-east-2.amazonaws.com).  DNS resolves this name to a public IP address as usual, but because the destination IP matches the AWS-managed prefix list referenced in our route table, the connection traverses the Gateway VPC Endpoint and does not involve NAT.
• If we do not deploy this Gateway VPC Endpoint, our instances can still connect to S3, but e.g. instance L will need to use NAT Gateway B.
• An IPv6 Internet host (2001:db8:9999::17) can communicate bi-directionally with the IPv6 address of instance J (2001:db8:abcd:ef04::17).
• Instance L (2001:db8:abcd:ef06::17) can initiate a connection to an IPv6 Internet host (2001:db8:9999::17); this communication traverses the Egress-only Internet Gateway.

How to Build Your Own Enterprise VPC

1. Determine how much private IPv4 space you need for the entire VPC: is a /24 (256 addresses) sufficient, or do you anticipate using more than that within the near future?  Things to consider:
   
   • Which types of subnets will you need?  Almost every VPC will include public-facing subnet(s), but campus-facing and private-facing subnets are optional.
   • Do you want to use two Availability Zones instead of one (recommended)?  If so, you will need pairs of subnets as shown in the Detailed Example.
   • How large do you need each subnet to be? (see also VPCs and Subnets)
   • Hint: http://jodies.de/ipcalc can help you with subnet math.  Use e.g. `ipcalc 192.0.2.0/24 26 --nobinary` to display all possible /26 subnets within a hypothetical VPC allocation, and `ipcalc 192.0.2.0/24 27 --nobinary` to display all possible /27 subnets.
   • You are free to choose a combination of differently sized subnets, so long as the actual addresses don't overlap (i.e. the Broadcast address at the end of your first subnet must be smaller than the base Network address at the beginning of your second one, and so on).
   • VPCs cannot be resized once built.  If you do someday need more space, the recommended procedure is to create a new larger VPC, migrate your applications, and then decommission the old VPC.
   • Subnets also cannot be resized once built, but you can destroy and rebuild individual subnets inside your VPC without having to destroy the whole VPC.
     
2. Contact Technology Services at aws-support@illinois.edu to request an Enterprise VPC allocation and get your AWS account added to the appropriate resource shares.  Include the following information in your request:
   
   • your AWS Account ID (12-digit number)
   • your AWS Account Alias (e.g. uiuc-tech-services-sandbox), if known
   • which AWS region(s) you plan to use (e.g. us-east-2 Ohio)
   • how much private IPv4 space you need
   • a brief description of what the VPC will be used for, e.g.
   • "general-purpose production VPC for Department of Redundancy Department"
   • "test VPC for Foo application/project/group within Department of Redundancy Department"
   • who should be listed as contacts (Primary, Backup, Administrative) and permissions (Change Contacts, DNS) in the Contacts Database model?
     • Please list at least two Primary/Backup contacts (i.e. two Primary or one of each) and at least one Administrative contact.  See also Contact Types in Contacts Database (CDB)
3. Once you receive your allocation, download the Infrastructure-as-Code from https://github.com/techservicesillinois/aws-enterprise-vpc/ and follow the README instructions there to customize and run it.  In the middle of this process, you'll contact Technology Services again to enable Enterprise networking features for your new VPC.

As always, please feel free to contact Technology Services if you have questions or need help with any step of this process.

Frequently Asked Questions

Q: How can my service answer inbound requests from Internet clients and access private resources on campus?

• A1: Use an internet-facing Elastic Load Balancer (i.e. Application Load Balancer or Network Load Balancer) as the entry point for your service.  The load balancer itself must be associated with public-facing subnets, but it can route requests to target instances on campus-facing (and/or private-facing) subnets.
  
  
• A2: Architect your service using multiple tiers of instances.  Place the front-end instance(s) which need to answer client requests on public-facing subnets, and the back-end instance(s) which need to access private resources on campus-facing subnets.
  
  
• A3: As a last resort, it is possible to assign two network interfaces to the same EC2 instance, placing the primary interface on a campus-facing subnet and the secondary interface on a public-facing subnet.  Multihoming is not for the faint of heart; the operating system inside your EC2 instance will probably not handle it correctly out of the box, so you will have to configure and troubleshoot routing at the host level (which is tricky and very easy to get slightly wrong) before you can move on to building your service.  We recommend avoiding this scenario if at all possible.

Q: Why can't I just create a single "everywhere-facing" subnet which routes default to the Internet Gateway and campus prefixes to the Transit Gateway?

• A: This combination is not supported because it creates an asymmetry in routing and NAT behavior which effectively makes it impossible for on-campus hosts to communicate with the public or Elastic IPv4 address associated with your instance.
  
  Example: suppose client 130.126.255.17 initiates a connection to Amazon public IP 52.15.88.88, which is translated by the AWS Internet Gateway to the private IP of instance J (10.x.y.170) on such a subnet.  When the instance replies, the destination IP 130.126.255.17 will match a uofi-campus-ipv4 prefix (130.126.0.0/16), so the reply packet will be routed to the Transit Gateway (and across its shared VPN connection) with untranslated source address 10.x.y.170 rather than traversing the Internet Gateway and having its source address translated back to 52.15.88.88.  The client is expecting a reply from 52.15.88.88, so it ignores this unsolicited packet from 10.x.y.170, and the connection fails to establish.

Q: Will my resources in public- and private-facing subnets automatically use IPv6?

• A: Not necessarily.  Even though a subnet is enabled for IPv6, you might not choose to assign an IPv6 address to every instance on that subnet, or the operating system inside your instance might not be configured for IPv6 and DHCPv6.

Q: Why isn't IPv6 supported for campus-facing subnets and Core Services Transit Gateway?

• A: Like an IPv4 Elastic IP address, the Amazon-provided IPv6 CIDR block for your VPC is globally unique but arbitrary, and reusable once you relinquish it.  Thus, unlike our private IPv4 allocations for Enterprise VPCs which are easily recognizable as University of Illinois IP Spaces, there is no easily scalable way for the network infrastructure on campus or in other Enterprise VPCs to distinguish IPv6 CIDR blocks presently assigned to University of Illinois AWS accounts (and thus deserving of hypothetical special routing treatment) from IPv6 CIDR blocks assigned to other AWS customers.
  
  One potentially promising solution is Bring your own IP addresses (BYOIP) with a /48 prefix of our own, but unfortunately it is not possible (as of June 2021) to share the prefix among many AWS accounts using AWS Resource Access Manager.  We remain hopeful that AWS may provide this feature at some point in the future.

Q: Why can't private-facing subnets utilize shared NAT Gateways?

• A: Adding a default route toward the Transit Gateway would effectively make the subnet campus-facing instead of private-facing (but only for IPv4, resulting in a confusing disparity).

Q: Do I need private-facing subnets?  What is the purpose of including private-facing subnets in a VPC?

• A1: In a multi-tier service architecture, putting back-end resources on private-facing subnets guarantees that they will never be accessible (inbound) from the public Internet.  However, you can use Security Groups to achieve the same goal for individual instances on public-facing subnets, so the question of whether this is valuable in practice comes down to a design preference; some people regard private-facing subnets as a useful conceptual boundary and/or an extra layer of protection (e.g. in case of accidental Security Group misconfiguration).
  
  
• A2: The fact that all outbound IPv4 connections from a private-facing subnet to the public Internet appear to come from a predictable IPv4 address (the Elastic IP of the NAT Gateway) may have practical value in some use cases.  Similar predictability can be achieved for individual instances on public-facing subnets by explicitly assigning an Elastic IP to each one, but that tactic doesn't generalize to more than a few instances or to Auto Scaling deployments.  Note that campus-facing subnets offer a looser degree of predictability which may be sufficient.
  
  
• A3: Many customers don't need them, and omitting them may help you save money by not deploying your own NAT Gateways.

Q: How much will my VPC cost?

• A: Please refer to AWS Pricing for authoritative information.  However, the following resources are noteworthy in that they incur hourly costs even when actual utilization is minimal:
  
  • Transit Gateway attachments (pricing)
  • NAT Gateways (pricing)
  • dedicated Site-to-Site VPN connections to campus (pricing)
  • Interface VPC endpoints (pricing), though not Gateway VPC endpoints
  
  For modest volume use cases, it is typically more economical to utilize the shared NAT Gateways and shared VPN connections (despite the addition of per-GB data charges from the Transit Gateway) than to deploy your own NAT Gateways and dedicated VPN connections.