AWS Architecting,
Well-Architected & Ecosystem
Belajar memilih arsitektur AWS dengan cara pikir bisnis, risiko, dan trade-off, bukan sekadar menghafal diagram.
Kenapa Arsitektur Bukan Sekadar Diagram
Analogi: membangun rumah, bukan menggambar rumah.
Arsitektur cloud mirip merancang rumah, gambar denah penting, tetapi keputusan tentang fondasi, keamanan, ventilasi, biaya listrik, dan kemudahan perawatan jauh lebih menentukan.
Banyak pemula mengira arsitektur AWS berarti menghafal ikon layanan dan menggambar kotak panah. Untuk CLF-C02, sudut pandangnya berbeda. Kamu perlu memahami kenapa sebuah desain lebih aman, lebih andal, lebih hemat, lebih mudah dioperasikan, dan lebih berkelanjutan. AWS menyebut cara berpikir ini melalui AWS Well-Architected Framework, AWS Cloud Adoption Framework, dan sumber ekosistem seperti AWS Architecture Center, AWS Marketplace, AWS Prescriptive Guidance, dan AWS re:Post Knowledge Center.
Diagram adalah denah, Well-Architected adalah checklist kualitas bangunan, CAF adalah rencana organisasi pindah ke lingkungan baru, dan ekosistem AWS adalah toko material plus konsultan yang membantu proyek berjalan.
Modul ini sengaja bukan mini Solutions Architect. Kita tidak akan masuk terlalu dalam ke desain multi-tier, routing detail, atau tuning database. Fokusnya adalah bahasa bisnis dan prinsip memilih arsitektur: apa trade-off-nya, siapa yang bertanggung jawab, risiko apa yang dikurangi, dan sumber resmi mana yang harus dibaca ketika butuh panduan.
Untuk praktik
Kamu belajar menilai workload dengan pertanyaan sederhana: apa tujuan bisnisnya, risikonya apa, dan layanan mana yang paling cocok.
Untuk ujian
Kamu harus bisa membedakan pilar Well-Architected, CAF, Marketplace, APN, Prescriptive Guidance, whitepapers, re:Post, dan Knowledge Center.
Untuk komunikasi
Kamu belajar menjelaskan desain AWS kepada stakeholder non-teknis tanpa tenggelam dalam konfigurasi teknis.
Cara Berpikir Architecting di AWS
Mulai dari tujuan bisnis, lalu terjemahkan menjadi keputusan teknis.
Architecting adalah proses mengambil keputusan yang sadar trade-off, bukan mencari satu jawaban sempurna untuk semua kasus.
Di dunia nyata, pertanyaan arsitektur jarang berbunyi, “Layanan apa yang paling keren?” Pertanyaannya lebih sering seperti ini: aplikasi harus tetap tersedia saat traffic naik, data pelanggan harus aman, tim operasi kecil, biaya harus terkendali, dan perubahan harus bisa dirilis cepat. Architecting berarti menyusun pilihan layanan, konfigurasi, proses, dan tanggung jawab agar kebutuhan itu terpenuhi.
Tentukan apa yang harus terjadi, misalnya checkout tidak boleh sering gagal, audit harus mudah, atau biaya kampanye musiman harus elastis.
Terjemahkan kebutuhan menjadi keamanan, reliabilitas, performa, efisiensi biaya, operasi, dan sustainability.
Gunakan layanan managed bila ingin mengurangi beban operasi, gunakan serverless bila pola beban cocok, gunakan multi-AZ bila downtime harus ditekan.
Catat keputusan, alasan, risiko, dan rencana perbaikan agar arsitektur tidak hanya hidup di kepala satu orang.
Di AWS, desain yang baik biasanya mengurangi undifferentiated heavy lifting, meningkatkan otomasi, memakai managed service saat masuk akal, dan mengevaluasi risiko secara berkala.
Pertanyaan architecting yang ramah pemula
- Siapa pengguna dan seberapa kritis aplikasinya? Website profil perusahaan berbeda dari sistem pembayaran.
- Data apa yang disimpan? Data publik, data internal, data pelanggan, dan data sensitif punya kebutuhan kontrol berbeda.
- Apa pola traffic-nya? Stabil, musiman, naik mendadak, atau tidak terprediksi.
- Siapa yang mengoperasikan? Tim kecil biasanya diuntungkan oleh layanan managed dan otomasi.
- Apa batas biaya dan risiko? Hemat biaya bukan berarti memilih yang termurah, tetapi memilih yang paling efisien untuk kebutuhan.
Jika soal memakai kata seperti design principles, pillars, trade-offs, best practices, atau review architecture, pikirkan Well-Architected, bukan langsung lompat ke satu layanan spesifik.
Enam general design principles
Sebelum masuk ke enam pilar, Well-Architected punya enam general design principles: prinsip umum yang berlaku lintas pilar dan menjelaskan kenapa cara berpikir di cloud berbeda dari data center tradisional. Di data center lama, kamu membeli server besar di awal karena menambah kapasitas butuh berminggu-minggu. Di cloud, kapasitas datang dalam hitungan menit, jadi keputusan arsitektur bisa lebih berani, lebih sering diuji, dan lebih dipandu data.
Stop guessing capacity
Berhenti menebak kebutuhan kapasitas. Pakai scaling otomatis agar kapasitas mengikuti permintaan nyata, bukan tebakan saat membeli server.
Test at production scale
Uji sistem pada skala produksi. Di cloud kamu bisa membuat lingkungan uji seukuran produksi, lalu mematikannya setelah selesai, jadi biaya tetap rendah.
Automate for experimentation
Otomasi dengan eksperimen arsitektur dalam pikiran. Otomasi membuat percobaan, rollback, dan replikasi arsitektur murah dan mudah diulang.
Evolutionary architectures
Pertimbangkan arsitektur yang bisa berevolusi. Desain tidak perlu sempurna di awal, ia boleh berubah seiring kebutuhan dan teknologi baru.
Drive with data
Kendalikan arsitektur dengan data. Pakai metrik nyata untuk memilih instance, storage, atau pola desain, bukan asumsi.
Improve through game days
Tingkatkan lewat game days. Latih skenario kegagalan secara terjadwal agar tim dan sistem terbukti siap sebelum insiden sungguhan.
Game day mirip simulasi kebakaran di gedung kantor. Kamu sengaja membunyikan alarm pada waktu terjadwal supaya semua orang tahu jalur evakuasi sebelum ada api sungguhan, bukan menunggu kebakaran asli untuk belajar.
AWS Well-Architected Framework
Kerangka evaluasi kualitas workload di cloud.
AWS Well-Architected Framework adalah cara konsisten untuk mengevaluasi apakah sebuah workload selaras dengan praktik terbaik cloud.
Menurut dokumentasi AWS, framework ini membantu memahami pro dan kontra dari keputusan saat membangun sistem di AWS, serta menyediakan cara untuk mengukur arsitektur terhadap praktik terbaik dan menemukan area perbaikan. Kata pentingnya adalah conversation, bukan audit. Review Well-Architected seharusnya menjadi diskusi konstruktif tentang keputusan arsitektur, bukan sidang mencari kesalahan.
Well-Architected seperti pemeriksaan kesehatan rutin. Tujuannya bukan mempermalukan pasien, tetapi menemukan risiko sebelum menjadi insiden besar.
Istilah penting
Workload
Satu set komponen yang menghasilkan nilai bisnis, misalnya backend mobile app, ecommerce, data platform, atau portal internal.
Lens
Kumpulan pertanyaan dan praktik terbaik untuk menilai workload dari perspektif tertentu, termasuk AWS Well-Architected Framework lens sebagai lens default.
Milestone
Catatan kondisi arsitektur pada titik tertentu, misalnya desain awal, testing, go live, atau setelah perbaikan besar.
HRI dan MRI
High risk issue adalah pilihan yang bisa berdampak negatif besar pada bisnis; medium risk issue serupa tetapi dampaknya lebih kecil dari HRI.
Konsep lens lebih dalam
Lens adalah ide penting yang sering muncul di soal. Lens default adalah AWS Well-Architected Framework lens yang berlaku untuk hampir semua workload. Selain itu, ada lens khusus untuk teknologi tertentu seperti Serverless, SaaS, Machine Learning, dan Generative AI, ditambah lens Responsible AI yang baru diperkenalkan pada re:Invent akhir 2025. Kamu juga bisa membuat custom lens untuk standar internal organisasi. Bila sebuah soal menyebut menyesuaikan review untuk teknologi spesifik, jawabannya adalah memakai lens khusus atau custom lens, bukan menulis ulang framework.
Memakai AWS Well-Architected Tool dan mendokumentasikan review tidak dikenakan biaya. Yang tetap berbiaya hanyalah resource AWS yang kamu provisioning untuk memperbaiki workload (misalnya menambah instance atau Multi-AZ).
Well-Architected bukan garansi aplikasi pasti tidak pernah gagal. Ia membantu menemukan risiko dan memperbaiki keputusan, tetapi implementasi tetap tanggung jawab tim.
Pada April 2025 AWS menyegarkan seratus persen praktik di setiap pilar dengan sekitar 78 best practice baru atau diperbarui, dan Pillar Reliability mendapat 14 pembaruan untuk pertama kali sejak siklus 2022. Nama enam pilar tetap sama, jadi yang berubah adalah isi praktiknya, bukan strukturnya.
Untuk CLF-C02, hafalkan nama enam pilar dan bedakan fokusnya. Kamu tidak perlu menghafal semua pertanyaan detail dari setiap pilar, tetapi harus paham contoh situasi: monitoring masuk operational excellence, least privilege masuk security, backup dan multi-AZ masuk reliability, rightsizing masuk cost optimization, pemilihan resource sesuai beban masuk performance efficiency, dan pengurangan resource idle masuk sustainability.
Enam Pilar Well-Architected
Enam sudut pandang untuk menilai kualitas sistem.
Enam pilar Well-Architected adalah operational excellence, security, reliability, performance efficiency, cost optimization, dan sustainability.
Operational Excellence
Fokus pada menjalankan, memonitor, mengotomasi, belajar dari insiden, dan memperbaiki proses. Contoh: CloudWatch alarm, runbook, deployment otomatis, dan post-incident review.
Security
Fokus pada perlindungan data, sistem, identitas, deteksi, respons, dan kontrol akses. Contoh: IAM least privilege, MFA, encryption, logging, GuardDuty, dan AWS Artifact.
Reliability
Fokus pada kemampuan workload pulih dari gangguan dan memenuhi kebutuhan ketersediaan. Contoh: backup, multi-AZ, Auto Scaling, health checks, dan disaster recovery.
Performance Efficiency
Fokus pada penggunaan resource yang tepat untuk kebutuhan saat ini dan saat berubah. Contoh: memilih EC2, Lambda, S3, DynamoDB, CloudFront, atau managed database sesuai pola beban.
Cost Optimization
Fokus pada mendapatkan nilai bisnis maksimum dengan biaya minimum yang masuk akal. Contoh: rightsizing, Savings Plans, Reserved Instances, Budgets, Cost Explorer, dan mematikan resource idle.
Sustainability
Fokus pada mengurangi dampak lingkungan dari workload cloud. Contoh: menghapus resource tidak terpakai, meningkatkan utilisasi, memilih managed service, dan menyesuaikan kapasitas dengan kebutuhan.
Soal sering memberi skenario yang mirip. Backup untuk pemulihan biasanya reliability, encryption dan IAM biasanya security, rightsizing biasanya cost optimization, dan monitoring operasi harian biasanya operational excellence.
Pertanyaan kunci dan trade-off tiap pilar
Topik ini bukan hanya soal nama pilar. Tiap pilar sebenarnya adalah satu pertanyaan yang harus kamu tanyakan ke arsitektur, dan setiap jawaban punya trade-off. Memahami trade-off inilah inti architecting, karena memaksimalkan satu pilar sering menekan pilar lain. Tabel ini membantu kamu berpikir seperti reviewer Well-Architected.
| Pilar | Pertanyaan kunci yang ia tanyakan | Trade-off yang harus disadari |
|---|---|---|
| Operational Excellence | Bagaimana kita menjalankan, memantau, dan terus memperbaiki workload setiap hari? | Otomasi dan observability butuh waktu serta usaha di awal sebelum hasilnya terasa. |
| Security | Bagaimana kita melindungi data, identitas, dan sistem dari ancaman? | Kontrol ketat (least privilege, enkripsi, approval) bisa memperlambat kecepatan tim bila berlebihan. |
| Reliability | Bagaimana workload pulih dari kegagalan dan memenuhi target ketersediaan? | Redundansi multi-AZ, backup, dan DR menambah biaya (bertabrakan dengan cost optimization). |
| Performance Efficiency | Apakah kita memakai resource yang tepat dan seefisien mungkin untuk beban ini? | Resource paling cepat sering paling mahal dan paling boros energi (menekan cost dan sustainability). |
| Cost Optimization | Apakah kita mendapat nilai bisnis maksimum dengan biaya yang wajar? | Memangkas biaya terlalu agresif bisa mengorbankan reliability dan performa. |
| Sustainability | Bagaimana kita meminimalkan dampak lingkungan dari workload? | Mengejar utilisasi maksimum bisa mengurangi headroom yang dibutuhkan reliability saat lonjakan. |
Arsitektur yang baik bukan yang menang di satu pilar, tetapi yang sengaja memilih keseimbangan sesuai kebutuhan bisnis. Reliability lawan cost, performa lawan sustainability, security lawan kecepatan, semuanya keputusan sadar, bukan kebetulan.
Dari gejala ke pilar
Cara tercepat menjawab soal pilar adalah membaca gejala lalu memetakannya ke satu pilar yang paling langsung terdampak. Gambar berikut melatih refleks itu dengan enam gejala konkret.
- Pertanyaannya: apakah sistem tetap hidup dan bisa pulih saat ada gangguan?
- Alat khasnya: multi-AZ, backup teruji, health check, Auto Scaling untuk ketersediaan, dan disaster recovery.
- Kata kunci soal: availability, recover, failover, backup, fault tolerance.
- Pertanyaannya: apakah kita memakai jenis dan ukuran resource yang paling pas untuk beban?
- Alat khasnya: pemilihan instance type, serverless, caching, dan database sesuai pola akses.
- Kata kunci soal: right resource, instance type, latency, throughput, scale efficiently.
- Tujuan akhirnya: nilai bisnis maksimum dengan rupiah seminimal mungkin.
- Alat khasnya: rightsizing, Savings Plans, Reserved Instances, Budgets, Cost Explorer.
- Kata kunci soal: bill, spend, price, lowest cost, budget.
- Tujuan akhirnya: jejak karbon dan pemborosan resource sekecil mungkin.
- Alat khasnya: maksimalkan utilisasi, pilih managed service dan region efisien, hapus resource idle.
- Kata kunci soal: environmental, carbon, ESG, energy, sustainability.
Keduanya sama-sama suka mematikan resource idle, jadi mudah tertukar. Pegang kata kuncinya: bila soal berbicara tentang uang, tagihan, atau harga, jawab cost optimization. Bila berbicara tentang lingkungan, karbon, atau ESG, jawab sustainability.
Cara cepat membedakan pilar
- Operational Excellence: bagaimana tim menjalankan dan memperbaiki sistem setiap hari.
- Security: siapa boleh mengakses apa, bagaimana data dilindungi, dan bagaimana ancaman dideteksi.
- Reliability: bagaimana sistem bertahan dan pulih saat terjadi kegagalan.
- Performance Efficiency: apakah resource yang dipilih cocok untuk beban kerja.
- Cost Optimization: apakah biaya sepadan dengan nilai bisnis.
- Sustainability: apakah sistem mengurangi pemborosan resource dan dampak lingkungan.
Pikirkan rumah: operasi adalah perawatan, security adalah kunci dan CCTV, reliability adalah struktur tahan gangguan, performance adalah ukuran ruangan pas, cost adalah tagihan, sustainability adalah hemat energi.
Review Workload dengan AWS WA Tool
Dari pertanyaan menuju improvement plan.
AWS Well-Architected Tool membantu mendokumentasikan workload, menjawab pertanyaan lens, menemukan risiko, dan menyusun rencana perbaikan.
AWS WA Tool dipakai untuk mendokumentasikan kondisi workload. Alur resminya sederhana: define workload, document workload state, review improvement plan, lalu make improvements and measure progress. Untuk pemula, bayangkan seperti checklist berkala sebelum aplikasi masuk produksi dan sesudah aplikasi berjalan.
Tulis nama workload, pemilik review, lingkungan, region, akun terkait, dan konteks bisnisnya.
Jawab pertanyaan berdasarkan lens yang dipilih, misalnya AWS Well-Architected Framework lens.
Lihat risiko tinggi dan risiko sedang, lalu kelompokkan mana yang harus diperbaiki lebih dulu.
Lakukan perbaikan bertahap, catat milestone, dan ukur ulang setelah perubahan.
Menjawab review dengan terlalu optimis membuat hasil review tidak berguna. Lebih baik jujur mencatat risiko daripada menyembunyikan masalah sampai menjadi insiden.
Fitur yang mempercepat review
Selain alur dasar, WA Tool punya dua fitur yang membuat review lebih terarah dan konsisten. Keduanya jarang jadi inti soal CLF-C02, tetapi mengenal namanya membantu kamu tidak bingung bila muncul di pilihan jawaban.
Profiles
Kamu mendefinisikan tujuan bisnis lebih dulu (misalnya prioritas keamanan atau kecepatan rilis), lalu WA Tool menyusun daftar pertanyaan yang sudah diprioritaskan sesuai konteks itu.
Review Templates
Kumpulan jawaban umum yang bisa dipakai ulang di banyak workload sejenis, sehingga tim tidak menjawab pertanyaan dasar yang sama berulang kali.
WA Tool bukan Trusted Advisor
Ini salah satu jebakan paling sering di topik ini. Keduanya sama-sama membicarakan kualitas, tetapi sudut pandangnya berbeda: WA Tool menilai satu workload lewat pertanyaan yang kamu jawab, sedangkan Trusted Advisor memindai akun secara otomatis. Mengenal kategori cek Trusted Advisor membantu memilah keduanya.
- Kamu yang menjawab pertanyaan lens; hasilnya improvement plan berisi HRI dan MRI.
- Fokus pada satu workload terhadap enam pilar Well-Architected.
- Bersifat dokumentasi keputusan dan diskusi, bukan pemeriksaan otomatis.
- Kata kunci soal: evaluate architecture, pillars, best practices, workload review.
- Memberi rekomendasi otomatis lintas akun, tanpa kamu menjawab kuesioner.
- Memeriksa lima sampai enam kategori: cost optimization, security, fault tolerance, performance, service limits/quotas, dan operational excellence.
- Cakupan cek penuh bergantung pada level AWS Support (Business atau Enterprise lebih lengkap).
- Kata kunci soal: account checks, recommendations, service limits, automatic.
Contoh mini dengan bahasa WA Tool
Sebuah backend toko online berjalan di satu EC2 instance tanpa backup database teruji. Di WA Tool, ini akan muncul sebagai high risk issue (HRI) pada pilar reliability, karena satu gangguan instance atau data bisa menghentikan bisnis. Improvement plan-nya bisa berupa database managed multi-AZ, backup terjadwal, health check, Auto Scaling, dan dokumentasi prosedur pemulihan. Setelah perbaikan, kamu catat milestone (misalnya “go live setelah hardening reliability”) lalu ukur ulang. Dari pilar cost optimization, jangan langsung memilih konfigurasi terbesar. Ukur beban, rightsizing, lalu pakai model harga yang sesuai agar HRI reliability tidak diganti dengan masalah biaya.
Jika soal menanyakan tool untuk mengevaluasi satu workload terhadap Well-Architected Framework, jawabannya AWS Well-Architected Tool, bukan Trusted Advisor, Cost Explorer, atau CloudTrail. Jika soal menyebut rekomendasi otomatis lintas akun pada cost, security, dan service limits, jawabannya Trusted Advisor.
AWS Cloud Adoption Framework
Framework untuk transformasi organisasi, bukan hanya desain aplikasi.
AWS CAF membantu organisasi merencanakan dan menjalankan adopsi cloud lewat perspektif bisnis, manusia, tata kelola, platform, keamanan, dan operasi.
Jika Well-Architected memeriksa kualitas workload, maka AWS Cloud Adoption Framework melihat perjalanan organisasi. Analogi sederhananya: Well-Architected mengecek apakah satu rumah dirancang baik, sedangkan CAF membantu satu perusahaan memindahkan banyak tim, proses, kebijakan, dan sistem ke kota baru bernama cloud.
Enam perspektif CAF
Business
Memastikan investasi cloud mendukung hasil bisnis, pendapatan, pengalaman pelanggan, dan prioritas eksekutif.
People
Mengembangkan kemampuan tim, perubahan peran, budaya belajar, dan kesiapan organisasi.
Governance
Membantu pengambilan keputusan, manajemen risiko, kepatuhan, finansial, dan kontrol portofolio.
Platform
Membangun lingkungan cloud, landing zone, jaringan, akun, dan fondasi teknis yang bisa dipakai tim.
Security
Mengatur identitas, proteksi data, deteksi ancaman, respons insiden, dan kepatuhan keamanan.
Operations
Mengelola monitoring, incident management, change management, service management, dan perbaikan berkelanjutan.
CAF menjawab “bagaimana organisasi berhasil mengadopsi cloud”, Well-Architected menjawab “apakah workload ini dirancang dan dioperasikan dengan baik”.
CAF 3.0 lebih dari enam perspektif
Banyak materi lama berhenti di enam perspektif, padahal CAF versi 3.0 (yang masih berlaku) menambahkan dua hal penting. Pertama, empat transformation domains: Technology, Process, Organization, dan Product, yaitu area apa saja yang berubah saat organisasi pindah ke cloud. Kedua, empat transformation phases yang berjalan iteratif: Envision → Align → Launch → Scale, yaitu tahapan perjalanan transformasi. Untuk CLF-C02 kamu cukup mengenali namanya, bukan menghafal detailnya.
Empat manfaat CAF yang paling sering diuji
Ini bagian yang sering terlewat. Exam Guide CLF-C02 justru menyebut komponen CAF lewat manfaat, bukan lewat enam perspektif. Jadi bila soal menanyakan manfaat CAF, jawaban yang dicari hampir selalu salah satu dari empat ini, bukan “Platform perspective”.
Reduced business risk
Adopsi cloud yang terencana menurunkan risiko bisnis lewat tata kelola, keamanan, dan operasi yang lebih matang.
Improved ESG performance
Cloud membantu memperbaiki kinerja environmental, social, dan governance, termasuk efisiensi energi dan jejak karbon.
Increased revenue
Kemampuan baru, kecepatan rilis, dan jangkauan global membuka peluang pendapatan baru.
Increased operational efficiency
Otomasi dan managed service mengurangi beban operasi, sehingga tim lebih produktif dengan sumber daya yang sama.
Perspektif menjawab “area apa yang berubah”, manfaat menjawab “untuk apa transformasi dilakukan”. Bila soal berbunyi “what is a benefit of AWS CAF”, pilih reduced business risk, improved ESG, increased revenue, atau increased operational efficiency, bukan salah satu nama perspektif.
Jangan tertukar: enam perspektif CAF vs enam pilar Well-Architected
Keduanya sama-sama berjumlah enam dan sama-sama punya item “Security” serta item operasi, jadi sangat mudah tertukar. Bedakan dari pertanyaan besarnya: CAF mengurus transformasi organisasi, Well-Architected mengurus kualitas satu workload.
- Pertanyaan besar: bagaimana ORGANISASI berhasil pindah ke cloud?
- Itemnya: Business, People, Governance, Platform, Security, Operations.
- Hasil yang diukur: readiness, roadmap, dan empat manfaat transformasi.
- Pertanyaan besar: apakah satu WORKLOAD dirancang dan dioperasikan dengan baik?
- Itemnya: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability.
- Hasil yang diukur: risiko (HRI/MRI) dan improvement plan per pilar.
Kenapa CAF muncul di CLF-C02?
Domain Cloud Concepts mencakup strategi adopsi cloud, manfaat migrasi, dan sumber daya untuk perjalanan cloud. Karena itu, CAF penting untuk memahami bahasa transformasi: business risk, operational efficiency, revenue, ESG, readiness, roadmap, dan stakeholder. Kamu tidak perlu menghafal semua capability detail, tetapi enam perspektif dan empat manfaat wajib dikenali.
Ecosystem: Partner, Marketplace, dan Sumber Resmi
Tahu ke mana mencari bantuan sama pentingnya dengan tahu layanan apa yang dipakai.
Ekosistem AWS membantu pelanggan belajar, membeli solusi, mencari partner, dan menemukan panduan resmi ketika menghadapi skenario nyata.
Dalam ujian CLF-C02, beberapa opsi jawaban bukan layanan compute, storage, atau database, melainkan sumber bantuan. Pemula sering salah karena semua terdengar seperti “tempat membaca artikel”. Bedakan fungsi utamanya.
AWS Partner Network (APN)
Komunitas global organisasi partner pihak ketiga (ISV, data provider, dan consulting partner) yang memakai teknologi, program, funding, dan tool AWS untuk membangun solusi bagi pelanggan.
AWS Professional Services
Tim konsultan milik AWS sendiri (first-party), bukan partner. Membantu migrasi, modernisasi, data/AI, serta scale dan security, dan sering bekerja berdampingan dengan APN partner.
AWS Marketplace
Katalog digital terkurasi untuk menemukan, membeli, men-deploy, dan mengelola software, data, dan layanan pihak ketiga, dengan tagihan langsung muncul di AWS bill.
AWS Whitepapers & Guides
Kumpulan konten teknis, decision guide, reference material, dan reference architecture untuk memperdalam pengetahuan cloud.
AWS Prescriptive Guidance
Panduan langkah demi langkah, arsitektur, tool, dan kode untuk skenario migrasi, modernisasi, optimasi, deployment, dan keamanan.
AWS Architecture Center
Tempat mencari contoh reference architecture, diagram, best practices, dan decision guides untuk merancang solusi.
AWS re:Post Knowledge Center
Sumber tanya jawab, troubleshooting, dan artikel Knowledge Center resmi (kini menyatu di re:Post) untuk masalah teknis yang sering muncul.
Catatan nama
Sejak Maret 2023, artikel Knowledge Center bermigrasi ke AWS re:Post, jadi URL lama mengarah ke repost.aws. Materi modern menyebutnya re:Post Knowledge Center.
Architecture Center adalah atlas desain, Prescriptive Guidance adalah resep langkah demi langkah, Marketplace adalah toko solusi, APN adalah jaringan konsultan dan vendor, re:Post adalah meja tanya jawab, whitepapers adalah buku referensi.
Kapan memakai yang mana?
Cara paling cepat memilih adalah mencocokkan kata kerja di soal dengan sumber yang tepat. Gambar berikut adalah decision-tree yang langsung melatih refleks itu.
- Butuh contoh desain dan decision guide: mulai dari AWS Architecture Center.
- Butuh panduan implementasi bertahap: cari AWS Prescriptive Guidance.
- Butuh software pihak ketiga dengan procurement terpusat: gunakan AWS Marketplace.
- Butuh partner pihak ketiga untuk migrasi, audit, atau managed service: cari AWS Partner Network.
- Butuh konsultan dari AWS sendiri untuk proyek besar: pakai AWS Professional Services.
- Butuh jawaban troubleshooting: cek AWS re:Post Knowledge Center dan dokumentasi layanan.
- Butuh pembelajaran konseptual mendalam: baca AWS Whitepapers & Guides.
Marketplace vs APN: katalog vs komunitas
Dua nama ini paling sering tertukar karena keduanya berurusan dengan “pihak ketiga”. Pegang bedanya: Marketplace adalah toko untuk membeli software, APN adalah jaringan perusahaan partner.
- Tempat menemukan, membeli, dan men-deploy software/data pihak ketiga.
- Model harga fleksibel: free trial, hourly, monthly, annual, multi-year, dan BYOL.
- Semua tagihan terpusat di AWS bill, termasuk private offer dengan harga dan EULA khusus.
- Kata kunci soal: find, buy, subscribe, deploy third-party software.
- Jaringan perusahaan partner: ISV, data provider, dan consulting/MSP partner.
- Kamu mencari rekan untuk membangun, migrasi, audit, atau mengelola workload.
- Bukan tempat transaksi software langsung, melainkan tempat menemukan keahlian.
- Kata kunci soal: find a partner, consulting, certified SI, managed service provider.
AWS Professional Services adalah konsultan milik AWS sendiri (first-party). APN partner adalah perusahaan pihak ketiga (third-party) yang tersertifikasi. Bila soal menyebut “AWS’s own consultants” jawab Professional Services; bila menyebut “certified third-party consultant atau SI” jawab APN partner.
Trust & Safety dan Acceptable Use Policy
Selain sumber bantuan, ekosistem AWS juga punya aturan main. AWS Acceptable Use Policy (AUP) mengatur bagaimana pelanggan boleh memakai layanan AWS, dan melanggarnya bisa berujung penangguhan akun.
AUP melarang antara lain aktivitas ilegal atau penipuan, melanggar hak orang lain, kekerasan/terorisme, konten eksploitasi anak (CSAM), upaya merusak keamanan/integritas/ketersediaan sistem, serta spam. Dugaan penyalahgunaan dilaporkan ke AWS Trust & Safety lewat jalur abuse resmi AWS.
Jika pertanyaan menyebut membeli solusi pihak ketiga, pikirkan Marketplace. Jika menyebut mencari partner konsultasi pihak ketiga, pikirkan APN. Jika menyebut konsultan milik AWS, pikirkan Professional Services. Jika menyebut aturan pemakaian yang boleh dan dilarang, pikirkan Acceptable Use Policy. Jika menyebut troubleshooting artikel resmi, pikirkan re:Post Knowledge Center.
Service Picker Berbasis Prinsip
Pilih layanan dari kebutuhan, bukan dari hafalan daftar produk.
Service picker yang baik dimulai dari kualitas arsitektur yang dibutuhkan, lalu memilih layanan yang mengurangi risiko dan beban operasi.
Modul sebelumnya sudah membahas banyak layanan. Di sini, kita mengikatnya dengan cara pikir architecting. Pertanyaan service picker untuk CLF-C02 biasanya sederhana: “layanan apa yang paling sesuai untuk use case ini?” Jawaban terbaik sering terlihat jika kamu tahu prinsipnya.
Butuh mengurangi operasi server
Pertimbangkan managed service atau serverless seperti Lambda, Fargate, RDS, DynamoDB, S3, SQS, SNS, atau EventBridge sesuai use case.
Butuh high availability
Pikirkan multi-AZ, load balancer, Auto Scaling, health check, managed database, backup, dan desain tanpa single point of failure.
Butuh security kuat
Pikirkan IAM least privilege, MFA, KMS, Secrets Manager, WAF, Shield, GuardDuty, CloudTrail, Config, dan pemisahan akun.
Butuh performa global
Pikirkan Region dekat pengguna, CloudFront, Global Accelerator, caching, database yang sesuai pola akses, dan pilihan compute yang tepat.
Butuh biaya terkendali
Pikirkan rightsizing, autoscaling, storage class, Savings Plans, Reserved Instances, Cost Explorer, Budgets, dan penghapusan resource idle.
Butuh adopsi organisasi
Pikirkan CAF, landing zone, AWS Organizations, multi-account, governance, training, partner, dan roadmap transformasi.
CLF-C02 tidak menuntut desain paling rumit. Banyak soal menguji apakah kamu memilih layanan paling sederhana yang memenuhi kebutuhan, bukan arsitektur paling canggih.
Contoh keputusan sederhana
- Upload file statis dan akses publik terkontrol: S3, mungkin CloudFront bila perlu distribusi global.
- Pesan antar komponen agar tidak saling menunggu: SQS untuk antrean, SNS untuk fan-out notifikasi, EventBridge untuk event bus.
- Database relasional managed: RDS atau Aurora, bukan EC2 manual kecuali ada alasan khusus.
- Contact center cloud: Amazon Connect, bukan membangun PBX sendiri di EC2.
- Menilai risiko desain: AWS Well-Architected Tool, bukan AWS Marketplace.
Baca kebutuhan bisnis, cari kata kunci kualitas, petakan ke pilar, lalu pilih layanan atau sumber AWS yang paling langsung menyelesaikan masalah.
Hands-on Ringan: Mini Review Arsitektur
Latihan konseptual tanpa perlu membuat resource mahal.
Hands-on modul ini adalah walkthrough berpikir: ambil satu aplikasi sederhana, lalu review dengan enam pilar.
Bayangkan aplikasi backend online shop skincare. Aplikasi menerima request dari mobile app, menyimpan produk dan pesanan, mengirim email transaksi, dan menampilkan gambar produk. Kita belum menggambar arsitektur lengkap. Kita hanya melakukan mini review untuk melatih cara pikir.
Nama: Backend Online Shop Skincare. Tujuan: pelanggan bisa melihat produk, checkout, menerima email, dan admin bisa mengelola pesanan.
Apa ada monitoring, alarm, deployment terulang, log terpusat, dan runbook ketika checkout gagal?
Apakah admin memakai MFA, akses IAM least privilege, data pelanggan dienkripsi, secret tidak ditaruh di kode, dan audit log aktif?
Apakah database punya backup, komponen penting tidak single point of failure, dan sistem bisa pulih saat traffic promo meningkat?
Apakah gambar produk memakai storage dan caching yang tepat, API bisa scale, dan database sesuai pola query?
Apakah resource idle dimatikan, kapasitas menyesuaikan traffic, dan alert budget sudah dibuat?
Apakah sistem mengurangi resource tidak terpakai, ukuran gambar dioptimalkan, dan kapasitas mengikuti kebutuhan aktual?
Jika backend sering gagal saat traffic promo dan belum punya Auto Scaling atau database multi-AZ, pilar yang paling jelas terdampak adalah reliability. Jika biaya naik karena resource besar selalu menyala, pilar yang paling jelas adalah cost optimization.
Output latihan
Buat daftar tiga risiko prioritas. Contoh: tidak ada backup teruji, IAM admin terlalu luas, dan tidak ada alarm untuk error checkout. Lalu buat improvement plan sederhana: aktifkan backup dan restore test, batasi IAM role, aktifkan CloudWatch alarm, dokumentasikan runbook, dan review ulang setelah perubahan. Inilah inti architecting di level Cloud Practitioner: memahami risiko dan perbaikan tanpa harus menjadi arsitek senior.
Kesalahan Umum & Jebakan Soal
Bagian ini menyelamatkan poin ujian yang sering hilang karena istilah mirip.
Sebagian besar jebakan topik ini berasal dari mencampuradukkan framework, tool, marketplace, partner, dan dokumentasi.
CAF disamakan dengan Well-Architected
CAF untuk transformasi organisasi dan readiness. Well-Architected untuk review kualitas workload.
Marketplace disamakan dengan APN
Marketplace untuk membeli dan mengelola solusi pihak ketiga. APN untuk jaringan partner, layanan profesional, dan kolaborasi partner.
WA Tool disamakan dengan Trusted Advisor
WA Tool mengevaluasi workload terhadap framework. Trusted Advisor memberi rekomendasi akun pada area seperti cost, security, fault tolerance, performance, dan service limits sesuai cakupan support.
Whitepaper disamakan dengan Knowledge Center
Whitepapers untuk pembelajaran dan panduan mendalam. Knowledge Center untuk pertanyaan umum dan troubleshooting resmi yang sering dialami pelanggan.
Performance disamakan dengan reliability
Performance membahas resource tepat dan efisien untuk beban. Reliability membahas kemampuan bertahan dan pulih dari kegagalan.
Cost disamakan dengan sustainability
Keduanya bisa sama-sama mengurangi resource idle, tetapi cost fokus biaya, sustainability fokus dampak lingkungan dan efisiensi resource.
Professional Services disamakan dengan APN
Professional Services adalah konsultan milik AWS (first-party). APN adalah jaringan partner pihak ketiga (third-party) yang tersertifikasi.
Perspektif CAF disamakan dengan manfaat CAF
Perspektif menjawab “area apa yang berubah” (Business, People, …). Manfaat menjawab “untuk apa” (reduced risk, ESG, revenue, efficiency), dan ini yang sering ditanya.
Hindari jawaban yang terdengar absolut seperti selalu multi-region atau selalu serverless. Arsitektur yang baik bergantung pada kebutuhan bisnis, risiko, biaya, dan kompleksitas operasional.
Kata kunci soal
- ”Evaluate architecture”, “risk”, “pillars”, “best practices”: Well-Architected atau AWS WA Tool.
- ”Cloud adoption”, “readiness”, “transformation roadmap”, “stakeholders”: AWS CAF.
- ”Find, buy, deploy third-party software”: AWS Marketplace.
- ”Work with certified third-party partner”, “consulting partner”, “MSP”: AWS Partner Network.
- ”AWS’s own consultants”, “first-party AWS consulting team”: AWS Professional Services.
- ”Step-by-step migration or modernization guidance”: AWS Prescriptive Guidance.
- ”Acceptable use”, “prohibited activity”, “report abuse”: AWS Acceptable Use Policy dan Trust & Safety.
- ”Automatic account checks on cost, security, service limits”: AWS Trusted Advisor (bukan WA Tool).
- ”Troubleshoot common AWS issue”: AWS re:Post Knowledge Center.
Jika dua jawaban sama-sama terdengar benar, pilih yang paling langsung menjawab kata kerja soal: evaluate, adopt, buy, partner, troubleshoot, atau learn.
Ringkasan & Tips Ujian
Peta akhir untuk mengikat modul ke domain CLF-C02.
Modul ini mengajarkan cara membaca keputusan arsitektur AWS dari sisi kualitas, risiko, organisasi, dan ekosistem resmi.
Poin Penting
- Architecting bukan sekadar diagram, tetapi proses memilih trade-off yang mendukung tujuan bisnis; ingat enam general design principles (stop guessing capacity, test at scale, automate, evolutionary, drive with data, game days).
- AWS Well-Architected Framework mengevaluasi workload melalui enam pilar: operational excellence, security, reliability, performance efficiency, cost optimization, dan sustainability, masing-masing dengan pertanyaan kunci dan trade-off.
- AWS WA Tool (gratis) dipakai untuk mendokumentasikan workload, menjawab pertanyaan lens, melihat improvement plan berisi HRI dan MRI, mencatat milestone, lalu ukur ulang; bukan Trusted Advisor yang memindai akun otomatis.
- AWS CAF punya enam perspektif (Business, People, Governance, Platform, Security, Operations), empat domain dan empat fase, tetapi yang paling sering diuji adalah empat manfaatnya: reduced business risk, improved ESG, increased revenue, increased operational efficiency.
- Marketplace = beli software pihak ketiga (tagihan di AWS bill), APN = komunitas partner pihak ketiga, Professional Services = konsultan AWS sendiri, Prescriptive Guidance = panduan implementasi, Architecture Center = reference architecture, Whitepapers = belajar mendalam, re:Post = troubleshooting, AUP = aturan pemakaian.
Pemetaan ke domain CLF-C02
- Domain 1, Cloud Concepts 24%: sangat relevan untuk design principles, Well-Architected, cloud adoption, CAF, manfaat cloud, dan konsep cloud economics.
- Domain 2, Security and Compliance 30%: relevan ketika membahas pilar security, shared responsibility, identitas, enkripsi, audit, compliance, dan sumber seperti AWS Artifact.
- Domain 3, Cloud Technology and Services 34%: relevan untuk memilih layanan berdasarkan kebutuhan, misalnya storage, compute, database, networking, monitoring, integration, dan managed services.
- Domain 4, Billing, Pricing, and Support 12%: relevan untuk cost optimization, AWS Marketplace billing, model lisensi, Support, Trusted Advisor, Cost Explorer, Budgets, dan Pricing Calculator.
Hafalkan enam pilar Well-Architected dan pertanyaan kuncinya, enam general design principles, enam perspektif plus empat manfaat CAF, fungsi WA Tool (gratis) vs Trusted Advisor, beda Marketplace vs APN vs Professional Services, isi AUP, serta kapan memakai Prescriptive Guidance, Whitepapers, Architecture Center, dan re:Post Knowledge Center.
Latihan cepat
- Soal menyebut “mengukur workload terhadap best practices”, jawab AWS Well-Architected Tool.
- Soal menyebut “perusahaan ingin roadmap transformasi cloud lintas bisnis dan teknologi”, jawab AWS CAF.
- Soal menyebut “membeli software firewall pihak ketiga dan tagihannya muncul di AWS bill”, jawab AWS Marketplace.
- Soal menyebut “mencari partner pihak ketiga untuk membantu migrasi”, jawab AWS Partner Network.
- Soal menyebut “konsultan dari AWS sendiri untuk proyek transformasi besar”, jawab AWS Professional Services.
- Soal menyebut “manfaat dari AWS CAF”, jawab salah satu dari reduced business risk, improved ESG, increased revenue, atau increased operational efficiency.
- Soal menyebut “panduan langkah demi langkah untuk modernisasi aplikasi”, jawab AWS Prescriptive Guidance.
Untuk Cloud Practitioner, kemampuan terbaik bukan menggambar arsitektur paling kompleks, tetapi memahami alasan keputusan, risiko yang dikurangi, dan sumber resmi yang tepat untuk langkah berikutnya.