search

aws-cloudformation / aws-cloudformation-resource-providers-stepfunctions

The CloudFormation Resource Provider Package For AWS Step Functions
https://aws.amazon.com/step-functions/
Apache License 2.0
6 stars 4 forks source link

Why doesn't it prepend StackId- to generated resource physical IDs? #26

Closed SPGremlin closed 1 year ago

SPGremlin commented 2 years ago

Lambda Function cloudformation deploys functions StackID-FunctionName-RandomID, but StateMachine cloudformation deploys only as StateMachineName-RandomID. This makes it less convenient when doing MultiStack within the same AWS account. Why is that, is this intenal (by design)?

wong-a commented 1 year ago

This is by design and was implemented according to recommendations by CloudFormation at the time we released these resources. I don't believe <stackId>-<logicalId>-<randomID> is a standard convention for all resources.

Can you elaborate your use case and why the StateMachine generated name convention affects it?

SPGremlin commented 1 year ago

The use-case is developer/admin convenience when working with multistack deployments, and i.e. you have dev, qa and prod stacks under one account/subscription (or at least personal branch dev stacks).

The default naming format lamda sticks to is convenient to filter (or sort) resources by name (dev-myfunc…) while the default stepfunction naming (without a stackId) made it harder to work with. Yes, the randomID is still there so resources are unique - just harder to navigate and find in the console.

That’s as much as I remember. It was over a year since I posted the issue, and have not worked with cloudformation or sam since then.

On Thu, Mar 16, 2023 at 20:49 Adam Wong @.***> wrote:

This is by design and was implemented according to recommendations by CloudFormation at the time we released these resources. I don't believe

-- is a standard convention for all resources. Can you elaborate your use case and why the StateMachine generated name convention affects it? — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you authored the thread.Message ID: -- ------- Best regards, Dmitriy
wong-a commented 1 year ago

Thanks for the quick follow up. That makes more sense to me now. I will close this issue as we don't plan to change our resource naming. Some alternatives to help would be using resource tags for the stack or using the Name property to construct your own name with the stack name and a unique suffix from stack parameters.

There may be organization constraints for your particular setup, but the best practice is to use separate AWS accounts. It is best to have hard isolation between dev and prod environments by keeping their resources in their own accounts.