# IAM vs AWS Organization

Here are two separate, resume-ready points for IAM and AWS Organizations/SSO:

**For AWS IAM:**  
**“Worked on AWS IAM by creating and managing users, groups, roles, and custom policies to enforce least-privilege access and ensure secure identity and access management across environments.”**

**For AWS Organizations & SSO:**  
**“Configured and managed AWS Organizations and AWS SSO to enable centralized account management, secure access control, and compliance across multi-account environments.”**

Would you like me to make these slightly **more concise** for a bullet-list style resume?

##### You said:

## <mark>Q.So, within IAM, we have policies, and for AWS Organizations, we use SCPs. We apply SCPs to OUs in AWS Organizations, right?</mark>

Exactly ✅

Here’s the breakdown:

* **IAM Policies (Identity-based policies)** → Applied to **users, groups, or roles** inside **a single AWS account**.
    
    * Used to **grant permissions** (e.g., “allow EC2:StartInstances”).
        
    * They define **what the identity can or cannot do** within that account.
        
* **SCPs (Service Control Policies)** → Used within **AWS Organizations**, applied to **OUs (Organizational Units)** or **accounts**.
    
    * SCPs **don’t grant permissions** — they **set the maximum boundary** of what IAM users or roles **can be allowed** to do.
        
    * Even if IAM policy allows an action, if SCP denies it, the action is blocked.
        
    * Typically used for **governance and compliance**, e.g., restricting root account usage, limiting regions, or blocking certain services.
        

So yes — **you organize accounts into OUs**, and then **apply SCPs on those OUs** to control permissions at the organizational level.

## <mark>Q. So we don't use SCPs to give permissions. What do we use instead?</mark>

Correct — **SCPs (Service Control Policies)** do **not** *grant* permissions.

Here’s how it works 👇

* **IAM Policies** (inside each account) → **Grant permissions**
    
    * You attach these to **IAM users, groups, or roles**.
        
    * They explicitly allow actions (e.g., `s3:GetObject`, `ec2:StartInstances`).
        
    * This is what actually gives people or services the ability to perform tasks.
        
* **SCPs** (in AWS Organizations) → **Restrict or limit permissions**
    
    * They set the **maximum boundary** for what any IAM policy *can* allow.
        
    * Think of it as a **permission guardrail** — it can *deny*, but never *grant*.
        
    * Example:
        
        * IAM policy allows `ec2:*` (all EC2 actions).
            
        * SCP denies `ec2:TerminateInstances`.
            
        * Result → user can do everything **except terminate instances**.
            

So in short:

* **IAM policies = actual permissions (who can do what)**
    
* **SCPs = guardrails (what’s never allowed, even if IAM says yes)**