はじめに
このブログは「Cloud Workstationsを踏み台サーバとしても使ってみよう（前編）」の続きです。
前編では、Cloud Workstationsを踏み台サーバとして利用できることを見てきました。後編では、従来はVMを立てて踏み台サーバを構成していた際の課題「管理や構築の負担」、「コスト低下の頭打ち」をCloud Workstationsで解決できるのかを見ていきます。
対象読者
企業向けにクラウドを利用しているなど、セキュリティが求められるクラウドを担当している方を想定しています。
結論
Cloud Workstationsを踏み台サーバとして利用することができます。従来のVMサーバで踏み台サーバを構成していた課題に対しては、管理や構築の負担は下がります。しかし、コストはケースバイケースで上下します。そのため、コストについてTCOの観点も含めて利用ケースに合うことを確認してから利用を検討しましょう。
目次
1. CloudWorkstationsで従来の課題を解決できるか
1.1. OS管理
Cloud Workstationsは、マネージドなVM上で稼働するコンテナが利用者に提供されます。
WorkstationsのVMは、Googleによって管理されているためユーザが管理する必要はありません。コンテナイメージは、ベースイメージがGoogleによって管理されており自動的に最新化されます（今回はイメージをカスタマイズして使うため、自動的に最新化するやり方を別途用意する必要がありますが、やり方は提示されています（参照先））。
また、WorkstationのOSユーザーは、Workstation作成時に自動的に作成されます。Google CloudのIAMと統合されているため、OSユーザーの管理を行う必要はありません 。
カスタムイメージを自動的に更新させる仕組みを用意する必要はありますが、OS管理負担は下がりそうです。
1.2. コスト
Cloud Workstationsのランニングコスト構成は次のようになっています（2023年7月14日時点）。
＜コスト試算の条件（詳細はこちらを参照）＞
・リージョンはus-central1の場合での試算
・マシンタイプはe2-standard-4(4vCPU, 16GBメモリ)
・Persistent Diskサイズは100GB
・平日8時間利用
Cloud Workstationsのコストは、GCEのコストに管理手数料とクラスタ料金が加わっているため、単純にGCEを利用する場合と比べるとコストは高くなります。これは、GoogleがVMを管理するコストや「1.3. アクセス制御の構成」で触れるように、WorkstationをVPCの中にプライベートに配置し安全にアクセスできる構成をとるためのコストも加わるためだと思います。
一方で、この料金構成は、一般的な使い方ではクラスタは１つ（複数のリージョン、異なるVPCに接続させる場合にクラスタは複数）なので、Workstationを複数台利用するケースで1台あたりのコストメリットが出てくる構成になっています。利用台数と1台あたりのコスト低下の関係は以下にまとめてみました。
また、Cloud Workstationsは利用されていないと自動停止する機能があります。こちらが上手く効果するとコストが下がるケースが期待できます。例えば、踏み台サーバは長時間使うものではないため、GCEと比較してきめ細かく起動停止されることでコストが下がるケースが多くなると思います。
コストは一見すると高くなるように見えますが、次のポイントを考慮に入れ、実際の利用ケースに照らして適切なコストになりそうか考える必要がありそうです。
・Cloud Workstationsの管理手数料、クラスタ料金が、従来のOS管理負担、接続構成にかかる運用コストと比較して適当かどうか
・多数のシステムを稼働しており、それぞれに踏み台サーバを用意しているなど、コストメリットが得られる利用ケースかどうか
・こまめに起動停止されることでコストが抑えられそうか
（とはいえ、コストメリットは分かりにくいですね、、。今後のサービス改善にて、コストメリットが分かりやすく得られるようになることを期待したいです。Googleさんにも伝えていきます！）
1.3. アクセス制御の構成
踏み台サーバに対して社外からアクセスを必要とする場合、踏み台サーバを外部公開する必要があります。直接外部に公開することは、セキュリティ上のリスクがあるため避ける必要があります。そのため、一般的には踏み台サーバを内部におき（パブリックIPを付与しない）、外部からはVPN経由でアクセスさせるなどの安全な接続手段を別途用意します。Cloud Workstationsでは、外部から安全にアクセスさせるための機能（ユーザー認証、通信暗号化、対象へのアクセス）が提供されており、社外からの安全なアクセス構成を別途用意することなく実現できます。（下図の参考元）
2. 実際の利用でさらに考えること
こちらはおまけになります。Cloud Workstationsを踏み台サーバとして利用することが適切なケースでは、実際の利用を想定するといくつか課題があるため考えてみます。
2.1. クラウド内のアクセス制御
前編で見たように、WorkstationからVPC内のサーバやマネージドサービスへアクセスできます。実際には、VPC内はFirewallルールで必要な通信制御を行います。セキュリティの厳しい環境では、基本的に全ての通信を拒否し、許可する通信だけ許可ルールを作成します。そのような環境でも、Workstationは必要な接続先だけ許可ルールを作ることで通信制御ができそうです。Firewallルールの送信元の指定には、サービスアカウントを用いることがより良いとされています（VPC firewall rules）。WorkstationはConfigurationごとにサービスアカウントを設定できるため、GCEのときと同じように踏み台サーバという用途のサービスアカウントを用意し、同じ用途のサーバからの通信をまとめて効率的に通信制御することができます。
2.2. 外部からのアクセスを制御
Workstationへのアクセスは、IAMで認証され、通信は暗号化されているので、外部からでも安全に利用できます。しかし、インターネット上のどこからでもアクセスできます。企業における実際の利用では、アクセス元を限定したいという要望があります。このケースに対応するためには、2つの方法があります。
1つ目は、Cloud Workstationsのプライベートゲートウェイを使う方法です。プライベートゲートウェイを使うと、パブリックなインターネットからの接続ができなくなり、VPCまたはVPCと接続するネットワークからのみ接続できるようになります（参考元）。下図はオンプレからCloud Workstationsを利用するイメージ図です（オンプレとVPCは、Cloud VPNまたはCloud Interconnectを用いて接続しています）。
2つ目は、BeyondCorp Enterpriseを使う方法です。別途BeyondCorp Enterpriseライセンスをユーザーに購入する必要がありますが、Google Chromeの機能を利用して、許可したユーザーのデバイスからのみGoogle Cloudへアクセスできるようにする方法です（詳細はこちら）。
2.3. 監査ログ
踏み台サーバはシステムに対する変更を行う操作元であるため、誰が、いつ利用したかをロギングしておくことが求められます。Cloud Workstationsでは３種類のログが提供されており、監査ログからCloud Workstationsの構成に関する変更を確認でき、プラットフォームログから誰がいつ利用したかを特定することができます。
| 種類 | 内容 |
|---|---|
| Cloud Workstationsに対する監査ログ | Cloud Workstationsの管理/構成情報に対する書き込み、読み込み操作のログを記録（詳細） |
| Cloud Workstationsのプラットフォームログ | Cloud Workstationsのリソース（ディスク、VM）割り当てのログを記録（詳細） |
| コンテナ出力ログ | ワークステーション コンテナによって生成される標準コンテナ出力ログと標準コンテナエラーログを記録（詳細） |
3. まとめ
実際の利用を想定した場合の課題についても対応していくことができそうです。ここまで、前編と後編にわたって、Cloud Workstationsを踏み台サーバとして利用する可能性を見てきました。従来、踏み台サーバはVMを立てて用意してきましたが、Cloud Workstationsを利用することで、OS管理の負担、構築の負担を減らせることが分かりました。コストについては利用ケースによって上下するため、コストの特徴を踏まえて、コストメリットが得られるかは確認する必要があります。
Cloud Workstationsは、IDEとしてだけでなく、踏み台サーバの用途としても利用していくことで、より効率的なクラウド活用ができるようになるサービスだと思います。今後も注目したいと思います（Cloud Workstationsのリリースノート）。