G-gen の杉村です。 Google Cloud (旧称 GCP) のマネージドの RDBMS サービスである Cloud SQL について徹底的に解説します。

Cloud SQL とは
料金
Cloud SQL editions
Cloud SQL Studio
- Cloud SQL Studio とは
- Gemini in Database
インスタンス
vCPU とメモリ
- マシン構成
- 運用中の変更
ストレージ（ディスク）
高可用性構成（HA 構成）
リードレプリカ
バックアップとリストア
ネットワークと接続方法
Cloud SQL Auth Proxy
認証・認可
メンテナンス
モニタリング・ロギング
監査
- クラウドリソースとしての監査ログ
- データベースとしての監査ログ
暗号化
- デフォルトの暗号化
- その他の暗号化
その他留意事項
- データベースエンジンごとの機能差
- 標準的なデータベースとの違い

Cloud SQL とは

Cloud SQL は、Google Cloud（旧称 GCP）のマネージドな RDBMS サービスです。

Cloud SQL では、利用者は OS レイヤや物理基盤を意識することなく、MySQL や PostgreSQL 等のデータベースを利用することができます。いわゆる DBaaS とも呼ばれる分類のサービスであり、他社サービスでは Amazon Web Services（AWS）の Amazon RDS がこれにあたります。

Cloud SQL の対応データベースエンジンは MySQL、 PostgreSQL、Microsoft SQL Server です。データベースエンジンはインスタンス作成時に選択し、後から変更することはできません。

作成したデータベースは、プライベート IP アドレスまたはパブリック IP アドレス経由で、通常のデータベースクライアントからアクセスできます。また Cloud SQL Studio という Web インターフェイスも用意されており、Google Cloud コンソール画面からテーブルの管理や SQL の実行が可能です。

Cloud SQL は簡単に利用開始できるほか、データベースエンジンのインストールやアップデート、バックアップやモニタリング、 CPU やメモリ、ストレージの拡張などの工数を大幅に削減することができます。また複数のゾーンにまたがる冗長化設定やリードレプリカの作成も容易です。

また、BigQuery など他の Google Cloud サービスとの連携もシームレスに行うことができます。

Google Cloud にホストするアプリケーションでリレーショナルデータベースを利用する際は、第1に採用を検討するべきサービスといえます。

参考 : Cloud SQL overview

料金

Cloud SQL の料金

Cloud SQL は従量課金です。割り当てた vCPU コア数、メモリ、ストレージ量などに対して、時間単位で課金されます。

データベースエンジンとして Microsoft SQL Server を選択した場合は、起動時間に応じて1時間単位でライセンス料金が発生します。

また Cloud SQL for MySQL と for PostgreSQL にはエディションの概念があります（後述）。Enterprise エディションと Enterprise Plus エディションがあり、後者は vCPU/メモリあたりの単価が高い代わりに、より高い可用性 SLA・短いダウンタイム・キャッシュ用ストレージなどが利用可能です。

月額費用の例として、Enterprise エディションの Cloud SQL for PostgreSQL を「vCPU: 2、RAM: 8 GB」で 1 ヶ月間フル稼働すると、約 21,864 円 / 月です (2023年7月時点、東京リージョン、140円/ドル、ストレージは 100GB SSD) 。

最新の利用料金は以下の公式ページでご確認ください。また、公式の見積もりツールで料金が試算できます。

確約利用割引

Cloud SQL には確約利用割引（Committed use discount / CUD）の仕組みがあります。

1年間または3年間の利用を確約（コミット）することで最大52%の割引を受けることができます。確約利用割引は、Google Cloud のコンソール画面から購入します。

確約利用割引は vCPU とメモリの料金に対して利用することができますが、ストレージ / バックアップ / ライセンス / ネットワーク料金には適用することができません。

詳細は以下の公式ドキュメントをご確認ください。

参考 : 確約利用割引

Extended Support（延長サポート）

Cloud SQL では MySQL や PostgreSQL からのコミュニティサポートが終了後、Google Cloud による有償の Extended support（延長サポート）を受けることができます。

Extended support 期間中は、セキュリティパッチ、バグフィックスなどが提供され、SLA の対象にもなります。

参考 : Extended support for Cloud SQL

Extended support 期間に入ったインスタンスは、稼働時間あたり、追加の料金が発生します。

参考 : Extended support pricing

Cloud SQL editions

Cloud SQL editions とは

Cloud SQL for MySQL と for PostgreSQL にはエディションの概念があります。Enterprise と Enterprise Plus エディションが存在し、前者は一般的なユースケースに、後者はより高い可用性とパフォーマンスが求められる場合に利用します。

Enterprise Plus エディションでは読み取り・書き込みの両パフォーマンスが Enterprise と比較して高くなります。公称では Cloud SQL Enterprise Plus for MySQL で「読み取りスループットが最大 3 倍、書き込みレイテンシが最大 2 倍向上」とされます。また可用性 SLA の向上、メンテナンス時のダウンタイムの短縮、トランザクションログの保持期間の長期化など、よりエンタープライズ・レディな仕様です。

エディションはインスタンスごとに選択することが可能で、1つのプロジェクトの中で複数のエディションを併用することは問題ありません。

Enterprise と Enterprise Plus の違い

それぞれのエディションには以下のような違いがあります。

比較観点	Enterprise	Enterprise Plus
料金	-	vCPU/Memory の時間単価が Enterprise の約1.3倍
DB バージョン	MySQL 5.6, 5.7, 8.0 PostgreSQL 9.6, 10, 11, 12, 13, 14, 15	MySQL 8.0 PostgreSQL 14, 15
マシンタイプ	General purpose machine family	Performance optimized N family
マシンスペック最大値	最大 96 vCPU 最大 624 GB RAM コア:メモリ比 = 1:6.5	最大 128 vCPU 最大 864 GB RAM コア:メモリ比 = 1:8
可用性 SLA	99.95%	99.99%
メンテナンス時ダウンタイム	60 秒未満	10 秒未満
データキャッシュ	利用不可	オプションで利用可
ポイントインタイムログ保持期間	最大7日間	最大35日間
書込レイテンシ	-	Enterprise と比較して最大2倍向上
自動チューニング	-	基盤に応じて自動チューニング
対応リージョン	-	Enterprise と比較して限定的 (Tokyo は対応)

参考 : Introduction to Cloud SQL editions

データキャッシュ

Enterprise Plus エディションではデータキャッシュが利用可能です。高速なローカル SSD をバッファ領域とすることで、読み取りパフォーマンスが向上します。

データベースはメインメモリ＞ローカル SSD (データキャッシュ)＞ストレージの順にデータを探します。書き込み時には、ストレージへの書き込みとローカル SSD (データキャッシュ) への書き込みを同時に行います。

当機能の利用はオプションであり、インスタンス作成時の設定または作成後の変更が可能です。割り当てた SSD の GB 数に応じて料金が発生します。

以下のような場合に当機能の利用が推奨されています。

ワークロードがメインメモリに収まらない場合
書き込みよりも読み取りが多いワークロードの場合

また MySQL インスタンスでは、インスタンスに 16 コア以上の vCPU を割り当てられている場合にデータキャッシュの恩恵がより受けられるとされています。

参考 : Data cache overview (MySQL)
参考 : Data cache overview (PostgreSQL)

料金の違い

Enterprise Plus エディションでは、vCPU とメモリの時間単価が Enterprise と比較して約1.3倍となります。

またオプションで割り当てたデータキャッシュ用ストレージにも、GB あたりの料金が発生します。HA 構成にする場合、スタンバイインスタンスにもデータキャッシュ用ストレージを割り当てるため、倍の料金が発生します。

参考 : Cloud SQL pricing

Enterprise Plus への移行

Enterprise エディションのインスタンスを Enterprise Plus エディションに移行するには、gcloud コマンドラインを使います。

gcloud sql instances patch コマンドで --edition=ENTERPRISE_PLUS オプションを指定します。変更には60秒未満のダウンタイムを伴います。Enterprise Plus エディションから Enterprise エディションへのダウングレードも可能です。

Cloud SQL Studio

Cloud SQL Studio とは

Cloud SQL には Cloud SQL Studio という Web ユーザーインターフェイスが用意されています。

Cloud SQL Studio は Google Cloud コンソールからアクセスできる Web 画面であり、データベース名とパスワードを入力することで、Web ブラウザから Cloud SQL のデータベースに接続できます。

Web 画面でテーブルの管理や SQL の実行が可能です。なおこの Web 画面は BigQuery の Web ユーザーインターフェイスと似ています。

参考 : Cloud SQL Studio を使用してデータを管理する

Gemini in Database

Cloud SQL Studio では、Google が開発する生成 AI 基盤モデルである Gemini を利用することができます。この機能は、Gemini in Database と呼ばれます。

Gemini を使うと、日本語での指示によって自動的にクエリを生成し、データベースに投入することが可能です。以下の記事もご参照ください。

blog.g-gen.co.jp

インスタンス

インスタンスとは

Cloud SQL はインスタンスという単位で管理します。インスタンスは1台の仮想サーバーであるとイメージすればよいでしょう。

データベースエンジン（MySQL、PostgreSQL、SQL Server）、vCPU コア数、メモリ数、ストレージサイズなどを指定してインスタンスを作成すると、データベースがインストール済みの仮想サーバーが自動的に構築されます。

起動と停止

Cloud SQL インスタンスは、データベースを利用しない間は停止することができます。

停止されたインスタンスには vCPU とメモリの料金が発生しません。ただし確保されたストレージに対しては料金が発生し続けるほか、確保された IP アドレスの利用料金もわずかに発生します。

なおインスタンスのストレージ容量が上限に近づくと、データロスを防ぐためインスタンスが自動的に停止されることがあります。オンプレミスや仮想サーバーで動作するデータベースと同様に、ストレージ使用率の適切なモニタリングが必要です。必要に応じて、後述のストレージ自動拡張機能を有効化することも検討します。

なお後述のリードレプリカインスタンスは停止することができません。

データベースフラグ

データベースフラグとは、データベースエンジン（MySQL、PostgreSQL、SQL Server）が持つパラメータを設定するための Cloud SQL インスタンスの設定値です。

Cloud SQL では OS レイヤやミドルウェアレイヤを Google Cloud が管理しているため、例えば PostgreSQL でいう postgresql.conf ファイルなどの設定ファイルを直接編集できません。

そのため Cloud SQL ではデータベースパラメーターは、データベースフラグという Cloud SQL インスタンスの設定値として管理されます。

データベースエンジンが用意している全てのパラメータが Cloud SQL でも利用可能というわけではなく、パラメータによっては変更不可なものがあります。対応状況は以下のドキュメントをご参照ください。

参考 : データベースフラグを構成する

なお、上記は PostgreSQL 版ドキュメントへのリンクとなっていますが、タイトルの見出し横のリンクから別のデータベースエンジンのドキュメントへ移動することができます。以下、全てのドキュメントで同じです。

vCPU とメモリ

マシン構成

Cloud SQL では、vCPU 数とメモリ量をカスタムして、適切なサイズのインスタンスを作成できます。

参考 : インスタンスを作成する

なお検証目的等のため、比較的スペックが低い共有コア CPU を使用するインスタンスを構築することもできます。共有コアを使う場合は、通常とは別単価が設定されているほか、SLA が適用されません。

参考 : Cloud SQL Service Level Agreement (SLA)

運用中の変更

vCPU とメモリ量は前述の通り、インスタンスの初期作成時にマシンタイプを指定することで決定しますが、インスタンスを編集することで後から変更できます。

ただし vCPU やメモリーの割り当て変更にはインスタンスの再起動が必要です。再起動を行うと、一時的にデータベースに接続できなくなります。

参考 : インスタンスを編集
参考 : インスタンスの設定について

ストレージ（ディスク）

種類

Cloud SQL を作成時、使用するストレージ（ディスク）を HDD（ハードディスクドライブ）か SSD の中から選ぶことができます。どちらの場合でも複数の物理ドライブにデータが複製されているので、高い堅牢性が確保されます。

一般的な用途では SSD が推奨されます。一方の HDD は SSD よりもパフォーマンスに劣りますが、料金単価が安い点が特徴です。

通常のユースケースでは SSD を選択します。一方で、データ容量が大きくかつレイテンシが問題にならない場合、特にランダムリードアクセスの頻度が低く、シーケンシャルライトが中心のワークロードの場合のみ、HDD を選択すると良いでしょう。

参考 : SSD ストレージと HDD ストレージのいずれかを選択する

容量

ストレージの容量はインスタンス作成時に指定できます。またインスタンス作成後にも拡張が可能です。ただし、ストレージの縮小はできません 。

ストレージの拡張は、インスタンスを起動したまま行うことができ、ダウンタイムは発生しません。

ストレージの自動増量

Cloud SQL インスタンスでは、オプションでストレージの自動増量を有効化することができます。ストレージの自動増量を有効化すると、ストレージの残容量が 30 秒ごとにチェックされ、残容量が一定回数以上、閾値を下回るとストレージが追加されます。

またストレージの自動増量には上限値を設定することもできます。

ストレージ自動拡張のトリガとなる閾値の計算方法などの詳細は、以下のドキュメントを参照してください。

参考 : ストレージの自動増量を有効にする

パフォーマンス

Cloud SQL のストレージのパフォーマンスは IOPS とスループットで表されます。

Cloud SQL ではバックエンドに Compute Engine（Google Cloud の仮想サーバーサービス）を使われており、IOPS とスループットが決まる仕組みは Compute Engine の永続ディスクと同じです。

原則的に、ストレージのサイズを大きくすればするほど IOPS とスループットが大きくなっていきます。詳細は、以下の記事の「永続ディスクのパフォーマンス」の項を参考にしてください。

参考 : Compute Engineを徹底解説！（応用編） ‐ 永続ディスクのパフォーマンス

また MySQL/PostgreSQL で利用可能な Cloud SQL Enterprise Plus エディションでは、書き込みレイテンシが最適化されているためより高い性能が発揮できるほか、データキャッシュにより読み取りレイテンシの最小化を図ることもできます。

高可用性構成（HA 構成）

概要

Cloud SQL インスタンスでは、簡単に高可用性構成を有効化することができます。インスタンス作成時に、高可用性のオプションのチェックマークを入れるだけで、プライマリインスタンス（主系）と、別のゾーンで起動するスタンバイインスタンス（従系）を作成できます。高可用性構成は HA 構成（High Availability 構成）とも呼ばれます。

高可用性構成では、プライマリインスタンスに障害が発生した際、自動的にスタンバイインスタンスにフェイルオーバーします。

プライマリインスタンスからスタンバイインスタンスへは、永続ディスクにデータが同期レプリケーションされます。つまり高可用性構成のデータベースのトランザクションは、両方のゾーンのディスクに書き込まれて初めてコミット完了となります。

そのため、高可用性構成のインスタンスの書き込みパフォーマンスは、高可用性構成でない場合と比べて劣る可能性があります。どのくらいの影響が出るかは、ディスク容量に応じた IOPS やデータ量などによるため一概には言えず、検証する必要があります。

また高可用性構成を有効化するとインスタンスが2台稼働するため、インスタンスの CPU、メモリ、ストレージ料金が2倍発生します。

参考 : 高可用性について

フェイルオーバー

Cloud SQL は毎秒、データベースに対してハートビート（ヘルスチェック）を送ります。プライマリインスタンスが約60秒間応答しない、またはプライマリインスタンスのゾーンで Cloud SQL としてのサービス停止が発生した場合にフェイルオーバーが発動します。

セカンダリインスタンスがプライマリに昇格すると IP アドレスも引き継がれるため、アプリケーションから見ると、若干のダウンタイムの後に透過的に新プライマリインスタンスに接続できるようになります。

なおフェイルオーバー後に旧プライマリインスタンスが正常に戻っても、自動的にフェイルバックはしません。プライマリを元のゾーンに戻したい場合は明示的に再度、手動でフェイルオーバーを実行してフェイルバックする必要があります。

参考 : フェイルオーバーを開始する

フェイルオーバーの発生履歴はオペレーションログから確認できます。

参考 : インスタンスのオペレーションログを表示する

可用性 SLA

Cloud SQL SLA では「高可用性構成であること」「共有コアインスタンスではないこと」など一定の条件のもとに、 Cloud SQL サービスのダウンタイムが一定期間を超えるとクレジットの払い戻しが受けられることが定義されています。

Enterprise エディション（MySQL、PostgreSQL）および Microsoft SQL Server インスタンスでは条件を満たしていれば月間 99.95% 以上の可用性が、Enterprise Plus エディション（MySQL/PostgreSQL）では月間 99.99% 以上の可用性が定義されています。

詳細な定義は、以下の公式ドキュメントをご参照ください。

参考 : Cloud SQL Service Level Agreement (SLA)

リードレプリカ

リードレプリカとは

リードレプリカは、Cloud SQL インスタンスのコピーであり、読み取りリクエストを負荷分散する目的で利用します。

参考 : Cloud SQL でのレプリケーションについて

プライマリインスタンスのデータが更新されると、ニアリアルタイムでデータがリードレプリカに非同期レプリケーションされます。レプリケーションの遅延は Cloud Monitoring のメトリクスで確認することができます。

参考 : レプリケーションのステータスを確認する

リードレプリカは読み取りリクエストを受け取れますが、書き込みリクエストを受け取ることはできません。

リードレプリカは高可用性構成（HA 構成）と似ているように思えますが、高可用性構成は可用性の向上が目的である一方、リードレプリカは読み取りワークロードの負荷分散が目的であるという点で異なります。

リードレプリカは高可用性が目的ではないものの、リードレプリカをプライマリインスタンスに手動で昇格させることが可能です。これにより後述のクロスリージョンリードレプリカを用いて、リージョン間の災害対策（DR）を実現することも可能です。

参考 : レプリカをプロモートする

クロスリージョンリードレプリカ

リードレプリカには通常のリードレプリカの他に、クロスリージョンリードレプリカが存在します。

クロスリージョンリードレプリカは、異なるリージョン間でデータを同期します。以下のような目的で利用されます。

他リージョンのアプリケーションからのデータベース読み取りのレイテンシを抑える
リージョン間のデータ移行
リージョン間の災害対策（DR）

レプリカと災害対策（DR）

高可用性構成（HA 構成）は「可用性の向上」が目的であり、一方のリードレプリカは「読み取りワークロードの負荷分散が目的であるという違いがあります。これらは異なる仕組みですが、高可用構成とリードレプリカを併用した以下のような構成が可能です。

また、クロスリージョンリードレプリカを用いることで、別のリージョンにリードレプリカを構成し、リージョンレベルの災害対策（DR）を行うことができます。レプリカをプライマリインスタンスに昇格させる際は、手動で昇格を指示する必要があります。

参考 : Cloud SQL の障害復旧（DR）について

また Enterprise Plus エディションでは、高度な障害復旧（advanced disaster recovery）機能を使うことができます。高度な障害復旧では、レプリカをプライマリインスタンスに昇格させると、旧プライマリインスタンスはレプリカになります。また、スイッチオーバーという操作で、旧プライマリインスタンスを再びプライマリインスタンスに昇格させることもできます。

参考 : 高度な障害復旧（DR）を使用する

外部レプリカ

Cloud SQL では外部レプリカ（External replica）も構成可能です。

外部レプリカを構成すると、オンプレミスや他のパブリッククラウドの MySQL、PostgreSQL、SQL Server から Cloud SQL に対してデータを同期できます。 MySQL ではさらに、逆に Cloud SQL のデータベースを外部にレプリケーションできるなど、データベースエンジンによって実現可能なことが異なります。

外部レプリカは高可用性目的や災害対策（DR）目的の他、データベースの移行の目的で利用されることもあります。

参考 : 外部レプリカを構成する

バックアップとリストア

バックアップ

仕組み

Cloud SQL にはインスタンス稼働中にデータをバックアップする機能があります。

バックアップにはオンデマンドバックアップ（手動）と自動バックアップがあります。どちらも同じ仕組みをベースとしており、バックアップを手動で開始するか、自動でスケジューリングするかの違いです。

Cloud SQL インスタンスのバックアップを取得すると、取得開始した時点のインスタンスのデータが保存されます。既にバックアップが存在するインスタンスで複数回バックアップを取得すると、2回目以降は増分バックアップになります。つまり、前回のバックアップ時点から変更されたデータのみがバックアップされます。なお、最も古いバックアップが削除されたとしても、その次に古いバックアップにフルバックアップが引き継がれるため「どれがフルバックアップでどれが増分バックアップか」を気にする必要はありません。

リストアの項で後述しますが、バックアップからのリストアは既存 Cloud SQL インスタンスを上書きする、あるいは新しい Cloud SQL インスタンスを生成することになります。

参考 : Cloud SQL バックアップについて

料金

ストレージ容量に応じて、バックアップを保存している期間だけ料金が発生します。料金は2024年11月現在、東京リージョンで $0.104/GB/月です。

例として 100 GB ストレージの Cloud SQL インスタンスのバックアップを 7 世代保存するとします。1 世代目のバックアップの容量は 100 GB であり、その後の世代は 10 % ずつ変更があるとすると、料金は以下のようになります。

100 GB + (10 GB × 6) = 160 GB
→ 160 GB × $0.104 = $16.64 / 月

自動バックアップ

Cloud SQL ではデフォルトで、7世代の自動バックアップが日次で取得されます。世代数は 0（無効化）〜365世代の間で設定できます。

自動バックアップの取得は日次で行われ、取得時刻は4時間の幅で指定されたバックアップウインドウの時間帯で行われます。バックアップ取得によりダウンタイムが発生することはありませんが、多少のパフォーマンス影響はありえるため、可能な限り利用者が少ない時間帯に設定することが望ましいです。

保存先ロケーション

バックアップの保存先のロケーション（リージョン）を指定することができます。

何も指定しない場合はインスタンスに最も近い「マルチリージョン」のロケーションに保存されます。インスタンスが東京リージョンにあれば asia というマルチリージョンに保存されます。データが複数リージョンに冗長化されるため、リージョン単位の大規模障害でもデータの堅牢性が保持されます。

トランザクションログ

リストアの項でも記載しますが、Cloud SQL ではポイントインタイムリカバリ（PITR）が可能です。ポイントインタイムリカバリは Cloud SQL 用語というわけではなく、データをある日時・時刻の状態に巻き戻すというリカバリ方法を指す一般的な用語です。

参考 : ポイントインタイムリカバリ（PITR）を使用する

ポイントインタイムリカバリには、データベースのトランザクションログを用います。トランザクションログは、MySQL ではバイナリログ（binlog）、PostgreSQL では WAL（Write Ahead Logging）と呼ばれます。

トランザクションログの保持期間は、Enterprise エディションでは1～7日の範囲で、Enterprise Plus エディションでは1〜35日の範囲で設定できます。デフォルト値は7日です。トランザクションログの保持期間は PITR の必要性に応じて期間を設定します。ただし、自動バックアップの保持期間より長く設定することはできません。

なおトランザクションログはかつては通常のデータ領域と同じディスクに保存されていましたが、PostgreSQL は2023年1月から、MySQL は2023年8月から、SQL Server は2024年5月から、Cloud Storage に保存されるようになりました。それ以前からポイントインタイムリカバリを有効にしている場合はトランザクションログがディスク領域を圧迫していますが、一度無効化してから再度有効化することでログが Cloud Storage に保管されるようになります。ただしこれを行った場合、直近のログは消えてしまいますので注意が必要です。

リストア

前述のバックアップ機能で取られた Cloud SQL インスタンスからのリストアは、以下のいずれかの方法で実現できます。

名称	説明	条件・制約等
同じインスタンスへの復元	元のインスタンスの中身をバックアップ時の状態に復元	-
別のインスタンスへの復元	バックアップから別のインスタンスを生成	別プロジェクトにも復元可。データベースフラグは復元されない
ポイントインタイムリカバリ	特定時点の状態に復元。ただし別インスタンス生成となり元のインスタンスは巻き戻せない	対象時点のバックアップとトランザクションログが必要

参考 : インスタンスの復元について
参考 : ポイントインタイムリカバリ（PITR）を使用する

注意点として、ポイントインタイムリカバリ（PITR）は「元のインスタンスをある時点に巻き戻す」のではなく「ある時点の状態のインスタンスを別インスタンスとして作成する」という挙動になります。

そのため PITR 実施後にはアプリケーションの向き先を変更したり、あるいは復元した新インスタンスから必要なデータだけを抜き取るなどが必要です。

インポート・エクスポート

Cloud SQL の標準機能のバックアップを、Google Cloud の外にエクスポートすることはできません。

ただし、各データベースエンジンの機能によるダンプファイルのエクスポートや CSV ファイルとしてのエクスポートおよびインポートは可能です。

データベースエンジンによりますが、Google Cloud コンソールや gcloud コマンドによる操作で、Cloud Storage へこれらのファイルを直接エクスポートさせることも可能です。

また Cloud SQL for MySQL と for PostgreSQL では、サーバーレスエクスポート機能があります。エクスポートジョブを実行するための一時的なインスタンスが作成され、そこからダンプファイルが Cloud Storage バケットへエクスポートされるため、本番インスタンスへのパフォーマンス影響を回避できます。

詳細は以下のドキュメントやその周辺リンクからご確認ください。

参考 : SQL ダンプファイルを使用したエクスポートとインポート

ネットワークと接続方法

Cloud SQL とネットワーク

Cloud SQL インスタンスは Google Cloud が管理する VPC（Virtual Private Cloud）ネットワーク内に作成されます。ユーザーが管理する VPC ネットワークではなく、Google が管理する VPC ネットワーク である点がポイントです。この Google 管理の VPC ネットワークは、Google Cloud コンソール等で見ることができず、ユーザーの視点からは隠されています。

AWS の Amazon RDS を例に取ると、Amazon RDS インスタンスはユーザーが所有する VPC に作成できます。一方、Cloud SQL インスタンスはそうではなく、Google が管理するマネージドな VPC ネットワーク内にインスタンスが作成されるのが特徴です。そして、この Google 管理の VPC ネットワークと、ユーザーが管理する VPC ネットワークの間で VPC ネットワークピアリングを作成することで、Cloud SQL インスタンスを利用できます。この仕組みはプライベートサービスアクセスと呼ばれます。インスタンスが配置される Google 管理の VPC ネットワークをサービスプロデューサーのネットワークと呼びます。

Cloud SQL インスタンスへの接続

ユーザーのアプリケーションから Cloud SQL に接続するには、以下の選択肢があります。

パブリック IP アドレス（Public IP address）に接続
プライベート IP アドレス（Private IP address）に接続
書き込みエンドポイント（write endpoint）に接続

前者は Cloud SQL インスタンスにパブリック IP アドレスを割り振り、インターネット経由でアクセスする方法です。

後者は Cloud SQL インスタンスにプライベート IP アドレスを割り振ります。そのうえで、ユーザーの VPC と Cloud SQL が存在するサービスプロデューサーのネットワークを VPC ネットワークピアリングで接続して利用することになります。

パブリック IP アドレスで接続

仕組み

Cloud SQL にはパブリック IPv4 アドレスを持たせ、インターネット経由でアクセスすることができます。IPv6 には未対応です。パブリック IP アドレスは無効化することができ、その場合は後述のプライベート IP アドレスを使用して接続します。

参考 : パブリック IP を構成する

パブリック IP アドレスを使う場合、インターネット経由でのアクセスとなりますので、アプリケーションと Cloud SQL インスタンス間の通信は SSL/TLS で暗号化することが強く推奨されます。

なお後述の Cloud SQL Auth Proxy 等を使えば、通信は自動的に暗号化されます。

参考 : SSL / TLS 証明書を使用して承認する

アクセス制御

インターネットからの無制限のアクセスを許可することはセキュリティ上のリスクであるため、Cloud SQL では、明示的に許可する接続元 IP アドレスをホワイトリスト形式で指定できます。

この許可対象の接続元 IP アドレスリストは承認済みネットワークと呼ばれます。逆に、承認済みネットワークを一つも設定しない場合、インスタンスへの接続は不可能です。

承認済みネットワークは CIDR 形式で指定します。xx.yy.zz.0/24 のようにプレフィックスを指定して、IP アドレス範囲を登録することができます。

プライベート IP アドレスで接続

仕組み

多くの場合、セキュリティ上の理由から Cloud SQL にはパブリック IP アドレスを持たせないことが推奨されます。この場合、プライベート IP アドレスを用いて Cloud SQL インスタンスに接続します。

参考 : プライベート IP の使用方法の詳細

前述したとおり、Cloud SQL インスタンスは Google 管理の VPC ネットワークに作成されます。そのためユーザーの VPC と Google の VPC を VPC ネットワークピアリングと呼ばれる仕組みで接続します。

なおこのように、インスタンスが Google 管理の VPC ネットワーク（サービスプロデューサーのネットワーク）に作成され、ユーザー管理の VPC ネットワークと接続して利用する仕組みをプライベートサービスアクセスと言います。 Cloud SQL 以外にも Memorystore、Cloud Build、Vertex AI などで利用されるネットワーク形態です。

参考 : プライベートサービスアクセス

サービスプロデューサーのネットワークの作成

サービスプロデューサーのネットワーク（プライベートサービスアクセス用のサブネット）は、プロジェクトで Cloud SQL インスタンスを初めて起動するときに IP アドレスレンジを指定して作成します。

指定可能な最小サイズは /24 ですが、推奨は /16 とされています。このとき、Cloud SQL を利用する予定の接続元ノード（Compute Engine VM 等）があるネットワークと重複しない IP アドレス帯を割り当てる必要があります。重複すると、適切なルーティングができず、クライアントと Cloud SQL インスタンスは通信できません。

一度サービスプロデューサーのネットワークを作成すれば、次回以降に Cloud SQL や Memorystore のインスタンスを構築する際は、そのネットワークを流用することができます。

設定方法

コンソール画面では、指示に沿って設定を進めることで Cloud SQL にプライベート IP アドレスを割り当て、サービスプロデューサーのネットワーク（プライベートサービスアクセス用のサブネット）を作成し、ユーザー管理の VPC との接続を有効化することで、Compute Engine VM 等から Cloud SQL インスタンスへ到達することができるようになります。

なおプライベート IP アドレスの割り当ては、Cloud SQL インスタンスの初期構築時のほか、既存のパブリック IP アドレスを利用する Cloud SQL インスタンスを設定変更して、プライベート IP アドレスの利用に変更することも可能です。

アクセス制御

Cloud SQL インスタンスが存在するサービスプロデューサーのネットワークにはVPC ファイアウォールルールを任意に設定できません。

またパブリック IP アドレスでアクセス制御に用いる「承認済みネットワーク」の仕組みは、プライベート IP アドレスでは原則的に使えません。RFC 1918 アドレス範囲 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) は自動的に許可される仕様となっています。ただし、クライアントが RFC 1918 以外のアドレス範囲に存在する場合のみ、明示的に承認済みネットワークに追加する必要があります。

参考 : 制限事項

そのためプライベート IP アドレスを用いる場合は、アクセス元 VPC ネットワークのファイアウォールルール等で、アウトバウンド接続を制限するなどしてトラフィックを制御します。

アクセス元を厳しく制限したい場合は、プライベート IP アドレスではなくあえてパブリック IP アドレス接続を設定し、承認済みネットワークに1つも CIDR を登録せず、Cloud SQL Auth Proxy（後述）での IAM 接続元承認を用いることで、特定のサービスアカウントからのみ接続できるように制限する方法も考えられます。

書き込みエンドポイントで接続

書き込みエンドポイント（write endpoint）は、常にプライマリインスタンスのプライベート IP アドレスを指す DNS 名です。書き込みエンドポイントを使って接続することで、別リージョンに構成したリードレプリカをプライマリインスタンスとして昇格した際も、アプリケーション側で向き先 IP アドレスを変更する必要がなくなります。

書き込みエンドポイントは、プライベート IP アドレスを有効化した Enterprise Plus エディションの Cloud SQL インスタンスのみで利用可能です。そのため、基本的な使い方は、前述のプライベート IP アドレスに関する項目をご参照ください。

また、Cloud SQL Auth Proxy では書き込みエンドポイントを使えないことに注意が必要です。

2024年11月現在、当機能は Preview です。

参考 : Connect by using a write endpoint

Cloud SQL Auth Proxy

Cloud SQL Auth Proxy とは

Cloud SQL に接続するには、パブリック/プライベート IP アドレス宛てに直接接続する以外にも、Cloud SQL Auth Proxy というプロキシソフトウェアを使う方法があります。

参考 : Cloud SQL Auth Proxy について

Cloud SQL Auth Proxy は、アプリケーションと同じサーバーで動作して、Cloud SQL への接続をプロキシ（中継）するソフトウェアです。

アプリケーション（データベースクライアント）から Cloud SQL Auth Proxy へは、ローカル通信（127.0.0.1 または localhost）で接続し、その後は Cloud SQL Auth Proxy から Cloud SQL へ TLS で通信します。

Cloud SQL Auth Proxy から Cloud SQL インスタンスへの通信は、TLS 1.3 で暗号化されます。

Cloud SQL Auth Proxy は、Linux、macOS、Windows 用のバイナリが用意されています。また Go のソースコードが公開されているため、他の OS 用にコンパイルして利用することも可能です。

Cloud SQL Auth Proxy による Cloud SQL への接続 (PostgreSQL の場合)

メリット

Cloud SQL Auth Proxy を使う利点は、以下のようなものがあります。

通信が TLS 暗号化される。データベース側の設定や SSL/TLS 証明書の管理は不要
パブリック IP アドレスを利用する場合でも「承認済みネットワーク」の追加が不要（接続元の認証は IAM）
IAM データベース認証が利用可能（IAM 権限でデータベースにログイン。ユーザー・パスワード不要）

3 つ目の IAM データベース認証については後述します。

接続の流れ

アプリケーションが Cloud SQL Auth Proxy を通じて Cloud SQL へ通信するフローは以下のとおりです。

アプリケーションからローカルマシン上の Cloud SQL Auth Proxy へ接続（通常のデータベースのプロトコル）
Cloud SQL Auth Proxy は Cloud SQLインスタンスへの既存コネクションがあるかチェックし、存在すればそれを使う
存在しない場合、 Cloud SQL Admin API へアクセスし一時的な SSL/TLS 証明書を取得
Cloud SQL Auth Proxy から Cloud SQL インスタンスへコネクション確立

上記の 3. では Cloud SQL Auth Proxy から sqladmin.googleapis.com へ 443/TCP で通信が発生します。このドメインの IP アドレスは固定ではないので、VPC ファイアウォールルール等でアプリケーションサーバーから 0.0.0.0/0 へのアウトバウンド通信を許可する必要があります。

また 4. では Cloud SQL Auth Proxy から Cloud SQL インスタンスへ 3307/TCP でアウトバウンド通信が発生します。やはり VPC ファイアウォールルール等で、Cloud SQL インスタンスの IP アドレスに対してアウトバウンド通信の許可が必要です。

以下は、psql コマンドから Cloud SQL Auth Proxy 経由で Cloud SQL に接続するときのコマンドライン例です。

psql "host=127.0.0.1 sslmode=disable dbname=DB_NAME user=USERNAME"

他の Cloud SQL コネクタ

Cloud SQL Auth Proxy の他にも、Cloud SQL への接続をプロキシする仕組みがあります。プログラムのランタイムに組み込むことのできる Cloud SQL 言語コネクタ（Cloud SQL Language Connectors）です。

参考 : Cloud SQL 言語コネクタの概要

2024年11月現在、Java、Python、Go、Node.js 用のコネクタが存在しており、これらの言語環境であれば、Cloud SQL Auth Proxy のように外部プロセスを稼働させることなく、通信の暗号化や IAM データベース認証のメリットを受けることが出来ます。

ライブラリとしてインポートして利用できるため、Cloud SQL Auth Proxy とは異なり実行環境に配置してプロセス起動する必要がありません。お使いのプログラミング言語が対応していれば、第1選択肢として有用です。

設定と接続の方法

Cloud SQL Auth Proxy を利用するには、アプリケーションやデータベースクライアントが稼働するローカルマシン上に Cloud SQL Auth Proxy をインストールします。

また Cloud SQL インスタンスへの接続元として承認されるために、IAM 権限が必要です。なおこの「接続元の承認」はデータベース（MySQL、PostgreSQL、SQL Server）のユーザー認証とは異なる概念であるという点に注意しましょう。日本語ドキュメントではどちらも「認証」とされているため紛らわしいのですが、当記事では「接続元の承認」という言葉と「（データベースの）（ユーザー）認証」という言葉で区別しています。前者の「承認」という言葉はパブリック IP アドレスの接続元アドレスを許可する際の「承認済みのネットワーク」と同じ意味合いです。

接続元の承認のための IAM 権限は、Google アカウントやサービスアカウント等に紐づきます。Cloud SQL Auth Proxy の実行環境が Compute Engine VM 等であれば、その VM インスタンス等にサービスアカウントをアタッチすることで、サービスアカウントが持つ IAM 権限で承認することが推奨されます。実行環境がオンプレミス等である場合は、サービスアカウントの認証情報キーを JSON ファイルとしてダウンロードして利用することになります。

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

参考 : Cloud SQL Auth Proxy を使用して接続する

認証・認可

データベースログインのための認証

Cloud SQL のデータベースにログインするための認証方法は、2通りあります。

ユーザー・パスワードによる認証
IAM による認証

前者は、通常の MySQL、PostgreSQL、SQL Server の組み込みのユーザー・パスワードを使ってログインする方法です。通常のデータベースと変わりありません。

後者は、Google Cloud の IAM の認証情報を使ってログインする方法です。また IAM による認証にも「手動」と「自動」の2種類があります。

データベースエンジンにより、利用可能な認証方法が異なります。以下の表は 2024年11月現在の対応状況です。

DB エンジン	ユーザー・パスワード認証	IAM 認証（手動）	IAM 認証（自動）
MySQL	◯	◯	◯
PostgreSQL	◯	◯	◯
SQL Server	◯	✕	✕

ユーザー・パスワードによる認証

通常の MySQL、PostgreSQL、SQL Server と同様に、ユーザー名とパスワードを使って認証します。mysql コマンドや psql クライアントなどを用いて、通常通りアクセスすることが可能です。

ユーザーの作成・管理は、原則的に通常の DB と同じ用に作成できます。また Google Cloud コンソール画面や gcloud コマンド等からもユーザー作成・削除やパスワードリセットが可能です。

インスタンス作成直後にはデフォルトユーザーアカウントが作成されており、初期パスワードの設定は Google Cloud コンソールから実施する必要があります。

Cloud SQL のデフォルトユーザーアカウント名は、MySQL では root、PostgreSQL では postgres、SQL Server では sqlserver です。

IAM による認証の概要

データベースに対して、Google Cloud の IAM の仕組みで認証できます。Cloud SQL インスタンスに対し、ユーザーアカウントまたはサービスアカウントが cloudsql.instances.login 権限を持っている必要があります。

この権限は、Cloud SQL 管理者（roles/cloudsql.admin）ロール、Cloud SQL インスタンスユーザー（roles/cloudsql.instanceUser）ロール等に含まれています。

このとき、Google Workspace や Cloud Identity の Google グループに権限を持たせることもできます。ユーザーアカウントやサービスアカウントを Google グループにまとめておき、グループにアクセス許可を与えることで、異動や退職の際の運用が効率化されます（以前はグループを紐づけることはできませんでしたが、2024年7月末のアップデートで可能になりました）。

IAM 認証のうち、「自動認証」では Cloud SQL Auth Proxy や各種コネクタが IAM 権限を使って認証情報の取得を認証を自動的に行ってくれます。「手動認証」ではアプリケーションのコードで明示的にアクセストークンを取得して、これを使って認証します。

参考 : IAM 認証

IAM による認証（自動）

IAM 自動認証を使うためには、データベースへの接続に通常の DB クライアントではなく前述の Cloud SQL Auth Proxy もしくは Cloud SQL 言語コネクタを利用します。

参考 : 自動 IAM データベース認証を使用してログインする

IAM による認証（手動）

手動認証は、自動認証とは異なり、プログラム内で明示的にアクセストークン（一時的な認証情報文字列。形式は OAuth 2.0 トークン）を Google API 経由で取得する必要があります。

ユーザーアカウント / サービスアカウントで gcloud コマンドを実行し Google Cloud へ認証
- ユーザーアカウントの場合 : gcloud auth login
- サービスアカウントの場合 : gcloud auth activate-service-account
コマンド gcloud sql generate-login-token でアクセストークンを取得
DB クライアントで DB へ接続
- ユーザー名 : ユーザーアカウント / サービスアカウントのメールアドレス
- パスワード : 取得したアクセストークン

以下は、コマンド例です。

gcloud auth login

PGPASSWORD=$(gcloud sql generate-login-token) psql --host=localhost 
                                                --username=hoge@example.com
                                                --dbname=mydatabase

参考 : 手動 IAM データベース認証を使用してログインする

メンテナンス

概要

Cloud SQL はマネージドサービスなので、物理基盤、OS、データベースエンジンは Google Cloud によって管理されます。

ただし、数か月に1度程度の頻度で、ダウンタイムを伴うメンテナンスが必要となります。メンテナンスには例として、Cloud SQL 自体の機能アップデート、データベースエンジンのマイナーバージョンアップデート、OS に対するパッチ適用などが含まれます。

参考 : Cloud SQL インスタンスでのメンテナンスについて

メンテナンスによる平均的なダウンタイムは30秒未満とされています（Enterprise エディションの PostgreSQL の場合）。また特定の条件を満たした Enterprise Plus エディションの場合、「ダウンタイムがほぼゼロの計画的メンテナンス（Near-zero downtime planned maintenance）」が適用され、この場合はダウンタイムが一般的に1秒未満とされています。

メンテナンスウインドウ、メンテナンスタイミング、拒否期間

メンテナンスを実施する時間を指定するため Cloud SQL インスタンスには メンテナンスウインドウ（メンテナンスの時間枠）を設定します。

メンテナンスウインドウには曜日と1日の中の1時間枠を設定できます。例えば「日曜日 01:00〜02:00」のように設定すると、メンテナンスが必要な際にこの時間枠の中でアップデートが実施されます。最もシステムの利用率が低い時間帯に設定するのが望ましいでしょう。

またメンテナンスタイミングという設定値により、メンテナンス通知から何週間のうちにメンテナンスが行われるかを制御することができます。Any、Week 1、Week 2、Week 5 の中から選択可能です。

さらに、システムの繁忙期等の理由で安定稼働が求められる場合はメンテナンス拒否期間を最長で90日間設定できます。これが設定されている期間はメンテナンスが行われません。

参考 : Maintenance settings

事前通知

Cloud SQL インスタンスのメンテナンス通知をメールで受け取れるように設定可能です。また、詳細は Google Cloud コンソールのインスタンス詳細ページ等から確認可能です。

通知後、どのくらいの期間のあとにメンテナンスが行われるかは、前述の「メンテナンスタイミング」設定値によります。

参考 : Opt in to maintenance notifications

メンテナンスの延期・即時適用

元々のメンテナンス予定日時から28日以内の範囲で、メンテナンスのスケジュールを変更することができます。スケジュールは「次回（1週間後）のメンテナンスウインドウ」あるいは「任意の日時」に変更可能です。

反対に、予告されているメンテナンスに対して即時実行を指示することもできます。

メンテナンスの仕組み

通常のメンテナンスの平均的なダウンタイムは30秒未満とされています。これはアップデートを短期間で終わらせる仕組みを Cloud SQL がバックエンドで実現しているからです。

ユーザー側からは特に意識する必要はありませんが、以下のようなプロセスでアップデートが行われることが明らかにされています。

アップデート適用済みの新規インスタンスがバックエンドで起動される
既存データベースを停止する
ディスクと IP アドレスを新規インスタンスに引き継ぐ
新規インスタンス側でデータベースを起動する

参考 : メンテナンスの仕組み

インプレースアップグレード

データベースのマイナーバージョンアップデート等は、前述のメンテナンスにより行われます。これとは別で、ユーザーが明示的に指示することによりメジャーバージョンのアップグレードも可能です。

既存の Cloud SQL インスタンスのデータベースのメジャーバージョンをアップグレードすることを、インプレースアップグレード（In-place Upgrade）と言います。

インプレースアップグレードでは既存インスタンスが直接アップグレードされるので、インスタンス名、 IP アドレス、データベースフラグ、データなどは引き継がれます。アップグレードにはダウンタイムが伴いますが、通常は10分以内に収まります。ただし所要時間はインスタンスの vCPU やメモリ量、データサイズに応じて変化します。またアップグレードの前後にバックアップが自動的に取得されます。

なおインプレースアップグレード以外には、新しいメジャーバージョンの新規インスタンスを構築して、データを移行するという方法があります。

実施の手順や対応しているバージョン等は DB エンジンによって異なります。詳細は以下のドキュメントをご参照ください。

参考 : データベースのメジャーバージョンをインプレースでアップグレードする

モニタリング・ロギング

Cloud Monitoring によるメトリクス収集

Cloud SQL の主要なパフォーマンスを測定する指標（メトリクス）は Cloud Monitoring の機能により自動的に収集されています。収集される指標は多岐にわたりますが、以下は代表的なものです。

CPU 使用率、メモリ使用量、ストレージ使用量
ディスク I/O
ネットワーク I/O
アクティブなコネクション数
秒間トランザクション数

Google Cloud コンソールには、これらの情報をわかりやすく可視化したシステム分析情報ダッシュボードの画面が閲覧できます。

参考 : システム分析情報を使用してシステムパフォーマンスを向上させる

また、取得可能な指標はデータベースエンジン（MySQL、PostgreSQL、SQL Server）によって異なります。指標の一覧は、以下のドキュメントをご参照ください。

参考 : Google Cloud metrics

Cloud Monitoring の詳細は、以下の記事もご参照ください。

blog.g-gen.co.jp

Query Insights

Query Insights 機能により、データベースに対するクエリのパフォーマンスを精査できます。Query Insights は、2024年11月現在、PostgreSQL と MySQL で利用できます。

Query Insights では以下のような事項が確認できます。

データベースの負荷状況
クエリごとの負荷状況
特に負荷が高いクエリの特定、実行計画・所要時間等の表示

Query Insights を利用するには、インスタンスごとに明示的に有効化する必要がありますが、料金は発生しません。有効化すると7日分の情報が保存されます。

参考 : Query Insights を使用してクエリのパフォーマンスを向上させる

また、アプリケーションで OR マッパー（ORM）を使っている場合、ソースコードに直接 SQL を記述しないため、負荷の大きいクエリを特定しづらいときがあります。そのような場合に sqlcommenter というオープンソースライブラリを使うことで、クエリにタグ付けし、Query Insights でクエリを特定しやすくすることができます。

参考 : ORM での sqlcommenter の使用

ロギング

Cloud SQL の各種ログは Cloud Logging に出力されます。Cloud Logging は Google Cloud のフルマネージドなログ管理サービスです。Cloud Logging では、Google Cloud コンソール画面からログを参照したり、BigQuery や Cloud Storage にログをエクスポートしたりできます。

例として PostgreSQL であれば、postgres.log ファイルの内容等が Cloud Logging に自動的に出力されます。

デフォルトでは、ログは Cloud Logging の _Default ログバケットに入り、30日間保存されます。この場合、料金は発生しません。これ以上の期間の保管が必要な場合、Cloud Logging で「シンク（ログルーター）」を作成して、より長期間のログバケットへログを格納します。

Cloud Logging の機能の詳細は以下の記事をご参照ください。

blog.g-gen.co.jp

監査

クラウドリソースとしての監査ログ

Cloud SQL のクラウドリソースとしての監査ログは、Cloud Audit Logs の機能を通じて Cloud Logging に出力されます。

参考 : 監査ログ

Cloud SQL に対する「インスタンスの作成、削除、設定変更、起動、停止」のような変更オペレーションは、デフォルトで自動的に記録されます。これらのログは、管理アクティビティ監査ログと呼ばれます。

一方で「インスタンス一覧の表示、設定情報の取得」のような閲覧系オペレーションや「Google Cloud コンソールや gcloud コマンドからのデータベースユーザーの作成」のようなオペレーションは、明示的に有効化する必要があります。これらのログは、データアクセス監査ログと呼ばれます。

これらの監査ログを記録する機能である Cloud Audit Logs の詳細は、以下の記事をご参照ください。

blog.g-gen.co.jp

データベースとしての監査ログ

データベース内のデータへのアクセス履歴やデータ変更の履歴等は、データベースエンジンごとの監査ログの仕組みで記録する必要があります。

例として PostgreSQL では pgAudit エクステンションを有効化して、ログを出力するよう明示的に設定することができます。データベースエンジンごとに、監査ログを有効化する方法は異なります。以下の公式ドキュメントをご参照ください。

暗号化

デフォルトの暗号化

Google Cloud では、すべてのデータは保存時に暗号化される仕様になっています。このデフォルトの暗号化の仕組みは、ストレージの透過的な暗号化であり、私たちユーザーには意識されません。このデフォルト暗号化が対抗できる脅威は「物理的な持ち去り」「データセンターの従業員による直接のアクセス」などです。

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

また同様に、VPC ネットワーク内を転送中のデータも自動的に暗号化されます。この暗号化が対抗できる脅威は「データセンター内での通信の盗聴」等です。

参考 : 転送データの暗号化

これらの暗号化は Cloud SQL でも適用されており、私たちユーザーが何もしなくても、保存時のデータは暗号化されていますし、通信が Google Cloud 内にとどまっている限り、通信も暗号化されます。

その他の暗号化

前述のように、Cloud SQL では何もしなくても、データが保存時や転送時に暗号化されています。ただし、「各種セキュリティ監査の対応」「パブリックインターネットでのデータ転送」「データセンターの内部犯行への対策を含むより強固なセキュリティが求められる」「クラウドリソースに対する追加のアクセス制御を施したい」などの理由がある場合、追加の選択肢もあります。

Cloud KMS に暗号鍵を登録することで、 Google が管理する鍵ではなくユーザーが管理する鍵でストレージを暗号化するよう指定できます。これを、顧客管理の暗号鍵（Customer-managed Encryption Keys、CMEK）による暗号化と呼びます。ほとんどのセキュリティ要件ではデフォルトの暗号化で十分ですが、監査上の目的や前述のような理由で自前での鍵管理が求められており、かつ自前での鍵管理が運用上可能である場合は、Cloud KMS を使った CMEK 暗号化を検討します。