Other AWS Services
Use Case Catalog
Kita belajar memilih layanan AWS dari masalah bisnisnya, seperti memilih toko yang tepat di sebuah pusat perbelanjaan besar.
Kenapa Modul Ini Ada?
AWS punya ratusan layanan, tetapi ujian Cloud Practitioner jarang bertanya “bagaimana cara setup”. Ia hampir selalu bertanya “layanan mana yang cocok untuk skenario ini?”
Bayangkan AWS seperti kota besar. Modul sebelumnya sudah membahas jalan utama: compute, storage, database, network, security, monitoring, billing, migration, dan AI. Modul ini adalah peta kios khusus: tempat mengirim email massal, membuka contact center, memberi desktop virtual, membuat aplikasi frontend, menghubungkan device IoT, menjalankan job batch, atau membawa sebagian AWS ke lokasi fisik perusahaan.
Kenapa modul ini penting untukmu? Karena justru di sinilah banyak orang kehilangan poin. Layanan inti seperti EC2 dan S3 sudah dilatih berkali-kali, jadi terasa familiar. Layanan pelengkap ini muncul lebih jarang, namanya mirip-mirip, dan satu kata kunci kecil bisa membalik jawaban. Soal tidak menguji kedalaman teknismu, ia menguji apakah kamu bisa mencocokkan satu kalimat skenario dengan satu nama layanan yang tepat.
Di CLF-C02, kamu tidak perlu menjadi ahli konfigurasi setiap layanan. Kamu perlu mengenali pola. Kalau pertanyaannya menyebut email transaksional atau marketing, arahkan ke Amazon SES. Kalau menyebut contact center, pilih Amazon Connect. Kalau menyebut virtual desktop, pilih Amazon WorkSpaces. Kalau menyebut GraphQL API, pilih AWS AppSync.
Layanan inti seperti EC2, S3, dan RDS adalah jalan raya. Layanan di modul ini adalah alamat tujuan spesifik, seperti kantor pos (SES), call center (Connect), studio aplikasi (Amplify), pabrik IoT (IoT Core), dan bengkel batch processing (Batch). Kamu tidak perlu tahu setiap mesin di dalamnya, cukup tahu kios mana yang menjual apa.
Secara resmi, layanan yang kita bahas ada di daftar in-scope CLF-C02 pada beberapa kategori: Business Applications (SES, Connect), End User Computing (WorkSpaces, AppStream 2.0, WorkSpaces Secure Browser), Frontend Web and Mobile (Amplify, AppSync), Internet of Things (hanya IoT Core), dan Compute (Batch, Lightsail, Outposts). Artinya, soal muncul sebagai pertanyaan pemilihan layanan, bukan sebagai pertanyaan konfigurasi mendalam.
Beberapa layanan terkenal sengaja kita lewati karena tidak ada di daftar in-scope CLF-C02: Amazon Pinpoint (bahkan sedang dipensiunkan, end of support 30 Oktober 2026), AWS Device Farm, Amazon Chime, AWS Elemental MediaConvert/MediaLive, Amazon Ground Station, dan Amazon Braket. Jika nama-nama ini muncul sebagai pilihan jawaban, mereka biasanya distractor; jawaban yang benar hampir pasti layanan in-scope. Kenali namanya agar tidak terkecoh, tapi jangan habiskan waktu mempelajarinya.
Pola Besar Modul
- Fokus utama: pasangan skenario bisnis dan layanan AWS yang paling cocok.
- Fokus ujian: bedakan layanan yang terdengar mirip, terutama WorkSpaces vs AppStream 2.0, SES vs SNS, Amplify vs AppSync, IoT Core vs Kinesis, dan Lightsail vs EC2 vs Batch.
- Fokus praktik: selalu cek keamanan, integrasi, lokasi data, dan biaya sebelum memilih layanan.
Cara Membaca Kamus Skenario
Mulai dari pekerjaan yang ingin diselesaikan, bukan dari nama layanan.
Cara tercepat memahami layanan AWS yang banyak adalah bertanya, “pekerjaan apa yang ingin saya selesaikan?”
Pemula sering menghafal nama layanan seperti daftar kosakata asing. Itu melelahkan dan rapuh, karena ujian sengaja menaruh dua nama mirip dalam satu soal. Cara yang lebih kuat adalah membuat peta mental berbasis pekerjaan: komunikasi, akses pengguna, pengembangan aplikasi, device dan edge, serta compute khusus. Begitu kamu mendengar pekerjaannya, kamu langsung tahu kios mana yang dituju.
1. Komunikasi bisnis
Butuh email aplikasi atau contact center? Mulai dari SES dan Connect.
2. Akses pengguna
Butuh desktop, aplikasi streaming, atau browser aman? Mulai dari WorkSpaces, AppStream 2.0, dan Secure Browser.
3. Aplikasi frontend dan API
Butuh hosting frontend, auth, data, atau GraphQL? Mulai dari Amplify dan AppSync.
4. Device, edge, dan hybrid
Butuh device terhubung ke cloud atau AWS di lokasi sendiri? Mulai dari IoT Core dan Outposts.
5. Compute khusus
Butuh VPS sederhana atau ribuan job batch? Mulai dari Lightsail dan AWS Batch.
6. Validasi biaya dan operasi
Cek model pembayaran, data transfer, integrasi IAM, logging, dan batasan region sebelum produksi.
Jika soal memberi kata kunci use case, jangan langsung mencari layanan paling canggih. Cari layanan yang namanya paling dekat dengan pekerjaan utama dalam skenario.
Pertanyaan pemilih layanan
- Siapa aktornya? Pelanggan, agent support, karyawan remote, developer frontend, device pabrik, atau sistem batch.
- Apa medianya? Email, telepon, chat, desktop, aplikasi, GraphQL API, MQTT, browser, atau container job.
- Apakah perlu real-time? Contact center, IoT, chat, dan GraphQL subscription sering menuntut respons cepat.
- Apakah butuh lingkungan managed? Banyak layanan di modul ini mengurangi beban mengelola server.
- Apakah ada batas fisik? Outposts muncul ketika ada kebutuhan on-premises, latensi rendah ke sistem lokal, atau residensi data.
Business Applications: SES & Connect
Kategori ini menjawab kebutuhan komunikasi pelanggan: email aplikasi dan pusat kontak.
Amazon Simple Email Service (Amazon SES)
Bayangkan ruang surat perusahaan: aplikasi menulis alamat tujuan, isi pesan, dan nama pengirim, lalu petugas pos memastikan surat itu benar-benar sampai dan tidak masuk kotak spam. Amazon SES adalah ruang surat itu dalam bentuk cloud, layanan untuk mengirim (dan menerima) email dari aplikasi secara terkelola dan dalam skala besar.
Contoh nyata: toko online mengirim email verifikasi akun, reset password, invoice, notifikasi pengiriman, dan newsletter promo. Semua itu bukan tugas database dan bukan tugas S3. Itu tugas layanan email aplikasi, dan SES dirancang khusus untuk urusan yang halus seperti deliverability (apakah email benar-benar sampai), bounce (email yang gagal terkirim), dan complaint (penerima menandai spam), yang semuanya menjaga reputasi pengirim agar email berikutnya tidak diblokir.
Pilih SES saat soal menyebut email transaksional, email marketing, newsletter, deliverability, reputasi pengirim, bounce, complaint, domain verified, atau SMTP/API email.
Komponen yang perlu dikenali
- Verified identity, domain atau alamat email yang dibuktikan sebagai milik pengirim sebelum boleh mengirim atas namanya.
- Sandbox, mode awal untuk pengujian. Di sini SES membatasi tujuan (hanya ke alamat yang sudah diverifikasi) dan volume.
- SMTP interface dan API, dua cara aplikasi mengirim email melalui SES.
- Bounce dan complaint handling, sinyal penting untuk menjaga reputasi pengirim.
- Dedicated IP, shared IP, dan owned IP, opsi deployment pengiriman email sesuai kebutuhan reputasi dan kontrol.
Di SES sandbox, kuota default adalah 200 email per periode 24 jam dengan laju maksimum 1 pesan per detik, dihitung atas jendela bergulir 24 jam. Batas ini tidak bisa dinaikkan selama masih di sandbox, kamu harus mengajukan pindah ke produksi. Soal kadang menyembunyikan “akun baru hanya bisa kirim ke alamat terverifikasi dengan volume kecil”, itu kode untuk sandbox.
Lupakan angka lama “62.000 email gratis per bulan dari EC2” (dihentikan Agustus 2023). Skema sekarang: 3.000 message charge per bulan untuk 12 bulan pertama, lalu untuk akun yang dibuat sejak 15 Juli 2025 berlaku model Free Tier baru berupa kredit $200 yang bisa dipakai lintas layanan. Untuk ujian, jangan menghafal angka harga; cukup ingat SES dibayar per email terkirim/diterima. Cek halaman pricing SES untuk angka terbaru.
SES vs SNS: jangan tertukar
Ini salah satu jebakan paling klasik. SES dan SNS sama-sama bisa “mengirim sesuatu”, tapi tujuannya berbeda. SES adalah produk email; SNS adalah mesin pemberitahuan pub/sub. Patokan cepat: jika kata kuncinya tentang isi dan kualitas email (newsletter, deliverability, reputasi), itu SES. Jika kata kuncinya tentang menyebar satu pesan ke banyak penerima/sistem (fanout, topic, decoupling), itu SNS.
- Mengirim dan menerima email transaksional, marketing, dan newsletter.
- Peduli pada deliverability, reputasi pengirim, bounce, dan complaint.
- Pakai SMTP atau API, dengan domain/identity yang diverifikasi.
- Kata kunci: email, newsletter, invoice, reset password, inbox.
- Menyebar satu pesan ke banyak subscriber sekaligus (fanout).
- Subscriber bisa email, SMS, Lambda, SQS, atau HTTP endpoint.
- Dipakai untuk decoupling sistem, bukan kampanye email.
- Kata kunci: topic, publish, subscribe, fanout, notifikasi sistem.
Amazon Connect
Bayangkan perusahaan ingin membuka call center, tetapi tidak mau membeli PBX, server telepon, lisensi software contact center, dan tidak mau menandatangani kontrak seat per agent selama bertahun-tahun. Amazon Connect menjawab itu: contact center cloud yang dibuat dalam hitungan menit. Perusahaan tinggal membuat instance, mengklaim nomor telepon, menyusun queue, agent, routing, contact flow, chat, dan task.
Contoh nyata: e-commerce ingin pelanggan bisa menghubungi support lewat telepon dan chat, agent bisa melihat antrean, supervisor bisa memantau kualitas, dan flow bisa mengarahkan pelanggan ke tim yang tepat. Itu skenario Amazon Connect.
Pilih Amazon Connect saat soal menyebut cloud contact center, call center, customer service agent, routing panggilan, queue, IVR, chat support, atau pengalaman pelanggan omnichannel.
Komponen yang perlu dikenali
- Instance, lingkungan contact center virtual.
- Phone number, nomor yang diklaim atau dipindahkan untuk menerima dan melakukan panggilan.
- Contact flow, alur interaksi pelanggan seperti menu IVR, pesan pembuka, dan routing.
- Queue dan routing profile, pengaturan antrean dan skill agent.
- Agent workspace, tempat agent menangani interaksi pelanggan.
Menurut halaman pricing Connect, Connect memakai model pay-as-you-go: tidak ada komitmen di muka, tidak ada kontrak jangka panjang, tidak ada lisensi seat per agent, dan tidak ada biaya minimum. Tagihan dihitung per menit (suara) dan per pesan (chat/SMS) sesuai pemakaian. Di Domain 4, kata kunci “no upfront, no per-agent license, pay per use untuk contact center” mengarah ke Connect.
Connect adalah contact center menghadap pelanggan (agent melayani pelanggan), bukan layanan video meeting internal. Layanan meeting internal adalah Amazon Chime, tetapi Chime tidak ada di silabus CLF-C02, jadi skenario “contact center” hampir pasti merujuk Connect.
End User Computing: WorkSpaces, AppStream 2.0 & Secure Browser
Kategori ini menjawab pertanyaan: bagaimana pengguna mengakses desktop, aplikasi, atau browser kerja tanpa mengelola laptop kantor secara penuh?
Ada tiga jawaban, dan ujian suka menukar-nukar ketiganya. Patokan satu kalimat: WorkSpaces memberi desktop penuh, AppStream 2.0 memberi satu aplikasi, WorkSpaces Secure Browser memberi sesi browser saja.
Amazon WorkSpaces
Bayangkan karyawan meminjam komputer kantor, tetapi komputer itu sebenarnya berjalan di AWS, bukan di meja mereka. Dari laptop tipis, tablet, atau device pribadi, mereka membuka desktop yang sama persis setiap hari. Itulah Amazon WorkSpaces: desktop virtual terkelola, sering disebut VDI (Virtual Desktop Infrastructure) atau DaaS (Desktop as a Service). Desktopnya persisten, jadi file dan setting tetap ada saat mereka login lagi.
Contoh nyata: perusahaan punya karyawan remote, kontraktor sementara, atau tim call center yang butuh desktop standar. Daripada mengirim laptop fisik ke semua orang, perusahaan menyediakan WorkSpaces dengan kebijakan keamanan dan kontrol terpusat. WorkSpaces juga terhubung ke directory (AWS Directory Service atau Active Directory) untuk login karyawan, jadi identitas dan akses dikelola dari satu tempat, ini sisi keamanan yang sering disinggung di Domain 2.
Pilih WorkSpaces saat soal menyebut virtual desktop, desktop cloud, VDI, DaaS, karyawan remote, desktop persisten, atau akses lingkungan kerja lengkap.
Dua mode tagihan WorkSpaces
Satu konsep biaya WorkSpaces cukup sering muncul: pilih mode tagihan sesuai pola pakai pengguna. Menurut halaman pricing WorkSpaces, ada dua mode.
- Tarif bulanan flat untuk pemakaian tanpa batas jam.
- Predictable, cocok untuk desktop utama yang dipakai tiap hari.
- Pengguna full-time, tidak peduli berapa jam aktif.
- Biaya dasar bulanan rendah plus tarif per jam hanya saat dipakai.
- Hemat untuk pengguna intermittent atau musiman.
- Pengguna part-time, login hanya beberapa jam per hari.
Banyak jam per hari, setiap hari → AlwaysOn (flat bulanan). Sedikit jam, jarang → AutoStop (dasar + per jam). Kata kunci “pekerja musiman / hanya beberapa jam / hemat saat tidak dipakai” mengarah ke AutoStop.
Amazon AppStream 2.0 (kini Amazon WorkSpaces Applications)
Di daftar ujian CLF-C02 (per Juni 2026), kamu akan melihat Amazon AppStream 2.0. Di halaman produk AWS, layanan ini sudah diganti nama menjadi Amazon WorkSpaces Applications (rename efektif sekitar 6 November 2025, fungsi tidak berubah, dilebur ke keluarga WorkSpaces). Untuk ujian, ingat dua nama ini sebagai satu konsep: streaming satu aplikasi dari cloud ke pengguna.
Penting: silabus CLF-C02 masih menulis “Amazon AppStream 2.0”, jadi di soal pilihan jawaban yang benar kemungkinan besar berbunyi AppStream 2.0, bukan “WorkSpaces Applications”. Kenali kedua nama, tapi pilih opsi bertuliskan AppStream 2.0 saat ragu.
Analogi: WorkSpaces memberi satu komputer penuh, sedangkan AppStream 2.0 hanya menayangkan satu aplikasi dari cloud, seperti menonton aplikasi lewat layar streaming. Pengguna tidak perlu menginstal aplikasi berat di laptopnya, tetapi tetap bisa memakai aplikasi itu lewat browser atau client.
Pilih AppStream 2.0 saat soal menyebut streaming aplikasi, aplikasi desktop tanpa instalasi lokal, software trial, training lab, atau akses aplikasi khusus dari browser.
Amazon WorkSpaces Secure Browser
Amazon WorkSpaces Secure Browser adalah browser enterprise terkelola yang berjalan sebagai sesi remote. Analogi: pengguna melihat layar browser dari jarak jauh, tetapi data sensitif tetap berada di lingkungan AWS dan kebijakan perusahaan diterapkan di sesi tersebut. Ini bukan desktop dan bukan aplikasi yang distreaming, hanya browser.
Contoh nyata: vendor eksternal perlu mengakses portal internal, tetapi perusahaan tidak ingin memberi VPN penuh atau mengizinkan data aplikasi menyentuh device vendor. Secure Browser bisa menjadi pilihan karena akses dibatasi ke browser, bukan desktop lengkap.
Pilih WorkSpaces Secure Browser saat soal menyebut secure browser, akses SaaS atau web internal secara aman, tanpa VPN penuh, dan kontrol policy browser terpusat.
Perbandingan cepat
| Kebutuhan | Layanan yang paling cocok | Petunjuk ujian |
|---|---|---|
| Desktop lengkap untuk karyawan | Amazon WorkSpaces | Kata kunci: VDI, virtual desktop, remote worker. |
| Satu aplikasi desktop distreaming | Amazon AppStream 2.0 | Kata kunci: application streaming, tanpa install lokal. |
| Browser aman untuk web internal/SaaS | Amazon WorkSpaces Secure Browser | Kata kunci: secure browser, web access, no VPN. |
Kalau pengguna butuh desktop penuh, jawab WorkSpaces. Kalau hanya butuh aplikasi tertentu, jawab AppStream 2.0. Kalau hanya butuh akses web aman, jawab WorkSpaces Secure Browser.
Frontend Web & Mobile: Amplify & AppSync
Kategori ini membantu developer frontend membuat aplikasi web/mobile lebih cepat tanpa membangun semua backend dari nol.
AWS Amplify
Bayangkan paket starter rumah: pondasi, listrik, dan air sudah terpasang, kamu tinggal mengisi perabot. AWS Amplify adalah paket starter itu untuk developer frontend, kumpulan tools dan layanan untuk membangun, men-deploy, dan menskalakan aplikasi web dan mobile. Di dalamnya ada hosting dengan CI/CD berbasis Git, auth, storage, dan data yang dibungkus rapi agar tim frontend tidak perlu merakit backend dari nol.
Contoh nyata: tim ingin membuat aplikasi React atau Next.js, deploy otomatis dari repository Git, menambahkan login, menyimpan file, dan menghubungkan data tanpa mengelola pipeline kompleks. Amplify cocok sebagai pintu masuk yang ramah frontend.
Pilih Amplify saat soal menyebut build dan deploy web/mobile app, frontend hosting, Git based deployment, auth untuk aplikasi, storage frontend, atau developer experience untuk aplikasi fullstack.
AWS AppSync
Bayangkan pelayan restoran yang tahu persis dari dapur mana setiap menu berasal. Pelanggan cukup memesan apa yang diinginkan dalam satu daftar, pelayan mengambilnya dari banyak dapur sekaligus. AWS AppSync adalah pelayan itu: layanan managed untuk GraphQL API. Aplikasi meminta tepat data yang dibutuhkan lewat satu GraphQL endpoint, lalu AppSync menariknya dari sumber seperti DynamoDB, Lambda, Aurora, OpenSearch, atau HTTP endpoint, dengan subscription real-time lewat WebSocket.
Contoh nyata: aplikasi mobile ingin menampilkan profil pengguna, daftar order, status pengiriman, dan notifikasi perubahan status secara real-time. Daripada memanggil banyak REST API terpisah, aplikasi menggunakan satu GraphQL API dari AppSync.
Pilih AppSync saat soal menyebut GraphQL API, real-time subscriptions, sync data mobile, atau menggabungkan data dari beberapa sumber untuk aplikasi. Kata “GraphQL” hampir selalu mengarah ke AppSync.
Sejak Oktober 2024, AppSync menambah AppSync Events, yaitu serverless WebSocket API (pub/sub real-time) yang tidak butuh GraphQL. Heuristik inti “GraphQL → AppSync” tetap benar untuk ujian, tetapi sekarang skenario fanout real-time juga bisa mengarah ke AppSync, bukan hanya IoT atau API Gateway WebSocket.
Amplify vs AppSync
Keduanya sering tertukar karena sama-sama “untuk aplikasi modern”, padahal perannya beda lapisan. Amplify mengurus bagaimana aplikasi dibangun dan di-host; AppSync mengurus bagaimana aplikasi mengambil data. Keduanya justru saling melengkapi: Amplify bisa memakai AppSync sebagai backend datanya.
- Build, host, dan deploy aplikasi web/mobile dari Git.
- Menyediakan auth, storage, dan CI/CD untuk tim frontend.
- Pengalaman end-to-end, bukan sekadar satu API.
- Kata kunci: deploy React/Next.js dari Git, hosting frontend.
- Managed GraphQL API (dan kini WebSocket pub/sub via Events).
- Menyatukan data dari DynamoDB, Lambda, Aurora, HTTP, dan lainnya.
- Fokus pada lapisan API dan data, bukan hosting.
- Kata kunci: GraphQL, real-time subscription, satu endpoint banyak sumber.
| Pertanyaan skenario | Jawaban kuat | Alasan |
|---|---|---|
| ”Developer frontend ingin deploy aplikasi web dari Git dengan mudah.” | AWS Amplify | Amplify fokus pada build, hosting, dan pengalaman frontend. |
| ”Aplikasi butuh satu GraphQL endpoint untuk data dari DynamoDB dan Lambda.” | AWS AppSync | AppSync fokus pada GraphQL API dan integrasi sumber data. |
| ”Aplikasi butuh update real-time seperti chat atau live score.” | AWS AppSync | AppSync mendukung real-time event dan subscription pattern. |
Amplify bukan database. AppSync bukan hosting frontend umum. Amplify bisa memakai AppSync, tetapi kata kunci GraphQL biasanya mengarah langsung ke AppSync.
IoT, Hybrid & Edge: IoT Core dan Outposts
Kategori ini muncul saat dunia fisik bertemu cloud: sensor, mesin, lokasi pabrik, data lokal, dan kebutuhan latensi rendah.
AWS IoT Core
Bayangkan gerbang masuk gedung kantor yang menerima jutaan kurir kecil. Setiap kurir wajib menunjukkan kartu identitas (sertifikat) sebelum boleh masuk, satpam (broker) menerima paket lalu menaruhnya di rak yang benar, dan ada aturan tertulis (rules engine) untuk meneruskan tiap jenis paket ke departemen yang tepat. AWS IoT Core adalah gerbang itu untuk dunia device: layanan untuk menghubungkan device ke AWS secara aman dan terkelola, lalu meneruskan pesannya ke layanan lain. Ia adalah satu-satunya layanan IoT yang masuk silabus CLF-C02, jadi setiap skenario IoT pada ujian hampir pasti mengarah ke sini.
Kenapa device butuh layanan khusus, bukan sekadar mengirim HTTP ke server biasa? Karena device IoT punya tiga sifat yang merepotkan server konvensional: jumlahnya bisa jutaan, koneksinya sering putus-nyambung (truk masuk terowongan, sensor di pelosok), dan tiap device harus dipercaya secara individual. IoT Core lahir untuk menangani ketiga sifat itu sekaligus, terutama lewat protokol ringan MQTT dan mekanisme state Device Shadow.
Contoh nyata: perusahaan logistik memasang sensor suhu di truk pendingin. Sensor mengirim data ke AWS melalui MQTT. IoT Core menerima pesan, menerapkan aturan, lalu meneruskan data ke layanan analitik, database, alarm, atau fungsi serverless.
Pilih AWS IoT Core saat soal menyebut device IoT, sensor, MQTT, telemetry, device fleet, mutual authentication, atau rule untuk memproses pesan device.
Komponen yang perlu dikenali
- Thing, representasi device di AWS IoT, terdaftar di Registry.
- Certificate dan policy, identitas dan izin untuk device.
- MQTT broker, komponen komunikasi pesan antar device dan cloud.
- Rules engine, aturan untuk memfilter, mentransformasi, dan meneruskan data ke layanan lain.
- Device Shadow, representasi state device sehingga aplikasi dapat membaca atau menetapkan state meski device tidak selalu online.
Protokol dan autentikasi
Menurut FAQ IoT Core, device bisa terhubung lewat MQTT, MQTT over WebSocket, HTTPS, dan LoRaWAN. MQTT adalah protokol andalan karena ringan dan hemat baterai, cocok untuk device kecil yang sering offline. Untuk keamanan, device diautentikasi dengan sertifikat X.509, IAM, atau Amazon Cognito, dan semua trafik dienkripsi dengan TLS. Kata kunci “MQTT” di soal hampir selalu menunjuk IoT Core.
Jebakan klasik: keduanya sama-sama menangani data masuk dalam jumlah besar. Bedanya, IoT Core fokus pada menghubungkan dan mengelola device (identitas, MQTT, Device Shadow), sedangkan Kinesis fokus pada ingest dan proses aliran data skala besar setelah datanya masuk. Kata kunci sensor, MQTT, certificate, device fleet → IoT Core. Kata kunci streaming data, pipeline analitik real-time → Kinesis.
- Menghubungkan dan mengamankan jutaan device fisik.
- Protokol MQTT/HTTPS/LoRaWAN, sertifikat X.509, Device Shadow.
- Cocok saat masalahnya “device-nya bagaimana terhubung dan dipercaya”.
- Kata kunci: sensor, IoT, MQTT, telemetry, device fleet.
- Menampung dan memproses aliran data berskala besar.
- Untuk analitik real-time, log, clickstream, dan pipeline data.
- Cocok saat masalahnya “datanya sudah masuk, lalu diolah bagaimana”.
- Kata kunci: data stream, real-time analytics, ingest pipeline.
AWS Outposts
Analogi: AWS membuka cabang mini di gedung perusahaan, tetapi tetap dikelola dengan pendekatan AWS. Rak servernya dipasang di ruang IT pelanggan, namun kamu memakainya dengan API, console, dan tooling AWS yang sama persis. AWS Outposts adalah cabang mini itu: keluarga layanan terkelola yang membawa infrastruktur dan sebagian layanan AWS ke lokasi on-premises atau edge pelanggan. Di silabus CLF-C02, Outposts duduk di kategori Compute, bukan Networking atau Migration.
Contoh nyata: rumah sakit harus memproses data dekat alat medis karena latensi dan regulasi. Pabrik perlu aplikasi berjalan dekat mesin produksi. Perusahaan punya sistem lama di data center lokal dan aplikasi baru perlu berkomunikasi sangat cepat dengan sistem itu. Outposts cocok untuk kebutuhan hybrid yang harus tetap konsisten dengan AWS Region.
Pilih AWS Outposts saat soal menyebut AWS services on premises, latency sangat rendah ke sistem lokal, local data processing, data residency, atau pengalaman hybrid yang konsisten dengan AWS.
Outposts bukan sekadar migration tool. Ia adalah opsi hybrid untuk menjalankan infrastruktur AWS di lokasi pelanggan ketika workload tidak bisa sepenuhnya pindah ke Region.
Compute Khusus: Lightsail dan AWS Batch
Tidak semua compute harus dimulai dari EC2 detail. Ada skenario yang lebih sederhana, dan ada skenario yang butuh pemrosesan massal.
Amazon Lightsail
Analogi: Lightsail seperti paket kos siap huni. Sudah ada kamar, listrik, dan internet dasar dengan satu harga per bulan, jadi kamu tidak perlu menghitung tagihan air, listrik, dan internet secara terpisah. Cocok untuk mulai cepat, tetapi tidak sefleksibel membangun gedung sendiri dengan EC2, VPC, ALB, RDS, dan layanan lain. Amazon Lightsail adalah paket kos itu: cara sederhana untuk menjalankan virtual private server, database sederhana, storage, container, CDN, load balancer, dan website dengan pengalaman yang lebih mudah daripada menyusun banyak layanan AWS satu per satu.
Contoh nyata: developer ingin meluncurkan WordPress, blog, landing page, aplikasi kecil, atau server sederhana dengan paket bulanan yang mudah dipahami. Lightsail cocok untuk pemula dan workload sederhana.
Pilih Lightsail saat soal menyebut VPS sederhana, website kecil, WordPress cepat, aplikasi sederhana, paket preconfigured, atau user yang ingin pengalaman AWS paling mudah.
Menurut halaman pricing Lightsail, Lightsail memakai harga bundle bulanan tetap dan mudah diprediksi yang sudah memaket vCPU, RAM, storage SSD, kuota data transfer, IP statis, DNS, dan console dalam satu harga. Inilah pembedanya dari EC2 yang menagih banyak komponen terpisah. Kata kunci “harga bulanan tetap, paket sederhana, mudah diprediksi” mengarah ke Lightsail.
AWS Batch
Analogi: Batch seperti manajer antrian pabrik. Kamu menumpuk ribuan pekerjaan di loket masuk, lalu manajer mengatur kapan dan di mana tiap pekerjaan dikerjakan, menyalakan mesin saat antrean panjang dan mematikannya saat sepi. AWS Batch adalah manajer antrian itu: layanan untuk merencanakan, menjadwalkan, dan menjalankan pekerjaan batch containerized pada skala besar, sambil memprovisioning compute (EC2 atau Fargate) sesuai kebutuhan.
Kenapa tidak pakai Lambda atau menyalakan EC2 manual? Karena pekerjaan batch sering berjalan lama (menit sampai jam), perlu dijalankan ribuan kali, dan butuh diatur urutannya. Lambda dibatasi durasi pendek, dan menyalakan EC2 satu per satu tidak praktis untuk ribuan job. Batch dibuat khusus untuk pola “banyak job berat yang antre”.
Contoh nyata: tim riset menjalankan simulasi, rendering, pemrosesan genomik, model training batch, atau analisis ribuan file. Mereka tidak ingin menyalakan server manual satu per satu. AWS Batch mengatur tiga hal inti: job queue (antrean pekerjaan), compute environment (kumpulan compute yang dipakai), dan job definition (cetak biru tiap job).
Pilih AWS Batch saat soal menyebut batch jobs, job queue, pemrosesan ribuan tugas, simulasi, analisis skala besar, ML training batch, atau containerized batch workloads.
Lightsail vs EC2 vs Batch
| Skenario | Pilih | Kenapa |
|---|---|---|
| Website kecil ingin cepat online | Lightsail | Paket sederhana dan preconfigured. |
| Server fleksibel dengan kontrol detail | EC2 | Kontrol instance, jaringan, storage, dan integrasi lebih luas. |
| Ribuan pekerjaan komputasi terjadwal | AWS Batch | Queue, scheduling, dan compute scaling untuk job batch. |
Lambda cocok untuk event-driven function, EC2 cocok untuk server fleksibel, Lightsail cocok untuk kesederhanaan, dan Batch cocok untuk pekerjaan massal yang dijadwalkan.
Kamus Skenario Cepat
Bagian ini adalah inti modul: baca skenario, tangkap kata kunci, pilih layanan.
| Skenario di soal | Layanan | Kata kunci yang perlu diingat |
|---|---|---|
| Mengirim email reset password, invoice, dan newsletter dari aplikasi | Amazon SES | Email transaksional, marketing email, SMTP, deliverability. |
| Membangun cloud contact center untuk telepon dan chat pelanggan | Amazon Connect | Contact center, agent, queue, IVR, routing, customer service. |
| Menyediakan desktop virtual untuk karyawan remote | Amazon WorkSpaces | VDI, cloud desktop, desktop persisten, remote worker. |
| Memberi akses aplikasi desktop tanpa instalasi lokal | Amazon AppStream 2.0 | Application streaming, software trial, training lab. |
| Memberi vendor akses web internal tanpa VPN penuh | Amazon WorkSpaces Secure Browser | Secure browser, web access, SaaS access, data tidak menyentuh device. |
| Deploy aplikasi web/mobile dari Git dengan auth dan backend sederhana | AWS Amplify | Frontend hosting, CI/CD, fullstack app, developer frontend. |
| Membuat GraphQL API untuk mobile app dengan data real-time | AWS AppSync | GraphQL, subscription, WebSocket, managed API. |
| Menghubungkan sensor pabrik ke AWS secara aman | AWS IoT Core | Device, MQTT, certificate, rule engine, telemetry. |
| Meluncurkan WordPress atau VPS sederhana | Amazon Lightsail | VPS, preconfigured, website kecil, paket sederhana. |
| Menjalankan ribuan job simulasi atau analitik | AWS Batch | Batch job, queue, scheduling, containerized workloads. |
| Menjalankan AWS infrastructure di lokasi pelanggan | AWS Outposts | On premises, hybrid, low latency, local data processing, data residency. |
Lingkari kata kerja dalam soal: kirim email, layani pelanggan, beri desktop, stream aplikasi, deploy frontend, buat GraphQL, hubungkan sensor, jalankan batch, atau bawa AWS on premises.
Tambahan pembeda yang sering menolong
SES vs SNS
SES untuk email aplikasi dan deliverability. SNS untuk notifikasi pub/sub ke subscriber.
Connect vs WorkSpaces
Connect untuk agent melayani pelanggan. WorkSpaces untuk desktop virtual karyawan.
AppStream vs WorkSpaces
AppStream streaming aplikasi. WorkSpaces desktop lengkap.
Amplify vs AppSync
Amplify untuk workflow web/mobile. AppSync untuk GraphQL dan real-time API.
IoT Core vs Kinesis
IoT Core menghubungkan device. Kinesis streaming data skala besar.
Lightsail vs Batch
Lightsail untuk server sederhana. Batch untuk pekerjaan komputasi massal yang antre.
Walkthrough Konseptual
Latihan ringan untuk berpikir seperti pembuat keputusan cloud.
Kita akan memakai satu perusahaan fiktif, lalu memilih layanan berdasarkan masalahnya.
Bayangkan perusahaan bernama TokoRapi, sebuah toko online yang berkembang cepat. Timnya punya pelanggan, agent support, developer frontend, gudang dengan sensor suhu, dan job laporan malam. Mereka bertanya: “layanan AWS mana yang perlu kami pilih untuk setiap kebutuhan?”
TokoRapi perlu reset password, invoice, dan email promo. Pilih Amazon SES karena kebutuhan utamanya adalah email dari aplikasi.
TokoRapi ingin pelanggan menghubungi support via telepon dan chat, lalu agent menerima antrean. Pilih Amazon Connect.
Agent kontrak bekerja dari rumah dan butuh desktop standar perusahaan. Pilih Amazon WorkSpaces.
Tim gudang butuh aplikasi desktop lama tanpa instalasi di laptop pribadi. Pilih AppStream 2.0 (kini juga dikenal sebagai WorkSpaces Applications).
Developer ingin deploy aplikasi web dari Git dan menambahkan auth dengan cepat. Pilih AWS Amplify.
Aplikasi mobile butuh GraphQL untuk order, profil, dan status pengiriman real-time. Pilih AWS AppSync.
Sensor suhu gudang mengirim telemetry dengan MQTT dan certificate. Pilih AWS IoT Core.
Setiap malam ribuan file diproses untuk laporan. Pilih AWS Batch bila tugasnya batch containerized dan butuh antrean komputasi.
Walkthrough aman: SES dari sandbox ke produksi
Ini alur konseptual yang bisa kamu pahami tanpa biaya, hanya membaca alurnya. Ia juga melatih kata kunci sandbox yang sering muncul di soal.
Buktikan kepemilikan domain atau alamat email pengirim. Tanpa identity terverifikasi, SES menolak mengirim atas namamu.
Akun baru otomatis di sandbox: hanya bisa kirim ke alamat terverifikasi, maksimal 200 email per 24 jam dan 1 pesan per detik. Cukup untuk uji coba, bukan untuk produksi.
Saat siap mengirim ke publik dengan volume nyata, ajukan keluar dari sandbox. Setelah disetujui, batas tujuan dan volume terangkat.
Reputasi pengirim bergantung pada seberapa sehat pengirimanmu. Bersihkan alamat yang bounce dan tanggapi complaint agar email berikutnya tidak diblokir.
Ambil satu aplikasi yang kamu kenal, lalu tulis 10 kebutuhan bisnisnya. Untuk setiap kebutuhan, pilih satu layanan AWS dan satu alasan sederhana. Lalu uji dirimu: kata kunci mana di tiap kebutuhan yang menjadi penentu jawaban?
Checklist sebelum produksi
- Security, pastikan IAM least privilege, enkripsi, logging, dan audit trail sesuai layanan.
- Region, cek ketersediaan layanan dan kebutuhan residensi data.
- Pricing, pahami unit biaya seperti email, sesi, desktop, request API, pesan IoT, job compute, storage, dan data transfer.
- Operasional, tentukan monitoring, alert, backup, dan proses support.
- Integrasi, cek apakah layanan perlu terhubung ke VPC, directory, identity provider, database, Lambda, atau CloudWatch.
Kesalahan Umum & Jebakan Ujian
Banyak jawaban salah bukan karena tidak tahu AWS, tetapi karena salah membaca kata kunci.
1. Menganggap semua email adalah SNS
SNS bisa mengirim notifikasi ke email subscriber, tetapi itu bukan layanan utama untuk kampanye email, email transaksional, reputasi pengirim, dan deliverability. Untuk email aplikasi berskala, jawab SES.
2. Menganggap semua akses remote adalah WorkSpaces
Remote access punya tiga bentuk. Desktop lengkap berarti WorkSpaces. Aplikasi desktop tertentu berarti AppStream 2.0. Browser aman untuk web berarti WorkSpaces Secure Browser.
3. Menganggap Amplify dan AppSync saling menggantikan
Amplify adalah pengalaman pengembangan web/mobile dan hosting. AppSync adalah managed GraphQL dan real-time API. Jika soal menyebut GraphQL secara eksplisit, AppSync biasanya jawaban kuat.
4. Memilih EC2 untuk semua server kecil
EC2 fleksibel, tetapi untuk skenario “mudah, cepat, VPS, WordPress, paket sederhana”, Lightsail sering lebih tepat di level Cloud Practitioner.
5. Memilih Lambda untuk semua pekerjaan otomatis
Lambda bagus untuk fungsi event-driven. Namun, jika soal menyebut ribuan job batch, antrian job, simulasi, atau analisis skala besar, AWS Batch lebih tepat.
6. Mengira Outposts sama dengan Region baru
Outposts bukan Region publik. Outposts membawa infrastruktur dan layanan AWS ke lokasi pelanggan untuk kebutuhan hybrid, latensi rendah, pemrosesan lokal, atau residensi data.
7. Menukar IoT Core dengan Kinesis
Keduanya menangani data masuk skala besar. IoT Core mengurus cara device terhubung dan dipercaya (MQTT, certificate, Device Shadow). Kinesis mengurus aliran data setelah masuk (analitik real-time, pipeline). Kata kunci sensor dan MQTT mengarah ke IoT Core; kata kunci streaming data dan pipeline mengarah ke Kinesis.
8. Mengira Connect untuk meeting tim internal
Amazon Connect adalah contact center menghadap pelanggan (agent melayani pelanggan), bukan layanan video meeting internal. Layanan meeting internal adalah Amazon Chime, tetapi Chime tidak ada di silabus CLF-C02, jadi skenario “contact center” hampir pasti Connect.
9. Melupakan shared responsibility
Layanan managed tidak berarti pelanggan bebas tanggung jawab. Pelanggan tetap mengatur identitas, konfigurasi akses, data, compliance, dan cara menggunakan layanan secara aman.
Kebutuhan bisnis + kata kunci teknis + batasan operasional = layanan yang paling cocok.
Jebakan yang Paling Sering
- Email marketing atau transaksional: SES, bukan SNS.
- Desktop virtual: WorkSpaces, bukan AppStream 2.0.
- Streaming aplikasi: AppStream 2.0, bukan WorkSpaces.
- GraphQL API: AppSync, bukan Amplify saja.
- Sensor dan MQTT: IoT Core, bukan Kinesis.
- Contact center pelanggan: Connect, bukan Chime (Chime di luar silabus).
- VPS sederhana: Lightsail, bukan selalu EC2.
- Batch job massal: AWS Batch, bukan selalu Lambda.
- AWS on premises: Outposts, bukan sekadar Direct Connect.
Ringkasan & Tips Ujian
Modul ini adalah peta cepat untuk menjawab soal “layanan mana untuk skenario apa”.
Peta layanan satu kalimat
- Amazon SES, layanan email aplikasi untuk email transaksional, marketing, newsletter, SMTP/API, dan deliverability.
- Amazon Connect, cloud contact center untuk telepon, chat, agent, queue, routing, dan layanan pelanggan.
- Amazon WorkSpaces, desktop virtual terkelola untuk karyawan remote atau lingkungan kerja cloud.
- Amazon AppStream 2.0, streaming aplikasi desktop dari cloud tanpa instalasi lokal, kini diposisikan sebagai WorkSpaces applications di halaman produk AWS.
- Amazon WorkSpaces Secure Browser, browser remote terkelola untuk akses web dan SaaS yang lebih terkontrol.
- AWS Amplify, tools dan layanan untuk membangun, hosting, dan deploy aplikasi web/mobile dengan pengalaman frontend.
- AWS AppSync, managed GraphQL dan real-time API untuk aplikasi yang butuh data dari banyak sumber.
- AWS IoT Core, gerbang aman untuk device IoT, MQTT, certificate, telemetry, dan rule pemrosesan pesan.
- Amazon Lightsail, VPS dan resource cloud preconfigured untuk website atau aplikasi sederhana.
- AWS Batch, layanan managed untuk menjadwalkan dan menjalankan job batch containerized pada skala besar.
- AWS Outposts, infrastruktur AWS terkelola di lokasi pelanggan untuk hybrid, latensi rendah, pemrosesan lokal, dan data residency.
Pemetaan ke domain CLF-C02
| Domain | Kaitan modul | Prioritas belajar |
|---|---|---|
| Domain 1: Cloud Concepts (24%) | Memahami nilai cloud: managed service, elastisitas, model hybrid, dan agility untuk aplikasi bisnis. | Sedang. |
| Domain 2: Security & Compliance (30%) | Memahami akses aman, identity, certificate IoT, secure browser, data residency, logging, dan shared responsibility. | Tinggi. |
| Domain 3: Cloud Technology & Services (34%) | Inti modul: memilih layanan dari kategori Business Applications, End User Computing, Frontend Web and Mobile, IoT, dan Compute. | Sangat tinggi. |
| Domain 4: Billing, Pricing & Support (12%) | Memahami pay as you use, unit biaya per layanan, AWS Pricing Calculator, Cost Explorer, Budgets, dan dokumentasi pricing resmi. | Sedang. |
Tips ujian praktis
- Hafalkan pasangan kata kunci dan layanan, bukan semua detail konfigurasi.
- Jika soal menyebut “contact center”, hampir selalu pikirkan Amazon Connect.
- Jika soal menyebut “GraphQL”, pikirkan AWS AppSync lebih dulu.
- Jika soal menyebut “VPS sederhana” atau “WordPress cepat”, pikirkan Lightsail.
- Jika soal menyebut “batch job queue” dan pemrosesan massal, pikirkan AWS Batch.
- Jika soal menyebut “on premises dengan pengalaman AWS”, pikirkan Outposts.
- Untuk pricing, jangan menghafal angka kecuali konteksnya jelas. Biasakan cek halaman pricing resmi karena harga, region, dan free tier bisa berubah.
Di CLF-C02, layanan kecil sering muncul sebagai jawaban besar ketika kata kunci skenarionya tepat.