Pola arsitektur jaringan hybrid dan multicloud yang aman

Last reviewed 2023-12-14 UTC

Halaman ini menampilkan tampilan satu halaman dari semua halaman dalam Membangun arsitektur hybrid dan multicloud menggunakan Google Cloud. Anda dapat mencetak halaman ini atau menyimpannya dalam format PDF dengan menggunakan fungsi cetak browser dan memilih opsi Simpan sebagai PDF. Halaman ini tidak menyediakan panel daftar isi (ToC) di sisi kanan.

Dokumen ini adalah yang ketiga dari tiga dokumen dalam satu set. Kursus ini membahas pola arsitektur jaringan hybrid dan multicloud. Bagian ini mempelajari beberapa pola arsitektur jaringan aman yang umum yang dapat Anda gunakan untuk arsitektur hybrid dan multicloud. Panduan ini menjelaskan skenario yang paling sesuai untuk pola jaringan tersebut, dan memberikan praktik terbaik untuk menerapkannya dengan Google Cloud.

Kumpulan dokumen untuk pola arsitektur hybrid dan multicloud terdiri dari bagian-bagian berikut:

• Membangun arsitektur hybrid dan multicloud: membahas perencanaan strategi untuk merancang konfigurasi hybrid dan multicloud dengan Google Cloud.
• Pola arsitektur hybrid dan multicloud: membahas pola arsitektur umum yang dapat diadopsi sebagai bagian dari strategi hybrid dan multicloud.
• Pola arsitektur jaringan aman hybrid dan multicloud: membahas pola arsitektur jaringan hybrid dan multicloud dari perspektif jaringan (dokumen ini).

Menghubungkan lingkungan komputasi pribadi ke Google Cloud secara aman dan andal sangat penting untuk keberhasilan arsitektur hybrid dan multicloud. Konektivitas jaringan hybrid dan pola arsitektur jaringan cloud yang Anda pilih untuk penyiapan hybrid dan multicloud harus memenuhi persyaratan unik workload perusahaan Anda. Hal ini juga harus sesuai dengan pola arsitektur yang ingin Anda terapkan. Meskipun Anda mungkin perlu menyesuaikan setiap desain, ada pola umum yang dapat Anda gunakan sebagai cetak biru.

Pola arsitektur jaringan dalam dokumen ini tidak boleh dianggap sebagai alternatif untuk desain zona landing di Google Cloud. Sebagai gantinya, Anda harus merancang dan men-deploy pola arsitektur yang dipilih sebagai bagian dari keseluruhan desain zona landing Google Cloud, yang mencakup area berikut:

• Identitas
• Pengelolaan resource
• Keamanan
• Networking
• Pemantauan

Aplikasi yang berbeda dapat menggunakan pola arsitektur jaringan yang berbeda, yang digabungkan sebagai bagian dari arsitektur zona landing. Dalam penyiapan multicloud, Anda harus mempertahankan konsistensi desain zona landing di semua lingkungan.

Seri ini berisi halaman berikut:

• Pertimbangan desain
• Pola arsitektur
  • Pola yang dicerminkan
  • Pola jala
  • Pola terbatas
    • Traffic keluar dengan gerbang
    • Traffic masuk terbatas
    • Traffic keluar dan masuk terbatas
  • Handover
• Praktik terbaik umum

Kontributor

Penulis: Marwan Al Shawi | Partner Customer Engineer

Kontributor lainnya:

• Saud Albazei | Customer Engineer, Modernisasi Aplikasi
• Anna Berenberg | Rekan Teknik
• Marco Ferrari | Arsitek Solusi Cloud
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Arsitek Solusi Cloud
• Mark Schlagenhauf | Penulis Teknis, Networking
• Daniel Strebel | Pemimpin Solusi EMEA, Modernisasi Aplikasi
• Ammett Williams | Developer Relations Engineer

Pola arsitektur

Dokumen dalam seri ini membahas pola arsitektur jaringan yang dirancang berdasarkan model komunikasi yang diperlukan antara aplikasi yang berada di Google Cloud dan di lingkungan lain (lokal, di cloud lain, atau keduanya).

Pola-pola ini harus dimasukkan ke dalam arsitektur zona landing organisasi secara keseluruhan, yang dapat mencakup beberapa pola jaringan untuk mengatasi persyaratan komunikasi dan keamanan spesifik dari berbagai aplikasi.

Dokumen dalam seri ini juga membahas berbagai variasi desain yang dapat digunakan dengan setiap pola arsitektur. Pola jaringan berikut dapat membantu Anda memenuhi persyaratan komunikasi dan keamanan untuk aplikasi:

• Pola yang dicerminkan
• Pola jala
• Pola terbatas
  • Traffic keluar dengan gerbang
  • Traffic masuk terbatas
  • Traffic keluar dengan gerbang dan akses masuk terbatas
• Pola serah terima

Pola yang diduplikasi

Pola yang dicerminkan didasarkan pada replikasi desain lingkungan atau lingkungan tertentu yang sudah ada ke lingkungan atau lingkungan baru. Oleh karena itu, pola ini berlaku terutama untuk arsitektur yang mengikuti pola hibrid lingkungan. Dalam pola tersebut, Anda menjalankan workload pengembangan dan pengujian di satu lingkungan sekaligus menjalankan workload staging dan produksi di lingkungan lain.

Pola yang diduplikasi mengasumsikan bahwa beban kerja pengujian dan produksi tidak seharusnya berkomunikasi langsung satu sama lain. Namun, kedua grup workload tersebut harus dapat dikelola dan di-deploy secara konsisten.

Jika Anda menggunakan pola ini, hubungkan kedua lingkungan komputasi tersebut sesuai dengan persyaratan berikut:

• Continuous integration/continuous deployment (CI/CD) dapat men-deploy dan mengelola workload di semua lingkungan komputasi atau lingkungan tertentu.
• Pemantauan, manajemen konfigurasi, dan sistem administratif lainnya harus berfungsi di semua lingkungan komputasi.
• Beban kerja tidak dapat berkomunikasi langsung di seluruh lingkungan komputasi. Jika diperlukan, komunikasi harus dilakukan dengan cara yang mendetail dan terkontrol.

Arsitektur

Diagram arsitektur berikut menunjukkan arsitektur referensi tingkat tinggi dari pola ini yang mendukung CI/CD, Pemantauan, pengelolaan konfigurasi, sistem administratif lainnya, dan komunikasi workload:

Deskripsi arsitektur dalam diagram sebelumnya adalah sebagai berikut:

• Beban kerja didistribusikan berdasarkan lingkungan fungsional (pengembangan, pengujian, CI/CD, dan alat administratif) di seluruh VPC terpisah di sisi Google Cloud.
• VPC Bersama digunakan untuk beban kerja pengembangan dan pengujian. VPC tambahan digunakan untuk CI/CD dan alat administratif. Dengan VPC bersama:
  • Aplikasi dikelola oleh tim yang berbeda per lingkungan dan per project layanan.
  • Project host mengelola dan mengontrol komunikasi jaringan dan kontrol keamanan antara lingkungan pengembangan dan pengujian—serta ke luar VPC.
• VPC CI/CD terhubung ke jaringan yang menjalankan workload produksi di lingkungan komputasi pribadi Anda.
• Aturan firewall hanya mengizinkan traffic yang diizinkan.
  • Anda juga dapat menggunakan Cloud Next Generation Firewall Enterprise dengan Intrusion Prevention Service (IPS) untuk menerapkan pemeriksaan paket mendalam untuk pencegahan ancaman tanpa mengubah desain atau perutean. Cloud Next Generation Firewall Enterprise bekerja dengan membuat endpoint firewall zona yang dikelola Google yang menggunakan teknologi intersepsi paket guna memeriksa workload secara transparan untuk tanda tangan ancaman yang dikonfigurasi. Teknologi ini juga melindungi workload dari ancaman.
• Memungkinkan komunikasi antar-VPC yang di-peering menggunakan alamat IP internal.
  • Peering dalam pola ini memungkinkan CI/CD dan sistem administratif untuk men-deploy dan mengelola workload pengembangan dan pengujian.
• Pertimbangkan praktik terbaik umum ini.

Anda dapat membuat koneksi CI/CD ini menggunakan salah satu opsi konektivitas jaringan hybrid dan multicloud yang telah dibahas, yang memenuhi persyaratan bisnis dan aplikasi Anda. Agar Anda dapat men-deploy dan mengelola workload produksi, koneksi ini memberikan jangkauan jaringan pribadi di antara berbagai lingkungan komputasi. Semua lingkungan harus memiliki ruang alamat IP RFC 1918 bebas tumpang-tindih.

Jika instance dalam lingkungan pengembangan dan pengujian memerlukan akses internet, pertimbangkan opsi berikut:

• Anda dapat men-deploy Cloud NAT ke jaringan project host VPC Bersama yang sama. Dengan men-deploy ke jaringan project host VPC Bersama yang sama, instance ini tidak dapat diakses langsung dari internet.
• Untuk traffic web keluar, Anda dapat menggunakan Proxy Web Aman. Proxy ini menawarkan sejumlah manfaat.

Untuk informasi selengkapnya tentang alat dan kemampuan Google Cloud yang membantu Anda membangun, menguji, dan men-deploy di Google Cloud serta di seluruh lingkungan hybrid dan multicloud, lihat blog penjelasan DevOps dan CI/CD di Google Cloud.

Variasi

Untuk memenuhi persyaratan desain yang berbeda, sambil tetap mempertimbangkan semua persyaratan komunikasi, pola arsitektur yang diduplikasi menawarkan opsi ini, yang dijelaskan di bagian berikut:

• VPC Bersama per lingkungan
• Firewall lapisan aplikasi terpusat
• Topologi hub-dan-spoke
• Arsitektur terdistribusi zero-trust Microservice

VPC Bersama per lingkungan

Opsi VPC bersama per desain lingkungan memungkinkan pemisahan tingkat aplikasi atau layanan di seluruh lingkungan, termasuk CI/CD dan alat administratif yang mungkin diperlukan untuk memenuhi persyaratan keamanan organisasi tertentu. Persyaratan ini membatasi komunikasi, domain administratif, dan kontrol akses untuk berbagai layanan yang juga perlu dikelola oleh tim yang berbeda.

Desain ini memberikan pemisahan dengan memberikan isolasi tingkat jaringan dan project antara berbagai lingkungan, sehingga memungkinkan komunikasi yang lebih mendetail serta kontrol akses Identity and Access Management (IAM).

Dari perspektif manajemen dan operasi, desain ini memberikan fleksibilitas untuk mengelola aplikasi dan workload yang dibuat oleh tim yang berbeda per lingkungan dan per project layanan. Jaringan VPC, dan fitur keamanannya dapat disediakan dan dikelola oleh tim operasi jaringan berdasarkan kemungkinan struktur berikut:

• Satu tim mengelola semua project host di semua lingkungan.
• Tim yang berbeda mengelola project host di lingkungannya masing-masing.

Keputusan tentang mengelola project host harus didasarkan pada struktur tim, operasi keamanan, dan persyaratan akses setiap tim. Anda dapat menerapkan variasi desain ini ke opsi desain zona landing bersama Jaringan VPC bersama untuk setiap zona landing. Namun, Anda perlu mempertimbangkan persyaratan komunikasi pola yang dicerminkan untuk menentukan komunikasi apa yang diizinkan di antara berbagai lingkungan, termasuk komunikasi melalui jaringan hybrid.

Anda juga dapat menyediakan jaringan VPC Bersama untuk setiap lingkungan utama, seperti dalam diagram berikut:

{i>Firewall<i} lapisan aplikasi terpusat

Dalam beberapa skenario, persyaratan keamanan mungkin mewajibkan pertimbangan lapisan aplikasi (Lapisan 7) dan inspeksi paket mendalam dengan mekanisme firewall lanjutan yang melebihi kemampuan Cloud Next Generation Firewall. Untuk memenuhi persyaratan keamanan dan standar organisasi Anda, Anda dapat menggunakan alat NGFW yang dihosting di peralatan virtual jaringan (NVA). Beberapa partner keamanan Google Cloud menawarkan opsi yang sesuai untuk tugas ini.

Seperti dalam diagram berikut, Anda dapat menempatkan NVA di jalur jaringan antara Virtual Private Cloud dan lingkungan komputasi pribadi menggunakan beberapa antarmuka jaringan.

Desain ini juga dapat digunakan dengan beberapa VPC bersama seperti yang digambarkan dalam diagram berikut.

NVA dalam desain ini berfungsi sebagai lapisan keamanan perimeter. Kebijakan ini juga berfungsi sebagai dasar untuk mengaktifkan pemeriksaan traffic inline dan menerapkan kebijakan kontrol akses yang ketat.

Untuk strategi keamanan multi-lapisan yang kuat dan mencakup aturan firewall VPC dan kemampuan layanan pencegahan intrusi, sertakan pemeriksaan traffic dan kontrol keamanan lebih lanjut untuk arus traffic timur-barat dan utara-selatan.

Catatan: Di region cloud yang didukung, dan jika secara teknis memungkinkan untuk desain Anda, NVA dapat di-deploy tanpa memerlukan beberapa jaringan VPC atau antarmuka peralatan. Deployment ini didasarkan pada penggunaan kemampuan load balancing dan perutean berbasis kebijakan. Kemampuan ini memungkinkan mekanisme yang tidak bergantung pada topologi dan berdasarkan kebijakan untuk mengintegrasikan NVA ke dalam jaringan cloud Anda. Untuk mengetahui detail selengkapnya, lihat Men-deploy virtual peralatan (NVA) jaringan tanpa beberapa VPC.

Topologi hub-dan-spoke

Variasi desain lainnya yang mungkin dilakukan adalah menggunakan VPC terpisah (termasuk VPC bersama) untuk pengembangan dan berbagai tahap pengujian. Dalam variasi ini, seperti yang ditunjukkan dalam diagram berikut, semua lingkungan tahap terhubung dengan CI/CD dan VPC administratif dalam arsitektur hub-and-spoke. Gunakan opsi ini jika Anda harus memisahkan domain administratif dan fungsi di setiap lingkungan. Model komunikasi hub-dan-spoke dapat membantu memenuhi persyaratan berikut:

• Aplikasi perlu mengakses sekumpulan layanan umum, seperti pemantauan, alat manajemen konfigurasi, CI/CD, atau autentikasi.
• Sekumpulan kebijakan keamanan umum perlu diterapkan ke traffic masuk dan keluar secara terpusat melalui hub.

Untuk mengetahui informasi selengkapnya tentang opsi desain hub-dan-spoke, lihat Topologi hub-dan-spoke dengan peralatan terpusat dan Topologi Hub-dan-spoke tanpa peralatan terpusat.

Seperti ditunjukkan dalam diagram sebelumnya, komunikasi antar-VPC dan konektivitas hybrid semuanya melewati VPC hub. Sebagai bagian dari pola ini, Anda dapat mengontrol dan membatasi komunikasi di VPC hub agar selaras dengan persyaratan konektivitas Anda.

Sebagai bagian dari arsitektur jaringan hub-and-spoke, berikut ini adalah opsi konektivitas utama (antara spoke dan VPC hub) di Google Cloud:

• Peering Jaringan VPC
• VPN
• Menggunakan network virtual appliance (NVA)
  • Dengan beberapa antarmuka jaringan
  • Dengan Network Connectivity Center (NCC)

Untuk mengetahui informasi selengkapnya tentang opsi yang harus Anda pertimbangkan dalam desain Anda, lihat Arsitektur jaringan Hub-and-spoke. Faktor utama yang memengaruhi pemilihan VPN melalui peering VPC antara spoke dan VPC hub adalah saat transitivitas traffic diperlukan. Transitivitas lalu lintas berarti bahwa lalu lintas dari spidol dapat mencapai jari-jari lain melalui hub.

Arsitektur terdistribusi zero-trust Microservice

Arsitektur hybrid dan multicloud dapat memerlukan beberapa cluster untuk mencapai tujuan teknis dan bisnis, termasuk memisahkan lingkungan produksi dari lingkungan pengembangan dan pengujian. Oleh karena itu, kontrol keamanan perimeter jaringan merupakan hal yang penting, terutama jika harus mematuhi persyaratan keamanan tertentu.

Tidak cukup untuk mendukung persyaratan keamanan arsitektur microservice terdistribusi cloud-first saat ini, dan Anda juga harus mempertimbangkan arsitektur terdistribusi zero-trust. Arsitektur terdistribusi zero-trust microservice mendukung arsitektur microservice Anda dengan penerapan kebijakan keamanan, autentikasi, dan identitas workload tingkat microservice. Kepercayaan berbasis identitas dan diterapkan untuk setiap layanan.

Dengan menggunakan arsitektur proxy terdistribusi, seperti mesh layanan, layanan dapat secara efektif memvalidasi pemanggil dan menerapkan kebijakan kontrol akses yang terperinci untuk setiap permintaan, sehingga lingkungan microservice menjadi lebih aman dan skalabel. Cloud Service Mesh memberi Anda fleksibilitas untuk memiliki mesh umum yang dapat mencakup deployment lokal dan Google Cloud Anda. Mesh ini menggunakan kebijakan otorisasi untuk membantu mengamankan komunikasi layanan-ke-layanan.

Anda juga dapat mengintegrasikan Apigee Adapter for Envoy, yang merupakan deployment gateway Apigee API yang ringan di dalam cluster Kubernetes, dengan arsitektur ini. Adaptor Apigee untuk Envoy adalah proxy layanan dan edge open source yang dirancang untuk aplikasi cloud-first.

Untuk informasi selengkapnya tentang topik ini, lihat artikel berikut:

• Arsitektur Terdistribusi Zero-Trust
• Lingkungan hybrid GKE Enterprise
• Hubungkan ke Google
  • Hubungkan cluster GKE Enterprise lokal ke jaringan Google Cloud.
• Menyiapkan mesh multicloud atau hybrid
  • Deploy Cloud Service Mesh di seluruh lingkungan dan cluster.

Praktik terbaik pola yang dicerminkan

• Sistem CI/CD yang diperlukan untuk men-deploy atau mengonfigurasi ulang deployment produksi harus sangat tersedia, yang berarti semua komponen arsitektur harus dirancang untuk menyediakan tingkat ketersediaan sistem yang diharapkan. Untuk mengetahui informasi selengkapnya, lihat Keandalan infrastruktur Google Cloud.

• Untuk menghilangkan error konfigurasi pada proses berulang seperti pembaruan kode, otomatisasi sangat penting untuk menstandarkan build, pengujian, dan deployment Anda. Untuk mempelajari lebih lanjut cara menggunakan berbagai pemeriksaan dan pengamanan saat Anda melakukan otomatisasi, lihat Mengotomatiskan deployment Anda.

• Integrasi NVA terpusat dalam desain ini mungkin memerlukan penggabungan beberapa segmen dengan berbagai tingkat kontrol akses keamanan. Untuk mengetahui informasi selengkapnya, lihat Peralatan jaringan terpusat di Google Cloud.

• Saat mendesain solusi yang menyertakan NVA, penting untuk mempertimbangkan ketersediaan tinggi (HA) NVA untuk menghindari titik tunggal kegagalan yang dapat memblokir semua komunikasi. Ikuti panduan desain dan penerapan HA dan redundansi yang disediakan oleh vendor NVA. Untuk mengetahui informasi selengkapnya, lihat bagian opsi arsitektur pada Peralatan jaringan terpusat di Google Cloud untuk mencapai ketersediaan tinggi di antara peralatan virtual.

• Dengan tidak mengekspor rute IP lokal melalui peering VPC atau VPN ke VPC pengembangan dan pengujian, Anda dapat membatasi keterjangkauan jaringan dari lingkungan pengembangan dan pengujian ke lingkungan lokal. Untuk mengetahui informasi selengkapnya, lihat Pertukaran rute kustom Peering Jaringan VPC.

• Untuk workload dengan alamat IP pribadi yang dapat memerlukan akses API Google, Anda dapat mengekspos Google API menggunakan endpoint Private Service Connect dalam jaringan VPC. Untuk informasi selengkapnya, lihat Traffic masuk yang dibatasi, dalam seri ini.

• Tinjau praktik terbaik umum untuk pola arsitektur jaringan hybrid dan multicloud.

Pola mesh

Pola meshed didasarkan pada penetapan arsitektur jaringan hybrid. Arsitektur tersebut mencakup beberapa lingkungan komputasi. Dalam lingkungan ini, semua sistem dapat berkomunikasi satu sama lain dan tidak terbatas pada komunikasi satu arah berdasarkan persyaratan keamanan aplikasi Anda. Pola jaringan ini berlaku terutama pada arsitektur hibrida bertingkat, cloud berpartisi, atau bursting. Hal ini juga berlaku untuk desain kelangsungan bisnis guna menyediakan lingkungan pemulihan dari bencana (DR) di Google Cloud. Dalam semua kasus, Anda harus menghubungkan lingkungan komputasi dengan cara yang selaras dengan persyaratan komunikasi berikut:

• Workload dapat berkomunikasi satu sama lain di seluruh batas lingkungan menggunakan alamat IP RFC 1918 pribadi.
• Komunikasi dapat dimulai dari kedua sisi. Detail model komunikasi dapat bervariasi berdasarkan persyaratan aplikasi dan keamanan, seperti model komunikasi yang dibahas dalam opsi desain yang mengikutinya.
• Aturan firewall yang Anda gunakan harus mengizinkan traffic antara sumber alamat IP dan tujuan tertentu berdasarkan persyaratan aplikasi, atau aplikasi, yang polanya dirancang. Idealnya, Anda dapat menggunakan pendekatan keamanan berlapis untuk membatasi aliran traffic secara mendetail, baik di antara maupun di dalam lingkungan komputasi.

Arsitektur

Diagram berikut mengilustrasikan arsitektur referensi tingkat tinggi dari pola meshed.

• Semua lingkungan harus menggunakan ruang alamat IP RFC 1918 bebas tumpang-tindih.
• Di sisi Google Cloud, Anda dapat men-deploy workload ke dalam satu atau beberapa VPC bersama atau VPC non-bersama. Untuk opsi desain lain yang mungkin dari pola ini, lihat variasi desain yang mengikutinya. Struktur VPC yang dipilih harus selaras dengan project dan desain hierarki resource organisasi Anda.
• Jaringan VPC Google Cloud terperluas ke lingkungan komputasi lainnya. Lingkungan tersebut dapat berada di infrastruktur lokal atau di cloud lain. Gunakan salah satu opsi konektivitas jaringan hybrid dan multicloud yang memenuhi kebutuhan bisnis dan aplikasi Anda.

• Batasi komunikasi hanya ke alamat IP yang diizinkan dari sumber dan tujuan Anda. Gunakan salah satu kemampuan berikut, atau kombinasinya:

  • Aturan firewall atau kebijakan firewall.

  • Alat virtual jaringan (NVA) dengan kemampuan pemeriksaan firewall (NGFW) generasi berikutnya, yang ditempatkan di jalur jaringan.

  • Cloud Next Generation Firewall Enterprise dengan Intrusion Prevention Service (IPS) guna mengimplementasikan pemeriksaan paket mendalam untuk pencegahan ancaman tanpa mengubah desain atau perutean jaringan.

Variasi

Pola arsitektur meshed dapat digabungkan dengan pendekatan lain untuk memenuhi berbagai persyaratan desain, sambil tetap mempertimbangkan persyaratan komunikasi pola tersebut. Opsi pola dijelaskan di bagian berikut:

• Satu VPC per lingkungan
• Menggunakan firewall lapisan aplikasi terpusat
• Arsitektur terdistribusi zero-trust Microservice

Satu VPC per lingkungan

Alasan umum untuk mempertimbangkan opsi satu VPC per lingkungan adalah sebagai berikut:

• Lingkungan cloud memerlukan pemisahan tingkat jaringan untuk jaringan dan resource VPC, sesuai dengan desain hierarki resource organisasi Anda. Jika pemisahan domain administratif diperlukan, pemisahan tersebut juga dapat digabungkan dengan project terpisah per lingkungan.
  • Untuk mengelola resource jaringan secara terpusat dalam sebuah jaringan bersama dan menyediakan isolasi jaringan di antara berbagai lingkungan, gunakan VPC bersama untuk setiap lingkungan yang Anda miliki di Google Cloud, seperti pengembangan, pengujian, dan produksi.
• Persyaratan penskalaan yang mungkin perlu melebihi kuota VPC untuk satu VPC atau project.

Seperti dalam diagram berikut, desain satu VPC per lingkungan memungkinkan setiap VPC terintegrasi langsung dengan lingkungan lokal atau lingkungan cloud lainnya menggunakan VPN, atau Cloud Interconnect dengan beberapa lampiran VLAN.

Pola yang ditampilkan dalam diagram sebelumnya dapat diterapkan pada topologi jaringan hub-dan-spoke zona landing. Dalam topologi tersebut, satu (atau beberapa) koneksi hybrid dapat dibagikan dengan semua VPC yang diucapkan. Jaringan ini digunakan bersama dengan menggunakan VPC transit untuk menghentikan konektivitas hybrid dan VPC yang lain. Anda juga dapat memperluas desain ini dengan menambahkan NVA dengan kemampuan pemeriksaan firewall generasi berikutnya (NGFW) di VPC transit, seperti yang dijelaskan di bagian berikutnya, "Menggunakan firewall lapisan aplikasi terpusat".

Menggunakan firewall lapisan aplikasi terpusat

Jika persyaratan teknis Anda mewajibkan mempertimbangkan lapisan aplikasi (Lapisan 7) dan pemeriksaan paket mendalam dengan kemampuan firewall tingkat lanjut yang melebihi kemampuan Cloud Next Generation Firewall, Anda dapat menggunakan perangkat NGFW yang dihosting di NVA. Namun, NVA tersebut harus memenuhi kebutuhan keamanan organisasi Anda. Untuk menerapkan mekanisme ini, Anda dapat memperluas topologi untuk meneruskan semua traffic lintas lingkungan melalui firewall NVA terpusat, seperti yang ditunjukkan pada diagram berikut.

Anda dapat menerapkan pola dalam diagram berikut di desain zona landing menggunakan topologi hub-dan-spoke dengan peralatan terpusat:

Seperti ditunjukkan dalam diagram sebelumnya, NVA berfungsi sebagai lapisan keamanan perimeter dan berfungsi sebagai dasar untuk mengaktifkan pemeriksaan traffic inline. Alat ini juga menerapkan kebijakan kontrol akses yang ketat. Untuk memeriksa arus traffic timur-barat dan utara-selatan, desain NVA terpusat dapat mencakup beberapa segmen dengan tingkat kontrol akses keamanan yang berbeda.

Arsitektur terdistribusi zero-trust Microservice

Saat aplikasi dalam container digunakan, arsitektur terdistribusi zero-trust microservice yang dibahas di bagian pola diduplikasi juga berlaku untuk pola arsitektur ini.

Perbedaan utama antara pola ini dan pola yang dicerminkan adalah model komunikasi antara beban kerja di Google Cloud dan lingkungan lainnya dapat dimulai dari kedua sisi. Traffic harus dikontrol dan terperinci, berdasarkan persyaratan aplikasi dan persyaratan keamanan menggunakan Mesh Layanan.

Praktik terbaik pola mesh

• Sebelum melakukan hal lainnya, tentukan desain hierarki resource, dan desain yang diperlukan untuk mendukung project dan VPC apa pun. Dengan begitu, Anda dapat memilih arsitektur jaringan optimal yang selaras dengan struktur project Google Cloud Anda.
• Gunakan arsitektur terdistribusi zero-trust saat menggunakan Kubernetes dalam lingkungan komputasi pribadi Anda dan Google Cloud.

• Saat menggunakan NVA terpusat dalam desain, Anda harus menentukan beberapa segmen dengan berbagai tingkat kontrol akses keamanan dan kebijakan pemeriksaan traffic. Dasarkan kontrol dan kebijakan ini berdasarkan persyaratan keamanan aplikasi Anda. Untuk mengetahui informasi selengkapnya, lihat Peralatan jaringan terpusat di Google Cloud.

• Saat mendesain solusi yang menyertakan NVA, penting untuk mempertimbangkan ketersediaan tinggi (HA) NVA untuk menghindari titik tunggal kegagalan yang dapat memblokir semua komunikasi. Ikuti panduan desain dan penerapan HA dan redundansi yang disediakan oleh vendor keamanan Google Cloud yang menyediakan NVA Anda.

• Untuk memberikan privasi yang lebih baik, integritas data, dan model komunikasi terkendali, ekspos aplikasi melalui API menggunakan gateway API, seperti Apigee dan Apigee hybrid dengan mTLS end-to-end. Anda juga dapat menggunakan VPC bersama dengan Apigee di resource organisasi yang sama.

• Jika desain solusi Anda mengharuskan eksposur aplikasi berbasis Google Cloud ke internet publik, pertimbangkan rekomendasi desain yang dibahas dalam bagian Networking untuk pengiriman aplikasi yang terhubung ke internet.

• Untuk membantu melindungi layanan Google Cloud di project Anda, dan membantu mengurangi risiko pemindahan data yang tidak sah, gunakan Kontrol Layanan VPC untuk menentukan perimeter layanan di tingkat project atau jaringan VPC. Selain itu, Anda juga dapat memperluas perimeter layanan ke lingkungan hybrid melalui VPN atau Cloud Interconnect resmi. Untuk mengetahui informasi selengkapnya tentang manfaat perimeter layanan, lihat Ringkasan Kontrol Layanan VPC.

• Tinjau praktik terbaik umum untuk pola jaringan hybrid dan multicloud.

Jika Anda ingin menerapkan isolasi yang lebih ketat dan akses yang lebih terperinci antara aplikasi Anda yang dihosting di Google Cloud, dan di lingkungan lain, pertimbangkan untuk menggunakan salah satu pola yang dibatasi yang dibahas dalam dokumen lain dalam seri ini.

Pola dengan akses terbatas

Pola dibatasi didasarkan pada arsitektur yang mengekspos aplikasi dan layanan tertentu secara terperinci, berdasarkan API atau endpoint tertentu yang diekspos di antara lingkungan yang berbeda. Panduan ini mengategorikan pola ini ke dalam tiga kemungkinan opsi, masing-masing ditentukan oleh model komunikasi tertentu:

• Traffic keluar dengan gerbang

• Traffic masuk terbatas

• Traffic keluar dan masuk dengan gerbang (dengan gerbang dua arah di kedua arah)

Seperti yang disebutkan sebelumnya dalam panduan ini, pola arsitektur jaringan yang dijelaskan di sini dapat disesuaikan dengan berbagai aplikasi dengan persyaratan yang beragam. Untuk memenuhi kebutuhan khusus berbagai aplikasi, arsitektur zona landing utama Anda mungkin menggabungkan satu pola atau kombinasi pola secara bersamaan. Deployment spesifik dari arsitektur yang dipilih ditentukan oleh persyaratan komunikasi spesifik untuk setiap pola dengan akses terbatas.

Catatan: Secara umum, pola yang dibatasi dapat diterapkan atau digabungkan dengan opsi desain zona landing yang mengekspos layanan dalam model produsen-konsumen.

Seri ini membahas setiap pola dengan akses terbatas dan kemungkinan opsi desainnya. Namun, salah satu opsi desain umum yang berlaku untuk semua pola dengan akses terbatas adalah Arsitektur Terdistribusi Zero-Trust untuk aplikasi dalam container dengan arsitektur microservice. Opsi ini didukung oleh Cloud Service Mesh, Apigee, dan Apigee Adapter for Envoy, sebuah deployment gateway Apigee yang ringan dalam cluster Kubernetes. Adaptor Apigee untuk Envoy adalah proxy layanan dan edge open source yang populer yang dirancang untuk aplikasi cloud-first. Kontrol arsitektur ini memungkinkan komunikasi antarlayanan yang aman dan arah komunikasi pada tingkat layanan. Kebijakan komunikasi traffic dapat dirancang, disesuaikan, dan diterapkan di tingkat layanan berdasarkan pola yang dipilih.

Pola dengan batasan memungkinkan penerapan Cloud Next Generation Firewall Enterprise dengan intrusion prevention service (IPS) untuk melakukan pemeriksaan paket mendalam guna mencegah ancaman tanpa modifikasi desain atau pemilihan rute. Pemeriksaan tersebut bergantung pada aplikasi tertentu yang diakses, model komunikasi, dan persyaratan keamanan. Jika persyaratan keamanan menuntut Lapisan 7 dan pemeriksaan paket mendalam dengan mekanisme firewall lanjutan yang melebihi kemampuan Firewall Cloud Next Generation, Anda dapat menggunakan firewall generasi berikutnya (NGFW) terpusat yang dihosting di peralatan virtual jaringan (NVA). Beberapa partner keamanan Google Cloud menawarkan peralatan NGFW yang dapat memenuhi persyaratan keamanan Anda. Integrasi NVA dengan pola terbatas ini dapat memerlukan pengenalan beberapa zona keamanan dalam desain jaringan, masing-masing dengan tingkat kontrol akses yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Peralatan jaringan terpusat di Google Cloud.

Traffic keluar dengan akses terbatas

Arsitektur pola jaringan gated egress didasarkan pada mengekspos API tertentu dari lingkungan lokal atau lingkungan cloud lain ke workload yang di-deploy di Google Cloud. Hal ini dilakukan tanpa mengeksposnya secara langsung ke internet publik dari lingkungan lokal atau dari lingkungan cloud lainnya. Anda dapat memfasilitasi eksposur terbatas ini melalui gateway atau proxy API, atau load balancer yang berfungsi sebagai fasilitas untuk workload yang ada. Anda dapat men-deploy fungsi gateway API di segmen jaringan perimeter terisolasi, seperti jaringan perimeter.

Pola jaringan traffic keluar yang dibatasi terutama berlaku pada (tetapi tidak terbatas pada) pola arsitektur aplikasi bertingkat dan pola arsitektur aplikasi berpartisi. Saat men-deploy workload backend dalam jaringan internal, jaringan keluar dengan gerbang membantu mempertahankan tingkat keamanan yang lebih tinggi dalam lingkungan komputasi lokal Anda. Pola ini mengharuskan Anda menghubungkan lingkungan komputasi dengan cara yang memenuhi persyaratan komunikasi berikut:

• Workload yang Anda deploy di Google Cloud dapat berkomunikasi dengan gateway API atau load balancer (atau endpoint Private Service Connect) yang mengekspos aplikasi dengan menggunakan alamat IP internal.
• Sistem lain di lingkungan private computing tidak dapat dijangkau langsung dari dalam Google Cloud.
• Komunikasi dari lingkungan komputasi pribadi ke workload apa pun yang di-deploy di Google Cloud tidak diizinkan.
• Traffic ke API pribadi di lingkungan lain hanya dimulai dari dalam lingkungan Google Cloud.

Fokus panduan ini adalah pada lingkungan hybrid dan multicloud yang terhubung melalui jaringan hybrid pribadi. Jika persyaratan keamanan organisasi Anda mengizinkannya, panggilan API ke API target jarak jauh dengan alamat IP publik dapat langsung dijangkau melalui internet. Namun, Anda harus mempertimbangkan mekanisme keamanan berikut:

• API OAuth 2.0 dengan Transport Layer Security (TLS).
• Pembatasan kapasitas.
• Kebijakan perlindungan ancaman.
• Mutual TLS dikonfigurasi ke backend lapisan API Anda.
• Pemfilteran daftar alamat IP yang diizinkan dikonfigurasi untuk hanya mengizinkan komunikasi dengan sumber dan tujuan API yang telah ditetapkan dari kedua sisi.

Untuk mengamankan proxy API, pertimbangkan aspek keamanan lainnya berikut. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk mengamankan aplikasi dan API Anda menggunakan Apigee.

Arsitektur

Diagram berikut menunjukkan arsitektur referensi yang mendukung persyaratan komunikasi yang tercantum di bagian sebelumnya:

Data mengalir melalui diagram sebelumnya sebagai berikut:

• Di sisi Google Cloud, Anda dapat men-deploy workload ke virtual private cloud (VPC). VPC dapat berupa satu atau beberapa (bersama atau tidak bersama). Deployment harus selaras dengan project dan desain hierarki resource organisasi Anda.
• Jaringan VPC lingkungan Google Cloud diperluas ke lingkungan komputasi lainnya. Lingkungan dapat berada di infrastruktur lokal atau di cloud lain. Untuk memfasilitasi komunikasi antarlingkungan menggunakan alamat IP internal, gunakan konektivitas jaringan hybrid dan multicloud yang sesuai.

• Untuk membatasi traffic yang berasal dari alamat IP VPC tertentu dan ditujukan untuk gateway atau load balancer jarak jauh, gunakan pemfilteran daftar alamat IP yang diizinkan. Traffic yang ditampilkan dari koneksi ini diizinkan jika menggunakan aturan firewall stateful. Anda dapat menggunakan kombinasi apa pun dari kemampuan berikut untuk mengamankan dan membatasi komunikasi hanya ke alamat IP sumber dan tujuan yang diizinkan:

  • Aturan firewall atau kebijakan firewall.

  • Alat virtual jaringan (NVA) dengan kemampuan pemeriksaan firewall (NGFW) generasi berikutnya yang ditempatkan di jalur jaringan.

  • Cloud Next Generation Firewall Enterprise dengan Intrusion Prevention Service (IPS) guna mengimplementasikan pemeriksaan paket mendalam untuk pencegahan ancaman.

• Semua lingkungan berbagi ruang alamat IP RFC 1918 bebas tumpang-tindih.

Variasi

Pola arsitektur traffic keluar yang dibatasi dapat digabungkan dengan pendekatan lain untuk memenuhi berbagai persyaratan desain yang masih mempertimbangkan persyaratan komunikasi pola ini. Pola ini menawarkan opsi berikut:

• Menggunakan gateway Google Cloud API dan frontend global
• Mengekspos layanan jarak jauh menggunakan Private Service Connect

Gunakan gateway Google Cloud API dan frontend global

Dengan pendekatan desain ini, eksposur dan pengelolaan API berada dalam Google Cloud. Seperti yang ditunjukkan dalam diagram sebelumnya, Anda dapat melakukannya melalui implementasi Apigee sebagai platform API. Keputusan untuk men-deploy gateway API atau load balancer di lingkungan jarak jauh bergantung pada kebutuhan khusus dan konfigurasi Anda saat ini. Apigee menyediakan dua opsi untuk penyediaan konektivitas:

• Dengan peering VPC
• Tanpa peering VPC

Kemampuan frontend global Google Cloud seperti Cloud Load Balancing, Cloud CDN (jika diakses melalui Cloud Interconnect), dan Cross-Cloud Interconnect meningkatkan kecepatan akses pengguna ke aplikasi yang memiliki backend yang dihosting di lingkungan lokal Anda dan di lingkungan cloud lainnya.

Kecepatan pengiriman konten dapat dioptimalkan dengan mengirimkan aplikasi tersebut dari titik kehadiran (PoP) Google Cloud. PoP Google Cloud ada di lebih dari 180 pertukaran internet dan di lebih dari 160 fasilitas interkoneksi di seluruh dunia.

Untuk melihat cara PoP membantu menghasilkan API berperforma tinggi saat menggunakan Apigee dengan Cloud CDN untuk melakukan hal berikut, tonton Menghadirkan API berperforma tinggi dengan Apigee dan Cloud CDN di YouTube:

• Mengurangi latensi.
• Menghosting API secara global.
• Meningkatkan ketersediaan untuk traffic puncak.

Contoh desain yang diilustrasikan dalam diagram sebelumnya didasarkan pada Private Service Connect tanpa peering VPC.

Jaringan arah utara dalam desain ini dibangun melalui:

• Load balancer (LB dalam diagram), tempat permintaan klien dihentikan, memproses traffic, lalu merutekannya ke backend Private Service Connect.
• Backend Private Service Connect memungkinkan load balancer Google Cloud mengirimkan permintaan klien melalui koneksi Private Service Connect yang terkait dengan lampiran layanan produsen ke layanan yang dipublikasikan (instance runtime Apigee) menggunakan grup endpoint jaringan (NEG) jaringan Private Service Connect.

Jaringan selatan dibangun melalui:

• Endpoint Private Service Connect yang mereferensikan lampiran layanan yang terkait dengan load balancer internal (ILB dalam diagram) di VPC pelanggan.

• ILB di-deploy dengan grup endpoint jaringan konektivitas hybrid (NEG konektivitas hybrid).

• Layanan hybrid diakses melalui NEG konektivitas hybrid melalui konektivitas jaringan hybrid, seperti VPN atau Cloud Interconnect.

Untuk mengetahui informasi selengkapnya, baca artikel Menyiapkan Load Balancer Jaringan proxy internal regional dengan konektivitas hybrid dan pola deployment Private Service Connect.

Catatan: Bergantung pada persyaratan Anda, API backend lokal dapat diekspos melalui Apigee Hybrid, gateway atau proxy API pihak ketiga, atau load balancer.

Mengekspos layanan jarak jauh menggunakan Private Service Connect

Gunakan opsi Private Service Connect untuk mengekspos layanan jarak jauh untuk skenario berikut:

• Anda tidak menggunakan platform API atau ingin menghindari menghubungkan seluruh jaringan VPC secara langsung ke lingkungan eksternal karena alasan berikut:
  • Anda memiliki batasan keamanan atau persyaratan kepatuhan.
  • Anda memiliki rentang alamat IP yang tumpang-tindih, seperti dalam skenario penggabungan dan akuisisi.
• Untuk memungkinkan komunikasi searah yang aman antara klien, aplikasi, dan layanan di seluruh lingkungan meskipun Anda memiliki batas waktu yang singkat.
• Anda mungkin perlu menyediakan konektivitas ke beberapa VPC konsumen melalui VPC produsen layanan (VPC transit) untuk menawarkan model layanan multi-tenant atau tenant tunggal yang sangat skalabel, guna menjangkau layanan yang dipublikasikan di lingkungan lain.

Penggunaan Private Service Connect untuk aplikasi yang digunakan sebagai API akan memberikan alamat IP internal untuk aplikasi yang dipublikasikan, sehingga memungkinkan akses aman dalam jaringan pribadi di seluruh region dan melalui konektivitas hibrid. Abstraksi ini memfasilitasi integrasi resource dari beragam cloud dan lingkungan lokal melalui model konektivitas hybrid dan multicloud. Anda dapat mempercepat integrasi aplikasi dan mengekspos aplikasi yang berada di lingkungan lokal secara aman atau lingkungan cloud lain menggunakan Private Service Connect untuk memublikasikan layanan dengan akses terperinci. Dalam hal ini, Anda dapat menggunakan opsi berikut:

• Lampiran layanan yang merujuk ke Load Balancer Jaringan proxy internal regional atau Load Balancer Aplikasi internal.
  • Load balancer menggunakan grup endpoint jaringan hybrid (NEG konektivitas hybrid) di VPC produsen yang berfungsi dalam desain ini sebagai VPC transit.

Pada diagram sebelumnya, workload di jaringan VPC aplikasi Anda dapat menjangkau layanan hybrid yang berjalan di lingkungan lokal Anda, atau di lingkungan cloud lain, melalui endpoint Private Service Connect, seperti yang diilustrasikan dalam diagram berikut. Opsi desain untuk komunikasi searah ini memberikan opsi alternatif untuk peering ke VPC transit.

Sebagai bagian dari desain dalam diagram sebelumnya, beberapa frontend, backend, atau endpoint dapat terhubung ke lampiran layanan yang sama, sehingga memungkinkan beberapa jaringan VPC atau beberapa konsumen mengakses layanan yang sama. Seperti dalam diagram berikut, Anda dapat membuat aplikasi dapat diakses oleh beberapa VPC. Aksesibilitas ini dapat membantu dalam skenario layanan multi-tenant saat layanan Anda digunakan oleh beberapa VPC konsumen meskipun rentang alamat IP-nya tumpang tindih.

Tumpang-tindih alamat IP adalah salah satu masalah paling umum saat mengintegrasikan aplikasi yang berada di lingkungan berbeda. Koneksi Private Service Connect dalam diagram berikut membantu menghindari masalah tumpang-tindih alamat IP. Hal ini dilakukan tanpa memerlukan penyediaan atau pengelolaan komponen jaringan tambahan, seperti Cloud NAT atau NVA, untuk melakukan penafsiran alamat IP. Untuk contoh konfigurasi, lihat Memublikasikan layanan hybrid menggunakan Private Service Connect.

Desain ini memiliki kelebihan berikut:

• Menghindari potensi dependensi penskalaan bersama dan pengelolaan yang kompleks dalam skala besar.
• Meningkatkan keamanan dengan menyediakan kontrol konektivitas terperinci.
• Mengurangi koordinasi alamat IP antara produsen dan konsumen layanan serta lingkungan eksternal jarak jauh.

Pendekatan desain dalam diagram sebelumnya dapat diperluas pada tahap selanjutnya untuk mengintegrasikan Apigee sebagai platform API menggunakan opsi desain jaringan yang telah dibahas sebelumnya, termasuk opsi Private Service Connect.

Anda dapat membuat endpoint Private Service Connect dapat diakses dari region lain menggunakan akses global Private Service Connect.

Klien yang terhubung ke endpoint Private Service Connect dapat berada di region yang sama dengan endpoint atau di region yang berbeda. Pendekatan ini dapat digunakan untuk memberikan ketersediaan tinggi di seluruh layanan yang dihosting di beberapa region, atau untuk mengakses layanan yang tersedia di satu region dari region lain. Saat endpoint Private Service Connect diakses oleh resource yang dihosting di region lain, biaya keluar antar-regional berlaku untuk traffic yang ditujukan ke endpoint dengan akses global.

Catatan: Untuk mencapai pemeriksaan kesehatan terdistribusi dan untuk memfasilitasi koneksi beberapa VPC ke lingkungan lokal melalui beberapa koneksi hybrid, rantai Load Balancer Aplikasi internal dengan Load Balancer Aplikasi eksternal. Untuk mengetahui informasi selengkapnya, baca artikel Perang Eksplisit Load Balancer Google Cloud L7 dengan PSC.

Praktik terbaik

• Mempertimbangkan Apigee dan Apigee Hybrid sebagai solusi platform API Anda, dapat memberikan beberapa manfaat. Layanan ini menyediakan lapisan proxy dan abstraksi atau facade untuk API layanan backend yang dikombinasikan dengan kemampuan keamanan, pembatasan kapasitas, kuota, dan analisis.
  • Gunakan Adaptor Apigee untuk Envoy dengan arsitektur deployment Hybrid Apigee dengan Kubernetes jika berlaku untuk persyaratan dan arsitektur Anda.
• VPC dan desain project di Google Cloud harus didorong oleh hierarki resource dan persyaratan model komunikasi yang aman.
• Saat API dengan gateway API digunakan, Anda juga harus menggunakan daftar alamat IP yang diizinkan. Daftar yang diizinkan akan membatasi komunikasi ke sumber alamat IP dan tujuan tertentu dari konsumen API dan gateway API yang mungkin dihosting di lingkungan berbeda.
• Gunakan aturan firewall VPC atau kebijakan firewall untuk mengontrol akses ke resource Private Service Connect melalui endpoint Private Service Connect.
• Jika aplikasi diekspos secara eksternal melalui load balancer aplikasi, pertimbangkan untuk menggunakan Google Cloud Armor sebagai lapisan keamanan tambahan untuk melindungi dari DDoS dan ancaman keamanan lapisan aplikasi.

• Jika instance memerlukan akses internet, gunakan Cloud NAT di VPC aplikasi (konsumen) agar workload dapat mengakses internet. Dengan begitu, Anda dapat menghindari penetapan instance VM dengan alamat IP publik eksternal dalam sistem yang di-deploy di belakang gateway API atau load balancer.

  • Untuk traffic web keluar, Anda dapat menggunakan Proxy Web Aman Google Cloud. Proxy ini menawarkan sejumlah manfaat.

• Tinjau praktik terbaik umum untuk pola jaringan hybrid dan multicloud.

Traffic masuk dengan akses terbatas

Arsitektur pola gated ingress didasarkan pada mengekspos API workload tertentu yang berjalan di Google Cloud ke lingkungan komputasi pribadi tanpa mengeksposnya ke internet publik. Pola ini adalah kebalikan dari pola traffic keluar, dan sangat cocok untuk skenario edge hybrid, tiered hybrid, dan cloud yang dipartisi.

Seperti halnya pola traffic keluar dengan akses terbatas, Anda dapat memfasilitasi eksposur terbatas ini melalui gateway API atau load balancer yang berfungsi sebagai fasad untuk workload atau layanan yang ada. Hal tersebut akan membuatnya dapat diakses oleh lingkungan komputasi pribadi, lingkungan lokal, atau di lingkungan cloud lainnya, sebagai berikut:

• Workload yang Anda deploy di lingkungan komputasi pribadi atau lingkungan cloud lainnya dapat berkomunikasi dengan gateway API atau load balancer dengan menggunakan alamat IP internal. Sistem lain yang di-deploy di Google Cloud tidak dapat dijangkau.
• Komunikasi dari Google Cloud ke lingkungan komputasi pribadi atau ke lingkungan cloud lainnya tidak diizinkan. Traffic hanya dimulai dari lingkungan pribadi atau lingkungan cloud lainnya ke API di Google Cloud.

Arsitektur

Diagram berikut menunjukkan arsitektur referensi yang memenuhi persyaratan pola masuk dengan akses terbatas.

Deskripsi arsitektur dalam diagram sebelumnya adalah sebagai berikut:

• Di sisi Google Cloud, Anda men-deploy workload ke satu VPC aplikasi (atau beberapa VPC).
• Jaringan lingkungan Google Cloud dapat diperluas ke lingkungan komputasi lainnya (lokal atau di cloud lainnya) dengan menggunakan konektivitas jaringan hybrid atau multicloud untuk memfasilitasi komunikasi antar lingkungan.
• Secara opsional, Anda dapat menggunakan VPC transit untuk melakukan hal berikut:
  • Berikan lapisan keamanan perimeter tambahan untuk mengizinkan akses ke API tertentu di luar VPC aplikasi Anda.
  • Rutekan traffic ke alamat IP API. Anda dapat membuat aturan firewall VPC untuk mencegah beberapa sumber mengakses API tertentu melalui endpoint.
  • Memeriksa traffic Lapisan 7 di VPC transit dengan mengintegrasikan alat virtual (NVA) jaringan.
• Akses API melalui gateway API atau load balancer (load balancer proxy atau aplikasi) untuk menyediakan lapisan proxy, dan lapisan abstraksi atau fasad untuk API layanan Anda. Jika perlu mendistribusikan traffic di beberapa instance gateway API, Anda dapat menggunakan Load Balancer Jaringan passthrough internal.
• Berikan akses terbatas dan terperinci ke layanan yang dipublikasikan melalui endpoint Private Service Connect dengan menggunakan load balancer melalui Private Service Connect untuk mengekspos aplikasi atau layanan.
• Semua lingkungan harus menggunakan ruang alamat IP RFC 1918 bebas tumpang-tindih.

Diagram berikut mengilustrasikan desain pola ini menggunakan Apigee sebagai platform API.

Pada diagram sebelumnya, penggunaan Apigee sebagai platform API memberikan fitur dan kemampuan berikut untuk mengaktifkan pola gated ingress:

• Fungsi proxy atau gateway
• Kemampuan keamanan
• Pembatasan kapasitas
• Analisis

Dalam desain:

• Konektivitas jaringan yang menuju ke utara (untuk traffic yang berasal dari lingkungan lain) melewati endpoint Private Service Connect di VPC aplikasi Anda yang terkait dengan VPC Apigee.
• Di VPC aplikasi, load balancer internal digunakan untuk mengekspos API aplikasi melalui endpoint Private Service Connect yang disajikan di VPC Apigee. Untuk informasi selengkapnya, lihat Arsitektur dengan peering VPC dinonaktifkan.

• Mengonfigurasi aturan firewall dan pemfilteran traffic di VPC aplikasi. Tindakan ini akan memberikan akses yang mendetail dan terkontrol. Hal ini juga membantu menghentikan sistem agar tidak langsung menjangkau aplikasi Anda tanpa melewati endpoint Private Service Connect dan gateway API.

  Selain itu, Anda juga dapat membatasi iklan subnet alamat IP internal dari workload backend di VPC aplikasi ke jaringan lokal untuk menghindari keterjangkauan langsung tanpa melewati endpoint Private Service Connect dan gateway API.

Persyaratan keamanan tertentu mungkin memerlukan pemeriksaan keamanan perimeter di luar VPC aplikasi, termasuk traffic konektivitas hybrid. Dalam kasus semacam ini, Anda dapat menyertakan VPC transit untuk menerapkan lapisan keamanan tambahan. Lapisan ini, seperti NVA firewall generasi berikutnya (NGFW) dengan beberapa antarmuka jaringan, atau Cloud Next Generation Firewall Enterprise dengan intrusion prevention service (IPS), melakukan pemeriksaan paket mendalam di luar VPC aplikasi Anda, seperti yang diilustrasikan dalam diagram berikut:

Seperti yang digambarkan dalam diagram sebelumnya:

• Konektivitas jaringan yang menuju ke utara (untuk traffic yang berasal dari lingkungan lain) melewati VPC transit terpisah menuju endpoint Private Service Connect di VPC transit yang terkait dengan VPC Apigee.
• Di VPC aplikasi, load balancer internal (ILB dalam diagram) digunakan untuk mengekspos aplikasi melalui endpoint Private Service Connect di Apigee VPC.

Anda dapat menyediakan beberapa endpoint di jaringan VPC yang sama, seperti yang ditunjukkan pada diagram berikut. Untuk mencakup berbagai kasus penggunaan, Anda dapat mengontrol berbagai kemungkinan jalur jaringan menggunakan Cloud Router dan aturan firewall VPC. Misalnya, jika Anda menghubungkan jaringan lokal ke Google Cloud menggunakan beberapa koneksi jaringan hybrid, Anda dapat mengirim sebagian traffic dari infrastruktur lokal ke Google API spesifik atau layanan yang dipublikasikan melalui satu koneksi dan sisanya melalui koneksi lain. Selain itu, Anda dapat menggunakan akses global Private Service Connect untuk memberikan opsi failover.

Variasi

Pola arsitektur masuk dengan akses terbatas dapat digabungkan dengan pendekatan lain untuk memenuhi persyaratan desain yang berbeda, sambil tetap mempertimbangkan persyaratan komunikasi pola tersebut. Pola ini menawarkan opsi berikut:

• Mengakses Google API dari lingkungan lain

• Mengekspos backend aplikasi ke lingkungan lain menggunakan Private Service Connect

• Menggunakan arsitektur hub dan spoke untuk mengekspos backend aplikasi ke lingkungan lain

Mengakses Google API dari lingkungan lain

Untuk skenario yang memerlukan akses ke layanan Google, seperti Cloud Storage atau BigQuery, tanpa mengirim traffic melalui internet publik, Private Service Connect menawarkan solusinya. Seperti yang ditunjukkan dalam diagram berikut, konfigurasi ini memungkinkan keterjangkauan ke Google API yang didukung dan layanan (termasuk Google Maps, Google Ads, dan Google Cloud) dari lingkungan lokal atau cloud lainnya melalui koneksi jaringan hybrid menggunakan alamat IP endpoint Private Service Connect. Untuk mengetahui informasi selengkapnya tentang mengakses Google API melalui endpoint Private Service Connect, lihat Tentang mengakses Google API melalui endpoint.

Pada diagram sebelumnya, jaringan lokal Anda harus terhubung ke jaringan VPC transit (konsumen) menggunakan tunnel Cloud VPN atau lampiran VLAN Cloud Interconnect.

Google API dapat diakses menggunakan endpoint atau backend. Dengan Endpoint, Anda dapat menargetkan sepaket Google API. Dengan backend, Anda dapat menargetkan Google API regional tertentu.

Catatan: Endpoint Private Service Connect terdaftar di Direktori Layanan untuk Google API tempat Anda dapat menyimpan, mengelola, dan memublikasikan layanan.

Mengekspos backend aplikasi ke lingkungan lain menggunakan Private Service Connect

Dalam skenario tertentu, seperti yang ditandai oleh pola hibrida bertingkat, Anda mungkin perlu men-deploy backend di Google Cloud sambil mempertahankan frontend di lingkungan komputasi pribadi. Meskipun kurang umum, pendekatan ini berlaku saat menangani frontend monolitik berat yang mungkin mengandalkan komponen lama. Atau, yang lebih umum, saat mengelola aplikasi terdistribusi di berbagai lingkungan, termasuk cloud lokal dan cloud lainnya, yang memerlukan konektivitas ke backend yang dihosting di Google Cloud melalui jaringan hybrid.

Dalam arsitektur seperti ini, Anda dapat menggunakan gateway API lokal atau load balancer di lingkungan lokal pribadi, atau lingkungan cloud lainnya, untuk langsung mengekspos frontend aplikasi ke internet publik. Penggunaan Private Service Connect di Google Cloud memfasilitasi konektivitas pribadi ke backend yang diekspos melalui endpoint Private Service Connect, idealnya menggunakan API yang telah ditetapkan, seperti yang diilustrasikan dalam diagram berikut:

Desain pada diagram sebelumnya menggunakan deployment Apigee Hybrid yang terdiri dari bidang pengelolaan di Google Cloud dan bidang runtime yang dihosting di lingkungan Anda yang lain. Anda dapat menginstal dan mengelola bidang runtime pada gateway API terdistribusi pada salah satu platform Kubernetes yang didukung di lingkungan lokal Anda atau di lingkungan cloud lainnya. Berdasarkan persyaratan Anda untuk workload terdistribusi di Google Cloud dan lingkungan lainnya, Anda dapat menggunakan Apigee di Google Cloud dengan Apigee Hybrid. Untuk mengetahui informasi selengkapnya, lihat Gateway API terdistribusi.

Menggunakan arsitektur hub dan spoke untuk mengekspos backend aplikasi ke lingkungan lain

Dalam skenario tertentu, mengekspos API dari backend aplikasi yang dihosting di Google Cloud pada berbagai jaringan VPC. Seperti yang digambarkan dalam diagram berikut, VPC hub berfungsi sebagai titik pusat interkoneksi untuk berbagai VPC (jari-jari), yang memungkinkan komunikasi yang aman melalui konektivitas hybrid pribadi. Secara opsional, kemampuan gateway API lokal di lingkungan lain, seperti Apigee Hybrid, dapat digunakan untuk menghentikan permintaan klien secara lokal tempat frontend aplikasi dihosting.

Seperti yang digambarkan dalam diagram sebelumnya:

• Untuk memberikan kemampuan pemeriksaan NGFW Lapisan 7 tambahan, NVA dengan kemampuan NGFW terintegrasi secara opsional dengan desain. Anda mungkin memerlukan kemampuan ini untuk mematuhi persyaratan keamanan tertentu dan standar kebijakan keamanan organisasi Anda.

• Desain ini mengasumsikan bahwa VPC TalkBack tidak memerlukan komunikasi VPC langsung ke VPC.

  • Jika komunikasi speech-to-spoke diperlukan, Anda dapat menggunakan NVA untuk memfasilitasi komunikasi tersebut.
  • Jika memiliki backend berbeda di VPC yang berbeda, Anda dapat menggunakan Private Service Connect untuk mengekspos backend ini ke VPC Apigee.
  • Jika peering VPC digunakan untuk konektivitas menuju utara dan selatan antara VPC spoke dan VPC hub, Anda perlu mempertimbangkan batasan transitivitas jaringan VPC melalui peering VPC. Untuk mengatasi keterbatasan ini, Anda dapat menggunakan salah satu opsi berikut:
    • Untuk menghubungkan VPC, gunakan NVA.
    • Jika memungkinkan, pertimbangkan model Private Service Connect.
    • Untuk membangun konektivitas antara VPC Apigee dan backend yang berada di project Google Cloud lain di organisasi yang sama tanpa komponen jaringan tambahan, gunakan VPC Bersama.

• Jika NVA diperlukan untuk pemeriksaan traffic, termasuk traffic dari lingkungan lain, konektivitas hybrid ke lingkungan lokal atau lingkungan cloud lainnya harus dihentikan di VPC transportasi umum.

• Jika desainnya tidak menyertakan NVA, Anda dapat menghentikan konektivitas hibrid di VPC hub.

• Jika fungsi load balancing atau kemampuan keamanan tertentu diperlukan, seperti menambahkan perlindungan DDoS atau WAF Google Cloud Armor, Anda dapat memilih untuk men-deploy Load Balancer Aplikasi eksternal di perimeter melalui VPC eksternal sebelum merutekan permintaan klien eksternal ke backend.

Praktik terbaik

• Jika permintaan klien dari internet perlu diterima secara lokal oleh frontend yang dihosting di lingkungan lokal pribadi atau lingkungan cloud lainnya, pertimbangkan untuk menggunakan Apigee Hybrid sebagai solusi gateway API. Pendekatan ini juga memfasilitasi migrasi solusi yang lancar ke lingkungan yang sepenuhnya dihosting Google Cloud sambil menjaga konsistensi platform API (Apigee).
• Gunakan Adaptor Apigee untuk Envoy dengan arsitektur deployment Hybrid Apigee dengan Kubernetes jika berlaku untuk persyaratan dan arsitektur Anda.
• Desain VPC dan project di Google Cloud harus mengikuti hierarki resource dan persyaratan model komunikasi yang aman, seperti yang dijelaskan dalam panduan ini.
• Penggabungan VPC transit ke dalam desain ini memberikan fleksibilitas untuk menyediakan tindakan keamanan perimeter tambahan dan konektivitas hybrid di luar VPC workload.
• Gunakan Private Service Connect untuk mengakses Google API dan layanan Google dari lingkungan lokal atau lingkungan cloud lainnya menggunakan alamat IP internal endpoint melalui jaringan konektivitas hybrid. Untuk informasi selengkapnya, lihat Mengakses endpoint dari host lokal.
• Untuk membantu melindungi layanan Google Cloud di project Anda dan membantu mengurangi risiko pemindahan data yang tidak sah, gunakan Kontrol Layanan VPC untuk menentukan perimeter layanan di tingkat project atau jaringan VPC.
  • Jika diperlukan, Anda dapat memperluas perimeter layanan ke lingkungan hybrid melalui VPN atau Cloud Interconnect. Untuk mengetahui informasi lebih lanjut tentang manfaat perimeter layanan, lihat Ringkasan Kontrol Layanan VPC.
• Gunakan aturan firewall VPC atau kebijakan firewall untuk mengontrol akses tingkat jaringan ke resource Private Service Connect melalui endpoint Private Service Connect. Misalnya, aturan firewall keluar di VPC aplikasi (konsumen) dapat membatasi akses dari instance VM ke alamat IP atau subnet endpoint Anda. Untuk mengetahui informasi selengkapnya tentang aturan firewall VPC secara umum, lihat Aturan firewall VPC.
• Saat mendesain solusi yang menyertakan NVA, penting untuk mempertimbangkan ketersediaan tinggi (HA) NVA untuk menghindari titik tunggal kegagalan yang dapat memblokir semua komunikasi. Ikuti panduan desain dan penerapan HA dan redundansi yang disediakan oleh vendor NVA. Untuk mengetahui informasi selengkapnya, tentang mencapai ketersediaan tinggi di antara peralatan virtual, lihat bagian Opsi arsitektur pada Peralatan jaringan terpusat di Google Cloud.
• Untuk memperkuat keamanan perimeter dan mengamankan gateway API Anda yang di-deploy di lingkungan masing-masing, Anda dapat memilih untuk menerapkan mekanisme load balancing dan firewall aplikasi web di lingkungan komputasi Anda yang lain (hybrid atau cloud lainnya). Terapkan opsi ini di jaringan perimeter yang terhubung langsung ke internet.
• Jika instance memerlukan akses internet, gunakan Cloud NAT di VPC aplikasi untuk mengizinkan beban kerja mengakses internet. Dengan begitu, Anda dapat menghindari penetapan instance VM dengan alamat IP publik eksternal dalam sistem yang di-deploy di belakang gateway API atau load balancer.

• Untuk traffic web keluar, gunakan Proxy Web Aman. Proxy ini menawarkan sejumlah manfaat.

• Tinjau praktik terbaik umum untuk pola jaringan hybrid dan multicloud.

Traffic keluar dan masuk dengan akses terbatas

Pola traffic keluar dan masuk dengan akses terbatas menggunakan kombinasi traffic masuk dengan akses terbatas dan akses masuk terbatas untuk skenario yang mengharuskan penggunaan dua arah API yang dipilih antar-beban kerja. Workload dapat berjalan di Google Cloud, di lingkungan lokal pribadi, atau di lingkungan cloud lainnya. Dalam pola ini, Anda dapat menggunakan gateway API, endpoint Private Service Connect, atau load balancer untuk mengekspos API tertentu dan secara opsional menyediakan autentikasi, otorisasi, serta audit panggilan API.

Perbedaan utama antara pola ini dan pola mesh terletak pada penerapannya pada skenario yang hanya memerlukan penggunaan API dua arah atau komunikasi dengan sumber alamat IP dan tujuan tertentu—misalnya, aplikasi yang dipublikasikan melalui endpoint Private Service Connect. Karena komunikasi dibatasi untuk API yang diekspos atau alamat IP tertentu, jaringan di seluruh lingkungan tidak perlu diselaraskan dalam desain Anda. Skenario umum yang berlaku mencakup, tetapi tidak terbatas pada, hal berikut:

• Merger dan akuisisi.
• Integrasi aplikasi dengan partner.
• Integrasi antara aplikasi dan layanan organisasi dengan berbagai unit organisasi yang mengelola aplikasi mereka sendiri dan menghostingnya di lingkungan berbeda.

Komunikasinya berjalan sebagai berikut:

• Workload yang Anda deploy di Google Cloud dapat berkomunikasi dengan gateway API (atau alamat IP tujuan tertentu) menggunakan alamat IP internal. Sistem lain yang di-deploy di lingkungan cloud computing tidak dapat dijangkau.
• Sebaliknya, workload yang Anda deploy di lingkungan komputasi lain dapat berkomunikasi dengan gateway API sisi Google Cloud (atau alamat IP endpoint spesifik yang dipublikasikan) menggunakan alamat IP internal. Sistem lain yang di-deploy di Google Cloud tidak dapat dijangkau.

Arsitektur

Diagram berikut menunjukkan arsitektur referensi untuk pola traffic keluar dengan akses terbatas dan pola traffic masuk dengan gerbang:

Pendekatan desain dalam diagram sebelumnya memiliki elemen-elemen berikut:

• Di sisi Google Cloud, Anda men-deploy workload di VPC (atau VPC bersama) tanpa mengeksposnya langsung ke internet.
• Jaringan lingkungan Google Cloud diperluas ke lingkungan komputasi lainnya. Lingkungan tersebut dapat berada di infrastruktur lokal atau di cloud lain. Untuk memperluas lingkungan, gunakan pola komunikasi konektivitas hybrid dan multicloud yang sesuai untuk memfasilitasi komunikasi antarlingkungan, sehingga keduanya dapat menggunakan alamat IP internal.
• Secara opsional, dengan mengaktifkan akses ke alamat IP target tertentu, Anda dapat menggunakan VPC transit untuk membantu menambahkan lapisan keamanan perimeter di luar VPC aplikasi.
  • Anda dapat menggunakan Firewall atau peralatan virtual jaringan (NVA) Cloud Next Generation dengan firewall generasi berikutnya (NGFW) di VPC transit untuk memeriksa traffic dan untuk mengizinkan atau melarang akses ke API tertentu dari sumber tertentu sebelum mencapai VPC aplikasi Anda.
• API harus diakses melalui gateway API atau load balancer untuk menyediakan lapisan proxy, dan abstraksi atau fasad untuk API layanan Anda.
• Untuk aplikasi yang digunakan sebagai API, Anda juga dapat menggunakan Private Service Connect guna memberikan alamat IP internal untuk aplikasi yang dipublikasikan.
• Semua lingkungan menggunakan ruang alamat IP RFC 1918 bebas tumpang-tindih.

Penerapan umum dari pola ini melibatkan deployment backend aplikasi (atau subset backend aplikasi) di Google Cloud saat menghosting komponen backend dan frontend lainnya di lingkungan lokal atau di cloud lainnya (pola hibrida bertingkat atau pola multicloud berpartisi). Seiring aplikasi berkembang dan bermigrasi ke cloud, dependensi dan preferensi untuk layanan cloud tertentu sering kali muncul.

Terkadang, dependensi dan preferensi ini menyebabkan distribusi aplikasi dan backend di berbagai penyedia cloud. Selain itu, beberapa aplikasi mungkin di-build dengan kombinasi resource dan layanan yang didistribusikan di seluruh lingkungan lokal dan beberapa lingkungan cloud.

Untuk aplikasi terdistribusi, kemampuan konektivitas hybrid dan multicloud Cloud Load Balancing eksternal dapat digunakan untuk menghentikan permintaan pengguna dan merutekannya ke frontend atau backend di lingkungan lain. Pemilihan rute ini terjadi melalui koneksi jaringan hybrid, seperti yang diilustrasikan dalam diagram berikut. Integrasi ini memungkinkan distribusi komponen aplikasi secara bertahap di berbagai lingkungan. Permintaan dari frontend ke layanan backend yang dihosting di Google Cloud berkomunikasi dengan aman melalui koneksi jaringan hybrid yang sudah dibuat yang difasilitasi oleh load balancer internal (ILB dalam diagram).

Penggunaan desain Google Cloud dalam diagram sebelumnya akan membantu hal-hal berikut:

• Memfasilitasi komunikasi dua arah antara Google Cloud, lokal, dan lingkungan cloud lainnya menggunakan API yang telah ditetapkan di kedua sisi yang selaras dengan model komunikasi pola ini.
• Guna menyediakan frontend global untuk aplikasi yang terhubung ke internet dengan komponen aplikasi terdistribusi (frontend atau backend), dan untuk mencapai sasaran berikut, Anda dapat menggunakan kemampuan keamanan dan load balancing lanjutan dari Google Cloud yang didistribusikan di titik kehadiran (PoP):
• Kurangi biaya modal dan sederhanakan operasi dengan menggunakan layanan terkelola serverless.
• Optimalkan koneksi ke backend aplikasi secara global untuk mendapatkan kecepatan dan latensi.
  • Jaringan Lintas Cloud Google Cloud memungkinkan komunikasi multicloud antara komponen aplikasi melalui koneksi pribadi yang optimal.
• Simpan konten statis dengan permintaan tinggi dan tingkatkan performa aplikasi untuk aplikasi menggunakan Cloud Load Balancing global dengan memberikan akses ke Cloud CDN.
• Amankan frontend global dari aplikasi yang terhubung ke internet menggunakan kapabilitas Google Cloud Armor yang menyediakan firewall aplikasi web (WAF) dan layanan mitigasi DDoS (WAF) yang terdistribusi secara global.
• Secara opsional, Anda dapat menyertakan Private Service Connect ke dalam desain Anda. Tindakan ini akan memungkinkan akses pribadi dan terperinci ke Google Cloud Service API atau layanan yang Anda publikasikan dari lingkungan lain tanpa perlu melewati internet publik.

Variasi

Pola arsitektur traffic keluar dan masuk dengan akses terbatas dapat digabungkan dengan pendekatan lain untuk memenuhi persyaratan desain yang berbeda, sambil tetap mempertimbangkan persyaratan komunikasi pola ini. Pola tersebut menawarkan opsi berikut:

• Gateway API terdistribusi
• Komunikasi API dua arah menggunakan Private Service Connect
• Komunikasi dua arah menggunakan endpoint dan antarmuka Private Service Connect

Gateway API terdistribusi

Dalam skenario seperti yang didasarkan pada pola cloud berpartisi, aplikasi (atau komponen aplikasi) dapat dibangun di berbagai lingkungan cloud, termasuk lingkungan lokal pribadi. Persyaratan umumnya adalah mengarahkan permintaan klien ke frontend aplikasi secara langsung ke lingkungan tempat aplikasi (atau komponen frontend) dihosting. Komunikasi semacam ini memerlukan load balancer lokal atau gateway API. Aplikasi ini dan komponennya mungkin juga memerlukan kemampuan platform API tertentu untuk integrasi.

Diagram berikut menggambarkan bagaimana Apigee dan Apigee Hybrid dirancang untuk memenuhi persyaratan tersebut dengan gateway API yang dilokalkan di setiap lingkungan. Pengelolaan platform API dipusatkan di Google Cloud. Desain ini membantu menerapkan langkah-langkah kontrol akses yang ketat di mana hanya alamat IP yang telah disetujui sebelumnya (API target dan tujuan atau alamat IP endpoint Private Service Connect) yang dapat berkomunikasi antara Google Cloud dan lingkungan lainnya.

Daftar berikut menjelaskan dua jalur komunikasi yang berbeda dalam diagram sebelumnya yang menggunakan gateway API Apigee:

• Permintaan klien tiba di frontend aplikasi secara langsung di lingkungan yang menghosting aplikasi (atau komponen frontend).
• Gateway dan proxy API dalam setiap lingkungan menangani permintaan API klien dan aplikasi dalam arah yang berbeda di beberapa lingkungan.
  • Fungsionalitas gateway API di Google Cloud (Apigee) mengekspos komponen aplikasi (frontend atau backend) yang dihosting di Google Cloud.
  • Fungsionalitas gateway API di lingkungan lain (Hybrid) mengekspos komponen frontend aplikasi (atau backend) yang dihosting di lingkungan tersebut.

Secara opsional, Anda dapat mempertimbangkan untuk menggunakan VPC transit. VPC transit dapat memberikan fleksibilitas untuk memisahkan masalah serta melakukan pemeriksaan keamanan dan konektivitas hybrid dalam jaringan VPC yang terpisah. Dari sudut pandang keterjangkauan alamat IP, VPC transit (tempat konektivitas hybrid terpasang) memfasilitasi persyaratan berikut untuk mempertahankan keterjangkauan end-to-end:

• Alamat IP untuk API target harus diiklankan ke lingkungan lain tempat klien/peminta dihosting.
• Alamat IP untuk host yang perlu berkomunikasi dengan API target harus diberitahukan ke lingkungan tempat API target berada—misalnya, alamat IP pemohon API (klien). Pengecualiannya adalah jika komunikasi terjadi melalui load balancer, proxy, endpoint Private Service Connect, atau instance NAT.

Untuk memperluas konektivitas ke lingkungan jarak jauh, desain ini menggunakan peering VPC langsung dengan kemampuan pertukaran rute pelanggan. Dengan desain ini, permintaan API tertentu yang berasal dari workload yang dihosting dalam VPC aplikasi Google Cloud dapat dirutekan melalui VPC transit. Atau, Anda dapat menggunakan endpoint Private Service Connect di VPC aplikasi yang dikaitkan dengan load balancer dengan backend grup endpoint jaringan hybrid di VPC transit. Penyiapan tersebut dijelaskan di bagian berikutnya: Komunikasi API dua arah menggunakan Private Service Connect.

Komunikasi API dua arah menggunakan Private Service Connect

Terkadang, perusahaan mungkin tidak perlu segera menggunakan gateway API (seperti Apigee), atau mungkin ingin menambahkannya nanti. Namun, mungkin ada persyaratan bisnis untuk mengaktifkan komunikasi dan integrasi antara aplikasi tertentu di lingkungan yang berbeda. Misalnya, jika perusahaan Anda mengakuisisi perusahaan lain, Anda mungkin perlu mengekspos aplikasi tertentu ke perusahaan tersebut. Mereka mungkin perlu mengekspos aplikasi ke perusahaan Anda. Kedua perusahaan mungkin memiliki workload sendiri yang dihosting di lingkungan berbeda (Google Cloud, lokal, atau di cloud lainnya), dan harus menghindari tumpang tindih alamat IP. Dalam hal ini, Anda dapat menggunakan Private Service Connect untuk memfasilitasi komunikasi yang efektif.

Untuk aplikasi yang digunakan sebagai API, Anda juga dapat menggunakan Private Service Connect untuk memberikan alamat pribadi bagi aplikasi yang dipublikasikan, yang memungkinkan akses aman dalam jaringan pribadi di seluruh region dan melalui konektivitas hybrid. Abstraksi ini memfasilitasi integrasi resource dari beragam cloud dan lingkungan lokal melalui model konektivitas hybrid dan multicloud. Cloud SQL juga memungkinkan perakitan aplikasi di seluruh lingkungan multicloud dan lokal. Hal ini dapat memenuhi persyaratan komunikasi yang berbeda, seperti mengintegrasikan aplikasi aman yang tidak menggunakan gateway API atau tidak direncanakan untuk digunakan.

Dengan menggunakan Private Service Connect dengan Cloud Load Balancing, seperti yang ditunjukkan dalam diagram berikut, Anda dapat mencapai dua jalur komunikasi yang berbeda. Setiap jalur dimulai dari arah yang berbeda untuk tujuan konektivitas terpisah, idealnya melalui panggilan API.

• Semua pertimbangan desain dan rekomendasi Private Service Connect yang dibahas dalam panduan ini berlaku untuk desain ini.
• Jika pemeriksaan Lapisan 7 tambahan diperlukan, Anda dapat mengintegrasikan NVA dengan desain ini (di VPC transit).
• Desain ini dapat digunakan dengan atau tanpa gateway API.

Dua jalur konektivitas yang digambarkan dalam diagram sebelumnya mewakili koneksi independen dan tidak menggambarkan komunikasi dua arah dari satu koneksi atau flow.

Komunikasi dua arah menggunakan endpoint dan antarmuka Private Service Connect

Seperti yang dibahas dalam pola gated ingress, salah satu opsi untuk mengaktifkan komunikasi layanan klien adalah dengan menggunakan endpoint Private Service Connect untuk mengekspos layanan di VPC produsen ke VPC konsumen. Konektivitas tersebut dapat diperluas ke lingkungan lokal atau bahkan lingkungan penyedia cloud lainnya melalui konektivitas hybrid. Namun, dalam beberapa skenario, layanan yang dihosting juga dapat memerlukan komunikasi pribadi.

Untuk mengakses layanan tertentu, seperti mengambil data dari sumber data yang dapat dihosting dalam VPC konsumen atau di luarnya, komunikasi pribadi ini dapat dilakukan antara VPC aplikasi (produsen) dan lingkungan jarak jauh, seperti lingkungan lokal.

Dalam skenario seperti ini, antarmuka Private Service Connect memungkinkan instance VM produsen layanan mengakses jaringan konsumen. Hal ini dilakukan dengan membagikan antarmuka jaringan, sambil tetap mempertahankan pemisahan peran produsen dan konsumen. Dengan antarmuka jaringan di VPC konsumen ini, VM aplikasi dapat mengakses resource konsumen seolah-olah berada secara lokal di VPC produsen.

Antarmuka Private Service Connect adalah antarmuka jaringan yang terpasang pada VPC konsumen (transit). Anda dapat menjangkau tujuan eksternal yang dapat dijangkau dari VPC konsumen (transit) tempat antarmuka Private Service Connect terhubung. Oleh karena itu, koneksi ini dapat diperluas ke lingkungan eksternal melalui konektivitas hybrid seperti lingkungan lokal, seperti yang diilustrasikan dalam diagram berikut:

Jika VPC konsumen adalah organisasi atau entitas eksternal, seperti organisasi pihak ketiga, biasanya Anda tidak akan dapat mengamankan komunikasi ke antarmuka Private Service Connect di VPC konsumen. Dalam skenario seperti ini, Anda dapat menentukan kebijakan keamanan di OS tamu VM antarmuka Private Service Connect. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi keamanan untuk antarmuka Private Service Connect. Atau, Anda dapat mempertimbangkan pendekatan alternatif jika pendekatan tersebut tidak mematuhi standar atau kepatuhan keamanan organisasi Anda.

Praktik terbaik

• Jika permintaan klien dari internet harus diterima secara lokal oleh frontend yang dihosting di lingkungan lokal pribadi atau lingkungan cloud lainnya, pertimbangkan untuk menggunakan Hybrid sebagai solusi gateway API.

  • Pendekatan ini juga memfasilitasi migrasi solusi ke lingkungan yang sepenuhnya dihosting Google Cloud sambil mempertahankan konsistensi platform API (Apigee).

• Guna meminimalkan latensi dan mengoptimalkan biaya untuk transfer data keluar dalam volume tinggi ke lingkungan Anda yang lain saat lingkungan tersebut berada dalam konfigurasi hybrid atau multicloud jangka panjang atau permanen, pertimbangkan hal berikut:

  • Menggunakan Cloud Interconnect atau Cross-Cloud Interconnect.
  • Untuk menghentikan koneksi pengguna pada frontend yang ditargetkan di lingkungan yang sesuai, gunakan Hybrid.

• Jika berlaku untuk persyaratan dan arsitektur Anda, gunakan Adaptor Apigee untuk Envoy dengan Deployment hybrid dengan Kubernetes.

• Sebelum mendesain konektivitas dan jalur pemilihan rute, Anda harus terlebih dahulu mengidentifikasi traffic atau permintaan API yang perlu diarahkan ke gateway API lokal atau jarak jauh, beserta lingkungan sumber dan tujuan.

• Gunakan Kontrol Layanan VPC untuk melindungi layanan Google Cloud dalam project Anda dan mengurangi risiko pemindahan data yang tidak sah, dengan menentukan perimeter layanan di tingkat project atau jaringan VPC.

  • Anda dapat memperluas perimeter layanan ke lingkungan hybrid melalui VPN atau Cloud Interconnect resmi. Untuk mengetahui informasi selengkapnya tentang manfaat perimeter layanan, lihat Ringkasan Kontrol Layanan VPC.

• Gunakan aturan firewall Virtual Private Cloud (VPC) atau kebijakan firewall untuk mengontrol akses tingkat jaringan ke resource Private Service Connect melalui endpoint Private Service Connect. Misalnya, aturan firewall keluar di VPC aplikasi (konsumen) dapat membatasi akses dari instance VM ke alamat IP atau subnet endpoint Anda.

• Saat menggunakan antarmuka Private Service Connect, Anda harus melindungi komunikasi ke antarmuka dengan mengonfigurasi keamanan untuk antarmuka Private Service Connect.

• Jika beban kerja di subnet pribadi memerlukan akses internet, gunakan Cloud NAT untuk menghindari penetapan alamat IP eksternal ke workload dan mengeksposnya ke internet publik.

  • Untuk traffic web keluar, gunakan Proxy Web Aman. Proxy ini menawarkan sejumlah manfaat.

• Tinjau praktik terbaik umum untuk pola jaringan hybrid dan multicloud.

Pola serah terima

Dengan pola handover, arsitektur didasarkan pada penggunaan layanan penyimpanan yang disediakan Google Cloud untuk menghubungkan lingkungan komputasi pribadi ke project di Google Cloud. Pola ini berlaku terutama untuk penyiapan yang mengikuti pola arsitektur hybrid multicloud analisis, dengan:

• Workload yang berjalan di lingkungan komputasi pribadi atau di data upload cloud lainnya ke lokasi penyimpanan bersama. Bergantung pada kasus penggunaan, upload dapat terjadi secara massal atau dalam peningkatan yang lebih kecil.
• Workload yang dihosting Google Cloud atau layanan Google lainnya (misalnya, analisis data dan layanan kecerdasan buatan) menggunakan data dari lokasi penyimpanan bersama dan memprosesnya dalam mode streaming atau batch.

Arsitektur

Diagram berikut menunjukkan arsitektur referensi untuk pola serah terima.

Diagram arsitektur sebelumnya menunjukkan alur kerja berikut:

• Di sisi Google Cloud, Anda men-deploy workload ke VPC aplikasi. Workload ini dapat mencakup pemrosesan data, analisis, dan aplikasi frontend terkait analisis.
• Untuk mengekspos aplikasi frontend kepada pengguna dengan aman, Anda dapat menggunakan Cloud Load Balancing atau Gateway API.
• Sekumpulan bucket Cloud Storage atau antrean Pub/Sub mengupload data dari lingkungan komputasi pribadi dan menyediakannya untuk diproses lebih lanjut berdasarkan workload yang di-deploy di Google Cloud. Dengan menggunakan kebijakan Identity and Access Management (IAM), Anda dapat membatasi akses ke workload tepercaya.
• Gunakan Kontrol Layanan VPC untuk membatasi akses ke layanan dan meminimalkan risiko pemindahan data yang tidak sah yang tidak beralasan dari layanan Google Cloud.
• Dalam arsitektur ini, komunikasi dengan bucket Cloud Storage, atau Pub/Sub, dilakukan melalui jaringan publik, atau melalui konektivitas pribadi menggunakan VPN, Cloud Interconnect, atau Cross-Cloud Interconnect. Biasanya, keputusan tentang cara terhubung bergantung pada beberapa aspek, seperti berikut:
  • Volume traffic yang diperkirakan
  • Penyiapan sementara atau permanen
  • Persyaratan keamanan dan kepatuhan

Variasi

Opsi desain yang diuraikan dalam pola gated ingress, yang menggunakan endpoint Private Service Connect untuk Google API, juga dapat diterapkan ke pola ini. Secara khusus, menyediakan akses ke Cloud Storage, BigQuery, dan Google Service API lainnya. Pendekatan ini memerlukan pengalamatan IP pribadi melalui koneksi jaringan hybrid dan multicloud seperti VPN, Cloud Interconnect, dan Cross-Cloud Interconnect.

Praktik terbaik

• Kunci akses ke bucket Cloud Storage dan topik Pub/Sub.
• Jika berlaku, gunakan solusi perpindahan data terintegrasi dan cloud-first seperti rangkaian solusi Google Cloud. Untuk memenuhi kebutuhan kasus penggunaan Anda, solusi ini dirancang untuk memindahkan, mengintegrasikan, dan mengubah data secara efisien.

• Lakukan penilaian terhadap berbagai faktor yang memengaruhi opsi transfer data, seperti biaya, waktu transfer yang diharapkan, dan keamanan. Untuk mengetahui informasi selengkapnya, lihat Mengevaluasi opsi transfer.

• Untuk meminimalkan latensi dan mencegah transfer data dan perpindahan data bervolume tinggi melalui internet publik, pertimbangkan untuk menggunakan Cloud Interconnect atau Cross-Cloud Interconnect, termasuk mengakses endpoint Private Service Connect dalam Virtual Private Cloud untuk Google API.

• Untuk melindungi layanan Google Cloud di project Anda dan mengurangi risiko pemindahan data yang tidak sah, gunakan Kontrol Layanan VPC. Kontrol layanan ini dapat menentukan perimeter layanan di level project atau jaringan VPC.

  • Anda dapat memperluas perimeter layanan ke lingkungan hybrid melalui VPN atau Cloud Interconnect resmi. Untuk mengetahui informasi selengkapnya tentang manfaat perimeter layanan, lihat Ringkasan Kontrol Layanan VPC.

• Berkomunikasi dengan workload analisis data yang dipublikasikan secara publik dan dihosting di instance VM melalui gateway API, load balancer, atau peralatan jaringan virtual. Gunakan salah satu metode komunikasi ini untuk meningkatkan keamanan dan menghindari agar instance ini tidak dapat dijangkau langsung dari internet.

• Jika akses internet diperlukan, Cloud NAT dapat digunakan di VPC yang sama untuk menangani traffic keluar dari instance ke internet publik.

• Tinjau praktik terbaik umum untuk topologi jaringan hybrid dan multicloud.

Praktik terbaik umum

Saat mendesain dan melakukan orientasi identitas cloud, hierarki resource, dan jaringan zona landing, pertimbangkan rekomendasi desain dalam Desain zona landing di Google Cloud dan praktik terbaik keamanan Google Cloud yang tercakup dalam blueprint perusahaan dasar. Validasi desain yang Anda pilih terhadap dokumen berikut:

• Praktik terbaik dan arsitektur referensi untuk desain VPC
• Mendesain infrastruktur jaringan
• Framework Arsitektur Google Cloud: Keamanan, privasi, dan kepatuhan

Selain itu, pertimbangkan praktik terbaik umum berikut:

• Saat memilih opsi konektivitas jaringan hybrid atau multicloud, pertimbangkan persyaratan bisnis dan aplikasi seperti SLA, performa, keamanan, biaya, keandalan, dan bandwidth. Untuk mengetahui informasi selengkapnya, lihat Memilih produk Konektivitas Jaringan dan Pola untuk menghubungkan penyedia layanan cloud lain dengan Google Cloud.

• Gunakan VPC bersama di Google Cloud, bukan beberapa VPC, jika sesuai dan selaras dengan persyaratan desain hierarki resource Anda. Untuk informasi selengkapnya, lihat Memutuskan apakah akan membuat beberapa jaringan VPC.

• Ikuti praktik terbaik untuk merencanakan akun dan organisasi.

• Jika memungkinkan, tetapkan identitas umum antarlingkungan sehingga sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.

• Untuk mengekspos aplikasi ke pengguna perusahaan dengan aman dalam konfigurasi hybrid dan memilih pendekatan yang paling sesuai dengan kebutuhan, Anda harus mengikuti cara yang direkomendasikan untuk mengintegrasikan Google Cloud dengan sistem pengelolaan identitas Anda.

  • Selain itu, lihat Pola untuk mengautentikasi pengguna tenaga kerja di lingkungan hybrid.

• Saat mendesain lingkungan lokal dan cloud, pertimbangkan untuk menggunakan alamat IPv6 sejak dini, dan pertimbangkan layanan mana yang mendukungnya. Untuk mengetahui informasi selengkapnya, lihat Pengantar IPv6 di Google Cloud. Kode ini merangkum layanan yang didukung saat blog ditulis.

• Saat mendesain, men-deploy, dan mengelola aturan firewall VPC, Anda dapat:

  • Gunakan pemfilteran berbasis akun layanan daripada pemfilteran berbasis tag jaringan jika Anda memerlukan kontrol ketat terkait penerapan aturan firewall ke VM.
  • Gunakan kebijakan firewall saat Anda mengelompokkan beberapa aturan firewall, sehingga Anda dapat memperbarui semuanya sekaligus. Anda juga dapat membuat kebijakan hierarkis. Untuk mengetahui detail dan spesifikasi kebijakan firewall hierarki, lihat Kebijakan firewall hierarkis.
  • Gunakan objek geolokasi dalam kebijakan firewall saat Anda perlu memfilter traffic IPv4 eksternal dan IPv6 eksternal berdasarkan lokasi geografis atau region tertentu.
  • Gunakan Threat Intelligence untuk aturan kebijakan firewall jika Anda perlu mengamankan jaringan dengan mengizinkan atau memblokir traffic berdasarkan data Threat Intelligence, seperti alamat IP berbahaya yang diketahui, atau berdasarkan rentang alamat IP cloud publik. Misalnya, Anda dapat mengizinkan traffic dari rentang alamat IP cloud publik tertentu jika layanan Anda hanya perlu berkomunikasi dengan cloud publik tersebut. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk aturan firewall.

• Anda harus selalu merancang keamanan cloud dan jaringan menggunakan pendekatan keamanan berlapis dengan mempertimbangkan lapisan keamanan tambahan, seperti berikut:

  • Google Cloud Armor
  • Cloud Intrusion Detection System
  • IPS Firewall Cloud Next Generation
  • Kecerdasan Ancaman untuk aturan kebijakan firewall

  Lapisan tambahan ini dapat membantu Anda memfilter, memeriksa, dan memantau berbagai macam ancaman di lapisan jaringan dan aplikasi untuk analisis dan pencegahan.

• Saat menentukan resolusi DNS yang harus dilakukan dalam konfigurasi hybrid, sebaiknya gunakan dua sistem DNS otoritatif untuk lingkungan Google Cloud pribadi Anda, dan untuk resource lokal yang dihosting oleh server DNS yang ada di lingkungan lokal Anda. Untuk mengetahui informasi selengkapnya, lihat Memilih tempat resolusi DNS dilakukan.

• Jika memungkinkan, selalu ekspos aplikasi melalui API menggunakan gateway atau load balancer API. Sebaiknya pertimbangkan platform API seperti Apigee. Apigee bertindak sebagai abstraksi atau fasad untuk API layanan backend, yang dikombinasikan dengan kemampuan keamanan, pembatasan kapasitas, kuota, dan analisis.

• Platform API (gateway atau proxy) dan Load Balancer Aplikasi tidak saling eksklusif. Terkadang, penggunaan gateway API dan load balancer secara bersamaan dapat memberikan solusi yang lebih andal dan aman untuk mengelola dan mendistribusikan traffic API dalam skala besar. Dengan gateway Cloud Load Balancing API, Anda dapat melakukan beberapa hal berikut:

  • Kirim API berperforma tinggi dengan Apigee dan Cloud CDN, untuk:

    • Mengurangi latensi
    • Menghosting API secara global

    • Meningkatkan ketersediaan selama musim lalu lintas puncak

      Untuk informasi selengkapnya, tonton Menghadirkan API berperforma tinggi dengan Apigee dan Cloud CDN di YouTube.

  • Terapkan pengelolaan traffic lanjutan.

  • Gunakan Google Cloud Armor sebagai perlindungan terhadap DDoS, WAF, dan layanan keamanan jaringan untuk melindungi API Anda.

  • Kelola load balancing yang efisien di berbagai gateway di berbagai region. Untuk informasi selengkapnya, tonton Securing APIs and Implement multi-region failover with PSC dan Apigee.

• Untuk menentukan produk Cloud Load Balancing yang akan digunakan, Anda harus terlebih dahulu menentukan jenis traffic yang harus ditangani oleh load balancer. Untuk mengetahui informasi selengkapnya, lihat artikel Memilih load balancer.

• Saat Cloud Load Balancing digunakan, Anda harus menggunakan kemampuan pengoptimalan kapasitas aplikasi jika berlaku. Cara ini dapat membantu Anda mengatasi beberapa tantangan kapasitas yang dapat terjadi pada aplikasi yang didistribusikan secara global.

  • Untuk mempelajari latensi secara mendalam, baca artikel Mengoptimalkan latensi aplikasi dengan load balancing.

• Meskipun Cloud VPN mengenkripsi traffic antarlingkungan, dengan Cloud Interconnect, Anda harus menggunakan MACsec atau VPN HA melalui Cloud Interconnect untuk mengenkripsi traffic saat transit di lapisan konektivitas. Untuk mengetahui informasi selengkapnya, baca Cara mengenkripsi traffic melalui Cloud Interconnect.

  • Anda juga dapat mempertimbangkan enkripsi lapisan layanan menggunakan TLS. Untuk mengetahui informasi selengkapnya, lihat Menentukan cara memenuhi persyaratan kepatuhan untuk enkripsi saat transit.

• Jika memerlukan lebih banyak volume traffic melalui konektivitas hybrid VPN daripada yang dapat didukung oleh satu tunnel VPN, Anda dapat mempertimbangkan untuk menggunakan opsi perutean VPN dengan ketersediaan tinggi (HA) aktif/aktif.

  • Untuk penyiapan hybrid atau multicloud jangka panjang dengan volume transfer data keluar yang tinggi, pertimbangkan Cloud Interconnect atau Cross-Cloud Interconnect. Opsi konektivitas tersebut membantu mengoptimalkan performa konektivitas dan dapat mengurangi biaya transfer data keluar untuk traffic yang memenuhi kondisi tertentu. Untuk mengetahui informasi selengkapnya, lihat harga Cloud Interconnect.

• Saat terhubung ke resource Google Cloud dan mencoba memilih antara Cloud Interconnect, Peering Langsung, atau Peering Operator, sebaiknya gunakan Cloud Interconnect, kecuali jika Anda perlu mengakses aplikasi Google Workspace. Untuk mengetahui informasi selengkapnya, Anda dapat membandingkan fitur Peering Langsung dengan Cloud Interconnect dan Peering Operator dengan Cloud Interconnect.

• Berikan ruang alamat IP yang cukup dari ruang alamat IP RFC 1918 Anda yang ada untuk mengakomodasi sistem yang dihosting di cloud.

• Jika memiliki batasan teknis yang mengharuskan Anda mempertahankan rentang alamat IP, Anda dapat:

  • Gunakan alamat IP internal yang sama untuk workload lokal Anda saat memigrasikannya ke Google Cloud, menggunakan subnet hybrid.

  • Sediakan dan gunakan alamat IPv4 publik Anda sendiri untuk resource Google Cloud menggunakan bawa IP Anda sendiri (BYOIP) ke Google.

• Jika desain solusi Anda mengharuskan eksposur aplikasi berbasis Google Cloud ke internet publik, pertimbangkan rekomendasi desain yang dibahas dalam Jaringan untuk pengiriman aplikasi untuk internet.

• Jika berlaku, gunakan endpoint Private Service Connect untuk mengizinkan workload di Google Cloud, infrastruktur lokal, atau di lingkungan cloud lain dengan konektivitas hybrid, untuk mengakses Google API secara pribadi atau layanan yang dipublikasikan, menggunakan alamat IP internal secara terperinci.

• Saat menggunakan Private Service Connect, Anda harus mengontrol hal-hal berikut:

  • Siapa yang dapat men-deploy resource Private Service Connect.
  • Apakah hubungan dapat dibentuk antara konsumen dan produsen.
  • Lalu lintas jaringan mana yang diizinkan untuk mengakses koneksi tersebut.

  Untuk mengetahui informasi selengkapnya, lihat keamanan Private Service Connect.

• Untuk mencapai penyiapan cloud yang andal dalam konteks arsitektur hybrid dan multicloud:

  • Lakukan penilaian komprehensif terhadap tingkat keandalan yang diperlukan dari berbagai aplikasi di seluruh lingkungan. Tindakan ini dapat membantu Anda memenuhi tujuan untuk ketersediaan dan ketahanan.
  • Pahami kemampuan keandalan dan prinsip desain penyedia cloud Anda. Untuk mengetahui informasi selengkapnya, lihat Keandalan infrastruktur Google Cloud.

• Visibilitas dan pemantauan jaringan cloud sangat penting untuk mempertahankan komunikasi yang andal. Network Intelligence Center menyediakan konsol tunggal untuk mengelola visibilitas, pemantauan, dan pemecahan masalah jaringan.

Pola arsitektur jaringan hybrid dan multicloud yang aman: Langkah berikutnya

• Pelajari lebih lanjut pola arsitektur umum yang dapat Anda peroleh dengan menggunakan pola jaringan yang dibahas dalam dokumen ini.
• Pelajari cara menggunakan pendekatan hybrid dan multicloud serta memilih workload yang sesuai.
• Arsitektur load balancing global yang menggunakan kebijakan perutean DNS: Kasus penggunaan untuk kebijakan perutean DNS geolokasi.
• Pelajari lebih lanjut Cross-Cloud Network Google Cloud, yakni platform jaringan global yang terbuka, aman, dan dioptimalkan untuk aplikasi serta pengguna di seluruh infrastruktur lokal dan cloud lainnya.
• Mendesain infrastruktur yang andal untuk workload Anda di Google Cloud: Panduan desain untuk membantu melindungi aplikasi Anda dari kegagalan di tingkat resource, zona, dan region.
• Untuk mempelajari lebih lanjut cara merancang arsitektur yang sangat tersedia di Google Cloud, lihat pola untuk aplikasi yang tangguh dan skalabel.
• Pelajari lebih lanjut opsi konektivitas yang memungkinkan untuk menghubungkan cluster GKE Enterprise yang berjalan di lingkungan lokal/edge Anda, ke jaringan Google Cloud, beserta Dampak pemutusan sementara dari Google Cloud.