Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Konsumen SaaS beroperasi AWS

Bagian ini membahas opsi konektivitas jika Anda dan konsumen Anda beroperasi di. AWS Cloud Skenario ini menawarkan fleksibilitas terbesar karena banyak yang terintegrasi Layanan AWS secara native dan karena kedua belah pihak memiliki akses ke seluruh Layanan AWS portofolio.

Peta nilai jaringan berikut merangkum bagaimana masing-masing opsi ini mendapat skor untuk setiap metrik evaluasi. Untuk informasi selengkapnya tentang metrik evaluasi, lihat Metrik evaluasi dalam panduan ini. Dalam peta, lima mewakili skor terbaik, seperti TCO terendah, isolasi jaringan terbaik, atau waktu terendah untuk memperbaiki. Untuk informasi lebih lanjut tentang cara membaca bagan radar ini, lihat Peta nilai jaringan di panduan ini.

Bagan radar menunjukkan nilai-nilai berikut.

Integrasi dengan AWS PrivateLink

AWS PrivateLinkadalah cara paling cloud-native untuk mengintegrasikan penawaran SaaS. Penyedia SaaS dapat meng-host aplikasi mereka baik di belakang Network Load Balancer. Network Load Balancer langsung terintegrasi dengan Application Load Balancer, Amazon Elastic Container Service (Amazon ECS) Service Elastic Container ECS), Amazon Elastic Kubernetes Service(Amazon EKS), dan grup Auto Scaling. Dimungkinkan juga untuk merutekan lalu lintas dari Network Load Balancer ke titik akhir VPC antarmuka di akun penyedia SaaS. Ini membantu Anda menggunakan API untuk menjangkau aplikasi, seperti melalui Amazon API Gateway atau AWS AppSync. Jika aplikasi Anda memerlukan akses ke sumber daya di lingkungan pelanggan yang tidak seimbang beban, seperti database, Anda dapat menggunakan titik akhir VPC sumber daya.

AWS PrivateLink mendukung bandwidth hingga 100 Gbps per Availability Zone. Diagram berikut menunjukkan konfigurasi dasar dengan beberapa kemungkinan integrasi. Ini menghubungkan dua akun konsumen ke akun penyedia SaaS melalui. AWS PrivateLink Ada titik akhir layanan di akun konsumen dan Network Load Balancer di akun penyedia SaaS.

Berikut ini adalah manfaat dari pendekatan ini:

Berikut ini adalah kelemahan dari pendekatan ini:

Berbagi layanan Amazon VPC Lattice

Untuk menggunakan Amazon VPC Lattice sebagai opsi konektivitas untuk aplikasi SaaS Anda, pertama-tama Anda membuat satu atau beberapa layanan VPC Lattice yang mewakili komponen aplikasi SaaS Anda. Anda mengonfigurasi pendengar dan aturan perutean untuk mengarahkan lalu lintas ke target backend Anda, seperti instans, wadah, atau fungsi Amazon EC2. AWS Lambda Untuk informasi selengkapnya, lihat Menghubungkan layanan Saas dalam jaringan layanan VPC LatticeAWS (posting blog). Dari segi konsep, ini hampir sama dengan mengkonfigurasi Application Load Balancer. Kemudian, Anda membagikan layanan SaaS Anda secara aman dengan pelanggan Akun AWS atau organisasi dengan menggunakan AWS Resource Access Manager (AWS RAM), menentukan izin apa yang mereka miliki. Setelah pelanggan menerima pembagian sumber daya, mereka dapat mengaitkan layanan SaaS Anda dengan jaringan layanan VPC Lattice yang ada atau yang baru dibuat untuk mengaktifkan komunikasi. service-to-service

Setiap layanan VPC Lattice dapat mendukung hingga 10 Gbps dan 10.000 permintaan per detik per Availability Zone. Dengan menerapkan kebijakan autentikasi, pelanggan Anda dapat memiliki kontrol yang baik atas layanan dan sumber daya mana yang dapat mengakses aplikasi SaaS. Anda dapat menggunakan gateway sumber daya untuk mengakses sumber daya yang memerlukan koneksi TCP. Misalnya, ini mungkin kluster Amazon EKS yang Anda kelola, atau mungkin sumber daya yang dikelola pelanggan yang perlu diakses aplikasi Anda. Untuk informasi selengkapnya tentang penggunaan gateway sumber daya untuk penawaran SaaS, lihat Memperluas kemampuan SaaS Akun AWS di seluruh AWS PrivateLink penggunaan dukungan untuk sumber daya VPC (posting blog).AWS

Diagram berikut menunjukkan konfigurasi VPC Lattice tingkat tinggi dengan beberapa contoh integrasi. Ini menggunakan jaringan layanan yang dikelola pelanggan untuk mengakses aplikasi SaaS.

Berikut ini adalah manfaat dari pendekatan ini:

Berikut ini adalah kelemahan dari pendekatan ini:

Membuat koneksi peering VPC

Saat Anda menggunakan peering VPC untuk menghubungkan VPC penyedia SaaS dengan VPC konsumen, kedua belah pihak dapat memulai koneksi. Ini memerlukan konfigurasi yang tepat dari grup keamanan, firewall, dan daftar kontrol akses jaringan (NACLs) di kedua akun. Jika tidak, lalu lintas yang tidak diinginkan mungkin masuk ke jaringan melalui koneksi peering. Anda dapat menggunakan grup keamanan untuk mereferensikan grup keamanan dari peered VPCs. Ini dapat membantu Anda mengontrol akses ke aplikasi Anda karena grup keamanan daftar izin memberikan kontrol akses yang lebih eksplisit dan terperinci dibandingkan dengan alamat IP daftar yang diizinkan.

Dengan VPC peering, penawaran SaaS dapat dicapai melalui layanan atau sumber daya yang digunakan di VPC. Sebagian besar aplikasi SaaS berada di belakang Application Load Balancer atau Network Load Balancer. AWS AppSync private APIs atau Amazon API Gateway private APIs adalah titik masuk umum lainnya ke aplikasi SaaS karena mereka dapat menjadi target melalui koneksi peering melalui titik akhir VPC antarmuka.

Setelah Anda membuat koneksi peering, Anda harus memperbarui tabel rute untuk VPCs di kedua akun untuk menentukan koneksi peering sebagai lompatan berikutnya untuk rentang CIDR masing-masing. Solusi ini direkomendasikan hanya untuk penyedia SaaS yang memiliki beberapa konsumen karena mengelola beberapa koneksi peering dengan cepat menjadi terlalu rumit.

Diagram berikut menunjukkan konfigurasi dasar dengan beberapa kemungkinan integrasi. VPCs di dua akun konsumen memiliki koneksi peering dengan VPC di akun penyedia SaaS.

Berikut ini adalah manfaat dari pendekatan ini:

Berikut ini adalah kelemahan dari pendekatan ini:

Menghubungkan VPCs dengan AWS Transit Gateway

Saat Anda terhubung AWS Transit Gateway, itu membuat lampiran VPC dan menyebarkan antarmuka jaringan di subnet setiap Availability Zone yang seharusnya VPCs merutekan lalu lintas ke dan dari VPC. Disarankan untuk memiliki /28 subnet khusus di setiap Availability Zone untuk lampiran VPC. Untuk informasi selengkapnya, lihat Praktik terbaik desain Gateway Transit VPC Amazon. VPCs Memerlukan tabel rute yang diperbarui untuk mengirim lalu lintas melalui antarmuka jaringan yang digunakan, dan tabel rute Transit Gateway perlu diperbarui sesuai dengan itu. Dalam konfigurasi multi-penyewa, Anda ingin VPC penyedia SaaS memiliki rute ke semua konsumen. VPCs Konsumen VPCs harus memiliki rute hanya ke VPC penyedia SaaS.

Transit Gateway sangat tersedia berdasarkan desain. Ini mendukung pemantauan dengan VPC Flow Logs, dan bandwidth maksimum untuk lampiran Transit Gateway adalah 100 Gbps per Availability Zone. Seperti peering VPC, pendekatan ini memungkinkan referensi grup keamanan lintas-VPC, yang menyederhanakan kontrol akses antar lingkungan.

Ada dua opsi utama untuk menghubungkan konsumen dengan penawaran SaaS Anda dengan Transit Gateway.

Opsi 1: Menggunakan RAM

Pada opsi pertama, penyedia layanan berbagi Transit Gateway dengan konsumen dengan menggunakan AWS Resource Access Manager (AWS RAM). Hal ini memungkinkan konsumen untuk menyebarkan lampiran VPC di akun mereka sendiri. Diagram berikut menunjukkan opsi ini pada tingkat tinggi.

Opsi 2: Gerbang transit peered

Opsi kedua adalah mengintip gateway transit Anda dengan gateway transit di akun konsumen. Ini memberi konsumen lebih banyak fleksibilitas karena mereka sekarang dapat sepenuhnya mengontrol tabel rute di dalam gateway transit mereka. Misalnya, mereka dapat mengatur inspeksi terpusat antara layanan dan beban kerja mereka. Kelemahan dari opsi ini hanya perutean statis antara gateway transit yang didukung. Diagram berikut menunjukkan opsi ini pada tingkat tinggi.

Berikut ini adalah manfaat dari pendekatan ini:

Berikut ini adalah kelemahan dari pendekatan ini: