feat(ecs-patterns): add blue/green deployment support for application load balanced services

[walkley]

Closes #35467.

Reason for this change

AWS CDK users need a high-level API to configure blue/green deployments for ApplicationLoadBalanced ECS patterns. Currently, users must manually configure low-level ECS service properties and alternate target groups, which is complex and error-prone. This feature request adds blue/green deployment support directly to the ECS patterns API, making it accessible through a simple, declarative interface.

Description of changes

Added optional blue/green deployment configuration to ApplicationLoadBalanced ECS patterns:

• New Interface: BlueGreenDeploymentConfiguration interface with properties for alternate target group, production listener, optional test listener, and optional IAM role
• Extended Props: Added optional blueGreenDeployment property to ApplicationLoadBalancedServiceBaseProps interface
• Enhanced Service Target: Modified addServiceAsTarget() method to create AlternateTarget configuration when blue/green properties are specified
• CloudFormation Integration: Generates AdvancedConfiguration in ECS Service LoadBalancers array with proper alternate target group and listener rule references
• Backward Compatibility: All changes are additive and optional - existing applications continue to work unchanged

The implementation leverages existing AlternateTarget infrastructure from the aws-ecs module, providing a clean separation between high-level pattern configuration and low-level ECS service setup.

Describe any new or updated permissions being added

N/A - No new IAM permissions are introduced. The feature leverages existing IAM role creation and managed policies from the underlying AlternateTarget class in the aws-ecs module.

Description of how you validated changes

• Unit tests: Added 4 comprehensive unit tests covering all blue/green deployment scenarios:
  • Basic blue/green configuration with production listener only
  • Blue/green configuration with both production and test listeners
  • Blue/green configuration with custom IAM role
  • Backward compatibility verification (services without blue/green work unchanged)
• Integration tests: Leverages existing aws-ecs integration tests for AlternateTarget functionality
• CloudFormation validation: Tests verify that AdvancedConfiguration is properly generated in ECS Service LoadBalancers with correct alternate target group ARN, role ARN, and listener rule configurations
• Regression testing: Full test suite execution (15,928/15,937 tests passing) confirms no breaking changes to existing functionality
• JSII compatibility: Fixed and verified JSII compilation by creating separate interface instead of inline object literal type

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Features must contain a change to an integration test file and the resulting snapshot.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

[eoin-betdex]

Hi I raised the issue for this and so was working on it also, but since you have your PR up first I guess I'll leave it and you can finish the change.

I don't know the reviewer guidelines for this module but I thought I'd add my $0.02.

ecs-patterns is meant to be a higher level library. Updating the interface to require load balancer listener rules and a target group to be passed in seems against that idea. That is to say, if the client must set up the load balancer themselves in order to pass in the listener then this reduces the usefulness of this library over using the ecs module directly.

I would have expected ApplicationLoadBalancedServiceBase to handle defining the alternate target group, and the production listener rule, possibly providing optional configuration/customisation props for the library client to use, e.g., optional production listener rule conditions that would override some default like pathPatterns['/*'].

This change also does not expose any ability to configure the Blue/Green deployment strategy properties for the Service: bakeInTime or lifecycleHooks.

I'd also be interested in knowing if you've managed to deploy a service using this change. As while my own attempt at this has different approach in the interface, the result is quite similar and I have not managed to get it to deploy successfully yet.

[kaizencc]

HI @walkley, thanks for the PR. I agree entirely with @eoin-betdex's comments regarding this approach. Fundamentally, ecs-patterns is different from the rest of aws-cdk-lib, it's an L3 construct with higher level patterns that only exists in the aws-cdk-lib for legacy reasons. In fact, at some point the ecs service team wanted users to migrate to a version of ecs-patterns outside of the aws-cdk-lib: https://github.com/cdklabs/cdk-ecs-service-extensions. I'm not sure how that's going in practice however :).

Since this is a submodule for L3 patterns for ecs, I think more design is necessary to nail down an incredible user experience. From a technical standpoint, there definitely needs to be an integ test to ensure that everything deploys propery.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. Note that PRs with failing linting check or builds are not reviewed, please ensure your build is passing

To prevent automatic closure:

• Resume work on the PR
• OR request an exemption by adding a comment containing 'Exemption Request' with justification e.x "Exemption Request: "
• OR request clarification by adding a comment containing 'Clarification Request' with a question e.x "Clarification Request: "

This PR will automatically close in 14 days if no action is taken.