Improve experience for renaming L1s

Using a L2 construct (I think that’s how you refer to them) to define a resource doesn’t allow me to explicitly define the resource’s logical name.

new Role(stack, "FunctionRole", {
  assumedBy: new ServicePrincipal('lambda.amazonaws.com')
});

==>

      FunctionRole111A5701:
        Type: 'AWS::IAM::Role'
        Properties:
            AssumeRolePolicyDocument:
                Statement:
                    -
                        Action: 'sts:AssumeRole'
                        Effect: Allow
                        Principal:
                            Service: lambda.amazonaws.com
                Version: '2012-10-17'

Reasons that I’d like to be able to set the logical name precisely:

• if I need to look at my template to debug anything, or if I have workflows that involve inspecting templates in API responses or the console UI, it can be easier to deal with if I can explicitly set my resource’s logical name

• if I have to resort to L1 constructs from ‘@aws-cdk/resources’, the pattern is changed – while the name argument looks the same, I end up without a suffixed logical resource name

new logs.LogGroupResource(stack, 'Logs', {
  logGroupName: new FnSub('/aws/lambda/${AWS::StackName}') as any,
  retentionInDays: 14
});

==>

    Logs:
        Type: 'AWS::Logs::LogGroup'
        Properties:
            LogGroupName:
                'Fn::Sub': '/aws/lambda/${AWS::StackName}'
            RetentionInDays: 14

[eladb]

Obviously that’s a good point.

In the meantime, you could synthesize first to determine the generated ID and then use “rename” but that’s a very broken experience.

Let us give this a bit of thought. Reopening for now.

[eladb]

Contrary to CloudFormation, which is a flat list of resources, CDK stacks form a tree. We need a way to assign unique and stable Logical IDs that won’t cause conflicts.

From the concepts.html#logical-ids documentation topic (#209 includes some improvements):

---

When you synthesize a stack into an AWS CloudFormation template, the CDK assigns a logical ID, which must be unique within the template, to each resource in the stack.

Each resource in the construct tree has a unique path that represents its location within the tree. The logical ID of a resource is formed by concatenating the names of all of the constructs in the resource’s path, and appending an eight-character MD5 hash of the path. This final component is necessary since AWS CloudFormation logical IDs cannot include the delimiting slash character (/), so simply concatenating the component values does not work. For example, concatenating the components of the path /a/b/c produces abc, which is the same as concatenating the components of the path /ab/c.

Since logical IDs can only use alphanumeric characters and also restricted in length, we are unable to simply use a delimited path as the logical ID. Instead IDs are allocated by concatenating a human-friendly rendition from the path (concatenation, de-duplicate, trim) with a short MD5 hash of the delimited path:

VPCPrivateSubnet2RouteTable0A19E10E
<-----------human---------><-hash->

Low-level CloudFormation Resources that are direct children of the Stack class use their name as their logical ID without modification. This makes it easier to port existing templates into a CDK app.

This scheme ensures that:

• Logical IDs have a human-friendly portion: this is useful when interacting directly with the synthesized AWS CloudFormation template during development and deployment.
• Logical IDs are unique within the stack: this is ensured by the MD5 component, which is based on the absolute path to the resource, which is unique within a stack.
• Logical IDs remain unchanged across updates: this is true as long as their location within the construct tree doesn’t change. See Creating a Runtime Value for information on how to retain logical IDs despite structural changes in your stack.

The AWS CDK applies some heuristics to improve the human-friendliness of the prefix:

• If a path component is Resource, it is omitted. This postfix does not normally contribute any additional useful information to the ID.
• If two subsequent names in the path are the same, only one is retained.
• If the prefix exceeds 240 characters, it is trimmed to 240 characters. This ensures that the total length of the logical ID does not exceed the 255 character AWS CloudFormation limit for logical IDs.

Renaming Logical IDs

The :py:meth:aws-cdk.Stack.renameLogical method can be used to explicitly assign logical IDs to certain resources, given either their full path or

class MyStack extends Stack {
      constructor(parent: App, name: string, props: StackProps) {
        super(parent, name);

        // note that `renameLogical` must be called /before/ defining the construct.
        // a good practice would be to always put these at the top of your stack initializer.
        this.renameLogical('MyTableCD117FA1', 'MyTable');
        this.renameLogical('MyQueueAB4432A3', 'MyAwesomeQueue');
        
        new Table(this, 'MyTable');
        new Queue(this, 'MyQueue');
      }
 }