AWS AmazonECS documentation change
Summary
Updated documentation for canary deployments with terminology changes (ELB instead of Elastic Load Balancing), lifecycle hook stage clarifications, and added lifecycle hook support column in lifecycle stages table
Security assessment
The changes primarily improve documentation clarity and add details about lifecycle hook support. While lifecycle hooks can be used for security validation, there is no direct mention of addressing a specific security vulnerability. The added documentation about lifecycle hooks at different stages helps users implement better deployment validation practices, which could indirectly improve security posture.
Diff
diff --git a/AmazonECS/latest/developerguide/canary-deployment.md b/AmazonECS/latest/developerguide/canary-deployment.md index 3e1d9a93e..3ecef62df 100644 --- a//AmazonECS/latest/developerguide/canary-deployment.md +++ b//AmazonECS/latest/developerguide/canary-deployment.md @@ -9 +9 @@ Resources involved in a canary deploymentConsiderationsHow canary deployments wo -Canary deployments first route a small percentage of traffic to the new revision for initial testing, then shift all remaining traffic at once after the canary phase completes successfully.. With Amazon ECS canary deployments, validate new service revisions with real user traffic while minimizing risk exposure. This approach provides a controlled way to deploy changes with the ability to monitor performance and roll back quickly if issues are detected. +Canary deployments first route a small percentage of traffic to the new revision for initial testing, then shift all remaining traffic at once after the canary phase completes successfully. With Amazon ECS canary deployments, validate new service revisions with real user traffic while minimizing risk exposure. This approach provides a controlled way to deploy changes with the ability to monitor performance and roll back quickly if issues are detected. @@ -27 +27 @@ The following are resources involved in Amazon ECS canary 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 canary 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 canary 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. @@ -86 +86 @@ The canary 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. @@ -99,12 +99,12 @@ CloudFormation deployments have additional timeout restrictions. While the 24-ho -Lifecycle stages 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 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 | Canary production traffic is routed to green revision and lifecycle hook is invoked with 24 hours timeout. The second step shifts remaining production traffic to green revision. | Yes +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