Study Guide920 words

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:

ElementPurposeExample
EffectWhether the policy allows or denies access."Effect": "Allow"
ActionThe specific API calls allowed."Action": "s3:GetObject"
ResourceThe 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

  1. 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.
  2. 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.
  3. 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.
  4. 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

Loading Diagram...

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

  1. Navigate to IAM > Groups > Create Group.
  2. Name the group S3-Admins.
  3. Attach Policy: Search for the AWS-managed policy AmazonS3FullAccess.
  4. Add Users: Select the specific IAM users (e.g., Dave, Sita) to add them.
  5. Result: Dave and Sita now have full S3 access. If you remove Sita from the group, her access is revoked instantly.

Example 2: Assuming a Role for EC2

  1. Create Role: Choose "AWS Service" as the trusted entity and select "EC2".
  2. Attach Policy: Attach AmazonS3ReadOnlyAccess.
  3. Attach to Instance: Select your EC2 instance in the console, choose Actions > Security > Modify IAM Role.
  4. Verify: Log into the EC2 instance and run aws s3 ls. The command succeeds without needing an aws configure step because the instance uses the role's temporary credentials.

Checkpoint Questions

  1. What is the main difference between an IAM User and an IAM Role?
  2. Why is it better to use a Customer-Managed policy instead of an Inline policy?
  3. Can an OpenSearch domain marked for "Public Access" use a VPC Interface Endpoint?
  4. Which AWS service allows you to integrate your existing corporate Active Directory for Single Sign-On (SSO)?

Comparison Tables

Policy Types Comparison

FeatureAWS-ManagedCustomer-ManagedInline
Created ByAWSYouYou
ReusabilityHigh (Multi-account/user)High (Single account)None (1:1 with identity)
Ease of UseSimplestModerateComplex to manage
Best ForCommon job functionsLeast privilege / custom needsOne-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.

Ready to study AWS Certified Data Engineer - Associate (DEA-C01)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free