Deployments & Managing Infrastructure
at Scale
Mengelola AWS dalam skala besar mirip mengelola dapur restoran ramai, resep, alur kerja, dan kontrol kualitas harus konsisten.
Mengapa Infrastruktur Perlu Dikelola sebagai Sistem
Dari klik manual menuju proses yang bisa diulang, diaudit, dan dipulihkan.
Bayangkan kamu membuka 50 cabang kafe, resep kopi tidak boleh bergantung pada ingatan barista satu orang.
Di AWS, masalah yang sama muncul ketika tim membuat VPC, EC2, load balancer, database, permission, dan pipeline secara manual. Klik manual terasa cepat untuk percobaan, tetapi sulit diulang, sulit diaudit, dan mudah berbeda antara development, staging, dan production.
Modul ini membahas dua sisi besar: deployment, yaitu cara merilis aplikasi atau perubahan infrastruktur, dan managing infrastructure at scale, yaitu cara mengelola banyak resource secara konsisten. Fokus CLF-C02 bukan menulis template rumit, tetapi mengenali layanan mana yang cocok untuk kebutuhan tertentu.
Kenapa pembedaan ini penting untukmu? Karena soal ujian jarang bertanya “tulis YAML ini”, tetapi sering bertanya “layanan apa yang paling tepat untuk skenario X”. Begitu kamu memetakan tiap layanan ke satu kata kerja inti (provision, define-with-code, run-web-app, build, deploy, orchestrate, operate), pilihan ganda yang tadinya membingungkan menjadi jauh lebih mudah dieliminasi.
CloudFormation adalah resep dapur, CDK adalah cara menulis resep memakai bahasa chef, CodePipeline adalah ban berjalan, CodeBuild adalah oven pengujian, CodeDeploy adalah pelayan yang mengantar menu baru, Elastic Beanstalk adalah paket restoran siap pakai, dan Systems Manager adalah ruang kontrol untuk semua cabang.
Bayangkan dampak klik manual saat skala membesar. Satu environment dengan 10 resource masih bisa diingat satu orang. Tetapi tiga environment (development, staging, production) dikali puluhan resource dikali beberapa Region menghasilkan ratusan keputusan kecil yang mudah berbeda satu sama lain. Perbedaan kecil itulah yang menjadi sumber bug “jalan di laptop saya tetapi gagal di production”. IaC dan CI/CD ada untuk menghapus celah itu, bukan sekadar mempercepat.
Menurut Exam Guide CLF-C02, kandidat perlu memahami nilai AWS Cloud, shared responsibility, keamanan, biaya, core services, dan pemilihan layanan untuk use case umum. Topik deployment dan operasi skala besar terutama masuk Domain 3, tetapi juga menyentuh Domain 2 (least privilege, akses aman, audit) dan Domain 4 (biaya layanan pengelola vs biaya resource yang dikelola).
Gambaran awal
- IaC membuat infrastruktur bisa didefinisikan sebagai file, bukan sekadar klik console.
- CI/CD membantu perubahan aplikasi bergerak dari source code sampai production secara otomatis dan terkontrol.
- Systems Manager membantu operasi harian, seperti patching, command, session, inventory, dan parameter.
Infrastructure as Code (IaC)
Mengubah infrastruktur menjadi blueprint yang bisa disimpan di Git.
IaC seperti denah rumah, tukang yang berbeda tetap bisa membangun bentuk yang sama karena rujukannya jelas.
Infrastructure as Code adalah praktik mendefinisikan resource cloud dalam file deklaratif atau kode pemrograman. Alih-alih membuat security group, subnet, bucket, atau load balancer satu per satu, kamu menuliskan keadaan yang diinginkan lalu tool akan membuat atau memperbaruinya.
Mengapa penting? Karena cloud memudahkan membuat resource, tetapi kemudahan itu bisa menjadi kacau bila tidak ada standar. Dengan IaC, tim bisa melakukan review, versioning, rollback, dan audit perubahan. Ini sama seperti kode aplikasi yang disimpan di repository.
Repeatable
Environment development, staging, dan production bisa dibuat dari blueprint yang sama dengan parameter berbeda.
Auditable
Perubahan terlihat di Git atau change set, sehingga tim tahu siapa mengubah apa dan kapan.
Recoverable
Jika resource rusak atau perlu dibuat ulang di Region lain, blueprint menjadi titik awal pemulihan.
Jika soal menyebut membuat dan mengelola resource AWS secara konsisten sebagai code, jawabannya cenderung CloudFormation atau CDK, bukan Elastic Beanstalk atau Systems Manager.
Kapan IaC dipakai?
IaC cocok ketika resource perlu dibuat berulang, environment perlu distandarkan, perubahan perlu ditinjau, atau compliance menuntut jejak audit. Untuk percobaan satu kali, console boleh dipakai, tetapi untuk workload tim dan production, IaC lebih aman.
Komponen mental model
Template atau kode
File yang menjelaskan resource, konfigurasi, dependency, parameter, dan output.
Engine provisioning
Layanan yang membaca blueprint lalu membuat, mengubah, atau menghapus resource.
State atau stack
Catatan resource yang dikelola bersama sebagai satu unit perubahan.
Review dan rollback
Proses memeriksa dampak perubahan dan kembali ke kondisi aman bila gagal.
AWS CloudFormation
Layanan native AWS untuk membuat dan mengelola stack resource.
CloudFormation seperti kontraktor resmi AWS yang membaca blueprint dan membangun resource sesuai urutan yang benar.
AWS CloudFormation membantu kamu memodelkan dan menyiapkan resource AWS dengan memperlakukan infrastruktur sebagai kode. Kamu menulis template, biasanya YAML atau JSON, lalu CloudFormation membuat stack, yaitu kumpulan resource yang dikelola sebagai satu unit.
CloudFormation bersifat deklaratif. Kamu tidak perlu menulis langkah imperatif seperti buat VPC dulu, lalu subnet, lalu route table. Kamu mendeskripsikan hasil akhir, CloudFormation memahami dependency banyak resource dan melakukan provisioning. Inilah perbedaan inti yang sering diuji: deklaratif berarti kamu menyatakan “apa yang diinginkan”, bukan “langkah-langkah membuatnya”. Jika provisioning gagal di tengah jalan, CloudFormation otomatis melakukan rollback ke kondisi terakhir yang stabil, sehingga kamu tidak meninggalkan resource setengah jadi yang membingungkan.
Templatenya bisa ditulis dalam format YAML atau JSON; keduanya didukung dan menghasilkan hasil yang sama, jadi tim biasanya memilih YAML karena lebih ringkas dan mudah dibaca.
Definisikan resource, parameter, output, dan dependency yang diperlukan.
Upload template ke CloudFormation dan berikan nilai parameter.
Gunakan change set untuk melihat resource apa yang akan dibuat, diubah, atau dihapus.
Kelola resource sebagai satu unit agar tidak tercecer dan mudah dibersihkan.
Template adalah blueprint, stack adalah hasil bangunan, change set adalah daftar rencana renovasi sebelum benar-benar dijalankan.
Fitur yang sering muncul di ujian
Stack
Kumpulan resource yang dibuat dan dikelola bersama sebagai satu unit; hapus stack maka semua resource di dalamnya ikut dibersihkan rapi.
Change set
Preview perubahan sebelum update stack dijalankan; kamu melihat resource mana yang akan dibuat, diubah, atau diganti sebelum benar-benar dieksekusi.
Drift detection
Mendeteksi perbedaan antara konfigurasi template dan resource aktual yang mungkin diubah manual di luar CloudFormation, sehingga kamu tahu environment sudah menyimpang dari blueprint.
StackSets
Deploy satu stack ke beberapa akun dan Region sekaligus dalam satu operasi, cocok untuk standardisasi guardrail di skala organisasi.
Keduanya sering tertukar di soal. Change set menjawab “apa yang akan terjadi jika saya update” (lihat ke depan, sebelum perubahan); drift detection menjawab “apakah resource saya sudah berbeda dari template” (lihat ke belakang, setelah ada perubahan manual).
Kapan memilih CloudFormation?
Pilih CloudFormation ketika soal menekankan IaC native AWS, template deklaratif, provisioning resource secara konsisten, atau deployment lintas akun dan Region dengan StackSets. Untuk level Cloud Practitioner, kamu tidak perlu hafal semua syntax, tetapi perlu tahu perannya.
CloudFormation bukan berarti semua resource gratis, kamu tetap membayar resource yang dibuat, misalnya EC2, load balancer, NAT Gateway, atau RDS.
Halaman pricing CloudFormation menyatakan tidak ada biaya tambahan untuk resource provider dengan namespace AWS::* dan Alexa::*. Yang berbiaya hanyalah resource provider pihak ketiga atau registry extension: 1.000 handler operation pertama per bulan gratis, selanjutnya ada tarif per handler operation, ditambah biaya bila durasi handler melampaui ambang tertentu. Harga dapat berubah, jadi cek halaman resmi untuk angka terbaru. Untuk ujian, ingat prinsipnya: CloudFormation sebagai IaC tool gratis untuk resource AWS, tetapi resource yang dibuat tetap berbiaya.
AWS Cloud Development Kit (CDK)
Menulis infrastruktur memakai bahasa pemrograman yang familiar.
Jika CloudFormation adalah formulir blueprint, CDK adalah aplikasi desain yang membantu membuat blueprint itu dengan kode.
AWS CDK adalah framework open source untuk mendefinisikan infrastruktur cloud dalam kode dan memprovisioningnya melalui CloudFormation. CDK v2 mendukung enam bahasa yang semuanya sudah GA: TypeScript, JavaScript, Python, Java, C#/.NET, dan Go. Di balik layar, CDK memakai teknologi bernama JSII untuk menghasilkan binding semua bahasa itu dari satu basis kode TypeScript, jadi fitur antarbahasa relatif konsisten.
Poin krusial yang sering keliru dipahami: CDK bukan engine provisioning tersendiri. CDK tidak berbicara langsung ke API tiap layanan AWS. Sebaliknya, CDK melakukan synth (synthesize), yaitu menghasilkan template CloudFormation dari kodemu, lalu CloudFormation-lah yang membuat resource. Jadi semua jaminan CloudFormation (rollback, change set, drift detection, manajemen stack) tetap kamu dapatkan walau menulisnya dengan kode.
CDK memakai konsep construct, yaitu building block reusable. Misalnya, sebuah construct bisa mewakili bucket S3, Lambda function, atau pola lebih besar seperti aplikasi serverless dengan API Gateway dan Lambda. Karena ditulis dalam bahasa pemrograman umum, kamu bisa memakai loop, kondisi, dan fungsi untuk menghasilkan banyak resource serupa tanpa menyalin-tempel ratusan baris template.
Infrastruktur didefinisikan dengan bahasa pemrograman umum.
CDK menghasilkan template CloudFormation dari kode tersebut.
Template dipakai untuk membuat atau memperbarui stack di AWS.
Daripada membuat setiap bata satu per satu, construct memberi blok siap pakai yang bisa disusun ulang dan dibagikan antar proyek.
CloudFormation vs CDK
Keduanya menghasilkan resource yang sama lewat CloudFormation; bedanya ada pada cara kamu menuliskan keinginanmu. CloudFormation memakai template deklaratif murni, sedangkan CDK memakai kode yang men-synth menjadi template itu.
- Kamu menulis YAML atau JSON yang menyatakan resource akhir secara langsung.
- Tidak butuh keahlian bahasa pemrograman, cocok untuk tim ops dan template standar.
- Apa yang ada di template persis itulah yang dibuat, tanpa lapisan abstraksi.
- Native AWS, tidak ada langkah synth, template adalah artefak utama.
- Kamu menulis TypeScript, Python, Java, C#, Go, atau JavaScript lalu jalankan synth.
- Bisa memakai loop, kondisi, fungsi, dan construct reusable untuk mengurangi pengulangan.
- Cocok untuk tim developer yang ingin pola infrastruktur dapat dibagi antar proyek.
- Tetap men-deploy lewat CloudFormation, jadi rollback dan change set tetap berlaku.
CDK bukan pengganti total CloudFormation. CDK justru men-synth menjadi CloudFormation template untuk deployment. Kalimat soal “define infrastructure using familiar programming languages” mengarah ke CDK; “provision resources from declarative templates” mengarah ke CloudFormation.
AWS Elastic Beanstalk
Platform aplikasi yang mengelola infrastruktur dasar untuk developer.
Elastic Beanstalk seperti menyewa dapur siap pakai, kamu membawa resep aplikasi, AWS menyiapkan kompor, kulkas, dan area servis.
AWS Elastic Beanstalk membantu deploy aplikasi web ke AWS tanpa mengelola semua detail infrastruktur dari nol. Kamu upload kode aplikasi, memilih platform, lalu Elastic Beanstalk dapat memprovisioning EC2, load balancing, health monitoring, dan scaling environment.
Elastic Beanstalk mendukung beberapa platform seperti Go, Java, .NET, Node.js, PHP, Python, Ruby, dan Docker. Ia cocok untuk developer yang ingin cepat menjalankan aplikasi web dengan kontrol yang masih lebih terlihat dibanding layanan serverless penuh.
Kelebihan utamanya adalah keseimbangan: kamu tetap melihat dan bisa mengakses EC2 instance, load balancer, dan Auto Scaling Group yang dibuat, tetapi tidak perlu merangkainya manual. Saat traffic naik, Beanstalk menambah instance; saat sepi, ia menguranginya. Jika kamu butuh kontrol detail di kemudian hari, kamu masih bisa menyesuaikan konfigurasi underlying tanpa membuang aplikasi.
Platform berbasis Amazon Linux 2023 (AL2023) aktif dirilis pada awal 2026 dan menjadi pilihan default ke depan. Semua platform berbasis Amazon Linux 2 (AL2) dijadwalkan dipensiunkan paling lambat 30 Juni 2026, jadi aplikasi lama sebaiknya bermigrasi ke AL2023. Ini detail operasional, bukan poin hafalan ujian, tetapi penting untuk praktik nyata.
Application
Wadah logis untuk versi aplikasi, environment, dan konfigurasi.
Environment
Tempat aplikasi berjalan, misalnya web server environment atau worker environment.
Platform
Runtime dan stack yang dipakai, seperti Node.js, Python, Java, .NET, atau Docker.
Kapan memilih Elastic Beanstalk?
Pilih Elastic Beanstalk saat soal menyebut developer ingin deploy aplikasi web dengan cepat, tetap memakai resource seperti EC2 dan load balancer, tetapi tidak ingin mengonfigurasi semuanya manual. Elastic Beanstalk bukan container orchestrator penuh seperti ECS, bukan IaC engine seperti CloudFormation, dan bukan pipeline CI/CD seperti CodePipeline.
Elastic Beanstalk tidak mengenakan biaya tambahan, tetapi resource yang dibuatnya, seperti EC2, S3, dan load balancer, tetap dikenakan biaya sesuai pemakaian.
CodeCommit, CodeBuild, CodeDeploy, dan CodePipeline
Rangkaian layanan developer tools untuk merilis perubahan secara otomatis.
CI/CD seperti jalur produksi pabrik, bahan mentah masuk, diuji, dikemas, lalu dikirim ke pelanggan dengan pemeriksaan di setiap tahap.
CI/CD membantu tim merilis software lebih cepat dan lebih aman. Continuous Integration berfokus pada build dan test setiap perubahan kode segera setelah di-push, sehingga bug ketahuan dini saat masih murah diperbaiki. Continuous Delivery berfokus pada menyiapkan rilis agar dapat dikirim ke environment tujuan dengan proses otomatis dan dapat diulang, mengurangi langkah manual yang rawan salah.
Cara mengingat peran tiap layanan Code* paling mudah lewat satu kata kerja: CodeCommit menyimpan (store), CodeBuild membangun (build), CodeDeploy mengirim (deploy), CodePipeline mengorkestrasi (orchestrate). CodePipeline adalah konduktor orkestra; ia tidak membangun atau men-deploy sendiri, melainkan memanggil CodeBuild dan CodeDeploy pada tahap yang tepat, dan bisa memanggil tool pihak ketiga juga.
AWS CodeCommit
Repository Git terkelola di AWS. Berdasarkan blog resmi AWS DevOps, layanan ini kembali tersedia untuk pelanggan baru (returns to GA) pada 24 November 2025.
AWS CodeBuild
Layanan build terkelola yang mengompilasi source code, menjalankan unit test, dan menghasilkan artifact siap deploy berdasarkan buildspec.
AWS CodeDeploy
Layanan deployment otomatis untuk tiga compute platform: EC2/On-Premises, AWS Lambda, dan Amazon ECS.
AWS CodePipeline
Layanan continuous delivery untuk memodelkan, memvisualisasikan, dan mengotomatisasi langkah rilis software dari source sampai production.
CodeCommit sempat ditutup untuk pelanggan baru, lalu kembali GA pada 24 November 2025. Catatan: halaman pricing-nya sempat belum diperbarui dan masih menampilkan teks lama, jadi rujukan status yang benar adalah blog resmi AWS DevOps, bukan halaman pricing.
Peran masing-masing layanan
Kode disimpan di CodeCommit, GitHub, GitLab, Bitbucket, atau sumber lain yang terhubung lewat integrasi.
CodeBuild menjalankan perintah dari buildspec, misalnya install dependency, test, dan package.
CodeDeploy atau Elastic Beanstalk mengirim versi aplikasi baru ke target.
CodePipeline menyusun semua tahap agar berjalan otomatis saat perubahan terjadi.
Sejak 29 Maret 2024, AWS mengganti nama AWS CodeStar Connections menjadi AWS CodeConnections untuk koneksi ke provider Git seperti GitHub, GitLab, dan Bitbucket. ARN lama (codestar-connections) masih didukung, tetapi materi modern memakai nama baru ini.
Jika pertanyaan menyebut pipeline end-to-end, pilih CodePipeline. Jika hanya build dan test, pilih CodeBuild. Jika hanya deployment aplikasi ke EC2, Lambda, atau ECS, pilih CodeDeploy.
Strategi Deployment Aman
Melepas versi baru tanpa membuat seluruh pelanggan ikut menjadi tester dadakan.
Deployment aman mirip mengganti menu restoran, jangan langsung mengganti semua cabang jika satu resep belum terbukti enak.
Strategi deployment menentukan bagaimana versi baru masuk ke environment. Inti yang membedakan semua strategi sederhana saja: berapa banyak traffic yang menyentuh versi baru, dan seberapa cepat. Makin sedikit traffic yang terkena di awal, makin kecil radius ledakan jika versi baru ternyata bermasalah. Di level Cloud Practitioner, kamu tidak perlu menghafal konfigurasi detail, tetapi perlu memahami pola risiko dan kapan dipakai.
In-place
Versi baru menggantikan versi lama pada resource yang sama. Sederhana, tetapi ada jeda saat instance diperbarui dan rollback bisa lebih menegangkan karena versi lama sudah ditimpa.
Rolling
Instance diperbarui bertahap per batch. Sebagian kapasitas tetap melayani traffic saat sebagian lain diperbarui, sehingga tidak ada downtime total tetapi sempat berjalan dua versi sekaligus.
Blue/green
Environment baru (green) dibuat terpisah berdampingan dengan yang lama (blue); traffic dipindah penuh setelah versi baru siap. Rollback cepat karena cukup mengalihkan traffic kembali ke blue.
Canary
Sebagian kecil traffic diarahkan ke versi baru lebih dulu (misalnya 10%), dipantau, lalu dinaikkan bertahap jika metrik sehat. Risiko paling terkontrol, tetapi prosesnya paling lambat.
- Dua environment penuh berjalan berdampingan, lalu traffic dialihkan 0 ke 100 persen sekaligus.
- Rollback sangat cepat: arahkan traffic kembali ke environment lama yang masih utuh.
- Butuh kapasitas ganda sementara, jadi biaya sesaat lebih tinggi.
- Cocok saat kamu ingin titik balik yang tegas dan pemulihan instan.
- Satu environment, porsi traffic ke versi baru dinaikkan sedikit demi sedikit.
- Masalah terdeteksi saat hanya sebagian kecil pengguna terkena, radius ledakan kecil.
- Tidak butuh kapasitas ganda penuh, tetapi proses rilis lebih lama.
- Cocok saat kamu ingin memvalidasi metrik nyata sebelum rollout penuh.
Strategi mana untuk platform mana
CodeDeploy mendukung tiga compute platform, dan strategi yang tersedia berbeda untuk tiap platform. Detail ini sering diuji di CLF-C02 karena menyangkut batasan platform.
EC2/On-Premises
Mendukung in-place dan blue/green. Catatan penting: in-place eksklusif untuk platform ini, dan blue/green di sini hanya bekerja dengan EC2 instances, bukan on-premises instances.
AWS Lambda & Amazon ECS
Tidak mendukung in-place. Keduanya memakai blue/green dengan traffic shifting: canary, linear, atau all-at-once untuk memindahkan traffic ke versi baru.
Ingat dua batasan yang sering muncul: in-place HANYA tersedia untuk EC2/On-Premises (Lambda dan ECS tidak bisa in-place), dan blue/green pada EC2/On-Premises HANYA bekerja dengan EC2 instances, bukan on-premises. Dalam soal, kata kunci automated deployment, deployment group, application revision, dan rollback sering mengarah ke CodeDeploy.
Auto Scaling Group menambah atau mengurangi kapasitas mengikuti beban. CodeDeploy mengelola rilis versi aplikasi. Keduanya bisa bekerja bersama, tetapi menjawab masalah yang berbeda: berapa banyak instance vs versi apa yang berjalan di instance itu.
AWS Systems Manager (SSM)
Ruang kontrol untuk mengelola server dan resource dalam skala besar.
Systems Manager seperti pusat komando gedung, kamu bisa melihat perangkat, mengirim instruksi, membuka akses aman, dan menjalankan perawatan rutin.
AWS Systems Manager membantu melihat, mengelola, dan mengoperasikan nodes secara terpusat di AWS, on-premises, dan lingkungan multicloud. Node perlu menjadi managed node, biasanya dengan SSM Agent terpasang dan izin IAM yang tepat.
Run Command
Menjalankan perintah jarak jauh pada managed nodes tanpa login manual satu per satu.
Session Manager
Membuka sesi shell aman tanpa harus membuka port SSH inbound ke internet.
Patch Manager
Mengotomatisasi patch operating system dan aplikasi sesuai maintenance window.
Parameter Store
Menyimpan parameter konfigurasi dan secret sederhana yang dapat direferensikan aplikasi.
Automation
Menjalankan runbook operasional, misalnya membuat AMI, restart service, atau remediasi standar.
Inventory
Mengumpulkan informasi software, konfigurasi, dan metadata instance untuk visibility.
Jika soal menyebut mengelola banyak EC2, menjalankan command jarak jauh, patching, atau akses shell tanpa SSH inbound, Systems Manager adalah kandidat kuat. Untuk akses aman tanpa membuka port, jawabannya Session Manager, bukan bastion host atau SSH publik.
Apa yang gratis dan apa yang berbiaya
Banyak kemampuan inti Systems Manager gratis untuk EC2, sehingga sering menjadi jawaban hemat biaya di soal. Untuk ujian, cukup ingat pola besar ini, bukan angka pastinya.
Gratis untuk EC2
Run Command, Session Manager, Patch Manager, dan Inventory tidak mengenakan biaya tambahan untuk EC2. Parameter Store tier Standard juga gratis.
Berbiaya
Parameter Store tier Advanced berbayar per parameter per bulan; Automation berbayar per step yang dieksekusi dan per detik eksekusi aws:executeScript. Angka dapat berubah, cek halaman pricing resmi.
SSM Agent dan IAM role
SSM Agent berjalan di node dan berkomunikasi dengan Systems Manager. Untuk EC2, biasanya instance memerlukan IAM role yang memberi izin komunikasi ke Systems Manager. Ini contoh bagus shared responsibility: AWS menyediakan layanan, tetapi pelanggan tetap bertanggung jawab memasang agent bila perlu, memberi izin yang benar, dan menjaga patch policy.
Walkthrough Konseptual
Latihan ringan yang aman dipahami tanpa harus membuat resource mahal.
Tujuan walkthrough ini adalah memahami alur, bukan mengejar konfigurasi production yang kompleks.
Latihan A, membaca stack CloudFormation
Cari bagian Parameters, Resources, dan Outputs untuk melihat input, resource yang dibuat, dan informasi hasil.
Tanyakan resource mana bergantung pada resource lain, misalnya EC2 perlu security group.
Sebelum update stack, pahami apakah perubahan akan menambah, mengubah, mengganti, atau menghapus resource.
Delete stack setelah latihan agar resource tidak tertinggal dan menimbulkan biaya.
Latihan B, membaca pipeline CI/CD
Identifikasi dari mana kode berasal, misalnya CodeCommit atau GitHub lewat CodeConnections.
Periksa artifact apa yang dihasilkan CodeBuild setelah test dan packaging.
Tentukan target deployment, misalnya Elastic Beanstalk environment, EC2 group lewat CodeDeploy, Lambda, atau ECS. Ingat: in-place hanya untuk EC2/On-Premises, sedangkan Lambda dan ECS memakai blue/green dengan traffic shifting.
Tentukan apakah rilis aman dengan blue/green (tukar penuh, rollback instan) atau canary (naikkan traffic bertahap sambil pantau metrik), sesuai toleransi risiko aplikasi.
Bayangkan titik manual approval untuk production dan alarm CloudWatch apa yang memicu rollback otomatis bila versi baru bermasalah.
Latihan C, membaca Systems Manager
Pastikan node muncul sebagai managed, artinya agent dan izin dasar bekerja.
Gunakan Run Command untuk perintah baca sederhana, bukan mengubah konfigurasi.
Pahami bagaimana Session Manager mengurangi kebutuhan bastion host dan port inbound.
Kelompokkan node berdasarkan environment agar patching tidak menabrak jam sibuk.
Setiap latihan AWS harus punya langkah cleanup. Banyak tagihan pemula datang dari resource yang lupa dimatikan, bukan dari materi belajarnya.
Keamanan, Operasi, dan Biaya
Deployment cepat harus tetap aman, terukur, dan tidak mengejutkan tagihan.
Otomatisasi mempercepat pekerjaan baik dan buruk, karena itu guardrail harus dibuat sebelum kecepatannya dinaikkan.
Keamanan deployment
Least privilege
Role untuk CloudFormation, CodeBuild, CodeDeploy, dan Systems Manager harus punya izin sesuai tugasnya, bukan izin admin permanen.
Secret management
Jangan menaruh password di template, build log, atau repository. Gunakan layanan seperti Parameter Store atau AWS Secrets Manager sesuai kebutuhan.
Audit trail
Gunakan CloudTrail, log pipeline, event deployment, dan riwayat stack untuk menelusuri perubahan.
Approval gate
Untuk production, pipeline bisa memakai manual approval agar perubahan berisiko tidak langsung masuk.
Operasi skala besar
Pada skala kecil, satu admin bisa login ke satu server. Pada skala besar, pola itu tidak aman dan tidak efisien. Systems Manager membantu menjalankan command, patching, session, dan automation secara terpusat. CloudFormation dan CDK membantu memastikan environment dibuat dengan pola yang sama.
Biaya dan lifecycle
CloudFormation dan Elastic Beanstalk sering muncul dalam soal biaya. Intinya, layanan orkestrasi dapat tidak menambah biaya langsung untuk penggunaan dasar tertentu, tetapi resource yang dibuatnya tetap berbiaya. Karena itu, tag, cleanup, budget alert, dan review resource harus menjadi bagian dari proses deployment.
Topik ini menyentuh Domain 4 karena kandidat harus memahami biaya, pricing, dan billing practices, terutama perbedaan antara biaya layanan pengelola dan biaya resource yang dikelola.
Kesalahan Umum dan Jebakan Soal
Hal-hal kecil yang sering membuat pemula memilih layanan yang salah.
Dalam ujian, kata kunci kecil sering menjadi pembeda antara jawaban yang mirip.
CloudFormation vs Elastic Beanstalk
CloudFormation mengelola resource sebagai IaC. Elastic Beanstalk mengelola deployment aplikasi web dan environment pendukung.
CodeBuild vs CodeDeploy
CodeBuild membangun dan menguji artifact. CodeDeploy mengirim artifact ke target runtime.
CodePipeline vs semua layanan Code
CodePipeline adalah orkestrator tahapan. Ia dapat memanggil CodeBuild, CodeDeploy, dan integrasi lain.
Systems Manager vs CloudWatch
Systems Manager menjalankan operasi dan manajemen node. CloudWatch memantau metrik, log, alarm, dan event.
Session Manager vs SSH publik
Session Manager membantu akses aman tanpa membuka port SSH inbound ke internet.
CDK vs CloudFormation
CDK menulis infrastruktur dengan bahasa pemrograman, lalu menghasilkan CloudFormation untuk provisioning.
Materi lama kadang menyebut CodeStar. Untuk konteks modern, ingat bahwa CodeConnections adalah nama baru untuk CodeStar Connections, dan pipeline modern biasanya dibahas lewat CodePipeline, CodeBuild, CodeDeploy, serta integrasi source.
Jebakan kalimat soal
Ini mengarah ke AWS CDK, bukan sekadar CloudFormation template.
Ini mengarah ke AWS CloudFormation.
Ini mengarah ke AWS Elastic Beanstalk.
Ini mengarah ke AWS CodeBuild.
Ini mengarah ke AWS CodePipeline.
Ini mengarah ke AWS Systems Manager.
Ini menggambarkan canary deployment, bukan blue/green yang menukar traffic penuh sekaligus.
Ini menggambarkan blue/green deployment, dengan rollback cepat ke environment lama.
Ringkasan & Tips Ujian
Peta cepat layanan deployment dan manajemen skala besar untuk CLF-C02.
Untuk lulus, hafalkan peran layanan, bukan detail syntax.
Poin Penting
- IaC membuat infrastruktur konsisten, repeatable, auditable, dan cocok untuk review.
- CloudFormation adalah layanan native AWS untuk provisioning resource dari template YAML atau JSON; kuasai stack, change set, drift detection, dan StackSets.
- CDK memungkinkan infrastruktur ditulis memakai bahasa pemrograman (enam bahasa) lalu di-synth menjadi CloudFormation untuk deployment.
- Elastic Beanstalk mempercepat deployment aplikasi web dengan mengelola resource pendukung seperti EC2, load balancer, health monitoring, dan scaling.
- CodePipeline mengorkestrasi workflow rilis, CodeBuild build dan test, CodeDeploy deployment otomatis, CodeCommit repository Git terkelola (kembali GA 24 November 2025).
- Strategi deployment: in-place hanya EC2/On-Premises; rolling per batch; blue/green tukar penuh dengan rollback instan; canary naik bertahap; Lambda dan ECS memakai blue/green dengan traffic shifting.
- Systems Manager membantu operasi node skala besar, termasuk Run Command, Session Manager, Patch Manager, Automation, Inventory, dan Parameter Store; banyak kemampuan intinya gratis untuk EC2.
Pemetaan ke domain CLF-C02
Domain 1, Cloud Concepts
Pahami manfaat otomatisasi, elasticity, repeatability, agility, dan mengapa cloud mempercepat eksperimen.
Domain 2, Security & Compliance
Ingat least privilege, audit trail, shared responsibility, patching, secret management, dan akses aman tanpa SSH publik.
Domain 3, Cloud Technology & Services
Ini domain utama modul, fokus pada pemilihan CloudFormation, CDK, Elastic Beanstalk, CodeBuild, CodeDeploy, CodePipeline, dan Systems Manager.
Domain 4, Billing, Pricing & Support
Bedakan layanan pengelola dari resource yang dibuat, dan ingat resource tetap bisa menimbulkan biaya walau dibuat otomatis.
Baca kata kerja di soal: provision berarti CloudFormation, define with programming language berarti CDK, build berarti CodeBuild, deploy berarti CodeDeploy atau Elastic Beanstalk, orchestrate release berarti CodePipeline, operate nodes berarti Systems Manager. Untuk strategi rilis: parallel environment lalu switch berarti blue/green, shift small percentage first berarti canary, replace on same resource berarti in-place.
CloudFormation membangun resource, CDK menulis blueprint dengan kode, Beanstalk menjalankan aplikasi web, CodePipeline mengalirkan rilis, Systems Manager merawat armada.