Mulai dari analogi, lalu definisi dan konteks ujian.

Bayangkan data perusahaan seperti bahan makanan di restoran: ada bahan yang harus cepat diambil, ada yang disimpan rapi, ada yang dianalisis untuk menentukan menu besok.

Kalau semua bahan ditaruh di satu rak, dapur akan kacau. Bumbu harian perlu dekat kompor, stok beras perlu gudang, data penjualan perlu laporan, dan riwayat sensor perlu rak khusus berdasarkan waktu. Di AWS, ide yang sama disebut purpose-built database dan analytics services: pilih layanan sesuai bentuk data, pola akses, kebutuhan skala, dan tujuan bisnis. Kenapa AWS repot menyediakan belasan layanan database, bukan satu database raksasa serbaguna? Karena tidak ada satu mesin yang optimal untuk semua pola sekaligus. Database yang jago transaksi cepat justru lambat saat diminta menjumlahkan satu miliar baris; database analitik yang jago menjumlahkan justru boros saat hanya mengubah satu baris pesanan. Memaksa satu alat untuk semua pekerjaan adalah resep lambat dan mahal.

Untuk CLF-C02, kamu tidak diminta menjadi database administrator mendalam. Kamu perlu tahu layanan mana untuk kasus apa, apa bedanya database operasional dan analytics, serta mana yang dikelola AWS versus tetap menjadi tanggung jawab pelanggan. AWS sendiri menempatkan database, migration, dan core service selection sebagai bagian dari kemampuan Cloud Practitioner untuk memposisikan layanan inti AWS pada use case umum.

Definisi sederhana

Database adalah tempat menyimpan dan mengambil data untuk aplikasi. Analytics adalah proses mengubah data menjadi insight, misalnya tren penjualan, pola fraud, atau laporan operasional. Di AWS, sebagian layanan fokus ke transaksi harian, sebagian fokus ke query besar, sebagian fokus ke migrasi, katalog, dan visualisasi. Membedakan dua dunia ini, transaksi versus analitik, adalah kunci membaca soal CLF-C02 dengan tenang.

Kenapa topik ini penting di CLF-C02?

CLF-C02 menekankan kemampuan mengenali layanan inti, memilih layanan untuk skenario umum, memahami keamanan dasar, dan memahami model biaya tingkat tinggi. Database dan analytics masuk terutama ke Domain 3 Cloud Technology and Services (34% soal), tetapi juga menyentuh Domain 2 Security and Compliance dan Domain 4 Billing, Pricing, and Support.

Mulai dari pertanyaan bisnis, bukan dari nama layanan.

Pertanyaan terbaik bukan “database AWS mana yang paling bagus?”, tetapi “data ini bentuknya apa dan akan dipakai bagaimana?”.

AWS menyediakan banyak layanan karena pola data berbeda-beda. Data order e-commerce biasanya butuh relasi dan transaksi. Keranjang belanja butuh akses sangat cepat. Log klik dari jutaan pengguna butuh analitik skala besar. Relasi teman, rekomendasi, dan fraud ring lebih cocok ke graph. Sensor suhu lebih cocok ke time series. Begitu kamu menamai bentuk data dan pola aksesnya, layanan yang tepat hampir selalu muncul sendiri.

Pola pemilihan layanan

Dua sumbu pemilihan yang paling sering ditanya

Banyak soal sebenarnya menguji satu dari dua perbandingan besar: relasional versus NoSQL, dan transaksi (OLTP) versus analitik (OLAP). Kuasai dua sumbu ini dan sebagian besar skenario database langsung jelas.

Untuk aplikasi yang butuh tabel, SQL, transaksi, dan integritas data.

Database relasional seperti buku besar akuntansi: kolomnya jelas, barisnya rapi, dan transaksi harus konsisten.

Amazon RDS adalah layanan database relasional terkelola yang memudahkan setup, operasi, dan scaling database di AWS. RDS menangani banyak tugas administrasi seperti patching, backup, failure detection, dan recovery, sehingga timmu tidak menghabiskan waktu untuk pekerjaan yang tidak membedakan bisnis. RDS mendukung enam engine: IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database, dan PostgreSQL.

Amazon Aurora adalah engine relasional fully managed yang kompatibel dengan MySQL dan PostgreSQL, berada di bawah payung Amazon RDS namun dirancang khusus untuk cloud. Untuk ujian, ingat bahwa Aurora bukan sekadar “RDS biasa”, melainkan engine database AWS dengan arsitektur storage terdistribusi yang dirancang untuk performa, ketersediaan, dan skalabilitas tinggi, sambil tetap memakai ekosistem MySQL atau PostgreSQL. Volume penyimpanan Aurora tumbuh otomatis sesuai kebutuhan, tanpa provisioning di muka, hingga maksimum sekitar 256 TiB per cluster.

Kapan dipakai?

• Order e-commerce, pembayaran, inventori, sistem HR, atau aplikasi bisnis yang butuh transaksi dan relasi antar tabel.
• Aplikasi yang ingin tetap memakai SQL dan tool database yang sudah dikenal tim.
• Workload yang ingin mengurangi beban operasional dibanding mengelola database sendiri di EC2.

RDS terkelola versus database di EC2

Kamu tetap boleh memasang MySQL atau PostgreSQL sendiri di atas EC2. Bedanya, pada EC2 kamu yang mengurus instalasi engine, patch database, backup, replikasi, failover, dan tuning. Pada RDS, AWS menangani sebagian besar pekerjaan itu. Pilih EC2 hanya jika butuh kontrol penuh atas versi, ekstensi khusus, atau konfigurasi sistem operasi yang tidak didukung RDS.

Single-AZ, Multi-AZ, Read Replica, Aurora Global Database, dan Aurora Serverless dalam bahasa pemula.

Opsi deployment database mirip memilih toko: satu toko hemat, cabang cadangan lebih tahan gangguan, cabang baca membantu antrean pelanggan.

Untuk Cloud Practitioner, kamu tidak perlu menghafal semua parameter. Yang penting adalah tahu tujuan setiap opsi deployment dan apa yang dioptimalkannya: ketersediaan, kapasitas baca, jangkauan global, atau elastisitas kapasitas.

Dua jenis Multi-AZ yang berbeda

RDS punya dua bentuk Multi-AZ yang sering tertukar, dan keduanya valid untuk CLF-C02. Bedanya terletak pada apakah salinan kedua bisa melayani lalu lintas baca.

Aurora Replicas bukan RDS Read Replicas

Ini perbedaan halus yang sering disalahpahami. RDS Read Replicas memakai replikasi asinkron dan punya storage terpisah dari primary, sehingga bisa ada jeda data dan failover relatif lebih lambat. Aurora Replicas berbagi satu storage terdistribusi yang sama dengan writer, sehingga tidak ada penyalinan data antar node, jeda sangat kecil, dan failover bisa terjadi dalam hitungan puluhan detik. Aurora cluster mendukung hingga 15 Aurora Replicas yang juga berperan sebagai target failover.

Serverless di database

Aurora Serverless v2 menjalankan Aurora dengan kapasitas yang menyesuaikan kebutuhan secara otomatis dalam satuan ACU (Aurora Capacity Units), tanpa mengelola ukuran instance secara manual. Ini cocok untuk workload variabel, development, testing, atau aplikasi dengan lonjakan yang tidak stabil. Aurora Serverless v2 bahkan dapat menjadi reader di Region sekunder pada Aurora Global Database. Untuk ujian, cukup kenali ide besarnya: kapasitas database dapat menyesuaikan demand.

Untuk data panas yang harus diambil sangat cepat.

Cache seperti catatan pesanan yang ditempel di dekat kasir: bukan sumber kebenaran utama, tetapi mempercepat pekerjaan yang sering diulang.

Amazon ElastiCache adalah layanan terkelola untuk cache in-memory. AWS mendokumentasikan ElastiCache sebagai layanan yang memudahkan setup, pengelolaan, dan scaling lingkungan cache terdistribusi di cloud. Engine yang didukung mencakup Valkey, Redis OSS, dan Memcached. Perhatikan penamaannya: AWS menyebut “Redis OSS” (bukan sekadar “Redis”) untuk membedakan dari layanan Redis berbayar, sedangkan Valkey adalah fork open-source dari Redis yang menjadi engine tersendiri, bukan bagian dari Redis OSS.

Kapan dipakai?

• Menyimpan session login, token sementara, hasil query populer, leaderboard game, atau data yang sering dibaca.
• Mengurangi beban database utama karena request yang sama tidak perlu selalu membaca RDS atau DynamoDB.
• Memperbaiki latency aplikasi saat data dapat disimpan sementara di memori dan diambil dalam milidetik.

Untuk skala besar, latency rendah, dan akses berdasarkan key.

DynamoDB seperti loker otomatis: masukkan nomor kunci, barang langsung ditemukan tanpa perlu mencari seluruh gudang.

Amazon DynamoDB adalah database NoSQL fully managed dan serverless. AWS menjelaskan DynamoDB sebagai layanan yang menghilangkan beban administrasi database terdistribusi seperti provisioning hardware, setup, konfigurasi, replikasi, patching, dan scaling cluster. Kamu cukup memikirkan data dan pola aksesnya, sisanya ditangani AWS.

Konsep utama

• Table: tempat kumpulan item.
• Item: satu record, mirip satu baris, tetapi fleksibel dan boleh punya atribut berbeda.
• Attribute: field di dalam item.
• Primary key: cara utama menemukan item, bisa partition key saja atau partition key plus sort key.
• Capacity mode: cara membaca dan menulis dibayar dan diskalakan, misalnya on-demand untuk pola tidak menentu atau provisioned untuk pola stabil.

Global Tables

DynamoDB Global Tables mereplikasi data tabel antar AWS Region. AWS mendokumentasikan global tables sebagai replikasi multi-Region yang bersifat multi-active: setiap replica dapat menerima read dan write, bukan satu Region aktif dan sisanya pasif. Tersedia dua mode konsistensi: Multi-Region Eventual Consistency (MREC, default) dan Multi-Region Strong Consistency (MRSC, hanya untuk global tables same-account). Untuk ujian, kata kunci pentingnya adalah multi-Region, multi-active, high availability, business continuity, dan latency global.

DocumentDB, Neptune, Timestream, Keyspaces, MemoryDB, dan Managed Blockchain.

Tidak semua data cocok dimasukkan ke tabel SQL. Beberapa data lebih alami sebagai dokumen, hubungan, waktu, atau transaksi bersama antar organisasi.

AWS memiliki beberapa database yang dibuat untuk pola data tertentu. Di CLF-C02, kamu perlu mengenali nama layanan dan use case utamanya, bukan detail operasionalnya.

Contoh nyata

Sebuah marketplace bisa memakai RDS untuk transaksi pembayaran, DynamoDB untuk keranjang, ElastiCache untuk session, DocumentDB untuk metadata produk fleksibel, Neptune untuk rekomendasi hubungan produk, Timestream untuk metrik operasional, Redshift untuk laporan penjualan, dan QuickSight untuk dashboard manajemen. Satu aplikasi nyata sering memakai banyak database sekaligus, masing-masing untuk pola data yang paling cocok.

Dari data mentah sampai dashboard bisnis.

Analytics seperti dapur riset restoran: data penjualan mentah diolah, ditanya dengan SQL, lalu ditampilkan sebagai laporan yang bisa dipahami pemilik bisnis.

OLTP versus OLAP: dua dunia yang sering tertukar

Sebelum menamai layanan, pahami dulu dua jenis pekerjaan data. OLTP (Online Transaction Processing) adalah dunia transaksi harian: banyak operasi kecil dan cepat, menulis dan membaca per baris, harus konsisten dan terbaru. Inilah ranah RDS, Aurora, dan DynamoDB. OLAP (Online Analytical Processing) adalah dunia analitik: sedikit query tetapi sangat berat, menjumlahkan dan mengelompokkan jutaan baris untuk laporan dan tren. Inilah ranah Redshift, Athena, dan EMR. Memaksa Redshift menangani ribuan transaksi pesanan per detik, atau memaksa RDS menjumlahkan satu miliar baris untuk dashboard, sama-sama keliru arsitektur.

Amazon Redshift

Amazon Redshift adalah data warehouse fully managed berskala petabyte dengan penyimpanan columnar untuk analitik cepat. Gunakan Redshift saat perusahaan ingin menganalisis data terstruktur dalam jumlah besar, membuat laporan BI, dan menjalankan query analitik kompleks. Tersedia juga Redshift Serverless yang menagih per RPU (Redshift Processing Unit) per detik tanpa mengelola cluster. Redshift bukan pengganti database transaksi harian seperti RDS.

Amazon EMR

Amazon EMR adalah platform terkelola untuk menjalankan framework big data seperti Apache Spark, Apache Hive, Apache Hudi, dan Presto di AWS. Gunakan EMR saat tim data perlu memproses data besar dengan tool open-source, misalnya transformasi batch, machine learning pipeline, atau pemrosesan log skala besar. Ada juga EMR Serverless yang menghilangkan kebutuhan provisioning cluster.

Amazon Athena

Amazon Athena adalah layanan query interaktif yang memudahkan analisis data langsung di Amazon S3 dengan SQL standar. Athena bersifat serverless, sehingga cocok untuk query ad-hoc tanpa mengelola cluster, dan ditagih berdasarkan jumlah data yang dipindai per query. Athena sering bekerja dengan AWS Glue Data Catalog untuk metadata tabel dan kolom.

Amazon OpenSearch Service

Amazon OpenSearch Service dipakai untuk pencarian (search) dan analitik log skala besar, misalnya menelusuri log aplikasi, observability, dan analisis teks. Tersedia juga OpenSearch Serverless. Jika skenario menyebut “search engine” atau “analisis log interaktif”, arahnya OpenSearch.

Amazon QuickSight

Amazon QuickSight adalah layanan business intelligence untuk membuat dashboard, visualisasi, dan insight yang mudah dipahami stakeholder. Per 9 Oktober 2025, QuickSight berevolusi menjadi bagian dari Amazon Quick Suite, dan komponen BI intinya kini disebut “Quick Sight” (dua kata) dalam navigasi suite tersebut, berdampingan dengan komponen baru seperti Quick Research dan Quick Flows. Namun, blueprint dan soal CLF-C02 masih memakai istilah “QuickSight”, jadi kenali kedua nama agar tidak bingung saat membaca materi lama maupun baru.

Menggerakkan data dari sumber ke insight.

Data tidak cukup disimpan. Data juga perlu ditemukan, dibersihkan, dipindahkan, diberi label, dan kadang diproses saat masih mengalir agar bisa dianalisis.

AWS Glue adalah layanan data integration serverless. AWS menjelaskan Glue sebagai layanan untuk menemukan, menyiapkan, dan mengintegrasikan data pada skala besar, termasuk Data Catalog, ETL, pipeline, dan koneksi ke banyak sumber data. Dalam data lake, Glue sering menjadi “daftar isi perpustakaan” yang memberi tahu Athena, Redshift, atau EMR di mana data berada dan seperti apa strukturnya. Glue juga punya Data Quality untuk memantau kualitas data di S3.

Amazon Kinesis menangani data yang masih mengalir (streaming) secara real time atau near real time. Untuk CLF-C02, cukup kenali bahwa Kinesis dipakai saat data datang terus-menerus, seperti clickstream, log, atau telemetry IoT. Salah satu sub-layanannya, Amazon Data Firehose (dulu bernama Kinesis Data Firehose), dapat memuat data streaming ke S3, Redshift, OpenSearch Service, atau Splunk secara near real time. Catat juga bahwa “Kinesis Data Analytics” kini bernama Amazon Managed Service for Apache Flink.

AWS DMS membantu migrasi database. AWS mendokumentasikan DMS sebagai layanan untuk memigrasikan relational database, data warehouse, NoSQL database, dan data store lain, baik ke AWS maupun antar kombinasi cloud dan on-premises. DMS juga dapat membantu schema conversion dalam proses migrasi tertentu.

Alur data sederhana

Database aman bukan hanya karena memakai layanan managed.

Managed service mengurangi beban operasional, tetapi bukan berarti semua keputusan keamanan pindah ke AWS.

Dalam model shared responsibility, AWS mengamankan infrastruktur cloud, sedangkan pelanggan tetap bertanggung jawab atas konfigurasi, akses, data, enkripsi yang dipilih, kredensial, dan pola penggunaan. Untuk database dan analytics, area yang sering muncul di ujian adalah IAM, enkripsi, network access, backup, monitoring, dan biaya berbasis konsumsi.

Biaya tingkat tinggi

• RDS dan Aurora dapat mengenakan biaya berdasarkan instance atau kapasitas, storage, I/O, backup tambahan, transfer data, dan opsi deployment.
• DynamoDB dapat memakai model on-demand atau provisioned, dengan biaya terkait read, write, storage, backup, stream, dan replikasi global tables.
• ElastiCache dipengaruhi node atau kapasitas cache, engine, deployment, dan traffic.
• Athena umumnya dipengaruhi jumlah data yang dipindai per query, sehingga format kolom seperti Parquet dan partisi dapat mengurangi biaya.
• Redshift dipengaruhi pilihan provisioned atau serverless, kapasitas, storage, dan durasi penggunaan.
• QuickSight dipengaruhi edisi, user, kapasitas, fitur, dan pola penggunaan dashboard.

Walkthrough konseptual tanpa membuat tagihan tak perlu.

Tujuan hands-on pemula bukan menghafal tombol, tetapi memahami alur keputusan dan konsekuensi layanan.

Walkthrough 1: RDS untuk aplikasi toko online

Walkthrough 2: Query file log di S3 dengan Athena

Menjelaskan ke stakeholder bisnis

Sampaikan dengan bahasa bisnis: “Kita memakai RDS untuk transaksi yang harus konsisten, DynamoDB untuk akses super cepat pada skala besar, ElastiCache untuk mengurangi antrean database, S3 plus Athena untuk analisis murah tanpa server, Redshift untuk gudang data perusahaan, dan QuickSight untuk dashboard manajemen.” Hindari istilah teknis berlebihan; hubungkan tiap layanan ke hasil bisnis seperti kecepatan, keandalan, dan biaya.

Peta akhir untuk mengunci jawaban CLF-C02.

Kunci bab ini adalah mencocokkan pola data dengan layanan, lalu membaca kata kunci soal dengan tenang.

Peta domain CLF-C02

Jebakan soal paling sering

• ”Relational database managed” bukan DynamoDB, jawabannya RDS atau Aurora.
• ”Query S3 with SQL, no servers” bukan Redshift, jawabannya Athena.
• ”Dashboard untuk business users” bukan Glue, jawabannya QuickSight.
• ”ETL dan Data Catalog” bukan DMS, jawabannya Glue.
• ”Migrate database” bukan Glue, jawabannya DMS.
• ”Cache in-memory” bukan DynamoDB, jawabannya ElastiCache.
• ”Graph relationship” bukan DocumentDB, jawabannya Neptune.
• ”Time-stamped IoT metrics” bukan RDS default, jawabannya Timestream.
• ”Multi-active read dan write lintas Region untuk NoSQL” jawabannya DynamoDB Global Tables.

Referensi resmi untuk pendalaman

• AWS Certified Cloud Practitioner CLF-C02 Exam Guide
• In-Scope AWS Services for CLF-C02
• Choosing an AWS database service
• Choosing an AWS analytics service
• Amazon RDS User Guide
• Amazon RDS Multi-AZ deployments
• Amazon Aurora User Guide
• Amazon DynamoDB Global Tables
• Amazon ElastiCache User Guide
• Amazon Athena User Guide
• AWS Glue
• AWS Database Migration Service User Guide