Mastering AWS IAM: Identities, Policies, and Endpoints
Create and update AWS Identity and Access Management (IAM) groups, roles, endpoints, and services
Mastering AWS IAM: Identities, Policies, and Endpoints
Learning Objectives
After studying this guide, you should be able to:
- Create and manage IAM identities including users, groups, and roles.
- Differentiate between AWS-managed, customer-managed, and inline policies.
- Apply the principle of least privilege when constructing JSON policy documents.
- Configure service-to-service authentication using IAM roles.
- Understand the limitations and configuration of OpenSearch VPC interface endpoints.
Key Terms & Glossary
- IAM User: An entity representing a person or service that interacts with AWS using permanent credentials (password or access keys).
- IAM Group: A collection of users. Permissions attached to a group are inherited by all members.
- IAM Role: A temporary identity with no permanent credentials, assumed by users or services to perform specific tasks.
- Policy: A JSON document that defines permissions (Allow/Deny) for actions on specific resources.
- ARN (Amazon Resource Name): A unique identifier for every AWS resource (e.g.,
arn:aws:iam::123456789012:user/Steve). - MFA (Multi-Factor Authentication): A security layer requiring a second form of authentication beyond just a password.
- Principle of Least Privilege: The security practice of providing only the minimum permissions necessary to perform a job.
The "Big Idea"
AWS Identity and Access Management (IAM) is the global gatekeeper of the AWS ecosystem. It is not just about logging in; it is the fundamental framework that governs how every person, application, and service interacts with every resource. In the context of data engineering, IAM ensures that your data pipelines (Lambda, Glue, EMR) can access data (S3, Redshift) securely without ever hardcoding sensitive credentials.
Formula / Concept Box
IAM Policy Structure (JSON)
Every IAM policy generally follows this logic:
| Element | Purpose | Example |
|---|---|---|
| Effect | Whether the policy allows or denies access. | "Effect": "Allow" |
| Action | The specific API calls allowed. | "Action": "s3:GetObject" |
| Resource | The specific ARN the action applies to. | "Resource": "arn:aws:s3:::my-bucket/*" |
| Condition | (Optional) When the policy is in effect. | "Condition": {"IpAddress": {"aws:SourceIp": "1.2.3.4/32"}} |
Hierarchical Outline
- IAM Fundamentals
- Global Service: IAM does not require region selection; settings apply worldwide.
- Root User: The account creator. Best Practice: Lock it down and use IAM users for daily tasks.
- Identities
- Users: Long-term credentials. Ideal for human administrators or external non-AWS tools.
- Groups: Logical containers for users. Used for bulk permission management (e.g., "DevTeam").
- Roles: Temporary credentials. Used for Service-to-Service access (e.g., EC2 accessing S3) or Cross-Account access.
- Access Control (Policies)
- Managed Policies: Created by AWS or customers. Reusable across multiple identities.
- Inline Policies: Embedded directly in a single user/role. Not reusable.
- Security Endpoints
- Interface VPC Endpoints: Enables private access to services like OpenSearch without leaving the AWS network.
- Limitations: OpenSearch interface endpoints do not support HTTP (HTTPS only) and cannot be created via CloudFormation.
Visual Anchors
IAM Permission Inheritance
Identity vs. Resource Policy
\begin{tikzpicture}[scale=0.8] \draw[thick, fill=blue!10] (0,0) circle (2cm) node[below=2.2cm] {Identity-Based (Who?)}; \draw[thick, fill=red!10] (3,0) circle (2cm) node[below=2.2cm] {Resource-Based (What?)}; \node at (0,0) {\begin{tabular}{c}Attached to\User/Role$e.g., IAM User)\end{tabular}}; \node at (3,0) {\begin{tabular}{c}Attached to\Resource$e.g., S3 Bucket)\end{tabular}}; \draw[<->, thick] (1.5,1.5) to[out=45, in=135] node[above] {Access Decision} (1.5,1.5); \end{tikzpicture}
Definition-Example Pairs
- Identity Federation: Linking a third-party identity (Google, Active Directory) to AWS.
- Example: A corporate employee signs into the AWS Console using their existing Windows laptop credentials via IAM Identity Center.
- Service-Linked Role: A predefined role that an AWS service uses to perform actions on your behalf.
- Example: Amazon Lex uses a service-linked role to access your Polly voices and Lambda functions automatically.
- Cross-Account Access: Allowing a user in Account A to access resources in Account B.
- Example: A centralized logging account (Account B) provides a role that developers in Account A can assume to upload their application logs.
Worked Examples
Example 1: Creating an S3 Admin Group
- Navigate to IAM > Groups > Create Group.
- Name the group
S3-Admins. - Attach Policy: Search for the AWS-managed policy
AmazonS3FullAccess. - Add Users: Select the specific IAM users (e.g.,
Dave,Sita) to add them. - Result: Dave and Sita now have full S3 access. If you remove
Sitafrom the group, her access is revoked instantly.
Example 2: Assuming a Role for EC2
- Create Role: Choose "AWS Service" as the trusted entity and select "EC2".
- Attach Policy: Attach
AmazonS3ReadOnlyAccess. - Attach to Instance: Select your EC2 instance in the console, choose Actions > Security > Modify IAM Role.
- Verify: Log into the EC2 instance and run
aws s3 ls. The command succeeds without needing anaws configurestep because the instance uses the role's temporary credentials.
Checkpoint Questions
- What is the main difference between an IAM User and an IAM Role?
- Why is it better to use a Customer-Managed policy instead of an Inline policy?
- Can an OpenSearch domain marked for "Public Access" use a VPC Interface Endpoint?
- Which AWS service allows you to integrate your existing corporate Active Directory for Single Sign-On (SSO)?
Comparison Tables
Policy Types Comparison
| Feature | AWS-Managed | Customer-Managed | Inline |
|---|---|---|---|
| Created By | AWS | You | You |
| Reusability | High (Multi-account/user) | High (Single account) | None (1:1 with identity) |
| Ease of Use | Simplest | Moderate | Complex to manage |
| Best For | Common job functions | Least privilege / custom needs | One-off, specific exceptions |
Muddy Points & Cross-Refs
- Service Role vs. Service-Linked Role: A Service Role is a role you create for a service (like EC2) to assume. A Service-Linked Role is a specialized role owned by the service itself (you can't delete it easily) that allows it to function (e.g., Auto Scaling roles).
- Public Access vs. VPC Endpoints: Remember that VPC Interface Endpoints for OpenSearch only work for domains within a VPC. If your OpenSearch domain is set to "Public Access," you must use its public URL and standard IAM/IP-based policies; you cannot bridge it with an interface endpoint.
- CloudFormation Limitation: Note that for the exam, interface VPC endpoints for OpenSearch cannot be created via CloudFormation templates—you must use the Console or APIs/SDKs.