# Required resources for Amazon ECS blue/green deployments To use a blue/green deployment with managed traffic shifting, your service must use one of the following features: + Elastic Load Balancing + Service Connect Services that don't use Service Discovery, Service Connect, VPC Lattice or Elastic Load Balancing can also use blue/green deployments, but don't get any of the managed traffic shifting benefits. The following list provides a high-level overview of what you need to configure for Amazon ECS blue/green deployments: + Your service uses an Application Load Balancer, Network Load Balancer, or Service Connect. Configure the appropriate resources. + Application Load Balancer - For more information, see [Application Load Balancer resources for blue/green, linear, and canary deployments](alb-resources-for-blue-green.md). + Network Load Balancer - For more information, see [Network Load Balancer resources for Amazon ECS blue/green, linear and canary deployments](nlb-resources-for-blue-green.md). + Service Connect - For more information, see [Service Connect resources for Amazon ECS blue/green, linear, and canary deployments](service-connect-blue-green.md). + Set the service deployment controller to `ECS`. + Configure the deployment strategy as `blue/green` in your service definition. + Optionally, configure additional parameters such as: + Bake time for the new deployment + CloudWatch alarms for automatic rollback + Deployment lifecycle hooks for testing (these are Lambda functions that run at specified deployment stages) ## Best practices Follow these best practices for successful Amazon ECS blue/green deployments: + Configure appropriate health checks that accurately reflect your application's health. + Set a bake time that allows sufficient testing of the green deployment. + Implement CloudWatch alarms to automatically detect issues and trigger rollbacks. + Use lifecycle hooks to perform automated testing at each deployment stage. + Ensure your application can handle both blue and green service revisions running simultaneously. + Plan for sufficient cluster capacity to handle both service revisions during deployment. + Test your rollback procedures before implementing them in production. # Application Load Balancer resources for blue/green, linear, and canary deployments To use Application Load Balancers with Amazon ECS blue/green deployments, you need to configure specific resources that allow traffic routing between the blue and green service revisions. ## Target groups For blue/green deployments with Elastic Load Balancing, you need to create two target groups: + A primary target group for the blue service revision (current production traffic) + An alternate target group for the green service revision (new version) Both target groups should be configured with the following settings: + Target type: `IP` (for Fargate or EC2 with `awsvpc` network mode) + Protocol: `HTTP` (or the protocol your application uses) + Port: The port your application listens on (typically `80` for HTTP) + VPC: The same VPC as your Amazon ECS tasks + Health check settings: Configured to properly check your application's health During a blue/green deployment, Amazon ECS automatically registers tasks with the appropriate target group based on the deployment stage. **Example Creating target groups for an Application Load Balancer** The following CLI commands create two target groups for use with an Application Load Balancer in a blue/green deployment: ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 aws elbv2 create-target-group \ --name green-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 ``` ## Application Load Balancer You need to create an Application Load Balancer with the following configuration: + Scheme: Internet-facing or internal, depending on your requirements + IP address type: IPv4 + VPC: The same VPC as your Amazon ECS tasks + Subnets: At least two subnets in different Availability Zones + Security groups: A security group that allows traffic on the listener ports The security group attached to the Application Load Balancer must have an outbound rule that allows traffic to the security group attached to your Amazon ECS tasks. **Example Creating an Application Load Balancer** The following CLI command creates anApplication Load Balancer for use in a blue/green deployment: ``` aws elbv2 create-load-balancer \ --name my-application-load-balancer \ --type application \ --security-groups sg-abcd1234 \ --subnets subnet-12345678 subnet-87654321 ``` ## Listeners and rules For blue/green deployments, you need to configure listeners on your Application Load Balancer: + Production listener: Handles production traffic (typically on port 80 or 443) + Initially forwards traffic to the primary target group (blue service revision) + After deployment, forwards traffic to the alternate target group (green service revision) + Test listener (optional): Handles test traffic to validate the green service revision before shifting production traffic + Can be configured on a different port (for example, 8080 or 8443) + Forwards traffic to the alternate target group (green service revision) during testing During a blue/green deployment, Amazon ECS automatically updates the listener rules to route traffic to the appropriate target group based on the deployment stage. **Example Creating a production listener** The following CLI command creates a production listener on port 80 that forwards traffic to the primary (blue) target group: ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456 ``` **Example Creating a test listener** The following CLI command creates a test listener on port 8080 that forwards traffic to the alternate (green) target group: ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 8080 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Creating a listener rule for path-based routing** The following CLI command creates a rule that forwards traffic for a specific path to the green target group for testing: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 10 \ --conditions Field=path-pattern,Values='/test/*' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Creating a listener rule for header-based routing** The following CLI command creates a rule that forwards traffic with a specific header to the green target group for testing: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 20 \ --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` ## Service configuration You must have permissions to allow Amazon ECS to manage load balancer resources in your clusters on your behalf. For more information, see [Amazon ECS infrastructure IAM role for load balancers](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). When creating or updating an Amazon ECS service for blue/green deployments with Elastic Load Balancing, you need to specify the following configuration. Replace the *user-input* with your values. The key components in this configuration are: + `targetGroupArn`: The ARN of the primary target group (blue service revision). + `alternateTargetGroupArn`: The ARN of the alternate target group (green service revision). + `productionListenerRule`: The ARN of the listener rule for production traffic. + `roleArn`: The ARN of the role that allows Amazon ECS to manage Elastic Load Balancing resources. + `strategy`: Set to `BLUE_GREEN` to enable blue/green deployments. + `bakeTimeInMinutes`: The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted. + `TestListenerRule`: The ARN of the listener rule for test traffic. This is an optional parameter. ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012", "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678", "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Traffic flow during deployment During a blue/green deployment with Elastic Load Balancing, traffic flows through the system as follows: 1. *Initial state*: All production traffic is routed to the primary target group (blue service revision). 1. *Green service revision deployment*: Amazon ECS deploys the new tasks and registers them with the alternate target group. 1. *Test traffic*: If a test listener is configured, test traffic is routed to the alternate target group to validate the green service revision. 1. *Production traffic shift*: Amazon ECS updates the production listener rule to route traffic to the alternate target group (green service revision). 1. *Bake time*: The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted. 1. *Completion*: After a successful deployment, the blue service revision is terminated. If issues are detected during the deployment, Amazon ECS can automatically roll back by routing traffic back to the primary target group (blue service revision). # Network Load Balancer resources for Amazon ECS blue/green, linear and canary deployments To use a Network Load Balancer with Amazon ECS blue/green deployments, you need to configure specific resources that enable traffic routing between the blue and green service revisions. This section explains the required components and their configuration. When your configuration includes a Network Load Balancer, Amazon ECS adds a 10 minute delay to the following lifecycle stages: + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT This delay accounts for Network Load Balancer timing issues that can cause a mismatch between the configured traffic weights and the actual traffic routing in the data plane. ## Target groups For blue/green deployments with a Network Load Balancer, you need to create two target groups: + A primary target group for the blue service revision (current production traffic) + An alternate target group for the green service revision (new service revision) Both target groups should be configured with the following settings: + Target type: `ip` (for Fargate or EC2 with `awsvpc` network mode) + Protocol: `TCP` (or the protocol your application uses) + Port: The port your application listens on (typically `80` for HTTP) + VPC: The same VPC as your Amazon ECS tasks + Health check settings: Configured to properly check your application's health For TCP health checks, the Network Load Balancer establishes a TCP connection with the target. If the connection is successful, the target is considered healthy. For HTTP/HTTPS health checks, the Network Load Balancer sends an HTTP/HTTPS request to the target and verifies the response. During a blue/green deployment, Amazon ECS automatically registers tasks with the appropriate target group based on the deployment stage. **Example Creating target groups for a Network Load Balancer** The following AWS CLI commands create two target groups for use with a Network Load Balancer in a blue/green deployment: ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP aws elbv2 create-target-group \ --name green-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP ``` ## Network Load Balancer You need to create a Network Load Balancer with the following configuration: + Scheme: Internet-facing or internal, depending on your requirements + IP address type: IPv4 + VPC: The same VPC as your Amazon ECS tasks + Subnets: At least two subnets in different Availability Zones Unlike Application Load Balancers, Network Load Balancers operate at the transport layer (Layer 4) and do not use security groups. Instead, you need to ensure that the security groups associated with your Amazon ECS tasks allow traffic from the Network Load Balancer on the listener ports. **Example Creating a Network Load Balancer** The following AWS CLI command creates a Network Load Balancer for use in a blue/green deployment: ``` aws elbv2 create-load-balancer \ --name my-network-load-balancer \ --type network \ --subnets subnet-12345678 subnet-87654321 ``` ## Considerations for using NLB with blue/green deployments When using a Network Load Balancer for blue/green deployments, consider the following: + **Layer 4 operation**: Network Load Balancers operate at the transport layer (Layer 4) and do not inspect application layer (Layer 7) content. This means you cannot use HTTP headers or paths for routing decisions. + **Health checks**: Network Load Balancer health checks are limited to TCP, HTTP, or HTTPS protocols. For TCP health checks, the Network Load Balancer only verifies that the connection can be established. + **Connection preservation**: Network Load Balancers preserve the source IP address of the client, which can be useful for security and logging purposes. + **Static IP addresses**: Network Load Balancers provide static IP addresses for each subnet, which can be useful for whitelisting or when clients need to connect to a fixed IP address. + **Test traffic**: Since Network Load Balancers do not support content-based routing, test traffic must be sent to a different port than production traffic. ## Listeners and rules For blue/green deployments with a Network Load Balancer, you need to configure listeners: + Production listener: Handles production traffic (typically on port 80 or 443) + Initially forwards traffic to the primary target group (blue service revision) + After deployment, forwards traffic to the alternate target group (green service revision) + Test listener (optional): Handles test traffic to validate the green service revision before shifting production traffic + Can be configured on a different port (e.g., 8080 or 8443) + Forwards traffic to the alternate target group (green service revision) during testing Unlike Application Load Balancers, Network Load Balancers do not support content-based routing rules. Instead, traffic is routed based on the listener port and protocol. The following AWS CLI commands create production and test listeners for a Network Load Balancer: Replace the *user-input* with your values. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 80 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456 aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 8080 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456 ``` ## Service configuration You must have permissions to allow Amazon ECS to manage load balancer resources in your clusters on your behalf. For more information, see [Amazon ECS infrastructure IAM role for load balancers](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). When creating or updating an Amazon ECS service for blue/green deployments with a Network Load Balancer, you need to specify the following configuration: Replace the *user-input* with your values. The key components in this configuration are: + `targetGroupArn`: The ARN of the primary target group (blue service revision) + `alternateTargetGroupArn`: The ARN of the alternate target group (green service revision) + `productionListenerRule`: The ARN of the listener for production traffic + `testListenerRule`: (Optional) The ARN of the listener for test traffic + `roleArn`: The ARN of the role that allows Amazon ECS to manage Network Load Balancer resources + `strategy`: Set to `BLUE_GREEN` to enable blue/green deployments + `bakeTimeInMinutes`: The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456", "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456", "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567", "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Traffic flow during deployment During a blue/green deployment with a Network Load Balancer, traffic flows through the system as follows: 1. *Initial state*: All production traffic is routed to the primary target group (blue service revision). 1. *Green service revision deployment*: Amazon ECS deploys the new tasks and registers them with the alternate target group. 1. *Test traffic*: If a test listener is configured, test traffic is routed to the alternate target group to validate the green service revision. 1. *Production traffic shift*: Amazon ECS updates the production listener to route traffic to the alternate target group (green service revision). 1. *Bake time*: The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted. 1. *Completion*: After a successful deployment, the blue service revision is terminated. If issues are detected during the deployment, Amazon ECS can automatically roll back by routing traffic back to the primary target group (blue service revision). # Service Connect resources for Amazon ECS blue/green, linear, and canary deployments When using Service Connect with blue/green deployments, you need to configure specific components to enable proper traffic routing between the blue and green service revisions. This section explains the required components and their configuration. ## Architecture overview Service Connect builds both service discovery and service mesh capabilities through a managed sidecar proxy that's automatically injected into your Amazon ECS tasks. These proxies handle routing decisions, retries, and metrics collection, while AWS Cloud Map provides the service registry backend. When you deploy a service with Service Connect enabled, the service registers itself in AWS Cloud Map, and client services discover it through the namespace. In a standard Service Connect implementation, client services connect to logical service names, and the sidecar proxy handles routing to the actual service instances. With blue/green deployments, this model is extended to include test traffic routing through the `testTrafficRules` configuration. During a blue/green deployment, the following key components work together: + **Service Connect Proxy**: All traffic between services passes through the Service Connect proxy, which makes routing decisions based on the configuration. + **AWS Cloud Map Registration**: Both blue and green deployments register with AWS Cloud Map, but the green deployment initially registers as a "test" endpoint. + **Test Traffic Routing**: The `testTrafficRules` in the Service Connect configuration determine how to identify and route test traffic to the green deployment. This is accomplished through **header-based routing**, where specific HTTP headers in the requests direct traffic to the test revision. By default, Service Connect recognizes the `x-amzn-ecs-blue-green-test` header for HTTP-based protocols when no custom rules are specified. + **Client Configuration**: All clients in the namespace automatically receive both production and test routes, but only requests matching test rules will go to the green deployment. What makes this approach powerful is that it handles the complexity of service discovery during transitions. As traffic shifts from the blue to green deployment, all connectivity and discovery mechanisms update automatically. There's no need to update DNS records, reconfigure load balancers, or deploy service discovery changes separately since the service mesh handles it all. ## Traffic routing and testing Service Connect provides advanced traffic routing capabilities for blue/green deployments, including header-based routing and client alias configuration for testing scenarios. ### Test traffic header rules During blue/green deployments, you can configure test traffic header rules to route specific requests to the green (new) service revision for testing purposes. This allows you to validate the new version with controlled traffic before completing the deployment. Service Connect uses **header-based routing** to identify test traffic. By default, Service Connect recognizes the `x-amzn-ecs-blue-green-test` header for HTTP-based protocols when no custom rules are specified. When this header is present in a request, the Service Connect proxy automatically routes the request to the green deployment for testing. Test traffic header rules enable you to: + Route requests with specific headers to the green service revision + Test new functionality with a subset of traffic + Validate service behavior before full traffic cutover + Implement canary testing strategies + Perform integration testing in a production-like environment The header-based routing mechanism works seamlessly with your existing application architecture. Client services don't need to be aware of the blue/green deployment process - they simply include the appropriate headers when sending test requests, and the Service Connect proxy handles the routing logic automatically. For more information about configuring test traffic header rules, see [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html) in the *Amazon Elastic Container Service API Reference*. ### Header matching rules Header matching rules define the criteria for routing test traffic during blue/green deployments. You can configure multiple matching conditions to precisely control which requests are routed to the green service revision. Header matching supports: + Exact header value matching + Header presence checking + Pattern-based matching + Multiple header combinations Example use cases include routing requests with specific user agent strings, API versions, or feature flags to the green service for testing. For more information about header matching configuration, see [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html) in the *Amazon Elastic Container Service API Reference*. ### Client aliases for blue/green deployments Client aliases provide stable DNS endpoints for services during blue/green deployments. They enable seamless traffic routing between blue and green service revisions without requiring client applications to change their connection endpoints. During a blue/green deployment, client aliases: + Maintain consistent DNS names for client connections + Enable automatic traffic switching between service revisions + Support gradual traffic migration strategies + Provide rollback capabilities by redirecting traffic to the blue revision You can configure multiple client aliases for different ports or protocols, allowing complex service architectures to maintain connectivity during deployments. For more information about client alias configuration, see [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html) in the *Amazon Elastic Container Service API Reference*. ### Best practices for traffic routing When implementing traffic routing for blue/green deployments with Service Connect, consider the following best practices: + **Start with header-based testing**: Use test traffic header rules to validate the green service with controlled traffic before switching all traffic. + **Configure health checks**: Ensure both blue and green services have appropriate health checks configured to prevent routing traffic to unhealthy instances. + **Monitor service metrics**: Track key performance indicators for both service revisions during the deployment to identify issues early. + **Plan rollback strategy**: Configure client aliases and routing rules to enable quick rollback to the blue service if issues are detected. + **Test header matching logic**: Validate your header matching rules in a non-production environment before applying them to production deployments. ## Service Connect blue/green deployment workflow Understanding how Service Connect manages the blue/green deployment process helps you implement and troubleshoot your deployments effectively. The following workflow shows how the different components interact during each phase of the deployment. ### Deployment phases A Service Connect blue/green deployment progresses through several distinct phases: 1. **Initial State**: The blue service handles 100% of production traffic. All client services in the namespace connect to the blue service through the logical service name configured in Service Connect. 1. **Green Service Registration**: When the green deployment starts, it registers with AWS Cloud Map as a "test" endpoint. The Service Connect proxy in client services automatically receives both production and test route configurations. 1. **Test Traffic Routing**: Requests containing the test traffic headers (such as `x-amzn-ecs-blue-green-test`) are automatically routed to the green service by the Service Connect proxy. Production traffic continues to flow to the blue service. 1. **Traffic Shift Preparation**: After successful testing, the deployment process prepares for production traffic shift. Both blue and green services remain registered and healthy. 1. **Production Traffic Shift**: The Service Connect configuration updates to route production traffic to the green service. This happens automatically without requiring client service updates or DNS changes. 1. **Bake Time Period**: The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted. 1. **Blue Service Deregistration**: After successful traffic shift and validation, the blue service is deregistered from AWS Cloud Map and terminated, completing the deployment. ### Service Connect proxy behavior The Service Connect proxy plays a crucial role in managing traffic during blue/green deployments. Understanding its behavior helps you design effective testing and deployment strategies. Key proxy behaviors during blue/green deployments: + **Automatic Route Discovery**: The proxy automatically discovers both production and test routes from AWS Cloud Map without requiring application restarts or configuration changes. + **Header-Based Routing**: The proxy examines incoming request headers and routes traffic to the appropriate service revision based on the configured test traffic rules. + **Health Check Integration**: The proxy only routes traffic to healthy service instances, automatically excluding unhealthy tasks from the routing pool. + **Retry and Circuit Breaking**: The proxy provides built-in retry logic and circuit breaking capabilities, improving resilience during deployments. + **Metrics Collection**: The proxy collects detailed metrics for both blue and green services, enabling comprehensive monitoring during deployments. ### Service discovery updates One of the key advantages of using Service Connect for blue/green deployments is the automatic handling of service discovery updates. Traditional blue/green deployments often require complex DNS updates or load balancer reconfiguration, but Service Connect manages these changes transparently. During a deployment, Service Connect handles: + **Namespace Updates**: The Service Connect namespace automatically includes both blue and green service endpoints, with appropriate routing rules. + **Client Configuration**: All client services in the namespace automatically receive updated routing information without requiring restarts or redeployment. + **Gradual Transition**: Service discovery updates happen gradually and safely, ensuring no disruption to ongoing requests. + **Rollback Support**: If a rollback is needed, Service Connect can quickly revert service discovery configurations to route traffic back to the blue service.