Google Cloud VMware Engine(GCVE)を徹底解説!

記事タイトルとURLをコピーする

G-gen の杉村です。VMware 資産を Google Cloud へリフトするにあたり重要な選択肢となる、Google Cloud VMware Engine(GCVE)を解説します。

概要

Google Cloud VMware Engine(GCVE)とは

Google Cloud VMware Engine(以下、GCVE)とは、Google Cloud(旧称 GCP)で VMware プラットフォームを運用できるマネージドサービスです。

VMware プラットフォームが稼働するための物理マシンは Google Cloud によって提供され、管理されます。私たちユーザーは、物理レイヤをほとんど意識することなく、VMware 関連サービスを利用することができます。障害が発生したハードウェアは自動的に交換され、管理プレーンの運用は Google によって行われます。

GCVE 環境は物理的には Google Cloud のデータセンターに存在しています。そのため GCVE の VM と、BigQuery や AI/ML 関係サービスなどの Google Cloud エコシステムは容易に、また低いレイテンシで連携することができ、データ活用の推進にも繋がります。

GCVE には vSphere、vCenter、vSAN、NSX-T、HCX などが含まれており、これらは既存の VMware プラットフォームと互換性があります。つまり、GCVE を採用すれば、VMware 資産や運用体制をほとんど変えずに、VM をクラウドに移行できることを意味しています。

GCVE は2024年7月現在、日本国内では東京リージョンで利用可能であり、大阪リージョンには対応していません。

概要図

VMware ライセンス

2023年11月、米 Broadcom Inc. が VMware, Inc を買収しました。これに伴い、VMware 製品のライセンス体系が大きく変わりました。

従来、VMware の各製品のライセンスは、買い切り型ライセンスとして製品ごとに単体購入が可能でした。しかしながら経営体制の変更に伴い、買い切り型ライセンスは廃止され、様々な製品がバンドルされた「VMware Cloud Foundation(VCF)」や「VMware vSphere Foundation(VVF)」といった、サブスクリプション型ライセンスに切り替わりました。

このライセンス体系の変更により、一部の VMware ユーザー企業はライセンスコストが増加します。一部のユーザー企業は、ライセンスコスト増加を避けるため、クラウドへの移行を検討しています。

当記事で紹介する Google Cloud VMware Engine(GCVE)は、利用料金に VMware 製品のライセンス費用も包含されています。このことから、GCVE は VMware 仮想サーバー資産の移行先の有力な候補と考えることができます。

メリット

GCVE へ VMware 仮想マシンを移行することで、物理機器の調達、セットアップ、増強などの管理や VMware ライセンスの管理工数が削減できます。これらはすべて、Google によって管理されるからです。これはすなわち、TCO(Total Cost of Ownership、総所有コスト)の削減に繋がります。

また、VM 資産をまずはいったん GCVE 環境にそのままの形で移行し、オンプレミスの物理機器を撤去したあとで、徐々にコンテナやフルマネージドサービス、サーバーレスなどのクラウドらしい近代的なアーキテクチャに移行(モダナイズ)するという中長期的な戦略を立てることにも繋がります。このように、一度は移行工数の少ない形で IT 資産をクラウドに移行し、その後でモダナイズする2段階の戦略のことを Lift & Shift と呼びます。

リフト&シフト(2段階の移行戦略)

2段階の移行戦略をとる場合でも、Lift の段階で VM 群は Google Cloud の豊富なエコシステムと連携できるようになります。つまり、BigQuery などの高性能なデータ分析サービス、生成 AI を含む先進的な AI/ML(人工知能・機械学習)サービスなどと、VM 上のデータを容易に連携できるようになります。

すなわち GCVE の利用は、「コスト削減」「クラウド化の第一歩となる」「データの活用推進」などの観点でメリットがあるといえます。

基本的な構成

GCVE は Google Cloud VMware Engine プライベートクラウドと呼ばれる、他の GCVE 利用者とは分離された仮想領域に展開されます。その中で、ノードと呼ばれるベアメタルハードウェアが割り当てられます。ノードは GCVE 利用の基本単位であり、複数ノードで vSphere クラスタを構成することができます。

ノードは ve1-standard-72ve2-standard-128 の2種類から選ぶことができますが、後者は限られたリージョンでしか利用できません。東京リージョンを含めた多くのリージョンでは、前者のみ利用可能です。ve1-standard-72 のスペックは、以下のとおりです。

CPU メモリ ストレージ キャッシュ
2x - 2.6 GHz (3.9 GHz Turbo), 36 cores, 72 hyperthreaded cores 768 GB 19.2 TB NVMe 3.2 TB NVMe

Google Cloud VMware Engine プライベートクラウドの構成

ノード数と PoC

GCVE は、原則的に3ノードから利用できます。ただし、PoC(概念実証)やテストの目的で、限定的な期間のみ、単一ノードのプライベートクラウドを利用することが可能です。

単一ノードのプライベートクラウドはあくまで一時的な環境という扱いであり、SLA も適用されません。単一ノード環境は、60日間で自動的に削除されます。ただし60日以内に3ノード以上に増加することで、本番環境扱いになり、削除されず、SLA が適用されるようになります。

他社の類似サービス

他社の類似サービスとして Amazon Web Services(AWS)の VMware Cloud on AWS が存在しますが、2024年4月30日以降、新規販売が停止されています。

他のクラウドベンダーからも、類似の VMware 互換サービスが提供されています。Microsoft Azure の Azure VMware Solution、Oracle Cloud の Oracle Cloud VMware Solution などがこれに当たります。

料金

GCVE ノード

GCVE は、ノード数に応じた課金が発生します。課金方法には複数のオプションがあり、以下のリストの下に行くほど安価に利用できます。

  • オンデマンド(コミット・前払いともに無し)
  • 1年コミットメント・月次支払い
  • 1年コミットメント・前払い
  • 3年コミットメント・月次支払い
  • 3年コミットメント・前払い

このノード料金には、vSphere、vSAN、NSX-T、HCX などの料金も含まれています。

このノード数に応じた料金のほか、構成によっては、Google Cloud から外に出るデータのトラフィック量に応じた課金(Egress traffic)や、専用線(Cloud Interconnect)、IP Sec VPN(Cloud VPN)の料金が発生する可能性があります。

サードパーティライセンス

VM 上で Windows Server や Microsoft SQL Server などを利用する場合、SPLA 形態で Google Cloud より提供されるライセンスを利用する必要があります。詳細は以下のドキュメントを参照してください。

Microsoft 社のライセンスであるか否かにかかわらず、クラウドへのソフトウェアライセンス持ち込みには複雑なルールが定められている場合があります。ソフトウェアライセンスに関しては、ライセンス提供元や Google Cloud の営業担当者と密に相談のうえ、検討を進めてください。

非機能要件

セキュリティ

責任共有モデル

GCVE では、通常の Google Cloud サービスと同様に、責任共有モデルの考え方が適用されます。

物理レイヤのセキュリティは、Google Cloud の責任です。テナント間でハードウェアが共有されることはありません。また、データセンター設備のセキュリティ、物理マシンのファームウェアなども、Google がメンテナンスを行います。

NSX によるネットワーク構成、そして VM 上の OS やソフトウェアに関するセキュリティは、ユーザーの責任となります。

データの暗号化

GCVE では、保存中のデータは vSAN ソフトウェアベースの暗号化が行われます。その際に使われる暗号鍵は、デフォルトでは Google が提供する鍵管理システム(Cloud KMS)によって自動的に管理されます。これによりデータはユーザーから見て透過的に暗号化され、ストレージの物理的な盗難や不正な物理アクセスなどに対処することができます。

転送中のデータについては、必要に応じてアプリケーション側で暗号化する必要があります。

また、物理マシンの安全な廃棄などは、規約に定められた安全な方法で廃棄されます。

ネットワーク

GCVE は、Google Cloud 内の安全な物理ネットワークインフラ上にあり、論理的には完全に独立しています。

ユーザー側では、仮想ネットワーク構成、後述するネットワークポリシー、外部アクセスルール(ファイアウォールルール)などによってアクセス制御を行います。

可用性

GCVE では、障害が発生した ESXi ノードは自動的に交換されます。

また、NIC 障害やディスク障害、ラック単位での障害などに関しても、GCVE の機能と VMware の各種機能を組み合わせることで対応しており、高い可用性が維持されます。

オプショナルで VMware Engine 拡張プライベートクラウドを設定することで、複数の Google Cloud ゾーンにまたがるクラスタを構成し、可用性をより高めることができます。

拡張プライベートクラウドではクラスタが2つのゾーンにわたって拡張されます。ゾーン間は物理的に 10km 以上離れていますが、レイテンシ(RTT)は 5 ms 以下です。拡張プライベートクラウドの各ゾーンは、総容量の半分のキャパシティを持たせます。これにより、片方のゾーンが停止しても、もう片方のゾーンで業務を継続できます。さらに、2つのゾーンと別に監視用のゾーンを1つ利用します。この監視用のゾーンや監視ノードは Google によって管理されるため、我々は意識する必要がありません。

ただし、2024年7月現在の東京リージョンでは GCVE を利用できるゾーンが1つだけですので、拡張プライベートクラウドは利用できない点にご留意ください。

拡張性

GCVE プライベートクラウドでは、コンソール画面からすぐにノードを追加したり、削除することができます。ノード追加の回数制限はありません。ただし、1つのクラスタのノードの最大数は32、1つのプライベートクラウドあたりのノードの最大数は96です。

ノードには ESXi の実行に必要な CPU、メモリ、ストレージが含まれており、ユーザー側での複雑なセットアップは必要ありません。

また、GCVE プライベートクラウドに新規のクラスタを追加することも容易です。クラスタには vSAN ディスクグループ、VMware HA、Distributed Resource Scheduler(DRS)などが含まれています。

VMware コンポーネント

概要

GCVE プライベートクラウドには多くの VMware アセットが含まれており、その利用料金はノードの利用料金に含まれています。また、各コンポーネントは Google Cloud コンソールから GCVE プライベートクラウドを作成する際に、ほぼ自動的にデプロイされます。

当記事では、以下の代表的なコンポーネントの概要のみを紹介します。

  • ESXi
  • vCenter
  • vSAN
  • NSX Data Center
  • HCX

ESXi

VMware ESXi は、ノード上で稼働するハイパーバイザです。GCVE では2024年7月現在、7.0 Update 3o(vSphere Enterprise Plus ライセンス)バージョンがデプロイされます。

GCVE では、ESXi はノードにインストール済みの状態で利用可能です。

各 ESXi ホスト(ノード)はデフォルトでクラスタとして構成されます。そして、最初のクラスタに各種管理コンポーネントがデプロイされます。

vCenter

vCenter Server Appliance は、プライベートクラウドの vSphere 環境を一元管理するための仮想アプライアンスです。単に vCenter、または VCSA と呼ばれることもあります。GCVE では2024年7月現在、7.0 Update 3p(vCenter Standard ライセンス)バージョンがデプロイされます。

vCenter は VMware Engine の認証、管理、オーケストレーション(統合管理)の機能を提供します。プライベートクラウドを作成する際に、vCenter は自動的にデプロイされます。また、GCVE ではノードを追加した場合、自動的に vCenter にもノードが追加されます。

vSAN

vSAN はストレージ機能です。 Software-defined(ソフトウェア定義)で物理的なストレージリソースを効率的に管理し、VM から利用可能にするための仕組みです。GCVE では2024年7月現在、7.0 Update 3o(Advanced + select vSAN Enterprise features ライセンス)バージョンがデプロイされます。

GCVE ではノードに接続されたローカル SSD を vSAN が統合管理します。

GCVE では vSAN の機能である重複除去(重複排除)と圧縮がデフォルトで有効になっており、効率的にストレージリソースを利用することができます。

また、vSAN のストレージポリシーにより、許容障害数(Failures to tolerate または FTT)と障害の許容方法(Failure tolerance method)を定義できます。例えば FTT が1の場合、RAID 1(ミラーリング)によって、すべてのデータには2つのコピーが作成されます。FTT を2にすると、すべてのデータには3つのコピーが作成されます。ただしこれには5台以上のノードが必要です。

このように FTT と障害の許容方法(RAID)をストレージポリシーで指定することで、データの堅牢性とストレージリソースの効率性のバランスを取ることができます。

NSX Data Center

NSX Data Center はネットワーク仮想化とセキュリティのためのコンポーネントです。仮想ネットワーク構築とセグメンテーション、ルーティング、ファイアウォール、NAT、VPN(L2 / L3)、LDAP 認証などの機能を備えています。GCVE では2024年7月現在、3.2.3.1.hp バージョンがデプロイされます。

VM 用のネットワークは、この NSX を利用して構築することになります。

HCX

HCX はオンプレミスとクラウドの間での移行を実現するための機能です。GCVE では2024年7月現在、4.6.2(Enterprise ライセンス)バージョンがデプロイされます。

HCX により、vMotion を使って無停止で VM を移行したり、レプリケーション機能により効率的にデータのコピーを実現できます。また、HCX による L2 延伸を利用することにより、IP アドレスを変更せずに VM を移行することも可能です。その他にも移行プロセスを自動化するための多くの機能を備えています。

HCX で実現できる移行方法として、L2 延伸とセットで利用することで仮想マシンを無停止で移行できる vMotion、レプリケーション機能で事前にデータを移行先に複製しておき、最終切り替え時に vMotion を利用することで大容量ディスクを持つ VM でも無停止移行を実現できる Replication Assisted vMotion(RAV)、最終切り替えのタイミングで VM 停止を伴うが多数の VM の同時移行が可能な Bulk Migration、VM を停止した状態で安全に移行を行う Cold Migration などが挙げられます。

HCX のライセンス料金は GCVE に含まれていますので、オンプレミス側にデプロイするにあたり、追加の料金を支払う必要はありません。

ネットワークの概要

概要図

GCVE プライベートクラウドのネットワーク構成は、以下のようになっています。

オンプレミスとの接続

図の左端は、ユーザーの既存のオンプレミス環境を示しています。オンプレミス環境は、専用線サービスである Cloud Interconnect や、IPSec VPN である Cloud VPN を使って Google Cloud と接続することができます。vMotion などを利用することで、これらのネットワーク接続経由で既存の VMware VM を移行することも可能です。

Google Cloud のネットワーク

図左端のオンプレミス環境は、Cloud Interconnect や Cloud VPN で Google Cloud と接続されます。接続はユーザーの VPC ネットワーク(図左部分の Customer VPC network)で終端されます。これは GCVE 以外の通常の Google Cloud ユーザーが用いる構成と同じです。

そして Customer VPC network は、図の中央左寄り部分に示したように、VPC network peering(Private Service Access) という仕組みで VMware Engine のマネージドな VPC network と接続されます。VPC network peering は Google Cloud の内部的なネットワーク接続の仕組みであり、仮想的なものです。

このような仕組みにより「オンプレミス環境」「Google Cloud の VPC」「GCVE プライベートクラウド」の3環境が、相互に L3 レイヤで接続され、Private IP アドレスで通信できるようになります。

GCVE のネットワーク

図の右寄り部分には、GCVE プライベートクラウド内のネットワークが示されています。

NSX-T によりサブネットを作成し、仮想マシン(VM)用の仮想ネットワークが構成できます(図右上部「NST-X overlay networks」)。このオーバーレイネットワーク上に、VM が配置されます。

その VM 用ネットワークとは別に、プライベートクラウドに1つ、管理用ネットワークが作成されます(図右中央部「Management networks」)。これは Management VLAN とも呼ばれ、各種の管理用トラフィックのために使用されます。

また、図中に表現されていないものとして、HCX の各種サブネットやサービスサブネットと呼ばれる各種アプライアンス向けのサブネットも存在します。

これらのネットワークの IP アドレスレンジを設計するには、公式ドキュメントに記載されている各種要件を考慮に入れる必要があります。

GCVE のノード

GCVE では、各ノードは4つの物理ネットワークインターフェイスを持ちます。vSphere distributed switch(vDS)がデフォルトで作成され、各インターフェイスを接続します。

ネットワークの詳細

DNS 構成

GCVE は、Google Cloud のフルマネージドの DNS サービスである Cloud DNS と統合されています。管理アプライアンスの名前解決は、Cloud DNS を用いて行われます。Cloud DNS は VM の名前解決にも利用できます。また、一部のドメインの名前解決をオンプレミスの DNS に転送することも可能です。以下は、実現できる DNS 構成の例です。

  • プライベートな DNS ゾーンを Cloud DNS で保持し、VM から名前解決させる
  • VM からの特定のドメイン名の名前解決クエリを、オンプレミスの DNS サーバーに転送する
  • VM からのすべての名前解決クエリを、オンプレミスの DNS サーバーに転送する
  • オンプレミスからの名前解決クエリを Cloud DNS で受け付ける

また、vCenter Server、NSX Manager、HCX などの管理アプライアンスの DNS 名を解決するための管理 DNS ゾーンも存在し、ユーザーの VPC とバインド(紐付け)することで、Google Cloud やオンプレミスから名前解決をすることができるようになります。

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

インターネットとの通信

VM とインターネットとの通信を実現するには、Google Cloud 上に作成するエッジ(あるいはゲートウェイ)経由か、あるいはオンプレミス経由で通信させることで実現できます。

エッジは最大 2 Gbps の帯域を確保できる、インターネットへの出入り口です。後述の「ネットワークポリシー」を設定することで定義できます。最小でも /26 の、他のネットワークと重複しない IP アドレス範囲が必要です。

Google Cloud 上のエッジではなく、オンプレミス経由でインターネットへアクセスさせるには、オンプレミスから専用線等経由で Google Cloud へ 0.0.0.0/0 の経路を広報したうえで、ネットワークポリシーにおいて GCVE の外部 IP アドレスサービスやインターネットアクセスサービスを無効化します。

ネットワークポリシー

GCVE のネットワークにはネットワークポリシーが設定可能です。以下のような事項を制御できます。

設定項目 説明
インターネットアクセスサービス 有効化すると VM からインターネットへのアウトバウンド(外向き)トラフィックを許可する
外部 IP アドレスサービス 有効化すると VM に Public IP アドレスを持たせることができるようになり、インバウンド(内向き)トラフィックを受け付けられる。インターネットアクセスサービスが有効である必要がある
エッジサービスのアドレス範囲 VMware Engine パブリック IP ゲートウェイ(エッジ)が使用する IP アドレス範囲

外部アクセスルール

外部アクセスルールは外部 IP アドレスとインターネットの間のアクセス制御を司る、ファイアウォールルールのことです。

ルールには、送信元/先 IP アドレス、送信元/先ポート番号、インターネットプロトコル、優先度などを設定可能です。

VM の移行

代表的な移行手法

既存 VMware 資産たる VM を移行するには、いくつかの方法があります。代表的なものを以下に挙げます。

手法名 概要
VMware HCX を利用したオンライン移行 前述した HCX を使います。方法によっては無停止・IP アドレス変更なしの移行が可能です。
オンプレミス側に HCX をインストールするための余剰リソースが必要です。HCX のライセンスは GCVE に含まれているため、追加調達は必要ありません。
Backup and disaster recovery tools の利用 リストア先として GCVE を指定します。
VMware PowerCLI の利用 移行先として GCVE を指定します。
ISO ファイルとテンプレートの利用 GCVE に ISO ファイルをアップロードし、vSphere コンテンツライブラリで公開されている VM テンプレートを使用して、新しい VM を作成

HCX を使った移行

HCX を用いた L2 レイヤでのネットワーク延伸(以下、L2 延伸)と vMotion を用いたライブマイグレーション(無停止移行)は、最も低い工数で迅速に移行を実現できる方法です。

ただし、既存の VMware 上に HCX をインストールする必要があります。その際は余剰リソースと、vSphere バージョンの互換性に注意してください。2024年7月現在の GCVE でデプロイされる HCX は、バージョン 4.6.2 です。このバージョンの HCX では、vSphere(ESXi)7.0 以上がサポート対象です。

また、HCX で L2 延伸を利用するには、オンプレミス側 vSphere 環境の仮想スイッチは vDS(vSphere Distributed Switch、分散スイッチ)である必要があります。vDS の利用には、vSphere Enterprise Plus ライセンスを要します。

このように HCX を使った移行には一定の要件があるため、場合によっては既存環境への構成変更が必要な場合があります。現行環境への影響を最小限にしたい場合、オンプレミスの余剰リソースを利用して移行用の「踏み台」となる vSphere 環境を構築するという手法も考えられます。この方法では VM を移行元環境からいったん踏み台環境に vMotion(通常の vCenter の機能)で無停止移行します。この踏み台環境は HCX の要件を満たしているので、踏み台環境から GCVE へは、HCX を使った L2 延伸と vMotion で移行を実現できます。

なお、L2 延伸はあくまで VM 移行のために一時的に実現するネットワーク構成であり、永続的なものとするべきでない点には十分ご留意ください。

運用・保守

バックアップ

標準のバックアップ

GCVE では、標準では以下がバックアップされ、Google Cloud のオブジェクトストレージである Cloud Storage に保存されます。

  • vCenter、PSC、DVS rule(夜間に増分バックアップ)
  • NSX の構成
  • vCenter native API
  • VMware 管理系ソフトウェアのアップグレード前の自動バックアップ

ただし、上記には VM とそのデータが含まれていません。VM とデータをバックアップするには、後述する Backup and DR などを使います。

Backup and DR Service

GCVE では、VM とデータをバックアップする機能が、Google Cloud サービスである Backup and DR Service(バックアップと DR サービス)によって提供されます。

Backup and DR Service によるバックアップでは、VM イメージが増分バックアップされます。最初のバックアップ時に各ディスクの VMDK snapshot が作成され、2回目以降は増分バックアップになります。

ユーザーの VPC にバックアップ用アプライアンスが Compute Engine VM として配置され、データをバックアップ・転送します。Backup and DR Service では、バックアップデータは Cloud Storage に保存されます。Cloud Storage は、容量無制限で堅牢、フルマネージドなオブジェクトストレージサービスです。

Backup and DR Service

なおこの方法では、VM のディスク単位のスナップショットが採取されるため、VM 上で稼働する固有のソフトウェアの考慮はされません。オプショナルで、エージェントを使ったバックアップを設定すると、Oracle Database、Microsoft SQL Server、PostgreSQL などのデータベースエンジンのバックアップ機能とエージェントが連動して、安全にバックアップを取得することが可能です。

Backup and DR Service のエージェントを使ったバックアップを検討する際は、エージェントの対応 OS や追加料金に注意してください。

サードパーティによるバックアップ

Backup and DR Service を使う方法の他には、Dell EMC Data Protection Solution、Veeam Backup & Replication、Commvault Backup & Recovery などのサードパーティ製品により、バックアップを実現することも可能です。

モニタリング

GCVE の VM 監視には、vCenter monitoring tools や VMware を対象とする従来のサードパーティツールの利用が可能です。また、マルチクラウド向けの管理プラットフォーム製品 VMware Aria の一部である VMware Aria Operations を利用することもできます。適切なモニタリング手法の選択については、以下の記事を参照してください。

また Google Cloud のネイティブなモニタリングサービスである Cloud Monitoring を利用することも可能です。スタンドアロンエージェントを VM にインストールすることで、指標を Cloud Monitoring に送信すると、Google Cloud コンソールで各種パフォーマンス情報が閲覧可能になります。また Cloud Monitoring のアラート機能を用いると、指標がしきい値を超えた場合などに通知を発報することができます。

Cloud Monitoring については、以下の記事を参照してください。

blog.g-gen.co.jp

GCVE ノード、vCenter、NSX、HCX の重要な障害は Cloud Logging にログエントリとして送信されるため、これをログベースのアラート機能で通知することも可能です。

Cloud Logging やログベースのアラート機能については以下の記事を参照してください。

blog.g-gen.co.jp

メンテナンス

物理的なメンテナンス

可用性の項目でも記載したとおり、GCVE では、障害が発生した ESXi ノードやディスクなどは自動的に交換され、VM に影響が出ないようになっています。その他の Google Cloud が管理する物理インフラストラクチャのメンテナンスも、ほとんどの場合はユーザーが意識しないところで行われ、VM に影響は出ません。

ただし、月1回程度の GCVE のコントロールプレーンの更新時などに、一時的に GCVE ポータル(GCVE 用の Google Cloud コンソール画面)のダウンタイムが発生する場合があります。このような場合には事前に通知が行われます。ポータルのダウンタイムの間でも、VM 自体に影響はありません。

ソフトウェア的なメンテナンス

ESXi、vCenter、PSC、NSX などの VMware 系ソフトウェアのパッチやアップデートは、Google Cloud とメンテナンス時間枠を調整のうえ、実施されます。VMware からメジャーバージョンがリリースされてから、6か月以内に適用されます。

監査ログ

GCVE は Cloud Audit Logs と統合されており、監査ログが出力・保管されます。ただしここで記録されるアクションは、VMware の世界のアクションではなく、Google Cloud のレイヤのアクションが記録されます。例えば、以下のようなものです。

  • GCVE クラスタの追加、削除
  • GCVE ノードの追加、削除
  • ネットワークポリシーの作成、変更、削除
  • 外部 IP アドレスの作成、変更、削除

また、人間のオペレーターやサポート担当者の操作に関するログも出力・保管されます。

前述のとおり、Cloud Audit Logs によって取得されるのは Google Cloud のレイヤのアクションのみです。VM 上で稼働するワークロードに関するログは、ユーザー側の責任で、適切に出力・保管する必要があります。

Cloud Audit Logs については、以下の記事も参照してください。

blog.g-gen.co.jp

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。