1.5.3. IAM (Identity and Access Management) for Applications

First Principle: IAM provides granular control over what AWS resources an application can access and what actions it can perform, ensuring secure interactions via the Principle of Least Privilege.

For developers, properly configuring AWS Identity and Access Management (IAM) for your applications is crucial for security. It ensures that your application (running on an EC2 instance, as a Lambda function, or in a container) has only the necessary permissions to interact with other AWS services.

• IAM Roles: (Secure IAM identities that grant temporary permissions.) Applications running on AWS should assume IAM roles (via instance profiles for EC2 or execution roles for Lambda) rather than using long-lived access keys embedded in code. This provides temporary, automatically rotated credentials.
• IAM Policies: (JSON documents that define specific permissions.) Attach these to IAM roles to define what actions your application is allowed to perform on which resources (e.g., s3:PutObject on a specific S3 bucket). Adhere strictly to the Principle of Least Privilege.
• Resource Policies: (Policies embedded directly within a resource). For services like Amazon S3 or Amazon SQS, these define who can access that specific resource and what actions they can perform.

Scenario: You're developing a Lambda function that needs to read data from an Amazon S3 bucket and write to an Amazon DynamoDB table. You want to grant it only these specific permissions.

⚠️ Exam Trap: IAM users with access keys are for human CLI access. Applications running on AWS should ALWAYS use IAM roles (Lambda execution role, EC2 instance profile, ECS task role) — never embedded access keys.