このサイトにはプロモーションが含まれます

API Gateway ってただのルーターだと思っていました

私、恥ずかしながら AWS API Gateway をただのルーターだと思っていました。
(Laravelで言うところのweb.php

実態を調べていくと Gateway の名がつく通り、玄関口としての機能の他、マネージドサービスとしての様々な機能が搭載されていることが分かったため備忘録として残したいと思います。

Let`s GO

はじめに知っておくべきこと

APIから理解していく

API = Application Interface という名がつく通り、リクエストを投げるためのインターフェースです。

テレビのリモコンを利用する際にあるボタンを押すと特定の動作が実行されることを想像してください。
私達はリモコン内部の詳細な処理を知っていなくても、ボタンを押すと期待する動作が実行されます。

それと同じで、
APIの呼び出し元は必要な情報を入力すると要求するデータが返ってくることが知っていればよいのです。
これがAPIの正体です。

API

やんやん

プログラマーとしてLEMP環境に主に生息しており、DevOps 的な立ち回りをしながらご飯を食べている当ブログの管理人のやんやんと申します。
最近はTmux使うのを辞めました。

 

概要と基本機能

API GatewayはAWSが提供するマネージドサービスで、以下を一元的に管理できるサービスです。

バージョン管理や環境ごとのデプロイ、認証・認可、モニタリングなどができるためデベロッパーを幸せにしてくれるサービスです。

特徴 説明
スケーラブル 自動的にトラフィックに対応。
プロトコル対応 REST API、HTTP API、WebSocket APIをサポート。
セキュリティ 認証、アクセス制御、リクエスト制限を実現。
開発効率化 簡単なセットアップでバックエンドと連携可能。
役割 説明
クライアントとバックエンド間の仲介役 API Gatewayがリクエストとレスポンスを処理します。
リクエストの認証と認可 IAMやCognito、カスタムオーソライザーで認証を管理。
データ変換 JSONからXMLなど、フォーマット変換を行う。
キャッシュによるパフォーマンス向上 頻繁にアクセスされるデータをキャッシュしてレスポンス速度を向上。
マネージドサービスとは

ざっくりいうとAWSさんがインフラの管理を行ってくれるサービスのことです。
管理している項目は以下のとおりです。
- サーバー
- ストレージ
- ネットワーク機器のセットアップ
- 運用
- 障害対応

ユースケース

種類 説明 バックエンド
REST API フロントエンドアプリやモバイルアプリがデータを取得するためのエンドポイントとして使用。 DynamoDBやRDSのデータを返す。 EC2, ECS,
DynamoDB, RDS, S3など
WebSocket 双方向通信が必要なリアルタイムアプリケーションで使用。 チャットアプリ、通知システム。 Lambda, IoT Coreなど
Lambda統合 サーバーレスアーキテクチャのフロントエンドとして機能。 Lambdaを介してデータ処理を行い、結果を返す。 Lambda, Step Functionsなど

RestAPIとHTTPAPIは機能が異なっているよ

基本的にはHTTPプロトコルを使用しますが、AWS API Gatewayの場合、REST APIとHTTP APIでいくつか仕様の違いがあります。

  • AWS API GatewayのREST APIを使用する場合、認証やリクエストパスに設定が必要
  • HTTP APIはAWS API Gatewayの軽量版で、低レイテンシーと簡単な設定が特徴です。多くの場合、REST APIよりもシンプル
//////////////////////
// RestAPI
///////////////////////
const axios = require('axios');

const httpApiUrl = "https://example.execute-api.us-east-1.amazonaws.com/resource"; // HTTP APIのエンドポイント
const token = "your-auth-token"; // 必要に応じてJWTや他の認証トークンを使用

async function callHttpApi() {
    try {
        const response = await axios.post(httpApiUrl, 
            { data: "Sample payload" }, // リクエストボディ
            {
                headers: {
                    Authorization: `Bearer ${token}`, // HTTP APIではJWTを使用するケースが多い
                },
            }
        );
        console.log("HTTP API Response:", response.data);
    } catch (error) {
        console.error("Error calling HTTP API:", error.response ? error.response.data : error.message);
    }
}

callHttpApi();

//////////////////////
// HTTPAPI
///////////////////////
const axios = require('axios');

const httpApiUrl = "https://example.execute-api.us-east-1.amazonaws.com/resource"; // HTTP APIのエンドポイント
const token = "your-auth-token"; // 必要に応じてJWTや他の認証トークンを使用

async function callHttpApi() {
    try {
        const response = await axios.post(httpApiUrl, 
            { data: "Sample payload" }, // リクエストボディ
            {
                headers: {
                    Authorization: `Bearer ${token}`, // HTTP APIではJWTを使用するケースが多い
                },
            }
        );
        console.log("HTTP API Response:", response.data);
    } catch (error) {
        console.error("Error calling HTTP API:", error.response ? error.response.data : error.message);
    }
}

callHttpApi();

 

特徴 REST API HTTP API
パフォーマンス 高機能だがレイテンシが高い 軽量で低レイテンシ
認証 APIキー、IAM認証が主流 JWT認証が一般的
コスト HTTP APIより高い REST APIより低い
ユースケース 高度な機能が必要な場合 シンプルなユースケース

その他にも様々な違いがあるため、一度目を通していただくと良いです。

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/http-api-vs-rest.html

知っておくと幸せになれるお話

パフォーマンス最適化

最適化方法 説明 設定例
キャッシュ レスポンスデータをキャッシュして、同じリクエストに対するバックエンド呼び出しを回避。
レイテンシ削減とバックエンド負荷軽減が可能。
- ステージ設定でキャッシュを有効化
- TTL(Time to Live)を300秒に設定
- キャッシュキーにクエリ文字列を追加
スロットリング リクエスト数を制限し、過剰なトラフィックやDDoS攻撃を防ぐ。
公平なリソース利用を促進。
- 最大リクエスト数: 100/秒
- バーストキャパシティ: 200
- ユーザーごとにAPIキーで制限
ペイロード リクエストやレスポンスのサイズを削減し、処理速度を向上。
圧縮や不要データの削除を行う。
- gzip圧縮を有効化
- レスポンスデータを最小限にする
- 必要なフィールドのみ返却

VPCのリソースへアクセスさせるためには

VPC内のリソースとAPI Gatewayを接続するには、「VPCリンク」というリソースを作成します。
これにより、API GatewayがVPC内のリソースに安全にアクセスできます。

認証・認可が不要なのでは?

バックエンドにWEBフレームワークを指定する場合は、WEBフレームワークで認証認可を行えば良いと思っていましたが、調べていくうちにAPI Gatewayで実施する方が効率が良いことに気付きました。

また、WEBフレームワークを使用する場合でも API Gatewayでの認証認可 + WEBフレームワークでの認証認可の2段階で実施することはセキュリティ強化につながるのではないかと考えます。
(冗長ですが、重ねて対策することでセキュリティ対策を向上させることができると思っています。

目的 詳細 メリット
不要なトラフィックの遮断 認証に失敗するリクエストをバックエンドに渡す前に遮断。 不正リクエストによるバックエンドリソースの消費を削減。
セキュリティ強化 OAuth 2.0、Cognito連携、IAMポリシーなど高度なセキュリティ設定が可能。 AWSのセキュリティ機能を活用し、バックエンドの脆弱性露出を軽減。
スケーラビリティの向上 スロットリング(Rate Limiting)やIP制限でトラフィック管理。 突発的なアクセス増加に対応し、バックエンドの負荷を軽減。
認証ロジックの共通化 複数のバックエンドやマイクロサービス間で認証を統一。 各バックエンドで認証を実装する必要がなく、管理が容易。
AWSリソースとの連携 IAM認証やAWSサービス(S3、DynamoDBなど)との連携が簡単。 AWSサービスへのセキュアなアクセスが可能。
バックエンドのシンプル化 認証処理をAPI Gatewayで行い、バックエンドはビジネスロジックに集中。 コードベースがシンプルになり、保守性が向上。

Twitterでフォローしよう

読んでみーな
おすすめの記事