LoadBalancedFargateService Improvements

[chelma-amzn]

I'm using the TypeScript version of CDK v0.36.0.

While considering whether I would be able to use the LoadBalancedFargateService instead of making my own combination of manually defined constructs I ran into a number of issues, several of which were blockers for me.

1. Because the LoadBalancedServiceBase stores its Load Balancer as an elbv2.BaseLoadBalancer, users must typecast the Load Balancer member to access things like the native CloudWatch metrics they provide. This is less than ideal, as it forces the user to pierce the veil of your abstraction. It may also cause problems in the case where one person is vending another person a collection of constructs, and the consumer doesn't know whether the LB is an Application or Network LB.

const loadBalancedService = new ecsPatternsLoadBalancedFargateService(...);

new cloudwatch.Alarm(this, "AlarmHealthyHostsCount", {
    metric: (<elbv2.NetworkLoadBalancer> loadBalancedService.loadBalancer).metricHealthyHostCount(),
    threshold: 1,
    evaluationPeriods: 1,
    period: core.Duration.seconds(60),
    comparisonOperator: cloudwatch.ComparisonOperator.LESS_THAN_THRESHOLD,
    statistic: "Average"
});

2. There does not appear to be a way to access the CloudWatch LogGroup object created by the Service's AwsLogDriver. This means it's not possible to do things like set up MetricFilters on those logs. This is a blocker, as there's also no way to pass in a log group for the driver to use.

3. There does not appear to be a way to configure the created LoadBalancer's target groups, which means that it isn't possible to configure custom health checks for the LB to send traffic to ECS tasks and instead the default behavior must be relied on. This is another blocker.

[eladb]

@chelma-amzn any chance I can bug you to split this into 3 separate issues?

[chelma-amzn]

Moved first item to its own ticket: #3499

[chelma-amzn]

Moved second item to its own ticket: #3500

[chelma-amzn]

#3 is actually a no-op; there is a way to configure the TargetGroup health checks after the LoadBalancedFargateService instantiates it:

const loadBalancedFargateService = new ecsPatterns.LoadBalancedFargateService(this, 'Service', {
    cluster: props.ecsCluster,
    memoryLimitMiB: 1024,
    cpu: 512,
    image: ecs.ContainerImage.fromRegistry("amazon/amazon-ecs-sample"),
    loadBalancerType: ecsPatterns.LoadBalancerType.NETWORK
});

(loadBalancedFargateService.targetGroup as elbv2.NetworkTargetGroup).configureHealthCheck({
    port: "traffic-port",
    protocol: elbv2.Protocol.TCP
});

[eladb]

@chelma-amzn can this be closed?

[chelma-amzn]

I believe so. The issue basically raised two problems - the default LogGroup instantiation couldn't be configured and there were a number of issues caused by the storage of LoadBalancers as their base class. We can close this top level issue and resolve the individual asks in their own issues.