Mallory Mooney
Staff Technical Content Writer
When you’re setting up AWS infrastructure, you need to decide which accounts will host your applications, deployment pipelines, and shared services. AWS Organizations lets you organize workloads and shared services into member accounts based on their ownership, purpose, and isolation requirements. A separate management account handles consolidated billing and administration of the organization. Setting up separate accounts and configuring access between them takes planning, though, so running workloads in the management account can seem like a simpler way to get started.
In our 2026 State of Cloud Security report, we found that 14% of the organizations analyzed run Amazon Elastic Compute Cloud (Amazon EC2) instances in their management account, up from 9% in 2025. Keeping workloads separate from those administrative responsibilities helps reduce the risk that a compromised application exposes credentials an attacker could use to administer other accounts. In this post, we’ll explain why account placement affects security, where to place workloads and shared services, and which permissions to review as you set up or reorganize your accounts.
Understand the risks of running workloads in the management account
In member accounts, you can use organization policies to restrict access that AWS Identity and Access Management (IAM) policies would otherwise allow. For example, service control policies (SCPs) limit what users and roles can do, while resource control policies (RCPs) limit access to resources. But those additional restrictions don’t apply within the management account, although IAM policies still govern access there. That’s one reason why AWS recommends keeping workloads in member accounts and reserving the management account for other organization-wide tasks, such as billing.
A compromised workload in the management account can also give an attacker access to member accounts if its credentials allow it to assume roles there. For example, AWS Organizations typically creates an administrative role named OrganizationAccountAccessRole in accounts that you create through the service. The role trusts the management account, so an attacker who obtains credentials with permission to assume it can gain administrative access to the member account, subject to that account’s restrictions. AWS has also observed attackers using management account privileges to call sts:AssumeRoot, which provides short-lived sessions for specific privileged tasks in member accounts where root sessions are enabled.
Choose the right account for workloads and shared services
When deployment tools or shared services need access to several accounts, you need to provide that access without bringing routine work into the management account. You should reserve that account for consolidated billing and tasks that require it, such as registering delegated administrators. You can use delegated administration to let teams manage their services from member accounts based on the teams’ responsibilities. For example, the security team can administer Amazon GuardDuty from a security tooling account, while a platform team manages shared services from a separate account.
Workload accounts should reflect who owns the applications, what they do, and which workloads or data need to stay isolated. For example, you should also keep production and development workloads in separate accounts so you can apply different access and network controls to each environment. The following table uses AWS’s guidance for organizing accounts to help you choose where to run workloads and shared services:
| Workload or responsibility | Recommended placement | What to keep in mind |
|---|---|---|
| Organization setup, registration for delegated administrators, and roles for tasks that require the management account | Management account | Limit access to those responsibilities. This account retains responsibility for paying the organization’s charges. |
| Application EC2 instances, containers, Lambda functions, databases, and runtime roles | Workload member accounts | Separate applications and environments according to their access and isolation requirements. |
| CI/CD runners, build jobs, and deployment orchestration hosted in AWS | Deployment or tooling member account | The pipeline can assume deployment roles in target workload accounts. Restrict those roles to only the pipeline identities that need access. |
| Central administration of GuardDuty, Security Hub, and Inspector | Security tooling member account | You should register a delegated administrator for each service and configure coverage for the member accounts and Regions you need to monitor. The resources stay in their member accounts. |
| Amazon Simple Storage Service (Amazon S3) buckets that hold organization CloudTrail logs and other audit records | Log archive member account | You can delegate CloudTrail administration to a security tooling account and store audit logs in the log archive account. This enables you to control access to the logs separately from permissions to administer CloudTrail. |
| Shared directory services, such as AWS Managed Microsoft AD, and routine administration of IAM Identity Center and Systems Manager | Shared services member account | Use delegated administration where supported. IAM Identity Center remains enabled in the management account, where you also manage permission sets that grant access to that account. |
Enforce access boundaries between accounts
A workload in a member account can still have unnecessary access to other accounts through the roles it’s allowed to assume. IAM policies grant that access, and SCPs set permission limits for users and roles in member accounts, including accounts that serve as delegated administrators. If your organization has all features enabled, you can apply SCPs to individual accounts or attach them to organizational units (OUs) to enforce the same restrictions across accounts with similar security requirements.
For example, a deployment pipeline might run under an IAM role in a dedicated deployment member account and assume roles in workload accounts to deploy applications. You should limit the pipeline role’s sts:AssumeRole permissions to the destination roles it needs. Each destination role’s trust policy should restrict access to the identities that need to assume it, and its permissions should cover only the deployment tasks the pipeline needs to perform.
You can reinforce those IAM restrictions by attaching an SCP to the same deployment account. The SCP can deny sts:AssumeRole for every destination role except those on an approved list, which you specify by including their Amazon Resource Names (ARNs) in the policy’s NotResource element. That restriction prevents the account’s pipeline roles from assuming unapproved roles even if someone later grants them broader IAM permissions.
If your pipeline uses automation tools such as GitHub Actions to authenticate to AWS, you should also restrict which workflows can assume its initial IAM role. Datadog Security Labs’ research on GitHub-to-AWS authentication flaws shows how overly broad trust policies can let untrusted workflows obtain AWS credentials.
Before applying an SCP broadly, you should test it with a small set of accounts in a test OU. A test account enables you to check that required deployments still succeed and attempts to assume unapproved roles fail. It also helps you ensure that administrators and other workloads in the deployment account can still assume the roles they need. Our guide to AWS data perimeter misconfigurations includes further examples of testing SCPs that block AWS CloudTrail changes and access to Amazon S3 buckets outside your organization.
Keep organization administration separate from workloads
As your team adds or moves workloads, you should review which accounts they’ll run in, which roles they can assume, and which organization policies apply. You can use SCPs to enforce restrictions across member accounts and IAM policies to grant only the access each workload needs. Whenever that access changes, you should test that required tasks still succeed and attempts to assume unapproved roles fail.
For more guidance on monitoring the workloads you deploy, see our guides to monitoring AWS Lambda functions, AWS Fargate workloads, and Amazon Elastic Kubernetes Service (Amazon EKS) clusters. You can also learn how to monitor Cloudtrail logs, detect unauthorized third-party access to AWS, and monitor AWS WAF to extend visibility into your environment and potential attack paths.
If you don’t already have a Datadog account, sign up for a 14-day free trial to start monitoring your AWS environment.
