Discover BCM Data Exports CUR 2.0 buckets for IAM policy

README.md

@@ -82,6 +82,8 @@ The AWS account that contains your Cost and Usage Report (CUR) and is the payer
 
 **Important**: CloudZero requires an HOURLY Cost and Usage Report. Daily reports are not supported.
 
+**Deploy payer accounts in `us-east-1`**: when the payer account has no existing CUR, this template creates one for you using the native `AWS::CUR::ReportDefinition` resource, which AWS only supports in `us-east-1` (the single region the Cost and Usage Report API runs in). Launch the stack in `us-east-1` on a payer account. If it is launched elsewhere on a payer account that needs a new CUR, the cross-account role is still created but the CUR is not — the stack's `MasterPayerCurStatus` output reports the skip. Payer accounts that already have a CUR are unaffected by region.
+
 If the payer account has more than one CUR configured, the auto-generated IAM policy grants `s3:Get*`/`s3:List*` on every CUR bucket discovered in the account, not only the one CloudZero ingests as primary. This keeps the role aligned with the customer's actual CUR footprint and avoids surprises if the primary CUR is later swapped.
 
 #### Resource Owner Account

docs/releases/1.0.101.md

@@ -0,0 +1,24 @@
+# [1.0.101](https://github.com/Cloudzero/provision-account/compare/1.0.100...1.0.101) (2026-06-15)
+
+> Discover BCM Data Exports (CUR 2.0) S3 buckets and add them to the master-payer IAM policy
+
+## New Features
+
+### CUR 2.0 Bucket Discovery
+* **Discovery now calls `bcm-data-exports:ListExports` + `bcm-data-exports:GetExport`** — AWS is migrating customers from the classic CUR to BCM Data Exports. `list_exports` only returns export ARNs, so each export is resolved with `get_export` to read its `DestinationConfigurations.S3Destination.S3Bucket`.
+* **Type-agnostic bucket access, `COST_AND_USAGE_REPORT`-only ingest** — CloudZero only ingests exports of type `COST_AND_USAGE_REPORT` (CUR 2.0), but the IAM policy is intentionally granted access to the destination bucket of *every* export regardless of type. This mirrors the existing schema-agnostic behavior for classic CUR: a bucket referenced by any export is legitimate billing storage, and the customer can switch export configurations without redeploying this stack.
+* **CUR 2.0 buckets are folded into `MasterPayerBillingBucketArns`** — `get_all_local_cur_bucket_names` now unions the classic CUR report buckets with the BCM Data Exports destination buckets, keeping only those owned locally. The master-payer role gains `s3:Get*`/`s3:List*` on the export buckets the same way it already covers classic CUR buckets.
+* **Graceful degradation** — if the account cannot call BCM Data Exports (e.g. `AccessDeniedException`), discovery logs a warning and falls back to the classic CUR buckets rather than failing.
+
+### Template
+* **`DiscoveryFunction` execution role gains `bcm-data-exports:ListExports` and `bcm-data-exports:GetExport`** — required for the discovery Lambda to enumerate CUR 2.0 export destinations. (The cross-account role policies already grant `bcm-data-exports:Get*/List*`.)
+
+## Files Modified
+
+- `services/discovery/src/app.py`
+- `services/discovery/template.yaml`
+- `services/discovery/tests/unit/test_app.py`
+
+## Deployment Notes
+
+* No customer action required. On the next stack update, the discovery Lambda begins enumerating BCM Data Exports destinations and the master-payer IAM policy's billing-bucket statement gains `Resource:` entries for any local CUR 2.0 / FOCUS export buckets.

docs/releases/1.0.102.md

@@ -0,0 +1,68 @@
+# [1.0.102](https://github.com/Cloudzero/provision-account/compare/1.0.101...1.0.102) (2026-06-16)
+
+> Flatten the connected-account stack to a single nested stack, move CUR creation to native CloudFormation, and remove the deprecated audit / cloudtrail-owner account types
+
+## Breaking / Behavioral Changes
+
+### Master-payer CUR creation now requires `us-east-1`
+* The Cost and Usage Report for a payer account is now created with the native
+  **`AWS::CUR::ReportDefinition`** resource (plus `AWS::S3::Bucket` + `AWS::S3::BucketPolicy`),
+  replacing the inline `Custom::CostAndUsageReport` Lambda. AWS only supports this resource in
+  `us-east-1`, so **payer accounts that need a new CUR must be onboarded from `us-east-1`**.
+  Launched elsewhere on such an account, the cross-account role is still created but the CUR is
+  skipped; the stack's new `MasterPayerCurStatus` output reports why. Payer accounts that
+  already have a CUR are unaffected by region. The CUR bucket uses `DeletionPolicy: Retain`, so
+  billing data is never deleted on stack removal (matching the prior Lambda behavior).
+
+### Audit and CloudTrail-owner account types removed
+* The deprecated **audit** and **cloudtrail-owner** roles/features are gone: their templates,
+  the discovery Lambda's CloudTrail/audit detection, and the `cloudtrail:DescribeTrails`
+  discovery permission have all been removed.
+* The reactor notification payload contract is **unchanged** — the `links.audit`,
+  `links.cloudtrail_owner`, and `discovery.*cloudtrail*` / `is_audit_account` /
+  `is_cloudtrail_owner_account` fields remain in the payload and are now always `null` / `false`.
+
+## New Features
+
+### Single nested stack (was 6)
+* `connected_account.yaml` now **inlines** the Discovery and Notification Lambdas (as native
+  `AWS::Lambda::Function` + `AWS::IAM::Role`) and provisions account resources through one
+  nested `AccountResources` stack (`services/account_type/account_resources.yaml`, merging the
+  former resource_owner + master_payer templates). The discovery, notification, resource_owner,
+  cloudtrail_owner, audit, and master_payer nested templates are no longer used as nested stacks.
+* The notification Lambda no longer scrapes sibling CloudFormation stack outputs at runtime; it
+  receives every value it needs as direct resource properties, and its execution role drops
+  `AWSCloudFormationReadOnlyAccess`.
+
+### `Stage` parameter
+* Both `connected_account.yaml` and `connected_account_dev.yaml` now carry a `Stage` parameter
+  (`prod` / `dev`) selecting the `CallbackConfiguration` mapping, so the two files differ only
+  by the `Stage` default instead of diverging across every resource.
+
+### Code clarity
+* The discovery and notification Lambda handlers were rewritten from the `toolz`-pipeline /
+  decorator-coeffect style into straightforward, auditable procedural flows.
+
+## Files Modified
+
+- `services/connected_account.yaml`, `services/connected_account_dev.yaml`
+- `services/account_type/account_resources.yaml` (new; replaces the four account-type templates)
+- `services/discovery/src/app.py`, `services/discovery/template.yaml`, discovery tests
+- `services/notification/src/app.py`, notification tests
+- `README.md`
+
+## Files Removed
+
+- `services/account_type/resource_owner.yaml`
+- `services/account_type/master_payer.yaml`
+- `services/account_type/audit.yaml`
+- `services/account_type/cloudtrail_owner.yaml`
+
+## Deployment Notes
+
+* On the next stack update, existing customer stacks delete the old per-account-type nested
+  stacks and create the single `AccountResources` stack; the cross-account IAM roles are
+  recreated (trust is by ExternalId and role path/names are stable, so CloudZero access
+  continues). Validate on a stack *update* in a test account, including the master-payer paths.
+* **Follow-up:** `policies/` and `terraform/` still carry audit / cloudtrail-owner definitions to
+  clean up in a separate change.