Day 20 wrapped up databases. Today we shift gears entirely, into the layer that decides who can do what in your AWS account: IAM and Organizations. This is arguably the most important security topic in the whole series — misconfigured permissions are one of the most common ways real companies get breached.
AWS IAM (Identity and Access Management)
IAM is how you control access to the entirety of AWS — every service, every resource — by granting proper permissions to identities. It's a global service, not tied to any Region, since identity and access control needs to apply consistently across your whole account regardless of where your resources live.
The starting point for every AWS account is the root account — the one you create the account with, using an email and password. The root account has full, unrestricted permissions over everything, including billing. Because of that, using the root account for day-to-day work is a bad practice: if those credentials are ever compromised, an attacker has complete control. This is exactly why IAM users exist — individual identities you create for actual people, each logging in with their own username and password, and each given only the specific permissions they need to do their job.
A concrete example makes this click: imagine one person needs EC2 access, another needs S3 and IAM access, a third needs only Lambda, a fourth needs RDS and EFS, and a fifth needs admin access to everything except billing. Rather than sharing the root account (or giving everyone full access "just in case"), IAM lets you create a separate user for each person with exactly the permissions their role requires — nothing more. This is the principle of least privilege, and it's the foundational idea behind almost everything else IAM does.
A few building blocks beyond individual users:
- IAM Groups let you bundle users who need the same permissions — instead of attaching a policy to five individual developers, you create a "Developers" group, attach the policy once, and add users to it. Permissions changes then happen in one place instead of five.
- IAM Roles are different from users in an important way: a role isn't tied to one specific person logging in with a password — it's an identity that gets assumed temporarily, often by an AWS service itself (like an EC2 instance needing to read from S3) or by a user/account that doesn't normally have that access. Roles issue temporary credentials through AWS's STS (Security Token Service) rather than permanent ones, which is a meaningfully safer pattern than embedding long-lived access keys directly into an application.
- IAM Policies are the actual documents that define permissions — written in JSON, specifying which actions are allowed or denied on which resources. AWS provides managed policies (pre-built, maintained by AWS, like "AmazonS3ReadOnlyAccess") that you can attach directly, or you can write inline policies custom-tailored to a specific user, group, or role.
- MFA (Multi-Factor Authentication) adds a second verification step beyond just a password — AWS strongly recommends enabling it on the root account at minimum, and ideally on every IAM user, since a password alone is a single point of failure.
Worth knowing: IAM Identity Center (formerly AWS SSO) extends this further for organizations managing many users across multiple AWS accounts — letting people log in once and access everything they're permitted to, rather than juggling separate credentials per account.
AWS Organizations
IAM controls access within one AWS account. Organizations solves a different problem: controlling and structuring multiple AWS accounts under one company.
Here's the scenario it's built for: a company doesn't run everything in a single AWS account — different teams (DevOps, Development, Testing, Support) often get their own separate accounts, each acting as its own isolated root account with its own resources and permissions. Left unmanaged, that's a lot of separate root accounts to track, secure, and bill. Organizations brings structure to that: one account becomes the management account (essentially the company's overarching root account), and the rest become member accounts underneath it.
In a typical setup, each member account is still its own root account with its own specific scope — a DevOps account might have access to IAM and EC2, a Developer account to Lambda, a Testing account to Route 53, a Support account to admin-level access. Organizations lets the management account oversee and control all of them centrally, rather than each team's account being a completely disconnected island.
SCPs (Service Control Policies) are how that central control actually gets enforced — they're policies attached at the organization or account level that define the maximum permissions a member account can ever have, regardless of what IAM policies exist inside that account. Even if someone inside a member account grants themselves a broad IAM policy, an SCP can still hard-block access to specific services entirely across that account — it's a guardrail that sits above IAM, not a replacement for it.
A couple of things worth knowing beyond the fundamentals: Organizational Units (OUs) let you group accounts logically (say, all "Engineering" accounts together) so you can apply SCPs to a whole group at once instead of one account at a time. And consolidated billing is a major practical benefit — instead of separate invoices per account, the management account gets one combined bill, and usage can even pool together to hit volume discount thresholds faster than any single account would alone.
How they work together
IAM and Organizations operate at different layers, but they're deeply connected: IAM controls who can do what within an account, while Organizations (via SCPs) controls the outer boundary of what an entire account is even allowed to do, regardless of its internal IAM setup. Think of SCPs as the walls of the room, and IAM policies as what you're allowed to do inside that room — you can't use an IAM policy to break through a wall an SCP has put up.
Quick Recap Questions
- Why is using the root account for day-to-day work considered bad practice?
- What's the actual difference between an IAM user and an IAM role?
- What does an SCP control that a regular IAM policy can't override?
- Why would a company want a management account and multiple member accounts instead of one big shared account?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 22 | Monitoring & Management | Trusted Advisor, AWS Inspector, CloudWatch, CloudTrail, Config |
Top comments (0)