Migration, Hybrid Cloud & Edge
CLF-C02
Pindah ke AWS bukan sekadar memindahkan server, tetapi memilih cara pindah yang paling masuk akal untuk aplikasi, data, biaya, risiko, dan lokasi pengguna.
Migrasi seperti pindah rumah
Analogi dulu, baru layanan AWS.
Bayangkan perusahaan seperti keluarga yang ingin pindah rumah dari rumah lama ke apartemen modern, tidak semua barang harus diperlakukan sama.
Ada barang yang langsung dibawa apa adanya, seperti lemari dan meja. Ada barang yang diganti karena lebih murah membeli baru. Ada barang yang ditinggalkan karena sudah tidak dipakai. Ada pula barang yang tetap di rumah lama karena belum siap dipindahkan. Migrasi cloud juga begitu, setiap aplikasi punya nasib berbeda.
Dalam konteks AWS, migrasi berarti memindahkan atau menata ulang aplikasi, database, data, dan operasi dari lingkungan lama ke AWS Cloud. Lingkungan lama bisa data center sendiri, colocation, cloud lain, atau cabang perusahaan. Untuk CLF-C02, yang penting bukan menjalankan cutover teknis, tetapi memahami strategi, alasan bisnis, dan layanan mana untuk pekerjaan apa.
Server adalah barang rumah, database adalah arsip penting, jaringan adalah akses jalan, dan cutover adalah hari pindahan saat pengguna mulai memakai alamat baru.
Kenapa pembedaan ini penting untukmu? Karena soal CLF-C02 jarang bertanya “bagaimana cara teknis memindahkan VM ini”, tetapi sering bertanya “perusahaan punya kondisi X, layanan atau strategi mana yang paling tepat”. Begitu kamu memetakan tiap kata kunci skenario ke satu jawaban inti (discovery, business case, rehost, pindah data database, konversi schema, transfer data besar, akses file lokal, atau infrastruktur AWS di site), pilihan ganda yang tadinya membingungkan jadi jauh lebih mudah dieliminasi.
Strategi
Menentukan apakah aplikasi dibawa apa adanya, dioptimalkan, diganti, ditahan, atau dimatikan. Ini bahasa keputusan, bukan nama layanan.
Alat migrasi
Membantu discovery, business case, rehost server, memindahkan database, dan melacak progres migrasi.
Hybrid dan edge
Menghubungkan lokasi on-premises dengan AWS saat data, latency, atau aturan bisnis belum bisa sepenuhnya cloud.
Sebagian besar materi yang diuji ada di Domain 3, yaitu memilih layanan yang tepat untuk skenario. Bagian strategi R menyentuh Domain 1, dan Migration Evaluator menyentuh Domain 4. Jadikan service picker sebagai inti latihanmu.
Kenapa migrasi penting di CLF-C02
Topik ini menyentuh Domain 1 dan Domain 3.
CLF-C02 menguji apakah kamu bisa menjelaskan manfaat migrasi dan memilih layanan AWS yang cocok untuk skenario umum.
Panduan ujian resmi CLF-C02 menyebut empat domain dengan bobot tetap, yaitu Domain 1 Cloud Concepts 24%, Domain 2 Security and Compliance 30%, Domain 3 Cloud Technology and Services 34%, dan Domain 4 Billing, Pricing, and Support 12%. Ujian terdiri dari 65 soal (50 dinilai), skor skala 100 sampai 1000, dan nilai lulus 700. Untuk topik migrasi, bobot terbesar ada di Domain 3, karena di situlah kamu memilih layanan untuk skenario. Lihat AWS Certified Cloud Practitioner exam guide dan daftar in-scope services CLF-C02.
Untuk modul ini, layanan yang resmi in-scope dan perlu kamu kuasai adalah AWS Migration Hub, AWS Application Discovery Service, Migration Evaluator, AWS Application Migration Service, AWS Database Migration Service, AWS Schema Conversion Tool, AWS Snow Family, AWS Storage Gateway, dan AWS Outposts. Daftar in-scope resmi menaruh tujuh layanan pertama di kategori Migration and Transfer, lalu Storage Gateway di kategori Storage, dan Outposts di kategori Compute.
AWS DataSync, AWS Transfer Family, AWS Local Zones, dan AWS Wavelength tidak ada di daftar in-scope CLF-C02 resmi. Kita tetap membahasnya supaya kamu bisa membedakannya dari layanan in-scope, tetapi jangan menghabiskan waktu menghafal detailnya. Beberapa blog persiapan keliru mengklaim Local Zones dan Wavelength diuji, jadi berpegang pada daftar resmi.
Ujian jarang meminta konfigurasi detail. Ujian lebih sering memberi skenario, lalu menanyakan layanan atau strategi yang paling tepat.
Peta domain CLF-C02
- Domain 1: alasan migrasi, strategi migrasi, cloud economics, agility, dan menghindari investasi data center besar.
- Domain 2: keamanan data saat migrasi, enkripsi, akses, kepatuhan, dan shared responsibility.
- Domain 3: service picker untuk Migration Hub, MGN, DMS, SCT, Snow Family, Storage Gateway, dan Outposts.
- Domain 4: business case, estimasi biaya, Migration Evaluator, Pricing Calculator, dan cara menghindari overprovisioning.
Tujuh R strategi migrasi
Cara mengelompokkan aplikasi sebelum pindah.
Strategi migrasi adalah label keputusan, bukan nama layanan.
Kembali ke analogi pindah rumah. Sebelum memesan truk, keluarga memilah barang satu per satu, mana yang dibawa, mana yang diganti, mana yang dibuang. Tujuh R adalah cara AWS memilah aplikasi dengan pertanyaan yang sama, hanya istilahnya formal.
AWS Prescriptive Guidance menjelaskan tujuh R untuk migrasi, yaitu Retire, Retain, Rehost, Relocate, Repurchase, Replatform, dan Refactor (atau re-architect). Penting: Relocate adalah anggota penuh dari tujuh R, bukan tambahan opsional. Sebagian materi lama menyebut “6R klasik plus Relocate”, tetapi panduan resmi memperlakukan ketujuhnya setara. Untuk ujian, kenali semuanya dan pahami posisi Relocate.
Retire
Dimatikan karena tidak lagi dipakai (aplikasi zombie atau idle), sehingga biaya dan risiko operasional berkurang.
Retain
Tetap di sumber untuk sementara, misalnya karena kepatuhan, dependensi, baru saja di-upgrade, atau butuh hardware khusus.
Rehost
Lift and shift, tanpa perubahan aplikasi. Dipindah apa adanya ke AWS, cocok saat ingin cepat keluar dari data center. Diotomatiskan oleh MGN.
Relocate
Pindahkan server, instance, atau objek pada level hypervisor (misalnya VMware Cloud on AWS) atau ke VPC, Region, atau akun lain, tanpa membeli hardware baru, menulis ulang aplikasi, atau mengubah operasi.
Repurchase
Drop and shop. Sistem lama diganti produk SaaS atau solusi berbeda, misalnya CRM lama diganti aplikasi SaaS.
Replatform
Lift, tinker, and shift. Aplikasi tetap mirip, tetapi sebagian komponen dioptimalkan, misalnya SQL Server pindah ke Amazon RDS.
Refactor
Re-architect. Aplikasi diubah besar agar cloud-native, misalnya monolith dipecah menjadi microservices atau serverless.
Bayangkan sofa lama. Rehost berarti mengangkat sofa apa adanya ke apartemen baru. Replatform berarti mengganti kakinya supaya muat lift, tetapi sofanya sama. Refactor berarti membongkar sofa jadi beberapa kursi modular yang lebih cocok dengan ruangan baru.
- Tidak ada perubahan aplikasi, dipindah apa adanya.
- Paling cepat, cocok untuk exit data center bertenggat.
- Diotomatiskan oleh AWS Application Migration Service (MGN).
- Keyword soal: “no changes”, “as is”, “quickly”.
- Optimasi kecil tanpa mengubah inti aplikasi.
- Contoh klasik: database self-managed pindah ke Amazon RDS.
- Menghapus beban operasional tanpa re-architecture penuh.
- Keyword soal: “minor optimization”, “managed database”.
Retire matikan, Retain tahan dulu, Rehost angkat apa adanya, Relocate pindah level hypervisor, Repurchase ganti produk, Replatform optimasi kecil, Refactor ubah arsitektur. Jangan tukar Replatform (kecil) dengan Refactor (besar).
Alur besar migrasi
Assess, plan, migrate, validate, modernize.
Migrasi yang sehat dimulai dari memahami lingkungan lama sebelum menyentuh server produksi.
Secara tingkat tinggi, migrasi berjalan seperti proyek pindahan kantor. Pertama inventarisasi barang, lalu kelompokkan mana yang pindah dulu, pilih kendaraan pindahan, lakukan pemindahan, cek apakah kantor baru berfungsi, lalu rapikan agar lebih efisien. Di AWS, fase ini dibantu oleh discovery tools, business case tools, migration tracking, server migration, database migration, transfer perangkat fisik, dan hybrid services.
Gunakan inventaris aplikasi, dependensi, biaya, dan risiko untuk memahami apa yang dimiliki perusahaan saat ini.
Kelompokkan server dan database menjadi aplikasi, pilih strategi R, urutkan wave, dan buat business case.
Gunakan layanan yang cocok, misalnya Application Migration Service untuk rehost server, DMS untuk database, atau Snow Family untuk transfer data besar.
Uji aplikasi di AWS, cek performa, keamanan, backup, monitoring, dan rencana rollback sebelum cutover.
Setelah stabil, lakukan optimasi bertahap seperti memakai managed database, autoscaling, serverless, atau observability yang lebih baik.
Pemula sering langsung memilih layanan migrasi tanpa tahu masalahnya. Di ujian, baca dulu apakah skenarionya tentang discovery, estimasi biaya, server, database, data besar, atau hybrid.
Service picker untuk aplikasi
Discovery, business case, tracking, dan rehost server.
Empat layanan ini sering terlihat mirip, tetapi pekerjaannya berbeda.
AWS Migration Hub adalah dashboard koordinasi. Ia menyediakan satu tempat untuk discovery, planning, dan tracking status migrasi aplikasi. Dokumentasi AWS menjelaskan bahwa Migration Hub dapat menampilkan koneksi dan status server maupun database dalam aplikasi yang sedang dimigrasikan, terlepas dari tool migrasi yang dipakai. Lihat AWS Migration Hub documentation.
AWS Application Discovery Service adalah alat untuk mengumpulkan data penggunaan dan konfigurasi server on-premises. Data seperti performa, konfigurasi, dan koneksi jaringan membantu menentukan dependensi antar server dan mengelompokkan server menjadi aplikasi. Lihat Application Discovery Service documentation.
Migration Evaluator membantu membuat business case berbasis data. Ia memproyeksikan biaya cloud masa depan berdasarkan baseline lingkungan saat ini, provisioning, utilization, dan lisensi. Lihat Migration Evaluator features dan Migration Evaluator pricing untuk ketentuan terbaru.
AWS Application Migration Service atau MGN adalah layanan rehost otomatis untuk memindahkan server fisik, virtual, atau cloud ke AWS. MGN mereplikasi source server ke akun AWS secara block-level, lalu meluncurkan server di AWS saat siap, sehingga downtime cutover minimal. MGN adalah penerus (next generation) dari CloudEndure Migration yang diakuisisi AWS, sekaligus menggantikan AWS Server Migration Service (SMS). AWS mendorong pengguna CloudEndure dan SMS untuk beralih ke MGN, dan inilah alasan MGN menjadi alat rehost yang direkomendasikan saat ini. Lihat Application Migration Service documentation dan kapan memilih MGN.
Kenapa rehost lewat MGN bisa nyaris tanpa downtime? Kuncinya ada di kata block-level dan continuous replication. Bukannya menyalin file satu per satu lalu mematikan server lama, MGN memasang agen ringan di server sumber, lalu menyalin blok disk ke staging area di AWS secara terus-menerus sambil server lama tetap melayani pengguna. Saat semua sudah sinkron, kamu memicu cutover, dan barulah server di AWS mengambil alih. Jeda yang dirasakan pengguna hanya sebatas peralihan terakhir, bukan seluruh durasi penyalinan.
Bayangkan memindahkan toko ke gedung baru tanpa pernah menutup yang lama. Setiap kali ada barang masuk atau berubah di toko lama, kurir langsung menyalinnya ke gedung baru. Pelanggan tetap belanja di toko lama sampai gedung baru benar-benar identik, lalu kamu cukup mengganti papan alamat dalam hitungan menit. Itulah cara kerja continuous block-level replication MGN.
Migration Hub
Pakai saat soal menekankan satu tempat untuk melacak banyak migrasi aplikasi.
Application Discovery Service
Pakai saat soal menekankan mengumpulkan data server on-premises dan dependensi aplikasi.
Migration Evaluator
Pakai saat soal menekankan business case, TCO, projected AWS cost, dan keputusan finansial sebelum migrasi.
Application Migration Service
Pakai saat soal menekankan rehost server cepat dari fisik, virtual, atau cloud lain ke AWS.
- Mengumpulkan inventory server on-premises plus dependensi dan performa.
- Memetakan server menjadi aplikasi sebelum kamu memutuskan strategi.
- Fase assess, hasilnya memberi makan Migration Hub.
- Keyword soal: “discover servers”, “dependencies”, “inventory”.
- Benar-benar mereplikasi dan meluncurkan server di AWS (rehost).
- Penerus CloudEndure Migration, menggantikan AWS SMS.
- Fase migrate, dipakai setelah strategi dipilih.
- Keyword soal: “lift and shift”, “rehost servers”.
Kalau keyword soal adalah tracking, pilih Migration Hub. Kalau keyword adalah collect inventory atau dependencies, pilih Application Discovery Service. Kalau keyword adalah business case atau TCO, pilih Migration Evaluator. Kalau keyword adalah lift-and-shift server, pilih Application Migration Service. Jangan pilih MGN hanya karena ada kata “migrasi”.
Database migration, DMS dan SCT
Data bergerak, skema berubah.
Migrasi database punya dua masalah utama, memindahkan data dan menyesuaikan struktur database.
AWS Database Migration Service atau AWS DMS membantu memigrasikan data database. DMS bisa dipakai untuk one-time migration atau replikasi perubahan berkelanjutan agar source dan target tetap sinkron selama masa transisi. Secara sederhana, DMS adalah mesin replikasi di AWS yang membaca dari source, lalu menulis ke target. Lihat AWS DMS documentation.
AWS Schema Conversion Tool atau AWS SCT membantu mengonversi schema database dari satu engine ke engine lain. Contoh, perusahaan ingin pindah dari database komersial on-premises ke Amazon Aurora PostgreSQL. Data bisa dipindahkan oleh DMS, tetapi struktur tabel, stored procedure, function, dan SQL tertentu mungkin perlu dikonversi. Lihat AWS SCT documentation.
Ada juga DMS Schema Conversion, layanan dalam AWS DMS yang dapat menilai dan mengonversi schema ke target engine yang kompatibel. Untuk CLF-C02, cukup pahami pola besarnya, DMS untuk migrasi data, SCT atau DMS Schema Conversion untuk konversi schema, terutama saat source dan target engine berbeda.
Bayangkan pindahan arsip. DMS adalah jasa kurir yang memindahkan isi map ke kantor baru, bahkan sambil terus menyalin map baru sampai hari pindahan (ongoing replication). SCT adalah penerjemah yang mengubah format map lama agar pas dengan lemari arsip baru saat mereknya berbeda. Map sama merek tidak perlu penerjemah, cukup kurir.
- Membaca dari source dan menulis ke target sebagai mesin replikasi.
- Mendukung one-time migration plus ongoing replication untuk downtime minimal.
- Cukup sendiri saat source dan target engine sama (homogen).
- Keyword soal: “migrate data”, “ongoing replication”, “minimal downtime”.
- Mengubah struktur tabel, stored procedure, function, dan SQL antar engine.
- Dipakai saat engine berbeda (heterogen), misalnya Oracle ke Aurora PostgreSQL.
- Dijalankan dulu untuk schema, baru DMS memindahkan datanya.
- Keyword soal: “convert schema”, “different database engine”.
| Skenario | Layanan yang cocok | Kenapa |
|---|---|---|
| Oracle ke Oracle di AWS | AWS DMS | Engine sama, fokus utama biasanya memindahkan data. |
| Oracle ke Aurora PostgreSQL | AWS SCT dan AWS DMS | Schema perlu dikonversi, lalu data dipindahkan. |
| Data warehouse ke Amazon Redshift | AWS SCT dan layanan migrasi data terkait | Perlu analisis schema, ETL, dan target warehouse. |
| Minim downtime database | AWS DMS ongoing replication | Perubahan dapat direplikasi sampai waktu cutover. |
DMS bukan alat utama untuk menemukan semua server aplikasi. Application Discovery Service untuk discovery server, DMS untuk database migration.
Transfer data, online vs offline
Lewat jaringan, atau lewat perangkat fisik yang dikirim.
Bayangkan mengirim 500 kotak buku ke kota lain. Kalau jalan tol lancar, kirim lewat kurir harian. Kalau jalannya rusak parah, lebih cepat menyewa truk dan mengantarnya sendiri.
Itulah inti pilihan transfer data. Saat bandwidth memadai, kirim data lewat jaringan (online). Saat data sangat besar dan koneksi terbatas, mahal, atau tidak ada, kirim perangkat fisik lewat pos (offline). AWS sekarang menempatkan transfer online sebagai pilihan default, dan transfer fisik sebagai jalan untuk kasus bandwidth terbatas.
Jalur online: DataSync (di luar in-scope)
AWS DataSync adalah layanan transfer data online yang menyalin data besar antara storage on-premises (NFS, SMB, HDFS, object storage) dan layanan AWS (Amazon S3, EFS, FSx), serta antar layanan AWS, lewat internet atau Direct Connect sampai sekitar 10 Gbps, dengan penjadwalan, enkripsi, dan verifikasi bawaan. DataSync adalah pasangan online dari Snow yang offline. Catatan penting: DataSync tidak ada di daftar in-scope CLF-C02, jadi cukup kenali perannya sebagai kontras. Lihat AWS DataSync.
AWS Transfer Family adalah layanan transfer file terkelola penuh lewat SFTP, FTPS, FTP, AS2, dan transfer berbasis web browser, menyimpan data di Amazon S3 atau Amazon EFS. Ini cocok saat mitra eksternal mengirim file lewat protokol SFTP tradisional. Transfer Family juga tidak in-scope CLF-C02. Lihat AWS Transfer Family.
Jalur offline: AWS Snow Family (in-scope)
AWS Snow Family adalah keluarga perangkat fisik yang dikirim ke lokasimu untuk transfer data dan edge computing saat koneksi terbatas, mahal, atau tidak stabil. Perangkat punya storage dan compute onboard, bisa memproses data lokal, menjalankan edge workload, lalu data dipindahkan ke atau dari AWS dengan mengirim balik perangkatnya. Lihat AWS Snowball Edge documentation.
Materi lama sering keliru di sini. Snowmobile (truk kontainer 45 kaki untuk skala exabyte) sudah dipensiunkan AWS sekitar 2024. Snowcone dihentikan, tidak bisa dipesan lagi sejak 12 November 2024. Lineup perangkat aktif kini hanya dua, yaitu Snowball Edge Storage Optimized 210TB (NVMe, hingga sekitar 1,5 GB/s) dan Snowball Edge Compute Optimized 104 vCPU (416GB RAM, 28TB NVMe). Sejak 7 November 2025, Snowball Edge hanya tersedia untuk pelanggan yang sudah ada (existing customers).
Karena perubahan itu, untuk akun baru AWS kini mengarahkan ke alternatif: AWS DataSync untuk transfer online, AWS Data Transfer Terminal untuk drop-off fisik, AWS Outposts untuk edge compute, atau solusi AWS Partner. AWS Data Transfer Terminal (diumumkan re:Invent 2024, awalnya di Los Angeles dan New York) adalah lokasi fisik aman tempat kamu membawa perangkat storage dan mengunggah langsung ke AWS sampai 400 Gbps lewat slot waktu reservasi. Data Transfer Terminal juga tidak in-scope CLF-C02, tetapi bagus diketahui sebagai opsi baru.
- Transfer lewat internet atau Direct Connect, tanpa perangkat dikirim.
- Cocok saat bandwidth memadai dan data bisa mengalir berkala.
- Penjadwalan, enkripsi, dan verifikasi bawaan, default AWS sekarang.
- Catatan: tidak in-scope CLF-C02, hanya untuk membedakan.
- Perangkat rugged dikirim, data disalin lokal, lalu perangkat dikirim balik.
- Cocok saat data sangat besar dan koneksi terbatas atau tidak ada.
- Bisa edge compute di lokasi terpencil sambil menunggu transfer.
- In-scope CLF-C02, tetapi kini existing customers only (Nov 2025).
”Large data, poor or no connectivity” tetap mengarah ke Snow Family. “Online transfer over the network” mengarah ke DataSync (di luar in-scope, tetapi sering dijadikan distraktor). “Managed SFTP/FTPS endpoint” mengarah ke Transfer Family. Hanya Snow Family yang resmi in-scope di antara ketiganya.
Hybrid storage dengan Storage Gateway
Ketika aplikasi lokal masih butuh akses file, blok, atau tape.
Tidak semua aplikasi langsung bisa meninggalkan file share lokal. Sebagian masih menulis ke folder jaringan atau tape backup setiap hari.
AWS Storage Gateway adalah jembatan storage hybrid. Aplikasi on-premises tetap mengakses storage secara lokal lewat protokol yang biasa mereka pakai, sementara data sebenarnya disimpan di backend AWS. Ada cache lokal supaya akses sehari-hari tetap cepat. Ini berbeda dari DataSync (yang memindahkan data sekali jalan) dan Transfer Family (endpoint SFTP); Storage Gateway adalah satu-satunya jawaban hybrid storage yang in-scope. Lihat AWS Storage Gateway documentation dan daftar fitur Storage Gateway.
Bayangkan lemari kecil di kantormu yang isinya selalu yang sering dipakai. Di belakangnya ada pintu ke gudang raksasa di AWS. Kamu membuka lemari seperti biasa, tetapi barang yang jarang dipakai sebenarnya tersimpan di gudang dan diambil saat perlu. Storage Gateway adalah lemari plus pintu itu.
Storage Gateway punya empat tipe, dibedakan oleh protokol yang dipakai aplikasi lokal dan backend AWS tujuannya.
Amazon S3 File Gateway
Aplikasi mengakses file lewat NFS atau SMB, file disimpan sebagai objek di Amazon S3.
Amazon FSx File Gateway
Aplikasi mengakses file share Windows lewat SMB, didukung oleh Amazon FSx for Windows File Server dengan cache lokal.
Volume Gateway
Menyediakan block storage lewat iSCSI, dengan snapshot tersimpan di AWS. Dua mode: cached dan stored.
Tape Gateway
Virtual tape library (VTL) yang menggantikan tape backup fisik, menyimpan virtual tape di Amazon S3 dan S3 Glacier.
Mode cached menaruh data utama di AWS dan hanya menyimpan cache yang sering diakses secara lokal, hemat ruang on-premises. Mode stored menaruh data utama secara lokal untuk akses berlatensi rendah, lalu menyimpan snapshot backup ke AWS.
”Replace physical tape backup” hampir selalu mengarah ke Tape Gateway. “On-prem app still needs local file access with cloud backend” mengarah ke S3 File Gateway atau FSx File Gateway. “Block storage over iSCSI” mengarah ke Volume Gateway. Jangan pilih Snow Family kalau kebutuhan utamanya akses harian ke file share.
Hybrid Cloud dan Edge
Ketika sebagian workload tetap perlu dekat dengan lokasi fisik.
Hybrid cloud berarti sebagian sistem berjalan di AWS Region, sebagian tetap dekat dengan data center, pabrik, toko, kapal, rumah sakit, atau cabang.
AWS Outposts adalah layanan fully managed yang memperluas infrastruktur, layanan, API, dan tools AWS ke lokasi pelanggan. Outposts cocok saat organisasi ingin pengalaman AWS yang konsisten, tetapi workload perlu local compute dan storage karena tiga pemicu utama: latency rendah (single-digit ms), data residency (data harus tetap di lokasi), dan pemrosesan data lokal. Outposts hadir dalam dua form factor, yaitu Outposts racks (42U, dapat diskalakan dari 1 sampai 96 rack) dan Outposts servers (1U atau 2U untuk ruang kecil atau edge). Lihat AWS Outposts documentation dan halaman produk Outposts.
Bayangkan AWS membuka cabang mininya langsung di ruang server kantormu. Rak hardware-nya milik AWS, dirawat AWS, dan dipakai dengan API yang sama persis seperti Region biasa, tetapi fisiknya ada di lantai bawah gedungmu. Pegawai pabrik atau rumah sakit memakai aplikasi yang merespons dalam hitungan milidetik karena datanya tidak perlu pergi jauh, sementara hasil ringkasannya tetap bisa dikirim ke Region pusat untuk analitik. Itulah Outposts.
Kenapa ada dua form factor? Karena kebutuhan ruang dan skala berbeda. Outposts racks adalah lemari penuh 42U yang cocok untuk data center dengan banyak workload dan kebutuhan kapasitas besar, bisa ditumpuk dari 1 sampai 96 rack. Outposts servers adalah unit 1U atau 2U yang muat di rak jaringan biasa, cocok untuk lokasi sempit seperti toko ritel, cabang, atau site edge yang hanya butuh sedikit compute lokal.
- Lemari penuh, kapasitas besar, skala 1 sampai 96 rack.
- Untuk data center dengan banyak workload sekaligus.
- Butuh ruang, daya, dan pendinginan kelas data center.
- Keyword soal: “large on-prem capacity”, “many workloads on site”.
- Unit kecil 1U atau 2U, muat di rak jaringan standar.
- Untuk toko ritel, cabang, atau lokasi edge berukuran kecil.
- Compute dan storage lokal terbatas, footprint minimal.
- Keyword soal: “small space”, “branch / retail / edge location”.
Edge dan hybrid bukan berarti anti-cloud. Justru keduanya sering menjadi jembatan. Data bisa diproses lokal untuk respons cepat, lalu hasilnya dikirim ke AWS untuk analitik, arsip, machine learning, atau disaster recovery. Salah satu cara terbaik memahami pilihan ini adalah membayangkan spektrum, dari pusat cloud sampai tepi jaringan.
Outposts in-scope, Local Zones dan Wavelength tidak
Untuk melengkapi gambaran, dua layanan edge lain sering disebut walau tidak in-scope CLF-C02. AWS Local Zones memperluas Region ke area metro atau kota untuk latency single-digit sampai low-double-digit ms bagi aplikasi sensitif latency. AWS Wavelength menanam compute dan storage AWS di dalam jaringan 5G operator telekomunikasi untuk latency ultra-rendah ke perangkat mobile dan 5G, misalnya AR/VR, kendaraan terhubung, dan video real-time. Lihat AWS Wavelength. Keduanya bagus dipahami, tetapi yang resmi diuji hanyalah Outposts.
Bedanya gampang diingat lewat siapa yang dilayani. Local Zones mendekatkan AWS ke pengguna di sebuah kota lewat jaringan internet biasa, sedangkan Wavelength mendekatkan AWS ke pengguna yang tersambung lewat jaringan seluler 5G operator telekomunikasi. Keduanya milik dan dikelola AWS, jadi kamu tidak menaruh hardware sendiri seperti pada Outposts.
- Lokasi AWS di area metro besar, latency single-digit sampai low-double-digit ms.
- Diakses lewat internet biasa, untuk gaming, media, atau aplikasi desktop sensitif latency.
- Milik dan dikelola AWS, bukan hardware pelangganmu.
- Catatan: tidak in-scope CLF-C02.
- Compute dan storage AWS ditanam di dalam jaringan 5G operator telekomunikasi.
- Untuk perangkat mobile dan 5G: AR/VR, kendaraan terhubung, video real-time.
- Trafik tidak perlu keluar dari jaringan operator untuk mencapai AWS.
- Catatan: tidak in-scope CLF-C02.
Outposts (in-scope)
AWS infrastructure di lokasi pelanggan, cocok untuk low latency, data residency, dan operasi konsisten dengan AWS di site permanen.
Snow Family (in-scope)
Perangkat rugged untuk transfer data atau edge compute, cocok saat jaringan terbatas, lokasi terpencil, atau sementara dan terputus.
Storage Gateway (in-scope)
Jembatan storage, cocok saat aplikasi lokal masih memakai protokol storage tradisional dengan backend AWS.
- Hardware AWS fully managed dipasang tetap di data center pelanggan.
- Pemicu: low latency, data residency, pemrosesan lokal konsisten.
- Dua form factor: racks (42U) dan servers (1U/2U).
- Keyword soal: “AWS infrastructure on premises”, “consistent hybrid”.
- Perangkat rugged sementara untuk lokasi terpencil atau terputus.
- Pemicu: bandwidth terbatas, operasi disconnected, transfer offline.
- Dikirim, dipakai, lalu dikembalikan, bukan instalasi permanen.
- Keyword soal: “remote site”, “no reliable connectivity”, “rugged”.
Kamu tidak perlu mendesain topologi Outposts detail. Cukup tahu kapan memilih Outposts dibanding Snow Family atau Storage Gateway, dan ingat Local Zones serta Wavelength tidak resmi diuji.
Skenario nyata dan walkthrough
Latihan berpikir seperti soal ujian.
Cara terbaik belajar migration picker adalah membaca skenario dan mencari keyword bisnisnya.
Skenario 1, keluar dari data center dalam 6 bulan
Perusahaan memiliki banyak VM on-premises dan ingin cepat pindah ke AWS dengan perubahan aplikasi minimal. Tim belum tahu dependensi antar server. Mulai dari Application Discovery Service untuk inventory dan dependency mapping, gunakan Migration Hub untuk grouping dan tracking, lalu gunakan Application Migration Service untuk rehost server secara lift-and-shift.
Skenario 2, database komersial ingin diganti ke Aurora PostgreSQL
Perusahaan ingin mengurangi biaya lisensi dan pindah ke database open-source compatible. Gunakan AWS SCT atau DMS Schema Conversion untuk menilai dan mengonversi schema, lalu AWS DMS untuk memindahkan data dan mereplikasi perubahan sampai cutover.
Skenario 3, kantor cabang punya file share dan ingin backup ke AWS
Aplikasi lokal masih memakai SMB atau NFS. Jangan langsung pilih Snow Family kalau kebutuhan utamanya akses harian ke file share. Gunakan AWS Storage Gateway, terutama File Gateway, agar aplikasi lokal tetap mengakses file dan data tersimpan di storage AWS.
Skenario 4, lokasi pertambangan dengan koneksi lemah
Sensor menghasilkan data besar, jaringan tidak stabil, dan sebagian pemrosesan harus terjadi lokal. Snow Family cocok untuk edge compute dan transfer data fisik ke AWS. Jika lokasi permanen butuh AWS infrastructure konsisten di site, pertimbangkan Outposts.
Skenario 5, transfer 200TB sekali jalan dengan bandwidth bagus
Perusahaan punya 200TB arsip dan koneksi Direct Connect cepat, tidak butuh akses lokal lagi. Untuk soal CLF-C02 klasik dengan “large offline transfer, poor connectivity”, jawabannya Snow Family. Tetapi di praktik 2026, kalau bandwidth memadai, AWS merekomendasikan AWS DataSync (online), dan untuk akun baru Snowball Edge sudah existing customers only sejak 7 November 2025. Pahami keduanya: keyword “no or poor connectivity” tetap Snow Family, keyword “online over the network” mengarah DataSync.
Cari kata seperti discovery, business case, lift-and-shift, database, schema, data besar, file share, latency, atau edge.
Tentukan apakah masalahnya strategi, aplikasi, database, transfer data, hybrid storage, atau edge compute.
Pilih layanan yang paling langsung menjawab kebutuhan, bukan layanan paling populer.
Buang pilihan yang benar secara umum tetapi tidak menjawab keyword utama skenario.
Walkthrough konseptual yang aman
Latihan memahami alur tanpa harus membuat resource berbiaya.
Tujuan latihan ini adalah membentuk model mental, bukan mengejar konfigurasi production. Semua langkah bisa kamu pahami hanya dengan membaca console dan dokumentasi, tanpa menimbulkan tagihan.
Migrasi nyata melibatkan banyak izin, jaringan, dan biaya, jadi untuk belajar CLF-C02 kamu tidak perlu benar-benar memindahkan server. Yang penting adalah mengenali bentuk tiap alur, supaya saat soal menyebut sepotong langkah, kamu langsung tahu layanan apa yang sedang dibicarakan.
Latihan A, membaca rencana rehost dengan MGN
Bayangkan kamu sudah punya daftar server dari Application Discovery Service dan grouping di Migration Hub. Tanyakan: server mana yang membentuk satu aplikasi?
Pahami bahwa MGN bekerja dengan agen ringan di server sumber yang menyalin blok disk ke staging area di AWS secara terus-menerus, sementara server lama tetap online.
Sebelum cutover, MGN bisa meluncurkan test instance dari salinan yang sudah sinkron untuk memastikan aplikasi jalan, tanpa mengganggu produksi.
Saat siap, cutover memindahkan beban ke EC2 produksi. Inilah satu-satunya jeda yang dirasakan pengguna, bukan seluruh durasi penyalinan.
Latihan B, membaca alur migrasi database dengan DMS dan SCT
Tanyakan apakah engine sama (Oracle ke Oracle) atau berbeda (Oracle ke Aurora PostgreSQL). Jawaban ini menentukan apakah perlu konversi schema.
Jika engine berbeda, jalankan AWS SCT atau DMS Schema Conversion dulu untuk mengubah tabel, stored procedure, dan SQL agar cocok dengan target.
Tentukan source endpoint, target endpoint, dan tipe migrasi. Untuk downtime minimal, pilih full load plus ongoing replication (change data capture).
Setelah data sinkron dan tervalidasi, arahkan aplikasi ke database baru, lalu hentikan task DMS bila tidak lagi diperlukan.
Latihan C, membaca pilihan transfer data besar
Jika aplikasi lokal masih perlu akses file harian, jawabannya Storage Gateway, bukan transfer sekali jalan. Hentikan di sini bila itu kasusnya.
Jika koneksi memadai, AWS DataSync dapat menjadwalkan, mengenkripsi, dan memverifikasi transfer online ke S3, EFS, atau FSx (di luar in-scope, tetapi default praktik 2026).
Jika bandwidth buruk atau tidak ada, pikirkan Snow Family (offline) atau Data Transfer Terminal (drop-off fisik dekat LA/NY). Ingat Snowball Edge kini existing customers only.
Latih diri menerjemahkan kalimat skenario ke satu cabang pohon keputusan, lalu pilih layanan yang in-scope bila soal memintanya.
Latihan D, membaca skenario hybrid edge
Apakah masalahnya latency rendah, data residency, pemrosesan lokal, atau operasi tanpa koneksi? Pemicu ini menentukan layanan.
Site permanen yang butuh AWS konsisten mengarah ke Outposts. Lokasi terpencil, sementara, atau terputus mengarah ke Snow Family.
Banyak workload dan kapasitas besar mengarah ke Outposts racks (42U). Ruang sempit seperti cabang atau ritel mengarah ke Outposts servers (1U/2U).
Jika soal menyebut Local Zones atau Wavelength sebagai jawaban, ingat keduanya tidak resmi diuji; Outposts adalah jawaban hybrid in-scope.
Kalau kamu memang mencoba di akun nyata, selalu sertakan langkah cleanup: hentikan replication task, hapus replication server, dan matikan resource uji. Banyak tagihan pemula datang dari resource yang lupa dimatikan, bukan dari materi belajarnya.
Kesalahan umum dan jebakan soal
Bagian ini membantu menghindari pilihan yang terdengar benar tetapi salah konteks.
Sebagian besar jebakan migration di CLF-C02 muncul karena nama layanan terdengar mirip.
Migration Hub bukan alat replikasi server
Migration Hub melacak dan mengelompokkan progres. Untuk rehost server, pikirkan Application Migration Service.
Application Discovery Service bukan DMS
Discovery Service mengumpulkan data server dan dependensi. DMS memigrasikan data database.
Migration Evaluator bukan Pricing Calculator umum
Migration Evaluator fokus pada business case migrasi berdasarkan kondisi on-premises. Pricing Calculator membuat estimasi biaya untuk arsitektur AWS, dan Compute Optimizer untuk right-sizing resource yang sudah jalan.
SCT bukan pengganti DMS
SCT membantu konversi schema. DMS memindahkan dan mereplikasi data. Engine sama cukup DMS, engine beda pakai SCT dulu baru DMS.
Snow Family bukan CDN
Snow Family memindahkan atau memproses data dengan perangkat fisik. CDN untuk caching konten adalah CloudFront.
Outposts bukan sekadar storage gateway
Outposts membawa infrastruktur AWS ke lokasi pelanggan. Storage Gateway hanya menjembatani storage on-premises dengan AWS.
DataSync bukan Storage Gateway
DataSync memindahkan data online sekali jalan. Storage Gateway membiarkan aplikasi lokal terus mengakses storage sambil backend di AWS. Hanya Storage Gateway yang in-scope.
7 R, bukan 6 R
AWS Prescriptive Guidance resmi menyebut tujuh R dengan Relocate sebagai anggota penuh, bukan tambahan. Jangan lupakan Relocate (level hypervisor).
Snow Family device lineup sudah berubah
Snowmobile dipensiunkan, Snowcone dihentikan, kini hanya dua Snowball Edge (Storage 210TB dan Compute 104 vCPU), existing customers only sejak Nov 2025.
Local Zones dan Wavelength tidak in-scope
Beberapa blog persiapan keliru memasukkan keduanya. Daftar resmi hanya menaruh Outposts (Compute) dan Storage Gateway (Storage) plus Snow Family (Migration).
Jika soal menyebut banyak aplikasi dan ingin satu dashboard status, jangan pilih MGN hanya karena ada kata migrasi. Jawaban paling tepat adalah Migration Hub.
Di praktik, migrasi besar sering memakai banyak layanan sekaligus. Di ujian, pilih layanan yang paling tepat untuk kebutuhan yang paling eksplisit di soal.
Ringkasan & Tips Ujian
Peta cepat sebelum latihan soal.
Modul ini membantu kamu mengenali strategi migrasi dan memilih layanan AWS untuk aplikasi, database, data besar, hybrid storage, dan edge.
Poin Penting
- Tujuh R: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor. Relocate adalah anggota penuh (level hypervisor), bukan tambahan opsional.
- Migration Hub: satu tempat untuk discovery, planning, grouping, dan tracking migrasi aplikasi.
- Application Discovery Service: mengumpulkan data server on-premises, performa, konfigurasi, dan dependensi.
- Migration Evaluator: membantu business case, TCO, baseline, projected AWS cost, dan keputusan finansial migrasi.
- Application Migration Service (MGN): rehost atau lift-and-shift server fisik, virtual, atau cloud ke AWS. Penerus CloudEndure Migration, menggantikan AWS SMS.
- DMS: memindahkan DATA database, termasuk one-time migration dan ongoing replication.
- SCT atau DMS Schema Conversion: mengonversi SKEMA saat berpindah engine database.
- Online vs offline: DataSync (online, di luar in-scope) vs Snow Family (offline, in-scope) vs Data Transfer Terminal (drop-off fisik, di luar in-scope).
- Snow Family: kini hanya dua Snowball Edge (Storage 210TB dan Compute 104 vCPU); Snowmobile dipensiunkan, Snowcone dihentikan; existing customers only sejak Nov 2025.
- Storage Gateway: empat tipe (S3 File, FSx File, Volume cached/stored, Tape) untuk akses lokal dengan backend AWS.
- Outposts: infrastruktur AWS fully managed di lokasi pelanggan (racks 42U atau servers 1U/2U) untuk low latency, data residency, dan pemrosesan lokal. Local Zones dan Wavelength tidak in-scope.
Pemetaan ke domain CLF-C02
- Domain 1, Cloud Concepts 24%: pahami manfaat migrasi, tujuh R strategi, agility, cloud economics, dan alasan bisnis pindah ke AWS.
- Domain 2, Security and Compliance 30%: ingat data migrasi tetap perlu enkripsi, kontrol akses, logging, dan kepatuhan. Pelanggan tetap bertanggung jawab atas konfigurasi dan data.
- Domain 3, Cloud Technology and Services 34% (bobot terbesar untuk modul ini): kuasai service picker migration, MGN, DMS, SCT, Snow Family, Storage Gateway, dan Outposts.
- Domain 4, Billing, Pricing, and Support 12%: kaitkan Migration Evaluator dengan business case dan estimasi finansial sebelum migrasi.
Tips ujian cepat
- Keyword business case atau TCO biasanya mengarah ke Migration Evaluator.
- Keyword discover servers, dependencies, atau inventory biasanya mengarah ke Application Discovery Service.
- Keyword single place to track migration biasanya mengarah ke Migration Hub.
- Keyword lift-and-shift servers biasanya mengarah ke Application Migration Service (MGN).
- Keyword database replication atau minimal downtime database biasanya mengarah ke AWS DMS.
- Keyword convert database schema atau different engine biasanya mengarah ke AWS SCT atau DMS Schema Conversion.
- Keyword large offline data transfer, poor connectivity, atau rugged device biasanya mengarah ke AWS Snow Family.
- Keyword online transfer over the network mengarah ke DataSync (di luar in-scope, sering jadi distraktor).
- Keyword replace physical tape backup mengarah ke Tape Gateway; on-prem file access with cloud storage mengarah ke S3 atau FSx File Gateway.
- Keyword AWS infrastructure on premises atau data residency biasanya mengarah ke AWS Outposts.
Jangan hafalkan layanan sebagai daftar. Hafalkan pasangan masalah dan solusi, karena CLF-C02 menguji pengenalan skenario.
Referensi resmi
- AWS Certified Cloud Practitioner CLF-C02 Exam Guide
- CLF-C02 In-Scope AWS Services
- AWS Prescriptive Guidance, Migration strategies (7 Rs)
- AWS Migration Hub User Guide
- AWS Application Discovery Service User Guide
- When to choose AWS Application Migration Service (MGN)
- AWS Database Migration Service User Guide
- AWS Schema Conversion Tool User Guide
- AWS Snowball Edge Developer Guide
- AWS Snow device updates (2024 dan 2025)
- AWS DataSync (di luar in-scope)
- AWS Transfer Family (di luar in-scope)
- AWS Storage Gateway features
- AWS Outposts product page
- AWS Wavelength dan Local Zones (di luar in-scope)