Before the cloud revolution, technical operations gurus were wizards that magically created the network, then handed it off to us developers to implement our database and web applications. We were at their mercy to ensure that the entry points were secure and that databases were isolated from the internet. We were even more at the mercy of expensive router technology that only wizards knew how to operate.
Enter the Virtual Private Cloud. I can now create within my AWS environment a set of subnets and roles that keep environments isolated. I can separate DEV from Production. I can tear down and create whole environments using Terraform code.
For the impatient, here is a quick start to a Virtual Private Cloud.
$ git clone https://github.com/timowlmtn/vpc.git
$ # Change the profile variable to your own profile
$ cd vpc
$ make deploy
Terraform allows you to piece together components of cloud architecture using a YAML-based markup language. It has detractors and isn't appropriate for every automated configuration, but it does a good job setting up a VPC. It also has the advantage of being vendor-neutral, so you can use it to manage a cloud environment with AWS, Azure, GCP.
I like Terraform because it allows you to have separate files for configurations. For example, I can define my cloud variables in a shared file vpc-vars.tf.
The first section of the file related my AWS profile to be used.
provider "aws" {
version = "~> 2.7"
region = "us-east-1"
profile = "default-owlmtn"
}
As an aside, the AWS regions I recommend: us-west-2, us-east-1 , ca-central-1, eu-west-1, eu-central-1, ap-southeast-1, and ap-southeast-2. The reason is that these regions are well supported for many of the newest AWS features and some very important third party vendors like Snowflake.
The next section defines the overall CIDR block for the VPC. The CIDR block definition creates a range of IP address in the VPC that can be used and the /16 notation defines a mask that allows us to use 10.20.*.* for or IP address range.
variable "vpc_cidr" {
default = "10.20.0.0/16"
}
The next section defined is our public subnet. In old-school terms, this is our DMZ, because this network is publically accessible. We should be very careful about what we put on this network, if anything at all. On these sub-networks we are creating one 10.20.1.* and 10.20.2.*.
variable "public_subnet_cidr" {
type = "list"
default = ["10.20.1.0/24", "10.20.2.0/24"]
}
We are also defining private subnets ranges of of 10.20.10.* and 10.20.11.* and some masks for allowing all traffic, which I will discuss in another post.