Belajar Infrastructure Engineer - Cloud Infrastructure

#Pendahuluan

Setelah sebelas episode membangun fondasi on-prem, kini kita masuk ke fase cloud. Di 2026, hampir tidak ada perusahaan yang murni on-prem atau murni cloud — dan setiap infrastruktur engineer wajib memahami keduanya. Episode 12 ini membangun dasar cloud yang akan kita perluas di episode 13 (hybrid/multi-cloud) dan 14 (K8s di cloud).

Mengapa topik ini penting? Karena cloud mengubah cara kalian berpikir: dari membeli hardware menjadi menyewa layanan lewat API; dari memperkirakan kapasitas setahun ke depan menjadi skala otomatis sesuai permintaan. Konsep-konsep on-prem yang sudah kalian kuasai tetap berlaku — hanya cara mewujudkannya yang berubah.

#Peta Cloud: Tiga Provider Besar

Konsep cloud hampir sama di semua provider — perbedaannya di nama layanan. Pahami pola, bukan hafalan:

Jangan terpaku pada satu provider — kemampuan berpindah bahasa cloud adalah kemampuan yang paling mahal di pasar.

#Blok Penyusun Infrastruktur Cloud

#Region dan Availability Zone

• Region: lokasi fisik data center (misal ap-southeast-1 = Singapura). Beda region = beda geografi.
• AZ (Availability Zone): data center terpisah dalam satu region, terhubung jaringan berlatensi rendah. Multi-AZ adalah cara cloud menerapkan HA.

Region ap-southeast-1
├── AZ ap-southeast-1a
├── AZ ap-southeast-1b
└── AZ ap-southeast-1c

Aturan emas ketersediaan cloud: sebarkan beban di minimal 2 AZ dalam satu region. Satu AZ mati (jarang tetapi pernah terjadi) tidak mematikan seluruh sistem.

#VPC dan Subnet

VPC adalah jaringan privat kalian di cloud. Di dalamnya, subnet membagi segmen — dan subnet public (punya internet gateway) vs private (tanpa akses internet langsung) adalah pola dasar arsitektur cloud:

VPC 10.0.0.0/16
├── Subnet public  10.0.1.0/24  → load balancer, bastion
└── Subnet private 10.0.2.0/24  → aplikasi, database

Beban kerja produksi yang benar: database tidak pernah di subnet public. Hanya load balancer dan entry point yang terbuka — ini fondasi yang sama dengan segmentasi on-prem (episode 18).

#Compute: VM dan Managed Service

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
  subnet_id     = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.web.id]
 
  tags = {
    Name = "web-01"
    Env  = "prod"
  }
}

Perhatikan pola baru di cloud: kalian tidak menentukan "berapa RAM dan core" secara mentah, melainkan memilih instance type yang merupakan bundle standar (t3.medium = 2 vCPU/4 GB, dan seterusnya).

#Object Storage: S3 dan Sahabatnya

Object storage adalah pondasi cloud: backup, media, arsip, dan data untuk aplikasi. Fitur yang wajib diaktifkan:

1. Block public access (default ketat)
2. Versioning: ON (perlindungan dari overwrite/hapus)
3. Encryption: SSE (di sisi server)
4. Lifecycle: otomatis turunkan tier / hapus
5. Object lock: immutability untuk data kritis

Kesalahan paling mahal di cloud: bucket yang sengaja dibuat public. Konfigurasi ini menyumbang jutaan kasus kebocoran data setiap tahun.

#Arsitektur Cloud Referensi

Gabungkan komponen di atas menjadi pola arsitektur web yang paling umum:

Pola ini menerapkan semua yang sudah kalian pelajari: HA (2 AZ), database managed (no ops), cache (performa), dan CDN (latensi). Kalian akan melihat variasi pola ini di hampir semua arsitektur cloud produksi.

#Network Security Group: Firewall Cloud

Setiap resource di cloud punya security group — firewall stateful di level instance:

resource "aws_security_group" "app" {
  name = "app-sg"
  vpc_id = aws_vpc.main.id
 
  ingress {
    from_port   = 8080
    to_port     = 8080
    protocol    = "tcp"
    cidr_blocks = [aws_subnet.public.cidr_block]
  }
 
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Perhatikan: hanya port 8080 yang bisa diakses dari subnet public; semua egress diizinkan. Prinsip yang sama dengan UFW deny-by-default di episode 11 — hanya diekspresikan sebagai API.

#IaC untuk Cloud

Cloud + IaC adalah pasangan sejati — tidak ada alasan mengklik console di cloud ketika API tersedia. Alur kerja standar dengan Terraform (dari episode 8):

terraform init
terraform plan -out=plan.tfplan
terraform apply plan.tfplan

State disimpan di backend remote (misal S3 + DynamoDB lock) — bukan di laptop:

terraform {
  backend "s3" {
    bucket         = "my-infra-state"
    key            = "prod/app/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-locks"
  }
}

#Mengelola Biaya Sejak Awal

Cloud memberi skala elastis — sekaligus tagihan elastis. Kebiasaan yang wajib ditanam dari episode ini:

1. Matikan resource non-produksi di luar jam kerja (auto stop)
2. Pakai managed service hanya bila menghemat tenaga, bukan karena gengsi
3. Monitor tagihan mingguan
4. Pasang budget alert sejak hari pertama
5. Tag semua resource (Env, Team, CostCenter) — episode 24

#Common Pitfalls Cloud

• Satu region tanpa AZ ganda: "region tidak pernah mati" adalah mitos — buktinya sejarah mencatat sebaliknya.
• Bucket public: kebocoran data terbesar di cloud.
• Security group terlalu longgar: 0.0.0.0/0 untuk port 22/5432 adalah undangan.
• State Terraform di laptop: hilang = infrastruktur kehilangan ingatan.
• Instance raksasa yang tidak pernah dimatikan: idle cost terbesar (episode 24).
• Mengklik console berulang kali: kalau diulang lebih dari sekali, harusnya kode.

#Penutup

Pada episode 12 ini kalian telah menguasai fondasi infrastruktur cloud:

• Pola tiga provider: region/AZ, VPC/subnet, compute, storage, IAM — nama beda, konsep sama.
• Arsitektur web referensi: CDN → ALB → app multi-AZ → managed DB + cache.
• Security group adalah firewall API; database tidak pernah di subnet public.
• Cloud + IaC (backend remote S3) adalah pasangan wajib.
• Tag, budget alert, dan terraform destroy menjaga tagihan tetap waras.

Di episode 13 selanjutnya kita menggabungkan dunia: hybrid & multi-cloud — mengintegrasikan on-prem dengan cloud lewat VPN/Direct Connect dan federation identity. Sampai jumpa di episode 13!