Menentukan desain jaringan untuk zona landing Google Cloud Anda

Last reviewed 2023-09-11 UTC

Saat mendesain zona landing, Anda harus memilih desain jaringan yang sesuai untuk organisasi Anda. Dokumen ini menjelaskan empat desain jaringan umum, dan membantu Anda memilih opsi yang paling sesuai dengan kebutuhan organisasi Anda, serta preferensi organisasi Anda untuk kontrol terpusat atau kontrol terdesentralisasi. Fitur ini ditujukan bagi engineer jaringan, arsitek, dan praktisi teknis yang terlibat dalam pembuatan desain jaringan untuk zona landing organisasi Anda.

Artikel ini adalah bagian dari seri tentang zona landing.

Pilih desain jaringan Anda

Desain jaringan yang Anda pilih terutama bergantung pada faktor-faktor berikut:

  • Kontrol terpusat atau terdesentralisasi: Bergantung pada preferensi organisasi, Anda harus memilih salah satu opsi berikut:
    • Memusatkan kontrol atas jaringan termasuk penentuan alamat IP, pemilihan rute, dan pembuatan firewall di antara berbagai workload.
    • Beri tim Anda otonomi yang lebih besar dalam menjalankan lingkungan mereka dan membangun elemen jaringan dalam lingkungan mereka sendiri.
  • Opsi konektivitas lokal atau hybrid cloud: Semua desain jaringan yang dibahas dalam dokumen ini menyediakan akses dari lingkungan lokal ke lingkungan cloud melalui Cloud VPN atau Cloud Interconnect. Namun, Beberapa desain mengharuskan Anda menyiapkan beberapa koneksi secara paralel, sementara desain yang lain menggunakan koneksi yang sama untuk semua workload.
  • Persyaratan keamanan: Organisasi Anda mungkin memerlukan traffic antara berbagaiworkload di Google Cloud agar dapat melewati peralatan jaringan terpusat seperti Firewall generasi berikutnya (NGFW) ini. Batasan ini mempengaruhi desain jaringan Virtual Private Cloud (VPC) Anda.
  • Skalabilitas: Beberapa desain mungkin lebih baik untuk organisasi Anda daripada yang lain, berdasarkan jumlah workload yang ingin Anda deploy dan jumlah mesin virtual (VM), beban internal penyeimbang, dan sumber daya lain yang akan mereka gunakan.

Poin keputusan untuk desain jaringan

Diagram berikut menunjukkan keputusan yang harus Anda ambil untuk memilih desain jaringan terbaik bagi organisasi Anda.

Keputusan untuk desain jaringan.

Diagram sebelumnya memandu Anda melalui pertanyaan-pertanyaan berikut:

  1. Apakah Anda memerlukan pemeriksaan Lapisan 7 menggunakan peralatan jaringan di antara berbagai workload di Google Cloud?
  2. Apakah banyak workload Anda memerlukan konektivitas lokal?
    • Jika ya, buka poin keputusan 4.
    • Jika tidak, lanjutkan ke pertanyaan berikutnya.
  3. Dapatkah workload Anda berkomunikasi menggunakan endpoint pribadi dalam model produsen dan konsumen layanan?
  4. Apakah Anda ingin mengelola pembuatan firewall dan pemilihan rute secara terpusat?

Diagram ini dimaksudkan untuk membantu Anda membuat keputusan, tetapi sering kali beberapa desain mungkin cocok untuk organisasi Anda. Dalam kasus ini, sebaiknya pilih desain yang paling sesuai dengan kasus penggunaan Anda.

Opsi desain jaringan

Bagian berikut menjelaskan empat opsi desain umum. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Desain lain yang dibahas di bagian ini adalah alternatif yang berlaku untuk persyaratan kasus organisasi tertentu.

Jaringan yang paling cocok untuk kasus penggunaan Anda mungkin juga berupa jaringan yang menggabungkan elemen dari beberapa opsi desain yang dibahas di bagian ini. Misalnya, Anda dapat menggunakan jaringan VPC Bersama dalam topologi hub-and-spoke untuk kolaborasi yang lebih baik, kontrol terpusat, dan untuk membatasi jumlah jari-jari VPC. Atau, Anda dapat mendesain sebagian besar workload dalam topologi VPC Bersama, tetapi memisahkan sejumlah kecil workload di jaringan VPC terpisah yang hanya mengekspos layanan melalui beberapa endpoint yang ditentukan menggunakan Private Service Connect.

Opsi 1: Jaringan VPC Bersama untuk setiap lingkungan

Kami merekomendasikan desain jaringan ini untuk sebagian besar kasus penggunaan. Desain ini menggunakan VPC Bersama yang terpisah untuk setiap lingkungan deployment yang Anda miliki di Google Cloud (pengembangan, pengujian, dan produksi). Desain ini memungkinkan Anda mengelola resource jaringan secara terpusat dalam jaringan yang sama dan memberikan isolasi jaringan di antara lingkungan yang berbeda.

Gunakan desain ini apabila:

  • Anda menginginkan kontrol pusat terhadap aturan firewall dan pemilihan rute.
  • Anda membutuhkan infrastruktur yang sederhana dan skalabel.
  • Anda memerlukan pengelolaan ruang alamat IP terpusat.

Hindari desain ini apabila:

  • Anda ingin tim developer memiliki otonomi penuh, termasuk kemampuan untuk mengelola aturan firewall, perutean, dan peering mereka ke jaringan tim lainnya.
  • Anda memerlukan pemeriksaan Lapisan 7 menggunakan peralatan NGFW.

Diagram berikut menunjukkan contoh implementasi desain ini.

Diagram Opsi 1.

Diagram di atas menunjukkan hal berikut:

  • Jaringan lokal tersebar di dua lokasi geografis.
  • Jaringan lokal terhubung melalui instance Cloud Interconnect yang redundan ke dua jaringan VPC Bersama yang terpisah, satu untuk produksi dan satu untuk pengembangan.
  • Lingkungan produksi dan pengembangan terhubung ke kedua instance Cloud Interconnect dengan VLAN attachments yang berbeda.
  • Setiap VPC Bersama memiliki project layanan yang menghosting workload.
  • Aturan firewall dikelola secara terpusat dalam project host.
  • Lingkungan pengembangan memiliki struktur VPC yang sama dengan lingkungan produksi.

Berdasarkan desainnya, traffic dari satu lingkungan tidak dapat menjangkau lingkungan lain. Namun, jika workload tertentu harus saling berkomunikasi, Anda dapat mengizinkan transfer data melalui saluran terkontrol secara lokal. Anda juga dapat berbagi data antar-aplikasi dengan layanan Google Cloud seperti Cloud Storage atau Pub/Sub. Sebaiknya hindari menghubungkan langsung lingkungan yang terpisah melalui Peering Jaringan VPC karena akan meningkatkan risiko pencampuran data secara tidak sengaja antar-lingkungan. Penggunaan Peering Jaringan VPC antara lingkungan besar juga meningkatkan risiko mencapai kuota VPC yang mencakup grup peering dan peering.

Untuk informasi selengkapnya, lihat referensi berikut:

Untuk menerapkan opsi desain ini, lihat Membuat opsi 1: Jaringan VPC bersama untuk setiap lingkungan.

Opsi 2: Topologi hub-and-spoke dengan peralatan terpusat

Desain jaringan ini menggunakan topologi hub-and-spoke. Jaringan VPC hub berisi satu set VM alat seperti NGFW yang terhubung ke jaringan VPC spoke yang berisi workload. Traffic antara workload, jaringan lokal, atau internet dirutekan melalui VM alat untuk pemeriksaan dan pemfilteran.

Gunakan desain ini apabila:

  • Anda memerlukan pemeriksaan Lapisan 7 di antara berbagai workload atau aplikasi.
  • Anda memiliki mandat perusahaan yang menentukan vendor alat keamanan untuk semua traffic.

Hindari desain ini apabila:

Diagram berikut menunjukkan contoh penerapan pola ini.

Diagram opsi 2.

Diagram di atas menunjukkan hal berikut:

  • Lingkungan produksi yang mencakup jaringan VPC hub dan beberapa jaringan VPC spoke yang berisi workload.
  • Jaringan VPC yang berbicara terhubung dengan jaringan VPC hub menggunakan Peering Jaringan VPC.
  • Jaringan VPC hub memiliki beberapa instance peralatan virtual dalam grup instance terkelola. Traffic ke grup instance terkelola akan melewati Load Balancer Jaringan passthrough internal.
  • Jaringan VPC spoke berkomunikasi satu sama lain melalui peralatan virtual dengan menggunakan rute statis dengan load balancer internal sebagai hop berikutnya.
  • Cloud Interconnect menghubungkan jaringan VPC transit ke lokasi lokal.
  • Jaringan lokal terhubung melalui Cloud Interconnect yang sama menggunakan lampiran VLAN terpisah.
  • Jaringan VPC transit terhubung ke antarmuka jaringan terpisah pada peralatan virtual, yang memungkinkan Anda memeriksa dan memfilter semua traffic ke dan dari jaringan ini menggunakan peralatan Anda.
  • Lingkungan pengembangan memiliki struktur VPC yang sama dengan lingkungan produksi.
  • Penyiapan ini tidak menggunakan penafsiran alamat jaringan sumber (SNAT). SNAT tidak diperlukan karena Google Cloud menggunakan hashing simetris. Untuk informasi selengkapnya, lihat Hashing simetris.

Berdasarkan desainnya, traffic dari satu jaringan jari-jari tidak dapat menjangkau jaringan lain. Namun, jika workload tertentu harus saling berkomunikasi, Anda dapat menyiapkan peering langsung antara jaringan yang ditarget menggunakan Peering Jaringan VPC, atau berbagi data antar-aplikasi dengan layanan Google Cloud seperti Cloud Storage atau Pub/Sub.

Untuk mempertahankan latensi rendah saat alat berkomunikasi antar-workload, alat harus berada di region yang sama dengan workload. Jika menggunakan beberapa region dalam deployment cloud, Anda dapat memiliki satu set peralatan dan satu VPC hub untuk setiap lingkungan di setiap region. Atau, Anda dapat menggunakan tag jaringan dengan rute agar semua instance berkomunikasi dengan perangkat terdekat.

Aturan firewall dapat membatasi konektivitas dalam jaringan VPC yang berbicara yang berisi workload. Sering kali, tim yang mengelola workload juga mengelola aturan firewall ini. Untuk kebijakan pusat, Anda dapat menggunakan kebijakan firewall hierarkis. Jika Anda mengharuskan tim jaringan pusat untuk memiliki kontrol penuh atas aturan firewall, pertimbangkan untuk men-deploy aturan tersebut secara terpusat di semua jaringan VPC menggunakan pendekatan GitOps. Dalam kasus ini, batasi izin IAM hanya untuk administrator yang dapat mengubah aturan firewall. Jaringan VPC Spoke juga dapat berupa jaringan VPC Bersama jika beberapa tim men-deploy di jari-jarinya.

Dalam desain ini, sebaiknya gunakan Peering Jaringan VPC untuk menghubungkan jaringan VPC hub dan jaringan VPC yang berbicara karena menambah kompleksitas minimum. Namun, jumlah maksimum jari-jari dibatasi oleh hal berikut:

  • Batas pada koneksi Peering Jaringan VPC dari satu jaringan VPC.
  • Batas grup peering seperti jumlah maksimum aturan penerusan untuk Load Balancing TCP/UDP internal untuk setiap grup peering.

Jika diperkirakan akan mencapai batas ini, Anda dapat menghubungkan jaringan yang berbicara melalui Cloud VPN. Penggunaan Cloud VPN menimbulkan biaya dan kompleksitas tambahan, dan setiap tunnel VPN Cloud memiliki batas bandwidth.

Untuk informasi selengkapnya, lihat referensi berikut:

Untuk menerapkan opsi desain ini, lihat Membuat opsi 2: Topologi hub-and-spoke dengan peralatan pusat.

Opsi 3: Topologi hub-and-spoke tanpa peralatan

Desain jaringan ini juga menggunakan topologi hub-and-spoke, dengan jaringan VPC hub yang terhubung ke jaringan lokal dan jaringan VPC spoke yang berisi workload. Karena Peering Jaringan VPC bersifat non-transitif, jaringan jari-jari tidak dapat saling berkomunikasi satu sama lain secara langsung.

Gunakan desain ini apabila:

  • Anda ingin workload atau lingkungan di Google Cloud tidak berkomunikasi satu sama lain menggunakan alamat IP internal, tetapi Anda ingin workload atau lingkungan tersebut berbagi konektivitas lokal.
  • Anda ingin memberikan otonomi kepada tim dalam mengelola aturan firewall dan pemilihan rute mereka sendiri.

Hindari desain ini apabila:

  • Anda memerlukan pemeriksaan Lapisan 7 di antara workload.
  • Anda ingin mengelola aturan pemilihan rute dan firewall secara terpusat.
  • Anda memerlukan komunikasi dari layanan lokal hingga layanan terkelola yang terhubung ke jari-jari melalui Peering Jaringan VPC lain, karena Peering Jaringan VPC bersifat non-transitif.

Diagram berikut menunjukkan contoh implementasi desain ini.

Diagram opsi 3.

Diagram di atas menunjukkan hal berikut:

  • Lingkungan produksi yang mencakup jaringan VPC hub dan beberapa jaringan VPC spoke yang berisi workload.
  • Jaringan VPC yang berbicara terhubung dengan jaringan VPC hub menggunakan Peering Jaringan VPC.
  • Konektivitas ke lokasi lokal melewati koneksi Cloud Interconnect di jaringan VPC hub.
  • Jaringan lokal terhubung melalui instance Cloud Interconnect menggunakan lampiran VLAN terpisah.
  • Lingkungan pengembangan memiliki struktur VPC yang sama dengan lingkungan produksi.

Berdasarkan desainnya, traffic dari satu jaringan jari-jari tidak dapat menjangkau jaringan lain. Namun, jika workload tertentu harus saling berkomunikasi, Anda dapat menyiapkan peering langsung antara jaringan yang ditarget menggunakan Peering Jaringan VPC, atau berbagi data antar-aplikasi dengan layanan Google Cloud seperti Cloud Storage atau Pub/Sub.

Desain jaringan ini sering digunakan di lingkungan tempat tim bertindak secara otonom dan tidak ada kontrol terpusat atas aturan pemilihan rute dan firewall. Namun, skala desain ini dibatasi oleh hal berikut:

Oleh karena itu, desain ini biasanya tidak digunakan dalam organisasi besar yang memiliki banyak workload terpisah di Google Cloud.

Sebagai variasi desain, Anda dapat menggunakan Cloud VPN, bukan Peering Jaringan VPC. Dengan Cloud VPN, Anda dapat meningkatkan jumlah spokes, dengan menambahkan batas bandwidth untuk setiap tunnel dan meningkatkan kompleksitas serta biaya. Saat Anda menggunakan pemberitahuan rute kustom, Cloud VPN juga memungkinkan transitivitas antara jari-jari tanpa mengharuskan Anda untuk menghubungkan langsung semua jaringan jari-jari.

Untuk informasi selengkapnya, lihat referensi berikut:

Untuk menerapkan opsi desain ini, lihat Membuat opsi 3: Topologi hub-and-spoke tanpa peralatan.

Opsi 4: Mengekspos layanan dalam model produsen konsumen dengan Private Service Connect

Dalam desain jaringan ini, setiap tim atau workload mendapatkan jaringan VPC mereka sendiri, yang juga bisa berupa jaringan VPC Bersama. Setiap jaringan VPC dikelola secara independen dan menggunakan Private Service Connect untuk menampilkan semua layanan yang perlu diakses dari luar jaringan VPC

Gunakan desain ini apabila:

  • Workload hanya berkomunikasi satu sama lain dan dengan lingkungan lokal melalui endpoint yang ditentukan.
  • Anda ingin tim menjadi independen satu sama lain, dan mengelola ruang alamat IP, firewall, serta aturan pemilihan rute mereka sendiri.

Hindari desain ini apabila:

  • Komunikasi antara layanan dan aplikasi menggunakan banyak port atau saluran yang berbeda, atau port dan saluran sering berubah.
  • Komunikasi antara workload menggunakan protokol selain TCP atau UDP.
  • Anda memerlukan pemeriksaan Lapisan 7 di antara workload.

Diagram berikut menunjukkan contoh penerapan pola ini.

Diagram opsi 4.

Diagram di atas menunjukkan hal berikut:

  • workload yang terpisah berada di project dan jaringan VPC yang terpisah.
  • VM klien dalam satu jaringan VPC dapat terhubung ke workload di jaringan VPC lain melalui endpoint Private Service Connect.
  • Endpoint disertakan ke lampiran layanan di jaringan VPC tempat layanan berada. Lampiran layanan dapat berada di region yang berbeda dengan endpoint jika endpoint dikonfigurasi untuk akses global.
  • Lampiran layanan terhubung ke workload melalui Cloud Load Balancing.
  • Klien dalam VPC workload dapat menjangkau workload yang berada di infrastruktur lokal sebagai berikut:
    • Endpoint terhubung ke lampiran layanan di jaringan VPC .
    • Lampiran layanan terhubung ke jaringan lokal menggunakan Cloud Interconnect.
  • Load Balancer Aplikasi internal dipasang ke lampiran layanan dan menggunakan grup endpoint jaringan hybrid untuk menyeimbangkan beban traffic di antara endpoint yang berada di infrastruktur lokal.
  • Klien lokal juga dapat menjangkau endpoint di jaringan VPC transit yang terhubung ke lampiran layanan di jaringan VPC workload.

Untuk informasi selengkapnya, lihat referensi berikut:

Untuk menerapkan opsi desain ini, lihat Membuat opsi 4: Mengekspos layanan dalam model produsen konsumen dengan Private Service Connect.

Praktik terbaik untuk deployment jaringan

Setelah memilih desain jaringan terbaik untuk kasus penggunaan Anda, sebaiknya terapkan praktik terbaik berikut:

Untuk informasi selengkapnya, lihat Praktik terbaik dan arsitektur referensi untuk desain VPC.

Langkah selanjutnya