AWS hands Identity Center assignment reporting to a sample solution you run yourself

The per-Region scoping is the part worth watching closely. The post scopes one of its four questions to assignments "across organization and AWS Regions" ^[5], so the discovery cannot be one organization-wide list call; it repeats per Region, under whatever identity you give it, and a Region left out of the run's scope comes back as nothing rather than as an error. Before any row exists, three levels have to be resolved in order: the Identity Center instances in the organization, the AWS applications associated with each instance, and the user and group assignments on each application ^[3].

The output shape decides what you can ask afterwards. AWS says results are stored in a queryable format and that the solution generates CSV files for downstream analysis or reporting ^[4]. That is a snapshot of entitlements as of the run. The continuous part of the title is the schedule, not the freshness of any individual row.

The second question strains against the artifact. AWS lists "who last accessed a specific AWS application and when" among the questions the solution helps answer ^[5], but an assignment inventory records who may access, not who did. The post's own description of the flow shows the distance: users authenticate into Identity Center, are authorized to AWS managed applications, and are then authorized to the associated AWS service and resources, which may have their own IAM principals ^[12]. For the identity trail itself, AWS points to trusted identity propagation, described as giving an end-to-end trail of the identity to the downstream service ^[11]. Two of the four questions ask which users and groups are assigned to which applications, differing mainly in whether Regions are named ^[15], so the list is shorter than the bullet count suggests.

The planning half of the post costs staff time rather than compute. It is also the better half. Four areas are named: who can provision managed AWS applications, who manages user and group assignments, how authentication flows from the IdP to AWS resources, and how IdP identities map to AWS resource access ^[6]. The recommended pattern is an IaC pipeline managing the provisioning of the integrated AWS resource, with a separate workflow handling requests to manage user and group membership for the managed application ^[10]. For the provisioning gate, AWS lists identity policies, service control policies, resource control policies, and IaC policy evaluation tools such as Open Policy Agent or Checkov ^[9]. That separation is the actual governance content: creating an application and granting a human access to it are different approvals, and they should not share a reviewer by accident.

For the number and the code to transfer, a few things have to be true in your environment. You need an organization instance of Identity Center with delegated administration enabled, which AWS calls a security best practice ^[8]. You need the reporting identity to reach every Region you claim coverage for. And you need someone named to answer the assignment-approval question: the sample reports assignments, but the decision on those assignments is left to your team ^[3]. AWS also recommends convening security, governance, application, and business stakeholders before the implementation ^[7], which is the honest way of saying the deployment is the cheap step. The reason given for all of it is scale: AWS says visibility into who has access to which applications, and consistent enforcement across accounts and Regions, gets harder as the organization grows ^[2].