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.


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 services like Shibboleth which are designed to be accessible from the public Internet.

If you don't have any special requirements for accessing private 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) recommended
us-east-1 (N. Virginia)
us-west-2 (Oregon)
Private IPv4 space
any allocated by Technology Services
limited in size
may be managed in IPAM
Public-facing subnets
supported supported
Private-facing subnets
supported supported
Campus-facing subnets
not supported supported
VPC Peering to other Enterprise VPCs
(including Core Services VPCs)

not supported supported


In general, only choose an Enterprise VPC when you require VPC Peering Connections and/or campus-facing subnets.  If you don't need these features, choose an Independent VPC.

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 a VPC 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 below provides a simple illustration of the different communication paths for public-facing subnets and campus-facing subnets (private-facing subnets would look like campus-facing subnets, but without the direct path to campus):

More generally, the following table summarizes the communications possible (though not necessarily permitted) for each type of subnet:

  Public-facing subnet
Private-facing subnet
Campus-facing subnet
To / from private IP in same VPC
yes yes yes
To / from private IP in other VPC
(requires VPC peering)
(requires VPC peering)
(requires VPC peering)
Outbound to Internet
(including any public server)
(requires public IP or Elastic IP)
(requires NAT Gateway)
(requires NAT Gateway)
Inbound from Internet
(including campus clients)
to AWS public IP
(requires public IP or Elastic IP)
no no
Outbound to campus host
(not publicly accessible)
no no yes
Inbound from campus host
to AWS private IP
no no yes


Detailed Example

The diagram below shows an Enterprise VPC with all three types of subnets duplicated across two Availability Zones, VPC Peering Connections to a Core Services VPC and one other Enterprise VPC, and a Gateway VPC Endpoint for direct access to Amazon S3.  In practice, 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 Enterprise VPC

  1. Determine which Enterprise networking features you need:
    • VPC peering to a Core Services VPC?
    • VPN connections to support campus-facing subnets?
    • both?

  2. 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 does each subnet need to be?  (They do not all have to be the same size, but they must all be powers of two)  See also VPCs and Subnets.
    • 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.

  3. Contact Technology Services at to request an Enterprise VPC allocation.  Include the following information in your request:
    • your 12-digit AWS account number
    • how much private IPv4 space you need
    • a brief description of what the VPC will be used for (example: "production VPC for Department of Redundancy Department")
    • who should be listed as contacts (Primary, Backup, Administrative) and permissions (Change Contacts, DNS) in the Contacts Database model?

  4. Download the example 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 the chosen 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 whose route table uses both the Internet Gateway and the VPN Gateway?

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

Q: What about IPv6?