Panduan ini memperkenalkan praktik terbaik dan arsitektur perusahaan pada umumnya untuk rancangan dari virtual private cloud (VPC) dengan Google Cloud. Panduan ini ditujukan untuk arsitek jaringan dan arsitek sistem cloud yang sudah memahami konsep jaringan Google Cloud.
Prinsip umum dan langkah pertama
Identifikasi pengambil keputusan, linimasa, dan persiapan.
Pertimbangkan desain jaringan VPC dari awal
Jangan berbelit-belit.
Gunakan konvensi penamaan yang jelas.
Mengidentifikasi pengambil keputusan, jadwal, dan persiapan
Sebagai langkah pertama dalam desain jaringan VPC Anda, identifikasi pembuat keputusan, linimasa, dan persiapan yang diperlukan untuk memastikan bahwa Anda dapat memenuhi persyaratan pemangku kepentingan.
Pemangku kepentingan dapat mencakup pemilik aplikasi, arsitek keamanan, arsitek solusi, dan manajer operasi. Pemangku kepentingan itu sendiri dapat berubah, bergantung pada apakah Anda merencanakan jaringan VPC untuk sebuah project, lini bisnis, atau seluruh organisasi.
Bagian dari pra-pekerjaan adalah mengajak tim memahami konsep dan terminologi seputar desain jaringan VPC. Dokumen yang berguna meliputi:
- Dokumentasi Resource Manager
- Dokumentasi Cloud Identity and Access Management
- Dokumentasi Virtual Private Cloud
Pertimbangkan desain jaringan VPC dari awal
Jadikan desain jaringan VPC sebagai bagian awal proses mendesain penyiapan organisasi Anda di Google Cloud. Hal ini dapat mengganggu organisasi Anda jika nantinya Anda perlu mengubah hal-hal mendasar seperti bagaimana jaringan Anda tersegmentasi atau lokasi beban kerja Anda.
Konfigurasi jaringan VPC yang berbeda dapat memiliki implikasi yang signifikan untuk pemilihan rute, skala, dan keamanan. Perencanaan matang dan pemahaman mendalam tentang pertimbangan khusus Anda membantu Anda menciptakan fondasi arsitektur yang kuat untuk beban kerja tambahan.
Jangan berbelit-belit.
Menjaga agar desain topologi jaringan VPC Anda tetap sederhana adalah cara terbaik untuk memastikan arsitektur yang dapat dikelola, andal, dan dipahami dengan baik.
Gunakan konvensi penamaan yang jelas
Buat konvensi penamaan Anda sederhana, intuitif, dan konsisten. Hal ini memastikan bahwa administrator dan pengguna akhir memahami tujuan setiap resource, lokasi resource, dan cara membedakannya dari resource lain.
Singkatan yang umum diterima untuk kata-kata panjang akan membantu menjadi singkat. Menggunakan terminologi yang sudah dikenal jika memungkinkan akan membantu keterbacaan.
Pertimbangkan komponen yang diilustrasikan dalam contoh berikut saat menetapkan konvensi penamaan Anda:
- Nama perusahaan: Perusahaan Acme:
acmeco - Unit bisnis: Sumber Daya Manusia:
hr - Kode aplikasi: Sistem kompensasi:
comp - Kode wilayah: northamerica-northeast1:
na-ne1, europe-west1:eu-we1 - Kode lingkungan:
dev,test,uat,stage,prod
Dalam contoh ini, lingkungan pengembangan untuk sistem kompensasi departemen resource manusia diberi nama acmeco-hr-comp-eu-we1-dev.
Untuk resource jaringan umum lainnya, pertimbangkan pola seperti ini:
Sintaksis Jaringan VPC
:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
Contoh:acmeco-hr-dev-vpc-1Sintaksis Subnet
:{company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
contoh:acmeco-hr-na-ne1-dev-vpc-1-subnet-1
catatan: Jika subnet hanya berisi resource di satu zona, Anda dapat menggunakan "label-zona", bukan "label-region".Aturan firewall
sintaksis:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
contoh:acmeco-hr-internet-internal-tcp-80-allow-ruleSintaksis rute IP
:{priority}-{VPC-label}-{tag}-{next hop}
contoh:1000-acmeco-hr-dev-vpc-1-int-gw
Alamat dan subnet
Gunakan subnet mode kustom di jaringan VPC perusahaan Anda.
Kelompokkan aplikasi ke dalam lebih sedikit subnet dengan rentang alamat yang lebih besar.
Menggunakan jaringan VPC mode kustom
Saat Anda memulai proyek pertama Anda, Anda memulai dengan jaringan
default, yang mana adalah mode otomatis
VPC network yang diberi namadefault. Jaringan mode
otomatis akan otomatis membuat subnet dan rute
subnet terkait yang rentang IP utamanya adalah /20
CIDR di setiap region Google Cloud menggunakan kumpulan RFC yang dapat diprediksi Rentang alamat
1918. Jaringan default juga secara otomatis menyertakan beberapa aturan firewall yang telah terisi otomatis.
Meskipun jaringan mode otomatis dapat berguna untuk eksplorasi awal, jaringan VPC mode kustom lebih cocok untuk sebagian besar lingkungan produksi.
Sebaiknya perusahaan menggunakan jaringan VPC dalam mode kustom sejak awal karena alasan berikut:
- Jaringan VPC mode kustom terintegrasi lebih baik ke dalam skema pengelolaan alamat IP yang ada. Karena semua jaringan mode otomatis menggunakan kumpulan rentang IP internal yang sama, rentang IP mode otomatis dapat tumpang tindih saat terhubung dengan jaringan perusahaan lokal Anda.
- Anda tidak dapat menghubungkan dua jaringan VPC mode otomatis bersama-sama menggunakan Peering Jaringan VPC karena subnetnya menggunakan rentang IP primer yang identik.
- Semua subnet mode otomatis memiliki nama yang sama dengan jaringan. Anda dapat memilih nama yang unik dan deskriptif untuk subnet mode kustom, sehingga jaringan VPC Anda lebih mudah dipahami dan dipelihara.
- Saat region Google Cloud baru diperkenalkan, jaringan VPC mode otomatis akan otomatis mendapatkan subnet baru di region tersebut. Jaringan VPC mode kustom hanya mendapatkan subnet baru jika Anda menentukannya. Hal ini dapat menjadi penting bagi kedaulatan dan alasan pengelolaan alamat IP.
Jika tidak memiliki resource, Anda dapat
menghapus jaringan
default. Anda tidak dapat menghapus jaringan VPC sebelum Anda menghapus semua resource, termasuk instance Virtual Machine (VM), yang bergantung padanya.
Untuk mengetahui detail lebih lanjut tentang perbedaan antara jaringan VPC mode otomatis dan mode kustom, lihat Ringkasan jaringan VPC.
Kelompokkan aplikasi ke dalam lebih sedikit subnet dengan rentang alamat yang lebih besar
Secara konvensional, beberapa jaringan perusahaan dipisahkan menjadi banyak rentang alamat kecil karena berbagai alasan. Misalnya, hal ini mungkin telah dilakukan untuk mengidentifikasi atau mengisolasi aplikasi, atau mempertahankan domain siaran yang kecil.
Namun, sebaiknya kelompokkan aplikasi dengan jenis yang sama ke dalam subnet yang lebih sedikit dan lebih mudah dikelola dengan rentang alamat yang lebih besar di region tempat Anda ingin beroperasi.
Tidak seperti lingkungan jaringan lain yang menggunakan subnet mask, Google Cloud menggunakan pendekatan software-defined networking (SDN) untuk menyediakan keterjangkauan mesh penuh di antara semua VM di jaringan VPC global. Jumlah subnet tidak memengaruhi perilaku perutean.
Anda dapat menggunakan akun layanan atau tag jaringan untuk menerapkan kebijakan perutean atau aturan firewall tertentu. Identitas di Google Cloud tidak hanya didasarkan pada alamat IP subnet.
Beberapa fitur VPC—termasuk Cloud NAT, Akses Google Pribadi, VPC Flow Logs, dan rentang IP aliasdikonfigurasi per subnet. Jika Anda memerlukan kontrol yang lebih terperinci atas fitur-fitur ini, gunakan subnet tambahan.
Jaringan VPC tunggal dan VPC Bersama
Mulai dengan satu jaringan VPC untuk mendapatkan resource yang memiliki persyaratan umum.
Gunakan VPC Bersama untuk administrasi beberapa grup kerja.
Memberikan peran pengguna jaringan di tingkat subnet.
Gunakan satu project host jika resource memerlukan beberapa antarmuka jaringan.
Gunakan beberapa project host jika persyaratan resource melebihi kuota satu project.
Gunakan beberapa project host jika Anda memerlukan kebijakan administrasi terpisah untuk setiap VPC.
Memulai dengan satu jaringan VPC untuk resource yang memiliki persyaratan umum
Untuk banyak kasus penggunaan sederhana, satu jaringan VPC memberikan fitur yang Anda butuhkan, sekaligus menjadi lebih mudah dibuat, dikelola, dan dipahami daripada alternatif yang lebih kompleks. Dengan mengelompokkan resource berdasarkan persyaratan dan karakteristik umum ke dalam satu jaringan VPC, Anda mulai menetapkan batas jaringan VPC sebagai perimeter untuk potensi masalah.
Untuk contoh konfigurasi ini, lihat arsitektur referensi satu project, jaringan VPC tunggal.
Faktor-faktor yang mungkin menyebabkan Anda membuat jaringan VPC tambahan mencakup skala, keamanan jaringan, pertimbangan keuangan, persyaratan operasional, dan Pengelolaan Akses dan Identitas (IAM).
Menggunakan VPC Bersama untuk administrasi beberapa grup kerja
Untuk organisasi yang memiliki beberapa tim, Shared VPC menyediakan alat yang efektif untuk memperluas kesederhanaan arsitektural jaringan VPC di beberapa kelompok kerja. Pendekatan yang paling sederhana adalah men-deploy satu project host VPC Bersama dengan satu jaringan VPC Bersama, lalu melampirkan project layanan tim ke jaringan project host.
Dalam konfigurasi ini, kebijakan dan kontrol jaringan untuk semua resource jaringan dipusatkan dan lebih mudah dikelola. Departemen project layanan dapat mengonfigurasi dan mengelola resource non-jaringan, sehingga memungkinkan pemisahan tanggung jawab yang jelas untuk berbagai tim dalam organisasi.
Resource dalam project tersebut dapat berkomunikasi satu sama lain secara lebih aman dan efisien melintasi batas project menggunakan alamat IP internal. Anda dapat mengelola resource jaringan bersama—seperti subnet, rute, dan firewall dari project host pusat, sehingga Anda dapat menerapkan kebijakan jaringan yang konsisten di seluruh project.
Untuk contoh konfigurasi ini, lihat arsitektur referensi Project host tunggal, beberapa project layanan, satu VPC Bersama.
Memberikan peran pengguna jaringan di tingkat subnet
Administrator VPC Bersama terpusat dapat memberikan peran pengguna jaringan (networkUser) kepada anggota IAM, baik di tingkat subnet, untuk otorisasi project layanan yang mendetail, atau untuk semua subnet
di level project host.
Dengan mengikuti prinsip hak istimewa terendah, sebaiknya berikan peran pengguna jaringan di tingkat subnet kepada pengguna, akun layanan, atau grup terkait.
Karena subnet bersifat regional, kontrol terperinci ini memungkinkan Anda menentukan region mana yang dapat digunakan setiap project layanan untuk men-deploy resource.
Dengan arsitektur VPC Bersama, Anda juga memiliki fleksibilitas untuk men-deploy beberapa project host VPC Bersama dalam organisasi Anda. Setiap project host VPC Bersama kemudian dapat mengakomodasi satu atau beberapa jaringan VPC Bersama. Dalam konfigurasi ini, lingkungan yang berbeda dapat dengan mudah menerapkan masalah kebijakan yang berbeda.
Untuk mengetahui informasi lebih lanjut, lihat Peran IAM untuk jaringan.
Menggunakan satu project host jika resource memerlukan beberapa antarmuka jaringan
Jika Anda memiliki project layanan yang perlu men-deploy resource ke beberapa jaringan VPC yang terisolasi, misalnya, instance VM dengan beberapa antarmuka jaringan, project host Anda harus berisi semua jaringan VPC yang menyediakan layanan tersebut singkat ini. Hal ini karena project layanan diizinkan untuk terhubung hanya ke satu project host.
Gunakan beberapa project host jika persyaratan resource melebihi kuota satu project
Jika persyaratan resource gabungan dari semua jaringan VPC tidak dapat terpenuhi dalam kuota project, gunakan arsitektur dengan beberapa project host dengan satu jaringan VPC Bersama per project host, bukan satu project host dengan beberapa jaringan VPC Bersama. Penting untuk mengevaluasi persyaratan skala Anda, karena penggunaan satu project host memerlukan beberapa jaringan VPC dalam project host, dan kuota diberlakukan pada level project.
Untuk contoh konfigurasi ini, lihat Beberapa project host, beberapa project layanan, beberapa arsitektur referensi VPC Bersama.
Gunakan beberapa project host jika Anda memerlukan kebijakan administrasi terpisah untuk setiap jaringan VPC
Karena setiap project memiliki kuotanya sendiri, gunakan project host VPC Bersama yang terpisah untuk setiap jaringan VPC guna menskalakan resource gabungan. Hal ini memungkinkan setiap jaringan VPC memiliki izin IAM terpisah untuk pengelolaan keamanan dan jaringan, karena izin IAM juga diimplementasikan di level project. Misalnya, jika Anda menerapkan dua jaringan VPC (jaringan VPC A dan jaringan VPC B) ke dalam project host yang sama, administrator jaringan (networkAdmin ) berlaku untuk kedua jaringan VPC.
Menentukan apakah akan membuat beberapa jaringan VPC atau tidak
Buat satu jaringan VPC per project untuk memetakan kuota jaringan VPC ke project.
Buat jaringan VPC untuk setiap tim otonom, dengan layanan bersama dalam jaringan VPC yang sama.
Buat jaringan VPC dalam berbagai project untuk kontrol IAM independen.
Isolasi data sensitif di jaringan VPC-nya sendiri.
Buat satu jaringan VPC per project untuk memetakan kuota resource VPC ke project
Kuota adalah batasan yang diterapkan pada level project atau jaringan. Semua resource memiliki kuota default awal yang dimaksudkan untuk melindungi Anda dari penggunaan resource yang tidak terduga. Namun, banyak faktor yang dapat menyebabkan Anda menginginkan lebih banyak kuota. Untuk sebagian besar resource, Anda dapat meminta kuota tambahan.
Sebaiknya buat satu jaringan VPC per project jika Anda ingin berkembang melebihi kuota resource VPC default. Hal ini mempermudah pemetaan peningkatan kuota level project untuk setiap jaringan VPC, bukan ke kombinasi jaringan VPC dalam project yang sama.
Batas dirancang untuk melindungi resource sistem secara agregat. Umumnya, batasan tidak dapat dinaikkan dengan mudah, meskipun tim dukungan dan penjualan Google Cloud dapat bekerja sama dengan Anda untuk meningkatkan beberapa batasan.
Lihat Kuota dan batas resource VPC untuk mengetahui nilai saat ini.
Dukungan Google dapat meningkatkan beberapa batas penskalaan, tetapi terkadang Anda perlu mem-build beberapa jaringan VPC untuk memenuhi persyaratan penskalaan Anda. Jika jaringan VPC Anda memiliki persyaratan untuk melakukan penskalaan di luar batas, diskusikan kasus Anda dengan tim penjualan dan dukungan Google Cloud tentang pendekatan terbaik untuk persyaratan Anda.
Buat jaringan VPC untuk setiap tim otonom, dengan layanan bersama dalam jaringan VPC umum
Beberapa deployment perusahaan besar melibatkan tim otonom yang masing-masing memerlukan kontrol penuh atas jaringan VPC masing-masing. Anda dapat memenuhi persyaratan ini dengan membuat jaringan VPC untuk setiap unit bisnis, dengan layanan bersama dalam jaringan VPC yang sama (misalnya, alat analisis, pipeline CI/CD dan mesin build, DNS/Direktori) layanan Anda). Untuk mengetahui informasi selengkapnya tentang cara membuat jaringan VPC umum untuk layanan bersama, lihat bagian layanan bersama.
Buat jaringan VPC dalam berbagai project untuk kontrol IAM independen
Jaringan VPC adalah resource level project dengan kontrol pengelolaan akses dan identitas (IAM) level project yang mendetail, termasuk peran berikut:
networkAdminsecurityAdminnetworkUsernetworkViewer
Secara default, kontrol IAM di-deploy di level project dan setiap peran IAM berlaku untuk semua jaringan VPC dalam project.
Jika Anda memerlukan kontrol IAM independen per jaringan VPC, buat jaringan VPC di berbagai project.
Jika Anda memerlukan peran IAM yang dicakupkan ke resource Compute Engine tertentu seperti instance VM, disk, dan image, gunakan kebijakan IAM untuk resource Compute Engine.
Mengisolasi data sensitif di jaringan VPC-nya sendiri
Bagi perusahaan yang menangani inisiatif kepatuhan, data sensitif, atau data yang sangat diatur yang terikat oleh standar kepatuhan seperti HIPAA atau PCI-DSS, langkah-langkah keamanan lebih lanjut sering kali dapat diterima. Salah satu metode yang dapat meningkatkan keamanan dan mempermudah untuk membuktikan kepatuhan adalah dengan mengisolasi setiap lingkungan ini ke dalam jaringan VPC-nya sendiri.
Menghubungkan beberapa jaringan VPC
Pilih metode koneksi VPC yang memenuhi kebutuhan biaya, performa, dan keamanan Anda.
Gunakan Peering Jaringan VPC jika Anda tidak akan melebihi batas resource.
Gunakan perutean eksternal jika Anda tidak memerlukan komunikasi alamat IP pribadi.
Gunakan Cloud VPN untuk menghubungkan jaringan VPC yang akan melebihi batas grup peering gabungan.
Gunakan Cloud Interconnect untuk mengontrol traffic antarjaringan VPC melalui perangkat lokal.
Gunakan peralatan virtual multi-NIC untuk mengontrol traffic antarjaringan VPC melalui perangkat cloud.
Buat VPC layanan bersama jika beberapa jaringan VPC memerlukan akses ke resource yang sama, tetapi tidak satu sama lain.
Pilih metode koneksi VPC yang sesuai dengan kebutuhan biaya, performa, dan keamanan Anda
Langkah berikutnya setelah memutuskan untuk menerapkan beberapa jaringan VPC adalah menghubungkan jaringan VPC tersebut. Jaringan VPC adalah ruang tenant yang terisolasi dalam SDN Andromeda Google, tetapi ada beberapa cara untuk memungkinkan komunikasi di antara keduanya. Bagian selanjutnya memberikan praktik terbaik untuk memilih metode koneksi VPC.
Kelebihan dan kekurangan masing-masing dirangkum dalam tabel berikut, dan bagian selanjutnya memberikan praktik terbaik untuk memilih metode koneksi VPC.
| Kelebihan | Kekurangan | |
|---|---|---|
| Peering Jaringan VPC |
|
|
| Perutean eksternal (IP publik atau gateway NAT) |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect - Khusus atau Partner |
|
|
| Antarmuka multi-jaringan (Multi-NIC) |
|
|
Gunakan Peering Jaringan VPC jika Anda tidak akan melebihi batas resource
Sebaiknya gunakan Peering Jaringan VPC saat Anda perlu menghubungkan jaringan VPC dan tidak dapat menggunakan satu VPC Bersama, selama jumlah total resource yang diperlukan untuk semua peer yang terhubung langsung tidak melebihi batas pada instance VM, jumlah koneksi peering, dan aturan penerusan internal.
Dengan Peering Jaringan VPC, dua jaringan VPC dapat saling terhubung secara internal melalui SDN Google, terlepas dari apakah keduanya berasal dari project yang sama maupun organisasi yang sama. Peering Jaringan VPC menggabungkan bidang kontrol dan propagasi alur di antara setiap peer, sehingga memungkinkan karakteristik penerusan yang sama seolah-olah semua VM berada di jaringan VPC yang sama. Saat jaringan VPC di-peering, semua subnet, rentang IP alias, dan aturan penerusan internal dapat diakses, dan setiap jaringan VPC mempertahankan firewall terdistribusinya sendiri. Peering Jaringan VPC tidak transitif.
Peering Jaringan VPC adalah metode pilihan untuk menghubungkan jaringan VPC karena alasan berikut:
- Tidak ada bottleneck gateway Traffic meneruskan ke berbagai peer seolah-olah VM berada di jaringan VPC yang sama.
- Penagihan—Tidak ada biaya tambahan; Anda ditagih seolah-olah VM berada di jaringan VPC yang sama.
Gunakan perutean eksternal jika Anda tidak memerlukan komunikasi alamat IP pribadi
Jika tidak memerlukan komunikasi alamat IP pribadi, Anda dapat menggunakan perutean eksternal dengan alamat IP eksternal atau gateway NAT.
Ketika jaringan VPC di-deploy, rute ke gateway internet default Google disediakan dengan prioritas 1000. Jika rute ini ada, dan VM diberi alamat IP eksternal, VM dapat mengirim traffic keluar (traffic keluar) melalui gateway internet Google. Anda juga dapat men-deploy layanan di balik salah satu dari banyak penawaran load balancing publik Google, yang memungkinkan layanan dijangkau secara eksternal.
VM yang dialamatkan secara eksternal berkomunikasi satu sama lain secara pribadi melalui backbone Google, terlepas dari region dan Network Service Tiers. Gunakan aturan firewall Google Cloud untuk mengontrol traffic masuk eksternal (akses masuk) ke VM Anda.
Perutean eksternal adalah opsi yang bagus untuk tujuan penskalaan, tetapi penting untuk memahami bagaimana perutean publik memengaruhi biaya. Untuk mengetahui detailnya, lihat Dokumentasi harga jaringan.
Menggunakan Cloud VPN untuk menghubungkan jaringan VPC yang akan melebihi batas grup peering gabungan
VPN dengan ketersediaan tinggi (HA) menyediakan layanan terkelola untuk menghubungkan jaringan VPC dengan membuat tunnel IPsec di antara kumpulan endpoint. Jika mengonfigurasi Cloud Router dengan mode iklan kustom, Anda dapat mengaktifkan perutean transitif di seluruh jaringan VPC serta topologi hub-and-spoke seperti yang akan dijelaskan nanti dalam dokumen ini. Dengan menggunakan Network Connectivity Center Anda dapat menggunakan tunnel VPN dengan ketersediaan tinggi (HA) sebagai jaringan transportasi umum antarjaringan lokal, seperti yang dijelaskan dalam dokumentasi Cloud VPN.
Cloud VPN tidak mendukung MTU besar. Untuk mengetahui detailnya, lihat pertimbangan MTU.
Menggunakan Cloud Interconnect untuk mengontrol traffic antarjaringan VPC melalui perangkat lokal
Cloud Interconnect memperluas jaringan lokal Anda ke jaringan Google melalui koneksi latensi rendah yang sangat tersedia. Anda dapat menggunakan Dedicated Interconnect untuk terhubung langsung ke Google atau menggunakan Partner Interconnect untuk terhubung ke Google melalui penyedia layanan yang didukung.
Dedicated Interconnect menyediakan layanan L2 berkecepatan tinggi antara Google dan penyedia kolokasi atau lokasi lokal. Dengan begitu, Anda dapat menggunakan peralatan perutean lokal untuk merutekan antarjaringan VPC dan menggunakan layanan keamanan dan inspeksi lokal yang sudah ada untuk memfilter semua traffic antarjaringan VPC. Semua traffic di antara dua jaringan VPC memiliki latensi tambahan karena perjalanan dua arah tambahan melalui sistem lokal.
Partner Interconnect memberikan kemampuan yang serupa, serta kemampuan untuk melakukan peering langsung dengan penyedia di L3 dan memiliki rute penyedia antarjaringan VPC. Hal ini memungkinkan akses ke alamat IP internal di seluruh jaringan lokal Anda dan jaringan VPC Google Cloud tanpa perangkat NAT atau tunnel VPN.
Karena banyak perangkat keamanan perusahaan dapat digunakan di Google Cloud dengan menggunakan VM dengan beberapa antarmuka jaringan, penggunaan Cloud Interconnect untuk merutekan traffic antarjaringan VPC tidak diperlukan kecuali dalam beberapa kasus di mana semua traffic harus mengalir melalui perangkat lokal karena kebijakan perusahaan.
Menggunakan peralatan virtual untuk mengontrol traffic antarjaringan VPC melalui perangkat cloud
Beberapa VM antarmuka jaringan bersifat umum untuk jaringan VPC yang memerlukan keamanan atau layanan tambahan di antara keduanya, karena beberapa VM antarmuka jaringan memungkinkan instance VM untuk menjembatani komunikasi antarjaringan VPC.
VM hanya diizinkan memiliki satu antarmuka untuk setiap jaringan VPC yang terhubung dengannya. Untuk men-deploy VM ke beberapa jaringan VPC, Anda harus memiliki izin IAM yang sesuai untuk setiap jaringan VPC yang terhubung dengan VM.
Ingatlah karakteristik berikut saat men-deploy VM multi-NIC:
- VM multi-NIC dapat memiliki maksimum 8 antarmuka.
- Rentang IP subnet antarmuka tidak boleh tumpang-tindih.
Membuat VPC layanan bersama jika beberapa jaringan VPC memerlukan akses ke resource umum, tetapi tidak satu sama lain
Jaringan VPC menyediakan mesh penuh keterjangkauan global. Oleh karena itu, layanan bersama dan pipeline continuous integration yang berada di jaringan VPC yang sama tidak memerlukan pertimbangan khusus dalam hal konektivitas. Keduanya dapat dijangkau secara inheren. VPC Bersama memperluas konsep ini, yang memungkinkan layanan bersama berada dalam project terpisah sekaligus memberikan konektivitas ke layanan atau konsumen lain.
Pendekatan untuk layanan bersama mencakup Private Service Connect, Peering Jaringan VPC, dan Cloud VPN. Gunakan Private Service Connect kecuali jika Anda tidak dapat melakukannya karena alasan tertentu. Anda dapat menggunakan Peering Jaringan VPC untuk terhubung ke jaringan VPC layanan bersama jika Anda tidak akan melebihi batas resource gabungan dan tidak ingin menyiapkan endpoint untuk setiap layanan. Anda juga dapat menggunakan Cloud VPN untuk menghubungkan jaringan VPC layanan bersama yang akan melebihi batas grup peering gabungan.
Private Service Connect memungkinkan Anda membuat layanan yang dihosting di satu jaringan tersedia untuk VM di jaringan lain dengan membuat endpoint khusus di jaringan konsumen. Konfigurasi Private Service Connect kemudian saluran traffic untuk layanan tersebut di antara dua jaringan.
Konsumen dapat menggunakan alamat IP internalnya sendiri untuk mengakses layanan tanpa keluar dari jaringan VPC atau menggunakan alamat IP eksternal. Traffic tetap berada sepenuhnya di dalam Google Cloud. Private Service Connect memberikan akses berorientasi layanan antara konsumen dan produsen dengan kontrol terperinci atas cara layanan diakses.
Pada model Peering Jaringan VPC, setiap jaringan VPC membuat hubungan peering dengan jaringan VPC layanan bersama yang umum untuk memberikan keterjangkauan. Peering Jaringan VPC memperkenalkan pertimbangan penskalaan karena batas penskalaan berlaku untuk penggunaan resource gabungan dari semua peer.
Peering Jaringan VPC juga dapat digunakan bersama dengan akses layanan pribadi dan Service Networking API. Dengan Service Networking API, Anda dapat mengizinkan pelanggan di organisasi yang sama atau organisasi lain menggunakan layanan yang Anda berikan, tetapi mengizinkan mereka memilih rentang alamat IP yang terhubung menggunakan Peering Jaringan VPC.
Cloud VPN adalah alternatif lain. Karena Cloud VPN menetapkan keterjangkauan melalui tunnel IPsec terkelola, Cloud VPN tidak memiliki batas agregat Peering Jaringan VPC. Cloud VPN menggunakan Gateway VPN untuk konektivitas dan tidak mempertimbangkan penggunaan resource agregat dari peer IPsec. Kekurangan dari Cloud VPN meliputi peningkatan biaya (tunnel VPN dan traffic keluar traffic), overhead pengelolaan yang diperlukan untuk mengelola tunnel, dan overhead performa IPsec.
Desain hybrid: menghubungkan lingkungan lokal
Gunakan pemilihan rute dinamis jika memungkinkan.
Gunakan jaringan VPC konektivitas untuk menskalakan arsitektur hub-and-spoke dengan beberapa jaringan VPC.
Setelah mengidentifikasi kebutuhan konektivitas hybrid dan telah memilih solusi yang memenuhi persyaratan bandwidth, performa, dan keamanan Anda, pertimbangkan cara mengintegrasikannya ke dalam desain VPC Anda.
Dengan menggunakan VPC Bersama, kebutuhan setiap project untuk mereplikasi solusi yang sama akan berkurang. Misalnya, saat Anda mengintegrasikan solusi Cloud Interconnect ke dalam VPC Bersama, semua VM terlepas dari project layanan atau region—dapat mengakses koneksi Cloud Interconnect.
Pemilihan rute dinamis
Perutean dinamis tersedia pada semua solusi campuran, termasuk VPN dengan ketersediaan tinggi (HA), VPN Klasik, Dedicated Interconnect, dan Partner Interconnect. Pemilihan rute dinamis menggunakan Cloud Router Google sebagai speaker Border Gateway Protocol (BGP) untuk menyediakan pemilihan rute BGP Eksternal (eBGP) yang dinamis.
Cloud Router tidak berada di bidang data; dan hanya membuat rute di SDN.
Perutean dinamis tidak menggunakan tag, dan Cloud Router tidak pernah mengiklankan ulang awalan yang dipelajari.
Anda dapat mengaktifkan salah satu dari dua mode Cloud Router, regional atau global, di setiap jaringan VPC. Jika Anda memilih perutean regional, Cloud Router hanya memberitahukan subnet yang berada bersama di region tempat Cloud Router di-deploy. Di sisi lain, perutean global memberitahukan semua subnet jaringan VPC tertentu, terlepas dari region-nya, tetapi menghukum rute yang diiklankan dan dipelajari di luar region. Hal ini mempertahankan simetri dalam region dengan selalu memilih interkoneksi lokal, dan dihitung dengan menambahkan metrik penalti (MED) yang sama dengan 200 + TTL dalam milidetik antar-region.
Pemilihan rute statis
Pemilihan rute statis hanya tersedia di VPN Klasik. Perutean statis menawarkan kemampuan untuk mengatur rute next-hop yang mengarah ke tunnel Cloud VPN.
Secara default, rute statis berlaku untuk semua VM di jaringan, terlepas dari region. Perutean statis juga memungkinkan administrator jaringan menetapkan VM yang menjadi rute secara selektif menggunakan tag instance, yang dapat ditetapkan saat Anda membuat rute.
Rute statis berlaku secara global dalam jaringan VPC, dengan prioritas rute yang sama satu sama lain. Oleh karena itu, jika Anda memiliki beberapa tunnel di beberapa region ke awalan yang sama dengan prioritas yang sama, VM akan menggunakan ECMP berbasis hash 5 tuple di semua tunnel. Untuk mengoptimalkan penyiapan ini, Anda dapat membuat rute dalam region yang diinginkan dengan mereferensikan tag instance untuk setiap region dan membuat rute pilihan yang sesuai.
Jika tidak ingin traffic keluar (egress) melewati gateway internet default Google, Anda dapat menetapkan rute statis default yang diinginkan untuk mengirim semua traffic kembali secara lokal melalui tunnel.
Menggunakan jaringan VPC konektivitas untuk menskalakan arsitektur hub-and-spoke dengan beberapa jaringan VPC
Jika Anda perlu menskalakan arsitektur hub-and-spoke dengan beberapa jaringan VPC, konfigurasikan konektivitas hybrid terpusat dalam jaringan VPC khusus dan lakukan peer ke project lain menggunakan rute khusus yang diberitahukan. Dengan begitu, rute yang dipelajari secara statis atau dinamis dapat diekspor ke jaringan VPC peer, untuk memberikan konfigurasi dan penskalaan terpusat pada desain jaringan VPC Anda.
Hal ini berbeda dengan deployment konektivitas hybrid konvensional, yang menggunakan tunnel VPN atau lampiran VLAN di setiap jaringan VPC.
Diagram berikut mengilustrasikan konektivitas hybrid terpusat dengan rute kustom Peering Jaringan VPC:
Keamanan jaringan
Identifikasi tujuan keamanan yang jelas.
Batasi akses eksternal.
Tentukan batas layanan untuk data sensitif.
Kelola traffic dengan aturan firewall berbasis Google Cloud jika memungkinkan.
Gunakan kumpulan aturan firewall yang lebih sedikit dan lebih luas jika memungkinkan.
Pisahkan VM menggunakan akun layanan jika memungkinkan.
Gunakan otomatisasi untuk memantau kebijakan keamanan saat menggunakan tag.
Gunakan alat tambahan untuk membantu mengamankan dan melindungi aplikasi Anda.
Google Cloud menyediakan fitur keamanan yang tangguh di seluruh infrastruktur dan layanannya, mulai dari keamanan fisik pusat data dan hardware keamanan khusus hingga tim peneliti khusus. Namun, mengamankan resource Google Cloud Anda merupakan tanggung jawab bersama. Anda harus mengambil langkah-langkah yang sesuai untuk membantu memastikan bahwa aplikasi dan data Anda terlindungi.
Mengidentifikasi tujuan keamanan yang jelas
Sebelum mengevaluasi kontrol keamanan berbasis cloud atau kapabilitas cloud, mulailah dengan serangkaian tujuan keamanan yang jelas yang disetujui oleh semua pemangku kepentingan sebagai bagian dasar produk. Tujuan ini harus menekankan pencapaian, dokumentasi, dan iterasi, sehingga dapat dirujuk dan ditingkatkan selama pengembangan.
Batasi akses eksternal
Saat membuat resource Google Cloud yang menggunakan jaringan VPC, pilih jaringan dan subnet tempat resource berada. Resource ini diberi alamat IP internal dari salah satu rentang IP yang terkait dengan subnet. Resource dalam jaringan VPC dapat berkomunikasi satu sama lain melalui alamat IP internal jika aturan firewall mengizinkan.
Batasi akses ke internet hanya untuk resource yang membutuhkannya. Resource yang hanya memiliki alamat IP internal pribadi masih dapat mengakses banyak API dan layanan Google melalui Private Service Connect atau Akses Google Pribadi. Akses pribadi memungkinkan resource untuk berinteraksi dengan layanan utama Google dan Google Cloud selagi tetap terisolasi dari internet publik.
Selain itu, gunakan kebijakan organisasi untuk lebih membatasi resource yang diizinkan menggunakan alamat IP eksternal.
Namun, sebelum memblokir akses internet, pertimbangkan dampaknya terhadap instance VM Anda. Memblokir akses internet dapat mengurangi risiko pemindahan data yang tidak sah, tetapi juga dapat memblokir traffic yang sah, termasuk traffic penting untuk update software serta API dan layanan pihak ketiga. Tanpa akses internet, Anda hanya dapat mengakses instance VM melalui jaringan lokal yang terhubung melalui tunnel Cloud VPN, koneksi Cloud Interconnect, atau Identity-Aware Proxy. Dengan Cloud NAT, mesin virtual dapat memulai koneksi keluar ke internet untuk traffic penting tertentu tanpa mengekspos koneksi masuk publik.
Tentukan perimeter layanan untuk data sensitif
Untuk beban kerja yang melibatkan data sensitif, gunakan Kontrol Layanan VPC untuk mengonfigurasi perimeter layanan di sekitar resource VPC Anda dan layanan yang dikelola Google, serta kontrol pergerakan data di seluruh batas perimeter. Dengan menggunakan Kontrol Layanan VPC, Anda dapat mengelompokkan project dan jaringan lokal Anda ke dalam satu perimeter yang mencegah akses data melalui layanan yang dikelola Google. Perimeter layanan tidak dapat memuat project dari organisasi yang berbeda, tetapi Anda dapat menggunakan jembatan perimeter agar project dan layanan dalam perimeter layanan yang berbeda dapat berkomunikasi.
Mengelola traffic dengan aturan firewall native Google Cloud jika memungkinkan
VPC Google Cloud menyertakan firewall stateful L3/L4 yang skalabel secara horizontal dan diterapkan ke setiap VM secara terdistribusi. Firewall ini dikonfigurasi menggunakan Kebijakan firewall hierarkis, kebijakan firewall jaringan global dan regional, serta aturan firewall VPC. Lihat ringkasan Cloud Firewall untuk mengetahui detailnya.
Google Cloud Marketplace memiliki ekosistem solusi pihak ketiga yang besar, termasuk VM yang melakukan hal berikut: memberikan keamanan lanjutan, seperti perlindungan dari kebocoran informasi, eksploitasi aplikasi, dan eskalasi hak istimewa; mendeteksi ancaman yang diketahui dan tidak diketahui; dan menerapkan pemfilteran URL. Ada juga manfaat operasional jika satu vendor menerapkan kebijakan di seluruh penyedia layanan cloud dan lingkungan lokal.
Traffic biasanya dirutekan ke VM ini dengan menentukan rute, baik dengan prioritas yang sama (untuk mendistribusikan traffic menggunakan hash 5 tuple) atau dengan prioritas yang berbeda (untuk membuat jalur redundan), seperti yang ditunjukkan dalam beberapa jalur ke Dev-subnet di diagram berikut.
Sebagian besar solusi memerlukan beberapa VM antarmuka jaringan. Karena VM tidak dapat memiliki lebih dari satu antarmuka per jaringan VPC, saat Anda membuat beberapa VM antarmuka jaringan, setiap antarmuka harus terhubung ke jaringan VPC yang terpisah.
Skala juga menjadi pertimbangan penting saat men-deploy solusi pihak ketiga ke dalam jaringan VPC Anda karena alasan berikut:
- Batas: Sebagian besar peralatan berbasis VM harus dimasukkan ke dalam jalur data. Hal ini memerlukan beberapa VM antarmuka jaringan yang menjembatani beberapa jaringan VPC yang berada dalam project yang sama. Karena kuota resource VPC ditetapkan pada level project, kebutuhan resource gabungan di semua jaringan VPC dapat menjadi terbatas.
- Performa: Memperkenalkan chokepoint berbasis VM tunggal ke dalam atribut skalabilitas horizontal yang sepenuhnya di jaringan VPC bertentangan dengan metodologi desain cloud. Untuk mengurangi hal ini, Anda dapat menempatkan beberapa peralatan virtual jaringan (NVA) ke dalam grup instance terkelola di belakang Load Balancer Jaringan passthrough internal.
Untuk memperhitungkan faktor-faktor ini dalam arsitektur persyaratan berskala tinggi, kirim kontrol keamanan ke endpoint Anda. Mulailah dengan melakukan hardening VM dan menggunakan aturan firewall Google Cloud. Strategi ini juga dapat melibatkan pengenalan agen pemeriksa endpoint berbasis host yang tidak mengubah arsitektur penerusan jaringan VPC Anda melalui beberapa VM antarmuka jaringan.
Untuk contoh tambahan konfigurasi ini, lihat Firewall L7 stateful antararsitektur referensi jaringan VPC.
Gunakan kumpulan aturan firewall yang lebih sedikit dan lebih luas jika memungkinkan.
Hanya sejumlah aturan tertentu yang dapat diprogram di VM apa pun. Namun, Anda dapat menggabungkan banyak aturan menjadi satu definisi aturan yang kompleks. Misalnya, jika semua VM di jaringan VPC harus secara eksplisit mengizinkan 10 port TCP masuk, Anda memiliki dua opsi: menulis 10 aturan terpisah, masing-masing menentukan satu port, atau menentukan satu aturan yang mencakup 10 aturan tersebut porta. Menentukan satu aturan yang menyertakan 10 porta adalah opsi yang lebih efisien.
Buat kumpulan aturan umum yang berlaku untuk seluruh jaringan VPC, lalu gunakan kumpulan aturan yang lebih spesifik untuk pengelompokan VM yang lebih kecil menggunakan target. Dengan kata lain, mulailah dengan menentukan aturan yang luas, lalu tentukan aturan secara lebih sempit sesuai kebutuhan:
- Terapkan aturan firewall yang sama di seluruh VM dalam jaringan VPC.
- Terapkan aturan firewall yang dapat dikelompokkan di beberapa VM, seperti grup instance layanan atau subnet.
- Terapkan aturan firewall ke setiap VM, seperti gateway NAT atau bastion host.
Mengisolasi VM menggunakan akun layanan jika memungkinkan
Banyak organisasi memiliki lingkungan yang memerlukan aturan khusus untuk sebagian VM di jaringan VPC. Ada dua pendekatan umum yang dapat Anda lakukan dalam kasus ini: isolasi subnet dan pemfilteran target.
Isolasi subnet
Dengan isolasi subnet, subnet membentuk batas keamanan tempat aturan firewall Google Cloud diterapkan. Pendekatan ini umum dalam konstruksi jaringan lokal dan dalam kasus saat alamat IP dan penempatan jaringan merupakan bagian dari identitas VM.
Anda dapat mengidentifikasi VM di subnet tertentu dengan menerapkan Tag, tag jaringan, atau akun layanan yang unik ke instance tersebut. Hal ini memungkinkan Anda membuat aturan firewall yang hanya berlaku untuk VM di subnet—aturan yang memiliki Tag, tag jaringan, dan akun layanan terkait. Misalnya, untuk membuat aturan firewall yang mengizinkan semua komunikasi antar-VM dalam subnet yang sama, Anda dapat menggunakan konfigurasi aturan berikut di halaman aturan Firewall:
- Targets: Tag target yang ditentukan
- Tag target: subnet-1
- Filter sumber: Subnet
- Subnets: Pilih subnet berdasarkan nama (contoh: subnet-1).
Pemfilteran target
Dengan pemfilteran target, semua VM berada di subnet yang sama atau merupakan bagian dari kumpulan subnet apa pun. Dengan pendekatan ini, keanggotaan subnet tidak dianggap sebagai bagian dari identitas instance untuk aturan firewall. Sebagai gantinya, Anda dapat menggunakan Tag, tag jaringan, atau akun layanan untuk membatasi akses antar-VM di subnet yang sama. Tag jaringan yang sama diterapkan pada setiap grup VM yang menggunakan aturan firewall yang sama.
Untuk menggambarkan hal ini, pertimbangkan aplikasi tiga tingkat (web, aplikasi, database) yang semua instance-nya di-deploy di subnet yang sama. Tingkat web dapat berkomunikasi dengan pengguna akhir dan tingkat aplikasi, dan tingkat aplikasi dapat berkomunikasi dengan tingkat database. Namun, komunikasi lain antartingkat tidak diizinkan. Instance
yang menjalankan tingkat web memiliki tag jaringan web, instance
yang menjalankan tingkat aplikasi memiliki tag jaringan app, dan instance yang menjalankan
tingkat database memiliki tag jaringan db.
Aturan firewall berikut menerapkan pendekatan ini:
| Aturan 1: Izinkan pengguna akhir → tingkat web | Target . Tag target yang ditentukan Tag target . web Filter sumber . Rentang IP Rentang IP sumber . 0.0.0.0/0 |
| Aturan 2: Izinkan tingkat web → tingkat aplikasi | Target . Tag target yang ditentukan Tag target . aplikasi Anda Filter sumber . Tag sumber Tag sumber . web |
| Aturan 3: Izinkan tingkat aplikasi → tingkat database | Target . Tag target yang ditentukan Tag target . dB Filter sumber . Tag sumber Tag sumber . aplikasi Anda |
Namun, meskipun tag jaringan dapat digunakan untuk pemfilteran target dengan cara ini, sebaiknya gunakan Tag atau akun layanan jika memungkinkan. Tag target tidak dikontrol akses dan dapat diubah oleh seseorang yang memiliki peran instanceAdmin saat VM beroperasi. Tag dan akun layanan dikontrol aksesnya, yang berarti
pengguna tertentu harus diizinkan secara eksplisit untuk menggunakan akun layanan.
Hanya boleh ada satu akun layanan per instance, sedangkan bisa saja ada beberapa tag. Selain itu, akun layanan yang ditetapkan ke VM hanya dapat diubah saat VM dihentikan.
Menggunakan otomatisasi untuk memantau kebijakan keamanan saat menggunakan tag
Jika Anda menggunakan tag jaringan, ingatlah bahwa administrator instance dapat mengubah tag tersebut. Hal ini dapat mengakali kebijakan keamanan. Oleh karena itu, jika Anda menggunakan tag jaringan di lingkungan produksi, gunakan framework otomatisasi untuk membantu mengatasi kurangnya tata kelola IAM pada tag jaringan.
Menggunakan alat tambahan untuk membantu mengamankan dan melindungi aplikasi
Selain aturan firewall, gunakan alat tambahan berikut untuk membantu mengamankan dan melindungi aplikasi Anda:
- Gunakan load balancer HTTP(S) global Google Cloud untuk mendukung ketersediaan tinggi dan normalisasi protokol.
- Integrasikan Google Cloud Armor dengan load balancer HTTP(S) untuk memberikan perlindungan DDoS dan kemampuan memblokir atau mengizinkan alamat IP di edge jaringan.
- Kontrol akses ke aplikasi menggunakan IAP (IAP) untuk memverifikasi identitas pengguna dan konteks permintaan untuk menentukan apakah pengguna harus diberi akses.
- Sediakan satu antarmuka untuk insight keamanan, deteksi anomali, dan deteksi kerentanan dengan Security Command Center.
Layanan jaringan: NAT dan DNS
Gunakan alamat IP eksternal tetap dengan Cloud NAT.
Gunakan zona DNS Pribadi untuk resolusi nama.
Menggunakan alamat IP eksternal tetap dengan Cloud NAT
Jika Anda memerlukan alamat IP eksternal tetap dari berbagai VM, gunakan Cloud NAT. Contoh alasan Anda memerlukan alamat IP keluar tetap adalah ketika pihak ketiga mengizinkan permintaan dari alamat IP eksternal tertentu. Dengan menggunakan Cloud NAT, Anda dapat memiliki sejumlah kecil alamat IP NAT untuk setiap region yang digunakan untuk komunikasi keluar.
Cloud NAT juga memungkinkan instance VM Anda berkomunikasi di seluruh internet tanpa memiliki alamat IP eksternal sendiri. Aturan firewall Google Cloud bersifat stateful. Artinya, jika koneksi diizinkan antara sumber dan target atau target dan tujuan, semua traffic berikutnya pada kedua arah tersebut akan diizinkan selama koneksi aktif. Dengan kata lain, aturan firewall memungkinkan komunikasi dua arah setelah sesi dibuat.
Gunakan zona DNS pribadi untuk resolusi nama
Gunakan zona pribadi di Cloud DNS agar layanan Anda dapat diselesaikan dengan DNS dalam jaringan VPC Anda menggunakan alamat IP internal tanpa memaparkan pemetaan ini ke luar.
Gunakan DNS split horizon untuk memetakan layanan ke alamat IP yang berbeda dari dalam jaringan VPC dibandingkan dari luar. Misalnya, Anda dapat membuat layanan diekspos melalui load balancing jaringan dari internet publik, tetapi load balancing internal menyediakan layanan yang sama menggunakan nama DNS yang sama dari dalam jaringan VPC.
Akses API untuk layanan terkelola Google
Gunakan gateway internet default jika memungkinkan.
Tambahkan rute eksplisit untuk Google API jika Anda perlu mengubah rute default.
Men-deploy instance yang menggunakan Google API di subnet yang sama.
Gunakan gateway internet default jika memungkinkan
Akses dari resource dalam jaringan VPC ke Google API mengikuti next-hop gateway internet default. Terlepas dari nama gateway next-hop, jalur traffic dari instance ke Google API tetap berada dalam jaringan Google.
Secara default, hanya instance VM dengan alamat IP eksternal yang dapat berkomunikasi dengan API dan layanan Google. Jika Anda memerlukan akses dari instance tanpa alamat IP eksternal, siapkan endpoint Private Service Connect atau gunakan fitur Akses Google Pribadi untuk setiap subnet. Hal ini tidak memperlambat komunikasi untuk Google API.
Google Kubernetes Engine (GKE) otomatis mengaktifkan Akses Google Pribadi di subnet tempat node di-deploy. Semua node di subnet ini yang tidak memiliki alamat IP eksternal dapat mengakses layanan yang dikelola Google.
Menambahkan rute eksplisit untuk Google API jika Anda perlu mengubah rute default
Jika Anda perlu mengubah rute default, tambahkan rute eksplisit untuk rentang IP tujuan Google API.
Di lingkungan dengan rute default (0.0.0.0/0) yang tidak menggunakan next-hop gateway internet default, konfigurasikan rute eksplisit untuk rentang alamat IP tujuan yang digunakan oleh Google API. Setel hop berikutnya dari rute eksplisit ke gateway internet default. Contoh skenario ini adalah saat Anda perlu memeriksa semua traffic melalui perangkat lokal.
Men-deploy instance yang menggunakan Google API di subnet yang sama
Deploy instance yang memerlukan akses ke Google API dan layanan Google pada subnet yang sama dan aktifkan Akses Google Pribadi untuk instance tanpa alamat IP eksternal. Atau, siapkan endpoint Private Service Connect.
Jika Anda mengakses Google API dari lingkungan lokal Anda menggunakan Akses Google Pribadi, gunakan Mengonfigurasi Akses Google Pribadi untuk host lokal untuk mengakses beberapa layanan Google melalui rentang alamat IP pribadi. Periksa untuk melihat layanan yang didukung sebelum mengaktifkan fitur ini. Hal ini karena akses ke Google API lainnya melalui alamat IP yang disediakan oleh layanan ini tidak dapat dijangkau. Mengaktifkan fitur ini dapat memerlukan konfigurasi DNS tambahan, seperti mengonfigurasi View DNS.
Jika Anda mengakses Google API dari lingkungan lokal menggunakan endpoint Private Service Connect, lihat Mengakses endpoint dari host lokal untuk mengetahui detailnya.
Logging, pemantauan, dan visibilitas
Sesuaikan logging untuk kasus penggunaan tertentu dan audiens yang diinginkan.
Tingkatkan interval agregasi log untuk jaringan VPC dengan koneksi panjang.
Gunakan pengambilan sampel Log Alur VPC untuk mengurangi volume.
Hapus metadata tambahan jika Anda hanya memerlukan data IP dan port.
Menyesuaikan logging untuk kasus penggunaan tertentu dan audiens yang diinginkan
Gunakan VPC Flow Logs untuk pemantauan jaringan, forensik, analisis keamanan real-time, dan pengoptimalan biaya. Anda dapat mengaktifkan atau menonaktifkan Log Alur VPC di tingkat subnet. Jika Log Alur VPC diaktifkan untuk satu subnet, log tersebut akan mengumpulkan data dari semua instance VM di subnet tersebut.
Log ini mencatat sampel alur jaringan yang dikirim dan diterima instance VM. Kasus penggunaan logging Anda membantu menentukan subnet yang Anda tentukan yang memerlukan logging, dan berapa lama prosesnya.
Log aliran digabungkan berdasarkan koneksi pada interval 5 detik dari VM Compute Engine, lalu diekspor secara real time. Anda dapat melihat log alur di Cloud Logging dan mengekspornya ke tujuan mana pun yang didukung ekspor Cloud Logging.
Halaman penyerapan log di Logging melacak volume log dalam project Anda dan memungkinkan Anda menonaktifkan semua penyerapan log atau mengecualikan (menghapus) entri log yang tidak Anda minati, sehingga Anda dapat meminimalkan biaya untuk log atas alokasi bulanan Anda.
Log adalah bagian penting dari keberhasilan operasional dan keamanan, tetapi tidak akan berguna kecuali jika Anda meninjaunya dan mengambil tindakan. Sesuaikan log dengan audiens yang mereka tuju, yang membantu memastikan keberhasilan operasional dan keamanan untuk jaringan VPC Anda.
Untuk mengetahui detailnya, lihat Menggunakan Log Alur VPC.
Meningkatkan interval agregasi log untuk jaringan VPC dengan koneksi panjang
Untuk jaringan VPC dengan koneksi berumur panjang, tetapkan interval agregasi log ke 15 menit untuk mengurangi jumlah log yang dihasilkan secara signifikan dan untuk memungkinkan analisis yang lebih cepat dan sederhana.
Contoh alur kerja yang sesuai untuk meningkatkan interval agregasi log adalah pemantauan jaringan, yang melibatkan tugas berikut:
- Melakukan diagnosis jaringan
- Memfilter log aliran oleh VM dan oleh aplikasi untuk memahami perubahan traffic
- Menganalisis pertumbuhan traffic untuk memperkirakan kapasitas
Menggunakan pengambilan sampel Log Alur VPC untuk mengurangi volume
Gunakan pengambilan sampel Log Alur VPC untuk mengurangi volume Log Alur VPC, tetapi masih dapat melihat sampel tingkat rendah dan tampilan gabungan.
Contoh alur kerja yang tepat untuk menggunakan sampling untuk mengurangi volume adalah memahami penggunaan jaringan dan mengoptimalkan biaya traffic jaringan. Alur kerja ini melibatkan tugas-tugas berikut:
- Memperkirakan traffic antara region dan zona
- Memperkirakan traffic ke negara tertentu di internet
- Mengidentifikasi pembicara teratas
Menghapus metadata tambahan jika Anda hanya memerlukan data IP dan port
Dalam kasus penggunaan keamanan jika Anda hanya tertarik dengan port dan alamat IP, hapus metadata tambahan untuk mengurangi volume data yang digunakan di Cloud Logging.
Contoh alur kerja yang sesuai untuk menghapus metadata adalah forensik jaringan, yang melibatkan tugas-tugas berikut:
- Menentukan IP mana yang berbicara dengan siapa dan dengan siapa
- Mengidentifikasi alamat IP yang disusupi, yang ditemukan dengan menganalisis alur jaringan
Arsitektur referensi
Bagian ini menyoroti beberapa arsitektur yang menggambarkan beberapa praktik terbaik dalam dokumen ini.
Satu project, jaringan VPC tunggal
Arsitektur referensi awal ini mencakup semua komponen yang diperlukan untuk men-deploy arsitektur yang sangat tersedia di beberapa region, dengan isolasi tingkat subnet dan SLA 99,99% yang terhubung ke pusat data lokal Anda.
Satu project host, beberapa project layanan, satu VPC Bersama
Dengan membuat arsitektur referensi awal, project host VPC Bersama dan beberapa project layanan memungkinkan administrator mendelegasikan tanggung jawab administratif—seperti membuat dan mengelola instance—kepada Admin Project Layanan sambil mempertahankan kontrol terpusat atas resource jaringan seperti subnet, rute, dan {i>firewall<i}.
Beberapa project host, beberapa project layanan, beberapa VPC Bersama
Diagram berikut mengilustrasikan arsitektur untuk isolasi VPC, yang dikembangkan berdasarkan desain ketersediaan tinggi kami sekaligus memisahkan produksi dari project lain. Ada banyak alasan untuk mempertimbangkan isolasi VPC, termasuk persyaratan audit (seperti PCI), pertimbangan kuota antarlingkungan, atau hanya lapisan isolasi logis lainnya. Anda hanya memerlukan dua interkoneksi (untuk redundansi) per lokasi, tetapi dapat menambahkan beberapa lampiran Interconnect ke beberapa jaringan atau region VPC dari keduanya.
Menggunakan isolasi juga dapat menimbulkan perlunya replikasi, saat Anda memutuskan tempat untuk menempatkan layanan inti seperti proxy, autentikasi, dan layanan direktori. Penggunaan jaringan VPC Layanan Bersama dapat membantu menghindari replikasi ini, dan memungkinkan Anda berbagi layanan ini dengan jaringan VPC lain melalui Peering Jaringan VPC, sekaligus memusatkan administrasi dan deployment.
Firewall L7 stateful antarjaringan VPC
Arsitektur ini memiliki beberapa jaringan VPC yang dihubungkan oleh alat firewall L7 generasi berikutnya (NGFW), yang berfungsi sebagai jembatan multi-NIC antarjaringan VPC.
Jaringan VPC luar yang tidak tepercaya diperkenalkan untuk menghentikan interkoneksi hybrid dan koneksi berbasis internet yang berakhir di segmen luar L7 NGFW untuk diperiksa. Ada banyak variasi pada desain ini, tetapi prinsip utamanya adalah memfilter traffic melalui firewall sebelum traffic tersebut mencapai jaringan VPC yang tepercaya.
Desain ini mengharuskan setiap jaringan VPC berada dalam project tempat Anda menyisipkan NGFW berbasis VM. Karena kuota diberlakukan pada level project, Anda harus mempertimbangkan gabungan dari semua resource VPC.
Langkah berikutnya
- Pembahasan mendalam dan praktik terbaik VPC (video Cloud NEXT'18)
- Topologi jaringan hybrid dan multi-cloud
- Menentukan hierarki resource untuk zona landing Google Cloud
- Praktik terbaik terkait pemilihan region Compute Engine
- Google Cloud untuk profesional pusat data: networking
- Dokumentasi VPC
- Ringkasan jaringan GKE
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.