クラウド上に自分専用のデスクトップ（DaaS: Desktop as a Service）を持つと、 タブレットや低スペックの端末からでも、いつもの作業環境に入れる。 問題はコストと経路の安全性である。商用DaaSは月額固定で高く、 自前で建てるとデスクトップをインターネットに直接晒しがちになる。
本稿では、ブラウザから起動・停止でき、VPN経由でのみ到達でき、 使う時だけ課金される構成を解説する。
ページ構成
- 全体像: 3つの構成要素
- 利用の流れ
- 各EC2サーバーの構成
- コスト設計: 「使う時だけ」を徹底する
- セキュリティ設計: 入口はVPNだけ
- 次期計画: AWS Client VPNのオンデマンド作成
- まとめ
1. 全体像: 3つの構成要素
| 構成要素 | 実体 | 常時稼働か |
|---|---|---|
| 管理ポータル | CloudFront + S3 + Cognito + Lambda（すべてサーバレス） | 常時（ただし従量課金でほぼゼロ円） |
| VPNサーバー | EC2（スポット）上のL2TP/IPsecサーバー | 使う時だけ起動 |
| デスクトップ | EC2（スポット）のWindows / Linux | 使う時だけ起動 |
鍵になるのは「常時いる部分」をすべてサーバレスにしたこと。 EC2は1台も常時稼働させず、それでも「ブラウザを開けばいつでも起動できる」入口だけは常に生きている。
2. 利用の流れ
- VPNはOS標準クライアント（タブレット含む）で接続できるL2TP/IPsecを採用。専用アプリの導入が不要
- デスクトップにはVPNトンネル内のプライベートアドレスで直接RDP接続する。インターネット側にRDPポートは一切開けない
- 停止し忘れに備え、毎晩決まった時刻に全インスタンスを自動停止するスケジュールを仕込んである
3. 各EC2サーバーの構成
VPNサーバー（ARM小型インスタンス・スポット）
| 項目 | 設計 |
|---|---|
| インスタンス | ARM系の小型（2vCPU/2GBクラス）。VPNの中継には十分 |
| ネットワーク | NICを2枚持つ。1枚はパブリックサブネット（VPN接続の受け口）、もう1枚はプライベートサブネット（デスクトップ側への足） |
| 受け付けるポート | IPsec関連（UDP 500/4500）のみ。SSHは開けない（管理はSSM Session Manager経由） |
| ソフトウェア | 起動時のユーザーデータでVPNサーバーを自動構築。認証情報はSecrets Managerから初回構築時にのみ取得し、以後はVPNサーバー側で管理 |
| クライアントの出口 | VPN接続した端末のインターネット向き通信は、プライベート側NIC → NATインスタンス経由に誘導。VPNサーバー自身のグローバルアドレスを晒さない |
デスクトップ（汎用インスタンス・スポット）
| 項目 | Windows | Linux |
|---|---|---|
| インスタンス | 汎用2vCPU/8GBクラス | 同左 |
| 配置 | プライベートサブネット（インターネットから直接到達不可） | 同左 |
| 画面転送 | 標準のRDP | デスクトップ環境 + RDP互換サーバーを起動時に自動構築 |
| 初期認証情報 | 乱数生成しパラメータストアに保存。初回ログイン後に変更 | 同左 |
| ログ | 構築ログ・画面転送サーバーのログをCloudWatch Logsへ集約 | 同左 |
NATインスタンス（ARM最小・オンデマンド）
プライベートサブネットからの外向き通信（OSアップデート等）にはNAT Gatewayではなく、 最小クラスのEC2をNATインスタンスとして使う。NAT Gatewayの固定費（月数千円）に対し、 この用途の帯域なら最小インスタンスで十分であり、デスクトップ停止中は一緒に停止もできる。
4. コスト設計: 「使う時だけ」を徹底する
| 施策 | 効果 |
|---|---|
| スポットインスタンス（永続リクエスト） | オンデマンド比で大幅割引。中断されても永続リクエストが再起動を試みる |
| 使う時だけ起動 | 1日2時間 × 20日利用なら、常時稼働の約1/18の稼働時間 |
| 夜間自動停止 | 消し忘れの上限を「その日の夜まで」に制限 |
| 常時部分のサーバレス化 | ポータルの固定費が実質ゼロ |
| NATインスタンス | NAT Gatewayの固定費を回避 |
スポットの中断リスクは「個人の作業環境」という用途なら許容しやすい。 中断時は数分後に再起動すればよく、作業データはインスタンスのボリュームに残っている。
5. セキュリティ設計: 入口はVPNだけ
| レイヤー | 制御 |
|---|---|
| ポータル | IDプロバイダ連携ログイン + 許可リストにあるアカウントのみサインイン可 |
| インターネットからの入口 | VPNサーバーのIPsecポートのみ。RDP/SSHは一切公開しない |
| デスクトップへの到達 | VPNトンネル経由のプライベートアドレスのみ。Security GroupもVPC内からの接続に限定 |
| サーバー管理 | SSHの代わりにSSM Session Manager。鍵の配布・管理が発生しない |
| 権限 | 起動停止APIのLambdaは対象タグの付いたインスタンスの起動・停止のみ許可 |
「デスクトップをインターネットに晒さない」を出発点に、 到達経路（ネットワーク）と操作権限（IAM）を別々のレイヤーで絞っている。
6. 次期計画: AWS Client VPNのオンデマンド作成
現構成のVPNサーバーはEC2の自前運用であり、OS・VPNソフトウェアの面倒を自分で見る必要がある。 マネージドなAWS Client VPNに置き換えたいが、Client VPNはエンドポイントを作成している時間に対して課金され、 常設すると月数千円の固定費になる。個人利用ではこれが導入をためらわせる。
そこで次期計画では、**Client VPNエンドポイント自体を「使う時だけTerraformで作成し、使い終わったら破棄する」**パターンを検討している。
- 証明書や設定値は保持し、エンドポイントというリソースだけを作り直す
- インフラがコードで定義されているからこそ、「リソースの存在自体をオンデマンドにする」という選択肢が生まれる
- EC2の自前VPN運用（OSパッチ・ソフト更新）から解放され、待機コストゼロとマネージドの両立を狙う
7. まとめ
| 設計判断 | 内容 |
|---|---|
| 常時稼働はサーバレスだけ | 「いつでも起動できる入口」と「使う時だけのEC2」を分離 |
| 入口はVPNに一本化 | RDP/SSHを公開せず、OS標準クライアントで繋がるL2TP/IPsecを採用 |
| スポット + 自動停止 | 割引と「消し忘れ上限」の二段構えでコストを抑える |
| 次の一手はリソースのオンデマンド化 | IaC前提なら「作って壊す」が運用手順になる |
DaaSは「贅沢な常時稼働サービス」である必要はない。 起動停止の導線をブラウザまで持ってくることで、クラウドの従量課金を個人の作業環境にそのまま適用できる。