Availability Zones

You'll notice that, in the instance creation code, I specified an Availability Zone (AZ) where the instance should reside. AZs in AWS map to local failure domains. Most regions have multiple AZs, as you can see from the previous map. The following diagram shows how AZs are connected by low-latency links within a region: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html.

We jumped ahead a little bit to get global availability of our product. Local availability should have been the first step. It provides some additional benefits that simplify our architecture. We're going to build another Terraform instance resource and deploy it into AZ 1C in the us-east1 region. Let's create a new Terraform file and call it instanceAZ1c.tf:

# Virginia 1c
resource "aws_instance" "cheap_worker1c" {
  # the below ami is for the latest Bitnami Wordpress East
  ami = "ami-001e1c1159ccfe992"
  instance_type = "t2.micro"
  availability_zone = "us-east-1c"

  tags {
    Name = "CheapWorker"
  }
}
output "id1c" {
  value = "${aws_instance.cheap_worker1c.id}"
}

Run your plan and apply. Notice that we didn't create a public IP for this instance. This reduces my attack surface and is generally the best practice. We'll see how to make this instance public facing in the Local Traffic Management section next.