Other Compute
Services CLF-C02
Setelah memahami EC2, sekarang kita belajar kapan memakai container, serverless, batch, PaaS, dan compute hybrid.
Analogi: Dapur, Koki, dan Layanan Siap Saji
Mulai dari analogi agar pilihan compute terasa masuk akal.
Bayangkan kamu ingin membuka bisnis makanan, pilihan compute AWS mirip cara memilih dapur.
Kalau memakai Amazon EC2, kamu menyewa dapur sendiri. Kamu memilih kompor, mengatur gas, membersihkan lantai, dan memutuskan kapan menambah meja kerja. Ini fleksibel, tetapi tanggung jawab operasionalnya besar.
Kalau memakai Elastic Beanstalk, kamu membawa resep dan bahan utama, lalu pengelola gedung menyiapkan dapur, ventilasi, meja kerja, dan petugas monitoring. Kamu tetap punya dapur di balik layar, tetapi banyak pekerjaan standar dibantu AWS.
Kalau memakai container, kamu mengemas makanan dalam kotak standar. Kotaknya bisa dipindah dari dapur kecil ke dapur besar tanpa banyak perubahan. ECR adalah rak penyimpanan kotak, ECS dan EKS adalah manajer dapur yang menentukan kotak mana dimasak di mana.
Kalau memakai Fargate, kamu tidak lagi memikirkan dapurnya. Kamu hanya bilang, “jalankan kotak ini dengan CPU dan memori sekian.” AWS menyiapkan tempatnya.
Kalau memakai Lambda, kamu tidak membuka dapur sepanjang hari. Kamu hanya memanggil koki saat ada pesanan tertentu, misalnya resize gambar ketika file baru masuk ke S3.
EC2 adalah dapur sewaan, Beanstalk adalah dapur dikelola, container adalah kotak standar, Fargate adalah jalankan kotak tanpa mengurus dapur, Lambda adalah koki on-demand.
Peta Besar Compute Setelah EC2
CLF-C02 menilai kemampuan mengenali layanan yang tepat, bukan menghafal semua konfigurasi teknis.
Di ujian, pertanyaan compute biasanya berbentuk skenario: workload apa, butuh kontrol seberapa besar, dan siapa yang mengelola server?
Panduan resmi CLF-C02 memasukkan AWS Batch, Amazon EC2, AWS Elastic Beanstalk, Amazon Lightsail, AWS Outposts, Amazon ECR, Amazon ECS, Amazon EKS, AWS Fargate, dan AWS Lambda dalam cakupan layanan terkait compute, container, dan serverless. Lihat daftar resminya di In-Scope AWS Services.
Domain 3 CLF-C02 meminta peserta mengenali layanan compute, opsi container seperti ECS dan EKS, serta opsi serverless seperti Fargate dan Lambda. Lihat Domain 3: Cloud Technology and Services.
Kontrol tinggi
Pilih EC2 atau Outposts saat kamu perlu mengatur sistem operasi, tipe instance, jaringan, atau lokasi fisik lebih detail.
Deploy lebih mudah
Pilih Elastic Beanstalk atau Lightsail saat tujuan utamanya menjalankan aplikasi web dengan lebih sedikit keputusan infrastruktur.
Abstraksi tinggi
Pilih Fargate atau Lambda saat ingin fokus pada container atau fungsi, bukan pada pengelolaan server.
CLF-C02 jarang meminta cara menulis task definition atau manifest Kubernetes, tetapi sering menguji kapan memilih ECS, EKS, Fargate, Lambda, Batch, Beanstalk, Lightsail, atau Outposts.
Container: ECR, ECS, dan EKS
Container membuat aplikasi mudah dipaketkan, dipindahkan, dan dijalankan konsisten.
Container adalah paket standar yang berisi aplikasi beserta dependensinya, seperti kotak makanan yang sudah diberi label isi dan cara pemanasan.
Kenapa container penting? Karena ia menyelesaikan keluhan klasik “di laptop saya jalan, di server kok error”. Aplikasi, library, versi runtime, dan konfigurasi dikemas jadi satu image yang berperilaku sama di mana pun dijalankan. Untuk tiga huruf yang sering tertukar di ujian, ingat satu kalimat: ECR menyimpan image, ECS dan EKS mengatur container, dan launch type (Fargate atau EC2) menentukan di mana container benar-benar berjalan.
Amazon ECR adalah managed container image registry untuk menyimpan dan membagikan image container. ECR mendukung private repository (akses diatur lewat IAM) dan public repository lewat Amazon ECR Public, sehingga bisa juga untuk berbagi image ke publik. ECR menerima Docker image, OCI image, dan artifact yang OCI-compatible. Jadi ECR bukan sekadar “private registry”, melainkan registry yang bisa privat maupun publik. Lihat What is Amazon ECR?.
Amazon ECS adalah layanan orkestrasi container fully managed, bukan compute engine. Tugasnya menjawab “siapa yang mengatur container”: berapa salinan harus hidup, mengganti container yang gagal, dan mengarahkan traffic. ECS dapat memakai beberapa backend compute, yaitu Fargate (serverless), EC2, ECS Managed Instances, dan ECS Anywhere untuk on-premises. Karena ECS adalah orchestrator, ia tidak bisa dibandingkan langsung dengan Fargate yang merupakan compute engine. Lihat What is Amazon ECS?.
Amazon EKS adalah managed Kubernetes service. Pilih EKS ketika organisasi sudah memakai Kubernetes, punya tim yang memahami ekosistemnya, atau butuh portabilitas tooling Kubernetes lintas lingkungan. EKS juga bisa menjalankan pod tanpa mengelola node lewat Fargate. Lihat What is Amazon EKS?.
Urutan kerja container sederhana
Developer membuat container image dari aplikasi, dependensi, dan konfigurasi runtime di mesinnya atau di pipeline CI/CD.
Image didorong ke repository ECR, privat untuk internal atau publik lewat ECR Public, agar bisa ditarik oleh layanan compute AWS.
Orchestrator menarik image lalu menentukan berapa banyak salinan container berjalan dan bagaimana traffic diarahkan.
Tentukan apakah container berjalan di Fargate (tanpa server yang kamu kelola) atau di EC2 (kamu mengurus host).
Gunakan CloudWatch, load balancer, dan Auto Scaling agar aplikasi tetap responsif saat traffic berubah.
ECS vs EKS, dua orchestrator yang sering tertukar
Keduanya sama-sama mengatur container, bedanya pada cara berpikir dan ekosistemnya, bukan pada “mana yang lebih bagus”.
- Orchestrator AWS-native, lebih sederhana untuk dimulai.
- Konsep inti: task definition dan service, bukan manifest Kubernetes.
- Cocok bila tim ingin menjalankan container tanpa belajar Kubernetes.
- Backend compute: Fargate, EC2, Managed Instances, atau ECS Anywhere.
- Managed Kubernetes, kompatibel dengan tooling Kubernetes standar.
- Konsep inti: pod, deployment, dan manifest YAML Kubernetes.
- Cocok bila organisasi sudah standar di Kubernetes lintas cloud.
- Backend compute: Fargate atau EC2 sebagai node.
ECR menyimpan image container, ECS dan EKS mengorkestrasi container, dan keduanya bisa memakai Fargate atau EC2 sebagai tempat container berjalan.
AWS Fargate: Container Tanpa Mengelola Server
Fargate adalah compute engine serverless untuk container, bukan orchestrator baru.
Fargate ibarat meminta dapur hotel memasak paket makananmu tanpa kamu menyewa dan merawat dapur sendiri.
AWS Fargate adalah compute engine serverless dengan model pay-as-you-go untuk container. Ia dipakai bersama ECS atau EKS untuk menjalankan container tanpa mengelola server atau cluster EC2. Dokumentasi AWS menyatakan Fargate menghilangkan kebutuhan memilih tipe server, menentukan kapan scale cluster, atau mengoptimalkan penempatan container. Lihat AWS Fargate for Amazon ECS.
Penting untuk tidak menukar peran: ECS dan EKS adalah orchestrator yang menjawab “siapa yang mengatur container”, sedangkan Fargate adalah compute engine yang menjawab “di mana container berjalan”. Jadi Fargate bukan orchestrator baru dan bukan pengganti Kubernetes, melainkan launch type yang dipakai di bawah ECS atau EKS.
Saat memakai Fargate, kamu tetap mendefinisikan image container, CPU, memori, networking, dan IAM policy. Bedanya, kamu tidak lagi memilih tipe instance, mem-patch sistem operasi host, atau merencanakan kapasitas cluster EC2.
Pakai Fargate jika
Tim ingin menjalankan container tanpa patching host, capacity planning, dan pengelolaan cluster EC2, serta nyaman membayar per task yang berjalan.
Pakai EC2 launch type jika
Tim butuh kontrol lebih rinci atas instance, tipe hardware tertentu seperti GPU, optimasi biaya khusus (misalnya Reserved atau Spot di skala besar), atau konfigurasi host.
Lambda vs Fargate, dua wajah “serverless”
Keduanya sama-sama menghilangkan pengelolaan server, tetapi unit kerjanya berbeda: Lambda menjalankan fungsi, Fargate menjalankan container. Soal CLF-C02 sering menguji perbedaan ini lewat bentuk workload.
- Unit kerja: fungsi yang dipicu event (S3, API Gateway, SQS, jadwal).
- Cocok untuk proses singkat, maksimum 900 detik (15 menit) per invocation.
- Scale otomatis dari nol sampai banyak invocation, tanpa kapasitas idle.
- Tidak perlu memikirkan image OS, cukup kode, memori, dan timeout.
- Unit kerja: container yang dipaketkan sebagai image, dijalankan terus.
- Cocok untuk service long-running seperti API atau worker yang selalu hidup.
- Scale dengan menambah task melalui ECS atau EKS dan load balancer.
- Kamu mengontrol image container, CPU, dan memori per task.
Jika soal bilang “jalankan fungsi singkat saat ada event”, pikirkan Lambda; jika bilang “jalankan container yang sudah dipaketkan tanpa mengelola server”, pikirkan Fargate.
AWS Lambda: Fungsi Kecil yang Jalan Saat Dipanggil
Lambda cocok untuk event-driven compute, otomatis scale, dan bayar sesuai pemakaian.
Lambda mirip bel layanan hotel, petugas datang ketika tombol ditekan, mengerjakan tugas singkat, lalu pergi.
AWS Lambda adalah layanan compute yang menjalankan kode tanpa perlu mengelola server. Kode dapat scale naik dan turun otomatis, dengan model pay-per-use. Lihat What is AWS Lambda?.
Lambda sangat cocok untuk tugas yang dipicu event, misalnya file baru masuk ke S3, pesan masuk ke SQS, perubahan data di DynamoDB, jadwal tertentu, atau request dari API Gateway.
Batas praktik yang perlu diingat
Batasan Lambda sering muncul sebagai jebakan halus di CLF-C02, jadi kenali angka kuncinya. Kamu tidak perlu menghafal semua, cukup ingat polanya: Lambda dibuat untuk tugas singkat, kecil, dan event-driven, bukan workload berat yang berjalan lama.
Lambda memiliki timeout default 3 detik dan dapat diatur sampai maksimum 900 detik (15 menit). Tidak ada cara menaikkan timeout di atas 900 detik, jadi proses yang lebih panjang harus dipindah ke Fargate, ECS, AWS Batch, atau EC2. Lihat Configure Lambda function timeout.
Memori Lambda dapat diatur dari 128 MB sampai 10.240 MB (10 GB) dengan increment 1 MB, dan alokasi CPU mengikuti memori (sekitar setara 1 vCPU pada 1.769 MB). Lambda juga menyediakan ephemeral storage di direktori /tmp, dengan minimum sekaligus default 512 MB dan dapat dinaikkan sampai 10.240 MB (10 GB). Storage di atas 512 MB dikenakan biaya tambahan. /tmp berguna untuk proses sementara seperti ETL ringan, pemrosesan gambar, atau file sementara. Lihat Configure ephemeral storage for Lambda functions dan Lambda quotas.
Secara default, satu akun punya batas 1.000 concurrent executions per Region dan 75 GB code storage per akun per Region, dan keduanya bisa dinaikkan lewat permintaan kuota. Inti praktisnya: Lambda scale otomatis, tetapi tetap ada plafon konkruensi yang dijaga agar aman.
Event singkat
Resize gambar, validasi data, webhook, transformasi file kecil, dan otomatisasi operasional.
Scale otomatis
Lambda cocok ketika beban datang tidak menentu dan kamu tidak ingin server idle membayar saat sepi.
Bukan untuk semua hal
Jika proses sangat lama, stateful, butuh GPU, atau perlu kontrol host, pertimbangkan ECS, Fargate, Batch, atau EC2.
Jika soal menyebut tugas berjalan lebih dari 15 menit, butuh GPU khusus, atau perlu mengelola OS, Lambda biasanya bukan jawaban terbaik. Angka 3 detik (default) dan 900 detik (maksimum) sering jadi pengecoh.
API Gateway dan Pola Event-Driven
Serverless sering berarti beberapa layanan kecil yang saling terhubung melalui event.
API Gateway adalah resepsionis API, ia menerima tamu, memeriksa aturan, lalu meneruskan permintaan ke backend seperti Lambda.
Amazon API Gateway adalah layanan untuk membuat, menerbitkan, memelihara, memonitor, dan mengamankan API pada skala besar. Ia mendukung tiga tipe API: REST API, HTTP API, dan WebSocket API. Lihat Amazon API Gateway documentation.
Perlu dicatat, REST API dan HTTP API adalah dua jenis RESTful API yang berbeda, bukan sinonim. REST API adalah versi lebih lama dengan fitur paling lengkap, sedangkan HTTP API lebih baru, lebih cepat, dan biasanya lebih hemat untuk kasus umum. Untuk CLF-C02 cukup mengenali bahwa keduanya ada dan berbeda, tanpa menghafal daftar fitur per jenis.
Dalam arsitektur serverless, API Gateway sering menjadi pintu depan (front door) untuk Lambda. Namun Lambda juga bisa dipicu oleh layanan lain, misalnya S3, EventBridge, SQS, SNS, DynamoDB Streams, atau jadwal tertentu.
Pola yang sering muncul
Browser memanggil API Gateway, API Gateway memanggil Lambda, Lambda mengembalikan response.
S3 atau EventBridge memicu Lambda, Lambda memproses data tanpa menunggu pengguna di depan layar.
SQS menahan pesan agar Lambda atau container dapat memproses pekerjaan secara stabil.
Serverless bukan berarti tidak ada server sama sekali, tetapi servernya dikelola AWS dan kamu fokus pada fungsi, event, serta konfigurasi keamanan.
Batch, Elastic Beanstalk, Lightsail, dan Outposts
Empat layanan ini sering keluar sebagai jawaban skenario yang mirip tetapi tujuannya berbeda.
Tidak semua pekerjaan cocok menjadi web server atau fungsi singkat, beberapa butuh antrean job, platform siap pakai, paket sederhana, atau lokasi on-premises.
AWS Batch
Layanan fully managed untuk menjalankan batch computing workloads, cocok untuk job besar seperti simulasi, analitik, dan ML batch. Batch tidak punya compute sendiri, melainkan memakai ECS, EKS, Fargate, dan EC2 (On-Demand atau Spot) sebagai backend. Lihat What is AWS Batch?.
Elastic Beanstalk
Layanan yang menyederhanakan deployment aplikasi web, menyediakan EC2, load balancing, health monitoring, dan scaling otomatis. Mendukung Go, Java, .NET, Node.js, PHP, Python, Ruby, dan Docker. Lihat What is Elastic Beanstalk?.
Amazon Lightsail
Cara mudah memulai website atau web app dengan paket sederhana seperti VPS, container service, managed database, CDN, load balancer, storage, static IP, DNS, dan snapshot, dengan harga bulanan tetap. Lihat What is Amazon Lightsail?.
AWS Outposts
Layanan fully managed yang membawa infrastruktur dan API AWS ke lokasi on-premises pelanggan, tersedia sebagai Outposts racks (42U) dan Outposts servers (1U/2U). Lihat What is AWS Outposts?.
Catatan penting tiap layanan
AWS Batch bukan pengganti Lambda atau ECS, melainkan lapisan orkestrasi job di atasnya. Kamu mengirim job ke job queue, dan Batch memilih kapan serta di mana menjalankannya memakai ECS, EKS, Fargate, atau EC2. Karena bisa memakai EC2 Spot, Batch sering jadi cara hemat untuk job besar yang tahan interupsi.
Elastic Beanstalk populer disebut PaaS di komunitas, tetapi dokumentasi AWS lebih sering menyebutnya sebagai layanan yang menyederhanakan deployment dengan provisioning otomatis. Untuk CLF-C02, fokuslah pada idenya: kamu unggah kode, AWS menyiapkan dan mengelola resource standar di baliknya. Tidak ada biaya layanan Beanstalk itu sendiri, kamu hanya membayar resource AWS yang dipakai.
Amazon Lightsail menonjol karena harga bulanan tetap yang mudah diprediksi, dengan compute, storage, dan sebagian transfer data sudah dibundel. Cocok untuk pemula dan proyek kecil, tetapi kurang fleksibel dibanding EC2 dan ECS untuk arsitektur kompleks.
AWS Outposts menjalankan EC2, ECS, EBS, S3, RDS, dan lainnya secara on-premises memakai API AWS yang sama seperti di Region. Satu hal yang sering jadi jebakan: EKS hanya didukung pada Outposts racks, bukan pada Outposts servers yang lebih kecil. Harga Outposts bergantung konfigurasi order, term kontrak, dan opsi pembayaran, jadi verifikasi langsung di halaman pricing AWS sebelum komitmen.
Bedakan dengan cepat
| Layanan | Gunakan ketika | Kata kunci ujian |
|---|---|---|
| AWS Batch | Pekerjaan batch, job queue, komputasi besar, pemrosesan periodik. | batch jobs, simulation, scheduled processing, ML batch. |
| Elastic Beanstalk | Developer ingin upload kode web app dan AWS mengelola resource standar. | easy deployment, web app, managed platform, underlying resources. |
| Lightsail | Pemula atau bisnis kecil ingin paket VPS sederhana dan harga lebih mudah diprediksi. | simple website, predictable monthly price, all-in-one bundle. |
| Outposts | Butuh menjalankan layanan AWS di on-premises karena latency, data locality, atau integrasi fasilitas lokal. | on premises, hybrid, local processing, same AWS APIs. |
Elastic Beanstalk tidak menambahkan biaya layanan platform tersendiri, tetapi resource di baliknya seperti EC2, load balancer, database, dan storage tetap ditagihkan.
Cara Memilih Layanan di Skenario Nyata
Mulai dari pertanyaan bisnis, bukan dari nama layanan.
Di dunia nyata, pilihan compute yang benar adalah yang paling sederhana memenuhi kebutuhan kontrol, skala, biaya, keamanan, dan skill tim.
Checklist keputusan
Apakah web app, API, fungsi event-driven, container, batch job, atau workload hybrid di lokasi fisik?
Apakah proses singkat dan event-based, berjalan terus, atau job panjang yang bisa masuk antrean?
Apakah perlu mengatur OS dan instance, atau cukup mendefinisikan kode, container, CPU, memori, dan event?
Apakah tim nyaman dengan Kubernetes, cukup dengan ECS, atau lebih cocok memakai Beanstalk dan Lightsail?
Apakah ingin pay-per-use, kapasitas selalu berjalan, Spot untuk job interupsi, atau paket bulanan yang mudah diprediksi?
Startup membuat API kecil
API Gateway + Lambda cocok jika traffic belum stabil, proses singkat, dan tim ingin minim server.
Perusahaan punya aplikasi Docker
ECR + ECS cocok jika ingin orkestrasi container AWS-native tanpa kompleksitas Kubernetes penuh.
Platform sudah Kubernetes
EKS cocok jika organisasi sudah punya pipeline, observability, dan deployment standard berbasis Kubernetes.
Riset menjalankan simulasi malam hari
AWS Batch cocok karena job bisa diantrikan, dijadwalkan, dan dijalankan dengan compute sesuai kebutuhan.
Untuk CLF-C02, jawaban terbaik biasanya layanan yang paling managed dan paling cocok dengan kata kunci skenario, bukan layanan yang paling fleksibel.
Keamanan, Observability, dan Shared Responsibility
Semakin managed layanannya, semakin banyak pekerjaan infrastruktur ditangani AWS, tetapi keamanan aplikasi tetap milik pelanggan.
Managed service bukan kartu bebas dari tanggung jawab, ia hanya memindahkan sebagian pekerjaan operasional ke AWS.
Pada Lambda, AWS mengelola infrastruktur runtime, tetapi kamu tetap bertanggung jawab atas kode, IAM role, environment variable, dependency, logging, dan akses ke data.
Pada ECS atau EKS di EC2, kamu punya tanggung jawab lebih besar atas host EC2, patching, kapasitas, dan konfigurasi jaringan. Pada Fargate, AWS lebih banyak mengurus host, tetapi kamu tetap mengatur image, task role, secrets, network, dan izin.
Pada ECR, perhatikan permission push/pull, image scanning, lifecycle policy, dan integrasi CI/CD. Image container yang usang atau berisi secret adalah risiko keamanan nyata.
Pada API Gateway, perhatikan authentication, authorization, throttling, logging, dan integrasi dengan backend. API yang terbuka tanpa kontrol ibarat pintu toko tanpa penjaga.
Observability minimum
CloudWatch Logs
Tempat umum melihat log Lambda, ECS, dan aplikasi agar error tidak hanya terasa oleh pengguna.
CloudWatch Metrics
Pantau invocations, errors, duration, throttles, CPU, memory, dan sinyal kapasitas sesuai layanan.
AWS X-Ray
Bantu tracing request lintas API, Lambda, dan service lain saat aplikasi semakin terdistribusi.
Jangan memberi role Lambda atau task ECS izin terlalu luas seperti akses penuh ke semua S3 bucket hanya karena aplikasi butuh satu bucket.
Hands-on Ringan: Rancang Tanpa Menekan Tombol
Latihan konseptual ini melatih pola pikir layanan, bukan langkah klik yang mudah berubah di console.
Bayangkan kamu diminta merancang fitur upload gambar untuk toko online kecil.
Skenario A: Serverless thumbnail
Pengguna mengunggah gambar produk ke bucket S3 melalui aplikasi.
Lambda berjalan hanya saat file baru masuk, lalu membuat thumbnail.
Thumbnail disimpan ke prefix berbeda agar aplikasi bisa menampilkan gambar ringan.
Jika resize gagal, tim melihat error dan durasi fungsi melalui CloudWatch Logs dan Metrics.
Skenario B: Container API
Tim membuat image container aplikasi dan menyimpannya di Amazon ECR.
ECS menjaga beberapa task tetap berjalan dan mengganti task yang gagal.
Fargate dipilih agar tim tidak mengelola EC2 host untuk container.
Traffic pengguna diarahkan ke service secara stabil, lalu kapasitas bisa diskalakan sesuai kebutuhan.
Jika kata kunci soal adalah “jalankan kode saat file masuk S3”, pikirkan Lambda; jika “jalankan container tanpa mengelola server”, pikirkan Fargate.
Kesalahan Pemula dan Jebakan Soal
Bagian ini membantu menghindari jawaban yang terlihat benar tetapi tidak paling cocok.
Banyak soal compute CLF-C02 terasa mudah, tetapi sengaja memakai kata kunci yang mirip.
ECR bukan tempat menjalankan container
ECR adalah registry image yang bisa privat maupun publik. Untuk menjalankan container, gunakan ECS, EKS, atau layanan lain yang mendukung container.
ECS itu orchestrator, bukan compute engine
ECS dan EKS mengatur container, sedangkan Fargate dan EC2 adalah tempat container berjalan. Jangan tukarkan peran orchestrator dan compute engine.
Fargate bukan pengganti Kubernetes
Fargate adalah compute engine serverless untuk container yang dipakai di bawah ECS atau EKS, sedangkan EKS adalah managed Kubernetes service.
Lambda bukan server web biasa
Lambda cocok untuk event dan proses singkat, bukan workload long-running yang perlu host selalu hidup.
Lightsail bukan pilihan enterprise paling fleksibel
Lightsail unggul untuk kesederhanaan dan prediktabilitas, tetapi EC2, ECS, EKS, atau Beanstalk lebih fleksibel untuk arsitektur kompleks.
Batch bukan database analytics
AWS Batch menjalankan job komputasi batch, sedangkan Athena, EMR, Redshift, dan Glue berada di ranah analytics yang berbeda.
Beanstalk tetap memakai resource AWS
Beanstalk menyederhanakan deployment, tetapi resource di baliknya tetap perlu dipahami dari sisi biaya dan konfigurasi.
Kata kunci cepat
| Kata kunci soal | Jawaban yang sering tepat | Kenapa |
|---|---|---|
| Event, fungsi, tidak mengelola server, trigger S3. | AWS Lambda | Compute serverless berbasis event. |
| Container, tidak ingin mengelola EC2 host. | AWS Fargate | Menjalankan container tanpa server yang dikelola pelanggan. |
| Orkestrasi container AWS-native. | Amazon ECS | Managed container orchestration di AWS. |
| Kubernetes managed. | Amazon EKS | Menjalankan Kubernetes tanpa mengelola control plane sendiri. |
| Simpan image Docker atau OCI. | Amazon ECR | Managed container registry. |
| Batch jobs skala besar. | AWS Batch | Mengelola antrean dan eksekusi job batch. |
| Upload kode web app, AWS siapkan environment. | Elastic Beanstalk | Menyederhanakan deployment aplikasi web dengan provisioning otomatis. |
| Website sederhana, paket VPS mudah. | Amazon Lightsail | Pengalaman sederhana dengan harga lebih mudah diprediksi. |
| AWS services di data center sendiri. | AWS Outposts | Hybrid cloud untuk lokasi pelanggan. |
Serverless di AWS bisa berarti Lambda untuk fungsi atau Fargate untuk container, jadi baca bentuk workload sebelum memilih.
Ringkasan & Tips Ujian
Pemetaan akhir ke domain CLF-C02.
Other Compute Services membantu kamu menjawab satu pertanyaan besar: beban kerja ini sebaiknya dijalankan di mana?
Poin Penting
- Lambda cocok untuk fungsi event-driven, proses singkat, scale otomatis, dan minim server management.
- Fargate menjalankan container tanpa mengelola server, biasanya bersama ECS atau EKS.
- ECR menyimpan image container, ECS mengorkestrasi container AWS-native, dan EKS menjalankan Kubernetes terkelola.
- AWS Batch cocok untuk batch job, simulasi, analitik, dan workload komputasi yang bisa diantrikan.
- Elastic Beanstalk menyederhanakan deployment web app, tetapi resource underlying tetap ada dan tetap ditagihkan.
- Lightsail cocok untuk website atau aplikasi sederhana yang butuh paket mudah dan prediktabel.
- Outposts membawa pengalaman AWS ke lokasi on-premises untuk kebutuhan hybrid, latency lokal, atau data locality.
Pemetaan domain CLF-C02
| Domain | Bobot | Hubungan dengan modul ini |
|---|---|---|
| Domain 1, Cloud Concepts | 24% | Memahami elasticity, managed services, dan value proposition serverless. |
| Domain 2, Security and Compliance | 30% | Memahami IAM roles, least privilege, shared responsibility, secrets, image security, dan API protection. |
| Domain 3, Cloud Technology and Services | 34% | Fokus utama modul, mengenali layanan compute, container, serverless, batch, PaaS, dan hybrid. |
| Domain 4, Billing, Pricing, and Support | 12% | Membedakan pay-per-use, resource underlying, kapasitas berjalan, dan paket harga yang lebih prediktabel tanpa menghafal angka. |
Tips ujian cepat
- Jika soal berkata “tanpa mengelola server” dan workload adalah fungsi, pilih Lambda; jika workload adalah container, pilih Fargate.
- Jika soal berkata “Kubernetes”, pilih EKS, bukan ECS.
- Jika soal berkata “registry untuk image container”, pilih ECR, bukan ECS.
- Jika soal berkata “batch jobs” atau “job queue”, pilih AWS Batch.
- Jika soal berkata “deploy web app dengan AWS mengurus load balancing, scaling, dan health monitoring”, pilih Elastic Beanstalk.
- Jika soal berkata “website sederhana untuk pemula dengan paket mudah diprediksi”, pilih Lightsail.
- Jika soal berkata “AWS di on-premises”, pilih Outposts.
Untuk Cloud Practitioner, hafalkan hubungan layanan dan skenario bisnisnya, bukan konfigurasi teknis terdalam.