Perbedaan IAM User dan IAM Role: Kapan Menggunakan Masing-Masing?

Salah satu kebingungan paling umum saat mulai bekerja dengan AWS adalah memilih antara IAM User dan IAM Role — terutama ketika sebuah aplikasi yang berjalan di EC2 perlu mengakses S3. Pilihan yang salah di sini bukan sekadar masalah estetika arsitektur; menyematkan access key di dalam instance adalah salah satu penyebab paling umum terjadinya kebocoran kredensial di lingkungan produksi.

TL;DR: IAM User vs IAM Role

Aspek	IAM User	IAM Role
Identitas	Manusia atau aplikasi dengan kredensial permanen	Identitas sementara yang dapat diasumsikan oleh entitas lain
Kredensial	Access Key ID + Secret Access Key (permanen)	Token sementara via STS (otomatis dirotasi)
Penggunaan ideal	Pengguna manusia, CI/CD pipeline tanpa OIDC	EC2, Lambda, ECS, cross-account access
Risiko kebocoran	Tinggi — kunci tidak kedaluwarsa secara otomatis	Rendah — token kedaluwarsa dalam hitungan jam
Rotasi kredensial	Manual	Otomatis oleh STS
Rekomendasi AWS	Hindari untuk workload aplikasi	Direkomendasikan untuk semua compute resource

Cara Kerja IAM User dan IAM Role

IAM User adalah entitas permanen di dalam akun AWS. Ia memiliki kredensial jangka panjang — access key yang tidak kedaluwarsa kecuali dicabut secara manual. Ini cocok untuk pengguna manusia yang login ke AWS Console atau tools CLI lokal, tapi berbahaya jika digunakan di dalam aplikasi karena kunci tersebut harus disimpan di suatu tempat, dan tempat itu bisa bocor.

IAM Role berbeda secara fundamental. Role tidak memiliki kredensial permanen. Sebaliknya, entitas yang 'mengasumsikan' role tersebut — bisa berupa EC2 instance, Lambda function, atau akun AWS lain — menerima token sementara dari AWS Security Token Service (STS). Token ini memiliki masa berlaku terbatas dan dirotasi secara otomatis.

Untuk EC2, mekanismenya bekerja melalui Instance Metadata Service (IMDS). Ketika sebuah Instance Profile (pembungkus role untuk EC2) dilampirkan ke instance, AWS SDK secara otomatis mengambil kredensial sementara dari endpoint IMDS tanpa konfigurasi tambahan.

sequenceDiagram participant App as Aplikasi di EC2 participant SDK as AWS SDK participant IMDS as IMDS (169.254.169.254) participant STS as AWS STS participant S3 as Amazon S3 App->>SDK: Panggil s3.getObject() SDK->>IMDS: GET /latest/meta-data/iam/security-credentials/ IMDS->>STS: Minta token sementara untuk Role STS-->>IMDS: Token (AccessKey + SecretKey + SessionToken + Expiry) IMDS-->>SDK: Kembalikan kredensial sementara SDK->>S3: Request dengan token sementara S3-->>App: Response data Note over SDK,IMDS: SDK otomatis memperbarui token sebelum kedaluwarsa

1. EC2 Instance memiliki Instance Profile yang terikat ke IAM Role.
2. AWS SDK di dalam aplikasi memanggil IMDS endpoint untuk mendapatkan token sementara.
3. STS menerbitkan kredensial sementara (Access Key, Secret Key, Session Token) dengan TTL terbatas.
4. SDK menggunakan token tersebut untuk memanggil S3 API.
5. Sebelum token kedaluwarsa, SDK secara otomatis memperbarui token dari IMDS — tanpa intervensi operator.

Credential Provider Chain: Urutan Resolusi Kredensial

AWS SDK tidak langsung menggunakan satu sumber kredensial. Ia menelusuri 'credential provider chain' secara berurutan dan berhenti di sumber pertama yang valid. Memahami urutan ini kritis untuk debugging — terutama saat kredensial yang salah digunakan secara diam-diam.

graph TD Start([AWS SDK mencari kredensial]) --> EnvCheck{Environment Variables
AWS_ACCESS_KEY_ID?} EnvCheck -->|Ada| UseEnv[Gunakan Env Vars
BERHENTI di sini] EnvCheck -->|Tidak ada| FileCheck{File credentials
~/.aws/credentials?} FileCheck -->|Ada| UseFile[Gunakan file credentials
BERHENTI di sini] FileCheck -->|Tidak ada| IMDSCheck{Instance Profile
terlampir ke EC2?} IMDSCheck -->|Ada| UseIMDS[Ambil token sementara
dari IMDS — BENAR] IMDSCheck -->|Tidak ada| Fail[NoCredentialsError] style UseEnv fill:#f9a825,color:#000 style UseFile fill:#f9a825,color:#000 style UseIMDS fill:#2e7d32,color:#fff style Fail fill:#c62828,color:#fff

1. Environment Variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) — diperiksa pertama kali. Jika variabel ini di-set di environment EC2, SDK akan menggunakannya dan tidak melanjutkan ke IMDS. Ini adalah jebakan umum: developer men-set env vars untuk testing lokal, lupa membersihkannya, lalu aplikasi di EC2 tidak pernah menggunakan Instance Role.
2. File credentials (~/.aws/credentials) — diperiksa kedua. Keberadaan file ini di dalam instance (misalnya karena seseorang pernah menjalankan aws configure di sana) akan memblokir penggunaan Instance Role secara diam-diam.
3. Instance Metadata Service (IMDS) — baru diperiksa ketiga. Ini adalah sumber kredensial yang benar untuk EC2 yang menggunakan Instance Profile.

Bayangkan credential provider chain seperti sistem login dengan fallback: jika kunci fisik tersedia (env vars), pintu terbuka tanpa memeriksa kartu akses digital (IMDS). Masalahnya, kunci fisik itu mungkin milik orang yang salah.

Mengapa IAM User di EC2 Adalah Praktik yang Harus Dihindari

Skenario klasik yang sering terjadi: developer membuat IAM User, men-generate access key, lalu menyimpannya di ~/.aws/credentials atau sebagai environment variable di dalam EC2 instance. Aplikasi berjalan normal. Enam bulan kemudian, instance tersebut di-snapshot untuk debugging, snapshot dibagikan, dan access key bocor.

Masalah mendasarnya adalah kredensial permanen memiliki attack surface yang jauh lebih besar. Token STS dari Instance Role kedaluwarsa dalam hitungan jam — bahkan jika bocor, window of exploitation sangat sempit. Access key IAM User tidak kedaluwarsa sampai dicabut secara eksplisit.

Ada satu lagi aspek yang sering diabaikan: audit trail. Dengan Instance Role, CloudTrail mencatat panggilan API dengan principal yang menyertakan instance ID dan role ARN. Dengan IAM User yang di-share antar instance, sulit menentukan instance mana yang melakukan panggilan tertentu.

Implementasi IAM Role untuk EC2 Mengakses S3

Berikut langkah konkret untuk menyiapkan Instance Profile dengan akses S3 menggunakan prinsip least privilege.

Langkah 1: Buat IAM Role dengan trust policy untuk EC2
Trust policy mendefinisikan siapa yang boleh mengasumsikan role ini. Untuk EC2, principal-nya adalah ec2.amazonaws.com.

🔽 Trust Policy JSON (klik untuk expand)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

aws iam create-role \
  --role-name MyAppS3Role \
  --assume-role-policy-document file://trust-policy.json \
  --region us-east-1

Langkah 2: Buat permission policy dengan akses S3 minimal
Jangan gunakan s3:*. Tentukan bucket dan operasi spesifik yang dibutuhkan aplikasi. Ini mencegah aplikasi yang terkompromi dari menghapus atau mengekspor data di luar scope-nya.

🔽 Permission Policy JSON (klik untuk expand)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::nama-bucket-anda/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::nama-bucket-anda"
    }
  ]
}

aws iam put-role-policy \
  --role-name MyAppS3Role \
  --policy-name S3AppAccess \
  --policy-document file://permission-policy.json

Langkah 3: Buat Instance Profile dan lampirkan role
Instance Profile adalah container yang menghubungkan IAM Role ke EC2 instance. Satu Instance Profile hanya bisa memiliki satu role.

aws iam create-instance-profile \
  --instance-profile-name MyAppInstanceProfile

aws iam add-role-to-instance-profile \
  --instance-profile-name MyAppInstanceProfile \
  --role-name MyAppS3Role

Langkah 4: Lampirkan Instance Profile ke EC2 instance

aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=MyAppInstanceProfile \
  --region us-east-1

Langkah 5: Verifikasi kredensial yang aktif di dalam instance
Setelah Instance Profile terlampir, SSH ke instance dan verifikasi bahwa SDK mengambil kredensial dari IMDS, bukan dari sumber lain. Ini langkah yang sering dilewati dan menjadi sumber kebingungan saat debugging.

aws sts get-caller-identity

Output yang benar akan menampilkan ARN dengan format arn:aws:sts::123456789012:assumed-role/MyAppS3Role/i-1234567890abcdef0. Jika output menampilkan IAM User ARN, berarti ada env vars atau file credentials yang memblokir IMDS — periksa dengan env | grep AWS dan cat ~/.aws/credentials.

Pola Penggunaan: Kapan IAM User Masih Relevan

Bukan berarti IAM User tidak punya tempat. Ada skenario di mana IAM User masih merupakan pilihan yang tepat:

• Pengguna manusia yang mengakses AWS Console — meskipun AWS Organizations dengan IAM Identity Center (SSO) kini lebih direkomendasikan untuk tim.
• CI/CD pipeline yang tidak mendukung OIDC — beberapa sistem legacy tidak bisa menggunakan Web Identity Federation. Dalam kasus ini, IAM User dengan rotasi kunci yang ketat dan kebijakan IP restriction adalah kompromi yang dapat diterima.
• Tools CLI lokal untuk developer — akses dari laptop developer, bukan dari dalam infrastruktur AWS.

Untuk semua workload yang berjalan di dalam AWS — EC2, Lambda, ECS, EKS — IAM Role adalah satu-satunya pilihan yang dapat dipertahankan secara operasional.

Pengalaman Nyata: Misdiagnosis yang Umum Terjadi

Gejala: aplikasi di EC2 mendapat error AccessDenied saat memanggil S3, padahal Instance Profile sudah terlampir dan policy terlihat benar.

Diagnosis awal yang salah: hampir semua orang langsung memeriksa policy S3 — menambah permission, memperluas resource scope, bahkan mencoba s3:*. Tidak ada yang berubah. Error tetap sama.

Penyebab sebenarnya: di dalam instance, ada file ~/.aws/credentials yang ditinggalkan dari sesi debugging sebelumnya. File itu berisi access key IAM User lama yang sudah dinonaktifkan. SDK menemukan file itu di langkah kedua credential provider chain dan berhenti di sana — tidak pernah sampai ke IMDS. Semua perubahan policy pada Instance Role tidak berpengaruh sama sekali karena SDK tidak menggunakannya.

Perbaikan: hapus file ~/.aws/credentials dari instance, jalankan ulang aws sts get-caller-identity, dan konfirmasi ARN menunjuk ke assumed-role yang benar.

Pelajaran: sebelum debugging IAM policy, selalu verifikasi dulu identitas mana yang sedang digunakan SDK.

Perbedaan IAM User dan IAM Role: Ringkasan Keputusan

graph TD Q1{Apakah identitas ini
berjalan di dalam AWS?} -->|Ya| Q2{Layanan compute apa?} Q1 -->|Tidak| Q3{Pengguna manusia
atau automation?} Q2 -->|EC2 / ECS / Lambda| UseRole[Gunakan IAM Role
dengan Instance Profile
atau Execution Role] Q2 -->|Cross-account access| UseRole Q3 -->|Pengguna manusia| Q4{Ada Identity Provider
atau SSO?} Q3 -->|Automation / CI-CD| Q5{Mendukung OIDC?} Q4 -->|Ya| UseSSO[Gunakan IAM Identity Center] Q4 -->|Tidak| UseUser[IAM User dengan MFA] Q5 -->|Ya| UseOIDC[Web Identity Federation
bukan IAM User] Q5 -->|Tidak| UseUserCI[IAM User dengan
rotasi kunci ketat] style UseRole fill:#2e7d32,color:#fff style UseSSO fill:#1565c0,color:#fff style UseOIDC fill:#1565c0,color:#fff style UseUser fill:#f9a825,color:#000 style UseUserCI fill:#f9a825,color:#000

Langkah Selanjutnya dan Referensi

Setelah memahami perbedaan IAM User dan IAM Role, langkah berikutnya yang direkomendasikan adalah mengaudit semua IAM User yang saat ini digunakan oleh aplikasi dan workload di dalam AWS, lalu migrasi ke Instance Profile atau service role yang sesuai. Gunakan AWS IAM Access Analyzer untuk mengidentifikasi akses yang berlebihan dan memvalidasi policy sebelum deployment.

• AWS IAM Roles — Official Documentation
• Using Instance Profiles
• IAM Roles for Amazon EC2

Glosarium

Istilah	Definisi
IAM User	Entitas permanen di AWS dengan kredensial jangka panjang (access key). Mewakili manusia atau aplikasi dengan identitas tetap.
IAM Role	Identitas sementara yang dapat diasumsikan oleh entitas lain. Tidak memiliki kredensial permanen; menggunakan token STS.
Instance Profile	Container IAM yang menghubungkan satu IAM Role ke EC2 instance, memungkinkan instance mengambil kredensial sementara via IMDS.
STS (Security Token Service)	Layanan AWS yang menerbitkan kredensial sementara untuk entitas yang mengasumsikan IAM Role.
IMDS (Instance Metadata Service)	Endpoint internal EC2 (169.254.169.254) yang menyediakan metadata instance termasuk kredensial sementara dari Instance Profile.