aws-cdk-lib 2.206.0__py3-none-any.whl → 2.208.0__py3-none-any.whl

aws_cdk/aws_ecs/__init__.py

@@ -8701,9 +8701,9 @@ class CfnService(
         :param capacity_provider_strategy: The capacity provider strategy to use for the service. If a ``capacityProviderStrategy`` is specified, the ``launchType`` parameter must be omitted. If no ``capacityProviderStrategy`` or ``launchType`` is specified, the ``defaultCapacityProviderStrategy`` for the cluster is used. A capacity provider strategy can contain a maximum of 20 capacity providers. .. epigraph:: To remove this property from your service resource, specify an empty ``CapacityProviderStrategyItem`` array.
         :param cluster: The short name or full Amazon Resource Name (ARN) of the cluster that you run your service on. If you do not specify a cluster, the default cluster is assumed.
         :param deployment_configuration: Optional deployment parameters that control how many tasks run during the deployment and the ordering of stopping and starting tasks.
-        :param deployment_controller: The deployment controller to use for the service. If no deployment controller is specified, the default value of ``ECS`` is used.
+        :param deployment_controller: The deployment controller to use for the service.
         :param desired_count: The number of instantiations of the specified task definition to place and keep running in your service. For new services, if a desired count is not specified, a default value of ``1`` is used. When using the ``DAEMON`` scheduling strategy, the desired count is not required. For existing services, if a desired count is not specified, it is omitted from the operation.
-        :param enable_ecs_managed_tags: Specifies whether to turn on Amazon ECS managed tags for the tasks within the service. For more information, see `Tagging your Amazon ECS resources <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html>`_ in the *Amazon Elastic Container Service Developer Guide* . When you use Amazon ECS managed tags, you need to set the ``propagateTags`` request parameter.
+        :param enable_ecs_managed_tags: Specifies whether to turn on Amazon ECS managed tags for the tasks within the service. For more information, see `Tagging your Amazon ECS resources <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html>`_ in the *Amazon Elastic Container Service Developer Guide* . When you use Amazon ECS managed tags, you must set the ``propagateTags`` request parameter.
         :param enable_execute_command: Determines whether the execute command functionality is turned on for the service. If ``true`` , the execute command functionality is turned on for all containers in tasks as part of the service.
         :param health_check_grace_period_seconds: The period of time, in seconds, that the Amazon ECS service scheduler ignores unhealthy Elastic Load Balancing, VPC Lattice, and container health checks after a task has first started. If you don't specify a health check grace period value, the default value of ``0`` is used. If you don't use any of the health checks, then ``healthCheckGracePeriodSeconds`` is unused. If your service's tasks take a while to start and respond to health checks, you can specify a health check grace period of up to 2,147,483,647 seconds (about 69 years). During that time, the Amazon ECS service scheduler ignores health check status. This grace period can prevent the service scheduler from marking tasks as unhealthy and stopping them before they have time to come up.
         :param launch_type: The launch type on which to run your service. For more information, see `Amazon ECS Launch Types <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
@@ -9239,11 +9239,14 @@ class CfnService(
             role_arn: typing.Optional[builtins.str] = None,
             test_listener_rule: typing.Optional[builtins.str] = None,
         ) -> None:
-            '''
-            :param alternate_target_group_arn: 
-            :param production_listener_rule: 
-            :param role_arn: 
-            :param test_listener_rule: 
+            '''The advanced settings for a load balancer used in blue/green deployments.
+
+            Specify the alternate target group, listener rules, and IAM role required for traffic shifting during blue/green deployments. For more information, see `Required resources for Amazon ECS blue/green deployments <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-deployment-implementation.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
+
+            :param alternate_target_group_arn: The Amazon Resource Name (ARN) of the alternate target group for Amazon ECS blue/green deployments.
+            :param production_listener_rule: The Amazon Resource Name (ARN) that that identifies the production listener rule (in the case of an Application Load Balancer) or listener (in the case for an Network Load Balancer) for routing production traffic.
+            :param role_arn: The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call the Elastic Load Balancing APIs for you.
+            :param test_listener_rule: The Amazon Resource Name (ARN) that identifies ) that identifies the test listener rule (in the case of an Application Load Balancer) or listener (in the case for an Network Load Balancer) for routing test traffic.
 
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html
             :exampleMetadata: fixture=_generated
@@ -9281,7 +9284,8 @@ class CfnService(
 
         @builtins.property
         def alternate_target_group_arn(self) -> builtins.str:
-            '''
+            '''The Amazon Resource Name (ARN) of the alternate target group for Amazon ECS blue/green deployments.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html#cfn-ecs-service-advancedconfiguration-alternatetargetgrouparn
             '''
             result = self._values.get("alternate_target_group_arn")
@@ -9290,7 +9294,8 @@ class CfnService(
 
         @builtins.property
         def production_listener_rule(self) -> typing.Optional[builtins.str]:
-            '''
+            '''The Amazon Resource Name (ARN) that that identifies the production listener rule (in the case of an Application Load Balancer) or listener (in the case for an Network Load Balancer) for routing production traffic.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html#cfn-ecs-service-advancedconfiguration-productionlistenerrule
             '''
             result = self._values.get("production_listener_rule")
@@ -9298,7 +9303,8 @@ class CfnService(
 
         @builtins.property
         def role_arn(self) -> typing.Optional[builtins.str]:
-            '''
+            '''The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call the Elastic Load Balancing APIs for you.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html#cfn-ecs-service-advancedconfiguration-rolearn
             '''
             result = self._values.get("role_arn")
@@ -9306,7 +9312,8 @@ class CfnService(
 
         @builtins.property
         def test_listener_rule(self) -> typing.Optional[builtins.str]:
-            '''
+            '''The Amazon Resource Name (ARN) that identifies ) that identifies the test listener rule (in the case of an Application Load Balancer) or listener (in the case for an Network Load Balancer) for routing test traffic.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html#cfn-ecs-service-advancedconfiguration-testlistenerrule
             '''
             result = self._values.get("test_listener_rule")
@@ -9555,7 +9562,7 @@ class CfnService(
 
             When the alarms are generated, Amazon ECS sets the service deployment to failed. Set the rollback parameter to have Amazon ECS to roll back your service to the last completed deployment after a failure.
 
-            You can only use the ``DeploymentAlarms`` method to detect failures when the ``DeploymentController`` is set to ``ECS`` (rolling update).
+            You can only use the ``DeploymentAlarms`` method to detect failures when the ``DeploymentController`` is set to ``ECS`` .
 
             For more information, see `Rolling update <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html>`_ in the **Amazon Elastic Container Service Developer Guide** .
 
@@ -9741,12 +9748,12 @@ class CfnService(
             '''Optional deployment parameters that control how many tasks run during a deployment and the ordering of stopping and starting tasks.
 
             :param alarms: Information about the CloudWatch alarms.
-            :param bake_time_in_minutes: 
+            :param bake_time_in_minutes: The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted. The following rules apply when you don't specify a value: - For rolling deployments, the value is set to 3 hours (180 minutes). - When you use an external deployment controller ( ``EXTERNAL`` ), or the CodeDeploy blue/green deployment controller ( ``CODE_DEPLOY`` ), the value is set to 3 hours (180 minutes). - For all other cases, the value is set to 36 hours (2160 minutes).
             :param deployment_circuit_breaker: .. epigraph:: The deployment circuit breaker can only be used for services using the rolling update ( ``ECS`` ) deployment type. The *deployment circuit breaker* determines whether a service deployment will fail if the service can't reach a steady state. If you use the deployment circuit breaker, a service deployment will transition to a failed state and stop launching new tasks. If you use the rollback option, when a service deployment fails, the service is rolled back to the last deployment that completed successfully. For more information, see `Rolling update <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html>`_ in the *Amazon Elastic Container Service Developer Guide*
-            :param lifecycle_hooks: 
+            :param lifecycle_hooks: An array of deployment lifecycle hook objects to run custom logic at specific stages of the deployment lifecycle.
             :param maximum_percent: If a service is using the rolling update ( ``ECS`` ) deployment type, the ``maximumPercent`` parameter represents an upper limit on the number of your service's tasks that are allowed in the ``RUNNING`` or ``PENDING`` state during a deployment, as a percentage of the ``desiredCount`` (rounded down to the nearest integer). This parameter enables you to define the deployment batch size. For example, if your service is using the ``REPLICA`` service scheduler and has a ``desiredCount`` of four tasks and a ``maximumPercent`` value of 200%, the scheduler may start four new tasks before stopping the four older tasks (provided that the cluster resources required to do this are available). The default ``maximumPercent`` value for a service using the ``REPLICA`` service scheduler is 200%. The Amazon ECS scheduler uses this parameter to replace unhealthy tasks by starting replacement tasks first and then stopping the unhealthy tasks, as long as cluster resources for starting replacement tasks are available. For more information about how the scheduler replaces unhealthy tasks, see `Amazon ECS services <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html>`_ . If a service is using either the blue/green ( ``CODE_DEPLOY`` ) or ``EXTERNAL`` deployment types, and tasks in the service use the EC2 launch type, the *maximum percent* value is set to the default value. The *maximum percent* value is used to define the upper limit on the number of the tasks in the service that remain in the ``RUNNING`` state while the container instances are in the ``DRAINING`` state. .. epigraph:: You can't specify a custom ``maximumPercent`` value for a service that uses either the blue/green ( ``CODE_DEPLOY`` ) or ``EXTERNAL`` deployment types and has tasks that use the EC2 launch type. If the service uses either the blue/green ( ``CODE_DEPLOY`` ) or ``EXTERNAL`` deployment types, and the tasks in the service use the Fargate launch type, the maximum percent value is not used. The value is still returned when describing your service.
             :param minimum_healthy_percent: If a service is using the rolling update ( ``ECS`` ) deployment type, the ``minimumHealthyPercent`` represents a lower limit on the number of your service's tasks that must remain in the ``RUNNING`` state during a deployment, as a percentage of the ``desiredCount`` (rounded up to the nearest integer). This parameter enables you to deploy without using additional cluster capacity. For example, if your service has a ``desiredCount`` of four tasks and a ``minimumHealthyPercent`` of 50%, the service scheduler may stop two existing tasks to free up cluster capacity before starting two new tasks. If any tasks are unhealthy and if ``maximumPercent`` doesn't allow the Amazon ECS scheduler to start replacement tasks, the scheduler stops the unhealthy tasks one-by-one — using the ``minimumHealthyPercent`` as a constraint — to clear up capacity to launch replacement tasks. For more information about how the scheduler replaces unhealthy tasks, see `Amazon ECS services <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html>`_ . For services that *do not* use a load balancer, the following should be noted: - A service is considered healthy if all essential containers within the tasks in the service pass their health checks. - If a task has no essential containers with a health check defined, the service scheduler will wait for 40 seconds after a task reaches a ``RUNNING`` state before the task is counted towards the minimum healthy percent total. - If a task has one or more essential containers with a health check defined, the service scheduler will wait for the task to reach a healthy status before counting it towards the minimum healthy percent total. A task is considered healthy when all essential containers within the task have passed their health checks. The amount of time the service scheduler can wait for is determined by the container health check settings. For services that *do* use a load balancer, the following should be noted: - If a task has no essential containers with a health check defined, the service scheduler will wait for the load balancer target group health check to return a healthy status before counting the task towards the minimum healthy percent total. - If a task has an essential container with a health check defined, the service scheduler will wait for both the task to reach a healthy status and the load balancer target group health check to return a healthy status before counting the task towards the minimum healthy percent total. The default value for a replica service for ``minimumHealthyPercent`` is 100%. The default ``minimumHealthyPercent`` value for a service using the ``DAEMON`` service schedule is 0% for the AWS CLI , the AWS SDKs, and the APIs and 50% for the AWS Management Console. The minimum number of healthy tasks during a deployment is the ``desiredCount`` multiplied by the ``minimumHealthyPercent`` /100, rounded up to the nearest integer value. If a service is using either the blue/green ( ``CODE_DEPLOY`` ) or ``EXTERNAL`` deployment types and is running tasks that use the EC2 launch type, the *minimum healthy percent* value is set to the default value. The *minimum healthy percent* value is used to define the lower limit on the number of the tasks in the service that remain in the ``RUNNING`` state while the container instances are in the ``DRAINING`` state. .. epigraph:: You can't specify a custom ``minimumHealthyPercent`` value for a service that uses either the blue/green ( ``CODE_DEPLOY`` ) or ``EXTERNAL`` deployment types and has tasks that use the EC2 launch type. If a service is using either the blue/green ( ``CODE_DEPLOY`` ) or ``EXTERNAL`` deployment types and is running tasks that use the Fargate launch type, the minimum healthy percent value is not used, although it is returned when describing your service.
-            :param strategy: 
+            :param strategy: The deployment strategy for the service. Choose from these valid values:. - ``ROLLING`` - When you create a service which uses the rolling update ( ``ROLLING`` ) deployment strategy, the Amazon ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that Amazon ECS adds or removes from the service during a rolling update is controlled by the service deployment configuration. - ``BLUE_GREEN`` - A blue/green deployment strategy ( ``BLUE_GREEN`` ) is a release methodology that reduces downtime and risk by running two identical production environments called blue and green. With Amazon ECS blue/green deployments, you can validate new service revisions before directing production traffic to them. This approach provides a safer way to deploy changes with the ability to quickly roll back if needed.
 
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html
             :exampleMetadata: fixture=_generated
@@ -9816,7 +9823,14 @@ class CfnService(
 
         @builtins.property
         def bake_time_in_minutes(self) -> typing.Optional[jsii.Number]:
-            '''
+            '''The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted.
+
+            The following rules apply when you don't specify a value:
+
+            - For rolling deployments, the value is set to 3 hours (180 minutes).
+            - When you use an external deployment controller ( ``EXTERNAL`` ), or the CodeDeploy blue/green deployment controller ( ``CODE_DEPLOY`` ), the value is set to 3 hours (180 minutes).
+            - For all other cases, the value is set to 36 hours (2160 minutes).
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-baketimeinminutes
             '''
             result = self._values.get("bake_time_in_minutes")
@@ -9841,7 +9855,8 @@ class CfnService(
         def lifecycle_hooks(
             self,
         ) -> typing.Optional[typing.Union[_IResolvable_da3f097b, typing.List[typing.Union[_IResolvable_da3f097b, "CfnService.DeploymentLifecycleHookProperty"]]]]:
-            '''
+            '''An array of deployment lifecycle hook objects to run custom logic at specific stages of the deployment lifecycle.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-lifecyclehooks
             '''
             result = self._values.get("lifecycle_hooks")
@@ -9904,7 +9919,11 @@ class CfnService(
 
         @builtins.property
         def strategy(self) -> typing.Optional[builtins.str]:
-            '''
+            '''The deployment strategy for the service. Choose from these valid values:.
+
+            - ``ROLLING`` - When you create a service which uses the rolling update ( ``ROLLING`` ) deployment strategy, the Amazon ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that Amazon ECS adds or removes from the service during a rolling update is controlled by the service deployment configuration.
+            - ``BLUE_GREEN`` - A blue/green deployment strategy ( ``BLUE_GREEN`` ) is a release methodology that reduces downtime and risk by running two identical production environments called blue and green. With Amazon ECS blue/green deployments, you can validate new service revisions before directing production traffic to them. This approach provides a safer way to deploy changes with the ability to quickly roll back if needed.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-strategy
             '''
             result = self._values.get("strategy")
@@ -9930,7 +9949,7 @@ class CfnService(
         def __init__(self, *, type: typing.Optional[builtins.str] = None) -> None:
             '''The deployment controller to use for the service.
 
-            :param type: The deployment controller type to use. There are three deployment controller types available:. - **ECS** - The rolling update ( ``ECS`` ) deployment type involves replacing the current running version of the container with the latest version. The number of containers Amazon ECS adds or removes from the service during a rolling update is controlled by adjusting the minimum and maximum number of healthy tasks allowed during a service deployment, as specified in the `DeploymentConfiguration <https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeploymentConfiguration.html>`_ . - **CODE_DEPLOY** - The blue/green ( ``CODE_DEPLOY`` ) deployment type uses the blue/green deployment model powered by AWS CodeDeploy , which allows you to verify a new deployment of a service before sending production traffic to it. - **EXTERNAL** - The external ( ``EXTERNAL`` ) deployment type enables you to use any third-party deployment controller for full control over the deployment process for an Amazon ECS service.
+            :param type: The deployment controller type to use. The deployment controller is the mechanism that determines how tasks are deployed for your service. The valid options are: - ECS When you create a service which uses the ``ECS`` deployment controller, you can choose between the following deployment strategies: - ``ROLLING`` : When you create a service which uses the *rolling update* ( ``ROLLING`` ) deployment strategy, the Amazon ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that Amazon ECS adds or removes from the service during a rolling update is controlled by the service deployment configuration. Rolling update deployments are best suited for the following scenarios: - Gradual service updates: You need to update your service incrementally without taking the entire service offline at once. - Limited resource requirements: You want to avoid the additional resource costs of running two complete environments simultaneously (as required by blue/green deployments). - Acceptable deployment time: Your application can tolerate a longer deployment process, as rolling updates replace tasks one by one. - No need for instant roll back: Your service can tolerate a rollback process that takes minutes rather than seconds. - Simple deployment process: You prefer a straightforward deployment approach without the complexity of managing multiple environments, target groups, and listeners. - No load balancer requirement: Your service doesn't use or require a load balancer, Application Load Balancer , Network Load Balancer , or Service Connect (which are required for blue/green deployments). - Stateful applications: Your application maintains state that makes it difficult to run two parallel environments. - Cost sensitivity: You want to minimize deployment costs by not running duplicate environments during deployment. Rolling updates are the default deployment strategy for services and provide a balance between deployment safety and resource efficiency for many common application scenarios. - ``BLUE_GREEN`` : A *blue/green* deployment strategy ( ``BLUE_GREEN`` ) is a release methodology that reduces downtime and risk by running two identical production environments called blue and green. With Amazon ECS blue/green deployments, you can validate new service revisions before directing production traffic to them. This approach provides a safer way to deploy changes with the ability to quickly roll back if needed. Amazon ECS blue/green deployments are best suited for the following scenarios: - Service validation: When you need to validate new service revisions before directing production traffic to them - Zero downtime: When your service requires zero-downtime deployments - Instant roll back: When you need the ability to quickly roll back if issues are detected - Load balancer requirement: When your service uses Application Load Balancer , Network Load Balancer , or Service Connect - External Use a third-party deployment controller. - Blue/green deployment (powered by CodeDeploy ) CodeDeploy installs an updated version of the application as a new replacement task set and reroutes production traffic from the original application task set to the replacement task set. The original task set is terminated after a successful deployment. Use this deployment controller to verify a new deployment of a service before sending production traffic to it. When updating the deployment controller for a service, consider the following depending on the type of migration you're performing. - If you have a template that contains the ``EXTERNAL`` deployment controller information as well as ``TaskSet`` and ``PrimaryTaskSet`` resources, and you remove the task set resources from the template when updating from ``EXTERNAL`` to ``ECS`` , the ``DescribeTaskSet`` and ``DeleteTaskSet`` API calls will return a 400 error after the deployment controller is updated to ``ECS`` . This results in a delete failure on the task set resources, even though the stack transitions to ``UPDATE_COMPLETE`` status. For more information, see `Resource removed from stack but not deleted <https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted>`_ in the AWS CloudFormation User Guide. To fix this issue, delete the task sets directly using the Amazon ECS ``DeleteTaskSet`` API. For more information about how to delete a task set, see `DeleteTaskSet <https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html>`_ in the Amazon Elastic Container Service API Reference. - If you're migrating from ``CODE_DEPLOY`` to ``ECS`` with a new task definition and AWS CloudFormation performs a rollback operation, the Amazon ECS ``UpdateService`` request fails with the following error: Resource handler returned message: "Invalid request provided: Unable to update task definition on services with a CODE_DEPLOY deployment controller. - After a successful migration from ``ECS`` to ``EXTERNAL`` deployment controller, you need to manually remove the ``ACTIVE`` task set, because Amazon ECS no longer manages the deployment. For information about how to delete a task set, see `DeleteTaskSet <https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html>`_ in the Amazon Elastic Container Service API Reference.
 
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentcontroller.html
             :exampleMetadata: fixture=_generated
@@ -9954,11 +9973,53 @@ class CfnService(
 
         @builtins.property
         def type(self) -> typing.Optional[builtins.str]:
-            '''The deployment controller type to use. There are three deployment controller types available:.
+            '''The deployment controller type to use.
+
+            The deployment controller is the mechanism that determines how tasks are deployed for your service. The valid options are:
+
+            - ECS
+
+            When you create a service which uses the ``ECS`` deployment controller, you can choose between the following deployment strategies:
 
-            - **ECS** - The rolling update ( ``ECS`` ) deployment type involves replacing the current running version of the container with the latest version. The number of containers Amazon ECS adds or removes from the service during a rolling update is controlled by adjusting the minimum and maximum number of healthy tasks allowed during a service deployment, as specified in the `DeploymentConfiguration <https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeploymentConfiguration.html>`_ .
-            - **CODE_DEPLOY** - The blue/green ( ``CODE_DEPLOY`` ) deployment type uses the blue/green deployment model powered by AWS CodeDeploy , which allows you to verify a new deployment of a service before sending production traffic to it.
-            - **EXTERNAL** - The external ( ``EXTERNAL`` ) deployment type enables you to use any third-party deployment controller for full control over the deployment process for an Amazon ECS service.
+            - ``ROLLING`` : When you create a service which uses the *rolling update* ( ``ROLLING`` ) deployment strategy, the Amazon ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that Amazon ECS adds or removes from the service during a rolling update is controlled by the service deployment configuration.
+
+            Rolling update deployments are best suited for the following scenarios:
+
+            - Gradual service updates: You need to update your service incrementally without taking the entire service offline at once.
+            - Limited resource requirements: You want to avoid the additional resource costs of running two complete environments simultaneously (as required by blue/green deployments).
+            - Acceptable deployment time: Your application can tolerate a longer deployment process, as rolling updates replace tasks one by one.
+            - No need for instant roll back: Your service can tolerate a rollback process that takes minutes rather than seconds.
+            - Simple deployment process: You prefer a straightforward deployment approach without the complexity of managing multiple environments, target groups, and listeners.
+            - No load balancer requirement: Your service doesn't use or require a load balancer, Application Load Balancer , Network Load Balancer , or Service Connect (which are required for blue/green deployments).
+            - Stateful applications: Your application maintains state that makes it difficult to run two parallel environments.
+            - Cost sensitivity: You want to minimize deployment costs by not running duplicate environments during deployment.
+
+            Rolling updates are the default deployment strategy for services and provide a balance between deployment safety and resource efficiency for many common application scenarios.
+
+            - ``BLUE_GREEN`` : A *blue/green* deployment strategy ( ``BLUE_GREEN`` ) is a release methodology that reduces downtime and risk by running two identical production environments called blue and green. With Amazon ECS blue/green deployments, you can validate new service revisions before directing production traffic to them. This approach provides a safer way to deploy changes with the ability to quickly roll back if needed.
+
+            Amazon ECS blue/green deployments are best suited for the following scenarios:
+
+            - Service validation: When you need to validate new service revisions before directing production traffic to them
+            - Zero downtime: When your service requires zero-downtime deployments
+            - Instant roll back: When you need the ability to quickly roll back if issues are detected
+            - Load balancer requirement: When your service uses Application Load Balancer , Network Load Balancer , or Service Connect
+            - External
+
+            Use a third-party deployment controller.
+
+            - Blue/green deployment (powered by CodeDeploy )
+
+            CodeDeploy installs an updated version of the application as a new replacement task set and reroutes production traffic from the original application task set to the replacement task set. The original task set is terminated after a successful deployment. Use this deployment controller to verify a new deployment of a service before sending production traffic to it.
+
+            When updating the deployment controller for a service, consider the following depending on the type of migration you're performing.
+
+            - If you have a template that contains the ``EXTERNAL`` deployment controller information as well as ``TaskSet`` and ``PrimaryTaskSet`` resources, and you remove the task set resources from the template when updating from ``EXTERNAL`` to ``ECS`` , the ``DescribeTaskSet`` and ``DeleteTaskSet`` API calls will return a 400 error after the deployment controller is updated to ``ECS`` . This results in a delete failure on the task set resources, even though the stack transitions to ``UPDATE_COMPLETE`` status. For more information, see `Resource removed from stack but not deleted <https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted>`_ in the AWS CloudFormation User Guide. To fix this issue, delete the task sets directly using the Amazon ECS ``DeleteTaskSet`` API. For more information about how to delete a task set, see `DeleteTaskSet <https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html>`_ in the Amazon Elastic Container Service API Reference.
+            - If you're migrating from ``CODE_DEPLOY`` to ``ECS`` with a new task definition and AWS CloudFormation performs a rollback operation, the Amazon ECS ``UpdateService`` request fails with the following error:
+
+            Resource handler returned message: "Invalid request provided: Unable to update task definition on services with a CODE_DEPLOY deployment controller.
+
+            - After a successful migration from ``ECS`` to ``EXTERNAL`` deployment controller, you need to manually remove the ``ACTIVE`` task set, because Amazon ECS no longer manages the deployment. For information about how to delete a task set, see `DeleteTaskSet <https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html>`_ in the Amazon Elastic Container Service API Reference.
 
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentcontroller.html#cfn-ecs-service-deploymentcontroller-type
             '''
@@ -9993,10 +10054,15 @@ class CfnService(
             lifecycle_stages: typing.Sequence[builtins.str],
             role_arn: builtins.str,
         ) -> None:
-            '''
-            :param hook_target_arn: 
-            :param lifecycle_stages: 
-            :param role_arn: 
+            '''A deployment lifecycle hook runs custom logic at specific stages of the deployment process.
+
+            Currently, you can use Lambda functions as hook targets.
+
+            For more information, see `Lifecycle hooks for Amazon ECS service deployments <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-lifecycle-hooks.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
+
+            :param hook_target_arn: The Amazon Resource Name (ARN) of the hook target. Currently, only Lambda function ARNs are supported. You must provide this parameter when configuring a deployment lifecycle hook.
+            :param lifecycle_stages: The lifecycle stages at which to run the hook. Choose from these valid values:. - RECONCILE_SERVICE The reconciliation stage that only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state. You can use a lifecycle hook for this stage. - 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. You can use a lifecycle hook for this stage. - 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. You can use a lifecycle hook for this stage. - 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. You can use a lifecycle hook for this stage. - POST_TEST_TRAFFIC_SHIFT The test traffic shift is complete. The green service revision handles 100% of the test traffic. You can use a lifecycle hook for this stage. - PRODUCTION_TRAFFIC_SHIFT Production traffic is shifting to the green service revision. The green service revision is migrating from 0% to 100% of production traffic. You can use a lifecycle hook for this stage. - POST_PRODUCTION_TRAFFIC_SHIFT The production traffic shift is complete. You can use a lifecycle hook for this stage. You must provide this parameter when configuring a deployment lifecycle hook.
+            :param role_arn: The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call Lambda functions on your behalf. For more information, see `Permissions required for Lambda functions in Amazon ECS blue/green deployments <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-permissions.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
 
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentlifecyclehook.html
             :exampleMetadata: fixture=_generated
@@ -10026,7 +10092,10 @@ class CfnService(
 
         @builtins.property
         def hook_target_arn(self) -> builtins.str:
-            '''
+            '''The Amazon Resource Name (ARN) of the hook target. Currently, only Lambda function ARNs are supported.
+
+            You must provide this parameter when configuring a deployment lifecycle hook.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentlifecyclehook.html#cfn-ecs-service-deploymentlifecyclehook-hooktargetarn
             '''
             result = self._values.get("hook_target_arn")
@@ -10035,7 +10104,52 @@ class CfnService(
 
         @builtins.property
         def lifecycle_stages(self) -> typing.List[builtins.str]:
-            '''
+            '''The lifecycle stages at which to run the hook. Choose from these valid values:.
+
+            - RECONCILE_SERVICE
+
+            The reconciliation stage that only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state.
+
+            You can use a lifecycle hook for this stage.
+
+            - 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.
+
+            You can use a lifecycle hook for this stage.
+
+            - 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.
+
+            You can use a lifecycle hook for this stage.
+
+            - 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.
+
+            You can use a lifecycle hook for this stage.
+
+            - POST_TEST_TRAFFIC_SHIFT
+
+            The test traffic shift is complete. The green service revision handles 100% of the test traffic.
+
+            You can use a lifecycle hook for this stage.
+
+            - PRODUCTION_TRAFFIC_SHIFT
+
+            Production traffic is shifting to the green service revision. The green service revision is migrating from 0% to 100% of production traffic.
+
+            You can use a lifecycle hook for this stage.
+
+            - POST_PRODUCTION_TRAFFIC_SHIFT
+
+            The production traffic shift is complete.
+
+            You can use a lifecycle hook for this stage.
+
+            You must provide this parameter when configuring a deployment lifecycle hook.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentlifecyclehook.html#cfn-ecs-service-deploymentlifecyclehook-lifecyclestages
             '''
             result = self._values.get("lifecycle_stages")
@@ -10044,7 +10158,10 @@ class CfnService(
 
         @builtins.property
         def role_arn(self) -> builtins.str:
-            '''
+            '''The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call Lambda functions on your behalf.
+
+            For more information, see `Permissions required for Lambda functions in Amazon ECS blue/green deployments <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-permissions.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentlifecyclehook.html#cfn-ecs-service-deploymentlifecyclehook-rolearn
             '''
             result = self._values.get("role_arn")
@@ -10188,7 +10305,7 @@ class CfnService(
 
             Services with tasks that use the ``awsvpc`` network mode (for example, those with the Fargate launch type) only support Application Load Balancers and Network Load Balancers. Classic Load Balancers are not supported. Also, when you create any target groups for these services, you must choose ``ip`` as the target type, not ``instance`` . Tasks that use the ``awsvpc`` network mode are associated with an elastic network interface, not an Amazon EC2 instance.
 
-            :param advanced_configuration: 
+            :param advanced_configuration: The advanced settings for the load balancer used in blue/green deployments. Specify the alternate target group, listener rules, and IAM role required for traffic shifting during blue/green deployments.
             :param container_name: The name of the container (as it appears in a container definition) to associate with the load balancer. You need to specify the container name when configuring the target group for an Amazon ECS load balancer.
             :param container_port: The port on the container to associate with the load balancer. This port must correspond to a ``containerPort`` in the task definition the tasks in the service are using. For tasks that use the EC2 launch type, the container instance they're launched on must allow ingress traffic on the ``hostPort`` of the port mapping.
             :param load_balancer_name: The name of the load balancer to associate with the Amazon ECS service or task set. If you are using an Application Load Balancer or a Network Load Balancer the load balancer name parameter should be omitted.
@@ -10241,7 +10358,10 @@ class CfnService(
         def advanced_configuration(
             self,
         ) -> typing.Optional[typing.Union[_IResolvable_da3f097b, "CfnService.AdvancedConfigurationProperty"]]:
-            '''
+            '''The advanced settings for the load balancer used in blue/green deployments.
+
+            Specify the alternate target group, listener rules, and IAM role required for traffic shifting during blue/green deployments.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-loadbalancer.html#cfn-ecs-service-loadbalancer-advancedconfiguration
             '''
             result = self._values.get("advanced_configuration")
@@ -10860,7 +10980,7 @@ class CfnService(
 
             :param port: The listening port number for the Service Connect proxy. This port is available inside of all of the tasks within the same namespace. To avoid changing your applications in client Amazon ECS services, set this to the same port that the client application uses by default. For more information, see `Service Connect <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
             :param dns_name: The ``dnsName`` is the name that you use in the applications of client tasks to connect to this service. The name must be a valid DNS name but doesn't need to be fully-qualified. The name can include up to 127 characters. The name can include lowercase letters, numbers, underscores (_), hyphens (-), and periods (.). The name can't start with a hyphen. If this parameter isn't specified, the default value of ``discoveryName.namespace`` is used. If the ``discoveryName`` isn't specified, the port mapping name from the task definition is used in ``portName.namespace`` . To avoid changing your applications in client Amazon ECS services, set this to the same name that the client application uses by default. For example, a few common names are ``database`` , ``db`` , or the lowercase name of a database, such as ``mysql`` or ``redis`` . For more information, see `Service Connect <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
-            :param test_traffic_rules: 
+            :param test_traffic_rules: The configuration for test traffic routing rules used during blue/green deployments with Amazon ECS Service Connect. This allows you to route a portion of traffic to the new service revision of your service for testing before shifting all production traffic.
 
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-serviceconnectclientalias.html
             :exampleMetadata: fixture=_generated
@@ -10934,7 +11054,10 @@ class CfnService(
         def test_traffic_rules(
             self,
         ) -> typing.Optional[typing.Union[_IResolvable_da3f097b, "CfnService.ServiceConnectTestTrafficRulesProperty"]]:
-            '''
+            '''The configuration for test traffic routing rules used during blue/green deployments with Amazon ECS Service Connect.
+
+            This allows you to route a portion of traffic to the new service revision of your service for testing before shifting all production traffic.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-serviceconnectclientalias.html#cfn-ecs-service-serviceconnectclientalias-testtrafficrules
             '''
             result = self._values.get("test_traffic_rules")
@@ -11460,8 +11583,13 @@ class CfnService(
             *,
             header: typing.Union[_IResolvable_da3f097b, typing.Union["CfnService.ServiceConnectTestTrafficRulesHeaderProperty", typing.Dict[builtins.str, typing.Any]]],
         ) -> None:
-            '''
-            :param header: 
+            '''The test traffic routing configuration for Amazon ECS blue/green deployments.
+
+            This configuration allows you to define rules for routing specific traffic to the new service revision during the deployment process, allowing for safe testing before full production traffic shift.
+
+            For more information, see `Service Connect for Amazon ECS blue/green deployments <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect-blue-green.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
+
+            :param header: The HTTP header-based routing rules that determine which requests should be routed to the new service version during blue/green deployment testing. These rules provide fine-grained control over test traffic routing based on request headers.
 
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-serviceconnecttesttrafficrules.html
             :exampleMetadata: fixture=_generated
@@ -11494,7 +11622,10 @@ class CfnService(
         def header(
             self,
         ) -> typing.Union[_IResolvable_da3f097b, "CfnService.ServiceConnectTestTrafficRulesHeaderProperty"]:
-            '''
+            '''The HTTP header-based routing rules that determine which requests should be routed to the new service version during blue/green deployment testing.
+
+            These rules provide fine-grained control over test traffic routing based on request headers.
+
             :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-serviceconnecttesttrafficrules.html#cfn-ecs-service-serviceconnecttesttrafficrules-header
             '''
             result = self._values.get("header")
@@ -12429,9 +12560,9 @@ class CfnServiceProps:
         :param capacity_provider_strategy: The capacity provider strategy to use for the service. If a ``capacityProviderStrategy`` is specified, the ``launchType`` parameter must be omitted. If no ``capacityProviderStrategy`` or ``launchType`` is specified, the ``defaultCapacityProviderStrategy`` for the cluster is used. A capacity provider strategy can contain a maximum of 20 capacity providers. .. epigraph:: To remove this property from your service resource, specify an empty ``CapacityProviderStrategyItem`` array.
         :param cluster: The short name or full Amazon Resource Name (ARN) of the cluster that you run your service on. If you do not specify a cluster, the default cluster is assumed.
         :param deployment_configuration: Optional deployment parameters that control how many tasks run during the deployment and the ordering of stopping and starting tasks.
-        :param deployment_controller: The deployment controller to use for the service. If no deployment controller is specified, the default value of ``ECS`` is used.
+        :param deployment_controller: The deployment controller to use for the service.
         :param desired_count: The number of instantiations of the specified task definition to place and keep running in your service. For new services, if a desired count is not specified, a default value of ``1`` is used. When using the ``DAEMON`` scheduling strategy, the desired count is not required. For existing services, if a desired count is not specified, it is omitted from the operation.
-        :param enable_ecs_managed_tags: Specifies whether to turn on Amazon ECS managed tags for the tasks within the service. For more information, see `Tagging your Amazon ECS resources <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html>`_ in the *Amazon Elastic Container Service Developer Guide* . When you use Amazon ECS managed tags, you need to set the ``propagateTags`` request parameter.
+        :param enable_ecs_managed_tags: Specifies whether to turn on Amazon ECS managed tags for the tasks within the service. For more information, see `Tagging your Amazon ECS resources <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html>`_ in the *Amazon Elastic Container Service Developer Guide* . When you use Amazon ECS managed tags, you must set the ``propagateTags`` request parameter.
         :param enable_execute_command: Determines whether the execute command functionality is turned on for the service. If ``true`` , the execute command functionality is turned on for all containers in tasks as part of the service.
         :param health_check_grace_period_seconds: The period of time, in seconds, that the Amazon ECS service scheduler ignores unhealthy Elastic Load Balancing, VPC Lattice, and container health checks after a task has first started. If you don't specify a health check grace period value, the default value of ``0`` is used. If you don't use any of the health checks, then ``healthCheckGracePeriodSeconds`` is unused. If your service's tasks take a while to start and respond to health checks, you can specify a health check grace period of up to 2,147,483,647 seconds (about 69 years). During that time, the Amazon ECS service scheduler ignores health check status. This grace period can prevent the service scheduler from marking tasks as unhealthy and stopping them before they have time to come up.
         :param launch_type: The launch type on which to run your service. For more information, see `Amazon ECS Launch Types <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
@@ -12771,8 +12902,6 @@ class CfnServiceProps:
     ) -> typing.Optional[typing.Union[_IResolvable_da3f097b, CfnService.DeploymentControllerProperty]]:
         '''The deployment controller to use for the service.
 
-        If no deployment controller is specified, the default value of ``ECS`` is used.
-
         :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html#cfn-ecs-service-deploymentcontroller
         '''
         result = self._values.get("deployment_controller")
@@ -12799,7 +12928,7 @@ class CfnServiceProps:
 
         For more information, see `Tagging your Amazon ECS resources <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html>`_ in the *Amazon Elastic Container Service Developer Guide* .
 
-        When you use Amazon ECS managed tags, you need to set the ``propagateTags`` request parameter.
+        When you use Amazon ECS managed tags, you must set the ``propagateTags`` request parameter.
 
         :see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html#cfn-ecs-service-enableecsmanagedtags
         '''
@@ -33949,11 +34078,7 @@ class NetworkMode(enum.Enum):
     single container instance when port mappings are used.
     '''
     NAT = "NAT"
-    '''The task utilizes NAT network mode required by Windows containers.
-
-    This is the only supported network mode for Windows containers. For more information, see
-    `Task Definition Parameters <https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#network_mode>`_.
-    '''
+    '''The task utilizes Docker's built-in virtual network which runs inside each Windows container instance.'''
 
 
 class OperatingSystemFamily(
@@ -34049,6 +34174,18 @@ class OperatingSystemFamily(
         '''WINDOWS_SERVER_2022_FULL.'''
         return typing.cast("OperatingSystemFamily", jsii.sget(cls, "WINDOWS_SERVER_2022_FULL"))
 
+    @jsii.python.classproperty
+    @jsii.member(jsii_name="WINDOWS_SERVER_2025_CORE")
+    def WINDOWS_SERVER_2025_CORE(cls) -> "OperatingSystemFamily":
+        '''WINDOWS_SERVER_2025_CORE.'''
+        return typing.cast("OperatingSystemFamily", jsii.sget(cls, "WINDOWS_SERVER_2025_CORE"))
+
+    @jsii.python.classproperty
+    @jsii.member(jsii_name="WINDOWS_SERVER_2025_FULL")
+    def WINDOWS_SERVER_2025_FULL(cls) -> "OperatingSystemFamily":
+        '''WINDOWS_SERVER_2025_FULL.'''
+        return typing.cast("OperatingSystemFamily", jsii.sget(cls, "WINDOWS_SERVER_2025_FULL"))
+
     @jsii.python.classproperty
     @jsii.member(jsii_name="WINDOWS_SERVER_20H2_CORE")
     def WINDOWS_SERVER_20_H2_CORE(cls) -> "OperatingSystemFamily":
@@ -39861,6 +39998,7 @@ class VolumeFrom:
 class WindowsOptimizedVersion(enum.Enum):
     '''ECS-optimized Windows version list.'''
 
+    SERVER_2025 = "SERVER_2025"
     SERVER_2022 = "SERVER_2022"
     SERVER_2019 = "SERVER_2019"
     SERVER_2016 = "SERVER_2016"