Azure API Management

解決する課題

• API 用のゲートウェイを自前で運用したくない（認証・レート制限・変換を共通の玄関で）
• バックエンド（Functions / App Service / AKS など）を安全に公開し、直接アクセスを遮断したい
• 社内外の利用者へ API をパッケージ化（製品）して配布し、サブスクリプションキーで利用を管理したい
• 既存の SOAP / REST / GraphQL / WebSocket を統一されたファサードの裏に隠し、後からバックエンドを差し替えたい
• API のドキュメント・試用環境（開発者ポータル） を自動で提供したい

主要概念と用語

• API / オペレーション: 公開する API と、その中の個々のエンドポイント（メソッド + URL テンプレート）
• 製品（プロダクト）: 1 つ以上の API を束ねた公開単位。公開/非公開、サブスクリプション要否、レート制限・クォータを製品単位で設定
• サブスクリプション / サブスクリプションキー: 利用者ごとのアクセスキー。既定では Ocp-Apim-Subscription-Key ヘッダ（またはクエリ）で送る。AWS の API キー + 使用量プランに相当
• ポリシー（Policies）: ゲートウェイの中核。リクエスト/レスポンスに対し XML で記述する処理パイプライン（inbound / backend / outbound / on-error）。認証・レート制限・変換・キャッシュ・モック・ヘッダ操作などを宣言的に適用
• バックエンド / API バックエンド: 転送先。backend エンティティで資格情報や回路ブレーカーをまとめて管理できる
• 開発者ポータル: API カタログ・ドキュメント・対話的な試用（Try it）・サブスクリプション申請を提供する自動生成サイト（カスタマイズ可）
• 名前付き値（Named values）: ポリシーで使う設定値/シークレットの集中管理。Key Vault 参照が可能
• ゲートウェイ（マネージド / セルフホスト）: 既定はマネージドゲートウェイ。セルフホストゲートウェイは同じゲートウェイをコンテナとしてオンプレ/他クラウド/エッジで実行できる（ハイブリッド/マルチクラウド向け）
• API バージョン / リビジョン: 破壊的変更を扱うバージョンと、無停止で差し替えるリビジョン

仕様・制限・クォータ

• SKU（レベル） で機能・SLA・スケール方式が異なる: Consumption（従量・サーバーレス、スケールゼロ）/ Developer（SLA なし・検証用）/ Basic / Standard / Premium、および新世代の Basic v2 / Standard v2（高速デプロイ、VNet 統合の簡素化）。Premium のみマルチリージョン展開・VNet（注入）・複数カスタムドメイン・可用性ゾーンに対応
• キャパシティ単位（スケールユニット） で性能をスケール。Premium はリージョンごとに複数ユニットへスケールアウト可（自動スケール対応）
• レート制限（rate-limit）とクォータ（quota）はポリシーで実装。短期のバースト抑制（例: 5 秒間に N 回）と、月次などの消費上限を分けて設定できる
• 応答キャッシュは内蔵キャッシュ、または Azure Cache for Redis（外部キャッシュ）を利用可能
• VNet 接続は 注入（injection: 専用サブネットに APIM を配置） と 統合（v2 の VNet integration）/ Private Endpoint（インバウンドのプライベート化） の方式がある
• 従来 SKU のプロビジョニング/構成変更は数十分かかることがある（特に Premium の VNet 構成）。v2 SKU は大幅に高速化

内部の仕組み

リクエストは クライアント → APIM ゲートウェイ → バックエンドの順に流れ、ゲートウェイ内でポリシーパイプラインが段階的に実行されます。

• inbound: 受信時。サブスクリプションキー検証・JWT 検証（validate-jwt）・IP 制限・レート制限/クォータ・URL/ヘッダ/ボディの書き換え・キャッシュ参照（cache-lookup）など
• backend: バックエンド呼び出しの前後。タイムアウト・リトライ・回路ブレーカー・バックエンド選択
• outbound: 応答返却前。ボディ変換（XML⇔JSON 等）・ヘッダ除去・キャッシュ格納（cache-store）
• on-error: いずれかでエラーが発生した時のハンドリング

ポリシーは グローバル → 製品 → API → オペレーションの各スコープで定義でき、<base /> で上位スコープの処理を差し込みます。バックエンドへの通信は APIM がファサードとして仲介するため、利用者にバックエンドの実体（ホスト名/認証方式）を隠蔽できます。

設計パターン / ベストプラクティス

• APIM + Azure Functions / App Service / AKS でサーバーレス〜コンテナ API のファサードを構築。バックエンドは APIM 経由のみ許可
• JWT 検証を玄関に集約: validate-jwt で Microsoft Entra ID（旧 Azure AD） のトークンを検証し、認可（OAuth 2.0 / OpenID Connect）をゲートウェイで統一
• 製品 + サブスクリプションで利用者・プラン（無料/有料）を分け、製品単位でレート制限・クォータを設定
• バックエンドの保護: バックエンド（App Service など）は VNet + Private Endpoint に隠し、APIM からのみ到達可能にする。あるいは APIM を前段の唯一の入口にして直接公開しない
• シークレットは名前付き値 + Key Vault 参照で管理し、ポリシーに直書きしない
• 可用性が要件なら Premium のマルチリージョン + 可用性ゾーン。前段に Front Door / Application Gateway（WAF） を併用して L7 防御・グローバル配信
• バージョンとリビジョンを使い分け、破壊的変更は新バージョン、無停止の修正はリビジョンで安全に反映

運用・監視

• Azure Monitor / メトリクス: 要求数（Requests）、容量（Capacity %）、バックエンド/全体の応答時間、4xx/5xx を監視。Capacity が高止まりならユニット追加（スケールアウト）
• Application Insights 連携で API 単位のテレメトリ・依存関係・例外を分析（サンプリング率に注意）
• 診断ログ（ゲートウェイログ）を Log Analytics / Storage / Event Hub へ送出。エラーやレイテンシのトレンドを把握
• 429（Too Many Requests） はレート制限/クォータポリシーの上限を確認。トレース（Ocp-Apim-Trace） でポリシーパイプラインの実行を可視化して原因を切り分け
• セルフホストゲートウェイはコンテナのヘルスと構成同期（コントロールプレーン到達性）を監視

コスト

• Consumption は呼び出し回数ベースの従量（一定の無料枠あり）で、トラフィックが間欠的なら安価。ただしコールドスタートや一部機能制限がある
• 従来 SKU / v2 は稼働時間（ユニット）課金が中心。定常的に流量がある本番では予測しやすく、機能（VNet・マルチリージョン・複数ドメイン）も揃う
• 応答キャッシュに Azure Cache for Redis を使う場合は Redis 側の料金が別途かかる。Application Insights / Log Analytics の取り込み量にも注意

セキュリティ

• サブスクリプションキーで利用を識別・制限し、validate-jwt で Entra ID / OAuth 2.0・OpenID Connect トークンを検証（認可を玄関に集約）
• mTLS（クライアント証明書） 認証や、バックエンドへのクライアント証明書/マネージド ID による認証に対応。APIM にマネージド ID を付与し、Key Vault や Functions などへ資格情報レスでアクセス
• IP 制限・レート制限・クォータポリシーで乱用を抑止。前段に Front Door / Application Gateway の WAF を併用して L7 攻撃を緩和
• VNet 注入 / Private Endpoint で APIM 自体やバックエンドをプライベート化。TLS 1.2 以上を維持し、弱い暗号スイートを無効化
• 名前付き値 + Key Vault でシークレットを集中管理し、ポリシーや構成への直書きを排除

関連サービス・比較（AWS との対応）

• APIM はポリシー（XML）で処理を宣言的に組み立てる点と、製品/サブスクリプション/開発者ポータルによる API の配布・収益化機能が標準で一体である点が特徴。API Gateway は HTTP API / REST API の使い分けでコストと機能を調整する
• ハイブリッド/マルチクラウドでは APIM の セルフホストゲートウェイが強み。Azure 側のバックエンド保護は VNet / Private Endpoint、前段の WAF は Front Door / Application Gateway が定番の組み合わせ

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# API Management インスタンスを作成（Consumption は安価・サーバーレス）
# ※ Developer/Basic などは作成に数十分かかる場合がある
az apim create \
  --resource-group demo-rg \
  --name demo-apim-0603 \
  --location japaneast \
  --publisher-name "Contoso" \
  --publisher-email admin@contoso.com \
  --sku-name Consumption

# 既存のバックエンド（OpenAPI/Swagger）から API をインポート
az apim api import \
  --resource-group demo-rg \
  --service-name demo-apim-0603 \
  --api-id petstore \
  --path petstore \
  --specification-format OpenApi \
  --specification-url https://petstore3.swagger.io/api/v3/openapi.json

# 製品を作成し、API を割り当て（サブスクリプション必須・公開）
az apim product create \
  --resource-group demo-rg \
  --service-name demo-apim-0603 \
  --product-id starter \
  --product-name "Starter" \
  --subscription-required true \
  --approval-required false \
  --state published

az apim product api add \
  --resource-group demo-rg \
  --service-name demo-apim-0603 \
  --product-id starter \
  --api-id petstore

# API 一覧を確認
az apim api list \
  --resource-group demo-rg \
  --service-name demo-apim-0603 \
  --query "[].{Name:displayName, Path:path}" -o table

レート制限・JWT 検証などはポリシー（XML）で API/製品スコープに適用します。例として、5 秒あたり 10 回に制限する inbound ポリシーは次のとおりです。

<policies>
  <inbound>
    <base />
    <rate-limit calls="10" renewal-period="5" />
    <!-- 例: Entra ID の JWT を検証して認可を玄関に集約 -->
    <!-- <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
           <openid-config url="https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration" />
           <audiences><audience>api://<app-id></audience></audiences>
         </validate-jwt> -->
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>