What's This
表題のことで、気になったのでまとめました。
以下３つが代表的なのとしてあげられるのかなと思います。
１、起動スクリプトを使う。
インスタンス作成画面で、Scriptを入力する、自動化があるので、以下のようなスクリプトを書いて起動します。
#! /bin/bash
apt update
apt -y install apache2
cat <<EOF > /var/www/html/index.html
<html><body><p>Linux startup script added directly.</p></body></html>
２、インスタントテンプレート
インスタンス テンプレートとは、仮想マシン（VM）インスタンスとマネージド インスタンス グループ（MIG）を作成するために使用できるリソースです。
ただ、インスタンス テンプレートを更新したい場合、注意が必要です。
同じ構成のインスタンスを作成するように設計されているため、既存のインスタンス テンプレートを更新したり、インスタンス テンプレートを作成した後で変更したりすることはできません。
構成の変更が必要になった場合は、新しいインスタンス テンプレートを作成する必要があるということですね。
例えば、既存のテンプレートのコピーを作成して、それを変更して新しいバージョンを作成したり、ですかね。
なお、インスタンステンプレートを作成するのにかかるコストは、ありません。テンプレートに基づいて作成するリソースには料金が発生します。
既存のインスタンスに基づくインスタンス テンプレートの作成
既存のインスタンスから設定をコピーして、テンプレートを作成するコマンドです。
gcloud compute instance-templates create INSTANCE_TEMPLATE_NAME \
--source-instance=SOURCE_INSTANCE \
--source-instance-zone=SOURCE_INSTANCE_ZONE \
３、カスタムイメージを使用
2.で、インスタンス テンプレートについて書きましたが、この方法だと、インスタンス起動時にOSパッチとソフトウェアをインストールするので、起動時間が長くなります。
これを回避する１つとして、カスタムイメージ使用が挙げられます。
OSやソフトウェアが、起動前からセットされているので、時間短縮できます。
こちらも、テンプレート同様、既存のインスタンスから作成できます。
作成したイメージは、異なるプロジェクト間で共有もできます。
https://cloud.google.com/compute/docs/images/managing-access-custom-images?hl=ja#accessing_images
共有もできますが、使わないように非推奨にすることもできます。
イメージを作成したものの、時間が経つと古くなっていくので、それは使わないようにマークすることもできるみたいですね。
セキュリティの面から見ても、いい方法だと考えることができます。
全社的に、あるいはプロジェクト的に、あらかじめ定められたセキュリティに準拠させたい場合、それに即したイメージを作成し、使用させることで、準拠させることができます。
作成時の注意
カスタム イメージは、ソースディスク、イメージ、スナップショット、Cloud Storage に保存されているイメージから作成し、そのイメージを使用して仮想マシン（VM）インスタンスを作ることができます。
実行中の VM にアタッチされている状態のディスクからでもイメージを作成できますが、
作成する前に、永続ディスクにデータを書き込ませないようにするため、VMは停止した方がいいっぽいです。
参考
https://cloud.google.com/compute/docs/images/managing-access-custom-images?hl=ja#accessing_images
https://cloud.google.com/compute/docs/images?hl=ja#custom_images
https://cloud.google.com/compute/docs/instance-templates
https://cloud.google.com/compute/docs/instances/startup-scripts