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

Anti-pola untuk akses jaringan di AWS Cloud

Anti-pola adalah solusi yang sering digunakan untuk masalah berulang di mana solusinya kontra-produktif, tidak efektif, atau kurang efektif daripada alternatif. Opsi desain yang disebutkan dalam bagian ini biasanya berfungsi, tetapi mereka datang dengan kerugian yang signifikan. Jika memungkinkan, mereka harus dihindari karena alternatif yang lebih baik tersedia.

Ketidakcocokan Zona Ketersediaan dengan AWS PrivateLink

Saat menyediakan akses ke aplikasi melalui AWS PrivateLink, konsumen SaaS dapat membuat titik akhir VPC antarmuka hanya di Availability Zones tempat aplikasi digunakan. Misalnya, jika aplikasi diterapkan di use1-az1 danuse1-az2, konsumen tidak dapat menerapkan titik akhir VPC di. use1-az3 Kami menyarankan Anda menerapkan penawaran SaaS di setiap Availability Zone. Mayoritas Wilayah AWS memiliki tiga Availability Zone, meskipun beberapa memiliki lebih banyak. Untuk daftar lengkap, lihat Wilayah dan Availability Zone. Pertimbangkan jumlah Availability Zone saat memilih Wilayah AWS.

Jika penyedia SaaS memilih untuk tidak menerapkan di semua Availability Zone, ada beberapa konsekuensinya. Asumsikan penawaran SaaS diterapkan di use1-az1 danuse1-az2, tetapi konsumen menggunakan ketiga Availability Zone, termasuk. use1-az3 Titik akhir VPC antarmuka digunakan di sisi konsumen di use1-az1 danuse1-az2, dan sekarang aplikasi use1-az3 perlu mengakses salah satu titik akhir ini. Pertama-tama, lalu lintas harus diizinkan dari subnet di Availability Zone yang tak tertandingi ke titik akhir VPC masing-masing. Konsumen dapat memutuskan untuk menggunakan nama AWS PrivateLink DNS regional, yang dapat menyelesaikan ke titik akhir VPC dan yang mendistribusikan lalu lintas secara merata di antara keduanya. Atau konsumen mungkin memilih untuk mengirim lalu lintas langsung ke titik akhir, sepertiuse1-az2. Ini menghasilkan 67% lalu lintas yang tiba di sisi penyedia use1-az2 dan 33% masuk. use1-az1 Gambar berikut menggambarkan skenario ini.

Dengan jumlah konsumen yang signifikan dan distribusi lalu lintas yang tidak merata, beban kerja mungkin mengalami masalah kapasitas di satu Availability Zone dan berada di bawah kapasitas di zona lain. Untuk mengatasi masalah itu, penyedia SaaS dapat memutuskan untuk memuat keseimbangan lalu lintas secara merata di sisi mereka dengan mengaktifkan penyeimbangan beban lintas zona pada Network Load Balancer. Ini menimbulkan biaya tambahan.

Jika hanya satu Availability Zone yang dicocokkan oleh penyedia layanan, maka semua lalu lintas akan masuk melalui satu titik akhir. Ini menciptakan ketidakseimbangan yang lebih besar. Akibatnya, penawaran SaaS tidak lagi tersedia untuk konsumen. Tidak masalah bagi konsumen jika aplikasi disajikan melalui Availability Zone tambahan yang tidak mereka gunakan sendiri. Dalam kasus terburuk, penyedia SaaS mungkin tidak dapat melayani konsumen yang tidak menggunakan Zona Ketersediaan yang sama.

Dalam kasus yang jarang terjadi bahwa tidak ada opsi yang layak bagi penyedia SaaS untuk menyediakan aplikasi mereka di semua Availability Zone, dimungkinkan juga untuk membuat subnet hanya di Availability Zone yang hilang dan kemudian memperluas layanan ke Availability Zone kosong tersebut. Penyeimbangan beban lintas zona kemudian dapat mendistribusikan lalu lintas masuk melalui titik akhir aplikasi aktual di Availability Zone lainnya.

AWS Site-to-Site VPN hubungan antara Akun AWS

Perusahaan yang bermigrasi dari lingkungan lokal ke cloud terkadang mencoba mengangkat dan menggeser seluruh jaringan. Hal ini dapat menyebabkan masalah karena ada perbedaan yang signifikan antara praktik jaringan lokal dan cloud. Jika pergeseran pola pikir ini tidak terjadi, hal-hal seperti AWS Site-to-Site VPN koneksi dari satu VPC ke VPC lain dapat terjadi. Pendekatan ini gagal memanfaatkan layanan jaringan yang dibangun khusus di AWS Cloud, yang menyederhanakan manajemen dan meningkatkan kinerja. Beradaptasi dengan desain cloud-native membantu mengurangi overhead operasional dan menghasilkan konektivitas yang lebih andal dan terukur di antaranya. VPCs

Jika Anda berpikir untuk menyediakan opsi konektivitas ini sebagai penyedia SaaS, tanyakan pada diri Anda atau konsumen mengapa AWS Site-to-Site VPN harus digunakan. Kemudian, bekerja mundur dari persyaratan tersebut untuk menemukan opsi konektivitas yang lebih baik. Bagian Membandingkan kemampuan layanan dari panduan ini berisi matriks yang dapat Anda gunakan untuk membantu mengidentifikasi opsi. Kemudian, Anda dapat mengerjakan bagian yang relevan dari panduan ini untuk menemukan pendekatan arsitektur yang membahas kasus penggunaan Anda.