VPC

Last updated: Feb 9, 2026

Rationale

We use AWS VPC (Virtual Private Cloud) for hosting our own private network in the cloud. It allows us to manage network configurations like subnets, IP addressing, Internet gateways, Routing tables, Security groups, among others.

The main reasons why we chose it over other alternatives are:

It is a core AWS service, which means that in order to be able to use other AWS services that rely on networking, one must use VPC.
It integrates with services that use networking-dependent infrastructure, such as EC2, Elastic Load Balancing, AWS Redshift, etc.
It complies with several certifications from ISO and CSA. Many of these certifications are focused on ensuring that the entity follows best practices regarding secure cloud-based environments and information security.
It supports Subnets, which allows having multiple network segments, each of which exists in a separate availability zone, granting network redundancy.
It supports Security groups that allow specifying inbound and outbound rules for network interfaces. Such rules can be based on other security groups, IP segments, and communication protocols.
It supports Internet gateways that provide NAT to machines with Internet access.
It supports Routing tables, allowing customization of routing inside the network.
It supports DHCP, allowing for easy assignment of private IP addresses to machines as they are created.
Resources can be written as code using Terraform.

Google Virtual Private Cloud (VPC): It provides a more SaaS-like approach to networking. Configuring networks is easier, but also less parameterizable.
Azure Virtual Network: It did not exist at the time we migrated to the cloud (pending review).

We use VPC for setting networking and security configurations for: