Deploying an aws-ecs-patterns to an AWS tenant that is not opted into the ECS Managed Tags feature will fail. This is can be resolved by adding the feature to set the enableECSManagedTags property to false through the LoadBalancedServiceBaseProps.
load-balanced-fargate-service.js
, add enableECSManagedTags: false
to the "Service" props and the stack will deploy.The new ARN and resource ID format must be enabled to work with ECS managed tags. Opt in to the new format and try again. (Service: AmazonECS; Status Code: 400; Error Code: InvalidParameterException; Request ID: 91d4b3b3-8529-40b1-9b55-16f820f23743)
new BaseService (/projects/fargate-pwa-starter-kit/server/node_modules/@aws-cdk/aws-ecs/lib/base/base-service.js:39:25)
\_ new FargateService (/projects/fargate-pwa-starter-kit/server/node_modules/@aws-cdk/aws-ecs/lib/fargate/fargate-service.js:30:9)
\_ new LoadBalancedFargateService (/projects/fargate-pwa-starter-kit/server/node_modules/@aws-cdk/aws-ecs-patterns/lib/fargate/load-balanced-fargate-service.js:30:24)
\_ new BonjourFargate (/projects/fargate-pwa-starter-kit/server/dist/index.js:31:32)
\_ Object.<anonymous> (/projects/fargate-pwa-starter-kit/server/dist/index.js:52:1)
\_ Module._compile (module.js:653:30)
\_ Object.Module._extensions..js (module.js:664:10)
\_ Module.load (module.js:566:32)
\_ tryModuleLoad (module.js:506:12)
\_ Function.Module._load (module.js:498:3)
\_ Function.Module.runMain (module.js:694:10)
\_ startup (bootstrap_node.js:204:16)
\_ bootstrap_node.js:625:3
Getting the below error since I have upgraded to 1.6 and deploying my fargate service :
The new ARN and resource ID format must be enabled to work with ECS managed tags. Opt in to the new format and try again. (Service: AmazonECS; Status Code: 400; Error Code: InvalidParameterException; Request ID: ae8a047e-ab7f-43b9-82b1-23dfa7478636)
new BaseService (/Users/akshay.a.malik/Documents/EVA-NEW_NEW_NEW/cloudformation/node_modules/@aws-cdk/aws-ecs/lib/base/base-service.ts:185:21)
_ new FargateService (/Users/akshay.a.malik/Documents/EVA-NEW_NEW_NEW/cloudformation/node_modules/@aws-cdk/aws-ecs/lib/fargate/fargate-service.ts:93:5)
You can either disable tag propagation on the service using the option enableECSManagedTags: false
or as a better solution opt in to the new ARN format by following the instructions here: https://aws.amazon.com/blogs/compute/migrating-your-amazon-ecs-deployment-to-the-new-arn-and-resource-id-format-2/
Note that all resources you create will automatically get the new ARN format starting Jan 1, 2020 (we first made the announcement about this ECS change and the migration path back in Nov 2018). So if you are still on the old ARN format and getting this error message I would recommend starting the migration early by opting in to the new format. Not only will it solve this error but it will also make sure you are prepared for the new ARN formats before the Jan 1, 2020 deadline.
@nathanpeck as far as I understand it, by default, the roles associated with the resources created are all dynamically generated, and as a result I'd have to create a specific role, manually opt-in via the UI, reference it via fromArn
or the like, and add the necessary permissions that the CDK would normally automatically add to the generated role, correct?
Is there a way to do this via the CDK itself, or does it require the UI?
opting in manually from UI does not resolve the problem when using CDK 1.6.1
You need to opt in using the same role that you are using to deploy with
CDK, or opt in using the root login for the account to opt in everyone
On Sun, Sep 1, 2019 at 9:35 AM Tomas Sykora notifications@github.com
wrote:
opting in manually from UI does not resolve the problem when using CDK
1.6.1—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-cdk/issues/3844?email_source=notifications&email_token=AA2VN6VFEOEUR2PWGWV24RDQHPAJLA5CNFSM4IRUYHW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5UCQMY#issuecomment-526919731,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA2VN6VS6KX2CZEIQILW4JDQHPAJLANCNFSM4IRUYHWQ
.
Opting in by default (at root level) for the lazy
#!/bin/bash
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
aws ecs put-account-setting-default --name awsvpcTrunking --value enabled
aws ecs put-account-setting-default --name containerInsights --value enabled
If you are using CodePipeline, you have to attach a managed policy to your pipeline object as well as opting in.
devPipeline.role.addManagedPolicy(iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonEC2ContainerServiceforEC2Role'))
If that doesn't work, and this is a dev env, try admin
devPipeline.role.addManagedPolicy(iam.ManagedPolicy.fromAwsManagedPolicyName('AdministratorAccess'))
Reference: ECS: Migrating to new ARN
I'm able to successfully deploy to a non-opted-in account on 1.7.0 thanks to #3887.
Closing the issue as it's resolved. Feel free to reopen the issue if you have any questions.
Most helpful comment
Opting in by default (at root level) for the lazy
If you are using CodePipeline, you have to attach a managed policy to your pipeline object as well as opting in.
If that doesn't work, and this is a dev env, try admin
Reference: ECS: Migrating to new ARN