CfnServicePropsMixin

class aws_cdk.mixins_preview.aws_ecs.mixins.CfnServicePropsMixin(props, *, strategy=None)

Bases: Mixin

The AWS::ECS::Service resource creates an Amazon Elastic Container Service (Amazon ECS) service that runs and maintains the requested number of tasks and associated load balancers.

The stack update fails if you change any properties that require replacement and at least one Amazon ECS Service Connect ServiceConnectConfiguration property is configured. This is because AWS CloudFormation creates the replacement service first, but each ServiceConnectService must have a name that is unique in the namespace. > Starting April 15, 2023, AWS ; will not onboard new customers to Amazon Elastic Inference (EI), and will help current customers migrate their workloads to options that offer better price and performance. After April 15, 2023, new customers will not be able to launch instances with Amazon EI accelerators in Amazon SageMaker, Amazon ECS , or Amazon EC2 . However, customers who have used Amazon EI at least once during the past 30-day period are considered current customers and will be able to continue using the service. > On June 12, 2025, Amazon ECS launched support for updating capacity provider configuration for Amazon ECS services. With this launch, Amazon ECS also aligned the CloudFormation update behavior for CapacityProviderStrategy parameter with the standard practice. For more information, see Amazon ECS adds support for updating capacity provider configuration for ECS services . Previously Amazon ECS ignored the CapacityProviderStrategy property if it was set to an empty list for example, [] in CloudFormation , because updating capacity provider configuration was not supported. Now, with support for capacity provider updates, customers can remove capacity providers from a service by passing an empty list. When you specify an empty list ( [] ) for the CapacityProviderStrategy property in your CloudFormation template, Amazon ECS will remove any capacity providers associated with the service, as follows:

For services created with a capacity provider strategy after the launch:

If there’s a cluster default strategy set, the service will revert to using that default strategy.

If no cluster default strategy exists, you will receive the following error:

No launch type to fall back to for empty capacity provider strategy. Your service was not created with a launch type.

For services created with a capacity provider strategy prior to the launch:

If CapacityProviderStrategy had FARGATE_SPOT or FARGATE capacity providers, the launch type will be updated to FARGATE and the capacity provider will be removed.

If the strategy included Auto Scaling group capacity providers, the service will revert to EC2 launch type, and the Auto Scaling group capacity providers will not be used.

Recommended Actions

If you are currently using CapacityProviderStrategy: [] in your CloudFormation templates, you should take one of the following actions:

If you do not intend to update the Capacity Provider Strategy:

Remove the CapacityProviderStrategy property entirely from your CloudFormation template

Alternatively, use !Ref AWS ::NoValue for the CapacityProviderStrategy property in your template

If you intend to maintain or update the Capacity Provider Strategy, specify the actual Capacity Provider Strategy for the service in your CloudFormation template.

If your CloudFormation template had an empty list ([]) for CapacityProviderStrategy prior to the aforementioned launch on June 12, and you are using the same template with CapacityProviderStrategy: [] , you might encounter the following error:

Invalid request provided: When switching from launch type to capacity provider strategy on an existing service, or making a change to a capacity provider strategy on a service that is already using one, you must force a new deployment. (Service: Ecs, Status Code: 400, Request ID: xxx) (SDK Attempt Count: 1)” (RequestToken: xxx HandlerErrorCode: InvalidRequest)

Note that CloudFormation automatically initiates a new deployment when it detects a parameter change, but customers cannot choose to force a deployment through CloudFormation . This is an invalid input scenario that requires one of the remediation actions listed above.

If you are experiencing active production issues related to this change, contact AWS Support or your Technical Account Manager.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html
CloudformationResource:: AWS::ECS::Service
Mixin:: true
ExampleMetadata:: fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview import mixins
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

# hook_details: Any

cfn_service_props_mixin = ecs_mixins.CfnServicePropsMixin(ecs_mixins.CfnServiceMixinProps(
    availability_zone_rebalancing="availabilityZoneRebalancing",
    capacity_provider_strategy=[ecs_mixins.CfnServicePropsMixin.CapacityProviderStrategyItemProperty(
        base=123,
        capacity_provider="capacityProvider",
        weight=123
    )],
    cluster="cluster",
    deployment_configuration=ecs_mixins.CfnServicePropsMixin.DeploymentConfigurationProperty(
        alarms=ecs_mixins.CfnServicePropsMixin.DeploymentAlarmsProperty(
            alarm_names=["alarmNames"],
            enable=False,
            rollback=False
        ),
        bake_time_in_minutes=123,
        canary_configuration=ecs_mixins.CfnServicePropsMixin.CanaryConfigurationProperty(
            canary_bake_time_in_minutes=123,
            canary_percent=123
        ),
        deployment_circuit_breaker=ecs_mixins.CfnServicePropsMixin.DeploymentCircuitBreakerProperty(
            enable=False,
            rollback=False
        ),
        lifecycle_hooks=[ecs_mixins.CfnServicePropsMixin.DeploymentLifecycleHookProperty(
            hook_details=hook_details,
            hook_target_arn="hookTargetArn",
            lifecycle_stages=["lifecycleStages"],
            role_arn="roleArn"
        )],
        linear_configuration=ecs_mixins.CfnServicePropsMixin.LinearConfigurationProperty(
            step_bake_time_in_minutes=123,
            step_percent=123
        ),
        maximum_percent=123,
        minimum_healthy_percent=123,
        strategy="strategy"
    ),
    deployment_controller=ecs_mixins.CfnServicePropsMixin.DeploymentControllerProperty(
        type="type"
    ),
    desired_count=123,
    enable_ecs_managed_tags=False,
    enable_execute_command=False,
    force_new_deployment=ecs_mixins.CfnServicePropsMixin.ForceNewDeploymentProperty(
        enable_force_new_deployment=False,
        force_new_deployment_nonce="forceNewDeploymentNonce"
    ),
    health_check_grace_period_seconds=123,
    launch_type="launchType",
    load_balancers=[ecs_mixins.CfnServicePropsMixin.LoadBalancerProperty(
        advanced_configuration=ecs_mixins.CfnServicePropsMixin.AdvancedConfigurationProperty(
            alternate_target_group_arn="alternateTargetGroupArn",
            production_listener_rule="productionListenerRule",
            role_arn="roleArn",
            test_listener_rule="testListenerRule"
        ),
        container_name="containerName",
        container_port=123,
        load_balancer_name="loadBalancerName",
        target_group_arn="targetGroupArn"
    )],
    network_configuration=ecs_mixins.CfnServicePropsMixin.NetworkConfigurationProperty(
        awsvpc_configuration=ecs_mixins.CfnServicePropsMixin.AwsVpcConfigurationProperty(
            assign_public_ip="assignPublicIp",
            security_groups=["securityGroups"],
            subnets=["subnets"]
        )
    ),
    placement_constraints=[ecs_mixins.CfnServicePropsMixin.PlacementConstraintProperty(
        expression="expression",
        type="type"
    )],
    placement_strategies=[ecs_mixins.CfnServicePropsMixin.PlacementStrategyProperty(
        field="field",
        type="type"
    )],
    platform_version="platformVersion",
    propagate_tags="propagateTags",
    role="role",
    scheduling_strategy="schedulingStrategy",
    service_connect_configuration=ecs_mixins.CfnServicePropsMixin.ServiceConnectConfigurationProperty(
        access_log_configuration=ecs_mixins.CfnServicePropsMixin.ServiceConnectAccessLogConfigurationProperty(
            format="format",
            include_query_parameters="includeQueryParameters"
        ),
        enabled=False,
        log_configuration=ecs_mixins.CfnServicePropsMixin.LogConfigurationProperty(
            log_driver="logDriver",
            options={
                "options_key": "options"
            },
            secret_options=[ecs_mixins.CfnServicePropsMixin.SecretProperty(
                name="name",
                value_from="valueFrom"
            )]
        ),
        namespace="namespace",
        services=[ecs_mixins.CfnServicePropsMixin.ServiceConnectServiceProperty(
            client_aliases=[ecs_mixins.CfnServicePropsMixin.ServiceConnectClientAliasProperty(
                dns_name="dnsName",
                port=123,
                test_traffic_rules=ecs_mixins.CfnServicePropsMixin.ServiceConnectTestTrafficRulesProperty(
                    header=ecs_mixins.CfnServicePropsMixin.ServiceConnectTestTrafficRulesHeaderProperty(
                        name="name",
                        value=ecs_mixins.CfnServicePropsMixin.ServiceConnectTestTrafficRulesHeaderValueProperty(
                            exact="exact"
                        )
                    )
                )
            )],
            discovery_name="discoveryName",
            ingress_port_override=123,
            port_name="portName",
            timeout=ecs_mixins.CfnServicePropsMixin.TimeoutConfigurationProperty(
                idle_timeout_seconds=123,
                per_request_timeout_seconds=123
            ),
            tls=ecs_mixins.CfnServicePropsMixin.ServiceConnectTlsConfigurationProperty(
                issuer_certificate_authority=ecs_mixins.CfnServicePropsMixin.ServiceConnectTlsCertificateAuthorityProperty(
                    aws_pca_authority_arn="awsPcaAuthorityArn"
                ),
                kms_key="kmsKey",
                role_arn="roleArn"
            )
        )]
    ),
    service_name="serviceName",
    service_registries=[ecs_mixins.CfnServicePropsMixin.ServiceRegistryProperty(
        container_name="containerName",
        container_port=123,
        port=123,
        registry_arn="registryArn"
    )],
    tags=[CfnTag(
        key="key",
        value="value"
    )],
    task_definition="taskDefinition",
    volume_configurations=[ecs_mixins.CfnServicePropsMixin.ServiceVolumeConfigurationProperty(
        managed_ebs_volume=ecs_mixins.CfnServicePropsMixin.ServiceManagedEBSVolumeConfigurationProperty(
            encrypted=False,
            filesystem_type="filesystemType",
            iops=123,
            kms_key_id="kmsKeyId",
            role_arn="roleArn",
            size_in_gi_b=123,
            snapshot_id="snapshotId",
            tag_specifications=[ecs_mixins.CfnServicePropsMixin.EBSTagSpecificationProperty(
                propagate_tags="propagateTags",
                resource_type="resourceType",
                tags=[CfnTag(
                    key="key",
                    value="value"
                )]
            )],
            throughput=123,
            volume_initialization_rate=123,
            volume_type="volumeType"
        ),
        name="name"
    )],
    vpc_lattice_configurations=[ecs_mixins.CfnServicePropsMixin.VpcLatticeConfigurationProperty(
        port_name="portName",
        role_arn="roleArn",
        target_group_arn="targetGroupArn"
    )]
),
    strategy=mixins.PropertyMergeStrategy.OVERRIDE
)

Create a mixin to apply properties to AWS::ECS::Service.

Parameters:

props (Union[CfnServiceMixinProps, Dict[str, Any]]) – L1 properties to apply.
strategy (Optional[PropertyMergeStrategy]) – (experimental) Strategy for merging nested properties. Default: - PropertyMergeStrategy.MERGE

Methods

apply_to(construct)

Apply the mixin properties to the construct.

Parameters:: construct (IConstruct)
Return type:: IConstruct

supports(construct)

Check if this mixin supports the given construct.

Parameters:: construct (IConstruct)
Return type:: bool

Attributes

CFN_PROPERTY_KEYS = ['availabilityZoneRebalancing', 'capacityProviderStrategy', 'cluster', 'deploymentConfiguration', 'deploymentController', 'desiredCount', 'enableEcsManagedTags', 'enableExecuteCommand', 'forceNewDeployment', 'healthCheckGracePeriodSeconds', 'launchType', 'loadBalancers', 'networkConfiguration', 'placementConstraints', 'placementStrategies', 'platformVersion', 'propagateTags', 'role', 'schedulingStrategy', 'serviceConnectConfiguration', 'serviceName', 'serviceRegistries', 'tags', 'taskDefinition', 'volumeConfigurations', 'vpcLatticeConfigurations']

Static Methods

classmethod is_mixin(x)

(experimental) Checks if x is a Mixin.

Parameters:: x (Any) – Any object.
Return type:: bool
Returns:: true if x is an object created from a class which extends Mixin.
Stability:: experimental

AdvancedConfigurationProperty

class CfnServicePropsMixin.AdvancedConfigurationProperty(*, alternate_target_group_arn=None, production_listener_rule=None, role_arn=None, test_listener_rule=None)

Bases: object

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 in the Amazon Elastic Container Service Developer Guide .

Parameters:

alternate_target_group_arn (Optional[str]) – The Amazon Resource Name (ARN) of the alternate target group for Amazon ECS blue/green deployments.
production_listener_rule (Optional[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.
role_arn (Optional[str]) – The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call the Elastic Load Balancing APIs for you.
test_listener_rule (Optional[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

ExampleMetadata:

fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

advanced_configuration_property = ecs_mixins.CfnServicePropsMixin.AdvancedConfigurationProperty(
    alternate_target_group_arn="alternateTargetGroupArn",
    production_listener_rule="productionListenerRule",
    role_arn="roleArn",
    test_listener_rule="testListenerRule"
)

Attributes

alternate_target_group_arn

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

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.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html#cfn-ecs-service-advancedconfiguration-productionlistenerrule

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.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html#cfn-ecs-service-advancedconfiguration-rolearn

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#cfn-ecs-service-advancedconfiguration-testlistenerrule

AwsVpcConfigurationProperty

class CfnServicePropsMixin.AwsVpcConfigurationProperty(*, assign_public_ip=None, security_groups=None, subnets=None)

Bases: object

An object representing the networking details for a task or service.

For example awsVpcConfiguration={subnets=["subnet-12344321"],securityGroups=["sg-12344321"]} .

Parameters:

assign_public_ip (Optional[str]) – Whether the task’s elastic network interface receives a public IP address. Consider the following when you set this value: - When you use create-service or update-service , the default is DISABLED . - When the service deploymentController is ECS , the value must be DISABLED .
security_groups (Optional[Sequence[str]]) – The IDs of the security groups associated with the task or service. If you don’t specify a security group, the default security group for the VPC is used. There’s a limit of 5 security groups that can be specified. .. epigraph:: All specified security groups must be from the same VPC.
subnets (Optional[Sequence[str]]) – The IDs of the subnets associated with the task or service. There’s a limit of 16 subnets that can be specified. .. epigraph:: All specified subnets must be from the same VPC.

See:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-awsvpcconfiguration.html

ExampleMetadata:

fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

aws_vpc_configuration_property = ecs_mixins.CfnServicePropsMixin.AwsVpcConfigurationProperty(
    assign_public_ip="assignPublicIp",
    security_groups=["securityGroups"],
    subnets=["subnets"]
)

Attributes

assign_public_ip

Whether the task’s elastic network interface receives a public IP address.

Consider the following when you set this value:

When you use create-service or update-service , the default is DISABLED .
When the service deploymentController is ECS , the value must be DISABLED .

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-awsvpcconfiguration.html#cfn-ecs-service-awsvpcconfiguration-assignpublicip

security_groups

The IDs of the security groups associated with the task or service.

If you don’t specify a security group, the default security group for the VPC is used. There’s a limit of 5 security groups that can be specified. .. epigraph:

All specified security groups must be from the same VPC.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-awsvpcconfiguration.html#cfn-ecs-service-awsvpcconfiguration-securitygroups

subnets

The IDs of the subnets associated with the task or service.

There’s a limit of 16 subnets that can be specified. .. epigraph:

All specified subnets must be from the same VPC.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-awsvpcconfiguration.html#cfn-ecs-service-awsvpcconfiguration-subnets

CanaryConfigurationProperty

class CfnServicePropsMixin.CanaryConfigurationProperty(*, canary_bake_time_in_minutes=None, canary_percent=None)

Bases: object

Configuration for a canary deployment strategy that shifts a fixed percentage of traffic to the new service revision, waits for a specified bake time, then shifts the remaining traffic.

The following validation applies only to Canary deployments created through CloudFormation . CloudFormation operations time out after 36 hours. Canary deployments can approach this limit because of their extended duration. This can cause CloudFormation to roll back the deployment. To prevent timeout-related rollbacks, CloudFormation rejects deployments when the calculated deployment time exceeds 33 hours based on your template configuration:

BakeTimeInMinutes + CanaryBakeTimeInMinutes

Additional backend processes (such as task scaling and running lifecycle hooks) can extend deployment time beyond these calculations. Even deployments under the 33-hour threshold might still time out if these processes cause the total duration to exceed 36 hours.

Parameters:

canary_bake_time_in_minutes (Union[int, float, None]) – The amount of time in minutes to wait during the canary phase before shifting the remaining production traffic to the new service revision. Valid values are 0 to 1440 minutes (24 hours). The default value is 10.
canary_percent (Union[int, float, None]) – The percentage of production traffic to shift to the new service revision during the canary phase. Valid values are multiples of 0.1 from 0.1 to 100.0. The default value is 5.0.

See:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-canaryconfiguration.html

ExampleMetadata:

fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

canary_configuration_property = ecs_mixins.CfnServicePropsMixin.CanaryConfigurationProperty(
    canary_bake_time_in_minutes=123,
    canary_percent=123
)

Attributes

canary_bake_time_in_minutes

The amount of time in minutes to wait during the canary phase before shifting the remaining production traffic to the new service revision.

Valid values are 0 to 1440 minutes (24 hours). The default value is 10.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-canaryconfiguration.html#cfn-ecs-service-canaryconfiguration-canarybaketimeinminutes

canary_percent

The percentage of production traffic to shift to the new service revision during the canary phase.

Valid values are multiples of 0.1 from 0.1 to 100.0. The default value is 5.0.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-canaryconfiguration.html#cfn-ecs-service-canaryconfiguration-canarypercent

CapacityProviderStrategyItemProperty

class CfnServicePropsMixin.CapacityProviderStrategyItemProperty(*, base=None, capacity_provider=None, weight=None)

Bases: object

The details of a capacity provider strategy.

A capacity provider strategy can be set when using the RunTask or CreateService APIs or as the default capacity provider strategy for a cluster with the CreateCluster API.

Only capacity providers that are already associated with a cluster and have an ACTIVE or UPDATING status can be used in a capacity provider strategy. The PutClusterCapacityProviders API is used to associate a capacity provider with a cluster.

If specifying a capacity provider that uses an Auto Scaling group, the capacity provider must already be created. New Auto Scaling group capacity providers can be created with the CreateCapacityProvider API operation.

To use an AWS Fargate capacity provider, specify either the FARGATE or FARGATE_SPOT capacity providers. The AWS Fargate capacity providers are available to all accounts and only need to be associated with a cluster to be used in a capacity provider strategy.

Parameters:

base (Union[int, float, None]) – The base value designates how many tasks, at a minimum, to run on the specified capacity provider for each service. Only one capacity provider in a capacity provider strategy can have a base defined. If no value is specified, the default value of 0 is used. Base value characteristics: - Only one capacity provider in a strategy can have a base defined - The default value is 0 if not specified - The valid range is 0 to 100,000 - Base requirements are satisfied first before weight distribution
capacity_provider (Optional[str]) – The short name of the capacity provider. This can be either an AWS managed capacity provider ( FARGATE or FARGATE_SPOT ) or the name of a custom capacity provider that you created.
weight (Union[int, float, None]) – The weight value designates the relative percentage of the total number of tasks launched that should use the specified capacity provider. The weight value is taken into consideration after the base value, if defined, is satisfied. If no weight value is specified, the default value of 0 is used. When multiple capacity providers are specified within a capacity provider strategy, at least one of the capacity providers must have a weight value greater than zero and any capacity providers with a weight of 0 can’t be used to place tasks. If you specify multiple capacity providers in a strategy that all have a weight of 0 , any RunTask or CreateService actions using the capacity provider strategy will fail. Weight value characteristics: - Weight is considered after the base value is satisfied - The default value is 0 if not specified - The valid range is 0 to 1,000 - At least one capacity provider must have a weight greater than zero - Capacity providers with weight of 0 cannot place tasks Task distribution logic: - Base satisfaction: The minimum number of tasks specified by the base value are placed on that capacity provider - Weight distribution: After base requirements are met, additional tasks are distributed according to weight ratios Examples: Equal Distribution: Two capacity providers both with weight 1 will split tasks evenly after base requirements are met. Weighted Distribution: If capacityProviderA has weight 1 and capacityProviderB has weight 4 , then for every 1 task on A, 4 tasks will run on B.

See:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html

ExampleMetadata:

fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

capacity_provider_strategy_item_property = ecs_mixins.CfnServicePropsMixin.CapacityProviderStrategyItemProperty(
    base=123,
    capacity_provider="capacityProvider",
    weight=123
)

Attributes

base

The base value designates how many tasks, at a minimum, to run on the specified capacity provider for each service.

Only one capacity provider in a capacity provider strategy can have a base defined. If no value is specified, the default value of 0 is used.

Base value characteristics:

Only one capacity provider in a strategy can have a base defined
The default value is 0 if not specified
The valid range is 0 to 100,000
Base requirements are satisfied first before weight distribution

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html#cfn-ecs-service-capacityproviderstrategyitem-base

capacity_provider

The short name of the capacity provider.

This can be either an AWS managed capacity provider ( FARGATE or FARGATE_SPOT ) or the name of a custom capacity provider that you created.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html#cfn-ecs-service-capacityproviderstrategyitem-capacityprovider

weight

The weight value designates the relative percentage of the total number of tasks launched that should use the specified capacity provider.

The weight value is taken into consideration after the base value, if defined, is satisfied.

If no weight value is specified, the default value of 0 is used. When multiple capacity providers are specified within a capacity provider strategy, at least one of the capacity providers must have a weight value greater than zero and any capacity providers with a weight of 0 can’t be used to place tasks. If you specify multiple capacity providers in a strategy that all have a weight of 0 , any RunTask or CreateService actions using the capacity provider strategy will fail.

Weight value characteristics:

Weight is considered after the base value is satisfied
The default value is 0 if not specified
The valid range is 0 to 1,000
At least one capacity provider must have a weight greater than zero
Capacity providers with weight of 0 cannot place tasks

Task distribution logic:

Base satisfaction: The minimum number of tasks specified by the base value are placed on that capacity provider
Weight distribution: After base requirements are met, additional tasks are distributed according to weight ratios

Examples:

Equal Distribution: Two capacity providers both with weight 1 will split tasks evenly after base requirements are met.

Weighted Distribution: If capacityProviderA has weight 1 and capacityProviderB has weight 4 , then for every 1 task on A, 4 tasks will run on B.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html#cfn-ecs-service-capacityproviderstrategyitem-weight

DeploymentAlarmsProperty

class CfnServicePropsMixin.DeploymentAlarmsProperty(*, alarm_names=None, enable=None, rollback=None)

Bases: object

One of the methods which provide a way for you to quickly identify when a deployment has failed, and then to optionally roll back the failure to the last working deployment.

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 .

For more information, see Rolling update in the Amazon Elastic Container Service Developer Guide .

Parameters:

alarm_names (Optional[Sequence[str]]) – One or more CloudWatch alarm names. Use a “,” to separate the alarms.
enable (Union[bool, IResolvable, None]) – Determines whether to use the CloudWatch alarm option in the service deployment process.
rollback (Union[bool, IResolvable, None]) – Determines whether to configure Amazon ECS to roll back the service if a service deployment fails. If rollback is used, when a service deployment fails, the service is rolled back to the last deployment that completed successfully.

See:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentalarms.html

ExampleMetadata:

fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

deployment_alarms_property = ecs_mixins.CfnServicePropsMixin.DeploymentAlarmsProperty(
    alarm_names=["alarmNames"],
    enable=False,
    rollback=False
)

Attributes

alarm_names

One or more CloudWatch alarm names.

Use a “,” to separate the alarms.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentalarms.html#cfn-ecs-service-deploymentalarms-alarmnames

enable

Determines whether to use the CloudWatch alarm option in the service deployment process.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentalarms.html#cfn-ecs-service-deploymentalarms-enable

rollback

Determines whether to configure Amazon ECS to roll back the service if a service deployment fails.

If rollback is used, when a service deployment fails, the service is rolled back to the last deployment that completed successfully.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentalarms.html#cfn-ecs-service-deploymentalarms-rollback

DeploymentCircuitBreakerProperty

class CfnServicePropsMixin.DeploymentCircuitBreakerProperty(*, enable=None, rollback=None)

Bases: object

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 it is turned on, a service deployment will transition to a failed state and stop launching new tasks. You can also configure Amazon ECS to roll back your service to the last completed deployment after a failure. For more information, see Rolling update in the Amazon Elastic Container Service Developer Guide .

For more information about API failure reasons, see API failure reasons in the Amazon Elastic Container Service Developer Guide .

Attributes

enable

Determines whether to use the deployment circuit breaker logic for the service.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentcircuitbreaker.html#cfn-ecs-service-deploymentcircuitbreaker-enable

rollback

Determines whether to configure Amazon ECS to roll back the service if a service deployment fails.

If rollback is on, when a service deployment fails, the service is rolled back to the last deployment that completed successfully.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentcircuitbreaker.html#cfn-ecs-service-deploymentcircuitbreaker-rollback

DeploymentConfigurationProperty

class CfnServicePropsMixin.DeploymentConfigurationProperty(*, alarms=None, bake_time_in_minutes=None, canary_configuration=None, deployment_circuit_breaker=None, lifecycle_hooks=None, linear_configuration=None, maximum_percent=None, minimum_healthy_percent=None, strategy=None)

Bases: object

Optional deployment parameters that control how many tasks run during a deployment and the ordering of stopping and starting tasks.

Parameters:

alarms (Union[IResolvable, DeploymentAlarmsProperty, Dict[str, Any], None]) – Information about the CloudWatch alarms.
bake_time_in_minutes (Union[int, float, None]) – 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).
canary_configuration (Union[IResolvable, CanaryConfigurationProperty, Dict[str, Any], None]) – Configuration for canary deployment strategy. Only valid when the deployment strategy is CANARY . This configuration enables shifting a fixed percentage of traffic for testing, followed by shifting the remaining traffic after a bake period.
deployment_circuit_breaker (Union[IResolvable, DeploymentCircuitBreakerProperty, Dict[str, Any], None]) –

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 in the Amazon Elastic Container Service Developer Guide
lifecycle_hooks (Union[IResolvable, Sequence[Union[IResolvable, DeploymentLifecycleHookProperty, Dict[str, Any]]], None]) – An array of deployment lifecycle hook objects to run custom logic at specific stages of the deployment lifecycle.
linear_configuration (Union[IResolvable, LinearConfigurationProperty, Dict[str, Any], None]) – Configuration for linear deployment strategy. Only valid when the deployment strategy is LINEAR . This configuration enables progressive traffic shifting in equal percentage increments with configurable bake times between each step.
maximum_percent (Union[int, float, None]) – 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 . 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.
minimum_healthy_percent (Union[int, float, None]) –
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 . 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.
strategy (Optional[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. - LINEAR - A linear deployment strategy ( LINEAR ) gradually shifts traffic from the current production environment to a new environment in equal percentages over time. With Amazon ECS linear deployments, you can control the pace of traffic shifting and validate new service revisions with increasing amounts of production traffic. - CANARY - A canary deployment strategy ( CANARY ) shifts a small percentage of traffic to the new service revision first, then shifts the remaining traffic all at once after a specified time period. This allows you to test the new version with a subset of users before full deployment.

See:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html

ExampleMetadata:

fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

# hook_details: Any

deployment_configuration_property = ecs_mixins.CfnServicePropsMixin.DeploymentConfigurationProperty(
    alarms=ecs_mixins.CfnServicePropsMixin.DeploymentAlarmsProperty(
        alarm_names=["alarmNames"],
        enable=False,
        rollback=False
    ),
    bake_time_in_minutes=123,
    canary_configuration=ecs_mixins.CfnServicePropsMixin.CanaryConfigurationProperty(
        canary_bake_time_in_minutes=123,
        canary_percent=123
    ),
    deployment_circuit_breaker=ecs_mixins.CfnServicePropsMixin.DeploymentCircuitBreakerProperty(
        enable=False,
        rollback=False
    ),
    lifecycle_hooks=[ecs_mixins.CfnServicePropsMixin.DeploymentLifecycleHookProperty(
        hook_details=hook_details,
        hook_target_arn="hookTargetArn",
        lifecycle_stages=["lifecycleStages"],
        role_arn="roleArn"
    )],
    linear_configuration=ecs_mixins.CfnServicePropsMixin.LinearConfigurationProperty(
        step_bake_time_in_minutes=123,
        step_percent=123
    ),
    maximum_percent=123,
    minimum_healthy_percent=123,
    strategy="strategy"
)

Attributes

alarms

Information about the CloudWatch alarms.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-alarms

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).

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-baketimeinminutes

canary_configuration

Configuration for canary deployment strategy.

Only valid when the deployment strategy is CANARY . This configuration enables shifting a fixed percentage of traffic for testing, followed by shifting the remaining traffic after a bake period.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-canaryconfiguration

deployment_circuit_breaker

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 in the Amazon Elastic Container Service Developer Guide

see:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-deploymentcircuitbreaker

lifecycle_hooks

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

linear_configuration

Configuration for linear deployment strategy.

Only valid when the deployment strategy is LINEAR . This configuration enables progressive traffic shifting in equal percentage increments with configurable bake times between each step.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-linearconfiguration

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 .

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.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-maximumpercent

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 .

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.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-minimumhealthypercent

strategy

.

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.
LINEAR - A linear deployment strategy ( LINEAR ) gradually shifts traffic from the current production environment to a new environment in equal percentages over time. With Amazon ECS linear deployments, you can control the pace of traffic shifting and validate new service revisions with increasing amounts of production traffic.
CANARY - A canary deployment strategy ( CANARY ) shifts a small percentage of traffic to the new service revision first, then shifts the remaining traffic all at once after a specified time period. This allows you to test the new version with a subset of users before full deployment.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentconfiguration.html#cfn-ecs-service-deploymentconfiguration-strategy
Type:: The deployment strategy for the service. Choose from these valid values

DeploymentControllerProperty

class CfnServicePropsMixin.DeploymentControllerProperty(*, type=None)

Bases: object

The deployment controller to use for the service.

Parameters:

type (Optional[str]) –

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 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 in the ECSlong API Reference. - If you’re migrating from CODE_DEPLOY to ECS with a new task definition and 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 in the ECSlong API Reference.

See:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentcontroller.html

ExampleMetadata:

fixture=_generated

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

deployment_controller_property = ecs_mixins.CfnServicePropsMixin.DeploymentControllerProperty(
    type="type"
)

Attributes

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 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 in the ECSlong API Reference.
If you’re migrating from CODE_DEPLOY to ECS with a new task definition and 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 in the ECSlong API Reference.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentcontroller.html#cfn-ecs-service-deploymentcontroller-type

DeploymentLifecycleHookProperty

class CfnServicePropsMixin.DeploymentLifecycleHookProperty(*, hook_details=None, hook_target_arn=None, lifecycle_stages=None, role_arn=None)

Bases: object

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 in the Amazon Elastic Container Service Developer Guide .

Parameters:

hook_details (Any) – Use this field to specify custom parameters that Amazon ECS passes to your hook target invocations (such as a Lambda function). This field must be a JSON object as a string.
hook_target_arn (Optional[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.
lifecycle_stages (Optional[Sequence[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.
role_arn (Optional[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 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

Example:

# The code below shows an example of how to instantiate this type.
# The values are placeholders you should change.
from aws_cdk.mixins_preview.aws_ecs import mixins as ecs_mixins

# hook_details: Any

deployment_lifecycle_hook_property = ecs_mixins.CfnServicePropsMixin.DeploymentLifecycleHookProperty(
    hook_details=hook_details,
    hook_target_arn="hookTargetArn",
    lifecycle_stages=["lifecycleStages"],
    role_arn="roleArn"
)

Attributes

hook_details

Use this field to specify custom parameters that Amazon ECS passes to your hook target invocations (such as a Lambda function).

This field must be a JSON object as a string.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentlifecyclehook.html#cfn-ecs-service-deploymentlifecyclehook-hookdetails

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.

See:: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentlifecyclehook.html#cfn-ecs-service-deploymentlifecyclehook-hooktargetarn

lifecycle_stages

.

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.