Amazon Web Services, VPC Guide for Illinois

How to use Virtual Private Cloud (VPC) features with your University of Illinois Amazon Web Services (AWS) account.

On this page:


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

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

  Independent VPC
Enterprise VPC
Region any us-east-2 (Ohio) preferred
us-east-1 (N. Virginia)
Private IPv4 space
any allocated by Technology Services
limited in size
may be managed in IPAM
IPv6 space (optional)
Public-facing subnets
supported supported
Private-facing subnets
supported supported
Campus-facing subnets
not supported supported
VPC Attachment to Core Services Transit Gateway
not supported supported
VPC Peering to other Enterprise VPCs
not supported supported but deprecated
Dedicated VPN connections to campus
not supported
supported but deprecated


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:

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

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

  Public-facing subnet
Private-facing subnet
Campus-facing subnet
To / from private IPv4 in same VPC
yes yes yes
To / from IPv6 in same VPC
yes yes no
To / from private IPv4 in other VPC
(via Transit Gateway or VPC peering)
(via Transit Gateway or VPC peering)
(via Transit Gateway or VPC peering)
To / from IPv6 in other VPC
see "Outbound IPv6 to Internet" and "Inbound IPv6 from Internet" below
Outbound IPv4 to Internet
(or any publicly reachable server)
(requires public IP or Elastic IP)
(via NAT Gateway in your VPC)
(via NAT Gateway in your VPC or shared NAT Gateway in Core Services VPC)
Outbound IPv6 to Internet
(or any publicly reachable server)
yes yes
(via Egress-only Internet Gateway in your VPC)
Inbound IPv4 from Internet
(including campus clients)
to AWS public IP
(requires public IP or Elastic IP)
no no
Inbound IPv6 from Internet
(including campus clients)

yes no no
Outbound to campus host
(not publicly reachable)
from AWS private IPv4
no no yes
Inbound from campus host
to AWS private IPv4
no no yes


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.


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

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: can help you with subnet math.  Use e.g. `ipcalc 26 --nobinary` to display all possible /26 subnets within a hypothetical VPC allocation, and `ipcalc 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 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 12-digit AWS account number
    • 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. "production VPC for Department of Redundancy Department" if general purpose)
    • who should be listed as contacts (Primary, Backup, Administrative) and permissions (Change Contacts, DNS) in the Contacts Database model?

  3. Download the Infrastructure-as-Code from 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?

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?

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

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

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

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

Q: How much will my VPC cost?