[ECS] [BUG]: Create Service Fails Using Multiple TG and Role Specified

[nataizya-s]

Specifying the Role when creating a service with 2 target groups fails:

$ aws ecs create-service --cluster test --service-name test --task-definition nginx:1 --load-balancers '[{ "targetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/test1/8717e8583778e6c1", "containerName":"nginx", "containerPort": 80 }, { "targetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/test2/f003525972e6665a", "containerName": "nginx", "containerPort":80 } ]' --desired-count 1 --role ECS

         An error occurred (InvalidParameterException) when calling the CreateService operation: You cannot specify an IAM role for services that require a service linked role.

Tested this with both the CLI and with CloudFormation as described in the docs https://aws.amazon.com/about-aws/whats-new/2019/07/amazon-ecs-services-now-support-multiple-load-balancer-target-groups/.

When the second target group is removed, it works as expected and the service is created successfully.

Why is it that the role is not recognized as a service linked role?

[rohanmangal]

Duplicate of https://github.com/aws/containers-roadmap/issues/12#issuecomment-516908024#

And Customized service role is not equal to Service Linked Role(SLR).

As per :https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html#ECS-CreateService-request-role

It says:
This parameter is only permitted if you are using a load balancer with your service and your task definition does not use the awsvpc network mode. If you specify the role parameter, you must also specify a load balancer object with the loadBalancers parameter.

As having services with multiple target group is relatively new feature, Documentation should be updated to reflect that SLR is only way for multiple target groups, and custom role should be only used with single target group only.

[vs-jawad]

@rohanmangal if that's just the way it works, that's less than ideal but fine. It's just odd to me that AWS would prevent people from being explicit with the error that @nataizya-s put above since that error also appears if you try to specify the default role of AWSServiceRoleForECS as documented in https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using-service-linked-roles.html. Yes, at the end of the day it all ends up configured the same way, it is just a bad practice to bomb out if someone is explicit instead of relying on a default.

[wbingli]

SLR is preferred way to use as it provides better service role management for both ECS user and ECS itself. e.g. ECS won't be able to manage customer resources if customize service role is deleted or misconfigured.

ECS is enforcing this requirement for new features. For backward compatibility, customized service role is still supported for single target group, but suggest to remove the customized service role and default to use SLR.

[vs-jawad]

I completely understand that SLR is required and why it is required from those docs, that is not the issue. The question of this issue is why ECS does not allow users to be explicit and specify that they want to use the SLR and instead forces users to depend on the default behavior working as they expect since that is not a good practice for users to follow.

[wbingli]

@vs-jawad Good question, if I understand correct, you expect aws ecs create-service --role AWSServiceRoleForECS should work as it's specifying the SLR.

[vs-jawad]

Yes, that is correct. Right now, trying to create a service specifying that role fails with the error message @nataizya-s (an AWS support agent) documented above. At a minimum, there should be a better error message for that scenario. The preferred outcome however would be that the call does not fail when you are explicit and specify the SLR.

[zbintliff]

Same issue. Running two target groups with an ECS services. Neither task is running awsvpc networking. We have repeatedly been burned by ECS (and worse by CFN)'s default behavior. Even though we are specifying the default "AWSServiceRoleForECS" with the deployment we don not want to remove it and rely on the account default.