Doubts regarding Innovation Sandbox solution by AWS

This is the source of truth → https://docs.aws.amazon.com/solutions/latest/innovation-sandbox-on-aws/solution-overview.html

My team has deployed the ISB and we are currently testing it to understand how it works in real scenarios and to identify any loopholes or caveats before providing it to the client. Before going deeper, this is the reference solution link: https://docs.aws.amazon.com/solutions/latest/innovation-sandbox-on-aws/solution-overview.html

Summary of the ISB solution The solution is designed to provide temporary, governed access to AWS accounts so users can experiment without needing their own AWS accounts. It focuses on controlled usage, cost governance, and lifecycle management of sandbox environments. There are 3 levels of access: Admin, Manager, and User.

Administrator has full control over the solution, including managing users, managers, and overall configuration of accounts and governance controls. Manager is responsible for approving or rejecting account lease requests and assigning sandbox accounts to users. User is the end consumer who requests access and uses the sandbox account within defined limits.

Blueprints can be created, which act as templates to standardize sandbox environments. These can include predefined configurations and governance controls such as SCPs, and are applied when provisioning accounts for lease.

Leased accounts are provided for a fixed duration and are governed by budget constraints.

Thresholds can be configured based on both budget and duration. Budget thresholds can trigger alerts or restrict account activity when nearing limits. Time-based thresholds control the lifecycle of the lease and can restrict access or end the lease when the duration expires.

At the end of the lease duration, the solution initiates cleanup of provisioned resources and the account is returned to the pool for reuse (it is not permanently deleted). Cost data is stored (for example in S3), but it is important to note that AWS billing data is not real-time and is delayed.

Currently, the major issue observed during testing is:

1. There is a delay in reflecting actual costs in AWS billing tools like Cost Explorer.
2. The final cost report generated at the end of a lease may not include the most recent usage (especially from the last few hours or last day). This is due to AWS billing data lag, not because the cost is lost. The cost will eventually appear in AWS billing, but it may not be attributed correctly to that specific lease or user in the ISB reporting.

How to address or think about this issue: since usage on the last day may not be reflected immediately, it creates a gap in cost attribution within the sandbox system. This does not mean the usage is free, but from the ISB reporting perspective, it may appear missing at the time of lease closure.

Example: User leases an account for 1 week with a budget of $50. Thresholds are configured to trigger near $49 and at lease expiration. User consumes approximately $5 per day for 6 days (total ~$30). On the last day, the user creates expensive resources.

Result: The ISB-generated report at lease end may only reflect the ~$30 usage. The remaining cost from the last day will appear later in AWS billing systems but will not be linked back to that lease in the ISB report.

This creates a cost gap where the actual spend and reported spend per lease will not match due to billing delays.