AWS CDK generated resource identifiers are horrible and not readable. Any way to fix this?

Question

Anyone, that has used AWS CDK suffers from horrible resource identifiers.

Examples of Stacks/Nested Stacks names:

Or examples of resource names:

These identifiers are horrible to read. Is there any work-around to override these identifiers?

I have tried to set ids / names / identifiers / alies of the resources. However it seems that cdk or cloudformation itself is generating these strings.

Thank you for suggestions!

score 5 · Answer 1 · answered Jan 16 '20 at 17:10

All of resources(or at least for most that I know) could be named manually.

For AWS::EC2::SecurityGroup that would be Properties -> GroupName

AWS::CloudWatch::Alarm - Properties -> AlarmName

AWS::Lambda::Function - Properties -> FunctionName etc.

But for some of them that would lead to consequences - you won't be able to update some of them, because they might need recreation (and the name is already occupied). So in general it's not a good practice. And obviously you won't be able to create a full env duplicate not changing some parameter for the generated name like this:

FunctionName: !Sub '${InstanceName}-your-resourse-constant-name-${Environment}'

If you don't specify the naming it would create a name like this:

${stackName}-${resourceNameInCF}-${someHashCode}, but in your case it seems you have nested stacks and it becomes pretty unreadable, especially with long names because of the names chaining.

Thanks for the answer. However, it does not solve my problem. I am completely aware that you can control resource names like lambda functions, etc. However, as I now understand, AWS CDK has purposely implemented this awful naming scheme for their ids to avoid possible name clashing. — Laimonas Sutkus, Oct 12 '20 at 13:49
You should be carafull with specifing names. I do not about CDK but for CloudFromation it can be tricky due to unable recreate a resource if something you changed demands replacement. — Yakim, Jul 27 '21 at 08:40

Cristophs0n · Answer 2 · 2022-05-22T22:13:17.147

Yeah, this is a good question. There's two types of IDs here:

Logical ID
Physical ID

Typically the Physical ID can be specified as a property on the resources. For instance, if you are using the CDK, you can set the functionName property when creating your Lambda (as below).

The Logical ID is also added when creating the resource and as you mentioned, however, the Logical ID is derived from a combination of what you specify and where it is within your stack. So, for example, if you have a stack that uses constructs, then this ID will be prefixed with the construct's Logical ID as well... and it's definitely not very readable.

I'd be very careful changing these IDs, especially if you have already deployed the stack, but if you really want to override them then you could do something like this in the CDK (TypeScript):

import {
  CfnResource,
} from "@aws-cdk/core";
import {
  Function,
  Runtime,
  Code,
} from "@aws-cdk/aws-lambda";

const consumerLambda = new Function(this, 'LogicalIdOnResource', {
  runtime: Runtime.NODEJS_12_X,
  handler: 'index.handler',
  code: Code.fromAsset(path.join(__dirname, 'lambda-handler')),
  functionName: 'ds-di-kafka-consumer-lambda' // PhysicalIdOnResource
});

// Override Logical ID
(consumerLambda.node.defaultChild as CfnResource).overrideLogicalId(
  'Consumer'
);

Which looks like this on CloudFormation:

AWS CDK generated resource identifiers are horrible and not readable. Any way to fix this?

2 Answers2