はじめに
「できるだけリアルタイムに情報を届けたいが、どの方式を選べばよいのか分からない」——。
プロジェクト中に、お客様から疑問の声があがりました。
私自身、過去の案件の経験ではREST APIを用いたポーリング処理の実装はありましたが、それ以外の実装経験はなく、その場でお客様に回答することができませんでした。
位置情報のトラッキングやチャット、IoT データのモニタリングなど、リアルタイムな情報提供が求められるユースケースは急速に増えています。AWS が提供する通信の手段も多様化し、HTTP ポーリングや WebSocket、比較的新しい AppSync Events など、選択肢が広がる一方で、方式ごとの特性を定量的に比較する情報は多くありません。
「ポーリングだとどれくらい遅延するのか？」
「WebSocket と AppSync Events で体感差はあるのか？」
「セキュリティや運用負荷はどう変わるのか？」
本記事では、リアルタイムでの通信方式を技術検証、比較し、得られた知見を共有します。
▼ この記事の対象読者
- リアルタイム通信の方式選定に悩んでいるエンジニア
- AWS 上でリアルタイムアプリケーションを構築する予定がある方
- 各方式の実装のポイントやコストの違いを把握したい方
本記事で取り扱わないこと
本記事の主眼は、AWSにおけるリアルタイム通信方式（4パターン）の特性を定量・定性的に比較し、最適な選定基準を提示することです。 そのため、以下の内容は扱いません。
- AWS 各サービスの基本概念・作成手順
- 具体的なソースコードの詳細解説
- 認証プロトコルの深い仕様解説
- WAF の詳細なルール構築
- TCP/IP や HTTP 等の下位レイヤー技術の詳細
検証の概要
比較対象
今回AWS環境上で以下の4つのデータ配信方式を検討、検証を行いました。
| No | 方式 | 主な AWS サービス | 通信モデル |
| 1 | HTTP Polling | API Gateway HTTP API + CloudFront | Pull 型 |
| 2 | REST Polling | API Gateway REST API | Pull 型 |
| 3 | WebSocket | API Gateway WebSocket API + CloudFront | Push 型 |
| 4 | AppSync Events | AWS AppSync Event API | Push 型 |
Pull 型（ポーリング）はクライアントが定期的にサーバーへリクエストする方式、Push 型はサーバーからクライアントへデータを即座に送信する方式です。この違いが遅延特性やコスト構造に大きく影響します。
検証構成
お客様のセキュリティ要件のため、今回の検証ではWAFを必須としました。直接WAFをアタッチできるサービスとそうでないサービスがあるため、方式により追加でCloudFrontが必要になってくるものがあります。
フロントエンドは 4 つのペインに分割し、それぞれの通信方式で同時にデータを取得し、どの程度の遅延が発生するかを比較しました。
4方式の技術的特性
1. HTTP Polling（API Gateway HTTP API）
HTTP API は API Gateway の中でもっとも軽量なタイプで、2019 年に登場しました。
クライアントが一定間隔で REST エンドポイントを呼び出し、サーバーはその時点の最新データを返すという古典的な Pull モデルです。
メリット
– 実装が最も簡単：標準的な HTTP リクエスト / レスポンスのみ。特別なプロトコルや接続管理は不要
– デバッグしやすい：curl やブラウザの DevTools で簡単にリクエストを確認できる
– インフラ構成がシンプル：Lambda + API Gateway のみ。接続状態を保持する必要がない
– CloudFront でキャッシュ可能：更新頻度が低いデータならキャッシュで Lambda 呼び出しを削減できる
デメリット
– 遅延がポーリング間隔に依存：10 秒間隔なら最大 10 秒の遅延。リアルタイム性を求めるほど間隔を短くする必要がある
– 無駄なリクエスト：データ更新がなくても定期的にリクエストが発生し、コストと負荷が増加
– スケール時のコスト増：クライアント数 × ポーリング頻度のリクエストが発生するため、接続数が増えるとコストが急増
2. REST Polling（API Gateway REST API）
REST API は API Gateway のオリジナルタイプで、HTTP API より機能が豊富です。データ取得モデルは HTTP Polling と同一（Pull 型）ですが、API キー管理、使用量プラン、リクエスト / レスポンス変換、X-Ray トレーシングなど、エンタープライズ向けの機能が充実しています。
メリット
– エンタープライズ機能が充実：API キー、使用量プラン、スロットリング、リクエスト検証、モデル定義
– Cognito User Pool Authorizer をネイティブサポート：認証の設定がシンプル
– X-Ray トレーシング内蔵：分散トレーシングが追加実装なしで利用可能
– WAF 直接アタッチ：CloudFront を介さずに Regional WAF を適用でき、構成がシンプル
デメリット
– HTTP API より高コスト：同じリクエスト数で約 3 倍のコスト差がある
– 遅延はポーリング間隔依存：HTTP Polling と同じ制約
– REST API 固有のオーバーヘッド：ステージ管理やモデルバリデーションにより、HTTP API と比べてわずかにレイテンシが増加
– 冗長な設定：シンプルな API の場合設定項目が過剰
3. WebSocket（API Gateway WebSocket API）
WebSocket API は、HTTP のハンドシェイクで接続を確立した後、TCP コネクションを維持して双方向通信を行います。サーバーからクライアントへの Push 配信が可能で、ポーリングのような待ち時間が発生しません。
AWSでは、API Gateway上でWebSocketの接続がサポートされています。
メリット
– 低遅延：データ発生から数百ミリ秒〜数秒で配信。
– 双方向通信：サーバー → クライアント（Push）だけでなく、クライアント → サーバーの送信もリアルタイム
– 接続単位の制御：connectionId を使い、特定のクライアントだけにメッセージを送信可能
– バックエンド主導の制御：配信ロジックをすべて自前で実装できるため、きめ細かいフィルタリングやルーティングが可能
デメリット
– 接続管理が必要：接続テーブルの設計、$connect / $disconnect ルートの実装、stale 接続のクリーンアップなど、考慮点が多い
– fanout の自前実装：全クライアントへの配信ループを自分で書く必要があり、接続数増加時のスケーリングも自己責任
– 認証制約：JWT Authorizer に非対応のため、カスタム Lambda Authorizer の実装が必須。
– CloudFront 経由の設定が複雑：WebSocket を CloudFront で中継するにはキャッシュポリシーやオリジンリクエストポリシーの細かい設定が必要
4. AppSync Events（AWS AppSync Event API）
AppSync Events は 2024 年に登場した AWS ネイティブの Pub/Sub サービスです。WebSocket ベースでリアルタイム配信を行いますが、接続管理・スケーリング・fanout をすべて AWS 側がマネージドに処理します。開発者は「チャネルに Publish する」「チャネルを Subscribe する」というシンプルなモデルでリアルタイム通信を実現できます。
メリット
– 低遅延 + マネージド：WebSocket 同等の低遅延を実現しつつ、接続管理・fanout・スケーリングを AWS に委任
– 接続テーブル不要：WebSocket のような自前の接続管理コードが不要で、実装量が大幅に削減
– Cognito / IAM のネイティブ統合：カスタム Authorizer の実装が不要
– チャネルベースの設計：Pub/Sub モデルが自然に適用でき、トピックごとの購読制御が容易
– WAF 直接アタッチ：Regional WAF を直接適用でき、CloudFront を介さずにセキュリティ保護が可能
デメリット
– 比較的新しいサービス：他の3方式に比べ、Web上でのノウハウは比較的少ない
– バックエンド制御の柔軟性が限定的：WebSocket のような接続単位のきめ細かい制御（特定クライアントだけに送信など）は不向き
– マネージドゆえのブラックボックス性：内部の配信遅延やスケーリング挙動を細かくチューニングできない
コスト比較
方式ごとのコスト構造は大きく異なります。
料金体系の違い
| 方式 | 課金モデル | 主な課金要素 |
| HTTP | リクエスト課金 | API Gateway リクエスト数 + Lambda 実行回数 |
| REST | リクエスト課金 | API Gateway リクエスト数 + Lambda 実行回数 |
| WebSocket | 接続時間 + メッセージ | 接続分数 + メッセージ数 + Lambda 実行回数 |
| AppSync Events | 接続 + オペレーション | 接続分数 + Publish / Subscribe オペレーション数 |
API Gateway 単価比較（東京リージョン）（2026年4月時点）
| 項目 | HTTP API | REST API | WebSocket API |
| リクエスト単価 | $1.29 / 100万リクエスト | $4.25 / 100万リクエスト | $1.14 / 100万メッセージ |
| 接続料金 | — | — | $0.285 / 100万接続分 |
AppSync Events は接続時間 $0.08/100万接続分 + オペレーション $1.00/100万 が目安
基本的にPull型はリクエスト単位で課金が発生し、Push型は接続時間に応じて課金が発生します。
つまり、リクエストの発生を抑えられる低頻度更新の場合はPull型にコストメリットがあり、高頻度になればなるほどPush型にメリットが寄っていく形となります。
また、接続数に応じてかかるfanout用のLambdaが必要になるWebSocketに比べ、マネージドでスケーリング管理を行ってくれるAppSync Eventsは大量接続時にコストメリットがあります。
| シナリオ | 低頻度更新 | 高頻度更新 | 大量同時接続 |
| HTTP | ◎ | △ | × |
| REST | ○ | △ | × |
| WebSocket | △ | ○ | △ |
| AppSync Events | △ | ○ | ◎ |
より詳細なコスト試算は、各データの特性や接続数によって変わってくるため、具体的な値に関しては別途計算が必要ですが、今回のプロジェクトの試算では数秒単位での更新が発生するならPush型、数十秒〜数分間隔での更新で良いのであればPull型という結論になりました。
セキュリティ比較
4方式すべてを同一のセキュリティ基準で保護するため、認証と入口制御（WAF）の両面で検証しました。
認証方式の比較
| 方式 | 認証メカニズム | 実装コスト | WAFの直接アタッチ | セキュリティ特性 |
| HTTP | JWT Authorizer | ◎ | × | API Gateway がトークン検証を代行。Lambda に到達する前に認証が完了 |
| REST | Cognito User Pool Authorizer | ◎ | ○ | Cognito との統合がネイティブ。スコープベースの制御も可能 |
| WebSocket | カスタムLambda Authorizer | △ | × | JWT Authorizer 非対応のため自前実装が必須。トークンをクエリストリングで渡すため、アクセスログにトークンが残るリスクあり |
| AppSync Events | Cognito User Pool / IAM | ○ | ○ | 複数の認証モードを宣言的に設定可能。Publish / Subscribe ごとに認証方式を切り替えられる |
認証、セキュリティに関しては、AWSマネージドで行ってくれるREST、AppSync Eventsが優れています。
検証結果の比較
実際に 4 方式を同時に動かして得られた結果を整理します。
遅延（即時性）
| 方式 | 遅延 | 要因 |
| HTTP | ポーリング間隔に依存 | ポーリング間隔に依存。データ発生直後にリクエストが飛ぶとは限らない |
| REST | ポーリング間隔に依存 | HTTP Polling と同等。REST API 固有のオーバーヘッドは体感差なし |
| WebSocket | 1〜3秒程度 | DynamoDB Streams の伝播遅延 + fanout Lambda の処理時間 |
| AppSync Events | 1〜3秒程度 | WebSocket とほぼ同等。AppSync 側の配信オーバーヘッドは軽微 |
Push 型（WebSocket / AppSync Events）は Pull 型と比較して体感で明確な差があり、地図上のデバイス移動がリアルタイムに追従する様子が確認できました。一方、Pull 型（HTTP / REST）では遅延がポーリング間隔に依存します。
Pull 型はデータの送信と取得、それぞれが各時のタイミングで行う関係で、遅延時間の期待値は（ポーリング間隔 / 2）となります。もし、データの送信直後にポーリングが行われれば即時取得できますが、その逆でポーリング直後にデータ送信が行われた場合は最大でポーリング間隔分の遅延が発生します。
実装の複雑さ
| 方式 | Lambda 数 | 接続管理 | 認証実装 | 総合評価 |
| HTTP | 1 | 不要 | JWT Authorizer（設定のみ） | ◎ 最もシンプル |
| REST | 1 | 不要 | Cognito Authorizer（設定のみ） | ◎ シンプル |
| WebSocket | 4 | DynamoDBでテーブル管理 | カスタム Lambda 実装 | △ 複雑 |
| AppSync Events | 1 | 不要 | 宣言的設定 | ○ やや複雑 |
WebSocket は、接続のライフサイクル管理（$connect / $disconnect）と fanout ロジックを自前で実装するため、Lambda の数もコードベースも大きくなります。AppSync Events は、この部分を AWS に委ねられるため、Push 型としては実装負荷が低いです。
スケーラビリティ
| 方式 | スケーリング特性 |
| HTTP | リクエスト数に応じて自動スケール |
| REST | 同上 |
| WebSocket | 接続数に応じてスケール (API Gateway 側) |
| AppSync Events | AWS が自動スケール |
WebSocket の fanout は「全接続を走査してメッセージ送信する」設計のため、接続数が増加すると Lambda の処理時間と post_to_connection の API コールが増大します。大規模配信では、SQS や Step Functions によるファンアウトの分散が必要になる場合があります。
AppSync Events は fanout を AWS 側が処理するため、接続数の増加に対してアプリケーション側のコードは影響を受けません。
方式選定ガイド
検証結果を踏まえた、ユースケース別の推奨方式です。
シンプルな画面更新・低頻度のデータ更新 → HTTP Polling
ダッシュボードの数値更新や、数十秒〜数分間隔で十分なユースケースでは、ポーリングの単純さとコストの低さが最大の武器です。HTTP API は REST API の約 1/3 のコストで利用でき、WAF が不要であれば CloudFront も省略可能です。
エンタープライズ要件がある定期取得 → REST Polling
API キー管理、使用量プラン、リクエスト検証など、API 管理機能が求められる場面では REST API が適しています。コストは高くなりますが、Regional WAF の直接アタッチや X-Ray トレーシングなど、運用面の機能が充実しています。
接続単位のきめ細かい制御が必要 → WebSocket
チャットやオンラインゲーム、特定ユーザーへの通知など、「誰に何を送るか」を接続単位で制御したいユースケースでは、WebSocket が最も柔軟です。双方向通信もサポートしており、クライアントからの入力もリアルタイムに受け取れます。ただし、接続管理と fanout の実装・運用コストが高くなることには注意してください。
Pub/Sub × マネージドスケーリング → AppSync Events
IoT データの全体配信、ライブフィード、位置情報のブロードキャストなど、「チャネルに配信し、購読者全員に届ける」モデルが自然なユースケースでは AppSync Events が最適です。接続管理とスケーリングを AWS に委ねられるため、運用負荷が大幅に低減します。
まとめ
本記事では、AWS 上でリアルタイム通信を実現する 4 つの方式——HTTP Polling、REST Polling、WebSocket、AppSync Events——を同一画面で同時に動かし、遅延・コスト・セキュリティ・スケーラビリティを多角的に比較しました。
コスト、セキュリティ要件、運用面など、考慮すべきことが多く、画一的にどれが最も良いと言えるものではなく、総合的に判断することが重要です。
また、カタログスペックでは見えにくいWebSocketに必要なLambdaの実装や接続管理の複雑さ、AppSync Eventsがマネージドで行ってくれる簡便さは、実際にコードを書いて動かしてみることで初めて正しく認識できました。
過去の経験ではREST APIを利用したポーリング処理だけで実装を行っていましたが、今後はお客様の要件次第ではAppSync Eventsを積極的に提案していくのも良さそうだと感じました。
本記事が、皆様のリアルタイムアプリケーション構築の際の試行錯誤を短縮する一助となれば幸いです。
参考文献
- Amazon API Gateway HTTP API
- Amazon API Gateway REST API
- Amazon API Gateway WebSocket API
- AWS AppSync Events
- Amazon API Gateway の料金
- AWS AppSync の料金
- AWS WAF
投稿者プロフィール
- AWSをメインとするバックエンドエンジニア。要件定義から運用保守まで幅広く対応しています。趣味は競技プログラミングで、アルゴリズムやロジックのパフォーマンスチューニングが得意。
