Documentation updates

awsdocs · Jul 12, 2018 · 0aa03ef · x4v13r64 · Jul 15, 2018 · madeddie
1 parent 1318b0b
commit 0aa03ef
Show file tree

Hide file tree

Showing 5 changed files with 7 additions and 11 deletions.
diff --git a/doc_source/DocumentHistory.md b/doc_source/DocumentHistory.md
@@ -5,7 +5,7 @@ The following table describes the Elastic Load Balancing releases and important
 
 | Feature | Description | Release Date | 
 | --- | --- | --- | 
-|  Classic Load Balancers  |  With the introduction of the new Application Load Balancers, load balancers created with the 2016\-06\-01 API are now known as *Classic Load Balancers*\. For more information about the differences between these types of load balancers, see [What is Elastic Load Balancing?](http://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) in the *Elastic Load Balancing User Guide*\.  | August 11, 2016 | 
+|  Classic Load Balancers  |  With the introduction of Application Load Balancers, load balancers created with the 2016\-06\-01 API are now known as *Classic Load Balancers*\. For more information about the differences between these types of load balancers, see [What is Elastic Load Balancing?](http://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) in the *Elastic Load Balancing User Guide*\.  | August 11, 2016 | 
 |  Support for AWS Certificate Manager \(ACM\)  |  You can request an SSL/TLS certificate from ACM and deploy it to your load balancer\. For more information, see [SSL/TLS Certificates for Classic Load Balancers](ssl-server-cert.md)\.  | January 21, 2016 | 
 |  Support for additional ports  |  Load balancers in a VPC can listen on any port in the range 1\-65535\. For more information, see [Listeners for Your Classic Load Balancer](elb-listener-config.md)\.  | September 15, 2015 | 
 |  Additional fields for access log entries  |  Added the `user_agent`, `ssl_cipher`, and `ssl_protocol` fields\. For more information, see [Access Log Files](access-log-collection.md#access-log-file-format)\.  | May 18, 2015 | 

diff --git a/doc_source/elb-cloudwatch-metrics.md b/doc_source/elb-cloudwatch-metrics.md
@@ -30,7 +30,7 @@ The `AWS/ELB` namespace includes the following metrics\.
 | Latency |  \[HTTP listener\] The total time elapsed, in seconds, from the time the load balancer sent the request to a registered instance until the instance started to send the response headers\. \[TCP listener\] The total time elapsed, in seconds, for the load balancer to successfully establish a connection to a registered instance\. **Reporting criteria**: There is a nonzero value **Statistics**: The most useful statistic is `Average`\. Use `Maximum` to determine whether some requests are taking substantially longer than the average\. Note that `Minimum` is typically not useful\. **Example**: Suppose that your load balancer has 2 instances in us\-west\-2a and 2 instances in us\-west\-2b, and that requests sent to 1 instance in us\-west\-2a have a higher latency\. The average for us\-west\-2a has a higher value than the average for us\-west\-2b\.  | 
 | RequestCount |  The number of requests completed or connections made during the specified interval \(1 or 5 minutes\)\. \[HTTP listener\] The number of requests received and routed, including HTTP error responses from the registered instances\. \[TCP listener\] The number of connections made to the registered instances\. **Reporting criteria**: There is a nonzero value **Statistics**: The most useful statistic is `Sum`\. Note that `Minimum`, `Maximum`, and `Average` all return 1\. **Example**: Suppose that your load balancer has 2 instances in us\-west\-2a and 2 instances in us\-west\-2b, and that 100 requests are sent to the load balancer\. There are 60 requests sent to us\-west\-2a, with each instance receiving 30 requests, and 40 requests sent to us\-west\-2b, with each instance receiving 20 requests\. With the `AvailabilityZone` dimension, there is a sum of 60 requests in us\-west\-2a and 40 requests in us\-west\-2b\. With the `LoadBalancerName` dimension, there is a sum of 100 requests\.  | 
 | SpilloverCount |  The total number of requests that were rejected because the surge queue is full\. \[HTTP listener\] The load balancer returns an HTTP 503 error code\. \[TCP listener\] The load balancer closes the connection\. **Reporting criteria**: There is a nonzero value **Statistics**: The most useful statistic is `Sum`\. Note that `Average`, `Minimum`, and `Maximum` are reported per load balancer node and are not typically useful\. **Example**: Suppose that your load balancer has us\-west\-2a and us\-west\-2b enabled, and that instances in us\-west\-2a are experiencing high latency and are slow to respond to requests\. As a result, the surge queue for the load balancer node in us\-west\-2a fills, resulting in spillover\. If us\-west\-2b continues to respond normally, the sum for the load balancer will be the same as the sum for us\-west\-2a\.  | 
-| SurgeQueueLength |  The total number of requests that are pending routing\. The load balancer queues a request if it is unable to establish a connection with a healthy instance in order to route the request\. The maximum size of the queue is 1,024\. Additional requests are rejected when the queue is full\. For more information, see `SpilloverCount`\. **Reporting criteria**: There is a nonzero value\.  **Statistics**: The most useful statistic is `Maximum`, because it represents the peak of queued requests\. The `Average` statistic can be useful in combination with `Minimum` and `Maximum` to determine the range of queued requests\. Note that `Sum` is not useful\. **Example**: Suppose that your load balancer has us\-west\-2a and us\-west\-2b enabled, and that instances in us\-west\-2a are experiencing high latency and are slow to respond to requests\. As a result, the surge queue for the load balancer nodes in us\-west\-2a fills, with clients likely experiencing increased response times\. If this continues, the load balancer will likely have spillovers \(see the `SpilloverCount` metric\)\. If us\-west\-2b continues to respond normally, the `max` for the load balancer will be the same as the `max` for us\-west\-2a\.  | 
+| SurgeQueueLength |  The total number of requests \(HTTP listener\) or connections \(TCP listener\) that are pending routing to a healthy instance\. The maximum size of the queue is 1,024\. Additional requests or connections are rejected when the queue is full\. For more information, see `SpilloverCount`\. **Reporting criteria**: There is a nonzero value\.  **Statistics**: The most useful statistic is `Maximum`, because it represents the peak of queued requests\. The `Average` statistic can be useful in combination with `Minimum` and `Maximum` to determine the range of queued requests\. Note that `Sum` is not useful\. **Example**: Suppose that your load balancer has us\-west\-2a and us\-west\-2b enabled, and that instances in us\-west\-2a are experiencing high latency and are slow to respond to requests\. As a result, the surge queue for the load balancer nodes in us\-west\-2a fills, with clients likely experiencing increased response times\. If this continues, the load balancer will likely have spillovers \(see the `SpilloverCount` metric\)\. If us\-west\-2b continues to respond normally, the `max` for the load balancer will be the same as the `max` for us\-west\-2a\.  | 
 | UnHealthyHostCount |  The number of unhealthy instances registered with your load balancer\. An instance is considered unhealthy after it exceeds the unhealthy threshold configured for health checks\. An unhealthy instance is considered healthy again after it meets the healthy threshold configured for health checks\. **Reporting criteria**: There are registered instances **Statistics**: The most useful statistics are `Average` and `Minimum`\. These statistics are determined by the load balancer nodes\. Note that some load balancer nodes might determine that an instance is unhealthy for a brief period while other nodes determine that it is healthy\. **Example**: See `HealthyHostCount`\.  | 
 
 <a name="estimated-metrics"></a>The following metrics enable you to estimate your costs if you migrate a Classic Load Balancer to an Application Load Balancer\. These metrics are intended for informational use only, not for use with CloudWatch alarms\. Note that if your Classic Load Balancer has multiple listeners, these metrics are aggregated across the listeners\.

diff --git a/doc_source/elb-healthchecks.md b/doc_source/elb-healthchecks.md
@@ -29,7 +29,9 @@ A health configuration contains the information that a load balancer uses to det
 |  Unhealthy Threshold  |  The number of consecutive failed health checks that must occur before declaring an EC2 instance unhealthy\. Valid values: 2 to 10 Default: 2  | 
 |  Healthy Threshold  |  The number of consecutive successful health checks that must occur before declaring an EC2 instance healthy\. Valid values: 2 to 10 Default: 10  | 
 
-The load balancer sends a request to each registered instance at the ping port and ping path every `Interval` seconds\. An instance is considered healthy if it returns a 200 response code within the health check interval\. If the health checks exceed the threshold for consecutive failed responses, the load balancer takes the instance out of service\. When the health checks exceed the threshold for consecutive successful responses, the load balancer puts the instance back in service\.
+The load balancer sends a health check request to each registered instance every `Interval` seconds, using the specified port, protocol, and ping path\. Each health check request is independent and lasts the entire interval\. The time it takes for the instance to respond does not affect the interval for the next health check\. If the health checks exceed **UnhealthyThresholdCount** consecutive failures, the load balancer takes the instance out of service\. When the health checks exceed **HealthyThresholdCount** consecutive successes, the load balancer puts the instance back in service\.
+
+An HTTP/HTTPS health check succeeds if the instance returns a 200 response code within the health check interval\. A TCP health check succeeds if the TCP connection succeeds\. An SSL health check succeeds if the SSL handshake succeeds\.
 
 ## Update the Health Check Configuration<a name="update-health-check-config"></a>
 

diff --git a/doc_source/ssl-server-cert.md b/doc_source/ssl-server-cert.md
@@ -13,7 +13,7 @@ We recommend that you use AWS Certificate Manager \(ACM\) to create or import ce
 To allow an IAM user to deploy the certificate on your load balancer using the AWS Management Console, you must allow access to the ACM `ListCertificates` API action\. For more information, see [Listing Certificates](http://docs.aws.amazon.com/acm/latest/userguide/authen-inlinepolicies.html#policy-list-certificates) in the *AWS Certificate Manager User Guide*\.
 
 **Important**  
-ACM supports RSA certificates with a 4096 key length and EC certificates\. However, you cannot install these certificates on your load balancer through integration with ACM\. You must upload these certificates to IAM in order to use them with your load balancer\.
+You cannot install certificates with 4096\-bit RSA keys or EC keys on your load balancer through integration with ACM\. You must upload certificates with 4096\-bit RSA keys or EC keys to IAM in order to use them with your load balancer\.
 
 ## Import an SSL/TLS Certificate Using IAM<a name="import-certificate-iam"></a>
 

diff --git a/doc_source/x-forwarded-headers.md b/doc_source/x-forwarded-headers.md
@@ -1,6 +1,6 @@
 # HTTP Headers and Classic Load Balancers<a name="x-forwarded-headers"></a>
 
-HTTP requests and HTTP responses use header fields to send information about the HTTP messages\. Header fields are colon\-separated name\-value pairs that are separated by a carriage return \(CR\) and a line feed \(LF\)\. A standard set of HTTP header fields is defined in RFC 2616, [Message Headers](http://tools.ietf.org/html/rfc2616#section-4.2)\. There are also non\-standard HTTP headers available that are widely used by the applications\. Some of the non\-standard HTTP headers have a `X-Forwarded` prefix\. Classic Load Balancers support the following `X-Forwarded` headers\.
+HTTP requests and HTTP responses use header fields to send information about the HTTP messages\. Header fields are colon\-separated name\-value pairs that are separated by a carriage return \(CR\) and a line feed \(LF\)\. A standard set of HTTP header fields is defined in RFC 2616, [Message Headers](http://tools.ietf.org/html/rfc2616#section-4.2)\. There are also non\-standard HTTP headers available that are widely used by the applications\. Some of the non\-standard HTTP headers have an `X-Forwarded` prefix\. Classic Load Balancers support the following `X-Forwarded` headers\.
 
 For more information about HTTP connections, see [Request Routing](http://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) in the *Elastic Load Balancing User Guide*\.
 
@@ -35,12 +35,6 @@ The following is an example `X-Forwarded-For` request header for a client with a
 X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e
 ```
 
-If a request from a client already contains an `X-Forwarded-For` header, Elastic Load Balancing appends the IP address of the client at the end of the header value\. In this case, the last IP address in the list is the IP address of the client\. For example, the following header contains two IP addresses added by the client, which might not be trustworthy, plus the client IP address added by Elastic Load Balancing: 
-
-```
-X-Forwarded-For: ip-address-1, ip-address-2, client-ip-address
-```
-
 ## X\-Forwarded\-Proto<a name="x-forwarded-proto"></a>
 
 The `X-Forwarded-Proto` request header helps you identify the protocol \(HTTP or HTTPS\) that a client used to connect to your load balancer\. Your server access logs contain only the protocol used between the server and the load balancer; they contain no information about the protocol used between the client and the load balancer\. To determine the protocol used between the client and the load balancer, use the `X-Forwarded-Proto` request header\. Elastic Load Balancing stores the protocol used between the client and the load balancer in the `X-Forwarded-Proto` request header and passes the header along to your server\.