Virtual Private Cloud (VPC)

Rationale

We use AWS VPC 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-dependant infrastructure like EC2, Elastic Load Balancing, AWS Redshift, etc.
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.
It supports Subnets, which allows to have multiple network segments, each of them existing in a separate availability zone, granting network redundancy.
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.
It supports Internet gateways that provide NAT to machines with Internet access.
It supports Routing tables, allowing to customize routing inside the network.
It supports DHCP, allowing to easily assign 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 to review.

We use VPC for setting networking and security configurations for:

You can access the AWS VPC console after authenticating on AWS.
Any changes to VPC's infrastructure must be done via Merge Requests by modifying its Terraform module.
To learn how to test and apply infrastructure via Terraform, visit the Terraform Guidelines.