API Gateway
目的
APIGatewayについて理解が曖昧なので学習目的で内容を整理します。
今回この整理しよう思ったきっかけ↓↓
全てのAPI GatewayにWAFはアタッチするべきものと勘違いしていて、
CountモードのWAFを全てのAPI Gatewayにアタッチして、状況を観察していました。
しかし、API Gatewayに色々種類があり、モノによってはWAFをつけなくてよかったり、そもそも付けられなかったりということを学び、全然API Gatewayわかってないじゃん！ と反省しました。
そもそもAPI Gatewayとは
あらゆる規模の REST、HTTP、および WebSocket API を作成、公開、維持、モニタリング、およびセキュア化するための AWS のサービスと難しい言葉で書いてあります。(公式ドキュメントより)
実際にやっていることはクライアントとバックエンドの仲介です。
ただし、Webアプリケーションはクライアントからバックエンドに直接リクエストを飛ばすことはもちろん可能です。
なぜわざわざAPI Gatewayにクライアントとバックエンドの仲介をさせるのでしょうか？
API Gatewayを使うメリット
間に挟むことで以下の３つのメリットが得られます。
①セキュリティ
バックエンドのエンドポイントを外部公開しなくて済む。
認証・認可を一元管理できる。
DDoS対策やレートリミットが簡単に設定できる。
②運用効率
APIバージョン管理やエンドポイントの統一がしやすい。
ログやモニタリングを一元管理できる。
CORS設定やリクエスト/レスポンス変換も容易。
③拡張性・管理性
複数のバックエンド(マイクロサービス)を一つのAPIとしてまとめて公開できる。
プロトコル変換ができる。
運用やバージョン管理などが楽になるし、認証関連も一元管理、マネージド化してよりバックエンドのビジネスロジックに集中できるといったところでしょうか。
API GatewayのAPIタイプについて
マネジメントコンソールでAPI Gatewayを作成するときに一番最初に選ばされるもの。
①REST API
一般的なHTTP/RESTエンドポイントを提供。
認証・認可、レートリミット、ステージ管理、リクエスト/レスポンス変換など多機能。
②HTTP API
REST APIよりシンプル・低コスト・高パフォーマンス
必要最小限の機能に絞られている。
コスト重視やクイックスタート時の選択肢。
社内システムやマイクロサービス間など外部公開していないAPIであれば、クライアントが改修による影響を受けないので、ステージ管理が不要。さらに、シンプルな認証やルーティングだけで済むことも多いので、低コスト、高パフォーマンスのHTTP APIが採用されやすい。
③WebSocket API
WebSocketを使いたい場合。
※①と②の使い分けに悩むところだが、基本的に公開APIならREST API、非公開ならHTTP APIというのが基本路線っぽい。
APIエンドポイントタイプ(REST APIを選択した場合)
REST APIのみ３種類のAPIエンドポイントタイプがサポートされている。(HTTPやWebSocketはリージョナルタイプのみ)
①リージョナル
デフォルトタイプで指定したAWSリージョン内でのみAPIを公開する。
②エッジ最適化エンドポイント
CloudFrontを自動的に利用し、世界中のエッジロケーション経由でAPIを公開。
グローバルなクライアントからのアクセス時にレイテンシが低減。
インターネット経由のグローバル公開APIに最適。
③プライベートエンドポイント
VPCエンドポイント経由でのみアクセス可能。
インターネットからは直接アクセスできず、社内システムやセキュアなAPI公開に最適。
API Gatewayのメインコンポーネント
①リソース
APIのエンドポイントでAPI Gatewayの本体みたいなもの。
各リソースごとにHTTPメソッドを指定できる。
パスを複数作って、パスごとにマイクロサービスを公開したりといった使い方が可能。
②ステージ
APIのデプロイ先や公開環境を表す。
同じAPIでも、ステージごとにエンドポイントURLや設定を分けられることにより、テスト環境の実装やリソース変更時に同時並行稼働期間などを設けてユーザへの影響を最小限に抑えられる。
APIバージョン管理が可能になる。
プロキシ統合
API Gatewayのリクエスト・レスポンスをそのまま中継し、バックエンドで処理を完結させる方式。
-主なメリット
①設定がシンプル：API Gateway側の細かい設定やマッピングが不要
②バックエンドの自由度が高い：リクエスト解析やレスポンス整形をすべてバックエンドで制御できる
③API Gatewayの機能追加や仕様変更に左右されにくい：バックエンドの実装だけで柔軟に対応可能
迅速な開発・デプロイが可能：API Gatewayの設定変更を最小限にできるため、開発サイクルが速い
※シンプルな設定でバックエンドの柔軟性が得られるというのが最大のメリット。
※選択肢としてLambda統合とHTTP統合があるが、これはシンプルにバックエンドで何を使っているかで使い分ける。
メソッド設定
メソッド設定もよくわからない横文字が複数あったので一つずつ確認します。
①メソッドリクエスト
クライアントからリクエストを受け取るフェーズ。
どのようなデータを受け取るのか？を定義するところでいわゆるバリデーションの役割。
他にも認証・認可の適用やリクエストパラメータのマッピング、リクエスト制限・制御、ドキュメント生成の基礎など役割は多岐にわたる。
②統合リクエスト
どのようにバックエンドにデータを渡すか？を定義するところ。
リクエストの転送先のバックエンドを選択しつつ、データの形式も変換できる。(XML→JSONなど)
③統合レスポンス
バックエンドから受けたレスポンスの内容を変換できる。
ステータスコードをマッピングして、ステータスコードに意味を持たせたり、データ形式を変えたりできる。
④メソッドレスポンス
クライアントに返すレスポンスの形式や内容（ステータスコード、ヘッダー、レスポンスモデル）」を定義・制御する。
最後に
設定項目が結構多くて混乱していましたが、整理できました。(メモ書きなのでわかりにくかったらすみません)
※補足
HTTP APIとWebSocket APIのエンドポイントタイプはともにリージョナル固定です。
メソッド設定については以下の通りです。
HTTP API
ルートごとで設定できるが、Lambda/HTTPプロキシ統合を選択する必要があり、非プロキシは利用不可。
WebSocket API
メソッドの概念がなく、
フローチャート作ってみたけど、REST API以外は設定項目はそんな多くない？
Discussion