Make resource names unique to deploy CFN stack multiple times

[AndreasSko]

Our team is currently working on deploying the Cloud Intelligence Dashboards. During development, we typically create a temporary acceptance environment for each PR by adding a prefix to all resource names to ensure uniqueness.

While working with the CID CFN template, we noticed that this approach doesn’t seem to be supported, limiting us to deploying the dashboard only once per AWS account. We were wondering if it would be feasible to extend the template to support adding a prefix/suffix to all resource names (I noticed there is a Suffix parameter, but it says it shouldn’t be used 😄).

We’d be happy to contribute to the project if you think this change would be beneficial 😊

[yprikhodko]

Hi @AndreasSko,

Such change would be beneficial, however it will bring significant additional complexity to current dashboard update process . We're tracking this feature internally, but it's not on our roadmap.
Could you please share more details about your use case? Which exactly changes you're running through the acceptance testing?

[AndreasSko]

Thanks for your quick reply, @yprikhodko! 😊
The CID CFN stack is just one part of a bigger infrastructure, which we are deploying using Terraform. We have two use cases where we would need this feature and one more "nice-to-have"-reason:

Lab testing

We have one Lab account that every developer has access to. Right now only one person in our team can deploy the CID at the same time. We are currently testing different permission models, extensions, etc to the dashboards, which we can't test simultaneously: We always need to make sure first to ask the other person to remove "their" CFN stack before another one can deploy and test his changes.

Acceptance pipelines

When creating a new PR, we are deploying the whole infrastructure in an acceptance AWS account, which is shared similarly to the Lab account. This is useful for catching issues (like missing permissions, etc.) early on, before attempting to deploy to production. Right now we have to hide the CID CFN stack behind a "feature flag" in the acceptance environment, as we can't deploy multiple stacks of it simultaneously. For us, this limits our ability to catch errors early, leading to lower trust in a "green" pipeline, because we didn't test the whole deployment process.

Resource naming convention

Finally, in our organization, we try to follow a naming standard where each resource has the repo name as a prefix (like <repo-name>-<environment>-<name-of-the-resource>). This helps us with IAM permissions and in general, quickly figuring out where a specific resource was deployed from. It's not a show-stopper for us, but it would definitely be nice if we could apply the same pattern when deploying the dashboards.

Hope this helps to better understand our use case 😊