---
title: Getting Started with Datadog
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: Docs > Infrastructure > Datadog Resource Catalog
---

# aws_ecs_service_deployment{% #aws_ecs_service_deployment %}

## `account_id`{% #account_id %}

**Type**: `STRING`

## `alarms`{% #alarms %}

**Type**: `STRUCT`**Provider name**: `alarms`**Description**: The CloudWatch alarms that determine when a service deployment fails.

- `alarm_names`**Type**: `UNORDERED_LIST_STRING`**Provider name**: `alarmNames`**Description**: The name of the CloudWatch alarms that determine when a service deployment failed. A "," separates the alarms.
- `status`**Type**: `STRING`**Provider name**: `status`**Description**: The status of the alarms check. Amazon ECS is not using alarms for service deployment failures when the status is `DISABLED`.
- `triggered_alarm_names`**Type**: `UNORDERED_LIST_STRING`**Provider name**: `triggeredAlarmNames`**Description**: One or more CloudWatch alarm names that have been triggered during the service deployment. A "," separates the alarm names.

## `capacity_provider_strategy`{% #capacity_provider_strategy %}

**Type**: `UNORDERED_LIST_STRUCT`**Provider name**: `capacityProviderStrategy`**Description**: The capacity provider strategy that are associated with the task set.

- `base`**Type**: `INT32`**Provider name**: `base`**Description**: The base value designates how many tasks, at a minimum, to run on the specified capacity provider. 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.
- `capacity_provider`**Type**: `STRING`**Provider name**: `capacityProvider`**Description**: The short name of the capacity provider.
- `weight`**Type**: `INT32`**Provider name**: `weight`**Description**: 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. An example scenario for using weights is defining a strategy that contains two capacity providers and both have a weight of `1`, then when the `base` is satisfied, the tasks will be split evenly across the two capacity providers. Using that same logic, if you specify a weight of `1` for capacityProviderA and a weight of `4` for capacityProviderB, then for every one task that's run using capacityProviderA, four tasks would use capacityProviderB.

## `cluster_arn`{% #cluster_arn %}

**Type**: `STRING`**Provider name**: `clusterArn`**Description**: The Amazon Resource Name (ARN) of the cluster that the service that hosts the task set exists in.

## `computed_desired_count`{% #computed_desired_count %}

**Type**: `INT32`**Provider name**: `computedDesiredCount`**Description**: The computed desired count for the task set. This is calculated by multiplying the service's `desiredCount` by the task set's `scale` percentage. The result is always rounded up. For example, if the computed desired count is 1.2, it rounds up to 2 tasks.

## `created_at`{% #created_at %}

**Type**: `TIMESTAMP`**Provider name**: `createdAt`**Description**: The Unix timestamp for the time when the task set was created.

## `deployment_circuit_breaker`{% #deployment_circuit_breaker %}

**Type**: `STRUCT`**Provider name**: `deploymentCircuitBreaker`**Description**: The circuit breaker configuration that determines a service deployment failed.

- `failure_count`**Type**: `INT32`**Provider name**: `failureCount`**Description**: The number of times the circuit breaker detected a service deploymeny failure.
- `status`**Type**: `STRING`**Provider name**: `status`**Description**: The circuit breaker status. Amazon ECS is not using the circuit breaker for service deployment failures when the status is `DISABLED`.
- `threshold`**Type**: `INT32`**Provider name**: `threshold`**Description**: The threshhold which determines that the service deployment failed. The deployment circuit breaker calculates the threshold value, and then uses the value to determine when to move the deployment to a FAILED state. The deployment circuit breaker has a minimum threshold of 3 and a maximum threshold of 200. and uses the values in the following formula to determine the deployment failure. `0.5 * desired task count`

## `deployment_configuration`{% #deployment_configuration %}

**Type**: `STRUCT`**Provider name**: `deploymentConfiguration`

- `alarms`**Type**: `STRUCT`**Provider name**: `alarms`**Description**: Information about the CloudWatch alarms.
  - `alarm_names`**Type**: `UNORDERED_LIST_STRING`**Provider name**: `alarmNames`**Description**: One or more CloudWatch alarm names. Use a "," to separate the alarms.
  - `enable`**Type**: `BOOLEAN`**Provider name**: `enable`**Description**: Determines whether to use the CloudWatch alarm option in the service deployment process.
  - `rollback`**Type**: `BOOLEAN`**Provider name**: `rollback`**Description**: 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.
- `deployment_circuit_breaker`**Type**: `STRUCT`**Provider name**: `deploymentCircuitBreaker`**Description**: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
  - `enable`**Type**: `BOOLEAN`**Provider name**: `enable`**Description**: Determines whether to use the deployment circuit breaker logic for the service.
  - `rollback`**Type**: `BOOLEAN`**Provider name**: `rollback`**Description**: 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.
- `maximum_percent`**Type**: `INT32`**Provider name**: `maximumPercent`**Description**: 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.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`**Type**: `INT32`**Provider name**: `minimumHealthyPercent`**Description**: 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 CLI, the Amazon Web Services SDKs, and the APIs and 50% for the Amazon Web Services 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.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.

## `fargate_ephemeral_storage`{% #fargate_ephemeral_storage %}

**Type**: `STRUCT`**Provider name**: `fargateEphemeralStorage`**Description**: The Fargate ephemeral storage settings for the task set.

- `kms_key_id`**Type**: `STRING`**Provider name**: `kmsKeyId`**Description**: Specify an Key Management Service key ID to encrypt the ephemeral storage for deployment.

## `finished_at`{% #finished_at %}

**Type**: `TIMESTAMP`**Provider name**: `finishedAt`**Description**: The time the service deployment finished. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.

## `id`{% #id %}

**Type**: `STRING`**Provider name**: `id`**Description**: The ID of the task set.

## `launch_type`{% #launch_type %}

**Type**: `STRING`**Provider name**: `launchType`**Description**: The launch type the tasks in the task set are using. 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.

## `load_balancers`{% #load_balancers %}

**Type**: `UNORDERED_LIST_STRUCT`**Provider name**: `loadBalancers`**Description**: Details on a load balancer that are used with a task set.

- `container_name`**Type**: `STRING`**Provider name**: `containerName`**Description**: 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.
- `container_port`**Type**: `INT32`**Provider name**: `containerPort`**Description**: 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.
- `load_balancer_name`**Type**: `STRING`**Provider name**: `loadBalancerName`**Description**: 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.
- `target_group_arn`**Type**: `STRING`**Provider name**: `targetGroupArn`**Description**: The full Amazon Resource Name (ARN) of the Elastic Load Balancing target group or groups associated with a service or task set. A target group ARN is only specified when using an Application Load Balancer or Network Load Balancer. For services using the `ECS` deployment controller, you can specify one or multiple target groups. For more information, see [Registering multiple target groups with a service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html) in the Amazon Elastic Container Service Developer Guide. For services using the `CODE_DEPLOY` deployment controller, you're required to define two target groups for the load balancer. For more information, see [Blue/green deployment with CodeDeploy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-bluegreen.html) in the Amazon Elastic Container Service Developer Guide.If your service's task definition uses the `awsvpc` network mode, you must choose `ip` as the target type, not `instance`. Do this when creating your target groups because tasks that use the `awsvpc` network mode are associated with an elastic network interface, not an Amazon EC2 instance. This network mode is required for the Fargate launch type.

## `network_configuration`{% #network_configuration %}

**Type**: `STRUCT`**Provider name**: `networkConfiguration`**Description**: The network configuration for the task set.

- `awsvpc_configuration`**Type**: `STRUCT`**Provider name**: `awsvpcConfiguration`**Description**: The VPC subnets and security groups that are associated with a task.All specified subnets and security groups must be from the same VPC.
  - `assign_public_ip`**Type**: `STRING`**Provider name**: `assignPublicIp`**Description**: 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`**Type**: `UNORDERED_LIST_STRING`**Provider name**: `securityGroups`**Description**: 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.All specified security groups must be from the same VPC.
  - `subnets`**Type**: `UNORDERED_LIST_STRING`**Provider name**: `subnets`**Description**: The IDs of the subnets associated with the task or service. There's a limit of 16 subnets that can be specified.All specified subnets must be from the same VPC.

## `pending_count`{% #pending_count %}

**Type**: `INT32`**Provider name**: `pendingCount`**Description**: The number of tasks in the task set that are in the `PENDING` status during a deployment. A task in the `PENDING` state is preparing to enter the `RUNNING` state. A task set enters the `PENDING` status when it launches for the first time or when it's restarted after being in the `STOPPED` state.

## `platform_family`{% #platform_family %}

**Type**: `STRING`**Provider name**: `platformFamily`**Description**: The operating system that your tasks in the set are running on. A platform family is specified only for tasks that use the Fargate launch type. All tasks in the set must have the same value.

## `platform_version`{% #platform_version %}

**Type**: `STRING`**Provider name**: `platformVersion`**Description**: The Fargate platform version where the tasks in the task set are running. A platform version is only specified for tasks run on Fargate. For more information, see [Fargate platform versions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html) in the Amazon Elastic Container Service Developer Guide.

## `rollback`{% #rollback %}

**Type**: `STRUCT`**Provider name**: `rollback`**Description**: The rollback options the service deployment uses when the deployment fails.

- `reason`**Type**: `STRING`**Provider name**: `reason`**Description**: The reason the rollback happened. For example, the circuit breaker initiated the rollback operation.
- `service_revision_arn`**Type**: `STRING`**Provider name**: `serviceRevisionArn`**Description**: The ARN of the service revision deployed as part of the rollback.
- `started_at`**Type**: `TIMESTAMP`**Provider name**: `startedAt`**Description**: Time time that the rollback started. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.

## `running_count`{% #running_count %}

**Type**: `INT32`**Provider name**: `runningCount`**Description**: The number of tasks in the task set that are in the `RUNNING` status during a deployment. A task in the `RUNNING` state is running and ready for use.

## `scale`{% #scale %}

**Type**: `STRUCT`**Provider name**: `scale`**Description**: A floating-point percentage of your desired number of tasks to place and keep running in the task set.

- `unit`**Type**: `STRING`**Provider name**: `unit`**Description**: The unit of measure for the scale value.
- `value`**Type**: `DOUBLE`**Provider name**: `value`**Description**: The value, specified as a percent total of a service's `desiredCount`, to scale the task set. Accepted values are numbers between 0 and 100.

## `service_arn`{% #service_arn %}

**Type**: `STRING`**Provider name**: `serviceArn`**Description**: The Amazon Resource Name (ARN) of the service the task set exists in.

## `service_deployment_arn`{% #service_deployment_arn %}

**Type**: `STRING`**Provider name**: `serviceDeploymentArn`**Description**: The ARN of the service deployment.

## `service_registries`{% #service_registries %}

**Type**: `UNORDERED_LIST_STRUCT`**Provider name**: `serviceRegistries`**Description**: The details for the service discovery registries to assign to this task set. For more information, see [Service discovery](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html).

- `container_name`**Type**: `STRING`**Provider name**: `containerName`**Description**: The container name value to be used for your service discovery service. It's already specified in the task definition. If the task definition that your service task specifies uses the `bridge` or `host` network mode, you must specify a `containerName` and `containerPort` combination from the task definition. If the task definition that your service task specifies uses the `awsvpc` network mode and a type SRV DNS record is used, you must specify either a `containerName` and `containerPort` combination or a `port` value. However, you can't specify both.
- `container_port`**Type**: `INT32`**Provider name**: `containerPort`**Description**: The port value to be used for your service discovery service. It's already specified in the task definition. If the task definition your service task specifies uses the `bridge` or `host` network mode, you must specify a `containerName` and `containerPort` combination from the task definition. If the task definition your service task specifies uses the `awsvpc` network mode and a type SRV DNS record is used, you must specify either a `containerName` and `containerPort` combination or a `port` value. However, you can't specify both.
- `port`**Type**: `INT32`**Provider name**: `port`**Description**: The port value used if your service discovery service specified an SRV record. This field might be used if both the `awsvpc` network mode and SRV records are used.
- `registry_arn`**Type**: `STRING`**Provider name**: `registryArn`**Description**: The Amazon Resource Name (ARN) of the service registry. The currently supported service registry is Cloud Map. For more information, see [CreateService](https://docs.aws.amazon.com/cloud-map/latest/api/API_CreateService.html).

## `source_service_revisions`{% #source_service_revisions %}

**Type**: `UNORDERED_LIST_STRUCT`**Provider name**: `sourceServiceRevisions`**Description**: The currently deployed workload configuration.

- `arn`**Type**: `STRING`**Provider name**: `arn`**Description**: The ARN of the service revision.
- `pending_task_count`**Type**: `INT32`**Provider name**: `pendingTaskCount`**Description**: The number of pending tasks for the service revision.
- `requested_task_count`**Type**: `INT32`**Provider name**: `requestedTaskCount`**Description**: The number of requested tasks for the service revision.
- `running_task_count`**Type**: `INT32`**Provider name**: `runningTaskCount`**Description**: The number of running tasks for the service revision.

## `stability_status`{% #stability_status %}

**Type**: `STRING`**Provider name**: `stabilityStatus`**Description**: The stability status. This indicates whether the task set has reached a steady state. If the following conditions are met, the task set are in `STEADY_STATE`:

- The task `runningCount` is equal to the `computedDesiredCount`.
- The `pendingCount` is `0`.
- There are no tasks that are running on container instances in the `DRAINING` status.
- All tasks are reporting a healthy status from the load balancers, service discovery, and container health checks.
If any of those conditions aren't met, the stability status returns `STABILIZING`.


## `stability_status_at`{% #stability_status_at %}

**Type**: `TIMESTAMP`**Provider name**: `stabilityStatusAt`**Description**: The Unix timestamp for the time when the task set stability status was retrieved.

## `started_at`{% #started_at %}

**Type**: `TIMESTAMP`**Provider name**: `startedAt`**Description**: The time the service deployment statred. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.

## `started_by`{% #started_by %}

**Type**: `STRING`**Provider name**: `startedBy`**Description**: The tag specified when a task set is started. If an CodeDeploy deployment created the task set, the `startedBy` parameter is `CODE_DEPLOY`. If an external deployment created the task set, the `startedBy` field isn't used.

## `status`{% #status %}

**Type**: `STRING`**Provider name**: `status`**Description**: The status of the task set. The following describes each state.

{% dl %}

{% dt %}
PRIMARY
{% /dt %}

{% dd %}
The task set is serving production traffic.
{% /dd %}

{% dt %}
ACTIVE
{% /dt %}

{% dd %}
The task set isn't serving production traffic.
{% /dd %}

{% dt %}
DRAINING
{% /dt %}

{% dd %}
The tasks in the task set are being stopped, and their corresponding targets are being deregistered from their target group.
{% /dd %}

{% /dl %}



## `status_reason`{% #status_reason %}

**Type**: `STRING`**Provider name**: `statusReason`**Description**: Information about why the service deployment is in the current status. For example, the circuit breaker detected a failure.

## `stopped_at`{% #stopped_at %}

**Type**: `TIMESTAMP`**Provider name**: `stoppedAt`**Description**: The time the service deployment stopped. The format is yyyy-MM-dd HH:mm:ss.SSSSSS. The service deployment stops when any of the following actions happen:

- A user manually stops the deployment
- The rollback option is not in use for the failure detection mechanism (the circuit breaker or alarm-based) and the service fails.



## `tags`{% #tags %}

**Type**: `UNORDERED_LIST_STRING`

## `target_service_revision`{% #target_service_revision %}

**Type**: `STRUCT`**Provider name**: `targetServiceRevision`**Description**: The workload configuration being deployed.

- `arn`**Type**: `STRING`**Provider name**: `arn`**Description**: The ARN of the service revision.
- `pending_task_count`**Type**: `INT32`**Provider name**: `pendingTaskCount`**Description**: The number of pending tasks for the service revision.
- `requested_task_count`**Type**: `INT32`**Provider name**: `requestedTaskCount`**Description**: The number of requested tasks for the service revision.
- `running_task_count`**Type**: `INT32`**Provider name**: `runningTaskCount`**Description**: The number of running tasks for the service revision.

## `task_definition`{% #task_definition %}

**Type**: `STRING`**Provider name**: `taskDefinition`**Description**: The task definition that the task set is using.

## `task_set_arn`{% #task_set_arn %}

**Type**: `STRING`**Provider name**: `taskSetArn`**Description**: The Amazon Resource Name (ARN) of the task set.

## `updated_at`{% #updated_at %}

**Type**: `TIMESTAMP`**Provider name**: `updatedAt`**Description**: The Unix timestamp for the time when the task set was last updated.
