AWS IAM Roles, Organizations, SCPs, CloudTrail, and Control Tower
IAM Roles are especially useful whenever you want an identity to access AWS resources without giving it long-term credentials. They are commonly used by AWS services and applications, for example, an ECS task can assume a role that allows it to read from S3, or an EC2 instance can assume a role that allows it to publish logs to CloudWatch. Roles are also useful for cross-account access, where a user or workload in one AWS account assumes a role in another account. The key idea is: use a role when access should be temporary or delegated, rather than creating and distributing permanent access keys.
Two IAM concepts that often appear alongside roles are service-linked roles and iam:PassRole. A service-linked role is a special IAM role created and managed by an AWS service for performing actions that the service needs on your behalf. For example, an AWS service may create a service-linked role so it can monitor resources or perform required operations without you manually creating the role. iam:PassRole, on the other hand, controls whether an IAM principal is allowed to give an IAM role to an AWS service. For example, when you create an ECS task and specify an IAM execution role, the person or system creating that task needs permission to pass that role to ECS. Importantly, PassRole doesn't allow you to assume or use the role yourself it controls the ability to delegate that role to an AWS service.
AWS Organizations
AWS Organizations lets you centrally manage multiple AWS accounts as a single organization. Instead of putting everything into one AWS account, a company might create separate accounts for production, development, security, logging, or individual teams. Organizations gives you a central management layer where you can group accounts into Organizational Units (OUs), apply policies across accounts, and manage things such as consolidated billing. This separation is valuable because an AWS account becomes a natural security and administrative boundary.
For example, you might have a structure like this:
The important idea is that Organizations manages the accounts, while IAM manages identities and permissions within those accounts. Organizations becomes particularly useful as your AWS environment grows, because you can establish security and governance rules centrally rather than configuring every account independently.
Service Control Policies (SCPs)
A Service Control Policy (SCP) is an Organizations policy that defines the maximum permissions available to accounts or organizational units. An SCP does not grant permissions by itself. Instead, it acts as a guardrail that limits what IAM users and roles inside an account can do. For example, you could apply an SCP to your Production OU that denies the ability to disable CloudTrail, meaning that even an administrator in a member account cannot perform that action.
A useful way to remember this is: IAM policies say what an identity can do; SCPs define the maximum boundary of what an account can do. An IAM policy might say “this role can delete S3 buckets,” while an SCP can say “accounts in this OU can never delete S3 buckets.” Both policies must allow an action for it to succeed.
AWS CloudTrail
AWS CloudTrail records activity and API calls made within your AWS environment. It answers questions such as who performed an action, what action they performed, when it happened, from where, and what AWS resource was involved. For example, if an S3 bucket was accidentally deleted, CloudTrail can help you determine which identity made the API call and when it happened. CloudTrail is therefore an important part of security, auditing, compliance, and troubleshooting.
CloudTrail can record management activity across AWS services, and you can configure trails to deliver events to destinations such as S3. For security-sensitive environments, it's common to make these logs difficult for ordinary administrators to modify or delete and to send them to a dedicated logging/security account.
Organizational Trails
An organizational trail is essentially a CloudTrail trail configured from the AWS Organizations management account so that it applies across the organization's member accounts. Instead of configuring an individual CloudTrail trail separately in every AWS account, you can establish centralized CloudTrail logging for the organization. This is particularly useful when you want consistent auditing across production, development, security, and other accounts.
This gives you a centralized view of activity across your AWS environment. A common pattern is to have CloudTrail logs from multiple accounts delivered to a dedicated logging/security account, helping separate the people who operate workloads from the people responsible for auditing and security.
AWS Control Tower
AWS Control Tower builds on top of AWS Organizations and provides a more opinionated way to set up and govern a multi-account AWS environment. Instead of manually configuring Organizations, accounts, policies, logging, and security guardrails yourself, Control Tower provides an automated framework for establishing a landing zone a standardized starting environment for your AWS accounts.
In one sentence: IAM controls access within accounts, Organizations manages multiple accounts, SCPs constrain what those accounts can do, CloudTrail records what happens, Organizational Trails centralize that auditing, and Control Tower helps establish and govern the entire multi-account AWS environment.
