

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

# Availability Zone
<a name="availability-zones"></a>

 [https://aws.amazon.com/about-aws/global-infrastructure/regions_az/](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) (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. [https://aws.amazon.com/console/](https://aws.amazon.com/console/) hanya menyediakan dua subnet yang akan ditentukan selama pembuatan armada. Gunakan [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appstream/create-fleet.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appstream/create-fleet.html)(AWSCLI) atau AWS CloudFormation untuk memungkinkan lebih dari dua ID [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-appstream-fleet-vpcconfig.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-appstream-fleet-vpcconfig.html). 

## Ukuran subnet
<a name="subnet-sizing"></a>

 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](https://docs.aws.amazon.com/cli/latest/reference/appstream/update-fleet.html)” AWS* CLI untuk menetapkan lebih banyak subnet. Untuk informasi lebih lanjut, lihat [https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). 

 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, [https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4) 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 label`ActualCapacity`. Untuk mengukur total ruang IP dengan benar, perkirakan yang diperlukan`ActualCapacity`, 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 

![\[Diagram menunjukkan kapasitas berkurang saat menggunakan tiga subnet versus dua subnet. Total perubahan dari 1.521 instance Armada menjadi 1.014 instance Armada.\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/images/subnet-sizing.png)


 *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 durasi`PendingCapacity`. 

## Perutean subnet
<a name="subnet-routing"></a>

 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
<a name="intra-region-connectivity"></a>

 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 [https://docs.aws.amazon.com/cli/latest/reference/appstream/create-fleet.html](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-fleet.html) atau [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) Managed AD. [https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html) 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
<a name="outbound-internet-traffic"></a>

 Sementara routing langsung ke layanan bersama sebagian besar dioptimalkan melalui koneksi peering, lalu lintas keluar untuk AppStream 2.0 dapat dirancang dengan [https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/) 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 [https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html). [https://aws.amazon.com/network-firewall/](https://aws.amazon.com/network-firewall/) [https://en.wikipedia.org/wiki/OSI_model](https://en.wikipedia.org/wiki/OSI_model) Untuk informasi selengkapnya, lihat [https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-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
<a name="on-premises"></a>

 Ketika konektivitas ke sumber daya lokal diperlukan, terutama untuk instance AppStream 2.0 yang digabungkan ke Active Directory, buat koneksi yang sangat [https://aws.amazon.com/directconnect/resiliency-recommendation/](https://aws.amazon.com/directconnect/resiliency-recommendation/). AWS Direct Connect 