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:

1. 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.
2. It integrates with services that use networking-dependant infrastructure like EC2, Elastic Load Balancing, AWS Redshift, etc.
3. It complies with several certifications from ISO and CSA. Many of these certifications are focused on granting that the entity follows best practices regarding secure cloud-based environments and information security.
4. It supports Subnets, which allows to have multiple network segments, each of them existing in a separate availability zone, granting network redundancy.
5. It supports Security groups that allow to specify inbound and outbound rules for network interfaces. Such rules can be based on other security groups, IP segments, and communication protocols.
6. It supports Internet gateways that provide NAT to machines with Internet access.
7. It supports Routing tables, allowing to customize routing inside the network.
8. It supports DHCP, allowing to easily assign private IP addresses to machines as they are created.
9. Resources can be written as code using Terraform.

Alternatives​

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

Usage​

We use VPC for setting networking and security configurations for:

1. EC2 machines
2. Kubernetes cluster workers
3. Batch workers
4. Elastic Load Balancing load balancers