{"version":"1.0","url":"https://blog.paulkinyatti.com/blog/creating-organizations-in-aws","title":"Creating Organizations in AWS: A Practical Guide to IAM Identity Center and Centralized Access","description":"Learn how to create an AWS Organization, enable IAM Identity Center, manage users and groups, assign permission sets, and build a secure foundation for AWS accounts.","publishedAt":"2026-09-17T12:00:00.000Z","updatedAt":"2026-09-17T15:41:34.983Z","author":{"name":"Paul Kinyatti","bio":"Building things, writing about them, and learning in public."},"tags":[],"category":"AWS","readTime":9,"wordCount":1630,"coverImage":{"url":"https://blog.paulkinyatti.com/images/aws-organizations-identity-center.png","alt":"Abstract cloud infrastructure network representing centralized AWS account access","caption":"A secure cloud foundation starts with clear identity and access boundaries."},"content":{"raw":"A cloud account can run for years and still have almost no real access model.\n\nThat was the situation I recently encountered with a team whose AWS account had been sitting for roughly two years. The environment was not empty. It had simple Amazon EC2 deployments and Amazon S3 buckets, but the operational model was still close to the starting line: the root user had been used directly, access was not centrally managed, and the account had not yet been organized for a growing team.\n\nThe first order of business was not adding another AWS service. It was creating a safer foundation for every service that comes next.\n\nThis guide explains the first steps in creating an AWS Organization, enabling AWS IAM Identity Center, managing users and groups, assigning permission sets, choosing a Region, and introducing centralized AWS account access.\n\n## Why create an AWS Organization?\n\nAWS makes it easy to create resources quickly. That is one of its strengths—and one of its traps.\n\nA team can launch an EC2 instance, create an S3 bucket, and deploy an application before it answers the questions that matter most:\n\n- Who should access the AWS environment?\n- Which people should access which AWS accounts?\n- What permissions should each role receive?\n- How do we remove access when someone changes teams?\n- How do we stop daily work from depending on the root user?\n- Where should identity and access decisions be managed as the environment grows?\n\nWithout clear answers, every new resource creates another isolated access decision. That may work for a personal project. It becomes fragile when a team, multiple environments, or multiple AWS accounts are involved.\n\nAWS Organizations provides the management structure for multiple AWS accounts. It gives a company a central place to apply governance, organize accounts, and prepare for controls such as service control policies, centralized logging, billing management, and security workflows.\n\nThe goal is to move from “we have an AWS account” to “we have a controlled AWS environment.”\n\n## Step 1: Create the AWS Organization\n\nTo create an AWS Organization, sign in to the AWS Console using the account that will become the management account. Open AWS Organizations and choose Create organization.\n\nFor most teams, the recommended choice is All features. This enables the organization capabilities needed for centralized account management and governance. AWS uses the current account as the management account and creates the organization around it.\n\nThe management account should be treated as a highly protected administrative boundary. It is not the place where every application should run forever. As the environment grows, workloads can be separated into dedicated accounts for development, staging, production, security, or shared services.\n\nAt this stage, the important thing is establishing the structure. An AWS Organization does not automatically make an environment secure. It gives the team the structure needed to manage security deliberately.\n\n## Step 2: Enable AWS IAM Identity Center\n\nThe next step is enabling AWS IAM Identity Center as an organization instance.\n\nAWS Identity and Access Management, commonly called IAM, and IAM Identity Center solve related but different problems. IAM manages identities, roles, and policies inside an AWS account. IAM Identity Center provides a central workforce access layer for people who need to work across AWS accounts.\n\nThat distinction matters.\n\nInstead of creating separate IAM users in every account and asking people to remember several account-specific login patterns, IAM Identity Center provides a managed AWS access portal. A user signs in centrally, sees the AWS accounts they are authorized to access, and enters an account through the permission set assigned to them.\n\nThe resulting model is:\n\nUser or group -> permission set -> AWS account -> role session\n\nThe user is managed centrally. The permission set defines the access level. AWS applies that access to the selected account through a role-based session.\n\nThis is easier to understand, audit, adjust, and scale than a collection of isolated IAM users.\n\n## Step 3: Choose an IAM Identity Center Region\n\nFor this setup, IAM Identity Center was enabled in Frankfurt, AWS Region eu-central-1.\n\nRegion selection is not just a visual setting. IAM Identity Center has a home Region, and that choice affects where the identity service is administered and which regional AWS Console endpoint is used for its organization-wide configuration.\n\nFor a team operating from East Africa, Frankfurt is a sensible starting point because it is generally closer than Ireland and often provides better latency for users in Kenya and neighboring countries. The final decision should still consider actual user locations, service availability, compliance requirements, data residency, and an AWS latency test.\n\nThe broader lesson is important: choose AWS Regions intentionally. A Region affects latency, service availability, compliance, operational design, and sometimes cost.\n\n## Step 4: Create users and groups\n\nUsers are important, but groups are where the access model becomes maintainable.\n\nRather than assigning permissions individually to every person, create groups based on responsibilities. A practical starting structure could include:\n\n- Administrators for people responsible for platform and account management\n- Developers for engineers who deploy and troubleshoot applications\n- ReadOnly for people who need visibility without modification rights\n- Security or Audit for security review and investigation workflows\n\nThe exact names are less important than the principle: AWS access should follow responsibility.\n\nWhen a new developer joins the team, add them to the appropriate group. When their role changes, update group membership or the permission assignment. When they leave, remove the identity from the organization access layer.\n\nThis is safer and easier to audit than copying permissions from one individual IAM user to another.\n\n## Step 5: Create permission sets\n\nA group by itself does not grant access to an AWS account. The group must be assigned a permission set for a specific account.\n\nPermission sets are the bridge between centralized identity and account-level access. They define what a person or group can do after entering an AWS account through IAM Identity Center.\n\nA small starting model might include:\n\n- AdministratorAccess for a tightly controlled administrative group\n- Developer or PowerUser access for application development and deployment work\n- ReadOnlyAccess for observation, support, and review\n- A custom Security or Audit permission set for security-focused workflows\n\nAvoid making AdministratorAccess the default for everyone. It is convenient at the beginning, but convenience becomes risk as the team grows.\n\nA better approach is to start with the smallest useful permission set, document why it exists, and expand it only when the work requires it. This is the practical side of least privilege in AWS.\n\n## Step 6: Assign access to AWS accounts\n\nAfter creating users, groups, and permission sets, open AWS accounts in IAM Identity Center. Select the account, choose the group or user, and assign the appropriate permission set.\n\nThe group does not grant access until this assignment is made. This distinction is easy to miss and explains why a user may exist in IAM Identity Center but still see no AWS account in the access portal.\n\nThe account assignment is where the access model becomes real:\n\n- The identity is managed centrally.\n- The group represents the responsibility.\n- The permission set represents the allowed actions.\n- The AWS account defines the boundary where those actions apply.\n\nThis makes access decisions explicit instead of informal.\n\n## Step 7: Use the AWS access portal\n\nIAM Identity Center provides an AWS access portal for workforce users. The initial URL uses an AWS-generated identifier, but the portal alias can be customized once to make it easier to remember.\n\nThe portal becomes the normal entry point for workforce access. Instead of sharing root credentials or creating long-lived IAM user passwords, team members sign in through the central portal and receive the AWS account access assigned to them.\n\nThe question changes from “which password do I use for this account?” to “which AWS account and permission set have I been assigned?” That is a much healthier operational model.\n\n## What this changes immediately\n\nCreating an AWS Organization and enabling IAM Identity Center provides several immediate improvements:\n\n1. Root access is no longer the normal path for daily work.\n2. Users and groups have a central management location.\n3. AWS account access can be assigned by responsibility.\n4. Permission sets provide a consistent access language.\n5. The team has a managed AWS access portal.\n6. The organization is ready for additional AWS accounts and stronger governance.\n7. Security reviews have a clearer place to begin.\n\nThis does not replace policies, logging, monitoring, backups, network design, or workload security. It makes those later improvements easier to apply consistently.\n\n## What comes next?\n\nCreating the AWS Organization and enabling IAM Identity Center is only the beginning.\n\nThe next stages should include protecting the root user with strong controls, enforcing multi-factor authentication, reviewing account recovery procedures, defining administrator responsibilities, enabling centralized logging, and separating workloads into accounts where that makes sense.\n\nFrom there, the organization can introduce service control policies, budget alerts, security findings, and more deliberate structures for development, staging, and production.\n\nCloud governance does not need to arrive as one giant redesign. It can start with the access model and grow from there.\n\n## Final thoughts\n\nA mature AWS environment is not defined by how many services it uses. It is defined by how clearly it answers the questions of identity, access, responsibility, and change.\n\nFor this team, the first meaningful step was not another deployment. It was creating an AWS Organization and putting IAM Identity Center at the center of workforce access.\n\nThat gives the environment a foundation: centralized identities, group-based access, permission sets, a managed sign-in portal, and a structure that can grow beyond one account and one root-user workflow.\n\nThere is still a lot to do. But this is the point where an AWS account starts becoming an AWS platform."}}