Autoscaling for Fargate services does not support new ECS ARN format

[pgarbe]

Auto scaling of a Fargate service fails, if the new ECS ARN format has already been activated.

The following snippet creates an auto scaling Fargate service:

export class AwsSummitDemoStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const vpc = new ec2.VpcNetwork(this, 'MyVpc', { maxAZs: 3 });

    const cluster = new ecs.Cluster(this, 'MyCluster', {
      vpc: vpc
    });

    const demo = new ecs.LoadBalancedFargateService(this, 'MyFargateService', {
      cluster: cluster, 
      image: ecs.ContainerImage.fromDockerHub('amazon/amazon-ecs-sample'),
    });

    const scaling = demo.service.autoScaleTaskCount({ maxCapacity: 10 });
    scaling.scaleOnCpuUtilization('CpuScaling', {
      targetUtilizationPercent: 50
    });
  }
}

When the account (or user) already opted in to the new ECS ARN format, the Fargate service can be created, but autoscaling fails, as it generates the wrong service name:

MyFargateService/Service/TaskCount/Target (MyFargateServiceTaskCountTargetFD19DCA5) ECS service doesn't exist: service/AwsSummitDemoStack-MyCluster4C1BA579-UUFVS0WJMFMG/AwsSummitDemoStack-MyCluster4C1BA579-UUFVS0WJMFMG (Service: AWSApplicationAutoScaling; Status Code: 400; Error Code: ValidationException; Request ID: ...)

[matthewtapper]

Hi, we turned on the new ECS ARN format today and it has broken a number of our stacks. It would be great to see this fixed.

[SoManyHs]

Hi @pgarbe,

Apologies about the delay in getting back to you. Was the error generated when you ran cdk deploy? I assume you opted into the new ECS ARN format as root user?

[matthewtapper]

Hi @SoManyHs, after a bit of investigation this is actually a CloudFormation bug https://forums.aws.amazon.com/thread.jspa?threadID=294793 I’m not sure there is a work around that will work for both formats? Given the CloudFormation issue has been open for a while some extra voices may encourage a faster fix.

[SoManyHs]

@matthewtapper Thanks for that info. I am still curious about the steps you took. I was unable to reproduce this bug using the stack in our integ test, so curious what I'm missing.

[matthewtapper]

@SoManyHs we enabled the new ECS ARN format in order to add some cost allocation tags to ecs. This was done as follows:

aws ecs put-account-setting-default --name serviceLongArnFormat --value enabled
aws ecs put-account-setting-default --name taskLongArnFormat --value enabled
aws ecs put-account-setting-default --name containerInstanceLongArnFormat --value enabled

With the above setting enabled valid CloudFormation is generated by cdk however the below portion of the stack fails as the Fn::GetAtt returns a cluster name as apposed to the service name

Fn::Join:
          - ""
          - - service/notifications-cluster/
            - Fn::GetAtt:
                - notificationsservicewebService8520C0F2
                - Name

[PaulMaddox]

+1. I've also seen this consistently since enabling the new ARN format. I'm pretty sure that integ test will start failing as soon as the new format is enabled on the CDK integ account.