マルチクラウド時代のAPI Gateway設計　~OCI API GatewayをAWSと徹底比較~

Last updated at 2026-07-27Posted at 2026-07-27

はじめに

マルチクラウドアーキテクチャが一般化した現在、APIエンドポイントを「どのクラウドに集約し、どう制御するか」は、システムの運用効率とコストを大きく左右します。

本記事では、OCIのAPI Gatewayを中心に、具体的な構築・設計のステップを解説します。あわせて、多くの技術者が使い慣れているAWSのAPI Gatewayとの違いを、エンジニア目線で比較します。

注意
本記事の料金・制限値・機能対応は執筆時点の情報に基づきます。

1. OCI API Gatewayのアーキテクチャと基本概念

OCI API Gatewayは、VCN内に配置されるフルマネージドかつサーバーレスなコンポーネントです。インターネットに公開するパブリックエンドポイントとしても、社内ネットワークやFastConnect内に閉じるプライベートエンドポイントとしても構成できます。

AWSとの最も大きな構造的な違いは、「VCNのサブネット内に直接配置される」 という点です。

Amazon API GatewayがAWS側の管理ネットワークに存在し、ユーザーVPCへの接続にVPCリンクやインターフェイスVPCエンドポイントを経由するのに対し、OCI API Gatewayは顧客のVCNサブネット内にプライベートIPを持って直接配置されます。

この構造により、バックエンドのリソースへのトラフィック制御を、セキュリティ・リストやネットワーク・セキュリティ・グループで直感的に行えます。

2. OCI API Gateway 構築・設計のステップ

OCI上にAPI Gatewayを設計・構築する際の重要なステップを解説します。

2.1 ネットワーク設計と前提条件

API Gatewayをデプロイする前に、以下のリソースを準備します。

VCNとサブネット：API Gateway専用、または既存のパブリック/プライベートサブネット
IAMポリシー：API Gatewayサービスがバックエンドを呼び出すためのリソース許可設定

以下は、API GatewayがOCI Functionsを呼び出すための標準的なポリシー例です。any-user を使う場合でも、必ずコンパートメントを明示し、request.principal.type で呼び出し元をAPI Gatewayに限定します。

Allow any-user to use functions-family in compartment <Functionsが配置されているコンパートメント名> where ALL {request.principal.type = 'ApiGateway', request.resource.compartment.id = '<API Gatewayのコンパートメント OCID>'}

セキュリティ上の注意
any-user を使う場合でも、where 句の条件（request.principal.type = 'ApiGateway'）とコンパートメント範囲の限定は必須です。条件を外すと意図しないプリンシパルに権限が広がるため、最小権限の原則を守ってください。本ポリシー例は執筆時点の公式ドキュメントに基づくものです。OCIのポリシー言語仕様は更新される可能性があるため、本番適用前に必ず最新の公式ドキュメントと照合してください。

2.2 デプロイメント仕様の記述

OCI API Gatewayのルーティングやポリシーは、コンソールではGUIで、CLI・Terraform・APIなどではJSON形式のデプロイメント仕様として定義します。

用語の注意
ここでいうJSONは、あくまでOCI API Gatewayの「デプロイメント仕様」のフォーマットを指します。バリデーション用の仕様記述言語である「JSON Schema」とは別物です。

以下は、HTTPバックエンドへのルーティング、ヘッダー変換を定義した概念的な構成例です。キー名や構造はバージョンにより変わる可能性があるため、実装前に必ず公式ドキュメントの最新スキーマを確認してください。

{
  "routes": [
    {
      "path": "/v1/users/{userId}",
      "methods": ["GET"],
      "backend": {
        "type": "HTTP_BACKEND",
        "url": "https://backend-service.internal/users/${request.path[userId]}",
        "connectTimeoutInSeconds": 10,
        "readTimeoutInSeconds": 30
      },
      "requestPolicies": {
        "headerTransformations": {
          "setHeaders": {
            "items": [
              {
                "name": "X-Gateway-Rendered",
                "values": ["true"]
              }
            ]
          }
        }
      }
    }
  ]
}

OCI JSON仕様の"ハマりどころ"

パスパラメータの変数参照：現行バージョンでは、ブラケット記法が採用されています。ただしバージョンにより記法が変わる可能性があるため、実装前に最新ドキュメントで確認してください。

ポリシーのネスト：ルート個別のポリシーは "policies" ではなく、"requestPolicies" の中にネストします。

ヘッダー値の指定：setHeaders の値は文字列ではなく、"values": ["..."] のように配列で指定します。

レート制限：レート制限ポリシーを使う場合は、利用しているAPIバージョンのスキーマを公式ドキュメントで確認してください。バージョンによって記述構造が異なります。

バックエンドURL：例ではHTTPSを使用しています。バックエンドへの通信は原則として暗号化を推奨します。

2.3 キャッシュに関する設計方針

Amazon API Gatewayがステージ単位の内蔵キャッシュを提供するのに対し、OCI API Gatewayには同等の内蔵レスポンスキャッシュ機能はありません。

そのため、OCIでレスポンスキャッシュを実現したい場合は、Redis / KeyDB等の外部キャッシュを別途構成するのが一般的です。たとえばCompute上にRedis/KeyDBクラスタを構築し、そのエンドポイントをバックエンドや前段のキャッシュ層として利用します。

この方式には、キャッシュサイズやエビクションポリシーをゲートウェイ側の制約に縛られず、インフラ要件に合わせて柔軟に設計できるというメリットがあります。一方で、キャッシュ層の運用・可用性・スケーリングを自前で担保する必要がある点はトレードオフです。

3. OCI vs AWS 詳細比較

インフラエンジニアが選定基準として重視する4つの軸で、両サービスを比較します。

3.1 機能・プロトコル対応

機能	OCI API Gateway	API Gateway Portals
ネイティブプロトコル	HTTP / REST	REST / HTTP / WebSocket
ポリシー定義	JSON仕様 / OpenAPIインポート	OpenAPI/ コンソール / 各種IaC
動的認可ロジック	カスタム認証	Lambdaオーソライザー
開発者ポータル	標準機能としてはなし	標準機能ではなく、別途実装が必要

考察
WebSocketによる双方向・リアルタイム通信が必要な場合は、ネイティブ対応するAWSに優位性があります。また、社内外へAPIを大規模公開し、開発者ポータル・利用申請・APIキー配布・利用状況可視化といったガバナンスを効かせたい場合、実はOCI・AWSいずれもAPI Gateway単体では標準搭載していないという点で立場は近く、別途構成が前提になります。AWSはエコシステムや実装事例が豊富な分、選択肢の幅という意味では扱いやすい場合があります。

3.2 料金モデル

マルチクラウド設計で最もインパクトが大きいのが、コスト構造の違いです。料金はAPI Gateway本体のリクエスト課金とデータ転送課金を分けて考える必要があります。

リクエスト課金

課金項目	OCI API Gateway	AWS REST API	AWS HTTP API
100万リクエスト	$3.00前後	$4.25前後	$1.29前後

データ転送・キャッシュ

課金項目	OCI API Gateway	AWS REST API	AWS HTTP API
データ転送	アウトバウンド転送に無料枠＋低単価が設定される傾向	別途データ転送課金	別途データ転送課金
内蔵キャッシュ	該当機能なし	ステージキャッシュあり	利用不可

コスト選定のヒント

アウトバウンドのデータ転送量が多いシステム一般にOCIはネットワーク転送料金が低く設定される傾向があり、動画・画像・大規模JSONペイロードを返すAPIではコスト優位になりやすいです。

リクエスト数が極めて多く、ルーティングが単純なシステム：AWSの軽量版「HTTP API」がリクエスト単価では最安の選択肢になりやすいです。

CloudFront併用時：配信先リージョンによって転送単価が変わります。グローバル配信と国内配信で単価が異なる点に注意してください。

3.3 パフォーマンスとスケーラビリティ

OCI
負荷状況に応じてバックエンドノードが透過的にスケールアウトする、堅実なアーキテクチャが特徴です。突発的なスパイクにも追従しますが、具体的なレイテンシは構成・リージョン・バックエンドに大きく依存するため、本番採用前に自環境での実測を推奨します。

AWS
大規模トラフィックまでスケールする実績を持ちます。技術的注意点として、コールドスタート遅延は、主にバックエンドのAWS Lambdaのランタイム初期化などに起因します。ただし、レイテンシは統合方式・認可・マッピング・ネットワーク経路によっても変動するため、すべてをLambda起因と捉えるのは正確ではありません。バックエンドがEC2やECS/ALBの場合、Lambdaコールドスタートに起因する遅延は発生しません。

3.4 セキュリティとWAF統合

OCI
OCI WAFは、API Gatewayの前段にOCI Load Balancerを配置し、そのLB/Edge側にWAFポリシーをアタッチする構成が一般的です。API Gatewayのデプロイメントへ直接アタッチする機能ではない点に留意してください。IaCでLB/WAF Edge・API Gatewayの両方を一元的に管理することは可能です。

AWS
- REST API：AWS WAFをAPI Gatewayへ直接アタッチできます。
- HTTP API：現時点では、AWS WAFを直接アタッチすることは対象外です。WAFを利用する場合は前段にAmazon CloudFrontを配置し、CloudFront側にAWS WAFをアタッチする構成を検討します。
- WebSocket API：HTTP APIと同様に標準では直接アタッチ非対応とされますが、情報源により記載に揺れがあるため、採用前に必ず最新のAWS公式ドキュメントで仕様を確認してください。WebSocketの場合、前段CloudFront構成にも制約があるため、設計時に要件と制約をあわせて確認する必要があります。

考察
OCI、AWS HTTP API/WebSocketはいずれも「前段レイヤーを介したWAF構成」が必要という点で構造が近く、直接アタッチが可能なのはAWS REST APIのみという整理になります。

4. マルチクラウド運用のベストプラクティス

4.1 TerraformによるIaC / GitOps管理

長期運用・複数環境を前提とする場合、API定義は手動ではなくIaCによるコード管理が推奨されます。

OCIでは、oci_apigateway_deploymentリソースのspecificationをHCLのネイティブなネストブロックとして記述してデプロイメント仕様を定義します。routes・request_policies・logging_policiesなどは、いずれもspecificationブロック内にさらにネストされたブロックとして記述します。これにより、インフラコードとルーティング定義をTerraformで一元管理できます。

resource "oci_apigateway_gateway" "api_gateway" {
  compartment_id = var.compartment_id
  display_name   = "production-gateway"
  endpoint_type  = "PUBLIC"
  subnet_id      = var.subnet_id
}

resource "oci_apigateway_deployment" "api_deployment" {
  compartment_id = var.compartment_id
  gateway_id     = oci_apigateway_gateway.api_gateway.id
  display_name   = "production-v1"
  path_prefix    = "/api"

  specification {
    routes {
      path    = "/users"
      methods = ["GET"]

      backend {
        type = "HTTP_BACKEND"
        url  = "https://${var.backend_host}/users"
      }
    }
  }
}

ポイント

specification はJSON文字列ではなく、HCLのネストブロックとして記述します。routesブロックの中に backendブロックやpath・methodsを直接定義する構造です（公式Terraform Providerドキュメント・サンプル（github.com/oracle/terraform-provider-oci/tree/master/examples/api_gateway）を参照）。

バックエンドURLはHTTPSを基本とし、IPアドレス直書きではなくロードバランサやサービス名を変数化して利用するのが望ましいです。

認証情報やエンドポイントはハードコードせず、変数やVault等のシークレット管理に外出ししてください。

本記事のサンプルは構文確認のための簡略版です。request_policies・logging_policies・認証・レート制限などを含む実際の構成では、フィールド名やネスト構造がバージョンにより変わる可能性があるため、実装前に必ず公式Provider最新ドキュメントを確認してください。

4.2 監視と可観測性の集約

マルチクラウド環境において、AWS CloudWatchとOCI Logging/Monitoringを個別に確認する運用は認知負荷を高めます。複数クラウド・複数アカウントを跨ぐ場合は、サードパーティ製プラットフォームへの一元集約により、運用チームの負荷を大きく下げられます。

① インフラログとメトリクスの一元集約

API Gateway Portalsは「Amazon CloudWatch」へ、OCI API Gatewayは「OCI Logging / Monitoring」へデータを出力します。

ここで重要なのは、OpenTelemetry CollectorはCloudWatchやOCI Loggingを直接Pullする仕組みではないという点です。基本は以下のいずれかの流れになります。

アプリやエージェントがOTLPでCollectorへPushする
CloudWatch Logs / OCI Loggingからログをエクスポートし、それを受けるパイプラインを構成する

CollectorのReceiverには、これらからエクスポート・送信されてくるデータを受けるプロトコルを設定し、必要に応じてパース・加工してバックエンドへExportします。

② 分散トレーシングの切り分け

インフラ層のログ集約だけでは、クラウドを跨いだ分散トレーシングは成立しません。

API Gateway層でトレースコンテキストを削除・上書きせずバックエンドへ透過させる設定を行う
- AWS / OCIともに、ヘッダーのパススルーやカスタムヘッダーの許可・転送設定が必要になるケースがあります
それを受けたアプリケーション自身がスパンを生成し、コレクターへ送信する

このように、Gatewayはコンテキスト透過、アプリはスパン生成と役割を分離して実装することがポイントです。

5. まとめ

現代のインフラ設計では、単一クラウドにすべてを集約する「1社1Gateway」の思想に縛られる必要はありません。データの局所性やネットワークコストを踏まえ、バックエンドリソースが配置されたリージョンの至近にそれぞれのAPI Gatewayを分散配置し、DNS層で大局的なトラフィック制御を行う——こうした マルチエッジ・アーキテクチャ こそが、エンタープライズインフラにおける最適解の一つと言えるでしょう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

マルチクラウド時代のAPI Gateway設計 ~OCI API GatewayをAWSと徹底比較~