0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

お題は不問！Qiita Tech Festa 2026で記事投稿！
Qiita Tech Festa20262026年7月13日まで開催中！
@hikaru0506(ひかる)Team Tea & Water

APIにおけるGoogle cloudとAWSの違い

0
Posted at

GCP の API 管理サービスを AWS API Gateway と比較してみた（API Gateway / Cloud Endpoints / Apigee 編）

GCP×AWS 比較シリーズ第4弾。今回は API の入り口（APIゲートウェイ／API管理） を扱う。

AWS では Amazon API Gateway がほぼ唯一の選択肢だが、GCP では 規模と目的に応じて3つのサービスに分かれている のがポイント。まずその全体像から入り、最後に「実際にどう使うか」をコマンドレベルで追う。

1. 全体像：GCP には3つの選択肢がある

AWS GCP ひとことで 想定規模
API Gateway（HTTP / REST API） API Gateway サーバーレス backend の前段に置く軽量ゲートウェイ（同名） 小〜中
API Gateway（の管理機能寄り） Cloud Endpoints OpenAPI/gRPC ベース。プロキシ（ESP）を挟むAPI管理 小〜中
API Gateway ＋ 本格運用 Apigee エンタープライズ API 管理。収益化・開発者ポータル・高度ポリシー 中〜大

迷ったらこれ：サーバーレス（Cloud Run / Cloud Functions）の前段なら GCP API Gateway。これが AWS API Gateway + Lambda の構成に一番近い。

2. 3サービスの違いを詳細比較

観点 GCP API Gateway GCP Cloud Endpoints GCP Apigee AWS API Gateway
位置づけ フルマネージドの軽量GW プロキシ(ESP)ベースのAPI管理 エンタープライズAPI管理 フルマネージドGW
定義方法 OpenAPI 2.0（Swagger） OpenAPI / gRPC UI / API でプロキシ設計 コンソール / OpenAPI / IaC
主な backend Cloud Run / Functions / App Engine GKE / Compute / Cloud Run 任意（GCP外も可） Lambda / HTTP / AWSサービス
認証 APIキー / JWT(Firebase,Auth0,SA等) APIキー / JWT / ESP認証 OAuth2 / APIキー / JWT / 独自 IAM / Cognito / Lambda Authorizer / APIキー
レート制限 あり（quota） あり（quota） 高度（spike arrest等） 使用量プラン+APIキー
変換・加工 最小限 最小限 強力（メディア変換/ポリシー連鎖） マッピングテンプレート
開発者ポータル なし なし あり なし（別途）
収益化 なし なし あり なし
料金感 安い（呼び出し課金） プロキシ実行分＋呼び出し 高い（エンタープライズ） 呼び出し課金
学習コスト 低 中 高 中

選び方フロー

  • API Gateway：とにかく手軽。サーバーレスAPIに認証・APIキー・レート制限を足したいだけ。
  • Cloud Endpoints：GKE/Compute上のサービスや gRPC を管理したい。ESP を backend に併走させる。
  • Apigee：社外公開・収益化・複雑なポリシー・開発者ポータルが必要な本格運用。

3. 基本的な使い方：GCP API Gateway（実践）

ここが本題。AWS API Gateway + Lambda に最も近い GCP API Gateway + Cloud Run の構成を、最小手順で通す。

3-0. 登場する3つのリソース

GCP API Gateway は3階層でできている。ここを理解すると一気に分かる。

リソース 役割 AWS で言うと
API APIの論理的な入れ物 API Gateway の「API」
API Config OpenAPI定義から作る設定（イミュータブル） 「ステージ/デプロイ」の元
Gateway 実際にURLを持つ稼働中のエンドポイント デプロイ済みステージ

流れ：OpenAPI定義 → API Config を作成 → Gateway にデプロイ → URLが払い出される。
Config はイミュータブル（作り直し）なので、更新時は新Configを作って Gateway を貼り替える。

3-1. 事前準備（APIの有効化）

gcloud config set project MY_PROJECT

gcloud services enable \
  apigateway.googleapis.com \
  servicemanagement.googleapis.com \
  servicecontrol.googleapis.com

3-2. OpenAPI 定義を書く（openapi.yaml）

GCP API Gateway は OpenAPI 2.0（Swagger） を使う。backend は x-google-backend 拡張で指定する。

swagger: "2.0"
info:
  title: my-api
  description: Sample API
  version: 1.0.0
schemes:
  - https
produces:
  - application/json
paths:
  /hello:
    get:
      summary: Greeting
      operationId: hello
      x-google-backend:
        address: https://my-service-xxxx-an.a.run.app   # Cloud Run のURL
      responses:
        "200":
          description: OK

3-3. API と API Config を作る

# (1) API を作成
gcloud api-gateway apis create my-api

# (2) OpenAPI から API Config を作成
gcloud api-gateway api-configs create my-config \
  --api=my-api \
  --openapi-spec=openapi.yaml \
  --backend-auth-service-account=SA_EMAIL   # backend呼び出し用のSA（必要に応じ）

3-4. Gateway をデプロイ（URLが払い出される）

gcloud api-gateway gateways create my-gateway \
  --api=my-api \
  --api-config=my-config \
  --location=asia-northeast1

# 払い出されたURLを確認
gcloud api-gateway gateways describe my-gateway \
  --location=asia-northeast1 \
  --format="value(defaultHostname)"
# => my-gateway-xxxx.an.gateway.dev

# 動作確認
curl https://my-gateway-xxxx.an.gateway.dev/hello

3-5. 設定を更新したいとき

Config はイミュータブルなので 新Configを作って貼り替える。

gcloud api-gateway api-configs create my-config-v2 \
  --api=my-api --openapi-spec=openapi.yaml

gcloud api-gateway gateways update my-gateway \
  --api=my-api --api-config=my-config-v2 \
  --location=asia-northeast1

AWS で言う「新しいデプロイを作ってステージに紐づけ直す」操作に相当。

4. 認証の付け方（GCP API Gateway）

4-1. API キー

OpenAPI に security を足してキー必須にする。

securityDefinitions:
  api_key:
    type: apiKey
    name: key
    in: query
security:
  - api_key: []

# キーは Credentials から発行し、API Gateway向けに制限をかける
# 呼び出し時
curl "https://.../hello?key=YOUR_API_KEY"
AWS GCP
APIキー発行 API Gateway の「APIキー＋使用量プラン」 Credentials（API key） を発行し利用制限
必須化 メソッドで API Key Required OpenAPI の security

4-2. JWT（IDトークン）認証

x-google-issuer / x-google-jwks_uri などで発行元を指定（Firebase Auth / Auth0 / Google SA など）。

securityDefinitions:
  firebase:
    authorizationUrl: ""
    flow: implicit
    type: oauth2
    x-google-issuer: https://securetoken.google.com/MY_PROJECT
    x-google-jwks_uri: https://www.googleapis.com/.../securetoken@system.gserviceaccount.com
    x-google-audiences: MY_PROJECT
security:
  - firebase: []
認証方式 AWS GCP API Gateway
IAM署名 IAM authorizer（SigV4） （無し。代わりにSA+JWT）
トークン検証 Cognito / JWT authorizer x-google-issuer 系で JWT 検証
自前ロジック Lambda Authorizer （無し。backend側 or Apigeeで）

AWS の Lambda Authorizer のような「任意コードでの認可」は GCP API Gateway 単体には無い。必要なら Apigee か backend 実装で対応。

5. レート制限・クォータ

# OpenAPI に quota を定義（メトリック＋上限）
x-google-management:
  metrics:
    - name: requests
      valueType: INT64
      metricKind: DELTA
  quota:
    limits:
      - name: request-limit
        metric: requests
        unit: "1/min/{project}"
        values:
          STANDARD: 1000
AWS GCP
単位 使用量プラン（rate / burst / quota） OpenAPI の quota 定義
キー単位の制限 APIキー×使用量プラン APIキー（コンシューマ）単位
高度な制御 （限定的） Apigee なら spike arrest 等が豊富

6. Cloud Endpoints の使い方（概要）

backend に ESP（Extensible Service Proxy）/ESPv2 を併走させて管理機能を足す方式。GKE や Compute、gRPC API に向く。

# OpenAPI定義をデプロイ（サービス構成として登録）
gcloud endpoints services deploy openapi.yaml

# backend(GKE/Compute)に ESPv2 コンテナをサイドカー的に配置し、
# --service と --rollout_strategy=managed を渡して起動する
  • 特徴：backend のすぐ前に自分でプロキシを置くので、gRPC や非サーバーレス環境に強い。
  • API Gateway との違い：API Gateway はプロキシをGoogleがフルマネージドで持つ。Endpoints は 自分で ESP を動かす（その分柔軟）。

7. Apigee の使い方（概要）

フル API 管理プラットフォーム。CLI で雑に立てるものではなく、API プロキシという単位を設計する。

  • API プロキシ：受け口(ProxyEndpoint)と backend(TargetEndpoint)の間に ポリシー連鎖（認証・変換・レート制限・キャッシュ・ログ）を差し込む。
  • 開発者ポータル：外部開発者向けにAPIドキュメント/キー発行を提供。
  • 収益化（Monetization）：API利用に課金プランを設定。
  • AWS で近いことをやるなら「API Gateway + Cognito + WAF + 使用量プラン + 自前ポータル」を全部まとめたイメージ。

学習コスト・コストともに高いので、社外公開・収益化・統制が要件になって初めて検討するのが現実的。

8. まとめ

観点 AWS API Gateway GCP の対応
基本の対応 API Gateway API Gateway（同名・最も近い）
定義 OpenAPI / コンソール / IaC OpenAPI 2.0（x-google-backendで接続）
デプロイ単位 API → ステージ API → API Config（不変）→ Gateway
サーバーレス連携 Lambda Cloud Run / Cloud Functions
認証 IAM / Cognito / Lambda Authorizer APIキー / JWT（issuer指定）。自前認可は無い
本格管理 （API Gateway + 周辺サービス） Apigee
非サーバーレス/gRPC （HTTP統合） Cloud Endpoints（ESP併走）

3行まとめ

  1. AWS API Gateway ≒ GCP API Gateway（同名）。サーバーレスの前段はこれ。
  2. 構成は API → Config（不変）→ Gateway の3階層。更新はConfigを作り直して貼り替え。
  3. 高度な管理は Apigee、gRPC/非サーバーレスは Cloud Endpoints と使い分ける。

関連記事：

  • [GCP のリソース階層を AWS と比較する（Organization / Folder / Project 編）]
  • [GCP と AWS で比較する IAM とポリシー継承の仕組み]
  • [GCP CLI を AWS CLI と比較する（gcloud / gsutil / bq 編）]
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?