Event-Driven AWS Access Management with IAM Identity Centre

Introduction

Access management is easy to underestimate in AWS. When there are only a few accounts and a small team, creating permissions manually does not seem like a major problem. The situation changes once an organisation starts operating hundreds of AWS accounts and employs thousands of employees.

Different teams have different requirements. Developers may need access to development accounts; the security team may require read-only access across the organisation; and production access may require additional restrictions. Employees also move between teams, while new AWS accounts and applications are created regularly.

The difficult part is not creating one permission. It is keeping all these access relationships correct as the environment changes.

AWS IAM Identity Centre can provide the centralised access layer for this problem. When combined with AWS Organisations, EventBridge, Lambda, and Terraform, it can turn access provisioning into a controlled workflow rather than a collection of manual console operations.

The Problem with Managing IAM Users Account by Account

A traditional AWS setup may create IAM users directly inside individual accounts and attach policies to them. This works for smaller environments, but every additional account creates another place where access needs to be maintained.

Consider a developer who has access to three AWS accounts and then moves to the security team. The old permissions Set featured imageneed to be removed, and the new ones added. The administrator must know which accounts were involved and what access the user previously had.

Offboarding creates a similar problem. Missing one account during the removal process can leave an unnecessary permission behind.

Over time, manual changes can also result in configuration differences between accounts. Two accounts might initially follow the same access model, but one may eventually have an older policy due to a change made directly through the console.

A centralised identity model removes much of this account-by-account administration.

Using IAM Identity Centre for Workforce Access

IAM Identity Centre can integrate with an organisation’s existing identity provider, such as Microsoft Entra ID, Okta, or Active Directory. SCIM can synchronise users and groups, preventing AWS from becoming another independent identity directory.

The access model is based around users, groups, Permission Sets, and account assignments.

For example:

• Payments-Developers
• Payments-Developer
• Payments-Dev

The group represents the users, the Permission Set describes their AWS permissions, and the account assignment connects that access to the required AWS account.

IAM Identity Centre provisions the corresponding AWSReservedSSO role in the target account. When the employee signs in, the assigned permissions are available without requiring a separate IAM user in that account.

This creates a useful separation: the corporate identity provider manages employee identities and group memberships, while IAM Identity Centre handles AWS authorisation.

Turning Account Changes into Events

Centralised access does not completely remove administrative work. Someone still needs to create assignments when new accounts are created or access requirements change.

Consider a new AWS account created for the Payments application. An administrator could manually find the appropriate group and Permission Set and assign them to the account. That may be reasonable occasionally, but it becomes repetitive when accounts are created frequently.

An event-driven workflow can take over this step.

Amazon EventBridge can receive relevant AWS events and match them against configured rules. A matching event can invoke an AWS Lambda function.

Lambda can then inspect the event and validate the request before making any changes to access. For example, it could check:

• whether the account belongs to the expected organisational unit;
• whether the application identifier matches an approved mapping;
• whether the requested Permission Set is allowed for that environment; and
• whether the group is authorised to receive access.

Only after those checks pass would the function create the required account assignment through IAM Identity Centre.

The resulting flow is:

AWS Event → EventBridge → Lambda → Validation → IAM Identity Center → AWS Account

The validation step is important. A naming match should help identify a resource, but it should not, by itself, be considered authorisation.

Using Naming Conventions as Automation Inputs

Consistent naming makes the relationships easier for automation to discover.

For example:

Payments-Developers

Payments-PowerUser

Payments-Dev

The shared Payments identifier provides a starting point for finding related resources.

In a production implementation, the name can be combined with other information, such as the AWS account ID, organisational unit, tags, and an approved application mapping. This is more reliable than depending entirely on a manually maintained spreadsheet.

A spreadsheet might contain the correct relationship today, but somebody has to remember to update it whenever an account or team changes. With event-driven automation, the function can evaluate the current AWS metadata when processing the event.

Terraform and Lambda Need Clear Ownership

Terraform can manage the parts of IAM Identity Centre that should be declared as infrastructure resources. Groups, Permission Sets, policy attachments, and selected account assignments can be defined in code, stored in Git, reviewed through pull requests, and deployed through CI/CD.

There is one design decision to make before implementing the automation: who owns each account assignment?

If Terraform creates an assignment and Lambda later modifies the same resource, Terraform may detect the change as drift and attempt to restore its declared state during a later deployment.

A better model is to establish ownership boundaries. Terraform can manage the baseline configuration, while Lambda handles assignments that are intentionally created or changed dynamically as part of the event-driven workflow.

This distinction becomes particularly important once the solution is running continuously in a production environment.

Making the Automation Idempotent

Event-driven systems should also assume that an event may be processed more than once.

If Lambda receives the same event twice, the second execution should not produce an unexpected result. Before creating an assignment, the function can check whether the expected assignment already exists.

This makes the operation idempotent—repeating the same request produces the same final state.

Logging is equally important. Recording details such as the event ID, account ID, group, Permission Set, validation result, and API response gives the operations team enough information to investigate failures later.

A Practical Operating Model

Each component now has a defined responsibility.

The identity provider handles employee identities and group membership. IAM Identity Centre connects identities to AWS permissions. AWS Organisations provides an account and organisational context. Terraform manages configuration that has been deliberately defined as code. EventBridge detects relevant changes, while Lambda performs runtime validation and entitlement operations.

If an employee cannot access an account, the team can trace the path from identity synchronisation to group membership, Permission Set, account assignment, and, finally, the automation logs.

That is considerably easier to troubleshoot than searching for manually created IAM users across multiple accounts.

Conclusion

The value of an event-driven IAM Identity Centre architecture lies not simply in reducing manual console work. The larger benefit is that access changes can follow a defined process.

New accounts can trigger entitlement checks, Permission Sets can be maintained through Terraform, and identity changes can continue to originate from the organisation’s existing identity provider. Lambda can apply additional authorisation checks before an assignment is created, while idempotency and logging make the automation safer to operate.

There are still important implementation decisions to be made regarding authorisation, offboarding, Terraform ownership, failure handling, and monitoring. These details matter because access automation is ultimately a security control.

For organisations operating a large AWS multi-account environment, IAM Identity Centre, combined with event-driven automation, provides a practical way to manage access without adding every new account, employee, or team to the manual administration workload.