chore(elasticloadbalancingv2): add warning for missing ApplicationTargetGroup protocol

[pahud]

Issue # (if applicable)

Closes #35295.

Reason for this change

The AWS CDK ApplicationTargetGroup construct currently allows users to create target groups without specifying a protocol, which causes deployments to fail at runtime with AWS service errors ("A protocol must be specified (Service: ElasticLoadBalancingV2, Status Code: 400)") instead of providing early feedback during CDK synthesis.

As reported in #35295, developers can create ApplicationTargetGroups without specifying a protocol, and the error is only discovered during CloudFormation deployment rather than getting immediate guidance during development.

Description of changes

This change adds a warning-only enhancement to provide better developer experience without breaking existing code. When users create ApplicationTargetGroups without explicitly specifying a protocol (for non-Lambda targets), they now receive a clear warning message during synthesis.

Why warnings instead of validation errors?

We chose a warning-only approach for several important reasons:

1. Backward compatibility: Many existing CDK applications may have ApplicationTargetGroups without explicit protocol specification. Making this a hard validation error would break existing deployments and CI/CD pipelines.

2. Gradual migration: Warnings allow teams to identify and fix these issues at their own pace without blocking current development workflows.

3. Existing functionality: The current behavior technically works - it just fails later during CloudFormation deployment. A warning preserves this behavior while guiding users toward best practices.

4. Non-disruptive guidance: Warnings provide the educational benefit without forcing immediate code changes, allowing developers to prioritize fixes appropriately.

5. CDK philosophy: The CDK generally favors warnings for guidance over hard validation errors that could break existing code, especially for issues that don't prevent synthesis but may cause deployment problems.

Key changes

1. Warning for missing protocol: Added a warning in the ApplicationTargetGroup constructor when protocol is not specified for non-Lambda targets
2. Lambda exemption: Properly exempts Lambda target groups from protocol requirements (they should never have protocol specified)
3. Clear guidance: Provides actionable warning message with specific examples
4. Comprehensive tests: Added tests to verify warning behavior and edge cases

Technical implementation

// Add a warning if protocol wasn't explicitly specified for non-Lambda targets
if (props.protocol === undefined && this.targetType !== TargetType.LAMBDA) {
  Annotations.of(this).addWarningV2(
    '@aws-cdk/aws-elbv2:target-group-protocol-default',
    'ApplicationTargetGroup protocol not specified. Please specify protocol explicitly (e.g., ApplicationProtocol.HTTP or ApplicationProtocol.HTTPS). Note: Missing protocol will cause deployment failures.',
  );
}

Before this change

// This would succeed at synthesis but fail at deployment
const targetGroup = new ApplicationTargetGroup(this, 'TargetGroup', { 
  vpc: vpc 
});
// No warning, deployment fails later

After this change

// This now shows helpful warning during synthesis
const targetGroup = new ApplicationTargetGroup(this, 'TargetGroup', { 
  vpc: vpc 
});
// Warning: "ApplicationTargetGroup protocol not specified. Please specify protocol explicitly (e.g., ApplicationProtocol.HTTP or ApplicationProtocol.HTTPS). Note: Missing protocol will cause deployment failures."

// Recommended fix:
const targetGroup = new ApplicationTargetGroup(this, 'TargetGroup', { 
  vpc: vpc,
  protocol: ApplicationProtocol.HTTP 
});

Benefits

• Non-breaking: Existing code continues to work unchanged
• Early feedback: Developers get immediate guidance during synthesis
• Clear guidance: Warning message explains the issue and provides examples
• Prevents deployment failures: Helps catch the issue before costly deployment attempts
• Lambda-aware: Correctly handles Lambda target groups which don't need protocol

Description of how you validated changes

Unit Tests

• Added comprehensive tests for protocol warning behavior
• Verified Lambda target groups are exempt from protocol warnings
• Tested warning message content and conditions
• Confirmed all existing tests continue to pass

Integration Tests

• All existing ELBv2 integration tests pass
• No snapshot updates required (no CloudFormation changes)
• Verified backward compatibility

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]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[ozelalisen]

It is also sufficient to provide port number for stack to be deployable. We can check if both of those are undefined, otherwise ask it to provide either one of them. In the scenario where port number is provided, I can still get this validation error, even though I do not have any issue.

Reference to documentation: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationTargetGroup.html#port

This change would require an update in the unit tests as well

[ozelalisen]

Left a comment

[ozelalisen]

This validation should remain in the validateTargetGroup method to maintain consistency with existing validation patterns. This change weakens validation by converting an error to a warning and moves logic outside the dedicated validation method.

I noticed also that the original validation logic was incorrect (used || instead of &&). We can fix this since, changing it to && logic actually loosens the validation, so it's not a breaking change.

We can do:

1. Fix the existing error validation in validateTargetGroup (change || to && logic)
2. Add the warning annotation as supplementary feedback within validateTargetGroup when targetType is undefined