AWS Security ChangesHomeSearch

AWS AmazonECS documentation change

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

File: AmazonECS/latest/developerguide/deployment-type-linear.md

Summary

Updated ELB terminology and added lifecycle hook support details to deployment stages table

Security assessment

Changes involve terminology updates (Elastic Load Balancing → ELB) and operational clarifications about lifecycle hooks. No security vulnerabilities, configurations, or mitigations are mentioned. The lifecycle hook timeout clarification is an operational detail without security implications.

Diff

diff --git a/AmazonECS/latest/developerguide/deployment-type-linear.md b/AmazonECS/latest/developerguide/deployment-type-linear.md
index 3cef1c1e9..757e65e72 100644
--- a//AmazonECS/latest/developerguide/deployment-type-linear.md
+++ b//AmazonECS/latest/developerguide/deployment-type-linear.md
@@ -27 +27 @@ The following are resources involved in Amazon ECS linear deployments:
-  * Target group - An Elastic Load Balancing resource used to route requests to one or more registered targets (for example, EC2 instances). When you create a listener, you specify a target group for its default action. Traffic is forwarded to the target group specified in the listener rule.
+  * Target group - An ELB resource used to route requests to one or more registered targets (for example, EC2 instances). When you create a listener, you specify a target group for its default action. Traffic is forwarded to the target group specified in the listener rule.
@@ -29 +29 @@ The following are resources involved in Amazon ECS linear deployments:
-  * Listener - A Elastic Load Balancing resource that checks for connection requests using the protocol and port that you configure. The rules that you define for a listener determine how Amazon ECS routes requests to its registered targets.
+  * Listener - A ELB resource that checks for connection requests using the protocol and port that you configure. The rules that you define for a listener determine how Amazon ECS routes requests to its registered targets.
@@ -31 +31 @@ The following are resources involved in Amazon ECS linear deployments:
-  * Rule - An Elastic Load Balancing resource associated with a listener. A rule defines how requests are routed and consists of an action, condition, and priority.
+  * Rule - An ELB resource associated with a listener. A rule defines how requests are routed and consists of an action, condition, and priority.
@@ -88 +88 @@ The linear traffic shift phase follows these steps:
-  * Lifecycle hooks - Optional Lambda functions can be executed at various stages during the deployment to perform automated validation, monitoring, or custom logic. Lambda functions or lifecycle hooks configured for PRODUCTION_TRAFFIC_SHIFT will be invoked at every production traffic shift step.
+  * Lifecycle hooks - Optional Lambda functions can be executed at various lifecycle stages during the deployment to perform automated validation, monitoring, or custom logic. Lambda functions or lifecycle hooks configured for PRODUCTION_TRAFFIC_SHIFT will be invoked at every production traffic shift step.
@@ -101,12 +101,12 @@ CloudFormation deployments have additional timeout restrictions. While the 24-ho
-Lifecycle stages | Description  
----|---  
-RECONCILE_SERVICE | This stage only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state.  
-PRE_SCALE_UP | The green service revision has not started. The blue service revision is handling 100% of the production traffic. There is no test traffic.  
-SCALE_UP | The time when the green service revision scales up to 100% and launches new tasks. The green service revision is not serving any traffic at this point.  
-POST_SCALE_UP | The green service revision has started. The blue service revision is handling 100% of the production traffic. There is no test traffic.  
-TEST_TRAFFIC_SHIFT | The blue and green service revisions are running. The blue service revision handles 100% of the production traffic. The green service revision is migrating from 0% to 100% of test traffic.  
-POST_TEST_TRAFFIC_SHIFT | The test traffic shift is complete. The green service revision handles 100% of the test traffic.  
-PRODUCTION_TRAFFIC_SHIFT | Traffic is gradually shifted from blue to green in equal percentage increments until green receives 100% of traffic. Each traffic shift step can last upto 24 hours.  
-POST_PRODUCTION_TRAFFIC_SHIFT | The production traffic shift is complete.  
-BAKE_TIME | The duration when both blue and green service revisions are running simultaneously.  
-CLEAN_UP | The blue service revision has completely scaled down to 0 running tasks. The green service revision is now the production service revision after this stage.  
+Lifecycle stages | Description | Lifecycle hook support  
+---|---|---  
+RECONCILE_SERVICE | This stage only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state. | Yes  
+PRE_SCALE_UP | The green service revision has not started. The blue service revision is handling 100% of the production traffic. There is no test traffic. | Yes  
+SCALE_UP | The time when the green service revision scales up to 100% and launches new tasks. The green service revision is not serving any traffic at this point. | No  
+POST_SCALE_UP | The green service revision has started. The blue service revision is handling 100% of the production traffic. There is no test traffic. | Yes  
+TEST_TRAFFIC_SHIFT | The blue and green service revisions are running. The blue service revision handles 100% of the production traffic. The green service revision is migrating from 0% to 100% of test traffic. | Yes  
+POST_TEST_TRAFFIC_SHIFT | The test traffic shift is complete. The green service revision handles 100% of the test traffic. | Yes  
+PRODUCTION_TRAFFIC_SHIFT | Traffic is gradually shifted from blue to green in equal percentage increments until green receives 100% of traffic. Each traffic shift invokes lifecycle hook with 24 hours timeout.  
+POST_PRODUCTION_TRAFFIC_SHIFT | The production traffic shift is complete. | Yes  
+BAKE_TIME | The duration when both blue and green service revisions are running simultaneously. | No  
+CLEAN_UP | The blue service revision has completely scaled down to 0 running tasks. The green service revision is now the production service revision after this stage. | No