CFN Template cid-cfn.yml doesn't account for ResourcePrefix

[pauldtill]

The aggregation template allows the customer to specify the parameter ResourcePrefix - which we used to avoid some collisions with other deployments.

Unfortunately the main dashboards template doesn't account for this in the bucket name (at least - maybe other places). Here for example the bucket is hard coded with a cid- prefix -

                Resource:
                  - !Sub arn:${AWS::Partition}:s3:::cid-${AWS::AccountId}-data-exports # prefix for data-exports hardcoded here

For the old 1.0 configuration the bucket name could be passed in as a parameter to handle this difference in naming, but with the above this isn't possible without directly changing the template.

Other resources in the initial aggregator template also use this resource prefix for naming e.g. CIDDatabase (AWS::Glue::Database) so I'm also concerned they won't be picked up correctly if the 2nd template isn't aware of the prefix used.

Apologies if I missed something.

[iakov-aws]

Hi @pauldtill
I confirm that ResourcePrefix is not fully functional. This is mainly linked to the fact that the python code does not support deployment of multiple environments (dashboards and datasets prefixes, neither athena tables and databases) so this parameter currently cannot be used as of today.

Normally you can specify a bucket prefix in dataexports stack, it will create a policy DataExportsReadAccess That then will be attached runtime by the lambda of dashboard creation or you can attach this policy to the QucikSight Role manually. The hardcoded value you point to are here only for backward compatibility.

[pauldtill]

@iakov-aws - this is unfortunate, we already have the source accounts (40+) setup using this resource prefix and replicating their data centrally, also using resource prefix AND we have 3 years worth of data backfilled. We also already have the dashboards deployed but using CUR 1.0, and need to update them to 2.0 - the prefix worked fine with the 1.0 setup.

Is there no way I can get the solution to work now with what has already been deployed i.e. do I need to start again from scratch ?

Perhaps this parameter should be completely removed, or at least moved to the "do not use" section to make this limitation clear?

[iakov-aws]

Hello Paul,

Can you contact your technical account manager from AWS to set up a call with one of cid team members?