AWS Security ChangesHomeSearch

AWS whitepapers documentation change

Service: whitepapers · 2025-11-22 · Documentation low

File: whitepapers/latest/blue-green-deployments/swap-the-auto-scaling-group-behind-elastic-load-balancer.md

Summary

Updated ELB references and image caption: changed 'Elastic Load Balancing (ELB)' to 'ELB (ELB)', shortened link text, and added 'Amazon EC2' to Auto Scaling group description

Security assessment

These changes are terminology updates and editorial improvements. The security-related content about health checks and instance replacement remains unchanged. No new security features or vulnerabilities are addressed.

Diff

diff --git a/whitepapers/latest/blue-green-deployments/swap-the-auto-scaling-group-behind-elastic-load-balancer.md b/whitepapers/latest/blue-green-deployments/swap-the-auto-scaling-group-behind-elastic-load-balancer.md
index e369bccfd..9c5e5582f 100644
--- a//whitepapers/latest/blue-green-deployments/swap-the-auto-scaling-group-behind-elastic-load-balancer.md
+++ b//whitepapers/latest/blue-green-deployments/swap-the-auto-scaling-group-behind-elastic-load-balancer.md
@@ -11 +11 @@ If DNS complexities are prohibitive, consider using load balancing for traffic m
-Auto Scaling also integrates with Elastic Load Balancing (ELB), so any new instances are automatically added to the load balancing pool if they pass the health checks governed by the load balancer. ELB tests the health of your registered EC2 instances with a simple ping or a more sophisticated connection attempt or request. Health checks occur at configurable intervals and have defined thresholds to determine whether an instance is identified as healthy or unhealthy. For example, you could have an ELB health check policy that pings port 80 every 20 seconds and, after passing a threshold of 10 successful pings, health check will report the instance as being `InService`. If enough ping requests time out, then the instance is reported to be `OutofService`. With Auto Scaling, an instance that is `OutofService` could be replaced if the Auto Scaling policy dictates. Conversely, for scaled-down activities, the load balancer removes the EC2 instance from the pool and drains current connections before they terminate. 
+Auto Scaling also integrates with ELB (ELB), so any new instances are automatically added to the load balancing pool if they pass the health checks governed by the load balancer. ELB tests the health of your registered EC2 instances with a simple ping or a more sophisticated connection attempt or request. Health checks occur at configurable intervals and have defined thresholds to determine whether an instance is identified as healthy or unhealthy. For example, you could have an ELB health check policy that pings port 80 every 20 seconds and, after passing a threshold of 10 successful pings, health check will report the instance as being `InService`. If enough ping requests time out, then the instance is reported to be `OutofService`. With Auto Scaling, an instance that is `OutofService` could be replaced if the Auto Scaling policy dictates. Conversely, for scaled-down activities, the load balancer removes the EC2 instance from the pool and drains current connections before they terminate. 
@@ -13 +13 @@ Auto Scaling also integrates with Elastic Load Balancing (ELB), so any new insta
-The following figure shows the environment boundary reduced to the Auto Scaling group. A blue group carries the production load while a green group is staged and deployed with the new code. When it’s time to deploy, you simply attach the green group to the existing load balancer to introduce traffic to the new environment. For HTTP/HTTPS listeners, the load balancer favors the green Auto Scaling group because it uses a least outstanding requests routing algorithm. For more information see, [How Elastic Load Balancing Works](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/how-elb-works.html). You can also control how much traffic is introduced by adjusting the size of your green group up or down. 
+The following figure shows the environment boundary reduced to the Auto Scaling group. A blue group carries the production load while a green group is staged and deployed with the new code. When it’s time to deploy, you simply attach the green group to the existing load balancer to introduce traffic to the new environment. For HTTP/HTTPS listeners, the load balancer favors the green Auto Scaling group because it uses a least outstanding requests routing algorithm. For more information see, [How ELB Works](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/how-elb-works.html). You can also control how much traffic is introduced by adjusting the size of your green group up or down. 
@@ -15 +15 @@ The following figure shows the environment boundary reduced to the Auto Scaling
-![AWS architecture showing blue-green deployment with Auto Scaling groups and load balancing.](/images/whitepapers/latest/blue-green-deployments/images/swap-auto-scaling-group.png)
+![AWS architecture showing blue-green deployment with Amazon EC2 Auto Scaling groups and load balancing.](/images/whitepapers/latest/blue-green-deployments/images/swap-auto-scaling-group.png)