> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/ecs-blue-green-faqs.md).

# ECS deployment FAQs

Frequently asked questions about ECS Blue-Green deployments.

This topic addresses frequently asked questions about Elastic Container Service (ECS) deployments in Harness.

<details>

<summary>What is the difference between the Swap and Traffic Shift steps?</summary>

There are two distinct flows for ECS Blue-Green deployments, and only one can be used in a pipeline.

**Swap step (traditional flow)**: The Blue-Green deploy step asks for **production and stage listener rules** (two separate rules, typically on different ports), and does not ask for stage target group input. Target groups are determined automatically based on which listener rule they are attached to. Running the pipeline multiple times with the same configuration automatically alternates two versions of services between Blue and Green. At the end of each deployment, the target group attached to the production listener rule has the blue service.

**Traffic Shift step (new flow)**: The Blue-Green step asks for **one listener rule only** (production rule), and this rule must be attached to precisely two target groups: stage and production. This flow requires manual input for the stage target group ARN to determine which of the two target groups is stage versus production. This design choice is intentional because configurations often use a 60-40 or 20-80 traffic split, not just 0-100. With non-zero traffic on both target groups, Harness cannot automatically determine which target group is stage versus production.

</details>

<details>

<summary>Why does Harness not automatically determine the stage target group like it does for ASG?</summary>

In Auto Scaling Group (ASG) deployments, Harness automatically determines the production target group as the one with 100% weight. For ECS traffic shifting, the behavior is different for the following reasons:

* Traffic configurations often use a 60-40, 20-80, or other split.
* Traffic is not always split 0-100, which makes automatic determination unreliable.
* Requiring explicit stage target group input gives you complete control over which target group receives the new deployment.

</details>

<details>

<summary>Why does my active service get deleted during deployment?</summary>

If your active service gets deleted during deployment, you likely see log lines similar to the following:

```
Deleting existing non-blue version Service: echo-service__1
Waiting for existing Service echo-service__1 to reach inactive state
Deleted non-blue version Service: echo-service__1
```

Harness deletes any non-blue services attached to the stage target group at the start of each deployment. If you reuse the same stage target group that contains your current blue (active) service, Harness deletes it.

To avoid this, alternate the stage target group between deployments:

1. **First deployment**: Use `target-group-a` as the stage target group. After the 100% shift, `target-group-a` has the blue service.
2. **Second deployment**: Use `target-group-b` as the stage target group. After the 100% shift, `target-group-b` has the blue service, and `target-group-a` has the green service.
3. **Third deployment**: Use `target-group-a` as the stage target group again, which continues the alternating pattern.

</details>

<details>

<summary>If I constantly shift 100% traffic, do I still need to alternate target groups?</summary>

Yes. Even with a 100% traffic shift, you must alternate the stage target group between deployments if you want to maintain two versions of services alternating between Blue and Green, similar to the traditional swap flow.

If you do not alternate the stage target group, the following happens:

* First deployment: Blue service `__1` is created in the stage target group with 100% traffic.
* Second deployment (same stage target group): Harness sees service `__1` attached to the stage target group, considers it non-blue because it is in the stage target group, and deletes it before deploying new service `__2`.
* You lose the ability to maintain two alternating versions.

If you do alternate the stage target group, the following happens instead:

* First deployment: Blue service `__1` is created in `target-group-a` with 100% traffic.
* Second deployment (using `target-group-b`): Service `__1` is now tagged as green (in the production target group), and blue service `__2` is created in `target-group-b` with 100% traffic.
* Third deployment (using `target-group-a`): Service `__2` is now green, and blue service `__3` is created in `target-group-a` with 100% traffic.

</details>

<details>

<summary>How can I achieve traffic shifting without manual stage target group selection?</summary>

You can automate stage target group selection using a shell script step before the ECS Blue Green Create Service step. This eliminates the need for manual selection on each deployment.

The following script configuration selects the target group with the lower traffic weight:

```bash
#!/bin/bash

# Configuration
LISTENER_RULE_ARN="<+pipeline.variables.prodListenerRuleArn>"
TARGET_GROUP_A="<+pipeline.variables.targetGroupA>"
TARGET_GROUP_B="<+pipeline.variables.targetGroupB>"

# Get current listener rule configuration
RULE_CONFIG=$(aws elbv2 describe-rules --rule-arns "$LISTENER_RULE_ARN" --query 'Rules[0].Actions[0].ForwardConfig.TargetGroups' --output json)

# Extract weights for each target group
WEIGHT_A=$(echo "$RULE_CONFIG" | jq -r ".[] | select(.TargetGroupArn==\"$TARGET_GROUP_A\") | .Weight")
WEIGHT_B=$(echo "$RULE_CONFIG" | jq -r ".[] | select(.TargetGroupArn==\"$TARGET_GROUP_B\") | .Weight")

# Select the target group with 0% traffic (or lower weight)
if [ "$WEIGHT_A" -lt "$WEIGHT_B" ]; then
  STAGE_TARGET_GROUP="$TARGET_GROUP_A"
  echo "Selected Target Group A: $STAGE_TARGET_GROUP"
else
  STAGE_TARGET_GROUP="$TARGET_GROUP_B"
  echo "Selected Target Group B: $STAGE_TARGET_GROUP"
fi

# Export as output variable
export STAGE_TARGET_GROUP_ARN="$STAGE_TARGET_GROUP"
```

Reference the output in your ECS Blue Green Create Service step as follows:

```yaml
stageTargetGroupArn: <+execution.steps.SelectTargetGroup.output.outputVariables.STAGE_TARGET_GROUP_ARN>
```

</details>

<details>

<summary>Can Harness provide a plugin or automatic inference for stage target group selection?</summary>

Stage target group selection is a manual input to support various traffic split configurations. If you have a specific use case that requires automatic inference, you can raise an enhancement request with Harness Support to explore options such as:

* Publishing a plugin for automatic target group selection.
* Adding configuration options for automatic inference based on traffic weights.
* Supporting specific traffic patterns, for example always selecting the target group with 0% weight.

</details>

<details>

<summary>What are the best practices for stage target group selection?</summary>

Follow these recommendations when selecting a stage target group for an ECS Blue-Green deployment:

1. **Use runtime input**: Configure `stageTargetGroupArn: <+input>` to manually verify the value before each deployment.
2. **Document your target groups**: Keep a record of your two target group ARNs and which one was used in the last deployment.
3. **Implement automation**: Use a shell script step to automatically select the target group with lower or zero traffic.
4. **Verify before deployment**: Check the AWS Console to confirm which target group holds 100% of traffic, since this is your blue service.
5. **Select the opposite target group**: Choose the other target group as the stage target group for the new deployment.

</details>

<details>

<summary>Does Harness support Network Load Balancers with multiple listeners for Blue-Green deployments?</summary>

No, multi-listener Blue-Green deployments with a Network Load Balancer (NLB) are not supported.

Harness supports Blue-Green deployments using an NLB, but only with a single pair of stage and production listeners. If your ECS service uses an NLB with multiple listeners (multiple ports exposed), the Blue-Green deployment strategy with dynamic target group switching does not work, for the following reasons:

* Only one stage listener and one production listener pair is supported.
* Multi-listener configurations are not supported, even though ECS natively supports them.

As a result, if your NLB exposes multiple ports (for example, port 80, port 443, and port 8080), Harness cannot perform automatic traffic shifting across all these listeners. Only a single listener and target group pair is managed by Harness during Blue-Green deployments.

Consider one of the following alternative approaches:

* Use an Application Load Balancer (ALB) instead, which fully supports Blue-Green deployments with Harness.
* Use a Rolling deployment strategy instead of Blue-Green if an NLB with multiple listeners is required.
* Configure separate load balancers for each port or service if Blue-Green is required.

</details>

## Related documentation

For more information about ECS Blue-Green deployments, see the following topics.

* [ECS Blue-Green Traffic Shifting Step](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/traffic-shifting.md): Configure the Traffic Shift step for ECS Blue-Green deployments.
* [ECS Deployments Overview](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/ecs-deployment-tutorial.md): Learn how to set up and run ECS deployments in Harness.

{% @harness-feedback/feedback %}