Apa itu jaringan virtual Azure? Kebanyakan orang mendengar istilah itu dan menganggapnya hanya pengaturan tambahan saat menerapkan mesin virtual, sesuatu yang dicentang lalu dilupakan. Namun tidak kenyataan, jaringan virtual Azure bukan sekadar pengaturan. Ini adalah fondasi dari sekelas Zootio yang Anda bangun di Azure. Setiap mesin virtual, basis data, layanan aplikasi, dan fungsi yang Anda terapkan semuanya berada di dalamnya. Dan jika Anda tidak memahami cara kerjanya, Anda tidak akan tahu apa-apa. Di akhir episode ini Anda akan memahami apa itu vNet sebenarnya, cara kerjanya, dan mengapa setiap sumber daya yang Anda terapkan bergantung padanya. Kami akan membahas apa itu vNet, cara kerja alamat IP, subnet, keamanan, perhubungan, dan cara menghubungkan vNet. Ambil kopi Anda dan mari kita mulai. Apa itu vNet? Jaringan cloud pribadi. Mari kita mulai definisi paling sederhana. Azure Virtual Network, atau disingkat vNet, adalah jaringan pribadi Anda sendiri di dalam Azure.

Anggaplah seperti gedung kantor pribadi. Hanya orang yang Anda izinkan yang bisa masuk. Anda mengontrol siapa yang masuk, siapa yang keantai mana, dan siapa yang dilarang sepenuhnya. Sebelum vNet ada, kondisinya berbeda. Menerapkan mesin virtual di cloud berarti secara default ekspos ke internet. Tidak ada jaringan pribadi di sekitar. Siapapun yang tahu alamat IP-nya bisa mencoba terubuh. Itu adalah mimpi buruk keamanan. Apa yang berubah? Azure memberi Anda kemampuan untuk membuat ruang jaringan pribadi yang terisolasi. Anda mendukang batasnya. Anda memutuskan apa yang ada di dalamnya. Tidak ada yang di luar batas itu bisa masuk kecuali Anda mengizinkannya secara eksplisit. Satu hal yang perlu diketahui di awal, vNet Anda berada di wilayah Azure tertentu. Ini tidak bersifat cloud. Buat vNet di Eropa Barat dan disitulah ia berada. Sumber daya berbeda tidak bisa langsung masuk ke dalamnya.

Mereka memerlukan vNet sendiri. Atau Anda harus menghubungkannya nanti. Seandainya membuat vNet, Anda menentukan sendiri ruang alamat IP-nya. Azure tidak memilih contohan. Anda menentukan tentang alamat IP yang akan digunakan sumber daya Anda. Itu adalah tanggung jawab besar dan kami akan membahas cara melakukannya dengan benar di bagian berikut. Berapa yang utamanya? VNet adalah fondasinya. Setiap mesin virtual, setiap basis data, setiap fungsi Azure yang Anda terapkan berada di dalamnya. Tanpa vNet, sumber daya Anda tidak memiliki konteks jaringan pribadi. Mereka hanya mengapung di cloud tanpa batas, tanpa isolasi, dan tanpa keamanan. Apa artinya ini bagi Anda? Jika Anda membangun apapun di Azure, mulailah dengan vNet terlebih dahulu. Bukan setelah Anda mendeploy sumber daya Anda, melainkan sebelumnya. VNet Anda adalah lahan tempat Anda membangun. Anda tidak akan membangun rumah dan membeli tanahnya terlebih dahulu, bukan?

Gagasan yang sama. Pengalamatan IP dan CIDR memilih ruang alamat Anda. Jadi mari kita mulai. Saat membuat vNet, keputusan besar pertama adalah memilih rentang IP. Anda melakukannya menggunakan notasi CIDR. CIDR adalah singkatan dari Classless Interdomain Routing. Namun artinya hanya Anda menyatakan saya butuh sekian banyak alamat IP. Mengapa ini penting? Karena rentang yang Anda pilih menentukan berapa banyak sumber daya yang dapat dimuat dalam jaringan virtual Anda. Ini cara kerjanya. CIDR menggunakan garis miring dan angka, seperti 16 atau 24. Angka tersebut memberi tahu Anda ukuran ruang alamat. Angka 16 memberi Anda sekitar 65 ribu alamat IP. Sangat banyak. Angka 24 memberi Anda sekitar 290 yang sempurna untuk tim kecil atau satu tingkat aplikasi. Jadi, saat melancang vNet, Anda perlu memikirkan berapa banyak sumber daya yang akan Anda miliki dan bagaimana Anda ingin mengompokkannya.

Nah, Anda tidak bisa sembarangan memilih rentang IP. Azure mengikuti standar RFC 1918 yang menyisikan rentang IP privat untuk jaringan internal. Anda memiliki 3 opsi. Rentang 10TX-CTX adalah yang terbesar memberi Anda banyak ruang untuk berkembang. Rentang 107TX sedikit lebih kecil, namun tetap berguna. Dan rentang 1920TX-X adalah yang mungkin Anda miliki di rumah pada router Anda. Ini masalahnya, ruang alamat vNet Anda tidak boleh tumpang tindih dengan jaringan lain yang ingin Anda hubungkan. Ini adalah kesalahan yang umum. Banyak orang memilih rentang yang terlihat familiar hanya untuk mengetahui nantinya bahwa rentang tersebut berkonflik dengan jaringan perusahaan mereka. Jadi, jika jaringan kantor perusahaan Anda menggunakan 10TX-CTX-16, jangan gunakan rentang yang sama di Azure. Jika Anda mencoba mukanya nanti, keduanya akan bentrok dan lalu lintas tidak akan tahu kemana. Ijinkan saya memberikan contoh kongkak.

Bayangkan Anda membangun pengaturan hibrida, di mana Azure terhubung kembali ke pusat data on-premises Anda dan pusat data Anda menggunakan 10TX-16. Jika Anda membuat vNet dengan rentang yang sama, Anda akan memiliki 2 jaringan yang memperebutkan IP yang sama. Pikirkanlah, 2 jaringan yang menggunakan rentang IP yang sama tidak dapat berkomunikasi dengan Anda. Ini seperti 2 rumah dengan alamat yang sama. Surat menjadi bingung. Itu adalah masalah yang tidak ingin Anda selesaikan setelah kejadian. Jadi, rencanakan ke depan dan pilih rentangnya. Dan ini tips perencanaan. Pilihlah rentang yang lebih besar dari yang Anda pikir Anda butuh. Anda mungkin berpikir hanya butuh 24 sekarang, tetapi saat aplikasi Anda berkembang, Anda akan berharap punya 16. Anda tidak bisa mengubahnya dengan mudah. Setelah vNet dibuat dan sumber daya diterapkan, mengubah ruang alamat akan merepotkan. Itu mungkin dilakukan, tetapi bukan hal yang ingin Anda lakukan pada sistem yang sedang berjalan.

Jadi, berdiri Anda ruang untuk bertemu. Aptainya ini bagi Anda. Anggap ruang alamat vNet Anda seperti membeli tanah, dapatkan yang cukup untuk pertumbuhan di masa. Jika Anda merasa betulan kecil, belilah yang berukuran sedang. Anda berima kasih pada diri sendiri. Itulah poin utamanya. Rencanakan ruang alamat Anda dengan mempertimbangkan pertemuan di masa depan. Subnet membagi jaringan Anda. Jadi, Anda sudah punya vNet dan telah memilih ruang alamat Anda. Lalu apa? Anda tidak bisa begitu saja menumpuk semuanya ke dalam satu. Disitulah subnet berperan. Subnet adalah salah satu blok pembangun mendasar dari vNet Anda. Subnet mengginkan Anda mengatur dan mengamankan sumber daya. Subnet adalah bagian yang lebih kecil dari ruang alamat vNet Anda. Jika vNet adalah bangunannya, subnet adalah ruangan-ruangan di dalamnya. Anda tidak akan menempatkan ruang server, meja resepsionis, dan ruang istirahat di ruangan terbuka yang sama, bukan?

Idenya sama di sini. Ini konsep sederhana, tetapi membuat perbedaan besar dalam cara Anda mengelola jaringan. Sumber daya yang berbeda ditempatkan di subnet yang berbeda. Server web Anda di satu subnet, basis data di subnet lain, dan logika aplikasi di subnet ketiga. Mengapa? Dua alasan, keamanan dan organisasi. Mari bahas keamanan dulu, karena itu biasanya yang paling penting. Keamanan yang utama. Jika seseorang merota server web Anda, Anda tidak ingin mereka memiliki akses langsung ke basis data. Subnet terpisah menciptakan penghalang ini. Penyerang harus melewati batas itu dan Anda bisa mengontrol dengan tepat apa yang melintasinya. Anda juga bisa menggunakan kelompok keamanan jaringan untuk mengontrol lalu lintasan. Itu topik untuk video lain, tetapi penting untuk mengetahui bahwa subnet adalah fondasi bagi keamanan tersebut. Organisasi yang kedua. Teka semuanya punya tempatnya, pengelolaannya jadi lebih mudah.

Anda tahu subnet mana yang berisi sumber daya frontend dan mana yang menampung data backend Anda. Anda bisa menerapkan kebijakan dan aturan ke seluruh subnet sekaligus alih-alih mengonfigurasi tiap sumber daya secara individu. Menghemat waktu dan mengurangi kesalahan. Nah ini detail yang sering mengejutkan orang. Azure mencadangkan lima alamat IP di setiap subnet untuk kebutuhan internal, seperti perhutuan internal, seperti perhutuan internet. Jadi jika Anda membuat subnet dengan rentang dua pagi yang memberi Anda 250 malamat, Anda sebenarnya hanya mendapatkan 200 ribu lakan bisa digunakan. Itu adalah cipakan yang memutuskan. Anda merencanakan 256 namun hanya mendapatkan 200 ribu lakan. Jadi selalu tambahkan sedikit cadangan saat menentukan ukuran subnet. Kabar baiknya Anda bisa menambahkan subnet setelah membuat vnet. Anda tidak terpaku pada subnet yang dibuat saat awal. Jadi jika Anda butuh subnet terpisah untuk alat manajemen atau sistem pemantauan, tambahkan saja nanti.

Tidak masalah. Namun tetap lebih baik untuk merencanakannya sejak awal. Menambahkan subnet nanti memang bisa, tapi Anda mungkin perlu memindahkan sumber daya yang bisa mengganggu. Namun di praktek terbaiknya, gunakan subnet terpisah untuk tingkat aplikasi yang berbeda sejak awal. Pikirkan tentang arsitektur aplikasi Anda. Biasanya ada tingkat front end untuk permintaan pengguna, back end untuk logika bisnis, dan data untuk penyimpanan. Masih harus memiliki subnet-nya sendiri. Jangan menunggu sampai tahap produksi untuk menyadari perlunya misalkan hal tersebut. Itu jauh lebih sulit jika sumber daya sudah diterapkan. Partinya ini bagi Anda. Subnet adalah cara Anda menjaga jaringan tetap terorganisir dalam. Ibarat ruangan-ruangan di gedung Anda. Rencanakan lebih awal dan beri setiap tingkat aplikasi ruangnya sendiri. Begitulah cara Anda menjaga jaringan tetap rapi dalam. IP public versus private.

Siap bisa, baca. Mari bahas alamat IP karena tidak semua alamat IP itu sama. Saat Anda menerapkan sumber daya di dalam vnet, Anda mendapatkan IP privat secara default. Itu alamat yang digunakan untuk berkomunikasi dengan sumber daya lain di dalam vnet. Bayangkan seperti nomor ekstensi telepon internal. Hanya orang di dalam gedung yang bisa menghubungi. IP privat hanya dapat diakses dari dalam vnet atau jaringan yang terhubung dengannya. Jika Anda di rumah memakai laptop, Anda tidak bisa menjangkau IP privat di Azure. IP tersebut tidak ada di internet. IP tersebut ada di dalam jaringan privat. Jadi bagaimana membuat sumber daya bisa diakses dari internet? Anda memberinya alamat IP public. Itu alamat yang terlihat oleh dunia luar. Seperti nomor telepon publik alih-alih ekstensi internal. Ini poin kuncinya. IP public bersifat opsional. Anda menetapkannya secara eksplisit. Karena Azure tidak pernah memberikan IP public kecuali Anda memintanya.

Itu yang dirancang, bingung. Defaultnya haruslah privat dan publik harus menjadi pilihan yang disengaja. Dan disinilah banyak pemula melakukan kesalahan. Mereka memberikan IP public ke segalanya. Server web, basis data, dan IP backend mereka semua diberi IP public. Itu adalah si keamanan. Basis data Anda tidak perlu bisa dijangkau dari internet. Begitu pula IP backend Anda. Hanya sumber daya frontend yang benar-benar berinteraksi dengan pengguna yang harus memiliki IP public. Nah, IP public hadir dalam dua jenis, statis dan dinamis. IP public statis tetap sama meskipun Anda menghentikan dan memulai ulang sumber daya. IP public dinamis bisa berubah-ubah. Jika Anda menjalankan aplikasi produksi, Anda mungkin butuh IP statis agar pengguna selalu bisa menemukan Anda. Jika Anda sedang menguji sesuatu, IP dinamis mungkin sudah cukup. Anda juga bisa menggunakan apa yang disebut prefix IP public yang memungkinkan Anda memesan blok alam.

Alih-alih membuatnya satu per satu, Anda memesan rentang lalu. Menetapkan alamat individu dari rentang tersebut. Berguna jika Anda tahu akan membutuhkan banyak IP public untuk sebuah proyek. Apa artinya ini bagi Anda? IP private adalah standar yang aman. IP tersebut adalah ekstensi telepon internet. IP public adalah pilihan yang disengaja, yang Anda buat hanya saat perlu sesuatu yang dapat diakses dari luar. Dan saat Anda membutuhkannya, pikirkan apakah Anda perlu yang statis atau dinamis, dan apakah prefix itu masuk akal. Grup keamanan jaringan mengendalikan lalu lintas. Jadi Anda sudah mengatur vnet, subnet, dan alamat IP Anda. Namun bagaimana Anda benar mengontrol lalu lintas apa yang diizinkan masuk dan keluar? Disitulah peran grup keamanan jaringan atau NSG. NSG adalah penjaga gerbang yang mengontrol lalu lintas yang masuk dan keluar dari sumber daya Anda. Bayangkan seperti petugas keamanan di pintu kulab, memperiksa identitas, melihat daftar tamu, dan menolak siapapun yang tidak seharusnya ada di sana.

Setiap lalu lintas yang mencoba mencapai sumber daya Anda harus melewati petugas ini terlebih dahulu. NSG bekerja dengan aturan. Setiap aturan menyatakan izinkan atau tolak berdasarkan 4 hal. Alamat IP sumber, alamat IP tujuan, nomor port, dan protokol, dan protokol. Jadi Anda bisa mengatakan izinkan lalu lintas dari alamat IP kantor saya pada port 443. Atau tolak semua lalu lintas dari internet pada port 22. Montrol semacam itu. Nah ini adalah fitur yang kuat. Anda bisa melampirkan NSG ke subnet atau langsung ke antarmuka jaringan 1VM. Jika Anda melampirkannya ke subnet, NSG tersebut berlaku untuk semua yang ada di dalam. Setiap PM, setiap basis data, setiap sumber daya. Ini adalah kebijakan Omel. Jika Anda melampirkannya ke antarmuka jaringan VM tertentu, itu hanya berlaku untuk satu mesin tersebut. Anda bahkan bisa melakukan keduanya. NSG tingkat subnet untuk aturan luas dan NSG tingkat NEC untuk pengecualian.

Aturan bawaan yang dibuat Azure cukup masuk akal. Mereka mengizinkan semua lalu lintas di dalam vnet agar sumber daya Anda dapat saling berkomunikasi dan mereka menolak semua lalu lintas dari internet sehingga tidak ada dari luar yang bisa menjangkau sumber daya Anda kecuali Anda mengizinkannya secara eksplis. Itu adalah titik awal yang baik. Jangan saya memberikan contoh. Katakanlah Anda mengelola mesin virtual Linux dan Anda perlu melakukan SSH ke dalam. Anda akan membuat aturan NSG yang mengizinkan lalu lintas masuk pada port 22, tetapi Anda tentu tidak ingin mengizinkan SSH dari mana saja. Itu sama saja menggunakan masalah. Jadi Anda membatasinya ke alamat IP Anda sendiri, sehingga hanya Anda yang bisa melakukan SSH dan yang lainnya akan diblokir. Ide yang sama berlaku untuk RDP pada port 389 untuk mesin Windows. Apa arti ini bagi Anda? NSG adalah lini pertahanan pertama Anda dan bagian terbaiknya semuanya gratis.

Tidak ada biaya tambahan untuk menggunakannya, jadi tidak ada alasan untuk tidak memasang. Setiap subnet, setiap sumber daya harus memiliki NSG yang terpasang. Mulailah dengan menolak semua dan hanya buka apa yang Anda perlukan. Tabel rute dan perutean mengarahkan lalu lintas. Sekarang mari kita bahas tentang perutean, karena setelah Anda menentukan lalu lintas apa yang diizinkan, Anda perlu menentukan kemana lalu lintas tersebut sebenarnya pergi. Begini, Azure secara otomatis membuat rute sistem untuk setiap subnet. Anda tidak perlu melakukan apa-apa. Bayangkan ini seperti GPS bawaan yang mengetahui jalan-jalan dasar. Lalu lintas di dalam v-net, lalu lintas ke v-net yang di piring, lalu lintas ke internet. Semuanya langsung berfungsi, tetapi terkadang GPS bawaan tidak membawa Anda ke tempat yang Anda inginkan. Setelah itu, Anda memerlukan rute yang ditentukan pengguna atau UDR. Ini memungkinkan Anda mengganti rute sistem Azure dan mengendalikan calur yang di lalu lintas.

Bagaimana cara kerjanya? Anda membuat tabel rute. Anda menambahkan rute kustoman. Kemudian Anda mengaitkan tabel rute tersebut dengan sebuah subnet. Sejak saat itu, lalu lintas yang meninggalkan subnet tersebut akan mengikuti aturan Anda, bukan Anda. Izinkan saya memberikan contoh konkret. Katakanlah Anda yang semua lalu lintas internet dari v-net Anda melewati firewall terlebih dahulu. Mungkin Anda perlu meriksanya, mencatatnya, atau memblokir situs berbahaya. Rute sistem default mengirimkan lalu lintas internet langsung keluar. Bukan itu yang Anda inginkan, jadi Anda membuat rute yang menyatakan bahwa semua lalu lintas yang menuju ke 0.0.0.0.0.0.0 yang berarti kemana saja di internet harus diarahkan ke firewall. Itulah rute yang ditentukan pengguna. Tabel rute menggunakan sesuatu yang disebut next hop. Itu adalah tujuan tempat lalu lintas dikirim selanjutnya. Anda memiliki beropo. Anda bisa mengirimnya ke appliance virtual seperti firewall.

Anda bisa mengirimnya ke gateway jaringan virtual yang merupakan cara Anda terhubung ke jaringan up-premises. Anda bisa mengirimnya langsung ke internet, atau tidak mengirimnya kemanapun, yang pada dasarnya akan memutus lalu lintas tersebut. Hal utama yang perlu dipahami adalah bahwa perutean adalah cara Anda mengontrol jalur lalu lintas melalui jaringan Anda. Rute sistem adalah standar yang baik, tetapi tidak selalu tepat untuk situasi Anda. Jika Anda perlu agar lalu lintas melewati titik inspeksi atau gateway tertentu, atau diblokir sepenuhnya, Anda memerlukan rute yang ditentukan pengguna. Apa artinya ini bagi Anda? Perutean adalah cara Anda memberitahu lalu lintas kemana harus pergi, dan Anda memiliki kuasa untuk mengabaikan pengaturan default Azure kapan pun dipenuhkan. Mulalah dengan rute sistem, pahami fungsinya, lalu tambahkan rute custom saat arsitektur Anda memerlukannya. Piring VNet menghubungkan jaringan Sejauh ini kita telah membahas satu VNet, satu gedung, satu jaringan privat.

Namun apa yang terjadi jika Anda memiliki beberapa VNet? Mungkin Anda memiliki satu untuk lingkungan produksi, dan satu lagi untuk pengujian, atau mungkin Anda menjalankan aplikasi di wilayah Azure yang berbeda. Secara default, VNet ini benar-benar terisolasi. Mereka tidak bisa saling berkomunik. Mereka seperti bangunan terpisah tanpa jalan di antaranya. Di situlah peran Piring VNet. Fitur ini memungkinkan Anda menghubungkan dua VNet secara privat dan yang sebenarnya berbeda. Lalu lintas antar VNet yang di pairing tetap berada di jaringan tulang punggung Microsoft. Lalu lintas tersebut tidak pernah menentu internet. Itu berarti latensi rendah, bandwidth tinggi, dan tambah papanan terhadap ancaman luar. Berikut sesuatu yang mengejutkan banyak orang. Piring juga bisa bekerja antar wilayah. Itu disebut piring global. Anda bisa memiliki VNet di Eropa Barat yang dipiring dengan VNet di Asia Tenggara, dan lalu lintas di antaranya tetap berada di jaringan privat Microsoft.

Tanpa gateway VPN, tanpa IP publik, hanya koneksi privat langsung. Namun ada satu aturan yang mutak tidak boleh dilanggar. VNet yang di pairing harus memiliki ruang alamat yang tidak tumpang tindis. Jika kedua VNet mencoba menggunakan rentang 10T0T0T16, mereka tidak bisa di pairing. Alamat IP akan bentrok, dan Azure tidak akan tahu ke jaringan mana paket tersebut berasal. Jadi ingat tips perencanaan sebelumnya tentang memilih ruang alamat dengan cermat. Inilah alasan. Jika Anda berpikir untuk melakukan pairing VNet di kemudian hari, pastikan rentang alamatnya tidak tumpang tindis ya. Nah ini detail yang sering membuat orang bingung. Piring bersifat non-transitif. Artinya itu, katakanlah VNet A di pairing dengan VNet B dan VNet B di pairing dengan VNet C. VNet A tidak secara otomatis menjangkau VNet C melalui B. Mereka tidak terhubung. Setiap pairing adalah hubungan langsung antara tepat dua VNet.

Jika Anda ingin A berkomunikasi dengan C, Anda merlukan pairing terpisah antara A dan C. Jadi bagaimana Anda nyelam sekarang besar? Anda menggunakan arsitektur hub dan spok. Satu VNet pusat, yaitu hub. Dihubungkan peer dengan banyak VNet lain, yaitu spok. Hub mungkin berisi layanan bersama seperti firewall, gateway VPN, atau alat pemantauan. Spok berisi beban kerja individual Anda. Setiap spok terhubung langsung dengan hub, tetapi antar spok tidak saling terhubung. Jika satu spok belum mengakses spok lain, lalu lintas akan melewati hub. Hal ini menjaga semuanya tetap teratur dan memberi Anda tempat terpusat untuk menerapkan kebijakan. Apa yang ini bagi Anda? Piring adalah cara Anda membangun jaringan yang mencakup banyak VNet dan wilayah. Ini ada jembatan di antara bangunan Anda. Rencanakan ruang alamat Anda agar tidak tumbang dini. Ingatlah bahwa piring tidak bersifat transitif dan pertimbangkan di sen hub dan spok saat Anda mulai berkembang melampaui satu VNet.

Bagaimana semuanya terhubung? Gambaran besar. Jadi, mari kita mundur dan melihat bagaimana potongan ini sebenarnya menyapa. Disitulah letak kekuatan yang sungguh. Anda mulai dengan sebuah VNet. Itu adalah ruang pribadi Anda di ISO. Anggap saja itu sebagai planet. Di dalam lahan tersebut, Anda membuat subnet. Itu adalah ruang-ruang. Satu untuk server web, satu untuk basis data, satu untuk alat manajemen. Setiap subnet mendapatkan blok alamatnya sendiri yang diambil dari ruang alamat VNet. Anda menambahkan keamanan. Grup keamanan jaringan NSG dipasang berat Anda. Grup ini mengontrol lalu lintas apa yang diizinkan masuk dan keluar. Subnet web Anda mengizinkan lalu lintas dari internet pada port 1.3. Subnet basis data Anda hanya mengizinkan lalu lintas dari subnet web pada port 1.3. Penjaga di setiap pintu tahu persis siapa yang diizinkan. Selanjutnya, Anda mengatur perutik. Mungkin Anda ingin semua lalu lintas internet keluar melewati firewall untuk diperiksa.

Anda membuat tabel rute, menambahkan rute khusus dan menautkannya ke subnet Anda. Sekarang, lalu lintas mengikuti jalur yang Anda rancang bukan jalur default azure. Dan akhirnya, Anda menghubungkan semuanya menjadi satu. Anda menghubungkan vnet Anda dengan vnet lain. Mungkin vnet hub yang menampung firewall dan layanan bersama Anda. Sekarang, aplikasi Anda mencakup banyak jaringan tetapi semuanya bekerja sebagai satu sistem yang terhubung. Ini adalah momen pencerahan. Tidak ada bagian ini yang berkerja serta desolasi. Vnet tanpa subnet hanyalah ruang kosong. Subnet tanpa NSG akan terbuka lebar. Perhutaan tanpa desain yang jelas akan mengirim lalu lintas ke tempat yang satu. Peering tanpa perencanaan akan menciptakan konflik alamat. Mereka ada satu sistem. Setiap bagian bergantung pada bagian lain. Izinkan saya memberi Anda contoh konkur. Bayangkan sebuah aplikasi web. Server web Anda berada di subnet publik dengan NSG yang mengizinkan lalu lintas HTTPS dari internet.

Server aplikasi Anda berada di subnet privat yang hanya menerima lalu lintas dari subnet web. Database Anda berada di subnet privat lain yang hanya menerima lalu lintas dari subnet aplikasi. Tabel rute memaksa semua lalu lintas keluar melalui firewall di hub vnet untuk pencatatan dan inspeksi. Dan semuanya dipering dengan jaringan perusahaan Anda sehingga tim internal dapat mengelolanya. Itulah nilai sebenarnya bukan sekadar satu fitur saja. Ini tentang bagaimana semuanya bekerja bersama. 20 tahun lalu Anda harus membeli server terpisah, mengatur ruter fisik, dan mengelola firewall per perangkat. Semuanya manual, lambat, dan mahal. Azure memberikan semua ini sebagai layanan. Anda mendefinisikannya dengan beberapa klik atau script dan semuanya langsung berfungsi. Apa artinya ini bagi Anda? Setelah Anda melihat bagaimana bagian-bagian ini menyatu, jaringan Azure menjadi dapat diprediksi. Anda tidak sedang menambah.

Anda sedang merancang. Dan saat ada masalah, Anda tahu persis kemana harus melihat karena Anda memahami sistemnya. Jadi inilah yang ingin saya bagikan dari episode ini. Pertama, langkah paling penting yang bisa Anda amat. Buat VNet dengan ruang alamat yang terencana dengan baik sebelum menyebarkan apapun. Keputusan tunggal itu mengelaruhi segalanya di tab selanjutnya. Kedua, gunakan subnet untuk memisahkan tingkatan aplikasi Anda. Server web, server aplikasi, basis data, berikan masing-masing ruangnya sendiri. Dan ketiga, mulailah dengan SG. Itu gratis. NSG sangat kuat dan secara dramatis meningkatkan keamanan Anda sejak hari pertama. VNet Anda adalah fondasi dari semua yang Anda bangun di Azure. Buatlah dengan benar dan segalanya akan menjadi lebih mudah. Jika salah, Anda akan menghabiskan waktu terus-menerus bergelut dengan jaringan. Perlanggananlah di platform podcast favorit Anda dan bagikan ini kepada seseorang yang memulai perjalanan Azure Mereng.

Tinggalkan komentar jika Anda pahami. Sampai jumpa di episode berikutnya.