Ability to set custom name for CUR bucket

[rclemente-mrge]

Issue #, if available:

Description of changes:

Ability to use a different bucket name instead of the default format

[iakov-aws]

@sean-nixon can you check this please?

Here we adjust source bucket but not replication one?

[rclemente-mrge]

@iakov-aws
Adding some context.

Currently our company already has CUR in a bucket and we want to import that into this module for creating the Cudos board

But we don't have a replication bucket yet.

[iakov-aws]

thanks for the context

We do not fully support this usecase and do not recommend using existing CUR.
https://catalog.workshops.aws/awscid/en-US/faqs#can-i-use-an-existing-cost-and-usage-report-(cur)-instead-of-the-one-created-by-cid

The main reason being that different customers can use different settings of CUR creating tens of combinations that we do not support.

Many use 3rd party tools that have their own requirements for CUR format and content and 9 out 10 are incompatible with others (and between tools as well).

Also there is a very special prefix convention allowing CID to collect data across multiple AWS Organization and customer's cur surely do not have this.

So the best way is to create a new CUR and backfill data for 3 years.

[iakov-aws]

Typically the cost of s3 is low even for huge customers and having many CURs is not any issue.

[iakov-aws]

One valid reason for this change would be to use customer's specific naming convention.

[CorinneVerheyde]

I would be interessed too by the ability to use/specify an existing bucket.

1. We are working on an automatic deployment of the whole CID solution. During the testing process, we have to deploy/destroy several time and it's a shame to have to empty the cur bucket each time to destroy it, then to recreate it 5 minutes later.

2. Use customer's specific naming convention, and be able to use different name for source or destination cur. For this, we would need both source bucket and replication one to be customized.

[iakov-aws]

I see. This is an interesting use-case. Totally see value of it.

Currently in CUR/DataExports we operate with bucket replication mechanisms that require replication rules and bucket policies/

• In destination account Bucket policies theoretically can be installed separately and this will only will work if bucket has no policy at all.
• In source account Bucket replication in source cannot be done outside of bucket definition at all.

We can try to implement this for destination account only.
Today the easiest would be to sync the data to a backup bucket and to sync it back once the stack is updated.