VPC

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: