docs: fix up production install (#453)

* docs: update production architecture diagram

* docs: fix installing guide

* docs: add back prod install diag

website/content/docs/installing/production.mdx

@@ -28,6 +28,8 @@ case can be extrapolated to almost any cloud platform to suit operator needs:
 As shown above, Boundary is broken up into its controller and worker server components across 3 [EC2 instances](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance), in
 3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate [availability zones](), with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independant [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity.
 
+The workers must be able to establish a connection to clients which they interact. In the architecture above, we place them in the public subnet so our remote client can establish a session between them and the target VM.
+
 Boundary requires an external [Postgres](https://www.postgresql.org/) and [KMS](https://aws.amazon.com/kms/). In the example above, we're using AWS managed services for these components. For Postgres, we're using [RDS](https://aws.amazon.com/rds/) and for KMS we're using Amazon's [Key Management Service](https://aws.amazon.com/kms/).
 
 ## Architecture Breakdown
@@ -160,9 +162,7 @@ kms "aead" {
 }
 ```
 
-name must be unique!
-
-### Installation
+### Install under Systemd
 
 `TYPE` below can be either `worker` or `controller`.
 
@@ -239,8 +239,4 @@ sudo systemctl start ${NAME}-${TYPE}
 
 ### Postgres Configuration
 
-TBD
-
-### KMS Configuration
-
-TBD
+Boundary prefers postgres version 11x or greater.