トップ > Cloud FTP > Cloud FTPを徹底解説！

Cloud FTPを徹底解説！

Cloud FTP Google Cloud 徹底解説シリーズ
記事タイトルとURLをコピーする

G-gen の杉村です。Google Cloud のフルマネージドな SFTP サーバーサービスである Cloud FTP について、特徴やアーキテクチャ、接続方法、セキュリティ設定などを解説します。

Cloud FTP とは

概要

Cloud FTP は、Google Cloud が提供するフルマネージドな SFTP（SSH File Transfer Protocol）サーバーサービスです。

当サービスを使うと、SFTP プロトコルを経由して、Google Cloud のオブジェクトストレージである Cloud Storage バケットに対してファイルをアップロードしたり、ダウンロードしたりできます。SFTP は、その経路が SSH によって暗号化されているプロトコルであるため、セキュアにファイルのやりとりが可能です。

クライアント側は、Cyberduck や FileZilla、WinSCP などの一般的な GUI クライアントや、Linux や macOS の標準的な sftp コマンドラインツールを使用して、従来の SFTP サーバーと同様の操作感で Cloud Storage を使用できます。

クライアントとサーバー間の認証は、公開鍵認証方式によって行われます。パスワード認証には対応していません。

アーキテクチャのイメージ

制限

Cloud FTP は、限られたリージョンでのみ使用できます。2026年8月末現在、東京（asia-northeast1）リージョンや大阪（asia-northeast2）リージョンには Cloud FTP サーバーを作成できません。

ただし、Cloud FTP サーバーと Cloud Storage バケットのリージョンが一致している必要はありません。例えば、Cloud FTP サーバーを asia-northeast3（ソウル）リージョンに作成し、バックエンドの Cloud Storage バケットは東京（asia-northeast1）リージョンを指定する、といった設定が可能です。このようにすれば、データ転送速度やリージョン間転送コストの観点ではデメリットがあるものの、日本国内のユーザーが当サービスを使用できないわけではありません。

ユースケース

Cloud FTP は、以下のようなユースケースに適しています。

オンプレミスやレガシーシステムからのデータ転送
クラウドネイティブな API や SDK への移行が困難な既存バッチ処理・基幹システムから、従来の SFTP 手順を変更せずにデータを Google Cloud へ集約する。仮想サーバーに SFTP サーバーを構築したり、運用したりする必要はない。

社外とのファイル連携
Google Cloud アカウントを持たない外部ベンダーや取引先に対して、セキュアな SFTP インターフェースを提供し、指定した Cloud Storage バケットのみへのアクセスを許可する。

データ分析基盤のデータ受領
外部から SFTP 経由で受け取った CSV やログファイルを Cloud Storage に配置し、BigQuery などの分析基盤や Cloud Run functions 等によるイベント駆動処理へと連携する。

メリット

Cloud FTP は、VM 等に通常の SFTP サーバーを構築することに比べて、以下のようなメリットがあります。

運用負荷の削減
Cloud FTP はフルマネージドサービスであるため、OS や SFTP ソフトウェアの構築、セキュリティパッチ適用、スケーリング、可用性維持などの管理は不要です。

Cloud Storage の耐久性と拡張性
バックエンドストレージが Cloud Storage であるため、高い耐久性と容量制限を意識しないスケーラビリティをそのまま享受できます。

Google Cloud セキュリティとの統合
接続元の IP アドレス制限や公開鍵認証に加え、IAM とサービスアカウントによるきめ細かなアクセス制御、VPC Service Controls によるデータ境界、Cloud Audit Logs による監査ログ取得が可能です。

料金

Cloud FTP は、サーバーの稼働時間と、転送データ量（アップロード / ダウンロード）に応じた従量課金です。

サーバー稼働時間については、1時間あたり $0.30 です。サーバーを停止している間は、課金されません。

転送データ量については、アップロード / ダウンロードともに、$0.04/GB です。

これらに加えて、通常の Cloud Storage 料金（データ保管料金やリクエストあたりの料金等）、またデータ転送料金など、関連サービスへの課金が発生します。

アーキテクチャ

外部サーバーと内部サーバー

Cloud FTP では、用途とネットワーク要件に応じて2種類のサーバータイプから選択してプロビジョニングします。なお、一度サーバーを作成した後にアクセスタイプ（External / Internal）を変更することはできません。

項目 外部サーバー（External） 内部サーバー（Internal）
アクセス経路 インターネット経由 VPC ネットワーク内経由（Private Service Connect、略称 PSC）
エンドポイント パブリック IP アドレス PSC サービスアタッチメント（Service Attachment）
ネットワーク制御 接続元 CIDR ブロック（最大500個） 許可プロジェクトリスト（最大500個）/ 拒否プロジェクトリスト（最大64個）
主な用途 外部取引先やインターネット越しのファイル送受信 社内システム、VPC 内の VM、オンプレミス（Cloud Interconnect / VPN 経由）

外部サーバーには、パブリック IP アドレスが割り当てられ、接続元 IP アドレス範囲を CIDR ブロックで登録してアクセスを制限します。0.0.0.0/0 を指定して全ての接続元からのアクセスを許可することも可能です。

内部サーバーでは、Private Service Connect（PSC）のサービスアタッチメントが作成されます。コンシューマ VPC （アクセス元の VPC）側に PSC エンドポイントを作成することで、インターネットを経由せずプライベート IP アドレス経由で SFTP 接続を行います。これにより、専用線や VPN を経由してオンプレミスのクライアントから接続したり、あるいは VPC ネットワーク内の VM からアクセスできます。

ユーザー管理と認証・認可

Cloud FTP は、SFTP ユーザーの認証に SSH 公開鍵暗号方式 を使用します。パスワード認証には対応していません。

認可（権限管理）は、Google Cloud の IAM の仕組みによって行われ、ユーザーをサービスアカウントとマッピングすることで実現されます。

  1. SFTP クライアントが SSH 秘密鍵を使用して Cloud FTP サーバーに接続
  2. Cloud FTP サーバーが、登録された SSH 公開鍵でユーザーを認証
  3. Cloud FTP サービスエージェントが、対象ユーザーに紐付けられたユーザー専用サービスアカウントの短期アクセストークンを生成（権限借用）
  4. 生成されたトークンを用いて、Cloud Storage バケットに対する読み取りや書き込み操作を実行

この仕組みにより、SFTP ユーザーごとに操作可能な Cloud Storage バケットやフォルダ、権限（読み取り専用 / 読み書き）を IAM によって厳密に制御できます。

ディレクトリマッピング

Cloud FTP では、SFTP ユーザーがログインした際に見えるディレクトリ構造（論理ディレクトリ）と、実際の Cloud Storage バケット（およびフォルダプレフィックス）をマッピングします。

ディレクトリマッピングには以下の仕様・制限事項があります。

制限の概要 説明
バケット数の上限 1ユーザーにつき最大10個のバケットをマッピング可能
公開鍵数の上限 1ユーザーにつき最大10個の SSH 公開鍵を登録可能
フラットな論理ディレクトリ構造 ネストされた論理ディレクトリはサポートされない。例えば /dir1 と /dir2 を並列にマッピングすることは可能だが /dir1 と /dir1/dir2 のような階層構造を定義することはできない
アクセス権限の指定 マッピングごとに READ_ONLY（読み取り専用）または READ_WRITE（読み書き可能）のパーミッションを指定可能

サポートされる SFTP 操作

サポートされるコマンド一覧

Cloud FTP では、標準的な SFTP コマンドおよびファイル操作がサポートされています。

コマンド 説明 備考
ls カレントディレクトリ内のファイル一覧表示 -1, -a, -f, -h, -l, -r, -S, -t フラグをサポート
cd ディレクトリの移動 マッピングされた論理ディレクトリ間を移動
pwd カレントのリモート作業ディレクトリを表示 -
get ファイルのダウンロード -R フラグによるフォルダの再帰的ダウンロードに対応
put ファイルのアップロード -R フラグによるフォルダの再帰的アップロードに対応。既存ファイルは上書き
mkdir ディレクトリの作成 Cloud Storage 上ではプレフィックス/空フォルダオブジェクトとして扱われる
rm ファイルの削除 Cloud Storage 上のオブジェクトを削除
rmdir ディレクトリの削除 ディレクトリ内の全ファイルを削除した後に実行可能
rename ファイル名またはフォルダ名の変更 フォルダ名変更は階層型名前空間（Hierarchical Namespace）有効バケットのみ対応
progress 転送進行状況メーターの表示切り替え -
version SFTP プロトコルバージョンの表示 -
bye / exit / quit SFTP セッションの終了 -

注意点

Cloud FTP でファイルやディレクトリを操作する際は、以下の仕様に留意する必要があります。

概要 説明
フォルダのリネーム バックエンドがオブジェクトストレージのため、通常のバケットではフォルダのリネーム（rename）はサポートされない。フォルダのリネームを行いたい場合は、階層型名前空間（Hierarchical Namespace）を有効化した Cloud Storage バケットを使用する必要がある
ディレクトリの削除 rmdir コマンドでディレクトリを削除する場合、ディレクトリ配下にオブジェクトが存在しない状態（空の状態）にしてから削除する必要がある
ファイルの自動上書き put コマンドで同名ファイルをアップロードした場合、確認なしに既存の Cloud Storage オブジェクトが上書きされる

監査ログ

概要

Cloud FTP の管理操作およびデータアクセス操作は、Cloud Audit Logs の仕組みを使って記録され、Cloud Logging に出力されます。

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

blog.g-gen.co.jp

Cloud FTP 関連の監査ログとしては「管理アクティビティ監査ログ」「データアクセス監査ログ」の2種類が出力されます。

管理アクティビティログ

サーバーやユーザーの管理における更新系の操作は、Cloud FTP の管理アクティビティ監査ログとして記録されます。管理アクティビティ監査ログは、プロジェクトでデフォルトで有効化されています。

具体的には、以下のようなアクションが記録されます。

  • サーバーやユーザーの作成（CreateServer, CreateUser）
  • サーバーやユーザーの削除（DeleteServer, DeleteUser）
  • サーバーの開始・停止（StartServer, StopServer）
  • サーバーの設定更新（UpdateServer, UpdateUser）

Cloud Logging のログエクスプローラで以下のクエリを実行することで、Cloud FTP の管理アクティビティ監査ログを抽出できます。my-project はプレイスホルダーであるため、置換してください。

protoPayload.serviceName="ftp.googleapis.com"
AND logName="projects/my-project/logs/cloudaudit.googleapis.com%2Factivity"

データアクセス監査ログ

前述のとおり、SFTP 経由で行われた Cloud Storage に対するファイル送受信操作は、Cloud Storage 側のデータアクセス監査ログ（storage.googleapis.com）として記録されます。Cloud Logging のログエクスプローラのクエリは以下のとおりです。

protoPayload.serviceName="storage.googleapis.com"
AND logName="projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access"

また、サーバーやユーザーの参照操作（GetServer, GetUser, ListServers, ListUsers）は、Cloud FTP 側のデータアクセス監査ログ（ftp.googleapis.com）として記録されます。Cloud Logging のログエクスプローラのクエリは以下のとおりです。

protoPayload.serviceName="ftp.googleapis.com"
AND logName="projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access"

データアクセス監査ログは、デフォルトではプロジェクトで無効化されています。プロジェクト全体、またはサービスごとのデータアクセス監査ログを、明示的に有効化する必要があります。

VPC Service Controls との統合

概要

Cloud FTP は、機密データの流出を防止する VPC Service Controls に対応しています。VPC Service Controls の詳細については、以下の記事を参照してください。

blog.g-gen.co.jp

Cloud Storage バケットを保護するサービス境界内に Cloud FTP を統合する場合、以下の構成を行います。

  1. 保護対象プロジェクトの追加: Cloud Storage バケットを含むプロジェクト、および SFTP サーバーを含むプロジェクトを同一サービス境界に追加します（別境界の場合は境界ブリッジを構成）。
  2. 制限対象サービスの追加: ftp.googleapis.com および storage.googleapis.com を制限対象サービスに指定します。
  3. アクセスレベルの定義: 接続を許可する SFTP クライアントの IP アドレス / CIDR ブロックをアクセスレベルとして定義します。
  4. 内向きルールの設定:
    • 送信元（From）: 作成したアクセスレベル、およびユーザーのサービスアカウント
    • 送信先（To）: 対象プロジェクト、サービス ftp.googleapis.com

上記は設定手順の概要です。詳細は以下のドキュメントを参照してください。

注意点

コンテキスト情報は使用不可
SFTP / SSH セッションにはデバイスポスチャーメタデータ（Chrome Enterprise Premium 等のデバイス健全性に関する属性）が付与されないため、内向きルールの評価に使えるのは、IP アドレスおよび ID 条件のみです。

内部サーバーにおける注意点
内部サーバーの場合、VPC Service Controls の境界の設定の適用はサーバー作成時にのみ行われます。内部サーバー作成後にサービス境界の設定（メンバープロジェクトの変更や内向きルールの変更など）を更新しても、そのルールは適用されません。変更後のルールを適用するには、内部サーバーを再作成する必要があります。

運用上の考慮事項

クライアントの自動再試行
Cloud FTP はフルマネージドですので、定期的にインフラの自動メンテナンスやパッチ適用が行われます。その際、一時的なセッション切断が発生する可能性があります。クライアント側で自動再試行を有効にしておくことが推奨されます。

Cloud Asset Inventory 未対応
2026年8月現在、Cloud FTP リソースは Cloud Asset Inventory によるアセット追跡・検索に対応していません。

1ユーザーあたりのリソース上限
1ユーザーにマッピング可能な Cloud Storage バケット数は最大10個、登録可能な SSH 公開鍵は最大10個です。

サーバー作成時間
サーバーのプロビジョニングには約10分を要します。CI/CD パイプライン等で動的に作成・破棄する運用を検討する場合は、この所要時間を織り込む必要があります。

サーバー停止によるコスト削減（Start / Stop）
データ転送が行われない夜間や休日、あるいはバッチ処理時間外などにサーバーを一時停止（Stop）することで、サーバーの稼働コストを削減できます。サーバーを停止すると、アクティブな接続は切断され、新規接続は拒否されます。データ送受信を再開したい時は、サーバーを開始（Start）します。

構築手順

必要な IAM ロール

Cloud FTP のサーバーおよびユーザーの構築・管理を行う管理者は、以下の IAM ロールを保持している必要があります。

  • プロジェクトに対する、Cloud FTP 管理者（roles/ftp.admin）
  • ユーザーごとのサービスアカウントに対する、サービス アカウント ユーザー（roles/iam.serviceAccountUser）
  • 対象バケットに対する、Storage バケット閲覧者（roles/storage.bucketViewer）
  • 対象バケットに対する、Storage オブジェクト閲覧者（roles/storage.objectViewer）

なおプロジェクトレベルでオーナー（roles/owner）や編集者（roles/editor）を持っていれば、これらの権限はすべて内包されています。

API の有効化

Cloud FTP を使用するには、まず対象の Google Cloud プロジェクトで Cloud FTP API を有効化します。

gcloud services enable ftp.googleapis.com

SFTP サーバーの作成

サーバーを作成するには、gcloud alpha storage ftp servers create コマンドを実行します。サーバーのプロビジョニングには約10分かかります。

外部サーバー（External）の場合

外部サーバーを作成する場合は、--access-type=EXTERNAL と --allowed-cidr-blocks を指定します。

gcloud alpha storage ftp servers create my-external-server \
    --access-type=EXTERNAL \
    --location=asia-northeast3 \
    --allowed-cidr-blocks=203.0.113.0/24,198.51.100.50/32
  • --location : サーバーを配置する Google Cloud リージョンを指定します。データ転送速度を最適化するため、マッピング先 Cloud Storage バケットと同一リージョン（または最も近いリージョン）を選択することが推奨されます。
  • --allowed-cidr-blocks : 接続を許可するクライアントの IP アドレス範囲をカンマ区切りで指定します（最大500個）。

--location オプションには Cloud FTP がサポートするリージョンを指定する必要がありますが、バックエンドの Cloud Storage バケットと異なるリージョンを指定しても構いません。2026年8月末現在、日本国内リージョンはサポートされていませんので、バケットが日本国内リージョンの場合は、地理的に近い asia-northeast3（ソウル）リージョン等が推奨されます。

内部サーバー（Internal）の場合

内部サーバーを作成する場合は、--access-type=INTERNAL と --consumer-accept-list を指定します。

gcloud alpha storage ftp servers create my-internal-server \
    --access-type=INTERNAL \
    --location=asia-northeast3 \
    --consumer-accept-list=my-consumer-project-id=10 \
    --consumer-reject-list=rejected-project-id
  • --consumer-accept-list : Private Service Connect 経由で接続を許可するコンシューマプロジェクト ID（またはプロジェクト番号）と、作成可能なエンドポイント数の上限値（1〜250）を PROJECT_ID=LIMIT 形式で指定します（カンマ区切りで最大500プロジェクト）。
  • --consumer-reject-list : 接続を明示的に拒否するプロジェクトを指定します（任意、最大64プロジェクト）。

ユーザー用サービスアカウントの作成

クライアントとして接続する SFTP ユーザーを作成します。

SFTP ユーザーが Cloud Storage にアクセスするための専用サービスアカウントを作成します。ユーザーごとに個別のサービスアカウントを作成することが推奨されています。

gcloud iam service-accounts create sftp-user01-sa \
    --description="Service Account for SFTP user01" \
    --display-name="sftp-user01-sa"

上記のコマンドの sftp-user01 は例です。ユーザーの判別ができる名称とすることが推奨されます。

次に、SFTP ユーザーを作成する管理者自身に、先ほど作成したサービスアカウントに対する roles/iam.serviceAccountUser ロールを付与します。

gcloud iam service-accounts add-iam-policy-binding sftp-user01-sa@my-project.iam.gserviceaccount.com \
    --member="user:admin@example.com" \
    --role="roles/iam.serviceAccountUser"

ユーザー用サービスアカウントへの権限付与

ユーザー用サービスアカウントに対して、対象の Cloud Storage バケットへのアクセス権を付与します。

読み取り専用アクセスの場合は、Storage オブジェクト閲覧者（roles/storage.objectViewer）を付与します。

読み取りと書き込みができるアクセスの場合は、Storage オブジェクト管理者（roles/storage.objectAdmin）を付与します。

gcloud storage buckets add-iam-policy-binding gs://my-data-bucket \
    --member="serviceAccount:sftp-user01-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectAdmin"

サービスエージェントへのトークン作成者ロール付与

Cloud FTP のサービスエージェントが、ユーザー用サービスアカウントのトークンを生成できるように、サービス アカウント トークン作成者（roles/iam.serviceAccountTokenCreator）ロールを付与します。

なお、サービスエージェントについては、以下の記事を参照してください。

blog.g-gen.co.jp

まずは必要な前提情報を得るために、サーバーの詳細情報を取得してサービスエージェントのメールアドレスを確認します。

gcloud alpha storage ftp servers describe my-external-server \
    --location=asia-northeast3

出力結果に含まれる serviceAgentEmail（例: p-1234567890-98765432109@gcp-sa-ftp.iam.gserviceaccount.com）に対してロールを付与します。

gcloud iam service-accounts add-iam-policy-binding sftp-user01-sa@my-project.iam.gserviceaccount.com \
    --member="serviceAccount:p-1234567890-98765432109@gcp-sa-ftp.iam.gserviceaccount.com" \
    --role="roles/iam.serviceAccountTokenCreator"

SFTP ユーザーの作成

認証情報ファイル（JSON）の準備

ユーザーの SSH 公開鍵（OpenSSH 形式）を記載した JSON ファイル（credentials.json）を作成します。

[
  {
    "credentialName": "user01-key",
    "credentialType": "PUBLIC_KEY",
    "sshPublicKeyBody": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQD..."
  }
]

SFTP ユーザーの作成

gcloud alpha storage ftp users create コマンドを実行して、ユーザーを作成し、ディレクトリマッピングを定義します。

gcloud alpha storage ftp users create user01 \
    --server=my-external-server \
    --location=asia-northeast3 \
    --customer-service-account=sftp-user01-sa@my-project.iam.gserviceaccount.com \
    --storage-directory-mapping=bucket=my-data-bucket,bucket_prefix=uploads,directory=/uploads,permission=READ_WRITE \
    --user-credentials-from-file=credentials.json
  • --storage-directory-mapping :
    • bucket : 対象の Cloud Storage バケット名（gs:// は不要）。
    • bucket_prefix : バケット内のフォルダパス（任意。省略時はバケットのルート）。
    • directory : SFTP ユーザーに見える論理パス（例 : /uploads）。
    • permission : READ_ONLY または READ_WRITE。
    • 複数バケットをマッピングする場合は、このフラグを複数回指定します。

PSC エンドポイントの作成（内部サーバーのみ）

以下の手順は、内部サーバーの構築時のみ必要です。コンシューマ VPC（接続元の VPC ネットワーク）内に Private Service Connect（PSC）エンドポイントを作成します。

1. サービスアタッチメント URI の取得

内部サーバーの詳細情報から serviceAttachment の URI を確認します。

gcloud alpha storage ftp servers describe my-internal-server \
    --location=asia-northeast3

URI の形式は projects/${SERVICE_PROJECT_ID}/regions/${REGION}/serviceAttachments/${SERVICE_NAME} のようになります。

2. Private Service Connect エンドポイントの作成

コンシューマ VPC 内で、転送ルール（フォワーディングルール）を作成して PSC エンドポイントを作成します。

  • ターゲット: 公開サービス（Published service）
  • ターゲットサービス: 取得したサービスアタッチメント URI
  • ネットワーク/サブネットワーク: クライアント VM が存在する VPC およびサブネット
  • IP アドレス : エンドポイント用のプライベート IP アドレス

なお、クライアント VM がサービスアタッチメントと異なるリージョンに存在する場合は、PSC エンドポイントの作成時にグローバルアクセス（Global access）を有効にする必要があります。

接続手順

SFTP サーバーの IP アドレスは gcloud alpha storage ftp servers describe コマンドで確認できます。

gcloud alpha storage ftp servers describe my-external-server \
    --location=asia-northeast3

OpenSSH（sftp コマンド）の場合、ターミナルから SSH 秘密鍵を指定して接続します。

sftp -i ~/.ssh/sftp_user_key user01@34.22.xx.xx

また GUI クライアントの場合は、クライアントソフトに応じて適切に設定値を入力します。一例として、WinSCP での接続時の設定例を示します。

  • 転送プロトコル : SFTP
  • ホスト名 : サーバーの IP アドレス
  • ポート番号 : 22
  • ユーザー名 : user01
  • 設定 > SSH > 認証 > 「秘密鍵ファイル」で秘密鍵を指定

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

杉村 勇馬 (記事一覧)

執行役員 CTO

元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。