Describe the feature

Currently we cannot hotswap an ECS task definition if it contains certain kind of tokens, raising an error like below:

Could not perform a hotswap deployment, because the CloudFormation template could not be resolved: We don't support attributes of the 'AWS::DynamoDB::GlobalTable' resource. This is a CDK limitation. Please report it at https://github.com/aws/aws-cdk/issues/new/choose

It makes ECS hotswap unusable for many cases, because we usually reference other AWS resources in a task definition e.g. as environment variables (name of a DynamoDB global table in the above case.) It would be great if we could hotswap a task definition also in those cases.

Use Case

Deploy ECS task definition instantly even when there are tokens in it.

Proposed Solution

Given that the configuration of environment variables won't change very often, it would be beneficial to specially support hotswap when changes don't include tokens (e.g. only container image tags are updated). In such cases, we can just copy the latest task definition and update the necessary fields to hotswap it.

1. Compare diff (synthesized template vs currently deployed template)
2. if the diff does not contain unsupported tokens, proceed to the hotswap
3. Get the latest task definition currently deployed
4. Update the fields from diff (we can do this easily as the diff does not contain tokens)
5. Create a new task definition
6. .... (After this, we can use the current implementation as-is)

Other Information

Currently some tokens are already supported for hotswap, including:

1. Ref functions, which will be resolved as physical resource ids
2. GetAtt functions for some resources and attributes (manually supported one by one, code)
3. several simple CFn functions (join, split, select, sub)
4. parameters like AWS::AccountId, Region, Partition, or UrlSuffix

One possible solution would be to support more resources manually (i.e. adding code to 2), but it needs huge and continuous effort to cover all the use cases. The proposed solution can solve many cases with a single PR.

Another consideration is that relying on a previously deployed task definition might lead to some problem in a rare case (e.g. someone may manually modify it), but it should not be a big problem as a user can easily fix it by deploying without hotswap once.

One example of currently unhotswappable change:

import { App, Stack, aws_ecs as ecs, aws_ec2 as ec2 } from 'aws-cdk-lib';

const app = new App();
const stack = new Stack(app, 'my-test-stack');

const vpc = new ec2.Vpc(stack, 'Vpc', { natGateways: 0 });

const cluster = new ecs.Cluster(stack, 'EcsCluster', { vpc });

const taskDefinition = new ecs.FargateTaskDefinition(stack, 'Task', {
  cpu: 256,
  memoryLimitMiB: 512,
});

taskDefinition.addContainer('EcsApp', {
  // change nginx:latest to nginx:stable
  image: ecs.ContainerImage.fromRegistry('nginx:latest'),
  environment: {
    VPC_ID: vpc.vpcCidrBlock,
  },
});

// Service
new ecs.FargateService(stack, 'Service', {
  cluster,
  taskDefinition,
  assignPublicIp: true,
});

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.77.0

Environment details (OS name and version, etc.)

macOS