Amazon AppStream 2.0

Amazon AppStream 2.0 は、Windows やLinuxのデスクトップアプリケーションをAWS上のインスタンスで実行し、その画面をストリーミングとしてエンドユーザーのブラウザへ配信するフルマネージドのアプリケーション仮想化サービスです。利用者は専用クライアントの導入や高性能な端末を用意せずに、対応ブラウザだけでアプリを使えます。

解決する課題

業務アプリの中には、各端末へのインストールやバージョン管理が煩雑なもの、高いGPUやメモリを要求するもの、ライセンスやデータの所在を厳しく管理したいものがあります。これらを利用者の手元の端末で動かそうとすると、配布・更新・サポートのコストが膨らみ、機密データが各端末に分散するリスクも生まれます。

AppStream 2.0 はアプリの実行をAWS側に集約し、画面だけを配信することで次のような課題を解決します。

• 端末ごとのインストールやアップデート作業をなくし、アプリの配布と更新を中央で一元管理できる
• 重い処理やGPUを要するアプリを、低スペックな端末やシンクライアントからでも利用できるようにする
• アプリとデータがAWS側に留まるため、端末側にデータを残さずに機密情報を扱える
• 短期契約者や外部委託先など、端末を管理下に置けない利用者にも安全にアプリを提供できる

主要概念と用語

• イメージビルダー: アプリをインストール・設定して配信用のイメージを作成するための専用インスタンス。ここで動作確認したアプリをイメージとして保存する。
• イメージ: 配信するアプリと設定をまとめたテンプレート。フリートはこのイメージを基にインスタンスを起動する。
• フリート: ユーザーにアプリを配信するインスタンスの集合。インスタンスタイプやスケーリング、フリート種別をここで設定する。
• スタック: フリートと、ユーザー向けの設定（ストレージの永続化、ユーザー設定の保存、アクセス制御など）を束ねる単位。ユーザーはスタックに対してアクセスする。
• フリート種別: インスタンスの起動・課金方式の違い。常時起動のAlways-On、利用時に起動するOn-Demand、プールから割り当てるElasticの3種類がある。
• ストリーミングプロトコル: 画面のピクセルと音声をクライアントへ送り、入力を戻すための通信。低遅延での操作を実現する。
• ホームフォルダ: ユーザーのファイルをセッションをまたいで永続化する仕組み。裏側ではマネージドのストレージに保存される。
• アプリケーションエンタイトルメント: どのユーザーにどのアプリを見せるかを制御する仕組み。属性に基づいてアプリの表示を絞り込める。

仕様・制限・クォータ

• フリートは画面配信に使うインスタンスタイプを選択でき、汎用・コンピュート最適化・GPU搭載など、アプリの要件に応じたファミリーを使い分けられる。
• ユーザーへの提供方法として、独自のIDプロバイダーと連携するSAMLによるシングルサインオンと、ユーザー単位のURLを発行するユーザープールの方式がある。
• セッションには最大の継続時間やアイドル時の切断時間といった上限を設定でき、放置されたセッションを自動で終了させられる。
• 同時セッション数やフリート数などはアカウント単位・リージョン単位のクォータで管理され、一部は引き上げ申請が可能だが固定の上限もある。
• 提供できるOSやサポートされるブラウザにはバージョンの前提があり、対応状況は変動するため公式ドキュメントで確認する必要がある。

内部の仕組み

ユーザーがスタックにアクセスすると、フリートのインスタンス上で対象のアプリケーションが起動し、その画面がストリーミングプロトコルで圧縮されてブラウザへ送られます。ユーザーのマウスやキーボードの入力は逆方向に送られ、サーバー側のアプリへ反映されます。実際に動いているのはAWS側のインスタンスであり、端末側はあくまで表示と入力の窓口として機能します。

フリートはイメージを基にインスタンスを起動します。Always-On と On-Demand のフリートはあらかじめ確保した容量からセッションを割り当て、スケーリングポリシーに従って容量を増減させます。Elastic フリートはアプリをイメージに焼き込む代わりに、アプリのパッケージを参照してプールされたインスタンスへ割り当てる方式で、容量管理の負担を抑えます。

ホームフォルダやアプリケーション設定の永続化は、セッション終了時にユーザーのファイルや設定をマネージドストレージへ同期し、次回のセッション開始時に復元することで実現されます。これにより、ステートレスなインスタンス上でもユーザーごとの作業環境を維持できます。

設計パターン / ベストプラクティス

• 利用が日中の業務時間に集中するなら、スケジュールやスケーリングポリシーで時間帯に応じて容量を増減させ、夜間の待機コストを抑える。
• 即応性が必要な用途には Always-On、コストを優先する間欠利用には On-Demand、容量管理を簡素にしたい場合は Elastic、と用途でフリート種別を選び分ける。
• アプリのバージョン更新はイメージビルダーで新しいイメージを作り、検証後にフリートへ割り当てることで、本番への影響を抑えながら更新する。
• ユーザーごとに見せるアプリを変えたい場合は、エンタイトルメントと属性を使って表示を制御する。
• 既存の認証基盤がある場合はSAML連携によるシングルサインオンを採用し、ユーザー管理を一元化する。
• VPCやサブネットの設計を行い、社内システムやファイル共有へ必要な経路だけを開ける。

運用・監視

• CloudWatch でフリートの容量使用率や利用可能なインスタンス数、セッションのスロットリングなどのメトリクスを監視し、容量不足や過剰を把握する。
• 利用状況のレポートを有効にすると、セッション開始や継続時間といった利用実績を集計し、課金やキャパシティ計画の根拠にできる。
• CloudTrail でフリートやスタックの作成・変更といった管理操作を記録し、監査に利用する。
• スケーリングポリシーを使って容量を自動調整し、ピーク時の待ち時間と平常時の無駄を両立させる。
• イメージの更新やアプリの入れ替えは定期的な運用作業として手順化し、検証用フリートで確認してから本番へ反映する。

コスト

AppStream 2.0 の料金は、おおむね使用したインスタンスの稼働時間に対する従量課金と、ユーザー単位の月額料金の組み合わせが基本です。Always-On のフリートは待機中も稼働時間として課金される一方、On-Demand のフリートは待機中の料金を抑えられ、利用された時間に対して課金されます。

加えて、ストリーミングに使うインスタンスのタイプやサイズ、データ転送、永続化ストレージの利用量などがコストに影響します。正確な料金は変動するため、設計時には公式の料金ページで最新の体系を確認し、利用パターンに合うフリート種別とスケーリングを選んでコストを最適化してください。

セキュリティ

• アプリとデータはAWS側のインスタンスで処理され、端末にはピクセルだけが届くため、機密データを端末に残さずに扱える。
• フリートのインスタンスはVPC内に配置でき、セキュリティグループやサブネット設計で通信経路を制御できる。
• セッション終了時にインスタンスを破棄・再構築する運用により、ユーザー間でのデータ残留を避けられる。
• IAMによる管理操作の権限分離と、SAML連携によるシングルサインオンで、利用者と管理者のアクセスを適切に分ける。
• クリップボードやファイル転送、印刷などの機能はスタックの設定で制限でき、データの持ち出しを抑制できる。

Well-Architected の観点

セキュリティの柱の観点では、AppStream 2.0 はアプリの実行とデータの保持をAWS側へ集約し、端末にデータを残さない構成を取りやすくします。VPC配置やセッション分離、クリップボード・ファイル転送の制限といった機能は、データ保護とアクセス制御の両面を支えます。

運用上の優秀性の観点では、アプリの配布と更新をイメージとして中央管理できるため、端末ごとの個別作業を排除し、更新の一貫性と切り戻しのしやすさを高められます。CloudWatch や利用状況レポート、CloudTrail による可観測性と監査性も、運用の継続的な改善とトレーサビリティの確保に寄与します。

試験で問われるポイント

関連サービス・比較

仮想デスクトップを提供する Amazon WorkSpaces としばしば比較されます。両者はAWS側で処理を行いブラウザや専用クライアントから利用する点は似ていますが、提供する単位が異なります。

特定の業務アプリだけをブラウザで安全に届けたいなら AppStream 2.0、フル機能のデスクトップを各ユーザーに持たせたいなら WorkSpaces、という使い分けが基本です。

ハンズオン / CLI例

CLI でフリートを作成し、スタックに関連付けてからフリートを起動する例です。あらかじめ作成したイメージ名を指定します。

# イメージを基に On-Demand フリートを作成する
aws appstream create-fleet \
  --name demo-fleet \
  --image-name demo-image \
  --instance-type stream.standard.medium \
  --fleet-type ON_DEMAND \
  --compute-capacity DesiredInstances=2

# スタックを作成する
aws appstream create-stack --name demo-stack

# フリートをスタックに関連付ける
aws appstream associate-fleet \
  --fleet-name demo-fleet \
  --stack-name demo-stack

# フリートを起動して配信を開始する
aws appstream start-fleet --name demo-fleet