IAM Roles and Policies — Least Privilege Principle

IAM controls every API call in AWS — it handles both authentication (proving who you are) and authorization (determining what you're allowed to do). Understanding least-privilege IAM is essential because overly permissive roles are the most common AWS security finding.

IAM roles vs IAM users

• An IAM user has permanent credentials (access key + secret); an IAM role is assumed by a resource and provides temporary credentials via STS
• For ECS tasks, Lambda functions, and EC2 instances: always use IAM roles, never IAM users; the platform automatically rotates the temporary credentials, which means you don't store or manage long-lived secrets in the environment

Least privilege — the principle

• Least privilege means granting only the exact permissions a service needs and nothing more — which means an ECS task that writes to one S3 bucket should have s3:PutObject on that specific bucket ARN, not s3:* on *
• Over-permissive roles are the single most exploited attack vector in AWS breaches; a compromised task with s3:* exposes all your buckets; a compromised task with s3:PutObject on one bucket exposes only that

IAM policy structure

• Policies have Effect (Allow/Deny), Action (the API operations), Resource (the specific ARN), and optional Condition — aws:SourceIp, aws:RequestedRegion, and s3:prefix are common conditions that narrow access further
• Start with AWS managed policies for common roles (e.g., AmazonECSTaskExecutionRolePolicy) and add custom policies for your specific resource ARNs

In Spring Boot on ECS

• Assign the IAM task role in the task definition; the AWS SDK automatically calls the ECS metadata endpoint to retrieve temporary credentials — no AWS key configuration in environment variables or application.properties
• Use @Value("${aws.region}") from the ECS metadata, not hardcoded; the SDK's DefaultCredentialsProvider chain resolves credentials automatically