Key takeaways

• An AWS organization typically includes not only workload accounts but also special-purpose accounts dedicated to operations, infrastructure, and governance.
• The special account used to create an AWS organization is called the management account or payer account. Access to that account should be restricted as much as possible.
• Many AWS organizational-level operations, which may align with distinct teams or responsibilities in a real-world organization, require being executed from the management account.
• The AWS delegated administrator function reduces the requirement for accessing the management account by allowing us to execute each of the above operations from different designated AWS accounts.
• If an AWS operation mandates using the management account, check if that service supports the delegated administrator feature to designate another member account to perform those administrative operations.

AWS Organization vs Real-life organization

AWS Organization Terminologies

Although AWS has long recommended using multiple accounts for improved security and governance ¹, I saw many teams still using only one AWS account for all their workloads and operations. This section briefly discusses the important terms when working with the AWS organization for those unfamiliar with it before we dive deep into more advanced features.

• First, we start with an AWS account, where you sign in with a username and password via the web console. Each AWS account has an AWS account ID, a 12-digit number that uniquely identifies this account.
• From one AWS account, we create an AWS organization once. You can establish an organization manually through the AWS Organizations service. However, using AWS Control Tower is highly recommended, as it offers baseline configurations and streamlined management..
• The original AWS account we used to create the organization is now called the management account or payer account. The latter name tells us that we will pay for the expenses in all AWS accounts under our organization from the payer account. This is also called consolidated billing. Access to the management account should now be tightly restricted, as it holds the keys to every administrative action across the organization. ².
• Inside an organization, we can create more AWS accounts and optionally group those accounts under groups called organizational units (OU). The other accounts in the organization, besides the management one, are called member accounts. We can apply many types of organizational policies to each AWS account or OU to take advanced control of what people can do in each AWS account ³. There are multiple ways to design the structure of AWS accounts and OUs in the organization. AWS also published a whitepaper introducing some good starting design⁴.
• Although not mandatory, human users should use AWS IAM Identity Center (formerly AWS SSO) to sign in to AWS accounts under an organization to execute tasks via the web UI.

Organizational Operations and People Responsibilities

As with many socio-technical systems, the structure of an AWS organization often mirrors the real-world team structures behind it—a phenomenon known as Conway’s Law:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. ⁵

Fundamentally, AWS enables us to deploy and manage workloads such as applications, services, and their dependencies. Application developers are responsible for deploying and operating their services in multiple environments (integration, staging, production, etc). In an AWS organization, we have member accounts whose purpose is to host those workloads. It’s best practice to use different AWS accounts for various environments.

Even within the most streamlined organizations, responsibilities extend far beyond mere application deployment. The cloud and infrastructure engineers are responsible for provisioning the whole cloud environment, ideally automated and reproducible via Infrastructure as Code (IaC) pipelines. They also own shared components like container registries, package registries, CI/CD runners, etc., that must be accessible from various workload environments. The cloud and infrastructure team also monitors the findings and recommendations from AWS Trusted Advisor to improve the whole AWS environment continuously. Personally, I have always had a dedicated AWS account named infra-ops, which plays the role of the cloud and infrastructure team’s headquarters, to host the above tools.

With a larger organization, a dedicated security team may govern the whole security architecture, including the cloud environment. They control the access of people to the AWS organization via the SSO portal (AWS IAM Identity Center) as well as what they can do from each account. The security team runs security tools to actively scan for threats and vulnerabilities in the organization, including monitoring findings from managed services like AWS Security Hub, AWS Guard Duty, or Amazon Inspector. Like for the cloud and infrastructure team, I usually have an AWS account named sec-ops for the security engineers.

As the organization scales, cross-account communication becomes inevitable, introducing additional networking complexity. As complexity grows, a networking team often emerges to design and operate the whole network. They have many operations that should be centralized for easier monitoring and controlling. A dedicated AWS account called networking may be a good choice to host those tools.

Unfortunately, to achieve their goals, all of the above different teams and people may need to execute operations that are required to be executed from the management account by default. But do you remember the principle of limiting access to our management account ²? We absolutely should not grant the permissions to our management account to dozens of people from multiple teams.

Infrastructure as Code Runner and the AWS Management Account

While the above section focuses on human actors when working with the AWS organization, this section focuses on the runners that provision the AWS environment. In mature cloud environments, infrastructure is seldom provisioned through manual console interactions. Instead, it’s defined programmatically via domain-specific languages like Terraform ⁶ or frameworks designed for infrastructure like CDK ⁷ or Pulumi ⁸. To make the changes in code reflected in the live environment, we have automation tools running on runners like GitHub actions, GitLab CI, or Atlantis runner ⁹. Like other applications, those runners need to be authenticated to AWS via roles and have specific permissions to make API calls to AWS environments.

People often refer to the least privilege principle ¹⁰ when talking about setting permissions for a specific workload that makes API calls to AWS. However, practitioners know that determining least-privilege policies for IaC runners can be complex and time-consuming, especially during initial setup. As a result, we usually grant the runner the administrative permissions to allow it to do anything in AWS accounts. Here, we should decide on how to use IaC with the management account due to its critical role in the whole organization:

• We can allow the runner to have administrative permissions in the management account and apply the IaC code to target this account. This leads to a large attack surface for the management account, as anyone who can assume the IaC runner role directly or indirectly can now execute operations from this privileged account.
• Or, we don’t allow the runner to access the management account. Any changes made in the management account should be made manually by humans via the web console or via IaC code from a machine that is limited to only people who have access to the management account. Taking this path, it’s better to have a maximum of three people who can apply those changes, not dozens of engineers, as mentioned in the previous section.

Is it possible to extend our IaC and automation practices to include even management-account tasks, to make our environment more transparent and replicable without compromising security?

AWS Delegated Administrator

Execute Organizational Operations from Another AWS Account in the Organization

The delegated administrator ¹¹ capability in AWS helps mitigate the dependency on the management account. Consider the scenario of provisioning a new SSO user in AWS IAM Identity Center. Most of the time, we only set up IAM Identity Center once. This setup process creates an organizational instance ¹² of IAM Identity Center in the management account so that we can manage multi-account permissions from this instance. As a result, if we want to manage SSO users and their permissions in this IAM Identity Center instance, we must use an IAM entity from the management account with the identitystore:* and sso:* permissions. If we want to manage the list of SSO users and their permissions as code and apply the code automatically from runners, we must grant the runners these permissions.

Instead of granting the runners these permissions directly in the management account, I will grant the runners these permissions from the sec-ops account. Without additional configuration, this setup would fail, as permissions typically apply only within the same account. Let’s set the sec-ops account to be the delegated administrator of the IAM Identity Center service by doing these steps:

• Sign in to the management account with the administrative role
• Select the Region where IAM Identity Center is enabled, and then open the IAM Identity Center console
• Choose Settings, and then select the Management tab.
• In the Delegated administrator section, choose Register account.
• On the Register delegated administrator page, select the AWS account you want to register, here the sec-ops account, and then choose Register account.

Once this configuration is in place, the runner who only operates in the sec-ops account can seamlessly manage SSO users organization-wide. If we want to allow a human user to manage IAM Identity Center from the web console, we can grant them the permissions to the sec-ops account instead of the permissions in the management account. Those users can sign in to the sec-ops account, navigate to the IAM Identity Center console, and manage our organization’s users from there.

Common Operations that Should be Delegated

When working with AWS on a large scale, many routine operations still default to the management account, like the above example, despite their decentralized nature. Many of them benefit from the delegated administrator function, allowing us to continue limiting access to the management account. The full list of AWS services that support the delegated administrator is publicly accessible in the AWS document ¹³. The following table summarizes common use cases for delegated administration, along with my suggested account assignments.

As a cloud engineer, when you see a task in AWS that requires execution from the management account, let’s try to see if the service supports the delegated administrator feature. If the service is supported, designate a member account to be the administrator account of that service and grant entities permission to access that service instead of the management one. The more rarely the management account is used, and the fewer individuals granted access to it, the stronger our overall security posture becomes. As organizations embrace complexity and scale, relying on a single AWS management account for critical operations is no longer sustainable. Embrace the delegated administrator model, not just as a best practice, but as an enabler of automation, clarity, and resilient design.