Merancang pemulihan dari bencana untuk workload yang dibatasi lokalitas

Last reviewed 2022-06-10 UTC

Dokumen ini membahas cara menggunakan Google Cloud untuk merancang pemulihan dari bencana (DR) guna memenuhi persyaratan spesifik per lokasi. Untuk beberapa industri yang diatur, workload harus mematuhi persyaratan ini. Dalam skenario ini, satu atau beberapa persyaratan berikut berlaku:

  • Data dalam penyimpanan harus dibatasi untuk negara yang ditentukan.
  • Data harus diproses di negara tempat data tersebut berada.
  • Workload hanya dapat diakses dari lokasi yang telah ditentukan.
  • Data harus dienkripsi menggunakan kunci yang dikelola pelanggan.
  • Jika Anda menggunakan layanan cloud, setiap layanan cloud harus menyediakan minimal dua lokasi yang redundan satu sama lain. Sebagai contoh persyaratan redundansi lokasi, lihat Katalog Kriteria Kepatuhan Cloud Computing (C5).

Artikel ini adalah bagian kelima dari seri yang membahas pemulihan bencana (DR) di Google Cloud. Bagian ini memberikan ringkasan proses perencanaan DR: hal yang perlu Anda ketahui untuk merancang dan mengimplementasikan rencana DR.

Rangkaian ini terdiri dari bagian-bagian berikut:

Terminologi

Sebelum Anda mulai merancang DR untuk workload yang dibatasi lokalitas, sebaiknya tinjau terminologi lokalitas yang digunakan di Google Cloud.

Google Cloud menyediakan layanan di region di seluruh Amerika, Eropa dan Timur Tengah, serta Asia Pasifik. Misalnya, London (europe-west2) adalah wilayah di Eropa, dan Oregon (us-west1) adalah wilayah di Amerika Utara. Beberapa produk Google Cloud mengelompokkan beberapa region ke dalam lokasi multi-region tertentu yang dapat diakses dengan cara yang sama seperti saat Anda menggunakan region.

Region dibagi lagi menjadi zona tempat Anda men-deploy resource Google Cloud tertentu seperti virtual machine, cluster Kubernetes, atau database Cloud SQL. Resource di Google Cloud bersifat multi-regional, regional, atau zona. Beberapa resource dan produk yang secara default ditetapkan sebagai multi-regional juga dapat dibatasi untuk sebuah region. Berbagai jenis resource dijelaskan sebagai berikut:

  • Resource multi-regional didesain oleh Google Cloud agar bersifat redundan dan didistribusikan di dalam dan di seluruh region. Resource multi-regional tahan terhadap kegagalan satu region.
  • Resource regional di-deploy secara redundan di beberapa zona dalam satu region, dan tahan terhadap kegagalan zona dalam region tersebut.
  • Resource zona beroperasi dalam satu zona. Jika zona menjadi tidak tersedia, semua resource zona di zona tersebut tidak akan tersedia hingga layanan dipulihkan. Pertimbangkan zona sebagai domain gagal tunggal. Anda perlu merancang aplikasi untuk mengurangi efek dari satu zona menjadi tidak tersedia.

Tabel berikut menunjukkan hubungan saat ini antara region, zona, dan lokasi untuk Eropa.

Region Zona Location
europe-north1 a, b, c Hamina, Finlandia
europe-west1 b, c, d St. Ghislain, Belgia
europe-west2 a, b, c London, Inggris, UK
europe-west3 a, b, c Frankfurt, Jerman
europe-west4 a, b, c Eemshaven, Belanda
europe-west6 a, b, c Zurich, Swiss

Untuk informasi selengkapnya, lihat Geografi dan wilayah.

Perencanaan DR untuk beban kerja yang dibatasi lokalitas

Pendekatan yang Anda ambil untuk mendesain aplikasi bergantung pada jenis beban kerja dan persyaratan lokalitas yang harus Anda penuhi. Pertimbangkan juga mengapa Anda harus memenuhi persyaratan tersebut karena apa yang Anda putuskan akan berpengaruh langsung terhadap arsitektur DR Anda.

Mulailah dengan membaca panduan perencanaan pemulihan dari bencana di Google Cloud. Dan saat Anda mempertimbangkan beban kerja yang dibatasi lokalitas, fokuslah pada persyaratan yang dibahas di bagian perencanaan ini.

Menentukan persyaratan lokalitas Anda

Sebelum memulai desain, tentukan persyaratan lokalitas Anda dengan menjawab pertanyaan-pertanyaan berikut:

  • Di mana data dalam penyimpanan? Jawabannya akan menentukan layanan yang dapat Anda gunakan, serta metode ketersediaan tinggi (HA) dan DR yang dapat Anda gunakan untuk mencapai nilai RTO/RPO. Gunakan halaman Lokasi Cloud untuk menentukan produk yang tercakup dalam cakupan.
  • Dapatkah Anda menggunakan teknik enkripsi untuk mengurangi persyaratan? Jika Anda dapat mengurangi persyaratan lokalitas dengan menggunakan teknik enkripsi menggunakan Cloud External Key Manager dan Cloud Key Management Service, Anda dapat menggunakan layanan multi-regional dan dual-regional serta mengikuti HA/DR standar teknik yang diuraikan dalam Skenario pemulihan dari bencana untuk data.

  • Apakah data dapat diproses di luar tempat data tersebut disimpan? Anda dapat menggunakan produk seperti GKE Enterprise untuk menyediakan lingkungan hybrid guna memenuhi kebutuhan Anda atau menerapkan kontrol khusus produk seperti load balancing instance Compute Engine di beberapa zona di satu region. Gunakan kebijakan Organisasi batasan Lokasi Resource untuk membatasi tempat resource dapat di-deploy .

    Jika data dapat diproses di luar tempat data tersebut perlu dalam penyimpanan, Anda dapat mendesain bagian "pemrosesan" aplikasi dengan mengikuti panduan dalam Elemen penyusun pemulihan dari bencana dan Skenario pemulihan dari bencana untuk aplikasi.

    Konfigurasikan perimeter Kontrol Keamanan VPC untuk mengontrol siapa yang dapat mengakses data dan membatasi resource yang dapat memproses data.

  • Dapatkah Anda menggunakan lebih dari satu region? Jika dapat menggunakan lebih dari satu region, Anda dapat menggunakan banyak teknik yang diuraikan dalam rangkaian Pemulihan dari Bencana. Periksa batasan multi-region dan region untuk produk Google Cloud.

  • Apakah Anda perlu membatasi siapa saja yang dapat mengakses aplikasi Anda? Google Cloud memiliki beberapa produk dan fitur yang membantu Anda membatasi siapa saja yang dapat mengakses aplikasi Anda:

    • Identity-Aware Proxy (IAP). Memverifikasi identitas pengguna, lalu menentukan apakah pengguna tersebut harus diizinkan untuk mengakses aplikasi. Kebijakan organisasi menggunakan batasan berbagi yang dibatasi domain untuk menentukan ID Cloud Identity atau Google Workspace yang diizinkan dalam kebijakan IAM.
    • Kontrol lokalitas khusus produk. Lihat setiap produk yang ingin Anda gunakan dalam arsitektur untuk mengetahui batasan lokalitas yang sesuai. Misalnya, gunakan pengelola konfigurasi GKE Enterprise untuk menerapkan kebijakan khusus lokalitas ke cluster GKE yang dikelola GKE Enterprise. Jika Anda menggunakan Cloud Storage, buat bucket di region tertentu.

Mengidentifikasi layanan yang dapat Anda gunakan

Identifikasi layanan yang dapat digunakan berdasarkan persyaratan lokalitas dan perincian regional Anda. Mendesain aplikasi yang tunduk pada pembatasan lokalitas memerlukan pemahaman tentang produk yang dapat dibatasi untuk region dan kontrol apa yang dapat diterapkan untuk menerapkan persyaratan pembatasan lokasi.

Mengidentifikasi perincian regional untuk aplikasi dan data

Identifikasi perincian regional untuk aplikasi dan data Anda dengan menjawab pertanyaan-pertanyaan berikut:

  • Dapatkah Anda menggunakan layanan multi-regional dalam desain Anda? Dengan menggunakan layanan multiregional, Anda dapat membuat arsitektur tangguh yang sangat tersedia.
  • Apakah akses ke aplikasi Anda memiliki batasan lokasi? Gunakan produk Google Cloud ini untuk membantu menetapkan lokasi yang dapat mengakses aplikasi Anda:
  • Apakah data dalam penyimpanan Anda dibatasi untuk region tertentu? Jika Anda menggunakan layanan terkelola, pastikan layanan yang Anda gunakan dapat dikonfigurasi sehingga data yang disimpan di layanan ini dibatasi untuk region tertentu. Misalnya, gunakan batasan lokalitas BigQuery untuk menentukan tempat set data Anda disimpan dan dicadangkan.
  • Di region mana Anda perlu membatasi aplikasi? Beberapa produk Google Cloud tidak memiliki batasan regional. Gunakan halaman Lokasi Cloud dan halaman khusus produk untuk memvalidasi region tempat Anda dapat menggunakan produk dan fitur mitigasi jika tersedia untuk dibatasi aplikasi Anda ke wilayah tertentu.

Memenuhi batasan lokalitas menggunakan produk Google Cloud

Bagian ini menjelaskan fitur dan teknik mitigasi untuk menggunakan produk Google Cloud sebagai bagian dari strategi DR untuk beban kerja yang dibatasi lokalitas. Sebaiknya baca bagian ini beserta Elemen penyusun pemulihan dari bencana.

Kebijakan organisasi

Layanan Kebijakan Organisasi memberi Anda kontrol terpusat atas resource Google Cloud. Dengan menggunakan kebijakan organisasi, Anda dapat mengonfigurasi batasan di seluruh hierarki resource Anda. Pertimbangkan batasan kebijakan berikut saat membuat arsitektur untuk workload yang dibatasi lokalitas:

  • Domain-restricted sharing: Secara default, semua identitas pengguna dapat ditambahkan ke kebijakan IAM. Daftar yang diizinkan/ditolak harus menentukan satu atau beberapa identitas pelanggan Cloud Identity atau Google Workspace. Jika batasan ini aktif, hanya identitas dalam daftar yang diizinkan yang memenuhi syarat untuk ditambahkan ke kebijakan IAM.

  • Location-restricted resources: Batasan ini mengacu pada kumpulan lokasi tempat resource Google Cloud berbasis lokasi dapat dibuat. Kebijakan untuk batasan ini dapat menentukan sebagai lokasi yang diizinkan atau ditolak salah satu dari hal berikut: multi-region seperti Asia dan Eropa, region seperti us-east1 atau europe-west1, atau zona individual seperti europe-west1-b. Untuk daftar layanan yang didukung, lihat Layanan yang didukung lokasi resource.

Enkripsi

Jika persyaratan lokalitas data Anda berkaitan dengan pembatasan siapa yang dapat mengakses data, maka menerapkan metode enkripsi mungkin merupakan strategi yang dapat diterapkan. Dengan menggunakan sistem pengelolaan kunci eksternal untuk mengelola kunci yang Anda sediakan di luar Google Cloud, Anda mungkin dapat men-deploy arsitektur multi-region untuk memenuhi persyaratan lokalitas Anda. Tanpa kunci yang tersedia, data tidak dapat didekripsi.

Google Cloud memiliki dua produk yang memungkinkan Anda menggunakan kunci yang Anda kelola:

  • Cloud External Key Manager (Cloud EKM): Dengan Cloud EKM, Anda dapat mengenkripsi data di BigQuery dan Compute Engine dengan kunci enkripsi yang disimpan dan dikelola dalam kunci pihak ketiga sistem manajemen proyek yang diterapkan di luar infrastruktur Google.

  • Kunci enkripsi yang disediakan pelanggan (CSEK): Anda dapat menggunakan CSEK dengan Cloud Storage dan Compute Engine. Google menggunakan kunci Anda untuk melindungi kunci yang dibuat oleh Google yang digunakan untuk mengenkripsi dan mendekripsi data Anda.

    Jika Anda memberikan kunci enkripsi yang disediakan pelanggan, Google tidak akan menyimpan kunci Anda secara permanen di server Google atau mengelola kunci Anda. Sebagai gantinya, Anda memberikan kunci untuk setiap operasi, dan kunci akan dihapus dari server Google setelah operasi selesai.

Saat mengelola infrastruktur utama Anda sendiri, Anda harus mempertimbangkan masalah latensi dan keandalan dengan cermat, serta memastikan bahwa Anda menerapkan proses HA dan pemulihan yang sesuai untuk pengelola kunci eksternal. Anda juga harus memahami persyaratan RTO Anda. Kunci merupakan bagian integral dalam penulisan data. Jadi, RPO bukanlah masalah penting karena tidak ada data yang dapat ditulis dengan aman tanpa kunci. Masalah sebenarnya adalah RTO karena tanpa kunci, Anda tidak dapat membatalkan enkripsi atau menulis data dengan aman.

Penyimpanan

Saat merancang DR untuk workload yang dibatasi lokalitas, Anda harus memastikan bahwa data dalam penyimpanan berada di region yang Anda perlukan. Anda dapat mengonfigurasi layanan penyimpanan file dan objek Google Cloud untuk memenuhi kebutuhan Anda

Cloud Storage

Anda dapat membuat bucket Cloud Storage yang memenuhi batasan lokalitas.

Di luar fitur yang dibahas di bagian Cloud Storage pada artikel Komponen Penyusunan Pemulihan Bencana, saat Anda merancang DR untuk workload yang dibatasi lokalitas, pertimbangkan apakah redundansi di seluruh region adalah persyaratan: objek disimpan di multi-region dandual-region disimpan di setidaknya dua area yang terpisah secara geografis, terlepas dari kelas penyimpanannya. Redundansi ini memastikan ketersediaan maksimum data Anda, bahkan selama gangguan berskala besar, seperti bencana alam. Dual-region mencapai redundansi ini dengan menggunakan sepasang region yang Anda pilih. Multi-region mencapai redundansi ini dengan menggunakan kombinasi pusat data apa pun di multi-region yang ditentukan, yang mungkin mencakup pusat data yang tidak secara eksplisit tercantum sebagai region yang tersedia.

Sinkronisasi data antara bucket terjadi secara asinkron. Jika Anda memerlukan tingkat keyakinan yang tinggi bahwa data telah ditulis ke region alternatif untuk memenuhi nilai RTO dan RPO Anda, salah satu strateginya adalah menggunakan dua bucket satu region. Kemudian, Anda dapat melakukan penulisan ganda pada objek atau menulis ke satu bucket dan menyalin Cloud Storage (rewriteTo) pada bucket kedua.

Strategi mitigasi region tunggal saat menggunakan Cloud Storage

Jika persyaratan Anda membatasi penggunaan satu region, misalnya, London atau Zürich, Anda akan dibatasi untuk region tersebut dan tidak dapat mengimplementasikan arsitektur yang berlebihan di seluruh lokasi geografis menggunakan Google Cloud saja. Dalam skenario ini, pertimbangkan untuk menggunakan satu atau beberapa teknik berikut:

  • Mengadopsi strategi multi-cloud atau hybrid. Dengan pendekatan ini, Anda dapat memilih solusi cloud atau solusi lokal lainnya di area geografis yang sama dengan region Google Cloud. Anda dapat menyimpan salinan data di bucket Cloud Storage secara lokal, atau menggunakan Cloud Storage sebagai target untuk data cadangan Anda.

    Untuk menggunakan pendekatan ini, lakukan hal berikut:

    • Pastikan persyaratan jarak terpenuhi.
    • Jika Anda menggunakan AWS sebagai penyedia cloud lainnya, lihat panduan interoperabilitas Cloud Storage untuk mengetahui cara mengonfigurasi akses ke Amazon S3 menggunakan alat Google Cloud.
    • Untuk cloud lainnya dan solusi lokal, pertimbangkan solusi open source seperti minIO dan Ceph untuk menyediakan penyimpanan objek lokal.
    • Pertimbangkan untuk menggunakan solusi partner untuk menyediakan penyimpanan objek lokal.
    • Pertimbangkan untuk menggunakan solusi partner untuk menerapkan alur kerja yang memungkinkan Anda menulis data ke Cloud Storage dan layanan penyimpanan objek cloud alternatif.
    • Pertimbangkan untuk menggunakan Cloud Composer dengan utilitas command line gsutil untuk mentransfer data dari penyimpanan objek lokal ke Cloud Storage.
    • Gunakan Transfer Service for On Premises Data untuk menyalin data yang disimpan di infrastruktur lokal ke Cloud Storage.

  • Menerapkan teknik enkripsi. Jika persyaratan lokalitas Anda mengizinkan penggunaan teknik enkripsi sebagai solusinya, Anda dapat menggunakan bucket multi-region atau dual-region.

Filestore

Filestore menyediakan penyimpanan file terkelola yang dapat Anda deploy di region dan zona sesuai dengan persyaratan pembatasan lokalitas Anda.

Database terkelola

Skenario pemulihan dari bencana untuk data menjelaskan metode untuk menerapkan strategi pencadangan dan pemulihan untuk layanan database terkelola Google Cloud. Selain menggunakan metode ini, Anda juga harus mempertimbangkan pembatasan lokalitas untuk setiap layanan database terkelola yang digunakan dalam arsitektur Anda, misalnya:

  • Bigtable tersedia di lokasi zona dalam suatu region. Instance produksi memiliki minimal dua cluster, yang harus berada di zona unik dalam region tersebut. Replikasi antar-cluster dalam instance Bigtable dikelola secara otomatis oleh Google. Bigtable menyinkronkan data Anda antar-cluster, sehingga membuat salinan data yang terpisah dan independen di setiap zona tempat instance Anda memiliki cluster. Replikasi memungkinkan traffic masuk mengalami kegagalan ke cluster lain dalam instance yang sama.

  • BigQuery memiliki batasan lokalitas yang menentukan tempat set data Anda disimpan. Lokasi set data dapat bersifat regional atau multi-regional. Untuk memberikan ketahanan selama bencana wilayah terjadi, Anda harus mencadangkan data ke lokasi geografis lain. Untuk multi-region BigQuery, sebaiknya menghindari pencadangan ke region dalam cakupan multi-region. Jika memilih multi-region di UE, Anda akan mengecualikan Zürich dan London agar tidak menjadi bagian dari konfigurasi multi-region. Untuk panduan penerapan solusi DR bagi BigQuery yang mengatasi peristiwa yang jarang terjadi yaitu kehilangan regional fisik, lihat Hilangnya wilayah.

    Untuk memahami implikasi penerapan konfigurasi BigQuery satu region atau multi-region, baca dokumentasi BigQuery.

  • Anda dapat menggunakan Firestore untuk menyimpan data Firestore di lokasi multi-region atau lokasi regional. Data di lokasi multi-region beroperasi dalam konfigurasi replikasi multi-zona dan multi-region. Pilih lokasi multi-region jika persyaratan pembatasan lokalitas Anda mengizinkannya dan Anda ingin memaksimalkan ketersediaan dan ketahanan database. Lokasi multi-region dapat memberikan perlindungan jika terjadi kehilangan di seluruh region dan menjaga ketersediaan tanpa kehilangan data. Data di lokasi regional beroperasi dalam konfigurasi replikasi multi-zona

  • Anda dapat mengonfigurasi Cloud SQL untuk ketersediaan tinggi. Instance Cloud SQL yang dikonfigurasi untuk HA juga disebut instance regional serta berada di zona utama dan sekunder di region yang dikonfigurasi. Dalam instance regional, konfigurasi terdiri dari instance utama dan instance standby. Pastikan Anda memahami waktu failover standar dari instance utama ke instance standby.

    Jika persyaratan Anda mengizinkan, Anda dapat mengonfigurasi Cloud SQL dengan replika lintas-region. Jika terjadi bencana, replika baca di wilayah lain dapat dipromosikan. Karena replika baca dapat dikonfigurasi untuk HA terlebih dahulu, replika tersebut tidak perlu mengalami perubahan tambahan setelah promosi untuk HA tersebut. Anda juga dapat mengonfigurasi replika baca agar memiliki replika lintas-regionnya sendiri yang dapat menawarkan perlindungan langsung dari kegagalan regional setelah promosi replika.

  • Anda dapat mengonfigurasi Spanner sebagai regional atau multi-region. Untuk setiap konfigurasi regional, Spanner mengelola tiga replika baca-tulis, masing-masing di zona Google Cloud yang berbeda di region tersebut. Setiap replika baca-tulis berisi salinan lengkap database operasional Anda yang dapat melayani permintaan baca/tulis dan hanya baca.

    Spanner menggunakan replika di zona yang berbeda sehingga jika terjadi kegagalan zona tunggal, database Anda akan tetap tersedia. Deployment multi-region Spanner menyediakan lingkungan yang konsisten di beberapa region, termasuk dua region baca-tulis dan satu region saksi yang berisi replika saksi. Anda harus memvalidasi bahwa lokasi semua region memenuhi persyaratan pembatasan lokalitas Anda.

Compute Engine

Resource Compute Engine bersifat global, regional, atau zona. Resource Compute Engine seperti instance virtual machine atau persistent disk zona disebut sebagai resource zona. Resource lain, seperti alamat IP eksternal statis, bersifat regional. Resource regional dapat digunakan oleh resource apa pun di region tersebut, di mana pun zonanya, sedangkan resource zona hanya dapat digunakan oleh resource lain di zona yang sama.

Menempatkan resource di zona berbeda dalam satu region akan mengisolasi resource tersebut dari sebagian besar jenis kegagalan infrastruktur fisik dan kegagalan layanan software infrastruktur. Selain itu, menempatkan sumber daya di berbagai wilayah memberikan tingkat independensi kegagalan yang lebih tinggi. Pendekatan ini memungkinkan Anda merancang sistem yang tangguh dengan resource yang tersebar di berbagai domain gagal.

Untuk informasi selengkapnya, lihat region dan zona.

Menggunakan infrastruktur lokal atau cloud lain sebagai situs produksi

Anda mungkin menggunakan region Google Cloud yang mencegah Anda menggunakan kombinasi ganda atau multi-region untuk arsitektur DR. Untuk memenuhi batasan lokalitas dalam hal ini, pertimbangkan untuk menggunakan pusat data Anda sendiri atau cloud lain sebagai situs produksi atau sebagai situs failover.

Bagian ini membahas produk Google Cloud yang dioptimalkan untuk workload hybrid. Arsitektur DR yang menggunakan infrastruktur lokal dan Google Cloud dibahas di bagian Skenario pemulihan dari bencana untuk aplikasi.

GKE Enterprise

GKE Enterprise adalah platform aplikasi hybrid dan multi-cloud terbuka dari Google Cloud yang membantu Anda menjalankan workload berbasis container dengan aman di mana saja. GKE Enterprise memungkinkan konsistensi antara lingkungan lokal dan cloud, sehingga Anda dapat memiliki model operasi yang konsisten dan satu tampilan cluster Google Kubernetes Engine (GKE), di mana pun Anda menjalankannya.

Sebagai bagian dari strategi DR Anda, GKE Enterprise menyederhanakan konfigurasi dan pengoperasian arsitektur HA dan failover di lingkungan yang berbeda (antara Google Cloud dan infrastruktur lokal atau cloud lainnya). Anda dapat menjalankan cluster GKE Enterprise produksi secara lokal dan jika terjadi bencana, Anda dapat gagal menjalankan beban kerja yang sama di cluster GKE Enterprise di Google Cloud.

GKE Enterprise di Google Cloud memiliki tiga jenis cluster:

  • Cluster zona tunggal. Cluster zona tunggal memiliki satu bidang kontrol yang berjalan di satu zona. Bidang kontrol ini mengelola beban kerja pada node yang berjalan di zona yang sama.
  • Cluster multi-zona. Cluster multi-zona memiliki satu replika bidang kontrol yang berjalan di satu zona, dan memiliki node yang berjalan di beberapa zona
  • Cluster regional. Cluster regional mereplikasi node dan primer cluster di beberapa zona dalam satu region. Misalnya, cluster regional di region us-east1 membuat replika bidang kontrol dan node dalam tiga zona us-east1: us-east1-b, us-east1-c, dan us-east1-d.

Cluster regional paling tahan terhadap pemadaman layanan di zona.

Google Cloud VMware Engine

Google Cloud VMware Engine memungkinkan Anda menjalankan workload VMware di cloud. Jika workload lokal Anda berbasis VMware, Anda dapat merancang solusi DR untuk berjalan di solusi virtualisasi yang sama dengan yang Anda jalankan secara lokal. Anda dapat memilih wilayah yang memenuhi persyaratan lokalitas Anda.

Networking

Jika rencana DR Anda didasarkan pada pemindahan data dari lokal ke Google Cloud atau dari penyedia cloud lain ke Google Cloud, Anda harus mengatasi strategi jaringan Anda. Untuk informasi selengkapnya, lihat bagian Mentransfer data ke dan dari Google Cloud di dokumen "Elemen penyusun pemulihan dari bencana".

Kontrol Layanan VPC

Saat merencanakan strategi DR, Anda harus memastikan bahwa kontrol keamanan yang berlaku untuk lingkungan produksi juga meluas ke lingkungan failover Anda. Dengan menggunakan Kontrol Layanan VPC, Anda dapat menentukan perimeter keamanan dari jaringan lokal ke project Anda di Google Cloud.

Kontrol Layanan VPC memungkinkan pendekatan akses kontekstual untuk mengontrol resource cloud Anda. Perusahaan dapat membuat kebijakan kontrol akses terperinci di Google Cloud berdasarkan atribut seperti identitas pengguna dan alamat IP. Kebijakan ini membantu memastikan kontrol keamanan yang sesuai tersedia di lingkungan lokal dan Google Cloud Anda.

Langkah selanjutnya