Subnet, CIDR, Routing #

Memahami konsep subnetting, notasi CIDR, dan aturan routing adalah keterampilan dasar yang mutlak dikuasai oleh setiap engineer cloud. Setiap kali kita merancang Virtual Private Cloud (VPC), membagi ruang alamat IP untuk kontainer Kubernetes, atau menghubungkan jaringan kantor ke cloud, kita akan selalu berhadapan dengan notasi matematis CIDR dan keputusan pembagian subnet. Pemahaman yang buruk mengenai pembagian alamat IP ini sering kali berujung pada kehabisan alamat IP saat auto-scaling aktif, atau bentrokan rute (routing collision) yang memaksa kita membangun ulang seluruh infrastruktur jaringan dari nol. Artikel ini akan mengupas tuntas cara membaca notasi CIDR, strategi merencanakan subnetting untuk lingkungan produksi, serta bagaimana Route Table menentukan arah aliran lalu lintas data secara cerdas.

Dasar Notasi CIDR: Matematika di Balik IP Addressing #

CIDR (Classless Inter-Domain Routing) adalah metodologi pengalamatan alamat IP yang menggantikan sistem pembagian kelas IP tradisional (Kelas A, B, C) yang dinilai tidak efisien dalam memanfaatkan ruang alamat IP. Format penulisan notasi CIDR selalu terdiri dari alamat IP dasar diikuti dengan garis miring dan angka biner yang disebut prefix length (panjang prefix): IP_Address/Prefix_Length.

Untuk membaca notasi CIDR, kita harus memahami struktur dasar alamat IPv4 yang terdiri dari 32 bit angka biner yang dibagi menjadi 4 oktet (masing-masing 8 bit). Angka setelah garis miring (prefix) menentukan berapa bit pertama yang bersifat statis (network portion) dan berapa bit sisanya yang bersifat dinamis untuk dialokasikan ke mesin (host portion).

Cara Menghitung Kapasitas IP dari Notasi CIDR:

  1. Notasi: 10.0.0.0/16
     → Prefix /16 berarti 16 bit pertama dikunci untuk identitas jaringan.
     → Sisa bit untuk host: 32 bit - 16 bit = 16 bit.
     → Total IP: 2^16 = 65.536 alamat IP.
     → Rentang IP: 10.0.0.0 hingga 10.0.255.255.

  2. Notasi: 10.0.1.0/24
     → Prefix /24 berarti 24 bit pertama dikunci.
     → Sisa bit untuk host: 32 bit - 24 bit = 8 bit.
     → Total IP: 2^8 = 256 alamat IP.
     → Rentang IP: 10.0.1.0 hingga 10.0.1.255.

Untuk mempermudah perencanaan jaringan, tabel di bawah ini menyajikan referensi cepat ukuran CIDR yang biasa digunakan di cloud:

Matematika Biner: Bagaimana Komputer Membaca Subnet Mask #

Di tingkat perangkat keras jaringan dan hypervisor cloud, komputer tidak mengenali angka desimal yang biasa kita baca (seperti 10.0.1.0). Komputer melihat seluruh alamat IP dalam bentuk string angka biner sepanjang 32 digit.

Subnet mask (prefix) bertindak sebagai filter biner. Ketika kita menetapkan notasi /24, kita memberi tahu sistem untuk menuliskan angka biner 1 sebanyak 24 kali berturut-turut, diikuti oleh angka 0 hingga panjangnya mencapai 32 bit.

Representasi Biner Subnet Mask /24:
  Desimal: 255.255.255.0
  Biner:   11111111.11111111.11111111.00000000
           |<─────── 24 bit network ───────>|  8 bit host

Ketika sebuah paket data masuk ke router virtual dengan tujuan IP tertentu, router akan melakukan operasi gerbang logika Bitwise AND antara alamat IP tujuan dengan subnet mask tersebut untuk menentukan apakah tujuan berada di jaringan lokal yang sama atau harus dilemparkan keluar melalui gateway.

Operasi Bitwise AND di Router Virtual:
  IP Tujuan:   10.0.1.55  →  00001010.00000000.00000001.00110111
  Subnet Mask: /24        →  11111111.11111111.11111111.00000000  (AND)
  ─────────────────────────────────────────────────────────────────────
  Hasil Network Address:     00001010.00000000.00000001.00000000  (10.0.1.0)

Jika hasil perhitungan bitwise AND tersebut sama dengan alamat jaringan lokal subnet (10.0.1.0), router tahu bahwa paket data dapat langsung dikirimkan ke VM tujuan secara lokal tanpa melewati gerbang luar. Jika hasilnya berbeda, router akan mengonsultasikan Route Table untuk melempar paket ke gateway eksternal.

Alokasi Reserved IP di Subnet Cloud #

Salah satu perbedaan penting antara jaringan fisik tradisional dan jaringan cloud adalah adanya alamat IP yang dicadangkan (Reserved IP). Pada jaringan lokal fisik, hanya ada 2 alamat IP yang tidak bisa dipakai: alamat jaringan (Network Address, IP pertama) dan alamat siaran (Broadcast Address, IP terakhir).

Namun, di lingkungan cloud, cloud provider mereservasi 5 alamat IP pertama dan terakhir di setiap subnet demi kepentingan operasional dan routing infrastruktur internal mereka.

Visualisasi Reservasi IP pada Subnet 10.0.1.0/24 (Total 256 IP):

  10.0.1.0   → Alamat Jaringan (Network Address) - Tidak bisa dipakai.
  10.0.1.1   → Alamat Router Internal VPC (VPC Router Gateway) - Dicadangkan.
  10.0.1.2   → Alamat Resolver DNS Internal (Route 53 / Cloud DNS) - Dicadangkan.
  10.0.1.3   → Alamat IP Cadangan untuk Kebutuhan Masa Depan - Dicadangkan.
  10.0.1.255 → Alamat Siaran Jaringan (Network Broadcast Address) - Tidak bisa dipakai.

  IP yang benar-benar bisa kita gunakan untuk VM: 10.0.1.4 hingga 10.0.1.254 (251 IP)

Jika kita mendeploy subnet dengan CIDR /28 (total 16 IP), maka kita hanya memiliki 11 IP usable (16 - 5 = 11). Apabila subnet ini digunakan untuk aplikasi dengan auto-scaling yang aktif, kapasitas IP tersebut akan habis dalam sekejap, mencegah instans VM baru aktif melayani request.

Strategi Segmentasi Subnet: Tiering Jaringan Produksi #

Dalam merancang arsitektur VPC yang aman untuk lingkungan produksi, kita disarankan untuk menerapkan pola 3-Tier Subnetting yang tersebar di minimal 2 atau 3 Availability Zones (AZ) untuk mencegah single point of failure.

flowchart TD
    subgraph VPC["VPC Utama: 10.0.0.0/16"]
        subgraph AZ_1a["Availability Zone 1 (AZ-1a)"]
            Pub1["Public Subnet 1<br>10.0.1.0/24"]
            Priv1["Private Subnet 1<br>10.0.10.0/24"]
            Data1["Data Subnet 1<br>10.0.20.0/24"]
        end
        subgraph AZ_1b["Availability Zone 2 (AZ-1b)"]
            Pub2["Public Subnet 2<br>10.0.2.0/24"]
            Priv2["Private Subnet 2<br>10.0.11.0/24"]
            Data2["Data Subnet 2<br>10.0.21.0/24"]
        end
    end

1. Public Subnet Tier (DMZ) #

Subnet ini terhubung langsung ke Internet Gateway (IGW) dan dialokasikan untuk resource yang harus dapat diakses secara langsung oleh internet luar.

• Resource: Application Load Balancer (ALB), NAT Gateway, Bastion Host.
• Routing: 0.0.0.0/0 diarahkan ke igw-xxxxxx.

2. Private Subnet Tier (Application) #

Subnet ini terisolasi dari internet luar dan hanya memiliki rute keluar searah (outbound-only) melalui NAT Gateway untuk kebutuhan mengunduh dependensi OS atau API integration luar.

• Resource: Application Server (NodeJS, Go, Java), Container Tasks, EKS Workers.
• Routing: 0.0.0.0/0 diarahkan ke nat-xxxxxx.

3. Data Subnet Tier (Database) #

Subnet ini memiliki tingkat isolasi tertinggi. Jaringan ini tidak memiliki rute ke internet luar sama sekali, baik masuk (inbound) maupun keluar (outbound). Komunikasi dibatasi secara lokal hanya untuk melayani compute layer.

• Resource: RDS Postgres/MySQL, Cluster Redis Cache, Database NoSQL.
• Routing: Hanya memiliki rute local (misal: 10.0.0.0/16 local).

Mekanisme Kerja Route Table: Longest Prefix Match Wins #

VPC router mengambil keputusan perutean paket data menggunakan aturan khusus yang disebut Longest Prefix Match (Pencocokan Prefix Terpanjang). Ketika sebuah paket data memiliki alamat IP tujuan tertentu, router akan memeriksa seluruh baris aturan di Route Table dan memilih aturan yang memiliki nilai prefix mask paling besar (paling spesifik).

Mari kita simulasikan bagaimana keputusan perutean ini diambil di dalam VPC:

Aturan Route Table Terpasang:
  Baris 1: 10.0.0.0/16   → local
  Baris 2: 10.0.5.0/24   → peering-connection-xyz
  Baris 3: 0.0.0.0/0     → internet-gateway

Kasus A: Tujuan Paket adalah 10.0.5.23 #

• Router mencocokkan IP ini dengan Baris 1 (/16), Baris 2 (/24), dan Baris 3 (/0).
• Karena /24 (Baris 2) lebih panjang dan lebih spesifik dibanding /16 (Baris 1), maka Baris 2 yang menang.
• Paket data dikirim ke peering-connection-xyz.

Kasus B: Tujuan Paket adalah 10.0.20.15 #

• IP ini cocok dengan Baris 1 (/16) dan Baris 3 (/0).
• Karena /16 (Baris 1) lebih spesifik daripada /0 (Baris 3), maka Baris 1 yang menang.
• Paket diproses di dalam VPC lokal secara aman.

Perutean Lintas Availability Zone dan Wilayah (Cross-AZ & Cross-Region Routing) #

Dalam merancang ketersediaan tinggi lintas Availability Zone (Multi-AZ), perutean lalu lintas jaringan harus memperhatikan implikasi biaya data transfer (data transfer charges) dan ketahanan terhadap bencana (fault tolerance).

1. Masalah NAT Gateway Multi-AZ (Anti-Pattern) #

Sebuah kesalahan desain yang sangat sering ditemui adalah mendeploy satu NAT Gateway tunggal di AZ-1a, kemudian menghubungkan Route Table dari private subnet di AZ-1a maupun AZ-1b ke satu NAT Gateway tersebut.

flowchart TD
    subgraph VPC["VPC Utama"]
        subgraph AZ_1a["Availability Zone 1a"]
            NatGW["NAT Gateway 1"]
            PrivSub1["Private Subnet 1"] -->|Routing| NatGW
        end
        subgraph AZ_1b["Availability Zone 1b"]
            PrivSub2["Private Subnet 2"] -->|Cross-AZ Routing| NatGW
        end
    end
    
    NatGW --> Internet["Internet (Outbound)"]

Mengapa arsitektur di atas berbahaya?

• Single Point of Failure (SPOF): Jika AZ-1a mengalami padam listrik atau crash hardware, NAT Gateway 1 akan mati. Akibatnya, private subnet di AZ-1b yang sehat secara komputasi akan kehilangan koneksi keluar ke internet secara total.
• Biaya Transfer Lintas AZ: Lalu lintas dari Private Subnet 2 di AZ-1b harus menyeberangi Availability Zone secara fisik untuk mencapai NAT Gateway di AZ-1a. Hal ini memicu biaya transfer data lintas AZ (Cross-AZ Data Transfer Fee) sebesar $0.01 per GB untuk setiap traffic keluar.

2. Solusi Desain Redundan: Satu NAT Gateway per AZ #

Desain terbaik adalah membangun satu NAT Gateway di masing-masing Availability Zone, dan membuat Route Table terpisah untuk setiap private subnet agar selalu menggunakan NAT Gateway lokal di zone yang sama.

Perencanaan Desain CIDR Agnostik Lintas Jaringan #

Salah satu kesalahan pemula yang paling fatal adalah menetapkan CIDR yang sama untuk setiap VPC yang mereka buat (misalnya menggunakan default 10.0.0.0/16 untuk semua VPC Dev, Staging, dan Prod).

Ketika bisnis berkembang, kita pasti akan membutuhkan integrasi lintas lingkungan tersebut, seperti membuat koneksi VPC Peering antara VPC Dev and VPC Staging, atau menghubungkan VPC Prod ke jaringan kantor pusat via VPN Tunnel. Jika CIDR kita tumpang tindih (overlap), rute jaringan akan bentrok dan tidak dapat saling terhubung.

// ANTI-PATTERN: Menggunakan CIDR yang bertubrukan (Overlap)
  VPC Production:  10.0.0.0/16
  VPC Staging:     10.0.0.0/16   ← BENTROK! Tidak akan pernah bisa dikoneksikan.

// BENAR: Merencanakan blok IP unik secara sistematis sejak awal
  VPC Production:  10.0.0.0/16   (IP: 10.0.0.0 - 10.0.255.255)
  VPC Staging:     10.1.0.0/16   (IP: 10.1.0.0 - 10.1.255.255)
  VPC Development: 10.2.0.0/16   (IP: 10.2.0.0 - 10.2.255.255)
  On-Premise Office: 192.168.0.0/16

Contoh Kode: Automasi Kalkulasi Jaringan dengan Terraform #

Untuk menghindari kesalahan kalkulasi IP secara manual, kita dapat memanfaatkan fungsi bawaan Terraform seperti cidrsubnet() untuk membagi VPC CIDR secara dinamis dan rapi:

# ✓ BENAR: Gunakan fungsi cidrsubnet() untuk mengotomatisasi pembagian IP secara dinamis

variable "vpc_cidr" {
  default = "10.0.0.0/16"
}

variable "availability_zones" {
  type    = list(string)
  default = ["ap-southeast-1a", "ap-southeast-1b"]
}

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr
  tags = {
    Name = "automation-vpc"
  }
}

# Membuat Public Subnets secara dinamis
resource "aws_subnet" "public" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  # cidrsubnet(iprange, newbits, netnum)
  # Hasil: index 0 -> 10.0.0.0/24, index 1 -> 10.0.1.0/24
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index)
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name = "dynamic-public-subnet-${count.index}"
  }
}

# Membuat Private Subnets secara dinamis
resource "aws_subnet" "private" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  # Menggunakan offset netnum untuk menghindari tumpang tindih
  # Hasil: index 0 -> 10.0.10.0/24, index 1 -> 10.0.11.0/24
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 10)
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name = "dynamic-private-subnet-${count.index}"
  }
}

Ringkasan #

• Notasi CIDR IP/N menentukan ukuran alamat IP — /16 memberikan 65.536 IP (ukuran VPC ideal), sedangkan /24 memberikan 256 IP (ukuran subnet ideal).
• Komputer memproses subnet mask secara biner — melakukan operasi Bitwise AND untuk mencocokkan apakah alamat IP tujuan lokal atau remote.
• Cloud provider mereservasi 5 alamat IP di setiap subnet — IP pertama, IP terakhir, serta 3 IP pertama setelah IP awal untuk DNS, router, dan fungsi internal.
• Terapkan pola 3-Tier Subnetting — pisahkan secara tegas Public Subnet, Private Subnet, dan Data Subnet demi keamanan optimal.
• Route table menggunakan aturan Longest Prefix Match — rute yang memiliki panjang netmask paling besar (paling spesifik) selalu diprioritaskan oleh router.
• NAT Gateway harus dideploy redundan per AZ — menghindari single point of failure dan meminimalkan biaya transfer data lintas AZ (Cross-AZ data transfer fees).
• Rencanakan CIDR agar tidak overlap — pastikan alokasi IP unik di seluruh VPC dan on-premise agar kelak bisa dikoneksikan via VPN atau Peering.
• Gunakan fungsi otomasi Infrastructure as Code (IaC) — manfaatkan fungsi cidrsubnet() di Terraform untuk membagi ruang alamat IP secara konsisten dan aman.

← Sebelumnya: Virtual Network (VPC / VNet)   Berikutnya: Public vs Private Network →