Infrastructure as Code Series 01: GCP Landing Zone — Membangun Cloud Foundation yang Repeatable

Membuat satu project di Google Cloud sebenarnya cukup mudah.

Kita bisa membuka Google Cloud Console, membuat project, mengaktifkan beberapa API, membuat service account, memberikan IAM role, membuat network, lalu mulai menjalankan workload.

Untuk satu project, pendekatan seperti ini mungkin masih terasa sederhana.

Tetapi bagaimana jika jumlah project mulai bertambah?

Bagaimana jika kita punya development, staging, dan production?

Bagaimana memastikan setiap project memiliki IAM baseline yang sama?

Bagaimana memastikan API yang diperlukan selalu aktif?

Bagaimana memastikan network, logging, security, dan automation dibuat dengan pola yang konsisten?

Dan yang tidak kalah penting:

Bagaimana jika suatu hari environment tersebut perlu dibangun ulang dari nol?

Di titik inilah Infrastructure as Code dan konsep Landing Zone mulai menjadi penting.

Landing Zone membantu kita membangun cloud foundation sebelum workload aplikasi mulai berjalan di atasnya.

Sedangkan Infrastructure as Code membantu foundation tersebut menjadi repeatable, versioned, reviewable, dan bisa dibangun kembali dengan cara yang konsisten.

Tentang Infrastructure as Code Series Ini

Artikel ini adalah bagian pertama dari sebuah series yang akan membahas perjalanan membangun infrastructure GCP menggunakan Infrastructure as Code.

Series ini akan terdiri dari enam bagian:

Infrastructure as Code Series 01
GCP Landing Zone
→ memahami cloud foundation dan posisi Infrastructure as Code

Infrastructure as Code Series 02
Terraform State
→ memahami bagaimana Terraform mengingat infrastructure

Infrastructure as Code Series 03
Bootstrapping GCP
→ remote state, service account, IAM, dan foundation awal

Infrastructure as Code Series 04
Workload Identity Federation
→ GitHub Actions ke GCP tanpa service account JSON key

Infrastructure as Code Series 05
GCP Project Factory
→ membuat project dan baseline infrastructure secara repeatable

Infrastructure as Code Series 06
Terraform Modules
→ mengubah infrastructure pattern menjadi reusable building blocks

Series pertama ini akan fokus pada big picture terlebih dahulu.

Kita belum akan membahas terlalu dalam soal syntax Terraform atau implementasi teknis.

Tujuannya adalah menjawab satu pertanyaan dasar:

Sebenarnya apa yang sedang kita bangun ketika kita mengatakan
"GCP Landing Zone dengan Infrastructure as Code"?

Masalah Ketika Cloud Dibangun Secara Manual

Mari mulai dari pendekatan yang paling sederhana.

Misalnya kita ingin membuat satu environment baru.

Secara manual, flow-nya mungkin terlihat seperti ini:

Engineer
→ Google Cloud Console
→ Create Project
→ Enable APIs
→ Create Service Account
→ Configure IAM
→ Create Network
→ Configure Logging
→ Deploy Workload

Tidak ada yang salah dengan flow tersebut.

Masalah mulai muncul ketika proses yang sama harus diulang berkali-kali.

Misalnya sebuah organisasi mempunyai:

Development
Staging
Production

Kemudian setiap environment terdiri dari beberapa project.

Development
├── application
├── data
└── tooling

Staging
├── application
├── data
└── tooling

Production
├── application
├── data
└── tooling

Jika semua project dibuat secara manual, lambat laun kita akan mulai menemukan perbedaan-perbedaan kecil.

Project A memiliki API tertentu yang aktif.

Project B tidak.

Project staging menggunakan satu IAM role.

Project production menggunakan role yang berbeda.

Firewall rule dibuat sedikit berbeda.

Service account diberi permission secara manual.

Logging mungkin sudah dikonfigurasi di satu project, tetapi belum di project lain.

Perbedaan-perbedaan kecil ini disebut configuration drift.

Semakin banyak resource dan environment yang dimiliki, semakin sulit memastikan semuanya tetap konsisten.

Apa Itu Infrastructure as Code?

Infrastructure as Code, atau IaC, adalah pendekatan untuk mendefinisikan dan mengelola infrastructure melalui code atau configuration file.

Jika sebelumnya kita membuat infrastructure melalui console:

Engineer
→ Cloud Console
→ Infrastructure

Dengan Infrastructure as Code, flow-nya berubah menjadi:

Engineer
→ Infrastructure Code
→ Automation
→ Cloud Provider

Salah satu tool yang banyak digunakan untuk pendekatan ini adalah Terraform.

Dengan Terraform, sebuah resource dapat direpresentasikan dalam configuration.

Contoh sederhananya:

resource "google_project_service" "compute" {
  project = var.project_id
  service = "compute.googleapis.com"
}

Configuration di atas menjelaskan bahwa sebuah API perlu diaktifkan pada project tertentu.

Tetapi nilai utama Infrastructure as Code bukan sekadar:

tidak perlu klik Google Cloud Console

IaC memberi kita beberapa kemampuan yang jauh lebih penting.

Repeatability

Infrastructure yang sama dapat dibuat kembali menggunakan code yang sama.

Consistency

Setiap environment dapat menggunakan baseline configuration yang seragam.

Version Control

Perubahan infrastructure dapat disimpan di Git.

Kita bisa mengetahui:

siapa mengubah apa
kapan perubahan dilakukan
kenapa perubahan dilakukan

Reviewability

Perubahan infrastructure dapat melalui Pull Request dan code review sebelum diterapkan.

Automation

Infrastructure dapat dibuat melalui CI/CD pipeline tanpa harus selalu dikerjakan secara manual.

Secara sederhana:

Infrastructure as Code
=
Infrastructure yang didefinisikan,
direview,
dan dikelola seperti software.

Lalu, Apa Itu Landing Zone?

Landing Zone adalah cloud foundation yang sudah memiliki baseline, sehingga workload dapat dibangun di atasnya dengan lebih aman dan konsisten.

Landing Zone bukan aplikasi.

Landing Zone juga bukan satu resource tertentu.

Landing Zone lebih tepat dipahami sebagai sekumpulan foundation capability yang disiapkan sebelum workload mulai berjalan.

Secara sederhana:

Cloud Provider
      ↓
Landing Zone
      ↓
Projects
      ↓
Applications / Workloads

Atau jika kita melihatnya dari bawah:

Application
     ↓
Project
     ↓
IAM / Network / Logging / Security
     ↓
Landing Zone
     ↓
Google Cloud

Landing Zone menjadi tempat workload "mendarat".

Karena itulah namanya Landing Zone.

Workload tidak langsung masuk ke cloud environment yang kosong.

Sebelumnya, sudah ada foundation yang menentukan bagaimana project dibuat, bagaimana identity dikelola, bagaimana network disusun, dan bagaimana baseline security diterapkan.

Infrastructure as Code dan Landing Zone Bukan Hal yang Sama

Infrastructure as Code dan Landing Zone sering dibicarakan bersamaan, tetapi keduanya mempunyai peran yang berbeda.

Landing Zone adalah foundation yang ingin kita bangun.

Infrastructure as Code adalah salah satu cara untuk mendefinisikan dan mengelola foundation tersebut.

Secara sederhana:

Landing Zone
=
Apa yang kita bangun

Infrastructure as Code
=
Bagaimana kita membangunnya secara repeatable

Jika digabungkan:

Git Repository
      ↓
Terraform
      ↓
GCP Landing Zone
      ↓
Projects
      ↓
Applications

Dengan pendekatan ini, cloud foundation tidak hanya hidup sebagai konfigurasi di Google Cloud Console.

Foundation tersebut juga memiliki representasi dalam bentuk code.

Apa yang Biasanya Ada di Sebuah GCP Landing Zone?

Tidak ada satu bentuk Landing Zone yang selalu cocok untuk semua organisasi.

Kebutuhannya bisa berbeda-beda tergantung ukuran organisasi, jumlah project, security requirement, struktur team, dan workload yang dijalankan.

Tetapi secara umum, ada beberapa komponen yang sering menjadi bagian dari cloud foundation.

Organization dan Resource Hierarchy

Google Cloud mempunyai resource hierarchy.

Secara sederhana:

Organization
├── Folder
│   ├── Development
│   │   └── Projects
│   │
│   ├── Staging
│   │   └── Projects
│   │
│   └── Production
│       └── Projects

Hierarchy membantu kita mengelompokkan resource berdasarkan kebutuhan organisasi.

Misalnya:

Organization
├── Platform
├── Shared Services
├── Development
├── Staging
└── Production

Dari hierarchy tersebut, policy atau IAM tertentu dapat diterapkan pada level yang sesuai.

Tanpa struktur yang jelas, project bisa berkembang menjadi kumpulan resource yang sulit dipahami dan dikelola.

Project

Project adalah salah satu boundary utama di Google Cloud.

Banyak resource akan hidup di dalam sebuah project.

Contohnya:

Compute Engine
Cloud Storage
GKE
Cloud SQL
Pub/Sub
Secret Manager
Artifact Registry

Project juga menjadi boundary penting untuk beberapa hal, seperti IAM, billing, API enablement, dan quota.

Karena itu, salah satu tugas penting Landing Zone adalah menentukan bagaimana project dibuat dan baseline apa yang harus dimiliki setiap project.

IAM Baseline

Identity and Access Management menentukan siapa yang dapat melakukan apa terhadap sebuah resource.

Secara sederhana:

Principal
   ↓
Role
   ↓
Resource

Principal bisa berupa:

User
Group
Service Account
Workload Identity

Sedangkan role menentukan permission yang diberikan.

Landing Zone sebaiknya membantu memastikan IAM tidak dibangun secara acak pada setiap project.

Misalnya:

Platform Admin Group
        ↓
Platform Role

Developer Group
        ↓
Developer Role

CI/CD Service Account
        ↓
Deployment Role

Tujuannya bukan membuat semua IAM menjadi sama.

Tujuannya adalah membuat pola pemberian access menjadi lebih jelas, konsisten, dan dapat diaudit.

Networking

Networking juga menjadi bagian penting dari cloud foundation.

Sebuah workload nantinya membutuhkan cara untuk berkomunikasi.

Misalnya melalui:

VPC
Subnet
Firewall
Private connectivity
Load balancer
DNS

Pada environment kecil, setiap project mungkin memiliki network sendiri.

Pada organisasi yang lebih besar, networking dapat berkembang menggunakan pola seperti Shared VPC atau centralized network architecture.

Yang penting pada tahap awal adalah memahami bahwa network bukan sesuatu yang sebaiknya dibuat secara asal-asalan ketika aplikasi mulai membutuhkan connectivity.

Landing Zone membantu menentukan baseline networking sebelum workload berkembang terlalu jauh.

API Enablement

Google Cloud menggunakan service API.

Sebelum sebuah resource dapat digunakan, service tertentu biasanya harus diaktifkan terlebih dahulu.

Contohnya:

compute.googleapis.com
iam.googleapis.com
iamcredentials.googleapis.com
storage.googleapis.com
artifactregistry.googleapis.com

Jika API diaktifkan secara manual, sangat mudah terjadi kondisi seperti:

development
→ API aktif

staging
→ API aktif

production
→ API lupa diaktifkan

Dengan Infrastructure as Code, kebutuhan API dapat menjadi bagian dari configuration.

Terraform
   ↓
Enable Required APIs
   ↓
Create Resources

Dengan begitu, requirement setiap environment menjadi lebih eksplisit.

Logging dan Monitoring

Cloud foundation sebaiknya juga mempertimbangkan visibility.

Ketika workload berjalan, kita ingin memahami apa yang sebenarnya terjadi di dalam environment.

Contohnya melalui:

Cloud Logging
Cloud Monitoring
Audit Logs
centralized logging
alerting

Landing Zone tidak harus langsung mempunyai observability architecture yang sangat kompleks.

Tetapi baseline logging dan auditability sebaiknya sudah dipikirkan sejak awal.

Karena semakin banyak project yang dibuat, semakin sulit membangun visibility secara retroaktif.

Security Baseline

Security juga menjadi bagian penting dari Landing Zone.

Beberapa contoh concern yang biasanya mulai dipikirkan:

IAM
service account
secrets
network access
audit logging
resource policies
environment separation

Landing Zone tidak berarti semua masalah keamanan langsung selesai.

Tetapi Landing Zone membantu memastikan workload tidak selalu dimulai dari environment tanpa guardrail.

Terraform State

Ketika Terraform digunakan untuk membangun Landing Zone, ada satu komponen penting yang perlu dipahami: Terraform State.

Secara sederhana:

Terraform Configuration
        ↓
Terraform State
        ↓
Actual Infrastructure

Terraform menggunakan state untuk memahami resource yang sebelumnya sudah dibuat dan bagaimana resource tersebut berhubungan dengan configuration saat ini.

Misalnya, Terraform mengetahui bahwa:

google_storage_bucket.tf_state

merepresentasikan bucket tertentu di Google Cloud.

Tanpa state, Terraform tidak memiliki catatan yang cukup untuk memahami infrastructure yang sedang dikelolanya.

Pada environment yang digunakan bersama team atau CI/CD, state biasanya tidak hanya disimpan di laptop engineer.

Kita membutuhkan remote state.

Contohnya:

Developer / CI
      ↓
Terraform
      ↓
Remote State
      ↓
Google Cloud

Terraform State akan kita bahas lebih dalam di Infrastructure as Code Series 02.

Bootstrap: Infrastructure Sebelum Infrastructure

Di sinilah muncul masalah yang cukup menarik.

Terraform membutuhkan tempat untuk menyimpan remote state.

Terraform juga mungkin membutuhkan service account untuk menjalankan automation.

Tetapi bucket dan service account tersebut juga merupakan infrastructure.

Jadi muncul pertanyaan:

Jika Terraform membutuhkan infrastructure untuk bisa berjalan,
siapa yang membuat infrastructure pertama tersebut?

Proses awal ini biasanya disebut bootstrap.

Secara sederhana:

Bootstrap
   ↓
Remote State Bucket
Service Account
IAM
Workload Identity
   ↓
Landing Zone
   ↓
Remaining Infrastructure

Bootstrap biasanya berisi resource minimum yang diperlukan agar automation berikutnya dapat berjalan.

Contohnya:

remote state bucket
Terraform service account
IAM baseline
Workload Identity Federation
required APIs

Setelah foundation tersebut tersedia, Terraform dapat mulai mengelola infrastructure berikutnya dengan lebih terstruktur.

Topik bootstrap ini akan dibahas lebih dalam pada Infrastructure as Code Series 03.

Bagaimana Flow Infrastructure Berubah Setelah Menggunakan IaC?

Tanpa Infrastructure as Code, perubahan bisa terjadi seperti ini:

Engineer
→ Login Google Cloud
→ Change Resource
→ Done

Masalahnya, engineer lain mungkin tidak tahu bahwa perubahan tersebut terjadi.

Tidak ada review.

Tidak ada plan.

Tidak selalu ada catatan mengapa resource tersebut berubah.

Dengan Infrastructure as Code, flow-nya dapat berubah menjadi:

Engineer
      ↓
Modify Terraform
      ↓
Git Commit
      ↓
Pull Request
      ↓
Terraform Plan
      ↓
Code Review
      ↓
Terraform Apply
      ↓
Google Cloud

Perubahan infrastructure akhirnya mempunyai lifecycle yang lebih dekat dengan software development.

Kita bisa melihat perubahan sebelum diterapkan.

Kita bisa mendiskusikan apakah IAM yang diberikan terlalu luas.

Kita bisa melihat apakah sebuah resource akan dibuat, diubah, atau dihapus.

Infrastructure menjadi lebih mudah untuk direview sebagai sebuah team.

Contoh Membuat Environment Baru

Bayangkan kita membutuhkan project baru untuk sebuah backend application.

Tanpa automation:

Create Project
→ Connect Billing
→ Enable APIs
→ Create Service Account
→ Configure IAM
→ Create Network
→ Configure Logging
→ Deploy Application

Dengan Landing Zone yang sudah dibangun menggunakan Infrastructure as Code:

Add Project Configuration
        ↓
Pull Request
        ↓
Terraform Plan
        ↓
Review
        ↓
Terraform Apply
        ↓
Project Created
        ↓
IAM Baseline
        ↓
Required APIs
        ↓
Network Baseline
        ↓
Logging / Security Baseline
        ↓
Ready for Workload

Di sinilah repeatability terasa sangat nyata.

Engineer tidak perlu lagi mengingat seluruh checklist setiap kali membuat project baru.

Baseline tersebut sudah direpresentasikan dalam code.

Contoh Struktur Repository

Repository Infrastructure as Code dapat disusun dengan banyak cara.

Contoh sederhananya:

terraform-gcp-landing-zone/
├── bootstrap/
│   ├── providers.tf
│   ├── storage.tf
│   ├── service-accounts.tf
│   ├── iam.tf
│   └── wif.tf
│
├── environments/
│   ├── development/
│   ├── staging/
│   └── production/
│
├── modules/
│   ├── project/
│   ├── iam/
│   └── network/
│
└── .github/
    └── workflows/

Bukan berarti semua Landing Zone harus menggunakan struktur seperti ini.

Struktur repository dapat berkembang sesuai kebutuhan.

Yang lebih penting adalah separation of concerns.

Kita ingin bisa memahami:

mana bootstrap
mana reusable module
mana environment
mana automation

tanpa harus membaca seluruh repository terlebih dahulu.

Authentication untuk Terraform

Ketika Terraform berkomunikasi dengan Google Cloud, Terraform membutuhkan identity.

Untuk development dari local machine, flow sederhananya bisa seperti:

Engineer
   ↓
Google Cloud Authentication
   ↓
Terraform
   ↓
GCP

Tetapi ketika Terraform dijalankan melalui CI/CD, kita membutuhkan pendekatan authentication yang berbeda.

Contohnya menggunakan GitHub Actions:

GitHub Actions
      ↓
OIDC
      ↓
Workload Identity Federation
      ↓
Google Cloud Service Account
      ↓
GCP

Dengan pendekatan seperti ini, CI/CD tidak perlu lagi menyimpan long-lived service account JSON key.

Identity dapat diberikan menggunakan federation dan short-lived credentials.

Kita akan membahas flow tersebut secara khusus di Infrastructure as Code Series 04.

Landing Zone Tidak Harus Langsung Besar

Salah satu kesalahan yang mudah terjadi adalah menganggap Landing Zone harus langsung menjadi architecture yang sangat kompleks.

Padahal tidak selalu demikian.

Pada tahap awal, sebuah Landing Zone mungkin hanya mempunyai:

Project
Remote State
IAM
Required APIs
CI/CD Identity

Kemudian berkembang menjadi:

Organization
Folders
Project Factory
Centralized IAM
Shared Networking
Logging
Security Policies
CI/CD
Governance

Landing Zone sebaiknya berkembang berdasarkan kebutuhan nyata.

Tidak semua team membutuhkan organization hierarchy yang kompleks.

Tidak semua environment membutuhkan Shared VPC.

Tidak semua project membutuhkan policy yang sama.

Yang terpenting adalah memiliki foundation yang cukup jelas untuk terus berkembang.

Kapan Landing Zone Mulai Sangat Berguna?

Landing Zone menjadi semakin berguna ketika complexity cloud mulai bertambah.

Contohnya ketika kita mulai mempunyai:

banyak GCP project
development, staging, dan production
beberapa engineering team
centralized IAM
shared networking
compliance requirement
CI/CD deployment
standardized logging
standardized security baseline
kebutuhan membuat project baru secara rutin

Pada tahap tersebut, membuat infrastructure secara manual mulai sulit dipertahankan.

Landing Zone membantu mengubah foundation menjadi platform yang bisa digunakan kembali oleh banyak workload.

Hal yang Perlu Diperhatikan

Infrastructure as Code dan Landing Zone sangat membantu, tetapi ada beberapa hal yang perlu diperhatikan.

Jangan Membuat Landing Zone Terlalu Kompleks

Landing Zone seharusnya mengurangi complexity, bukan menambahkan complexity yang tidak diperlukan.

Mulailah dari requirement yang nyata.

Jika hanya membutuhkan beberapa project, tidak perlu langsung membuat hierarchy yang sangat besar.

Hindari IAM yang Terlalu Luas

Infrastructure as Code membuat IAM mudah dibuat.

Tetapi itu tidak berarti setiap service account harus mendapatkan role yang luas.

Principle of least privilege tetap penting.

Berikan permission berdasarkan kebutuhan workload.

Lindungi Terraform State

Terraform State dapat mengandung informasi penting mengenai infrastructure.

Remote state perlu diperlakukan sebagai bagian penting dari infrastructure itu sendiri.

Access terhadap state sebaiknya dibatasi dan dikelola dengan baik.

Hindari Manual Changes Tanpa Alasan yang Jelas

Jika sebuah resource sudah dikelola Terraform lalu diubah secara manual, configuration dan actual infrastructure dapat menjadi berbeda.

Kondisi ini disebut drift.

Tidak semua manual change selalu salah, terutama dalam kondisi incident atau emergency.

Tetapi perubahan tersebut sebaiknya kemudian direkonsiliasi kembali ke Infrastructure as Code.

Pisahkan Bootstrap dengan Jelas

Bootstrap mempunyai lifecycle yang berbeda dengan workload biasa.

Remote state bucket atau automation identity biasanya menjadi foundation bagi Terraform lainnya.

Karena itu, resource bootstrap sebaiknya mudah dikenali dan tidak tercampur dengan workload application.

Hindari Long-Lived Credentials

Service account JSON key memang mudah digunakan.

Tetapi long-lived credential membawa risiko tambahan.

Untuk automation modern, identity federation seperti Workload Identity Federation dapat menjadi pendekatan yang lebih baik ketika memungkinkan.

Landing Zone Bukan Produk yang Sekali Jadi

Landing Zone bukan sesuatu yang dibuat satu kali lalu tidak pernah disentuh lagi.

Cloud environment terus berkembang.

Team bertambah.

Project bertambah.

Security requirement berubah.

Network architecture berkembang.

Automation menjadi lebih matang.

Karena itu, Landing Zone juga akan terus berevolusi.

Hari pertama mungkin hanya berupa:

Project
IAM
State
APIs

Beberapa waktu kemudian bisa berkembang menjadi:

Organization
Folders
Project Factory
IAM
Networking
Security
Logging
Policies
CI/CD
Governance

Infrastructure as Code membantu evolusi tersebut tetap bisa dilihat dan direview melalui code.

Penutup

GCP Landing Zone membantu kita membangun cloud foundation sebelum workload mulai berkembang di atasnya.

Infrastructure as Code membantu foundation tersebut menjadi repeatable, konsisten, versioned, dan lebih mudah direview.

Keduanya mempunyai peran yang berbeda, tetapi saling melengkapi.

Landing Zone
=
Cloud foundation yang kita bangun

Infrastructure as Code
=
Cara kita mendefinisikan dan mengelola foundation tersebut

Tujuan akhirnya bukan membuat Terraform sebanyak mungkin.

Tujuannya juga bukan menghilangkan Google Cloud Console sepenuhnya.

Tujuannya adalah membuat infrastructure lebih mudah dipahami, direplikasi, direview, dan dikembangkan bersama team.

Di artikel berikutnya, kita akan membahas salah satu komponen terpenting dalam Terraform yang sering digunakan tetapi belum tentu langsung dipahami ketika pertama kali belajar Infrastructure as Code:

Terraform State

Kita akan melihat mengapa Terraform membutuhkan state, apa sebenarnya isi state, mengapa local state mulai menjadi masalah ketika bekerja dalam team, dan mengapa remote state menjadi bagian penting dari sebuah cloud foundation.