CUR from master payer for all child accounts or CUR from EVERY account

[gitcdb]

Describe the bug

I've followed the steps outlined here: https://docs.aws.amazon.com/solutions/latest/workload-discovery-on-aws/set-up-the-cost-feature.html but the costs found in Workload Discovery only reflect costs in the account where Workload Discovery was deployed. I have deployed the prescribed CUR and s3 replication from Control Tower org master (also one of our master payer accounts) to the WD deployment account and indeed the objects have been replicated successfully for the CUR objects bucket, but zero costs are included beyond the deployment account.

To Reproduce Steps to reproduce the behavior:

1. follow instructions outlined here: https://docs.aws.amazon.com/solutions/latest/workload-discovery-on-aws/set-up-the-cost-feature.html
2. navigate to costs section of workload discovery (or load costs for a diagram)
3. Behold! No costs beyond those associated with the WD deployment account

Expected behavior Costs for all accounts similar to how CUDOS/CID reports work

Additional context

I am curious as to the differing prefixes suggested for deployment account for external accounts. Anything related to this or is it designed to work with the two separate prefixes?

Do I instead need to set up CUR in every one of our accounts? We have like 50 accounts presently and it'll expand well beyond that with out intended work this year. I'd rather avoid having to deploy the CUR to each account if I can avoid it. Have I instead missed something and it's a PEBKAC issue?

[svozza]

I am curious as to the differing prefixes suggested for deployment account for external accounts. Anything related to this or is it designed to work with the two separate prefixes?

This is a bug in the documentation, it should be aws-perspective for both. We will be fixing the docs it shortly. My guess is that's why you're not seeing the cost data from the CUR being replicated as the Glue crawler will be looking for the CUR in a folder with the aws-perspective prefix. Rather than wait for the next report to drop after changing the prefix, you can test it by going into the WD cost report bucket and manually move the contents of the workload-discovery folder to the aws-perspective folder.

[gitcdb]

Ah indeed, thanks @svozza! Now oddly enough the costs are kind of off, but it seems like that might be region based. I've tried importing the other two main regions we're in, but now it's basically un-discovered everything it previously had discovered from the primary region. It's been a bit, but I'll let it do its thing for a while.

In hindsight I suspect I should have let it complete the second region before adding the third.

[svozza]

When you say undiscovered, do you mean that resources from regions that were there are no longer present? If so, have a look inside the ECS logs for the task, there might be some info there. There are steps here (ignore the section about lambda, we only care about ECS here): https://aws-solutions.github.io/workload-discovery-on-aws/workload-discovery-on-aws/2.0/debugging-the-discovery-component.html.

[gitcdb]

discovery_errors.csv

ECS filtered for errors attached. Also, yes, there were 50,000+ resources that went to 0. When I looked at the accounts section, clicking on an account and seeing the regions associated with them as being Not Discovered. They're now starting to be discovered but I thought I'd attach the log for you in case there's any beneficial information. It does look like items will be discovered fully as the straggling accounts and regions are fully incorporated.