翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # アベイラビリティーゾーン [https://aws.amazon.com/about-aws/global-infrastructure/regions_az/](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)は、AWS リージョン の冗長電源、ネットワーク、および接続を備えた 1 つ以上の個別のデータセンターです。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。 Amazon AppStream 2.0 では、フリートを起動するために必要なサブネットは 1 つだけです。ベストプラクティスは、少なくとも 2 つのアベイラビリティーゾーン (固有のアベイラビリティーゾーンごとに 1 つのサブネット) を設定することです。フリートの自動スケーリングを最適化するには、3 つ以上のアベイラビリティーゾーンを使用してください。水平スケーリングには、サブネットに IP スペースを追加して拡張できるという利点があります。これについては、このドキュメントの次の「サブネットのサイズ設定」セクションで説明します。[https://aws.amazon.com/console/](https://aws.amazon.com/console/)では、フリートの作成時に指定できるサブネットは 2 つだけです。[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) (AWS CLI) または AWS CloudFormation を使用して、3 つ以上の[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) を許可します。 ## サブネットのサイズ設定 ルーティングポリシーとネットワークアクセスコントロールリストを柔軟に設定できるように、サブネットを AppStream 2.0 フリート専用にします。多くの場合、スタックには個別のリソース要件があります。例えば、AppStream 2.0 スタックには分離要件があり、ルールセットを区分する方法を提供します。複数の Amazon AppStream 2.0 フリートが同じサブネットを使用する場合は、すべてのフリートの**最大キャパシティ**の合計が、使用可能な IP アドレスの総数を超えないようにします。 同じサブネット内のすべてのフリートの最大キャパシティが、使用可能な IP アドレスの総数を超える可能性がある、または超えた場合は、フリートを専用のサブネットに移行します。これにより、自動スケーリングイベントによって割り当てられた IP スペースが枯渇するのを防ぐことができます。フリートの合計キャパシティが、割り当てられたサブネットの割り当てられた IP スペースを超える場合は、API または AWS CLI の「*[フリートの更新](https://docs.aws.amazon.com/cli/latest/reference/appstream/update-fleet.html)」*を使用してさらにサブネットを割り当てます。詳細については、「[https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)」を参照してください。 ベストプラクティスとしては、サブネット数をスケールアウトし、それに応じてサブネットのサイズを設定して、VPC のキャパシティを拡大することです。また、AppStream 2.0 フリートの最大数が、サブネットによって割り当てられた合計 IP スペースを超えないようにします。IP スペースの合計量を計算する際には、AWS のサブネットごとに [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)。3 つ以上のサブネットを使用して水平方向にスケーリングする場合、次のようないくつかの利点があります。 + アベイラビリティーゾーンの障害に対する耐性の向上 + フリートインスタンスを自動スケーリングする場合のスループットの向上 + プライベート IP アドレスをより効率的に使用して IP バーンを回避 Amazon AppStream 2.0 のサブネットのサイズを設定するときは、サブネットの総数と、使用率のピーク時に予想されるピーク同時実行数を考慮してください。これは、フリートに対して (`InUseCapacity`) とリザーブドキャパシティ (`AvailableCapacity`) を使用することでモニタリングできます。Amazon AppStream 2.0 では、使用済みおよび使用可能な AppStream 2.0 フリートインスタンスの合計に `ActualCapacity` のラベルが付けられます。合計 IP スペースを適切なサイズに設定するには、必要な `ActualCapacity` を予測し、フリートに割り当てられたサブネットの数から、耐障害性のための 1 つのサブネットを引いた数で割ります。 例えば、ピーク時に予測されるフリートインスタンスの最大数が 1000 で、1 つのアベイラビリティーゾーンに障害が発生しても回復力を維持することがビジネス要件である場合、3 x/23 サブネットで技術要件とビジネス要件を満たすことができます。 + /23 = 512 ホスト — 5 リザーブド = サブネットあたり 507 フリートインスタンス + 3 サブネット — 1 サブネット = 2 サブネット + 2 サブネット x サブネットあたり 507 フリートインスタンス = ピーク時 1,014 フリートインスタンス ![\[3 つのサブネットを使用する場合と、2 つのサブネットを使用する場合と比べてキャパシティが減少する様子を示す図。合計が 1,521 のフリートインスタンスから 1,014 のフリートインスタンスに変更されました。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/images/subnet-sizing.png) *サブネットのサイズ設定の例* 2 x /22 サブネットでも耐障害性は十分ですが、次の点を考慮してください。 + 1,536 の IP アドレスを予約する代わりに、2 つの AZ を使用すると 2,048 の IP アドレスが予約され、他の機能に使用できる IP アドレスが無駄になります。 + 1 つの AZ にアクセスできなくなった場合、フリートインスタンスをスケールアウトする機能は AZ のスループットによって制限されます。これにより、`PendingCapacity` の期間が延長される可能性があります。 ## サブネットのルーティング AppStream 2.0 インスタンス用のプライベートサブネットを作成し、アウトバウンドトラフィック用に一元管理された VPC を介してパブリックインターネットにルーティングするのがベストプラクティスです。AppStream 2.0 セッションストリーミングのインバウンドトラフィックは、ストリーミングゲートウェイ経由で Amazon AppStream 2.0 サービスを通じて処理されます。このためにパブリックサブネットを設定する必要はありません。 ## リージョン内の接続 Active Directory ドメインに参加している AppStream 2.0 フリートインスタンスでは、各 AWS リージョン の共有サービス VPC で Active Directory ドメインコントローラを設定します。Active Directory のソースは、[https://docs.aws.amazon.com/cli/latest/reference/appstream/create-fleet.html](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-fleet.html) ベースのドメインコントローラでも [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) でもかまいません。共有サービスと AppStream 2.0 VPC 間のルーティングは、[https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html)または[https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html)のいずれかを介して行うことができます。トランジットゲートウェイは大規模なルーティングの複雑さを解決しますが、VPC ピアリングがほとんどの設定で望ましい理由はいくつかあります。 + VPC ピアリングは 2 つの VPC 間の直接接続です (余分なホップはありません)。 + 時間単位の課金はなく、アベイラビリティーゾーン間の標準データ転送料金のみです。 + 帯域幅に制限はありません。 + VPC 間のセキュリティグループへのアクセスのサポート。 これは、AppStream 2.0 インスタンスが、共有サービス VPC 内の大きなデータセットを持つアプリケーションインフラストラクチャやファイルサーバーに接続する場合に特に当てはまります。これらの一般的にアクセスされるリソースへのパスを最適化することで、他のすべての VPC およびインターネットルーティングがトランジットゲートウェイを介して実行される設計でも、VPC ピアリング接続が優先されます。 ## アウトバウンドインターネットトラフィック 共有サービスへの直接ルーティングはほとんどピアリング接続を通じて最適化されますが、AppStream 2.0 のアウトバウンドトラフィックは、[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/)。マルチ VPC 設計では、すべての送信インターネットトラフィックを制御する専用 VPC を用意するのが標準的な方法です。この設定では、トランジットゲートウェイがより柔軟になり、サブネットにアタッチされた標準ルーティングテーブルでのルーティングを制御できるようになります。この設計では、複雑さを増すことなく推移的なルーティングもサポートされ、冗長なネットワークアドレス変換（NAT）ゲートウェイ、つまり各 VPC 内の NAT インスタンスが不要になります。 すべてのアウトバウンドインターネットトラフィックが単一の VPC に集中化されると、NAT ゲートウェイまたは NAT インスタンスが一般的な設計上の選択肢になります。どちらが組織にとって最適かを判断するには、管理ガイドの [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)のレイヤー 3 から 7 までのステートレスルールとステートフルルールを提供することで、セキュリティグループやネットワークのアクセス制御レベルを超えて保護を拡張できます。詳細については、「[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/)」を参照してください。組織が URL フィルタリングなどの高度な機能を実行するサードパーティ製品を選択した場合は、そのサービスをアウトバウンドインターネット VPC にデプロイします。これは NAT ゲートウェイや NAT インスタンスの代替となります。サードパーティベンダーが提供するガイドラインに従ってください。 ## オンプレミス オンプレミスのリソースへの接続が必要な場合、特に Active Directory に参加している AppStream 2.0 インスタンスへの接続が必要な場合は、[https://aws.amazon.com/directconnect/resiliency-recommendation/](https://aws.amazon.com/directconnect/resiliency-recommendation/)を確立してください。