Setting Up AWS Identity Center for Unified Account Access
Many Australian organisations have spread their workloads across several AWS accounts over the past few years, often landing primary infrastructure in Sydney (ap-southeast-2) and a growing number of workloads in Melbourne (ap-southeast-4). What started as a single dev account has multiplied into production, staging, sandbox, and partner environments, and the credential sprawl that followed has become a genuine operational headache.
AWS IAM Identity Center, the rebrand of what used to be called AWS Single Sign-On, replaces ad-hoc IAM users with a central identity layer that talks to your existing directory and feeds permission sets into every member account. The end state is fewer passwords, consistent policies, and an audit trail that holds up against the ACSC Essential Eight, APRA CPS 234, and the Privacy Act's notifiable data breaches scheme.
The catch is that Identity Center only pays off if you plan the rollout properly. The following walkthrough covers the practical steps local teams use when wiring the service into hybrid environments with Active Directory, plus the guardrails that keep auditors happy.
Choosing where identities will live
Before switching anything on, decide which identity source the platform will trust, because changing it later means a full re-provisioning cycle. Most Australian mid-sized businesses and MSPs run Microsoft Active Directory on-premises and replicate it into AWS through either AD Connector or self-managed Domain Controllers hosted in EC2.
Smaller outfits that don't want to maintain an on-prem footprint can use AWS Managed Microsoft AD, which gives multi-AZ resilience inside a chosen region without standing up Windows servers. A third path is Identity Center's built-in identity store, but that quickly runs out of road once you need federation or group-based assignments.
For most hybrid shops, AD Connector hits the sweet spot. It proxies authentication back to existing Domain Controllers without synchronising passwords into AWS, which keeps the security boundary tight and simplifies review during an IRAP assessment.
Enabling the service and selecting an identity source
Identity Center is provisioned from the organisation's management account. Open the console in the region where you want SSO to be managed, with Sydney the common pick for east-coast operations, choose Enable, and then pick your identity source. AD Connector, AWS Managed Microsoft AD, the built-in store, and an external SAML 2.0 provider such as Entra ID are the four options.
If you go with AD Connector, you'll need bidirectional name resolution between the VPC hosting the connector and your on-premises DCs. That typically means a VPC in ap-southeast-2 with routes to a transit gateway or Direct Connect, and DNS forwarders pointing back to Active Directory. The connector handles the SAML and SCIM traffic once the network plumbing is right.
Designing permission sets that scale
Permission sets are the templates that translate group membership into IAM policies inside each member account. They support AWS managed policies, customer managed policies, and inline policies generated from a permissions boundary. For APRA-regulated entities, the boundary pattern is useful because it caps blast radius even when developers are granted broader rights through group assignment.
Aim for permission sets that reflect roles, not individuals. A PlatformEngineers set with AdministratorAccess, a Developers set scoped to PowerUserAccess in non-production OUs, and a ReadOnlyAuditors set with SecurityAudit are common starting points. Resist the urge to create one set per project; that approach collapses under its own weight once you're managing a dozen accounts.
Structuring accounts inside AWS Organisations
Identity Center requires an AWS Organisation with all features enabled. Organisational units usually mirror business units, environments, or compliance posture. A typical Australian financial services customer might have OUs named Production-APRASCoped, Sandbox, and SharedServices, and service control policies layered on top enforce guardrails such as enforced CloudTrail, blocked unapproved services, and required tags on every resource.
If you've already deployed AWS Control Tower, the landing zone guardrails do much of this work for you, and Identity Center slots in cleanly on top. Either way, the goal is consistent policy enforcement without relying on every account admin to remember the rules.
Mapping groups to accounts and permission sets
Once Identity Center is connected to the directory, group membership is automatically discovered. The next job is assigning each group to the appropriate accounts and choosing the right permission set for each assignment. A single group can have different permission sets in different accounts, which is handy for separating read-only audit access in production from write access in dev.
A common local pattern is a PlatformEngineers group with AdministratorAccess across every OU, a Developers group with PowerUserAccess in non-prod only, and a ReadOnlyAuditors group with SecurityAudit in the regulated workloads. Avoid heavy nesting; SCIM synchronisation flattens membership, but lag during sync windows can confuse incident response when someone thinks they've been added and the access hasn't arrived yet.
Tuning sessions and adding just-in-time access
Default session duration in Identity Center is one hour. That suits most desk work but frustrates engineers running long Terraform plans or CloudFormation stacks. The practical compromise is bumping session length to four or twelve hours for low-risk developer accounts while keeping it short for sensitive production access.
Attribute-based access control lets you tag sessions with cost-centre or project data pulled from the directory, which makes chargeback reports cleaner. For privileged tasks, an increasing number of Australian shops are bolting on third-party just-in-time tools on top of Identity Center rather than handing out long-lived administrator sessions, and the combination gives you a paper trail that satisfies internal risk committees without slowing the engineering team down to a crawl.
Monitoring, auditing, and local compliance
CloudTrail records every Identity Center event, and the easiest pattern is to ship those logs into a central logging account in Sydney, then alert on anomalies through EventBridge and Security Hub. The ACSC Essential Eight pushes for multi-factor authentication on all privileged users, which Identity Center supports natively when MFA is enforced in the underlying directory.
If you're chasing IRAP assessment for a federal or state government contract, document the identity flow, permission set inventory, and SCP coverage as evidence. Pair that with a short runbook written in plain English and run a tabletop exercise with the Melbourne or Sydney ops team before the first real incident lands. Auditors notice when the people on the ground actually understand the system they're operating.