G-gen の杉村です。当記事では Google Cloud（旧称 GCP）の仮想マシンサービスである Compute Engine を徹底解説します。当記事は、基本編記事に続く、「応用編」です。

基本編の記事

Compute Engine の基礎的な内容については、以下「基本編」の記事をご参照ください。

blog.g-gen.co.jp

基本編に含まれている内容は、以下のとおりです。

概要
VM のステート（状態）
ネットワーク
マシンファミリー・マシンシリーズ・マシンタイプ
リージョンとゾーン
ストレージ
接続（ログイン）
メンテナンスと障害対応
バックアップとリストア
Compute Engine の料金

当記事では「基本編」で紹介できなかった仕組みをご紹介します。

サービスアカウントとアクセススコープ

サービスアカウントのアタッチ

Compute Engine VM には、サービスアカウントをアタッチすることができます。

サービスアカウントは、人ではなくプログラムが利用するアカウントです。プログラムが Google Cloud APIs へリクエストする際の認証・認可に用いられます。

サービスアカウントからはキー（秘密鍵）を発行でき、プログラムからはこのキーを Google Cloud APIs への認証に使うことができます。ただし、サービスアカウントキーはテキストファイル（通常は JSON）であるため、漏洩の危険性があります。可能な限り発行を避けるのがベストプラクティスです。

サービスアカウントとして認証したいプログラムを Compute Engine 上で動作させる場合は、サービスアカウントキーを発行せず、VM に直接サービスアカウントをアタッチできます。

VM 上で gcloud コマンドを実行したり、各言語用の Google Cloud クライアントライブラリ（Cloud SDK）が動作すると、VM にアタッチしたサービスアカウントの認証情報を自動的に利用してくれます。この仕組みを利用すれば、サービスアカウントキーを発行し、ファイルとして VM に配置するという危険を冒す必要がありません。

アクセススコープ

アクセススコープとは、Compute Engine VM の内部からアクセス可能な Google Cloud APIs を制限する設定です。VM インスタンスごとに設定することができます。

例として、アクセススコープに https://www.googleapis.com/auth/devstorage.read_only だけを設定すると、VM の内部からは Cloud Storage バケットに対する読み取りオペレーションの API しか発行することができません。

この制限はサービスアカウントの持つ権限より優先されます。つまり、ある VM のアクセススコープに Cloud Storage 読み取り専用スコープが設定されている場合、たとえ VM にアタッチされているサービスアカウントが Cloud Storage バケットに対する読み取りと書き込みの権限を持っていたとしても、その VM の内部からは書き込みオペレーションを実行することはできません。

アクセススコープは、サービスアカウントの権限に「フタをする」ような挙動をすると考えれば分かりやすくなります。

参考 : アクセススコープ

以下の記事で、サービスアカウントとアクセススコープに関する挙動を検証・解説していますのでご参照ください。

blog.g-gen.co.jp

デフォルトのサービスアカウント

Google Cloud プロジェクトで Compute Engine の API を有効化する際、Compute Engine のデフォルトのサービスアカウントが作成されます。デフォルトのサービスアカウントの名称は、以下のようになります。

(プロジェクト番号)-compute@developer.gserviceaccount.com

このサービスアカウントには自動的に、プロジェクトレベルで編集者ロール（roles/editor）が付与されます。編集者ロールは強力な権限を持っていますので、セキュリティリスクとなるおそれもあります。

このデフォルトの挙動を回避する方法が、以下の記事で紹介されています。

参考 : 改めてサービスアカウントとVMのアクセススコープを理解する - G-gen Tech Blog - 最小権限の原則を意識する

Compute Engine へのサーバー移行

オンプレミスの物理サーバーや仮想サーバー、AWS 等他のパブリッククラウドのサーバーを Google Cloud に移行するには、複数の方法があります。

代表的な手法として、ツールを使って複数サーバーを一括で移行し、ダウンタイムも抑えられる Migrate for Compute Engine や、仮想イメージファイルを VM イメージとしてインポートする仮想ディスクのインポート機能があります。それぞれ、以下の記事をご参照ください。

ロードバランシングと SSL/TLS

Compute Engine で動作するアプリケーションに対するロードバランシング（負荷分散）は、仮想ロードバランサーである Cloud Load Balancing を用います。

負荷分散対象の VM を後述のマネージドグループでグルーピングして、Cloud Load Balancing の下にぶら下げることで、負荷分散を実現できます。

Cloud Load Balancing は配下の VM に対して一定間隔でヘルスチェックを行い、障害状態（unhealthy）となったインスタンスにはトラフィックを振り分けないようにするなどの対処を自動で行ってくれます。

Cloud Load Balancing にはいくつか種類があり、 TCP 通信を終端するタイプのロードバランサーでは SSL/TLS の終端が可能です。そのうえで Cloud Load Balancing と VM の間は、復号済みの HTTP で通信させることが可能です。なおこの場合のロードバランサーから VM までの通信は Google Cloud の内部ネットワークで行われており、通信は自動で暗号化されます。この暗号化は、ネットワークレベルの自動暗号化と呼ばれています。詳細は以下のドキュメントを参照してください。

参考 : プロキシロードバランサとバックエンド間の暗号化

Cloud Load Balancing の詳細は、公式ドキュメントや当社記事をご参照ください。

インスタンスグループ

インスタンスグループとは

インスタンスグループとは、VM をグルーピングするためのリソースであり、以下の目的で使われます。

ロードバランシング（負荷分散）
オートスケーリング
オートヒーリング
自動アップデート ... 等

インスタンスグループには、マネージドインスタンスグループとアンマネージドインスタンスグループの2種類が存在します。

アンマネージドインスタンスグループ

アンマネージドインスタンスグループ（Unmanaged instance group）とは、VM を Cloud Load Balancing の配下にぶら下げるためのインスタンスグループです。日本語では非マネージドインスタンスグループとも呼称されます。

後述のマネージドインスタンスグループ（MIG）とは対照的に、オートスケーリングやオートヒーリングは利用できません。

オートスケーリングやオートヒーリングを用いず、単純に構築した VM を Cloud Load Balancing に追加したい場合に、このアンマネージドインスタンスグループを使います。

アンマネージドインスタンスグループは、単一ゾーンの VM をグルーピングできますが、複数ゾーンにまたがることはできません。

参考 : 非マネージド VM をグループ化する

マネージドインスタンスグループ（MIG）

マネージドインスタンスグループ（MIG）とは

マネージドインスタンスグループ（MIG）とは、同一でステートレスな VM をまとめるためのグループです。

MIG では、オートスケーリング（autoscaling、自動でインスタンスを増減する）、オートヒーリング（autohealing、障害を起こしたインスタンスを自動で再作成する）などを実現できます。

オートスケーリングとオートヒーリングは、VM をカスタムイメージから自動構築することで実現されます。

MIG において VM は同じカスタムイメージから起動され、同じ起動シーケンスを経て、同じ状態の VM として起動されますので「同一（identical）」です。またインスタンスは都度、イメージから新しいものが起動されますので、可変のデータは外部データベース等に外だしする必要があります。これが VM が「ステートレス（stateless、状態を持たない）」であるという言葉の意味です。

参考 : マネージドインスタンスグループ（MIG）

インスタンステンプレート

前述の通り、オートスケーリングとオートヒーリングは VM をイメージから都度、自動構築することで実現されます。

自動構築は、インスタンステンプレートという、ユーザー定義の設定リソースに基づいて行われます。

参考 : インスタンステンプレート

インスタンステンプレートは以下のような設定値を持ち、自動構築するインスタンスの定義を保持します。

マシンタイプ
イメージ（パブリック/カスタム）
ラベル
スタートアップスクリプト
その他

パブリックイメージとカスタムイメージ

インスタンステンプレートの持つ定義情報として、イメージ（images）があります。

ここで言うイメージは、基本編で解説したバックアップ用のマシンイメージ（Machine images）とは別物であることに注意してください。インスタンステンプレートで用いられるイメージは、単にイメージ（images）もしくは OS イメージ（OS images）または Compute Engine イメージ（Compute Engine image）と呼ばれます。

また、イメージにはパブリックイメージとカスタムイメージが存在します。

パブリックイメージは Google Cloud が公式に配布しているイメージです。一般的に VM を構築するときに使う Debian や Windows Server のイメージが、これに当たります。

カスタムイメージは、ユーザーがパブリックイメージをベースにして独自に作成するイメージです。パブリックイメージをもとに構築した VM に、ミドルウェアやアプリケーションをインストールして、そこからカスタムイメージを採取します。

このカスタムイメージをインスタンステンプレートに設定することで、MIG でオートスケーリングやオートヒーリングに活用できます。

参考 : イメージ管理のベストプラクティス

イメージとマシンイメージ、スナップショットはそれぞれ違うものであり、以下の記事で違いが整理されています。

参考 : Compute Engineのスナップショット、マシンイメージ、カスタムイメージの違い

その他の MIG

その他にも、 MIG には多用な機能があります。

リージョナル（Regional）/ゾーナル（Zonal）MIG : ゾーンをまたいだ可用性はリージョナル、インスタンス間のレイテンシ等を重視する場合はゾーナル
コンテナの利用 : VM が Container-optimized OS で構築され全 VM に所定の Docker コンテナが起動する
スポット VM: スポット VMで構成された MIG を作成可能
ステートフル MIG : インスタンス名、ディスク、IP アドレスなどを維持できるステートフルな MIG。オートスケーリングはできないがオートヒーリングが可能
自動アップデート : 新しいインスタンステンプレートをローリングアップデート/カナリアアップデートなどを用いてアップデートできる他、ロールバック等も可能

詳細は、以下の公式ドキュメントを参照してください。

参考 : インスタンスグループ

オートスケーリング（Autoscaling）

オートスケーリングとは

オートスケーリング（Autoscaling）は、負荷状況に応じて VM が自動的にスケールアウト・スケールインする仕組みです。前述の通り、オートスケーリングでは MIG を用いて、イメージから VM が起動されます。

スケールインやスケールアウトのきっかけとなる閾値は、オートスケーリングポリシーで定義されます。例えば平均 CPU 使用率、秒あたりの HTTP リクエスト数、その他の Cloud Monitoring の指標（メトリクス）に閾値を設定し、しきい値の超過や低下をトリガーにしてスケールアウトやスケールインを実行できます。

なおオートスケーリングには VM の利用料の他に、追加の料金は発生しません。

参考 : インスタンスのグループの自動スケーリング

設定

オートスケーリングで VM がスケールアウトする際は、イメージから VM が起動され、スタートアップスクリプトに従って VM の初期化が行われます。初期化が終わる前に次のスケールイン・アウトが始まらないように、クールダウン期間を設定可能です（デフォルトで60秒）。

参考 : 初期化期間

また10分間の安定化期間が設定されており、スケールインの判断は過去10分間のピーク負荷を基準に行われます。

参考 : 安定化期間

運用

オートスケーリングやオートヒーリングは、イメージから VM が起動されることで実現されます。そのため、オートスケーリングやオートヒーリングを運用する場合は、イメージのメンテナンスやアプリケーションデプロイの仕組みが必要であることを意味します。

常に最新版のアプリが入っている状態のイメージを用意する
スタートアップスクリプト（後述）を設定してアプリや設定をダウンロードする

といった方法で、VM にミドルウェアやアプリケーションがセットアップされるようにする必要があります。

オートスケーリングやオートヒーリングは便利な仕組みではありますが、OS、ミドルウェア、アプリケーションのアップデートに追従して、イメージのメンテナンスをする必要がある、という点に十分留意が必要です。

メタデータ

メタデータとは

メタデータは、Compute Engine における、Key-Value ペアの属性です。Compute Engine では、プロジェクト単位または VM 単位でメタデータを定義できます。プロジェクト単位で定義されたメタデータは、そのプロジェクト内のすべての VM に継承されます。

メタデータには、すべての VM がデフォルトで持つ事前定義されたメタデータと、ユーザーが定義できるカスタムメタデータがあります。

事前定義されたメタデータは「VM の ID」「プロジェクト名」「イメージ名」「NIC の IP アドレス」など、VM が Google Cloud リソースとして持つ基本的な定義情報が自動的に設定されます。事前定義されたメタデータを VM 上のプログラムからクエリすることで、これらの基本的な情報を取得することができます。

一方のカスタムメタデータは、ユーザーが自由に定義できます。スタートアップスクリプトを登録したり、特定の設定を有効にするために用います。

参考 : VM メタデータについて

事前定義されたメタデータ

事前定義されたメタデータは全ての VM が持つメタデータです。以下は、事前定義されたメタデータに設定される情報の一部抜粋です。

VM の所属するプロジェクト
VM の起動に使われたイメージ名
VM の NIC の IP アドレス
メンテナンスイベントの状況

メタデータは、VM の内部から http://metadata.google.internal/computeMetadata/v1/instance/ へHTTP リクエストを投げることで参照できます。

以下は、Linux VM にて curl コマンドを実行して NIC の IP に関するメタデータをクエリする際のコマンドとレスポンスです。リクエストヘッダには Metadata-Flavor: Google を付与する必要があります。

$ curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip
10.146.0.60

参考 : 事前定義されたメタデータキー

カスタムメタデータ

カスタムメタデータは、ユーザーが自由に定義できるメタデータです。以下のような用途で用います。

スタートアップスクリプトやシャットダウンスクリプトの定義
ゲスト属性（Guest Attribute）
OS Login の有効化
VM の SSH 公開鍵の登録

ゲスト属性とは、VM 上のアプリケーションから読み取りや書き込みが可能なカスタムメタデータです。簡易的なデータストアとして利用できますが、1分間あたりのクエリ数の制限があったり、機密情報を保存するのには適していないことに留意が必要です。

参考 : カスタムメタデータの設定と削除
参考 : ゲスト属性の設定とクエリ

注意点

特にユーザーが自由に定義できるカスタムメタデータにおいて、センシティブな情報をメタデータに含ませてはいけません。

メタデータは機密情報を保持するようには設計されていないため、パスワードや一時トークンなどをカスタムメタデータに含ませることは NG です。

スタートアップスクリプト、シャットダウンスクリプト

スタートアップスクリプト

スタートアップスクリプト は VM が起動するときに毎回実行されるスクリプトです。

スタートアップスクリプトにより、VM 起動時にミドルウェアをセットアップしたり、設定値や必要なデータをダウンロードすることができます。オートスケーリングやオートヒーリングを利用する際にも利用されます。

スクリプトは、Linux VM では root ユーザーで、Windows VM では LocalSystem アカウントで実行されます。

前述の通り、スタートアップスクリプトはメタデータに設定します。以下は、Linux VM でスタートアップスクリプトを定義するときの例です。

例1
- Key : startup-script
- Value : (スクリプト本文)
例2
- Key : startup-script-url
- Value : gs://(Cloud Storage に格納したスクリプトの URL)

注意点として、スタートアップスクリプトは起動時に毎回実行されます。よって、スクリプトの処理は冪等（べきとう）、すなわち何回実行されても同じ結果になるように書かれている必要があります。もしくは、初回起動後はメタデータを削除してスタートアップスクリプトが実行されないようにするなど、工夫が必要です。

参考 : 起動スクリプトについて

シャットダウンスクリプト

シャットダウンスクリプトは、VM の停止時もしくは削除時に実行されるスクリプトです。

特にオートスケーリングを活用する場合に、インスタンスが削除される前にデータやログを退避するなどのユースケースで利用されます。またスポット VM がプリエンプト（中断）される前の停止前処理としても利用されます。

スクリプトは、Linux VM では root ユーザーで、 Windows VM では System アカウントで実行されます。

ただし Compute Engine では、シャットダウンスクリプトの実行はベストエフォートであり「完了を保証できないことがある」とされています。このことから、シャットダウンスクリプトの失敗がクリティカルとなるような処理設計は避けるべきです。

シャットダウンスクリプトは以下のような際に実行されます。

Google Cloud コンソールや gcloud コマンドでインスタンスがシャットダウンされるとき
instances.delete や instances.stop の API リクエストで VM がシャットダウンするとき
スポット VM が中断されるとき
sudo shutdown や sudo reboot 等ゲスト OS のコマンドで停止または再起動されるとき

注意点として、Google Cloud コンソールや gcloud コマンドからの「再起動」にあたる instances.reset では、シャットダウンスクリプトは起動しません。

参考 : シャットダウンスクリプトの実行

Persistent Disk のパフォーマンス

IOPS とスループット

Persistent Disk のパフォーマンスには、大きく分けて以下の考慮点があります。

IOPS
スループット

IOPS（Input/Output Per Second）は、ストレージにおける一秒間あたりの読み書きの回数を意味します。小さいデータのランダム IO が多く発生する処理では、性能として IOPS が重視されます。

スループットとは、単位時間あたりに読み書きできるデータサイズを意味します。Compute Engine では、スループットは多くの場合で MB/sec で表記されます。シーケンシャルな読み書きが発生する処理や、1回あたりの読み書きサイズが大きい処理の場合に、スループットが重視されます。

参考 : Persistent Disk のパフォーマンスについて

性能の計算方法

ある VM にアタッチされたディスクにおける、IOPS とスループット性能の上限は、以下のように計算されます。

ベースライン性能 + ( GB あたりの性能上限 × インスタンスにアタッチされている全ディスクの合計 GB )

ベースライン性能とは、バランスディスクと SSD ディスクに設定された最低限の IOPS 性能です。Balanced Persistent Disk と SSD（Performance）Persistent Disk のみに存在し、他は0です。

ディスクの種類	ベースライン IOPS (インスタンスあたり)
Balanced Persistent Disk	3,000
SSD（Performance）Persistent Disk	6,000

GB あたりの性能上限とは、ディスクサイズが大きければ大きいほど与えられる IOPS 性能です（以下の表には一部のみ抜粋）。

ディスク種別	読み取り IOPS / GB	書き込み IOPS / GB
Zonal Standard Persistent Disk	0.75	1.5
Zonal Balanced Persistent Disk	6	6
Zonal SSD（Performance）Persistent Disk	30	30

例えば 1,000 GB のゾーンバランスディスクの場合、読取・書込ともに 6,000 IOPS が上限です。

計算例

2つの 1,000 GB のゾーン Balanced Persistent Disk をアタッチした VM では、IOPS 上限の計算式は以下のようになります。

ベースライン性能 3,000 + (6 IOPS * 2000 GB) = 15,000 IOPS

ただし、VM にはマシンシリーズごと、また vCPU コア数ごとに上限も設定されており、これを超えることはできません。例えば e2-medium インスタンスの最大 IOPS は書込で10,000、読取で12,000です。

スループットにも同様に上限が設定されます。当記事では詳細に解説しませんが、詳細は以下の公式ドキュメントを参照してください。

参考 : Persistent Disk のパフォーマンスについて

パフォーマンスの最適化

前述の通り、ストレージのパフォーマンスを律速する要素は以下があります。

ストレージの種類（Standard、Balanced、SSD Persistent Disk 等）ごとの上限
VM のマシンタイプごと、vCPU コア数ごとの上限

ディスクやストレージサイズを増やしても、マシンタイプやコア数ごとの上限に当たっているとそれ以上は性能が上がりません。

ディスクのパフォーマンスが思うように出ない場合は、Cloud Monitoring の指標（メトリクス）を確認し、ストレージのパフォーマンスがどの要素で律速されているかを調査して、適切な対処を取る必要があります。

また、Persistent Disk では要件を満たせない場合、Hyperdisk の利用を検討します。Hyperdisk では、IOPS やスループットなどのパフォーマンスを明示的に指定（プロビジョニング）できます。

参考 : Google Cloud Hyperdisk のパフォーマンスについて

ログ管理

Compute Engine で動作するアプリケーションのログや、OS のシステムログ等を管理するのに最も効率的な方法は、Cloud Logging です。VM 内に Ops Agent をインストールすることで、Cloud Logging にログエントリを送信することができます。

以下のドキュメントを参考にして、Ops Agent のセットアップや、ログ送出の設定が可能です。

ライセンス

ライセンスの基本

パブリッククラウドでサードパーティソフトウェアを使う場合には、ライセンスが問題になることが多くあります。

Google Cloud が配布しているイメージファイルや Google Cloud Marketplace で販売・配布されるソフトウェアについては、課金が Google Cloud と統合されており、難しい考慮なく利用可能な場合があります。

一方で、ユーザーが自ら VM にインストールするソフトウェアのライセンス体系については、パブリッククラウド上での利用における制限や、ライセンス料金へ適応される係数などがあり、複雑になっている場合があります。当該ソフトウェアの開発元ベンダーや、代理店に確認するのが原則です。

オンデマンドライセンス（PAYG）

OS 等のライセンスについては、まず第1の選択肢として、公式に配布しているプレミアムイメージや、Google Cloud Marketplace で配布されているイメージを利用することを検討します。

参考 : プレミアムイメージ

Red Hat Enterprise Linux（RHEL）、Windows Server、Microsoft SQL Server などのプレミアムイメージが配布されています。これらのイメージから VM を起動すると、ライセンス料金は時間単位で Google Cloud の請求先アカウントに課金されます。複雑な契約などの考慮が必要なく、シンプルに時間課金でライセンスを購入可能です。

このようなライセンス体系は、オンデマンド、従量課金、あるいは PAYG（Pay As You Go）等と呼ばれます。

Windows Server や Microsoft SQL Server の場合、プレミアムイメージを使う他にも、インポートしたイメージや、Migrate for Compute Engine などのツールを使ってインポートした仮想マシンにも、オンデマンドライセンスを付加することが可能です。

参考 : Google Cloud での Microsoft ライセンス

ライセンス持ち込み（BYOL）

第2の選択肢としては、ライセンスの持ち込みが挙げられます。この手法は、Bring Your Own License の頭文字を取って BYOL と呼ばれます。

BYOL の可否は、ライセンス発行者によりルールが異なりますので、開発元ベンダーや販売元代理店へ確認が必要です。

参考 : ライセンスについて

Windows Server や Microsoft SQL Server などの Microsoft ライセンスについては、第1の選択肢としてオンデマンドライセンスが推奨されます。第2以降の選択肢として単一テナントノードを使ったライセンス持ち込みや、ソフトウェアアシュアランスによるライセンスモビリティを適用した持ち込みなどが考えられます。こちらも、詳細はドキュメントを参照するとともに、販売元に確認が必要です。

参考 : Google Cloud での Microsoft ライセンス

単一テナントノード

単一テナントノードとは

単一テナンシー（sole-tenancy）は、1台の物理マシンを専有して VM を配置できる仕組みです。この機能で専有した物理マシンを、単一テナントノード（sole-tenant nodes）と呼びます。

デフォルトでは、VM はマルチテナントノードで起動されます。マルチテナントノードでは、他の Google Cloud ユーザーの VM も、同一の物理マシンで起動されている可能性があります。一方の単一テナントノードでは、自分のプロジェクトの VM だけでマシンを専有できます。

単一テナントノードは、セキュリティ要件やコンプライアンス要件を満たすために利用する他、ライセンス販売元の要件を満たすためにも利用されます。その他にも、VM 間の高い IOPS パフォーマンスが求められる場合にも用いられることがあります。

参考 : 単一テナンシーの概要

料金

単一テナントノードでは物理マシン単位でリソースを確保するため、ノード単位の料金がかかります。以下のドキュメントに料金が記載されています。永続ディスク等の料金は別途発生することも記載されていますので、十分ご注意ください。

参考 : 単一テナントノードの料金

GPU

Compute Engine の GPU

Compute Engine にはグラフィック処理や機械学習目的のため、GPU が利用できます。GPU が接続されているアクセラレータ最適マシンタイプの VM を起動したり、N1 マシンタイプに外付けの GPU をアタッチするなどして、GPU が利用可能です。

以下は、アクセラレータ最適マシンタイプの一例です。

マシンタイプ	GPU
A4	NVIDIA B200 GPU
A3	NVIDIA H100 80GB GPU または NVIDIA H200 141GB GPU
G2	NVIDIA L4 GPU

また、N1 インスタンスタイプには、以下の GPU をアタッチできます。

NVIDIA T4、NVIDIA V100、NVIDIA P100、NVIDIA P4
参考 : GPU マシンタイプ
参考 : 概要

GPU の利用料金

アクセラレータ最適化マシンファミリーの VM は、VM の利用料金に、GPU の利用料金が含まれています。一方で N1 マシンに GPU をアタッチした場合、GPU の利用料金が別途発生します。

参考 : アクセラレータ最適化マシンタイプファミリー
参考 : GPU の料金

なお、GPU を使うマシンが分散処理のワーカー等である場合、スポット VM と組み合わせることで、コストを節約することも可能です。スポット VM に接続する GPU は、割引価格で利用できます。

参考 : Spot VM 上の GPU

制限

Compute Engine における GPU の利用には、以下のような制限があります。

共有コアマシンタイプの N1 インスタンスにはアタッチできない
割り当て（Quotas）に注意する必要がある
適切なデバイスドライバが必要
ライブマイグレーションができない

上記は一部抜粋ですので、完全なリストは以下の公式ドキュメントを参考にしてください。

高度なセキュリティ

Shielded VM

Shielded VM とは、VM がセキュアに起動することを担保するための一連の機能のことです。

Shielded VM 機能群を有効化すると、VM が起動する際に、ブートローダー（bootloader。コンピュータ起動時に実行されるプログラム）とカーネル（OS の中核となるプログラム）がチェックされ、ブートレベルおよびカーネルレベルのマルウェアや、ルートキット（rootkit。攻撃者がコンピュータへの攻撃のために忍ばせておく悪意あるツールの総称）に汚染されていないことが確認されます。

参考 : Shielded VM について
参考 : Shielded VM とは？

Shielded VM は以下の 3 機能で構成されており、 VM ごとにオン / オフを設定できます。

No	機能名	デフォルト	説明
1	セキュアブート	Off	ブートコンポーネントのデジタル署名を検証し、失敗時は VM を停止する
2	vTPM	On	仮想的な Trusted Platform Module（鍵や証明書生成などに使う物理チップ）
3	整合性モニタリング	On	前回起動時とブートシーケンスが異なる場合、起動を失敗させる

セキュアブートはデフォルトではオフになっています。これは署名されていないドライバを使っている等の場合に対処するためです。問題ない場合はオンにすることができます。

vTPM と整合性モニタリングはセットで利用するものであり、前者をオンにしないと後者をオンにできません。デフォルトでは両方ともオンになっています。後者をオンにすると、VM の起動時にブートシーケンスが前回と変化したかがチェックされ、変化があればブートプロセスが停止されます。そのため VM の起動シーケンスに影響を与える「カーネルの更新」「ドライバのインストール」等を行った場合、整合性検証が失敗し、 VM が起動しない場合があります。このような際は gcloud コマンド等で、明示的にベースラインを更新する必要があります。

参考 : 整合性ポリシーベースラインを更新する

整合性チェックの失敗時は、Cloud Monitoring のログエントリに、earlyBootReportEvent、lateBootReportEvent などが出力されます。

参考 : 整合性モニタリングイベント

Confidential VM

Confidential Computing は、Trusted Execution Environment（TEE）というハードウェアにより、メモリ内のデータの暗号化を実現する機能です。

コンピュータが扱うデータの暗号化は、データの所在の観点で「保存中（at-rest）」「転送中（in-transit もしくは in-flight）」「処理中（in-use）」に分類されます。このうち、データ処理中の暗号化（Encryption-in-use）を実現するのが Confidential Computing です。

Compute Engine では Confidential Computing がサポートされており、特定のマシンタイプの VM を、Confidential Computing が適用された Confidential VM として起動することができます。Confidential VM を有効化すると、暗号化と復号のオーバヘッドがかかりますが、ハードウェアでサポートされた処理のため、パフォーマンス影響は「ゼロから最小限の範囲」とされています。

参考 : Confidential Computing の概要
参考 : Confidential VM の概要

なお Google Cloud において、保存中のデータの暗号化（Encryption-at-rest）はデフォルトで実現されています。また転送中のデータの暗号化（Encryption-in-transit）は、ユーザー側で HTTPS などで実現できるほか、Google Cloud 内部の通信はデフォルトで暗号化が実現されています。

参考 : デフォルトの保存データの暗号化
参考 : 転送データの暗号化

Confidential VM は、特定のプロセッサを搭載したマシンタイプ（N2D、C2D、C3D、c3-standard-* 等) で利用できますが、利用可能な OS は制限されています。

参考 : サポートされている構成

運用の自動化

Compute Engine では、VM の運用を自動化するための VM Manager 機能があります。

同機能については、以下の記事でご紹介しています。

blog.g-gen.co.jp

また、スナップショットの取得や、VM の定時における起動・停止などは、スケジューラーで自動化することができます。

VM の起動・停止のスケジューリングについては、以下の記事も参考にしてください。

blog.g-gen.co.jp