Belajar Cloud Computing - Hybrid Cloud & Multi-Cloud Connectivity

#Pendahuluan

Pada episode 17 kemarin kita membahas FinOps — cara mengendalikan biaya cloud agar tetap efisien dan tidak membengkak. Namun ada pertanyaan mendasar yang belum kita jawab: bagaimana jika perusahaan kalian belum seratus persen berada di cloud? Banyak organisasi nyata masih memiliki data center on-premise: server warisan yang menjalankan sistem ERP, database yang secara regulasi wajib berada di lokasi tertentu, atau aplikasi yang terlalu mahal dan berisiko untuk dipindahkan sekaligus.

Realita industri tidak pernah "all or nothing". Hampir semua perusahaan besar berjalan dalam mode hybrid cloud — sebagian workload di cloud, sebagian tetap di data center sendiri — dan semakin banyak yang memilih multi-cloud — memakai dua atau lebih penyedia cloud sekaligus. Kalau tiap bagian sistem berjalan di tempat yang berbeda, maka yang menghidupkan semuanya adalah konektivitas: jembatan yang menghubungkan data center kalian dengan VPC di cloud.

Pada episode ini kita akan membahas dua keluarga besar konektivitas hybrid: IPsec Site-to-Site VPN yang terenkripsi tapi melewati internet publik, dan dedicated private connection yang menggunakan jalur fiber privat tanpa menyentuh internet. Kita tutup dengan perbandingan layanan konektivitas di AWS, GCP, dan Azure.

#Mengapa Hybrid Cloud & Multi-Cloud Dibutuhkan

Sebelum masuk ke teknis, pahami dulu alasan bisnisnya. Ada tiga pendorong utama:

Migrasi bertahap. Memindahkan ribuan server dalam satu malam adalah mimpi buruk operasional. Jalur yang realistis adalah menggeser workload bertahap sementara sistem lama tetap berjalan melayani pengguna. Selama masa transisi itulah dua dunia harus saling terhubung dengan aman.

Kepatuhan dan regulasi. Data kartu pembayaran, rekam medis, atau data pemerintahan sering diatur harus berada di lokasi geografis tertentu. Region cloud bisa jauh dari lokasi yang disyaratkan regulasi; data center on-premise kalian bisa menjadi satu-satunya tempat yang memenuhi syarat untuk data tertentu.

Resiliensi dan antikebergantungan vendor. Menempatkan seluruh infrastruktur pada satu penyedia berarti satu gangguan di penyedia itu menghentikan semuanya. Multi-cloud juga memberi posisi tawar saat negosiasi harga dan memungkinkan memanfaatkan kekuatan masing-masing penyedia. Konsekuensinya lebih kompleks, tetapi untuk workload kritis banyak perusahaan bersedia membayarnya.

#Dua Keluarga Konektivitas Hybrid

Semua solusi konektivitas hybrid pada dasarnya jatuh ke dalam dua keluarga: melewati internet publik dengan enkripsi, atau memakai jalur privat khusus yang tidak tersentuh internet.

#IPsec Site-to-Site VPN

IPsec Site-to-Site VPN membangun tunnel terenkripsi antara perangkat VPN di data center kalian (router atau firewall on-premise) dan VPN gateway di cloud, di atas internet publik.

Analogi yang paling tepat: internet adalah jalan raya umum yang ramai dan bisa disadap. IPsec adalah terowongan pribadi yang dibangun menembus jalan raya itu. Dari luar, orang tetap bisa melihat ada kendaraan keluar-masuk jalan raya — tetapi isi dan arah perjalanannya tersegel di dalam terowongan yang hanya bisa dibuka oleh dua ujung yang memegang kunci yang sama. Keuntungannya nyata: murah, cepat dipasang (hitungan jam hingga hari), dan seluruh lalu lintas otomatis terenkripsi oleh protokol. Kekurangannya juga jelas: lalu lintas tetap ikut memakai infrastruktur internet publik, sehingga latensi tidak terjamin dan bandwidth terbatas oleh kualitas koneksi internet kantor kalian.

IPsec bekerja dalam dua fase. Konsepnya penting kalian pahami karena semua perangkat VPN — StrongSwan, firewall Cisco, hingga VPN gateway cloud — memakai parameter yang sama persis:

Di AWS, VPN gateway dibuat lewat layanan AWS Site-to-Site VPN. Perintah CLI berikut membuat koneksi VPN yang menautkan customer gateway (sisi on-premise) ke virtual private gateway (sisi AWS):

aws ec2 create-vpn-connection \
  --customer-gateway-id cgw-0123456789abcdef0 \
  --type ipsec.1 \
  --vpn-gateway-id vgw-0abcdef1234567890

Perintah di atas menghasilkan dua tunnel yang masing-masing memiliki endpoint IP dan PSK berbeda. Kedua tunnel inilah yang dipasang pada perangkat VPN on-premise; jika satu tunnel putus, tunnel lainnya tetap membawa lalu lintas — karena itulah site-to-site VPN selalu hadir berpasangan untuk high availability. Perhatikan bahwa --type ipsec.1 di sini adalah nama jenis koneksi AWS, bukan versi protokol IPsec — jangan tertukar dengan IKEv2.

#Dedicated Private Connection

Keluarga kedua adalah jalur fiber optik privat yang menghubungkan data center kalian langsung ke jaringan penyedia cloud — tanpa pernah melewati internet publik. Di AWS layanan ini bernama AWS Direct Connect, di GCP Cloud Interconnect (Dedicated atau Partner), dan di Azure Azure ExpressRoute.

Lanjutkan analogi di atas: kalau IPsec adalah terowongan di tengah jalan raya umum, dedicated connection adalah membangun rel kereta khusus milik sendiri. Tidak ada kendaraan lain di jalur itu, tidak ada antrean lalu lintas publik, dan kapasitasnya bisa diatur sesuai kebutuhan — dari ratusan Mbps hingga ratusan Gbps. Karena jalurnya tidak berbagi dengan traffic publik, latensi lebih konsisten dan rendah, sangat penting untuk replikasi database atau workload dengan sensitivitas latency tinggi.

Konsekuensinya juga masuk akal: lebih mahal, dan provisioning jauh lebih lama. Penyedia telekomunikasi harus menarik fisik fiber dari lokasi kalian ke titik peering penyedia cloud, sehingga prosesnya biasanya berminggu-minggu hingga berbulan-bulan, bukan berjam-jam. Kalian tidak bisa "menyalakan" dedicated connection secara instan seperti VPN.

Ada satu hal yang sering disalahpahami. Koneksi privat tidak otomatis berarti terenkripsi: paket berjalan di jaringan yang dikendalikan penyedia cloud dan telekomunikasi, bukan di internet terbuka — itu soal jalur, bukan soal kriptografi. Jika regulasi kalian mewajibkan enkripsi end-to-end, tetap tambahkan lapisan enkripsi di atasnya, misalnya MACsec untuk Direct Connect atau tunnel IPsec yang "menumpang" di atas jalur privat tersebut.

#Perbandingan Site-to-Site VPN vs Dedicated Connection

#Komparasi Layanan Konektivitas Big 3 Cloud

Setiap penyedia menawarkan pasangan layanan yang sama: satu berbasis VPN di atas internet, satu berbasis dedicated connection.

Konsepnya identik, nama dan detail implementasinya berbeda. Di GCP, Cloud VPN mendukung dua tunnel aktif sekaligus (High Availability VPN), dan Cloud Interconnect hadir dalam dua opsi: Dedicated Interconnect untuk port fiber khusus dan Partner Interconnect yang disediakan lewat provider telekomunikasi pihak ketiga — berguna ketika lokasi kalian tidak terjangkau port langsung. Di Azure, VPN Gateway mendukung konfigurasi active-active, sementara ExpressRoute punya opsi ExpressRoute Local untuk koneksi hanya ke satu region tertentu dengan biaya lebih rendah.

#Penutup

Pada episode 18 ini kalian memahami bahwa konektivitas hybrid dibangun dari dua keluarga: IPsec Site-to-Site VPN — murah, cepat dipasang, terenkripsi otomatis, tetapi bergantung pada kondisi internet publik — dan dedicated private connection seperti Direct Connect, Cloud Interconnect, dan ExpressRoute — stabil dan berkapasitas besar, tetapi mahal dan lama provisioning-nya.

Poin kunci yang perlu kalian bawa:

• Hybrid cloud dan multi-cloud bukan tren belaka, melainkan realita migrasi bertahap, kepatuhan, dan resiliensi.
• Parameter IPsec konseptualnya sama di semua vendor: IKE version, PSK, algoritma enkripsi, dan tunnel CIDR.
• VPN di atas internet publik selalu terenkripsi; jalur privat belum tentu terenkripsi.
• Dedicated connection unggul pada stabilitas dan bandwidth, tetapi lebih mahal dan lebih lama dibangun.
• Pola produksi yang umum: dedicated sebagai primary, VPN sebagai backup.
• Nama layanan berbeda antar penyedia, konsepnya satu: AWS Site-to-Site VPN/Direct Connect, GCP Cloud VPN/Interconnect, Azure VPN Gateway/ExpressRoute.

Semua konektivitas ini punya satu tujuan: menjaga sistem tetap hidup dan saling terhubung. Pertanyaan besar muncul berikutnya — apa yang terjadi ketika koneksi, server, bahkan satu region penuh mati? Di episode 19 selanjutnya kita akan membahas Disaster Recovery & Business Continuity: metrik RPO dan RTO, empat strategi pemulihan dari backup-and-restore hingga multi-region active-active, dan cara menyusun rencana agar bisnis tetap berjalan saat bencana. Pastikan tetap semangat!