Advanced Identity &
Multi-Account Access
Belajar memilih layanan identitas yang tepat untuk karyawan, aplikasi, mesin, dan banyak akun AWS.
Kenapa Identitas Lanjutan Penting?
Analogi gedung kantor, badge tamu, dan akses antar lantai.
Bayangkan AWS seperti gedung perkantoran besar dengan banyak lantai, ruang server, ruang arsip, dan pintu khusus staf.
Di gedung kecil, satu kunci mungkin cukup. Tetapi ketika perusahaan tumbuh, satu kunci untuk semua orang menjadi berbahaya. Resepsionis butuh daftar tamu, karyawan butuh badge sesuai divisi, vendor butuh akses sementara, pelanggan aplikasi tidak boleh masuk ruang staf, dan cabang kantor lain butuh cara meminjam fasilitas tanpa mengambil alih gedung.
Di AWS, pola itu diterjemahkan menjadi IAM Identity Center untuk akses karyawan, federation untuk memakai identitas perusahaan, AWS STS untuk kredensial sementara, Amazon Cognito untuk pengguna aplikasi, Directory Service untuk Active Directory, cross-account access untuk berpindah akun secara aman, AWS RAM untuk berbagi resource, dan AWS Organizations untuk mengelola banyak akun sebagai satu lingkungan.
IAM user seperti kunci permanen di satu ruangan, IAM role seperti badge sementara, IAM Identity Center seperti meja resepsionis pusat untuk semua lantai, dan Cognito seperti loket login pelanggan aplikasi.
Menurut daftar layanan in-scope CLF-C02 dari AWS, topik identity, security, governance, Organizations, IAM Identity Center, Cognito, Directory Service, STS, dan RAM berada dalam area yang perlu dikenali kandidat. Modul ini tidak sedalam ujian Solutions Architect, tetapi kamu harus bisa memilih layanan yang benar dalam skenario singkat.
Tiga Jenis Identitas di AWS
Sebelum memilih layanan, kenali siapa yang sedang meminta akses.
Kesalahan pemula biasanya dimulai dari satu pertanyaan yang tidak dijawab, siapa identitasnya?
Di AWS, identitas bukan hanya orang. Identitas bisa manusia internal, pengguna aplikasi, atau mesin. Setiap jenis punya layanan dan pola akses yang berbeda.
Workforce user
Karyawan, admin, developer, auditor, atau partner internal yang perlu masuk ke AWS Console, CLI, aplikasi AWS, atau beberapa akun AWS.
Application user
Pelanggan aplikasi web atau mobile yang login ke aplikasi, misalnya pembeli online shop, pengguna SaaS, atau member komunitas.
Machine identity
Workload, CI/CD pipeline, Lambda, EC2, container, atau aplikasi eksternal yang perlu memanggil AWS API tanpa manusia mengetik password.
Definisi praktisnya sederhana. Authentication menjawab “siapa kamu?”, authorization menjawab “boleh melakukan apa?”, dan federation menjawab “bolehkah AWS mempercayai identitas dari sistem lain?”.
Untuk karyawan gunakan IAM Identity Center, untuk pelanggan aplikasi gunakan Cognito, untuk mesin gunakan role dan kredensial sementara.
Tiga layanan yang paling sering tertukar di ujian adalah IAM, IAM Identity Center, dan Cognito. Ketiganya bicara soal akses, tetapi melayani aktor yang berbeda dan punya cakupan yang berbeda. Sebelum hafal fiturnya, kunci dulu satu pembeda inti, siapa yang login dan ke mana.
- Aktornya karyawan internal: developer, finance, security, auditor, partner.
- Memberi akses ke AWS account dan aplikasi bisnis lewat satu portal SSO.
- Kata kunci soal: “employees across multiple AWS accounts”, “centralized workforce access”.
- Sesi memakai kredensial sementara, bukan password AWS permanen per akun.
- Aktornya pengguna aplikasimu: pelanggan, member, siswa, pengguna SaaS.
- Menyediakan sign-up, sign-in, dan token untuk aplikasi web atau mobile.
- Kata kunci soal: “customer identity”, “mobile/web app users”, “sign-up/sign-in for my app”.
- Ini ranah CIAM (customer identity), bukan akses admin ke akun AWS.
Kapan memakai apa?
| Kebutuhan | Pilihan utama | Kenapa |
|---|---|---|
| Karyawan masuk ke banyak akun AWS | IAM Identity Center | Akses terpusat, single sign-on, permission set, cocok dengan AWS Organizations. |
| Perusahaan sudah punya Okta, Microsoft Entra ID, atau AD | Federation ke IAM Identity Center | User tetap dikelola di IdP perusahaan, AWS memberi akses berdasarkan assignment. |
| Aplikasi mobile butuh sign-up dan sign-in | Amazon Cognito user pool | Cognito menyediakan direktori pengguna aplikasi dan token untuk aplikasi. |
| Pengguna aplikasi perlu akses terbatas ke AWS resource | Amazon Cognito identity pool | Identity pool dapat memberikan temporary AWS credentials melalui role. |
| CI/CD dari luar AWS perlu deploy | IAM role dengan federation OIDC atau STS | Menghindari access key permanen di pipeline. |
| Akun A perlu mengakses resource Akun B | Cross-account IAM role atau resource-based policy | Akses lintas akun dikendalikan melalui trust dan permission. |
| Resource perlu dipakai banyak akun | AWS RAM | Share resource yang didukung tanpa menggandakan resource. |
IAM Identity Center untuk Workforce
Pusat akses untuk manusia internal di banyak akun dan aplikasi.
IAM Identity Center adalah “resepsionis pusat” yang mengatur siapa boleh masuk ke akun dan aplikasi mana.
AWS IAM Identity Center (nama lama: AWS Single Sign-On, diganti nama pada Juli 2022) menyediakan satu tempat untuk mengelola akses workforce user ke banyak AWS account dan aplikasi. Dalam pola multi-account modern, pengguna masuk ke AWS access portal, memilih akun, memilih permission set, lalu mendapatkan sesi akses sementara untuk bekerja. Namespace API lamanya (sso dan identitystore) tetap dipakai agar tidak merusak otomasi yang sudah ada, jadi jangan kaget bila masih melihat nama itu di dokumentasi teknis.
Komponen utamanya adalah identity source, users and groups, permission sets, account assignments, dan AWS access portal. Identity source bisa direktori bawaan IAM Identity Center, external identity provider seperti Okta atau Microsoft Entra ID, atau Active Directory melalui AWS Directory Service.
IAM Identity Center bukan pengganti Cognito untuk pelanggan aplikasi, dan bukan sekadar IAM user massal. Fokusnya adalah workforce access. Mengaktifkannya tidak menambah biaya, kamu hanya membayar resource AWS yang dipakai di baliknya.
Kenapa tidak cukup pakai IAM user saja?
Bayangkan perusahaan dengan 200 karyawan dan 15 akun AWS. Tanpa Identity Center, kamu harus membuat IAM user di tiap akun, lalu mengelola 200 dikali 15 kombinasi password, rotasi, dan offboarding. Saat satu orang resign, kamu harus berburu akunnya di 15 tempat. Identity Center memindahkan daftar orang ke satu sumber, lalu menempelkan permission set ke akun yang relevan. Resign cukup dimatikan di satu tempat, dan akses ke semua akun otomatis hilang. Inilah alasan AWS merekomendasikannya sebagai jalur utama untuk akses manusia di lingkungan multi-account.
Ada dua jenis instance. Organization instance (disarankan) butuh AWS Organizations dan mengelola akses ke semua akun member dari satu titik. Account instance bercakupan satu akun, biasanya untuk memberi akses ke aplikasi tertentu. Untuk skenario multi-account klasik, jawabannya selalu organization instance.
Permission set dengan analogi seragam kerja
Permission set mirip seragam kerja. Seragam “ReadOnly” hanya boleh melihat, seragam “Developer” boleh mengelola resource tertentu, dan seragam “Billing” fokus ke biaya. Saat permission set di-assign ke akun, IAM Identity Center memprovision IAM role di akun tersebut dan menempelkan kebijakan yang sesuai.
Identity source
Tempat user dan group berasal, bisa Identity Center directory, external IdP, atau Active Directory.
Permission set
Paket izin yang bisa diassign ke user atau group pada akun AWS tertentu.
Account assignment
Hubungan antara user atau group, permission set, dan akun AWS target.
AWS access portal
Portal tempat user memilih akun, role, dan aplikasi yang sudah diberikan kepadanya.
Kapan Identity Center dipakai?
Gunakan IAM Identity Center ketika organisasi punya banyak akun AWS, banyak tim, kebutuhan single sign-on, rotasi akses, atau ingin menghindari pembuatan IAM user untuk setiap karyawan di setiap akun. Untuk CLF-C02, jawaban “centralized access for workforce users across multiple AWS accounts” sangat kuat mengarah ke IAM Identity Center.
Federation, SAML, OIDC, dan SCIM
Cara AWS mempercayai identitas dari luar AWS tanpa menyalin semua password.
Federation seperti hotel yang menerima kartu identitas resmi dari perusahaan, bukan membuat KTP baru untuk setiap tamu.
Federation berarti AWS mempercayai identitas dari identity provider eksternal. Pengguna tidak harus punya password terpisah di AWS. Mereka login di IdP perusahaan, lalu AWS memberikan akses berdasarkan trust dan assignment yang sudah dikonfigurasi.
SAML 2.0
Umum untuk single sign-on enterprise berbasis browser, misalnya akses karyawan dari IdP perusahaan ke AWS access portal.
OIDC
Umum untuk aplikasi modern dan workload eksternal, misalnya CI/CD pipeline yang menukar token OIDC dengan role AWS.
SCIM
Bukan protokol login. SCIM membantu provisioning dan sinkronisasi user atau group dari IdP ke IAM Identity Center.
SAML dan OIDC membantu proses federated authentication, sedangkan SCIM membantu provisioning identitas agar user dan group dikenal oleh IAM Identity Center.
Federation dengan IAM Identity Center vs IAM langsung
AWS merekomendasikan IAM Identity Center untuk manajemen akses manusia secara terpusat pada banyak akun dalam AWS Organizations. Federation IAM langsung masih bisa dipakai untuk skenario tertentu, misalnya akun tunggal, deployment skala kecil, atau machine identity yang memakai OIDC. Untuk ujian, perhatikan kata kunci “multiple AWS accounts”, “centralized workforce access”, dan “corporate IdP”.
Kenapa federation lebih aman daripada IAM user permanen?
Dengan federation, organisasi tidak perlu mendistribusikan access key jangka panjang kepada manusia. Akses bisa dikendalikan dari IdP pusat, user yang resign bisa dinonaktifkan di satu tempat, dan sesi AWS biasanya berbasis kredensial sementara.
STS, Role, dan Kredensial Sementara
Kunci sementara lebih aman daripada kunci permanen.
AWS STS seperti mesin pembuat badge sementara, badge punya masa berlaku dan hanya membuka pintu tertentu.
AWS Security Token Service (AWS STS) menerbitkan temporary security credentials. Kredensial sementara bekerja mirip access key, tetapi punya masa berlaku dan menyertakan session token. Pola ini lebih aman daripada menyimpan access key jangka panjang di laptop, server, atau pipeline.
IAM role bukan user dan tidak punya password permanen. Role memiliki dua sisi penting. Trust policy menjawab siapa boleh mengambil role ini, sedangkan permissions policy menjawab apa yang boleh dilakukan setelah role berhasil diasumsikan.
Trust policy
Daftar pihak yang dipercaya untuk assume role, misalnya akun lain, layanan AWS, atau IdP federasi.
Permissions policy
Izin kerja saat role sudah dipakai, misalnya membaca objek S3, menulis log, atau deploy resource tertentu.
Trust policy adalah “siapa boleh memakai badge”, permissions policy adalah “badge ini membuka pintu apa”.
STS adalah mesin di balik AssumeRole dan federation, tetapi STS tidak muncul sebagai nama layanan tersendiri di daftar in-scope CLF-C02, ia hadir sebagai konsep di bawah IAM. Cukup kenali idenya, “temporary security credentials = STS”, tanpa menghafal detail API.
Contoh pemakaian role dan STS
Aplikasi di EC2 butuh membaca S3, berikan IAM role ke instance, bukan access key di file konfigurasi. Lambda butuh menulis CloudWatch Logs, berikan execution role. Developer dari akun pusat butuh memeriksa akun produksi, gunakan cross-account role dengan sesi sementara. Pipeline GitHub Actions butuh deploy ke AWS, gunakan OIDC federation ke IAM role, bukan access key statis di secret repository.
Cross-Account Access
Mengakses akun lain tanpa membagikan password akun itu.
Cross-account access seperti cabang Jakarta meminjam ruang rapat cabang Bandung dengan surat izin, bukan meminta kunci master cabang Bandung.
Dalam arsitektur multi-account, kamu sering memisahkan akun berdasarkan lingkungan atau fungsi, misalnya shared-services, security, dev, test, dan prod. Agar tim pusat bisa bekerja lintas akun, AWS menyediakan pola cross-account access dengan IAM role, resource-based policy, atau AWS RAM untuk resource tertentu.
Alur cross-account role
User, role, atau pipeline di Account A harus diizinkan memanggil sts:AssumeRole ke role target.
Trust policy di Account B harus menyebut principal dari Account A sebagai pihak yang boleh assume role.
Jika kedua sisi cocok, STS mengembalikan temporary credentials untuk sesi role di Account B.
Setelah masuk, aksi yang boleh dilakukan tetap dibatasi oleh permissions policy role, resource policy, dan guardrail organisasi.
Jika soal menyebut akun A harus mengakses akun B secara aman tanpa membuat IAM user di akun B, cari jawaban IAM role dengan trust policy dan STS AssumeRole.
Resource-based policy vs role proxy
Beberapa layanan mendukung resource-based policy, misalnya bucket policy di S3. Resource policy menyatakan langsung principal mana yang boleh mengakses resource. Jika resource tidak mendukung resource-based policy, pola umum adalah memakai IAM role sebagai “proxy” di akun target.
Amazon Cognito untuk Pengguna Aplikasi
Jangan pakai IAM Identity Center untuk pelanggan aplikasi publik.
Cognito adalah loket login untuk pengguna aplikasi, bukan meja admin AWS untuk karyawan.
Amazon Cognito membantu developer menambahkan sign-up, sign-in, dan kontrol akses untuk aplikasi web atau mobile. Cognito sering muncul di soal CLF-C02 ketika ada kata kunci pelanggan, user aplikasi, mobile app, web app, social login, atau user directory untuk aplikasi.
User pool
Direktori pengguna aplikasi. Cocok untuk login, sign-up, MFA aplikasi, federasi social atau enterprise, dan token JWT untuk app atau API.
Identity pool
Menukar identitas pengguna aplikasi menjadi temporary AWS credentials, sehingga app bisa mengakses resource AWS secara terbatas melalui role.
User pool menjawab “pengguna login ke aplikasi”, identity pool menjawab “pengguna aplikasi mendapat AWS credentials terbatas”.
Urutan dua komponen ini yang sering dibalik peserta. Pengguna login dulu ke user pool dan mendapat token JWT. Kalau aplikasi cuma butuh tahu “ini siapa” dan menyimpan data lewat backend sendiri, user pool saja sudah cukup. Identity pool baru dipakai ketika aplikasi perlu memanggil AWS secara langsung dari sisi klien, misalnya upload langsung ke S3, lalu token tadi ditukar menjadi kredensial AWS sementara yang dipetakan ke IAM role.
- Direktori dan mesin login: sign-up, sign-in, MFA, reset password.
- Keluarannya token JWT untuk aplikasi atau API milikmu.
- Mendukung social login (Google, Apple) dan federasi enterprise (SAML, OIDC).
- Kata kunci: “user directory for my app”, “let customers sign in”.
- Menukar identitas terverifikasi menjadi temporary AWS credentials.
- Kredensial dibatasi oleh IAM role, jadi tiap pengguna hanya menyentuh bagiannya.
- Dipakai saat aplikasi mengakses S3, DynamoDB, atau layanan AWS lain langsung.
- Kata kunci: “upload to S3 directly from the app per user”, “grant AWS access”.
Halaman login bawaan Cognito kini disebut Managed Login (penerus Hosted UI), dengan branding tanpa kode serta opsi passkey dan passwordless. Cognito juga punya feature tier baru (Lite, Essentials, Plus). Detail harga tidak diuji, tetapi istilah “Managed Login” adalah terminologi terkini yang mungkin kamu temui.
Skenario nyata
Online shop skincare punya pelanggan yang membuat akun, login dengan email, dan melihat riwayat pesanan. Ini cocok dengan Cognito user pool. Jika aplikasi mobile perlu upload foto profil langsung ke S3 dengan izin terbatas per user, identity pool bisa memberikan kredensial sementara yang dipetakan ke role khusus.
Bedakan dari IAM Identity Center
IAM Identity Center melayani workforce user seperti developer, finance, security, dan auditor. Cognito melayani application user seperti pelanggan, member, siswa, atau pengguna SaaS. Jika soal menyebut “customer identity and access management” atau “mobile and web app users”, arahkan ke Cognito.
AWS Directory Service dan Active Directory
Saat organisasi sudah hidup dengan Microsoft AD.
Directory Service seperti jembatan antara buku telepon perusahaan lama dan gedung cloud AWS.
AWS Directory Service membantu menjalankan atau menghubungkan direktori Microsoft Active Directory dengan AWS. Ini relevan ketika perusahaan punya Windows workload, kebijakan domain, user AD, atau ingin memakai kredensial perusahaan yang sudah ada untuk aplikasi dan layanan AWS tertentu.
AWS Managed Microsoft AD
Microsoft AD asli yang terkelola di AWS, cocok saat butuh fitur AD nyata seperti trust, group policy, dan schema extension untuk workload Windows dan integrasi enterprise.
AD Connector
Gateway atau proxy yang meneruskan permintaan ke Active Directory on-premises, tanpa menyimpan direktori apa pun di AWS. Cocok bila AD tetap ingin dikelola di kantor.
Simple AD
Direktori mandiri berbasis Samba dengan subset fitur AD, cocok untuk kebutuhan sederhana, bukan untuk semua fitur Microsoft AD penuh.
- Microsoft AD sungguhan yang berjalan dan disimpan di AWS.
- Mendukung trust ke domain lain, group policy, dan schema extension.
- Pilih saat butuh fitur AD penuh atau saat tidak ada AD on-premises.
- Kini punya edisi Standard, Enterprise, dan Hybrid Edition (memperluas forest on-prem ke AWS).
- Tidak menyimpan direktori di AWS, hanya meneruskan ke AD on-premises.
- Sumber kebenaran tetap AD di kantor; AWS sekadar pintu masuk.
- Pilih saat AD harus tetap dikelola on-prem dan kamu hanya ingin menyambungkannya ke AWS.
- Jika koneksi ke on-prem putus, layanan AWS yang bergantung padanya ikut terganggu.
IAM Identity Center dapat menggunakan Active Directory sebagai identity source melalui Directory Service. Artinya user dan group tetap berasal dari AD, lalu assignment ke AWS account atau aplikasi dikelola di IAM Identity Center.
Untuk Cloud Practitioner, fokus pada “Directory Service menghubungkan atau menjalankan Microsoft AD di AWS”, bukan detail domain controller tingkat admin.
Kapan Directory Service dipilih?
Pilih Directory Service jika soal menyebut Microsoft Active Directory, domain join, Windows workload, kredensial AD, atau integrasi direktori perusahaan. Jangan memilih Cognito untuk login karyawan Windows domain, dan jangan memilih IAM user untuk menggantikan direktori perusahaan yang sudah ada.
Organizations, SCP, RCP, dan AWS RAM
Multi-account bukan hanya banyak akun, tetapi pola tata kelola.
AWS Organizations adalah peta gedung, SCP dan RCP adalah pagar maksimum, dan RAM adalah cara berbagi fasilitas antar ruangan.
AWS Organizations membantu mengelola banyak akun AWS secara terpusat. Kamu bisa mengelompokkan akun ke dalam Organizational Unit (OU), memakai consolidated billing, mengatur guardrail dengan Service Control Policy (SCP) dan Resource Control Policy (RCP), dan mengintegrasikan layanan seperti IAM Identity Center dan AWS RAM.
Bayangkan ruangan dengan plafon dan lantai. SCP adalah plafon: tinggi maksimum yang boleh kamu capai. IAM policy adalah lantai yang kamu bangun: izin yang benar-benar diberikan. Kamu hanya bisa berdiri di area yang plafon dan lantai sama-sama izinkan. Plafon sendiri tidak pernah menambah ruang gerak, ia hanya membatasi.
SCP bukan pemberi izin
SCP adalah guardrail maksimum. SCP tidak memberi izin. Izin tetap harus diberikan oleh identity-based policy atau resource-based policy. Jika IAM policy mengizinkan ec2:*, tetapi SCP memblokir EC2 di OU tersebut, user tetap tidak bisa menjalankan EC2. Bahkan AdministratorAccess di sebuah member account tetap terblokir bila SCP melarang aksinya.
”SCPs do not grant permissions” adalah konsep wajib. SCP hanya membatasi maksimum izin pada akun member dalam organisasi.
Dua batasan SCP yang sering jadi jebakan
Ada dua hal yang sering keliru dipahami soal SCP. Pertama, SCP tidak berlaku untuk management account, hanya untuk akun member. Jadi jawaban “pasang SCP untuk mengunci management account” adalah perangkap, itu tidak bekerja. Inilah salah satu alasan kuat kenapa kamu tidak menaruh workload biasa di management account. Kedua, SCP butuh AWS Organizations dalam mode all features, ia tidak tersedia bila organisasi hanya memakai fitur consolidated billing saja. SCP juga tidak membatasi service-linked role.
Tidak menyentuh management account
SCP hanya mengikat akun member. Management account kebal dari SCP, jadi jangan andalkan SCP untuk mengamankannya.
Butuh mode all features
SCP hanya aktif bila Organizations memakai all features, bukan mode consolidated billing only.
RCP, pagar di sisi resource
Sejak November 2024, AWS menambahkan Resource Control Policy (RCP) sebagai tipe kebijakan otorisasi baru di Organizations. Kalau SCP membatasi apa yang boleh dilakukan oleh principal (user dan role), RCP membatasi apa yang boleh dilakukan terhadap resource. RCP adalah pagar data perimeter, awalnya mendukung S3, STS, SQS, KMS, dan Secrets Manager. Sama seperti SCP, RCP tidak memberi izin, ia hanya menyempitkan. Keduanya guardrail, bukan pemberi akses, dan tidak ada biaya tambahan.
- Membatasi maksimum izin user dan role di akun member.
- Menjawab “principal ini paling jauh boleh apa?”.
- Tidak berlaku untuk management account dan service-linked role.
- Butuh mode all features di Organizations.
- Membatasi siapa pun yang mencoba mengakses resource tertentu.
- Menjawab “resource ini paling jauh boleh diakses oleh siapa dan bagaimana?”.
- Awalnya untuk S3, STS, SQS, KMS, dan Secrets Manager.
- Bagian dari pola data perimeter, melengkapi SCP.
AWS RAM untuk berbagi resource
AWS Resource Access Manager (AWS RAM) membantu share resource yang didukung ke akun lain, OU, atau seluruh organization, dan untuk sebagian tipe resource juga ke IAM role atau user tertentu. Contohnya, tim network dapat membuat subnet VPC, Transit Gateway, atau Route 53 Resolver rule di akun pusat, lalu membuatnya bisa dipakai oleh akun aplikasi tanpa menggandakan resource. RAM gratis dipakai, kamu hanya membayar resource yang dibagikan. RAM bukan alat untuk login lintas akun dan bukan cara berbagi semua jenis resource secara bebas.
RAM berbagi resource (mis. subnet, Transit Gateway), bukan memberi seseorang kemampuan masuk ke akun lain dan bukan alat billing. Kalau soal bilang “share a subnet across accounts without duplicating”, jawabannya RAM.
Organizations
Mengelompokkan akun, mengelola billing, menerapkan kebijakan organisasi, dan menjadi fondasi multi-account governance.
SCP & RCP
Guardrail maksimum. SCP membatasi principal, RCP membatasi resource. Keduanya tidak memberikan izin langsung.
AWS RAM
Berbagi resource yang didukung dengan account, OU, organization, atau principal tertentu jika resource mendukung.
Identity Center
Mengatur user dan group mana yang mendapat permission set di akun tertentu.
Control Tower dan Consolidated Billing
Dari plumbing manual menuju landing zone yang sudah tertata.
Jika Organizations adalah rangka dan pipa gedung, Control Tower adalah kontraktor yang langsung menyerahkan gedung siap huni dengan satpam dan CCTV terpasang.
Membangun multi-account yang aman dengan Organizations saja butuh banyak keputusan manual: bikin OU, atur SCP, siapkan akun untuk log, akun untuk audit, lalu sambungkan semuanya. AWS Control Tower mengotomasi semua itu menjadi sebuah landing zone, yaitu lingkungan multi-account yang sudah tertata mengikuti praktik baik AWS sejak menit pertama.
Saat diaktifkan, Control Tower menyiapkan management account dengan consolidated billing, lalu membuat dua akun khusus: Log Archive untuk menampung log secara terpusat dan Audit untuk akses keamanan lintas akun. Di atasnya, Control Tower menerapkan controls atau guardrails: preventif (mencegah aksi, biasanya lewat SCP), detektif (mendeteksi pelanggaran), dan proaktif (menolak resource yang tidak patuh sebelum dibuat). Control Tower sendiri tidak memungut biaya terpisah, kamu hanya membayar layanan yang ia jalankan di baliknya.
- Fondasi multi-account: akun, OU, consolidated billing, SCP, RCP.
- Fleksibel tetapi banyak langkah manual untuk merakit struktur yang baik.
- Kata kunci: “single bill”, “group accounts”, “apply SCP”.
- Kamu sendiri yang mendesain landing zone di atasnya.
- Wrapper opinionated yang berdiri di atas Organizations.
- Otomatis membuat Log Archive, Audit, OU, dan controls sekaligus.
- Kata kunci: “quickly set up a governed, well-architected multi-account environment”.
- Cepat siap pakai, tetapi mengikuti pola yang sudah ditentukan AWS.
Consolidated billing, satu tagihan untuk banyak akun
Salah satu manfaat paling konkret dari Organizations adalah consolidated billing. Semua akun member dibayar lewat satu tagihan di management account, jadi finance cukup melihat satu invoice, bukan belasan. Lebih dari sekadar kerapian, pemakaian semua akun digabung untuk menghitung volume discount, dan komitmen seperti Reserved Instances serta Savings Plans bisa dibagi lintas akun. Akun yang sepi memakai sisa komitmen akun yang sibuk, sehingga diskon tidak terbuang.
Pisahkan dua hal. “Single bill dan combined usage discounts” mengarah ke consolidated billing (Organizations). “Quickly set up a governed multi-account environment” mengarah ke Control Tower. SCP, OU, dan Control Tower urusan governance, bukan billing.
Walkthrough Konseptual
Latihan mental untuk membangun akses multi-account yang rapi.
Hands-on ini tidak wajib kamu jalankan sekarang, tetapi pahami urutannya seperti arsitek yang menggambar peta akses.
Kelompokkan akun menjadi shared-services, security, dev, test, dan prod, lalu tempatkan dalam OU yang masuk akal.
Gunakan organization instance agar akses ke banyak akun dapat dikelola dari satu tempat.
Gunakan Identity Center directory untuk lab sederhana, external IdP untuk perusahaan modern, atau Active Directory jika organisasi memakai AD.
Contoh group: Developers, SecurityAuditors, BillingViewers, dan NetworkAdmins.
Contoh permission set: ReadOnly, DeveloperPowerUser, BillingReadOnly, dan SecurityAudit.
Developers boleh DeveloperPowerUser di dev, tetapi hanya ReadOnly di prod. Auditor boleh SecurityAudit di semua akun.
Pipeline atau tooling pusat bisa assume role di akun target dengan trust policy yang jelas dan permission minimum.
Resource yang dikelola pusat, seperti network resource yang didukung, bisa dibagikan ke akun aplikasi tanpa menggandakan resource.
Gunakan CloudTrail dan layanan governance terkait untuk melihat siapa melakukan apa, dari akun mana, dan dengan role apa.
Desain yang baik membuat user masuk dari satu portal, mendapat izin sesuai tugas, memakai kredensial sementara, dan meninggalkan jejak audit.
Mini skenario
Tim developer ingin deploy ke akun dev, membaca log di akun prod, tetapi tidak boleh menghapus resource produksi. Solusi yang sehat adalah group Developers di IAM Identity Center, permission set lebih luas untuk akun dev, permission set read-only untuk akun prod, dan pipeline deploy memakai role terpisah dengan izin minimum.
Kesalahan Umum dan Jebakan Ujian
Bagian ini sengaja dibuat eksplisit karena soal CLF-C02 sering menukar istilah.
Banyak jawaban salah terasa benar karena semua berbicara tentang “akses”, padahal identitasnya berbeda.
IAM user untuk semua karyawan
Keliru untuk organisasi modern. Untuk workforce access terpusat, arahkan ke IAM Identity Center dan federation.
Cognito untuk admin AWS
Keliru. Cognito untuk pengguna aplikasi web atau mobile, bukan portal utama karyawan mengelola akun AWS.
STS dianggap database user
Keliru. STS menerbitkan temporary security credentials, bukan menyimpan direktori user.
SCIM dianggap protokol login
Keliru. SCIM untuk provisioning user dan group, sedangkan SAML atau OIDC dipakai untuk federated authentication.
SCP dianggap memberi izin
Keliru. SCP hanya guardrail maksimum, izin tetap berasal dari IAM policy atau resource policy.
SCP untuk mengunci management account
Keliru. SCP tidak berlaku untuk management account, hanya akun member. Lindungi management account dengan cara lain.
Control Tower sama dengan Organizations
Keliru. Organizations adalah fondasinya, Control Tower adalah wrapper otomatis yang membangun landing zone (Log Archive, Audit, controls) di atasnya.
Identity pool dipakai untuk login
Keliru. Login lewat user pool (token JWT), identity pool baru menukar identitas itu menjadi AWS credentials sementara.
Simple AD untuk fitur AD penuh
Keliru. Simple AD hanya subset fitur. Untuk trust dan schema extension, pilih AWS Managed Microsoft AD. AD Connector hanya proxy ke AD on-prem.
RAM dianggap akses login
Keliru. AWS RAM berbagi resource yang didukung, bukan memberi user kemampuan masuk ke akun lain.
”Employees across multiple AWS accounts” mengarah ke IAM Identity Center, “mobile app users” mengarah ke Cognito, “temporary credentials” mengarah ke STS, “share subnet across accounts” mengarah ke AWS RAM, “governed multi-account landing zone” mengarah ke Control Tower, “single bill and combined discounts” mengarah ke consolidated billing.
Sumber resmi untuk review
- AWS CLF-C02 in-scope services
- AWS IAM Identity Center User Guide
- IAM identity providers and federation
- Temporary security credentials in IAM
- Amazon Cognito Developer Guide
- AWS Directory Service Administration Guide
- AWS Resource Access Manager User Guide
- AWS Organizations SCP documentation
- AWS Organizations RCP documentation
- AWS Control Tower User Guide
Ringkasan & Tips Ujian
Peta hafalan cepat untuk CLF-C02.
Inti modul ini adalah memilih layanan identitas berdasarkan jenis pengguna dan konteks multi-account.
Poin Penting
- IAM mengelola identitas di dalam satu akun, IAM Identity Center mengelola akses workforce ke banyak akun, Cognito mengelola identitas pengguna aplikasi.
- IAM Identity Center adalah pilihan utama untuk workforce access terpusat (pakai organization instance) dan gratis diaktifkan.
- Federation membuat AWS mempercayai identitas dari IdP eksternal, misalnya SAML, OIDC, Active Directory, Okta, atau Microsoft Entra ID.
- SCIM membantu provisioning user dan group, bukan proses login.
- STS menerbitkan temporary security credentials, sering dipakai saat assume role dan federation (konsep di bawah IAM, bukan layanan in-scope terpisah).
- IAM role memiliki trust policy untuk siapa boleh assume dan permissions policy untuk apa yang boleh dilakukan.
- Cross-account access membutuhkan izin dari sisi pemanggil dan trust dari sisi target.
- Amazon Cognito cocok untuk pengguna aplikasi web atau mobile: user pool untuk login (JWT), identity pool untuk AWS credentials sementara.
- AWS Directory Service: Managed Microsoft AD (AD nyata), AD Connector (proxy ke on-prem), Simple AD (subset fitur).
- AWS Organizations mengatur banyak akun, OU, consolidated billing, dan guardrail seperti SCP dan RCP.
- SCP membatasi maksimum izin principal (tidak berlaku untuk management account, butuh mode all features), RCP membatasi akses ke resource. Keduanya tidak memberi izin.
- AWS Control Tower membangun landing zone otomatis (Log Archive, Audit, controls) di atas Organizations.
- Consolidated billing memberi satu tagihan plus volume discount dan sharing RI/Savings Plans lintas akun.
- AWS RAM membagikan resource yang didukung, bukan membagikan password atau akses login.
Pemetaan ke domain CLF-C02
Domain 2: Security & Compliance (30%)
Identity Center, federation, STS, role, cross-account trust, SCP, RCP, least privilege, dan kredensial sementara sangat relevan dengan keamanan akses. Ini domain utama modul.
Domain 3: Cloud Technology & Services (34%)
Cognito, Directory Service, RAM, Organizations, Control Tower, dan pola multi-account termasuk layanan inti yang harus bisa dikenali dari skenario.
Domain 1: Cloud Concepts (24%)
Multi-account membantu pemisahan lingkungan, isolasi risiko, dan governance yang lebih baik daripada satu akun untuk semua workload.
Domain 4: Billing, Pricing & Support (12%)
Consolidated billing memberi satu tagihan dan diskon gabungan lintas akun, sedangkan layanan governance seperti SCP dan Control Tower sendiri tidak memungut biaya terpisah.
Tips ujian super cepat
Jika aktornya karyawan, pikirkan IAM Identity Center. Jika aktornya pelanggan aplikasi, pikirkan Cognito. Jika aktornya workload, pikirkan role.
Temporary credentials, assume role, dan federated session hampir selalu melibatkan STS.
Akses manusia lintas banyak akun mengarah ke IAM Identity Center, sedangkan governance akun mengarah ke Organizations, SCP, dan Control Tower.
Jika soal ingin resource dipakai akun lain tanpa duplikasi, periksa AWS RAM atau resource-based policy, bukan membuat IAM user baru.
”Single bill dan combined discounts” berarti consolidated billing. “Governed landing zone” berarti Control Tower. Keduanya beda urusan.
Keduanya tidak pernah memberi izin. Jika semua policy mengizinkan tetapi SCP atau RCP melarang, aksi tetap ditolak. SCP juga tidak menyentuh management account.
Untuk CLF-C02, jangan hafal semua detail konfigurasi. Hafalkan peta keputusan layanan, siapa identitasnya, dari mana login berasal, apakah aksesnya permanen atau sementara, dan ingat guardrail hanya menyempitkan, tidak pernah memberi izin.