AWS Solutions Architect Security IAM

AWS Identity and Access Management controls who can access AWS resources and what actions they can perform. It's a foundational service for secure cloud architecture.

IAM Core Components

Every IAM setup involves three key elements:

• Principals (AWS accounts, IAM users, IAM roles, federated users)
• Authentication (verifying identity through credentials)
• Authorization (determining what actions a principal can perform)

Every principal must authenticate to AWS first. Then IAM policies determine which actions they can perform on specific resources.

The Principle of Least Privilege

IAM operates on least privilege, meaning users should only have permissions necessary for their job functions. This minimizes security exposure if credentials are compromised.

AWS denies all requests by default unless an explicit Allow statement exists. This implicit deny principle is crucial for exam success.

IAM Policy Types

IAM Policies are JSON documents that define permissions. There are three main types:

1. Identity-based policies (attached to users, groups, or roles)
2. Resource-based policies (attached to resources like S3 buckets)
3. Permission boundaries (limiting maximum permissions)

Understanding explicit allow versus implicit deny is essential. You must design least-privilege access patterns for the Solutions Architect exam.

Auditing and Access Management

The IAM console provides visibility into user activities and security configurations. Two key tools help you audit IAM:

• Access Advisor shows when permissions were last used
• Credential Report lists all users and their credential status

These features help identify unused permissions and security gaps in multi-account AWS environments.

Each IAM component serves a specific purpose in your access architecture. Understanding when to use each is critical for the Solutions Architect exam.

IAM Users vs. IAM Groups

IAM Users represent individual people or applications. Each has a unique name and can have console and programmatic access credentials. Users generate long-term credentials that you manage manually.

IAM Groups are collections of users with similar permission requirements. Instead of attaching policies to each user individually, you attach policies to groups. All group members automatically receive those permissions.

Groups simplify management at scale. When you change a policy attached to a group, all members immediately get the new permissions. Groups cannot be nested, so organize them by function or department.

IAM Roles and Trust Policies

IAM Roles are the preferred mechanism for granting temporary access. Unlike users, roles don't have long-term credentials. Instead, they generate temporary security credentials through AWS Security Token Service (STS).

Roles are essential for:

• Cross-account access
• Federated identity
• Service-to-service communication
• Applications running on EC2, Lambda, or containers

Trust Policies are resource-based policies attached to roles. They determine which principals can assume a role. A trust policy specifies the Principal, Action (usually sts:AssumeRole), and Effect.

Multi-Account Access Example

Imagine you need an application in Account A to access resources in Account B. Here's the solution:

1. Create a role in Account B with appropriate resource permissions
2. Add a Trust Policy allowing Account A's role to assume it
3. Configure Account A's role to assume the Account B role

This pattern is fundamental to large-scale AWS architectures spanning multiple accounts.

Large AWS organizations often span multiple accounts. Each account might host different workloads, teams, or business units. Secure cross-account access requires careful IAM design.

How Cross-Account Access Works

The delegation process uses role assumption and trust relationships. Here's the flow:

1. Create a role in the resource account (Account B) with necessary permissions
2. Add a Trust Policy allowing a principal from Account A to assume this role
3. A user in Account A assumes the role and receives temporary credentials
4. Temporary credentials grant access to Account B resources for the session duration

ARNs (Amazon Resource Names) are essential for specifying principals and resources in these scenarios. They identify users, roles, and accounts across the organization.

Preventing Security Issues with External ID

The External ID parameter is a critical security best practice. It acts like a secret password, preventing the confused deputy problem where an unrelated third party could accidentally gain access.

When implementing cross-account role assumption, always include an External ID. Require third parties to provide it when assuming the role. This ensures that even if the role ARN is compromised, unauthorized parties cannot access your resources.

Multi-Account Governance

Organizations use AWS Organizations service control policies (SCPs) to enforce permission boundaries across multiple accounts. SCPs provide centralized governance without managing individual IAM policies everywhere.

Common Cross-Account Scenarios

You'll encounter these patterns on the exam:

• Granting developers temporary access to production accounts
• Enabling third-party vendors to audit resources
• Establishing hub-and-spoke architectures where a central account manages access

For Solutions Architect success, design secure cross-account architectures and troubleshoot access issues confidently.

AWS recommends critical best practices tested heavily on the Solutions Architect exam. Following these prevents security breaches and architectural flaws.

Essential Security Practices

Enable Multi-Factor Authentication (MFA) on the root account and all users with console access. MFA adds a second authentication factor beyond passwords, significantly improving security.

Follow the principle of least privilege by granting only minimum necessary permissions. Regularly review and remove unnecessary permissions. Users should only access resources required for their job.

Use IAM Roles instead of IAM Users for applications and services. Roles provide temporary credentials that automatically rotate, reducing credential leakage risks.

Enable AWS CloudTrail logging for all IAM activities. CloudTrail creates an audit trail showing who accessed what resources and when.

Identity Management at Scale

Use AWS Identity Center (formerly AWS SSO) for centralized user management in multi-account environments. This eliminates managing individual IAM users across accounts and enables group-based access provisioning.

Federation allows organizations to extend their corporate identity systems into AWS without creating separate IAM users.

Credential and Permission Management

Implement these specific controls:

• Create password policies requiring strong passwords with complexity requirements and minimum length
• Use temporary credentials through STS AssumeRole instead of long-term access keys
• Never embed credentials in code or configuration files
• Use IAM roles for EC2 instances, Lambda functions, and containers instead

Auditing and Monitoring

Regularly audit IAM configurations using two key tools:

1. AWS Access Analyzer identifies resources accessible from outside your account
2. IAM Access Advisor shows when permissions were last used

Implement permission boundaries to limit maximum permissions for delegated user administration. This prevents users from granting excessive permissions accidentally.

Memoize these best practices and identify security issues in architectural scenarios. The exam tests your ability to recommend improvements.

The Solutions Architect Associate exam tests your ability to design secure IAM architectures meeting business requirements. You must understand how to integrate IAM with organizational needs.

Federated Identity Integration

You must understand federated identity using AWS Identity Provider, external providers like Okta or Azure AD, and SAML or OpenID Connect protocols.

Federation allows organizations to extend corporate identity systems into AWS without creating separate IAM users. This scales to thousands of employees.

Enterprise-Scale Scenario

Consider a company with 10,000 employees needing appropriate AWS access based on job role. Creating 10,000 IAM users would be impractical.

The best approach uses federated identity through AWS Identity Center. Access automatically provisions based on corporate directory groups. This eliminates manual user creation and reduces administrative overhead.

Multi-Account Strategy Design

Another common scenario involves designing multi-account strategies where business units operate independently but need centralized security governance.

Implement this architecture with:

• AWS Organizations with service control policies to enforce permission boundaries across accounts
• Cross-account roles for auditing and logging
• A central security account containing IAM resources and logs

Identifying Security Weaknesses

Exam questions often present security flaws for you to identify:

• Excessively permissive policies using wildcard resources
• Missing MFA enforcement on critical accounts
• Improper cross-account trust relationships
• Long-term access keys used instead of temporary credentials

You'll recommend specific improvements using AWS services and IAM features.

IAM Integration with Other Services

Understand how IAM integrates across AWS:

• EC2 uses instance profiles to grant permissions
• S3 uses bucket policies and object ACLs
• KMS uses key policies for encryption
• RDS supports IAM authentication for database access

Practice designing least-privilege policies granting specific actions on specific resources to specific principals. Overly permissive policies are a common architectural flaw the exam tests.