Pola untuk menghubungkan penyedia layanan cloud lain dengan Google Cloud

Dokumen ini membantu arsitek cloud dan profesional operasi menentukan cara menghubungkan Google Cloud dengan penyedia layanan cloud (CSP) lainnya seperti Amazon Web Services (AWS) dan Microsoft Azure. Dalam desain multicloud, koneksi antara CSP memungkinkan transfer data di antara jaringan virtual Anda. Dokumen ini juga menyediakan informasi tentang cara menerapkan opsi yang Anda pilih.

Banyak organisasi beroperasi di beberapa platform cloud, baik hanya sebagai tindakan sementara selama migrasi atau karena organisasi sudah memiliki strategi multicloud jangka panjang.

Untuk pertukaran data di antara Google Cloud dengan CSP, ada beberapa opsi yang akan dibahas di dalam dokumen ini:

• Transfer data melalui alamat IP publik dalam internet.
• Menggunakan layanan VPN terkelola di antara Google Cloud dengan CSP lain.
• Menggunakan Partner Interconnect di Google Cloud untuk terhubung dengan partner yang dapat secara langsung terhubung dengan CSP lainnya.
• Menggunakan Dedicated Interconnect di Google Cloud untuk mentransfer data ke CSP lain melalui titik kehadiran (POP) umum.
• Menggunakan Cross-Cloud Interconnect pada Google Cloud untuk koneksi terkelola ke CSP lain.

Opsi ini mungkin berbeda dalam hal kecepatan transfer, latensi, keandalan, perjanjian tingkat layanan (SLA), kompleksitas, dan biaya. Dokumen ini menjelaskan masing-masing opsi beserta kelebihan dan kekurangannya secara detail dan ditutup dengan perbandingan seluruh opsi.

Dokumen ini mencakup transfer data antara virtual machine yang ada di Google Cloud dengan jaringan virtual CSP lainnya. Untuk data yang disimpan di produk Google Cloud lain seperti Cloud Storage dan BigQuery, lihat bagian yang mencakup produk ini.

Dokumen ini dapat berfungsi sebagai panduan untuk mengevaluasi opsi yang digunakan untuk mentransfer data di antara Google Cloud dengan satu atau lebih CSP lain, berdasarkan kebutuhan dan kemampuan Anda.

Konsep dalam dokumen ini berlaku dalam beberapa kasus:

• Saat Anda berencana mentransfer data dalam jumlah besar selama jangka waktu yang singkat, misalnya, untuk project migrasi data.
• Jika Anda menjalankan transfer data berkelanjutan di antara beberapa penyedia cloud, misalnya, karena workload komputasi Anda berjalan di beberapa CSP sementara workload big data Anda menggunakan Google Cloud.

Pertimbangan awal

Sebelum Anda memilih cara menghubungkan lingkungan cloud Anda, sangat penting bagi Anda untuk memperhatikan wilayah manakah yang Anda pilih di setiap lingkungan dan bahwa Anda telah memiliki strategi transfer data yang tidak dilakukan dalam lingkungan jaringan.

Pilih cloud - region

Jika resource Google Cloud dan CSP lain berada di wilayah yang secara geografis dekat satu sama lain, maka akan menimbulkan keunggulan biaya dan latensi pada transfer data di antara penyedia cloud.

Diagram berikut menggambarkan aliran data antara Google Cloud dengan CSP lain.

Terlepas dari metode transfer, aliran data dari Google Cloud ke CSP lain adalah sebagai berikut:

• Dari wilayah Google Cloud tempat resource dihostingkan ke POP edge Google.
• Melalui fasilitas pihak ketiga antara Google Cloud dengan CSP lain.
• Dari edge POP edge CSP lain ke wilayah tempat resource berada di dalam jaringan CSP lain.

Data yang mengalir dari CSP lain ke Google Cloud berjalan ke jalur yang sama, tetapi dalam arah yang berlawanan.

Jalur menyeluruh menentukan latensi transfer data. Untuk beberapa solusi, biaya jaringan juga dapat bertambah ketika POP edge kedua penyedia tidak berada di area metropolitan. Detailnya tercantum di bagian harga setiap solusi berikut.

Pastikan Anda memilih wilayah yang sesuai pada setiap cloud yang dapat menghosting workload yang workloads yang Anda inginkan. Kunjungi halaman Lokasi untuk Google Cloud dan halaman serupa untuk CSP lain, seperti tabel wilayah AWS atau Produk Azure berdasarkan wilayah. Untuk bantuan umum dalam memilih satu atau beberapa lokasi di Google Cloud, baca Praktik terbaik untuk pemilihan wilayah Compute Engine.

Transfer data pada Cloud Storage dan BigQuery

Hanya data yang berada di dalam lingkungan VPC Google Cloud yang dapat diteruskan melewati tunnel Cloud VPN atau koneksi Cloud Interconnect secara default.

Jika ingin mentransfer data ke dan dari layanan Google lain, Anda dapat menggunakan Private Service Connect dan Akses Google Pribadi untuk hosting lokal dari lingkungan CSP lain.

Jika ingin mentransfer object storage, database, data warehouse CSP, atau produk lainnya, periksa dokumentasinya untuk melihat apakah data dapat diteruskan melewati produk VPN interkoneksi atau terkelola. Jika tidak, Anda harus memungkinkan agar data ini diteruskan melewati proxy virtual machine proxy yang sudah Anda siapkan di lingkungan CSP yang dimaksud untuk memungkinkannya diteruskan melewati koneksi yang Anda inginkan.

Untuk mentransfer data ke Cloud Storage atau BigQuery, Anda juga dapat menggunakan Storage transfer service atau BigQuery transfer service.

Transfer melalui alamat IP eksternal menggunakan jaringan internet

Cara paling mudah untuk mentransfer data antara Google Cloud dengan CSP lain adalah dengan menggunakan internet dan mentransfer data menggunakan alamat IP eksternal.

Diagram berikut mengilustrasikan elemen untuk solusi ini.

Data diteruskan melewati edge jaringan Google dengan edge jaringan CSP lain melalui internet atau menggunakan peering langsung antara Google Cloud dengan CSP lain. Data hanya dapat diteruskan antar resource dengan alamat IP yang sudah ditetapkan.

Cara Google terhubung ke jaringan lain

POP edge Google merupakan tempat jaringan Google terhubung dengan jaringan lain yang secara kolektif membentuk internet. Google hadir di berbagai lokasi di seluruh dunia.

Di internet, setiap jaringan diberikan nomor sistem otonom (ASN) yang meliputi infrastruktur dan rute jejaring internal dari suatu jaringan. ASN utama Google adalah 15169.

Ada dua cara utama bagi sebuah jaringan untuk dapat mengirim atau menerima traffic ke atau dari Google:

• Membeli layanan internet dari internet service provider (ISP) yang sudah memiliki konektivitas ke Google (AS15169). Opsi ini umumnya disebut sebagai IP transit dan mirip dengan apa yang dibeli oleh konsumen dan perusahaan dari penyedia akses di rumah dan tempat usaha mereka.
• Terhubung langsung ke Google (AS15169). Opsi ini disebut peering, memungkinkan jaringan untuk mengirimkan dan menerima traffic secara langsung ke Google (AS15169) tanpa menggunakan jaringan pihak ketiga. Dalam skala besar, peering umumnya lebih dipilih daripada transit karena operator jaringan memiliki kontrol lebih atas cara dan tempat pertukaran traffic, sehingga memungkinkan pengoptimalan performa dan biaya. Peering adalah sistem sukarela, ketika memilih untuk peer, operator jaringan memutuskan ke mana fasilitas yang harus disambungkan, berapa besar bandwidth yang harus disediakan, cara membagi biaya infrastruktur, dan setiap detail yang diperlukan untuk menyiapkan koneksi. AS15169 memiliki kebijakan peering terbuka, yang artinya selama jaringan memenuhi persyaratan teknis, Google bersedia untuk peering dengan jaringan tersebut.

Peering adalah perjanjian pribadi yang saling menguntungkan di antara dua jaringan independen. Dengan demikian, jaringan umumnya tidak mengungkapkan secara publik dengan jaringan yang melakukan peering di lokasi tertentu, seberapa besar bandwidth yang tersedia, dll. Namun, karena dan merupakan kebijakan terbuka, Google melakukan peering langsung dengan hampir sebagian besar ISP dan penyedia layanan cloud di beberapa lokasi dan di seluruh wilayah. Tim jaringan Google bekerja secara langsung dengan rekan kerja dalam jaringan ini untuk menyediakan kapasitas peering yang memadai untuk memenuhi kebutuhan.

Baca selengkapnya tentang cara kerja peering internet di Playbook Peering Internet.

Penerapan

Dalam penyiapan ini, semua virtual machine yang mentransfer data di antara Google Cloud dengan penyedia cloud lain harus memiliki alamat IP publik. Pada satu sisi, firewall harus dibuka untuk mengizinkan koneksi dari alamat IP publik dari penyedia cloud lain. Langkah tambahan tidak diperlukan karena pertukaran data terjadi dalam konektivitas internet yang sudah ada.

Kecepatan dan latensi transfer

Meskipun tidak ada kecepatan dan latensi yang dijamin pada jalur yang melalui internet, umumnya, CSP besar dengan Google bertukar data secara langsung di beberapa lokasi di seluruh dunia. Kapasitas digunakan bersama dengan pelanggan dan layanan lainnya, tetapi, seringkali dikarenakan koneksi langsung di antara kedua penyedia, latensinya serupa atau lebih rendah daripada opsi lainnya.

Sebaiknya Anda menguji latensi dan bandwidth antara Google Cloud dengan CSP lain di wilayah pilihan Anda. Anda dapat melakukan tolok ukur cepat menggunakan alat seperti iperf atau netperf, atau jalankan tolok ukur khusus yang lebih lengkap berdasarkan apl Anda. Meskipun conditions mungkin berubah dari waktu ke waktu, tolok ukur dapat memberikan indikasi performa yang dapat Anda perkirakan dan indikasi apakah suatu solusi memenuhi kebutuhan Anda. Jika Anda membutuhkan bandwidth khusus di antara kedua lingkungan, Anda dapat memilih solusi lainnya.

Perhatikan bahwa produk dari vendor yang berbeda mungkin tidak selalu memiliki karakteristik performa yang selaras. Misalnya, kapasitas VPN IPsec per-tunnel mungkin berbeda-beda dari setiap vendor.

Keamanan

Traffic di internet tidak terenkripsi dan mungkin diteruskan melewati internet service provider (ISP), sistem otonom, dan fasilitas pihak ketiga. Oleh karenanya, Anda harus mengenkripsikan traffic sensitif pada lapisan aplikasi atau memilih solusi lainnya.

Keandalan dan SLA

Google Cloud umumnya memiliki beberapa jalur yang beragam untuk konektivitas internet dari beberapa wilayah, dan ada koneksi peering langsung dengan CSP besar lainnya di beberapa lokasi di seluruh dunia.

Namun, Google Cloud tidak menyediakan SLA untuk konektivitas dengan CSP lainnya di internet. Meskipun Anda harus memeriksa SLA untuk CSP lain Anda, SLA tersebut umumnya merujuk pada konektivitas internet secara keseluruhan, bukan penyedia tertentu.

Penyedia mungkin memiliki kebijakan pemilihan rute berbeda yang dapat memengaruhi ketersediaan. Misalnya, pada halaman peeringdb miliknya, Amazon menjelaskan bahwa banyak wilayah AWS hanya menyiarkan rute lokal, karena VPC AWS bersifat hanya regional (VPC Google Cloud bersifat global.) Hal ini berarti pelanggan mungkin mengandalkan link pada satu lokasi peering tunggal, karena traffic yang keluar dari Google Cloud hanya dapat menggunakan link tersebut untuk menjangkau tujuan. Ini tidak menjadi suatu masalah dalam operasi normal dengan traffic yang dipertukarkan dalam wilayah, tetapi sebaiknya pelanggan merancang deployment multi-region untuk menoleransi kegagalan regional. Tindakan ini dapat mencakup penyetelan gateway tambahan, HA VPN, peering jaringan virtual, atau topologi multi-region lain di cloud pihak ketiga.

Aplikasi juga harus di-build sedemikian rupa sehingga aplikasi 'fail open' sebagaimana yang disarankan oleh Google SRE dibuku SRE. Misalnya, jika Anda mem-build aplikasi yang mengandalkan kemampuan untuk menjangkau layanan pihak ketiga melalui pemilihan rute Internet, pastikan agar aplikasi tetap berfungsi, atau paling tidak menampilkan pesan error bermanfaat bagi pengguna meskipun terjadi masalah konektivitas.

Jika masalah pemilihan rute Internet terjadi, tim jaringan Google akan berupaya memulihkan konektivitas dengan pihak ketiga. Namun, tidak semua masalah berada dalam kendali Google. Jadi dalam beberapa kasus, perbaikan dapat bergantung pada pihak ketiga (ISP atau penyedia cloud) yang melakukan tindakan restoratif. Pelanggan memiliki pengaruh paling besar atas cara operator dalam merespons pemadaman layanan, maka pastikan Anda memiliki cakupan dukungan dengan semua penyedia dan paket untuk mengeskalasi masalah jika terjadi kesalahan. Selain itu lakukan latihan BCP (proses keberlanjutan bisnis) rutin untuk memastikan ketahanan aplikasi yang dirancang di multicloud.

Harga

Untuk transfer data melewati internet, tarif traffic keluar internet normal berlaku untuk traffic keluar Google Cloud. Jika latensi tidak diutamakan, dengan menggunakan Network Service Tier Standar akan memberikan tingkat penentuan harga lebih rendah.

CSP lain memiliki tagihan transfer data sendiri. Dalam banyak kasus, CSP hanya membuat tagihan untuk menagih traffic keluar jaringan mereka. Lihat daftar harga CSP Anda misalnya, untuk AWS, lihat Tagihan transfer data EC2 dan untuk Azure, lihat Detail Harga Bandwidth.

VPN terkelola antar-penyedia cloud

Anda dapat menggunakan layanan VPN terkelola dari kedua penyedia cloud, yang akan memberikan dua manfaat. Layanan tersebut memberikan saluran terenkripsi antar jaringan virtual baik di lingkungan cloud, dan memungkinkan Anda mentransfer data menggunakan alamat IP privat. Layanan ini merupakan ekstensi terhadap solusi sebelumnya yaitu transfer melewati internet tanpa membutuhkan perangkat keras atau partner.

Diagram berikut mengilustrasikan elemen untuk solusi ini.

Dengan menggunakan solusi ini, data terenkripsi pada Google Cloud menggunakan Cloud VPN dan solusi VPN untuk CSP lain. Transfer data antara Google Cloud dengan CSP lain menggunakan internet seperti pada solusi sebelumnya.

Penerapan

Google menawarkan Cloud VPN sebagai layanan VPN terkelola untuk tunnel IPsec terenkripsi yang dapat digunakan di sisi Google. CSP lain menawarkan produk VPN terkelola mereka sendiri yang dapat Anda gunakan untuk mem-build tunnel VPN IPsec di antara kedua lingkungan. Misalnya, AWS menawarkan AWS Site-to-Site VPN sementara Azure menawarkan Azure VPN gateway. Anda dapat terhubung dengan jaringan virtual di antara lingkungan dengan memanfaatkan tunnel VPN.

Alamat IP pada dua lingkungan tidak boleh tumpang-tindih karena tidak memilikipenafsiran alamat jaringan (NAT) yang tersedia di Cloud VPN. Pada Cloud Router, jalur yang tumpang-tindih dapat dihapus dan ditukarkan antar lingkungan, tetapi setelahnya komunikasi antar layanan yang menggunakan alamat IP ini tidaklah memungkinkan.

Dengan Cloud Router dalam mode pemilihan rute dinamis global, Anda dapat menjangkau semua wilayah di jaringan VPC global dengan hanya menggunakan tunnel VPN untuk wilayah tersebut. Untuk CSP lainnya, Anda kemungkinan membutuhkan tunnel VPN tiap wilayah. Jika memiliki beberapa jaringan virtual dalam lingkungan cloud yang tidak di-peering, Anda harus terhubung ke semua jaringan virtual yang perlu berkomunikasi satu sama lain secara independen menggunakan VPN.

Google Cloud menawarkan panduan interoperabilitas, yang memiliki petunjuk langkah-demi langkah untuk menyiapkan tunnel penyedia, layanan, cloud provider cloud providers:

• Gateway Cloud VPN Alibaba tanpa redundansi: hanya mendukung rute statis.
• Gateway Cloud VPN Alibaba dengan redundansi: hanya mendukung rute statis.
• AWS: mendukung pemilihan rute dinamis menggunakan Cloud Router.
• Microsoft Azure: mendukung pemilihan rute dinamis menggunakan Cloud Router.

Kecepatan dan latensi transfer

Jika Anda menggunakan tunnel VPN terkelola, data tetap mengikuti jalur internet yang sama seolah-olah data ditukarkan secara langsung dengan menggunakan alamat IP publik. Latensi yang diamati harus sama dengan opsi sebelumnya dengan hanya overhead latensi yang kecil untuk tunnel VPN. Bandwidth yang tersedia dibatasi oleh bandwidth maksimum per tunnel VPN di Google Cloud, bandwidth maksimum dari tunnel CSP lain, dan bandwidth yang tersedia di jalur internet.

Untuk mendapatkan bandwidth yang lebih tinggi, Anda dapat men-deploy beberapa tunnel secara paralel. Untuk informasi selengkapnya tentang cara men-deploy solusi tersebut, lihat Membuat VPN dengan throughput tinggi.

Anda dapat menguji latensi dan bandwidth sebagaimana dijelaskan di bagian terakhir, tetapi kondisi mungkin berbeda-beda dari waktu ke waktu, dan tidak ada jaminan atas latensi atau bandwidth.

Keamanan

Traffic yang melewati tunnel VPN IPsec dienkripsi menggunakan cipher yang diterima oleh kedua CSP. Untuk informasi selengkapnya, lihat Cloud VPN yang didukung cipher IKE, FAQ VPN AWS, dan Parameter VPN IPsec/IKE Azure.

Keandalan dan SLA

Cloud VPN menawarkan SLA 99,9%-99,99% bergantung pada apakah VPN Klasik atau VPN HA dipilih. CSP lain terkadang menawarkan SLA pada produk VPN terkelolanya, misal, AWS Site-to-Site VPN SLA dan Azure SLA for VPN Gateway. Namun, SLA ini hanya mencakup ketersediaan gateway VPN dan tidak termasuk konektivitas ke CSP lain di internet, sehingga solusi keseluruhan tidak memiliki SLA.

Untuk meningkatkan keandalan, pertimbangkan untuk menggunakan beberapa gateway dan tunnel VPN pada Google Cloud dan CSP lain.

Harga

Untuk layanan VPN terkelola, biaya diberlakukan. Untuk Google Cloud, tagihan tiap jam berlaku, lihat harga Cloud VPN. Untuk CSP lain, lihat daftar harganya, misalnya, lihat harga koneksi VPN AWS Site-to-Site atau harga VPN Gateway Azure.

Selain harga per jam untuk layanan VPN, Anda harus membayar atas data yang ditransfer melalui gateway VPN. Untuk Google Cloud dan sebagian besar CSP, berlaku tarif transfer data internet standar, sebagaimana dirinci dalam Transfer melalui alamat IP eksternal menggunakan jaringan internet. Dalam banyak kasus, tagihan transfer data melampaui biaya tetap untuk solusi ini.

Partner Interconnect dengan partner yang mendukung multicloud

Partner Interconnect memungkinkan Anda terhubung dengan Virtual Private Cloud ke jaringan virtual CSP lain melalui jaringan partner tertentu yang menawarkan solusi multicloud langsung. Anda terhubung dengan men-deploy satu atau lebih instance pemilihan rute virtual yang menangani penyiapan Border Gateway Protocol (BGP) yang diperlukan.

Diagram berikut menampilkan penyiapan redundan dengan menggunakan dua koneksi Partner Interconnect.

Rute ini mengalami pertukaran antara Cloud Router dengan gateway pada sisi CSP lain melalui instance pemilihan rute yang dikelola oleh partner yang menyediakan interkoneksi. Traffic mengalir melalui jaringan partner di antara Google Cloud dengan CSP lain.

Penerapan

Solusi ini mengharuskan Anda untuk menyiapkan beberapa komponen:

• Di sisi Google Cloud, Anda harus menyiapkan Partner Interconnect dengan penyedia layanan interkoneksi yang melayani wilayah Google Cloud Anda dan menawarkan konektivitas multicloud ke CSP lain.
• Pada sisi CSP lain, Anda harus menggunakan produk interkoneksi mereka untuk terhubung ke partner yang sama. Misalnya, di AWS Anda dapat menggunakan Direct Connect dan di Azure Anda dapat menggunakan ExpressRoute.
• Di sisi partner penyedia layanan, Anda harus mengonfigurasi peralatan pemilihan rute virtual yang menyediakan sesi BGP ke Google Cloud dan ke CSP lain.

Jika ruang alamat IP di antara kedua lingkungan CSP tumpang tindih, partner Anda mungkin menawarkan fungsionalitas NAT untuk peralatan pemilihan rute virtual. Lihat dokumentasi partner untuk mengetahui detailnya.

Kecepatan dan latensi transfer

Solusi ini menawarkan kapasitas khusus antara Google Cloud dengan CSP lain. Bergantung pada partner dan CSP lain, kapasitas lampiran yang tersedia mungkin berbeda-beda. Pada sisi Google Cloud, Partner Interconnect tersedia dengan kapasitas lampiran antara 50 Mbps hingga 50 Gbps.

Latensi untuk solusi ini merupakan jumlah dari hal berikut:

• Latensi antara wilayah tempat resource Anda dihostingkan di Google Cloud dan lokasi interkoneksi tempat partner terhubung dengan Google Cloud.
• Latensi pada jaringan partner ke, dari, dan melalui instance pemilihan rute virtual terhadap CSP lain.
• Latensi dari lokasi edge CSP lain tempat interkoneksi dengan partner terjadi ke wilayah tempat resource dihostingkan di CSP.

Untuk latensi serendah mungkin, lokasi edge Google Cloud dan CSP lain harus berada di area metropolitan yang sama, beserta instance pemilihan rute virtualnya. Misalnya, Anda mungkin akan mendapati koneksi latensi rendah jika wilayah cloud CSP, POP edge, serta instance pemilihan rute virtual berada di daerah Ashburn, Virginia.

Meskipun Google Cloud dan sebagian besar CSP menawarkan jaminan tanpa latensi untuk traffic terhadap edge jaringan mereka, karena ada jalur dan kapasitas khusus melalui partner, umumnya latensi dalam solusi ini lebih kecil kemungkinannya untuk berubah-ubah daripada jika Anda menggunakan alamat IP eksternal atau solusi VPN.

Keamanan

Traffic melalui Partner Interconnect tidak dienkripsi secara default. Untuk membantu mengamankan traffic Anda, Anda dapat men-deploy HA VPN melewati Cloud Interconnect pada koneksi di sisi Google Cloud. Beberapa CSP lain memungkinkan Anda untuk menggunakan layanan VPN terkelola mereka di interkoneksi, misalnya AWS Site-to-Site VPN dapat digunakan di AWS Direct Interconnect. Jika tidak, Anda dapat menggunakan perangkat virtual yang mengenkripsi traffic pada sisi CSP lain.

Opsi lainnya adalah mengenkripsi traffic Anda di lapisan aplikasi, daripada menggunakan VPN.

Keandalan dan SLA

Solusi ini melibatkan tiga SLA yang berbeda: satu dari Google, satu dari partner interkoneksi, dan satu dari CSP lain.

Ketika menggunakan Partner Interconnect secara redundan, Google menawarkan 99,9% - 99,99% SLA bulanan bergantung pada topologi yang dipilih. Tidak ada SLA untuk koneksi Partner Interconnect tunggal.

Lihat dokumentasi CSP lain untuk SLA pada produk interkoneksi mereka, misalnya, SLA AWS Direct Connect atau pada Azure SLA untuk ExpressRoute.

Lihat dokumentasi atau ketentuan penyedia partner service Partner Interconnect untuk SLA mereka mengenai ketersediaan dari konektivitas dan instance pemilihan rute virtual. Misalnya, lihat Perjanjian Layanan Global Megaport.

Harga

Pada sisi Google Cloud, ada biaya bulanan untuk setiap lampiran Partner Interconnect, bergantung pada bandwidth. Traffic yang keluar melalui Partner Interconnect dikenai biaya dengan tarif lebih rendah daripada traffic internet. Untuk informasi selengkapnya, lihat halaman harga Partner Interconnect.

Lihat halaman harga CSP lain untuk produk interkoneksi mereka, misalnya harga AWS Direct Connect atau harga Azure ExpressRoute. Biasanya, harga juga dikenakan biaya bulanan untuk interkoneksi dan biaya transfer data melalui interkoneksi dengan tarif lebih rendah daripada internet.

Partner menyediakan tagihan layanan interkoneksi berdasarkan penentuan harga mereka sendiri, yang dapat ditemukan di situs web mereka atau dengan meminta penawaran kepada tim penjualan mereka. Umumnya, jika semua transfer data terjadi di daerah metropolitan yang sama, tagihan akan jauh lebih rendah daripada jika data harus menempuh jarak yang lebih jauh pada jaringan partner.

Ketika data ditransfer secara berkala dengan volume yang cukup tinggi, bergantung pada harga CSP lain, solusi ini terkadang dapat menawarkan biaya total paling rendah karena ada diskon tarif traffic keluar. Bahkan ketika menambahkan biaya bulanan interkoneksi untuk Partner Interconnect, CSP lain, dan partner penyedia layanan, menggunakan solusi ini dapat memberikan penghematan yang signifikan. Karena harga partner dan CSP lain dapat berubah tanpa pemberitahuan, buatlah perbandingan Anda sendiri menggunakan penawaran terbaru dari semua pihak yang terlibat.

Dedicated Interconnect melalui POP umum

Dengan menggunakan satu atau lebih perangkat pemilihan rute fisik pada fasilitas interkoneksi umum antara Google Cloud dengan CSP lain, Anda dapat terhubung dengan kedua penyedia cloud dengan menggunakan Dedicated Interconnect pada sisi Google Cloud dan produk yang setara pada CSP lain. Lokasi interkoneksi tidak harus berada di lokasi yang sama dengan wilayah tempat resource Anda berada.

Diagram berikut menunjukkan penyiapan redundan menggunakan dua koneksi Dedicated Interconnect:

Rute dipertukarkan antara Cloud Router dengan gateway di sisi CSP lain melalui router fisik yang Anda posisikan di fasilitas interkoneksi umum. Traffic yang mengalir melalui router ini antara Google Cloud dengan CSP lain.

Penerapan

Solusi ini mengharuskan agar Anda menghostingkan dan mengelola perangkat pemilihan rute fisik di fasilitas kolokasi tempat Google dan CSP yang ingin Anda hubungkan berada. Dari perangkat pemilihan rute ini, Anda memesan dua koneksi fisik kepada fasilitas: satu ke Google Cloud menggunakan Dedicated Interconnect, dan satu ke penyedia layanan lain menggunakan produk yang setara, misalnya, AWS Direct Connect atau Azure ExpressRoute. Pada perangkat pemilihan rute Anda, Anda harus mengonfigurasi BGP untuk memungkinkan pertukaran rute antara dua lingkungan cloud.

Periksa Daftar lokasi fasilitas kolokasi dari Google Cloud dan CSP lain Anda, misalnya Lokasi AWS Direct Connect atau lokasi peering Azure ExpressRoute, untuk mengidentifikasi lokasi yang sesuai untuk penyiapan ini.

Rentang alamat IP antara jaringan virtual Anda tidak boleh tumpang tindih, kecuali perangkat pemilihan rute fisik Anda dapat melakukan NAT antar lingkungan atau Anda membatasi beberapa pertukaran rute antar lingkungan.

Solusi ini efektif jika ANda menggunakan konektivitas khusus juga untuk terhubung kembali dengan lingkungan lokal Anda, selain koneksi ke CSP lainnya.

Dalam kasus lain, solusi ini terbilang kompleks karena mengharuskan Anda untuk memiliki dan mengelola peralatan fisik, serta memiliki kontrak dengan fasilitas kolokasi. Kami hanya menyarankan solusi ini jika paling tidak salah satu dari hal berikut sesuai dengan Anda:

• Anda telah memiliki peralatan di fasilitas yang sesuai untuk keperluan lain dan telah memiliki kontrak dengan fasilitas.
• Anda mentransfer volume data yang besar secara berkala sehingga solusi ini dianggap opsi hemat biaya atau Anda memiliki kebutuhan bandwidth yang tidak dapat dipenuhi oleh partner.

Kecepatan dan latensi transfer

Solusi ini menawarkan kapasitas khusus antara Google Cloud dengan CSP lain. Pada sisi Google Cloud, Dedicated Interconnect tersedia dengan menggunakan satu atau beberapa koneksi fisik 10 atau 100 Gbps.

Latensi untuk solusi ini adalah akumulasi dari hal berikut:

• Latensi antara wilayah tempat resource Anda dihostingkan di Google Cloud dengan lokasi interkoneksi tempat Anda melakukan interkoneksi ke Google Cloud.
• Latensi melalui fasilitas dengan peralatan fisik Anda yang biasanya dapat diabaikan ketika dibandingkan dengan latensi yang berdasarkan panjang fiber.
• Latensi dari lokasi interkoneksi melalui jaringan CSP lain ke wilayah tempat resource dihostingkan pada CSP.

Meskipun tidak ada jaminan latensi yang ditawarkan, solusi ini umumnya memberikan latensi paling rendah dan kecepatan transfer paling tinggi antara Google Cloud dengan lingkungan cloud lain lewat alamat IP privat.

Keamanan

Traffic melewati Dedicated Interconnect tidak dienkripsi secara default. Untuk membantu mengamankan traffic Anda, Anda dapat men-deploy HA VPN di Cloud Interconnect pada sisi koneksi Google Cloud. Beberapa CSP lain memungkinkan Anda untuk menggunakan layanan VPN terkelola mereka di interkoneksi, misalnya AWS Site-to-Site VPN dapat digunakan di AWS Direct Interconnect. Atau, Anda juga dapat menggunakan perangkat virtual yang mengenkripsi traffic pada sisi CSP lain.

Opsi lainnya adalah mengenkripsi traffic Anda di lapisan aplikasi, daripada menggunakan VPN.

Keandalan dan SLA

Ketika menggunakan Dedicated Interconnect secara redundan, Google menawarkan 99,9%-99,99% SLA bulanan bergantung pada topologi yang dipilih. Tidak ada SLA untuk koneksi Dedicated Interconnect tunggal.

Untuk informasi selengkapnya, lihat dokumentasi CSP lain untuk SLA pada produk interkoneksi mereka, misalnya, SLA AWS Direct Connect atau SLA Azure untuk ExpressRoute.

Fasilitas kolokasi atau vendor hardware untuk peralatan pemilihan rute fisik mungkin juga menawarkan SLA pada layanan mereka.

Harga

Pada sisi Google Cloud, ada biaya bulanan untuk setiap port Dedicated Interconnect serta untuk setiap lampiran VLAN yang terhubung ke lingkungan VPC. Traffic yang keluar melalui Dedicated Interconnect dikenai biaya dengan tarif yang lebih rendah daripada traffic internet. Untuk informasi selengkapnya, lihat halaman harga Dedicated Interconnect.

Lihat halaman harga CSP lain untuk produk interkoneksi mereka, misalnya, Harga AWS Direct Connect atau Harga Azure ExpressRoute. Biasanya, harga juga dikenakan biaya bulanan untuk interkoneksi dan biaya transfer data melalui interkoneksi dengan tarif lebih rendah daripada internet.

Selain itu, Anda harus memperhitungkan biaya untuk layanan fasilitas kolokasi yang menyediakan ruang, listrik, dan koneksi fisik terhadap kedua lingkungan cloud serta setiap biaya dan kontrak layanan yang berlangsung dengan vendor untuk peralatan pemilihan rute fisik. Jika koneksi antara kedua CSP tidak dapat terjadi di dalam fasilitas yang sama dan Anda harus mengadakan konektivitas antar fasilitas, penentuan harga mungkin jauh lebih tinggi untuk layanan semacam ini.

Koneksi terkelola Cross-Cloud Interconnect

Anda dapat menghubungkan jaringan VPC Google Cloud Anda ke jaringan virtual Anda di CSP lain melalui fabric jaringan Google. Dalam beberapa hal, penyiapan ini berfungsi seperti Partner Interconnect, tetapi dengan SLA Google yang mencakup jaringan Google dan interkoneksi itu sendiri.

Diagram berikut menunjukkan konfigurasi Cross-Cloud Interconnect dengan jumlah koneksi yang minimum.

Rute dipertukarkan antara Cloud Router dengan gateway pada sisi CSP lain melalui fabric jaringan Google. Traffic yang mengalir melalui fabric ini adalah antara Google Cloud dengan CSP lain.

Penerapan

Ketika Anda membeli Cross-Cloud Interconnect, Google menyediakan koneksi fisik khusus antara jaringan Google dan koneksi dari penyedia layanan cloud lainnya. Anda dapat menggunakan koneksi ini untuk melakukan peering jaringan Virtual Private Cloud (VPC) Google Cloud Anda dengan jaringan yang dihostingkan oleh penyedia layanan cloud yang didukung.

Setelah Anda menyediakan koneksi, Google memberikan dukungan hingga ke titik saat koneksi menjangkau jaringan penyedia layanan cloud lain. Google tidak menjamin waktu beroperasi dari penyedia layanan cloud lainnya. Namun, Google tetap menjadi kontak utama untuk layanan penuh dan akan memberi tahu Anda jika Anda harus membuka kasus dukungan dengan CSP lain.

Solusi ini mengharuskan Anda untuk mengikuti proses penyiapan untuk CSP lain, meliputi memilih tempat dua jaringan akan melakukan interkoneksi. Hanya CSP tertentu yang didukung.

Kecepatan dan latensi transfer

Solusi ini menawarkan kapasitas khusus antara Google Cloud dengan CSP lain. Pada sisi Google Cloud, Dedicated Interconnect tersedia dengan menggunakan satu atau beberapa sambungan sambungan koneksi fisik 10 Gbps atau 100.

Latensi untuk solusi ini adalah akumulasi dari hal berikut:

• Latensi antara wilayah tempat resource Anda dihostingkan di Google Cloud dengan lokasi cross-cloud.
• Latensi antara lokasi edge Google dengan lokasi edge CSP lain (seringkali dalam fasilitas yang sama)
• Latensi dari lokasi edge CSP lain tempat Cross-Cloud Interconnect di-deploy ke wilayah tempat resource dihostingkan di CSP.

Meskipun tidak ada jaminan latensi yang ditawarkan, solusi ini umumnya memberikan latensi serendah mungkin dan kecepatan transfer setinggi mungkin antara Google Cloud dengan lingkungan cloud lain lewat alamat IP privat.

Keamanan

Karena traffic melalui Cross-Cloud Interconnect tidak dienkripsi, kami menyarankan untuk menggunakan enkripsi lapisan aplikasi untuk traffic yang bersifat sensitif.

Jika semua traffic harus dienkripsikan, peralatan virtual yang tersedia dari partner Google Cloud di Cloud Marketplace dapat memberikan solusi untuk mengenkripsi traffic ke lingkungan CSP lain.

Keandalan dan SLA

Cross-Cloud Interconnect menggunakan SLA Cloud Interconnect. Agar memenuhi syarat untuk SLA, konfigurasi Cross-Cloud Interconnect harus menggunakan satu atau lebih sambungan koneksi, sebagaimana dijelaskan di bagian Perjanjian tingkat layanan ringkasan Cross-Cloud Interconnect.

SLA mencakup segala hal di sisi Google hingga edge dari jaringan penyedia cloud. Layanan ini tidak dicakup dalam jaringan CSP lain. Untuk informasi selengkapnya, lihat dokumentasi CSP lain untuk SLA pada produk interkoneksi mereka misalnya, SLA AWS Direct Connect atau SLA Azure untuk ExpressRoute.

Harga

Ada biaya per jam untuk setiap koneksi Cross-Cloud Interconnect serta untuk setiap lampiran VLAN yang terhubung ke lingkungan VPC. Traffic yang keluar melalui Cross-Cloud Interconnect dikenai biaya dengan tarif lebih rendah daripada traffic internet. Untuk informasi selengkapnya, lihat Harga Cross-Cloud Interconnect.

Lihat halaman harga CSP lain untuk produk interkoneksi mereka, misalnya, Harga AWS Direct Connect atau Harga Azure ExpressRoute. Umumnya, interkoneksi dikenai biaya bulanan. Tagihan untuk transfer data melalui interkoneksi umumnya dikenai biaya lebih rendah daripada transfer data melalui internet.

Tidak ada biaya terpisah untuk lokasi atau peralatan interkoneksi.

Perbandingan opsi

Opsi yang disajikan mungkin berbeda-beda dalam hal kecepatan, ketersediaan, kompleksitas, keamanan, dan harga. Anda harus mengevaluasi semua opsi secara menyeluruh berdasarkan kebutuhan Anda.

Diagram berikut memandu Anda melalui proses pemilihan salah satu solusi yang disebutkan dalam dokumen ini melalui diagram alur sederhana.

Biasanya, kami dapat merekomendasikan pilihan berikut:

• Untuk berbagai skenario jika data dipertukarkan sesekali atau dengan volume rendah dan transfer data bukan hal utama, transfer data melalui internet merupakan opsi paling mudah dan tetap akan memberikan latensi yang relatif rendah di samping bandwidth yang besar.
• Jika enkripsi atau transfer data dalam jumlah kecil menggunakan alamat IP privat diperlukan, pertimbangkan menggunakan Cloud VPN dan layanan VPN terkelola pada sisi CSP lain.
• Jika Anda mentransfer volume data yang besar, menggunakan Partner Interconnect dengan partner yang mendukung multicloud memberikan beberapa manfaat: kapasitas khusus, biaya transfer data yang lebih rendah, dan bergantung pada topologi, SLA untuk setiap bagian solusi. Kapasitas Partner Interconnect umumnya kurang dari 10 Gbps per koneksi.
• Jika Anda menghubungkan peralatan lokal Anda ke beberapa cloud, menggunakan Dedicated Interconnect melalui POP umum merupakan opsi yang umum. Tindakan tersebut menyertakan kompleksitas tambahan untuk mengelola hardware Anda sendiri dan hubungan dengan fasilitas kolokasi. Kecuali Anda telah memiliki infrastruktur, solusi ini dicadangkan untuk kasus-kasus dengan kecepatan transfer data mencapai 10 Gbps atau lebih.
• Jika Anda tidak ingin terbebani dengan mengelola koneksi silang dan peralatan pemilihan rute dalam POP jarak jauh, Cross-Cloud Interconnect menyediakan solusi di mana Google menangani semuanya untuk Anda.

Langkah selanjutnya

• Tinjau seri panduan Pola dan praktik hybrid dan multicloud.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.