Availability Zone

Availability Zone (AZ) adalah satu atau lebih pusat data diskrit dengan daya redundan, jaringan, dan konektivitas dalam file. Wilayah AWS Zona Ketersediaan memiliki ketersediaan dan toleransi kesalahan yang lebih baik, dan dapat diskalakan dibandingkan infrastruktur pusat data tunggal atau multi tradisional.

Amazon AppStream 2.0 hanya membutuhkan satu subnet untuk armada untuk diluncurkan. Praktik terbaik adalah mengonfigurasi minimal dua Availability Zone, satu subnet per Availability Zone unik. Untuk mengoptimalkan penskalaan otomatis armada, gunakan lebih dari dua Availability Zone. Penskalaan secara horizontal memiliki manfaat tambahan menambahkan ruang IP dalam subnet untuk pertumbuhan, yang tercakup dalam bagian ukuran Subnet berikut dari dokumen ini. AWS Management Console hanya menyediakan dua subnet yang akan ditentukan selama pembuatan armada. Gunakan AWS Command Line Interface(AWSCLI) atau AWS CloudFormation untuk memungkinkan lebih dari dua ID subnet.

Ukuran subnet

Dedikasikan subnet ke AppStream 2.0 armada untuk memungkinkan fleksibilitas dalam kebijakan perutean, dan Daftar Kontrol Akses Jaringan. Tumpukan kemungkinan akan memiliki persyaratan sumber daya yang terpisah. Misalnya, AppStream 2.0 Stacks dapat memiliki persyaratan isolasi yang memberi jalan untuk memisahkan kumpulan aturan. Ketika beberapa armada Amazon AppStream 2.0 menggunakan subnet yang sama, pastikan jumlah Kapasitas Maksimum semua armada tidak melebihi jumlah total alamat IP yang tersedia.

Jika kapasitas maksimum untuk semua armada di subnet yang sama dapat, atau telah, melebihi jumlah total alamat IP yang tersedia, migrasi armada ke subnet khusus. Ini mencegah peristiwa penskalaan otomatis menghabiskan ruang IP yang dialokasikan. Jika total kapasitas armada melebihi ruang IP yang dialokasikan dari subnet yang ditetapkan, gunakan API, atau “update fleet” AWS CLI untuk menetapkan lebih banyak subnet. Untuk informasi lebih lanjut, lihat kuota Amazon VPC, dan cara meningkatkannya.

Ini adalah praktik terbaik untuk mengukur jumlah subnet, mengukur subnet yang sesuai sambil menyimpan kapasitas untuk tumbuh di VPC Anda. Selain itu, pastikan bahwa maksimum armada AppStream 2.0 tidak melebihi total ruang IP yang dialokasikan oleh subnet. Untuk setiap subnetAWS, lima alamat IP dicadangkan saat menghitung jumlah total ruang IP. Menggunakan lebih dari dua subnet dan penskalaan secara horizontal menawarkan beberapa manfaat, seperti:

• Ketahanan yang lebih besar dari kegagalan Availability Zone

• Throughput yang lebih besar saat instance armada penskalaan otomatis

• Penggunaan alamat IP pribadi yang lebih efisien, menghindari pembakaran IP

Saat mengukur subnet untuk Amazon AppStream 2.0, pertimbangkan jumlah total subnet, dan konkurensi puncak yang diharapkan selama pemanfaatan puncak. Ini dapat dipantau menggunakan (InUseCapacity) ditambah kapasitas cadangan (AvailableCapacity) untuk armada. Di Amazon AppStream 2.0, jumlah instance armada yang dikonsumsi dan available-to-be-consumed AppStream 2.0 diberi labelActualCapacity. Untuk mengukur total ruang IP dengan benar, perkirakan yang diperlukanActualCapacity, dan bagi dengan jumlah subnet, dikurangi satu subnet untuk ketahanan, yang ditugaskan ke armada.

Misalnya, jika jumlah maksimum instans armada yang diantisipasi pada puncaknya adalah 1000, dan persyaratan bisnis harus tangguh dalam satu kegagalan Availability Zone, 3 x/23 subnet memenuhi persyaratan teknis dan bisnis.

• /23 = 512 Host - 5 Cadangan = 507 instance armada per subnet

• 3 subnet - 1 subnet = 2 subnet

• 2 subnet x 507 instance armada per subnet = 1.014 instance armada di puncak

Contoh ukuran subnet

Sementara 2 x /22 subnet juga akan memenuhi ketahanan, pertimbangkan hal berikut:

• Alih-alih 1.536 alamat IP yang dicadangkan, menggunakan dua AZ menghasilkan 2.048 alamat IP yang dicadangkan, membuang-buang alamat IP yang bisa masuk ke fungsi lain.

• Jika satu AZ menjadi tidak dapat diakses, kemampuan untuk skala instance armada dibatasi oleh throughput AZ. Hal ini dapat memperpanjang durasiPendingCapacity.

Perutean subnet

Ini adalah praktik terbaik untuk membuat subnet pribadi untuk AppStream 2.0 instance, perutean ke internet publik melalui VPC terpusat untuk lalu lintas keluar. Lalu lintas masuk untuk streaming sesi AppStream 2.0 ditangani melalui layanan Amazon AppStream 2.0 melalui Gateway Streaming: Anda tidak perlu mengonfigurasi subnet publik untuk ini.

Konektivitas Intra-Wilayah

Untuk instance armada AppStream 2.0 yang digabungkan ke Domain Direktori Aktif, konfigurasikan Pengontrol Domain Direktori Aktif di VPC Layanan Bersama di masing-masing. Wilayah AWS Sumber untuk Active Directory dapat berupa Pengontrol Domain berbasis Amazon EC2 atau AWSMicrosoft Managed AD. Perutean antara layanan bersama dan AppStream 2.0 VPC dapat dilakukan melalui koneksi peering VPC atau gateway transit. Meskipun gateway transit memecahkan kompleksitas perutean dalam skala besar, ada sejumlah alasan mengapa peering VPC lebih disukai di sebagian besar pengaturan:

• VPC peering adalah koneksi langsung antara dua VPC (tidak ada hop ekstra).

• Tidak ada biaya per jam, hanya tarif transfer data standar antara Availability Zones.

• Tidak ada batasan bandwidth.

• Support untuk mengakses Grup Keamanan antar VPC.

Hal ini terutama berlaku jika instance AppStream 2.0 terhubung ke infrastruktur aplikasi dan/atau server file dengan kumpulan data besar dalam VPC layanan bersama. Dengan mengoptimalkan jalur ke sumber daya yang umum diakses ini, koneksi peering VPC lebih disukai, bahkan dalam desain di mana semua VPC dan perutean internet lainnya dilakukan melalui gateway transit.

Lalu lintas internet keluar

Sementara routing langsung ke layanan bersama sebagian besar dioptimalkan melalui koneksi peering, lalu lintas keluar untuk AppStream 2.0 dapat dirancang dengan membuat titik keluar internet tunggal dari beberapa VPC menggunakan Transit Gateway. AWS Dalam desain multi-VPC, itu adalah praktik standar untuk memiliki VPC khusus yang mengontrol semua lalu lintas internet keluar. Dengan konfigurasi ini, Transit Gateways memiliki fleksibilitas yang lebih besar, dan kontrol routing atas tabel routing standar yang melekat pada subnet. Desain ini juga mendukung perutean transitif tanpa kerumitan tambahan, dan menghilangkan kebutuhan akan gateway terjemahan alamat jaringan (NAT) redundan, atau instance NAT di setiap VPC.

Setelah semua lalu lintas internet keluar dipusatkan menjadi VPC tunggal, gateway NAT atau instance NAT adalah pilihan desain yang umum. Untuk menentukan mana yang terbaik untuk organisasi Anda, lihat panduan administrasi untuk membandingkan gateway NAT dan instance NAT. AWS Network Firewall dapat memperluas perlindungan di luar kelompok keamanan dan tingkat kontrol akses jaringan dengan melindungi pada tingkat rute dan menawarkan aturan stateless dan stateful dari lapisan 3 hingga 7 dalam model OSI. Untuk informasi selengkapnya, lihat model Deployment untuk AWS Network Firewall. Jika organisasi Anda telah memilih produk pihak ketiga yang melakukan fitur-fitur canggih seperti pemfilteran URL, terapkan layanan ke VPC internet keluar Anda. Ini dapat menggantikan gateway NAT atau instance NAT. Ikuti panduan yang diberikan oleh vendor pihak ketiga.

On-premise

Ketika konektivitas ke sumber daya lokal diperlukan, terutama untuk instance AppStream 2.0 yang digabungkan ke Active Directory, buat koneksi yang sangat tangguh. AWS Direct Connect