Style and typo changes

source/high-availability/aws/index.html.md

@@ -71,7 +71,7 @@ to associate an Internet Gateway. On the same VPC dashboard choose
 Route Tables on the left column and give it a name and associate it to 
 our newly created VPC.
-![Subnet Creation](images/high-availability/route_table.png)
+![Route Table](images/high-availability/route_table.png)
  
  
 ### Internet Gateway
@@ -80,7 +80,7 @@ Now still on the same dashboard head over to Internet Gateways and
 create a new one. After its created pres on the `Attach to VPC` button and
 select our VPC.
-![Subnet Creation](images/high-availability/ig.png)
+![Internet Gateway](images/high-availability/ig.png)
 ### Configure Subnets
@@ -89,7 +89,7 @@ press the Routes tab on the bottom section and edit it. We need to add a
 new target which will be our Internet Gateway and have it receive 
 traffic from any destination.
     
-![Subnet Creation](images/high-availability/ig-rt.png)
+![Subnet Config](images/high-availability/ig-rt.png)
 Before leaving this screen select the next tab to the rgiht which is 
 Subnet Associations and add our public subnets. If you followed our 
@@ -108,7 +108,7 @@ create the actual RDS instance.
 From the RDS dashboard select Subnet Groups. Lets select our VPC from 
 the VPC ID dropdown and at the bottom we can add our private subnets.
-![Subnet Creation](images/high-availability/db-subnet-group.png)
+![Subnet Group](images/high-availability/db-subnet-group.png)
 ### RDS
@@ -149,16 +149,16 @@ AWS console. Now lets create a cache subnet group which will be very
 similar to the RDS subnet group. Make sure to select our VPC and its 
 private subnets.
-![Network and Security](/images/high-availability/ec-subnet.png)
+![ElastiCache](/images/high-availability/ec-subnet.png)
 Now press the Launch a Cache Cluster and choose Redis for our 
 DB engine. You'll be able to configure details such as replication, 
 Multi AZ and node types. The second section will allow us to choose our 
 subnet and security group and     
-![Network and Security](/images/high-availability/redis-cluster-det.png)
-![Network and Security](/images/high-availability/redis-net.png)
+![Redis Cluster details](/images/high-availability/redis-cluster-det.png)
+![Redis Network](/images/high-availability/redis-net.png)
 ***
@@ -171,7 +171,7 @@ The 
next section allows us to add tags and choose between General
 Purpose or 
Max I/O which is a good option when being accessed by a 
 large number of 
EC2 instances.
-

![Network and Security](/images/high-availability/elastic-file-system.png)
+

![Elastic File System](/images/high-availability/elastic-file-system.png)
 To actually mount and install the NFS client we'll use the User Data 
 section when adding our Launch Configuration.
@@ -208,7 +208,7 @@ namely `gitlab-ec2-security-group`, and edit select the RDS security
 group and edit the inbound rules. Choose the rule type to be PostgreSQL 
 and paste the name under source. 
-![Network and Security](/images/high-availability/rds-sec-group.png)
+![RDS security group](/images/high-availability/rds-sec-group.png)
 Similar to the above we'll jump to the `gitlab-ec2-security-group` group
 and add a custom TCP rule for port 6379 accessible within itself. 
@@ -250,23 +250,31 @@ number.
 While connected to your server edit the `gitlab.rb` file at `/etc/gitlab/gitlab.rb` 
 find the `external_url 'http://gitlab.example.com'` option and change it 
 to the domain you will be using or the public IP address of the current 
-instance to test the configuration. 
+instance to test the configuration.
+
+For a more detailed description about configuring GitLab read [Configuring GitLab for HA](http://docs.gitlab.com/ee/administration/high_availability/gitlab.html) 
 Now look for the GitLab database settings and uncomment as necessary. In 
 our current case we'll specify the adapter, encoding, host, db name, 
 username, and password. 
-![Network and Security](/images/high-availability/db-config.png)
+    gitlab_rails['db_adapter'] = "postgresql"
+    gitlab_rails['db_encoding'] = "unicode"    
+    gitlab_rails['db_database'] = "gitlabhq_production"   
+    gitlab_rails['db_username'] = "gitlab"
+    gitlab_rails['db_password'] = "mypassword"
+    gitlab_rails['db_host'] = "<rds-endpoint>"
 Next we only need to configure the Redis section by adding the host and 
 uncommenting the port.
-![Network and Security](/images/high-availability/redis-cluster.png)
+
 The last configuration step is to [change the default file locations ](http://docs.gitlab.com/ee/administration/high_availability/nfs.html)
 to make the EFS integration easier to manage. 
-![Network and Security](/images/high-availability/change_file_loc.png)
+    gitlab_rails['redis_host'] = "<redis-endpoint>"
+    gitlab_rails['redis_port'] = 6379
 Finally run reconfigure, you might find it useful to run a check and 
 a service status to make sure everything has been setup correctly. 
@@ -275,7 +283,6 @@ a service status to make sure everything has been setup correctly.
     sudo gitlab-rake gitlab:check  
     sudo gitlab-ctl status  
-
 If everything looks good copy the Elastic IP over to your browser and 
 test the instance manually. 
@@ -350,7 +357,7 @@ scroll down to Advanced Details we can choose to receive traffic from ELBs.
 Lets enable that option and select our ELB. We also want to use the ELB's 
 health check.
-![Network and Security](/images/high-availability/auto-scaling-det.png)
+![Auto scaling](/images/high-availability/auto-scaling-det.png)
 ### Policies
@@ -360,7 +367,7 @@ scale between 2 and 4 instances where one instance will be added if CPU
 utilization is greater than 60% and one instance is removed if it falls 
 to less than 45%. Here are the complete policies:
-![Network and Security](/images/high-availability/policies.png)
+![Policies](/images/high-availability/policies.png)
 You'll notice that after we save this AWS starts launching our two 
 instances in different AZs and without a public IP which is exactly what