通信プロトコルの地図とAWSでの実装例

Last updated at 2026-02-21Posted at 2026-02-21

導入

「HTTPとWebSocketとSSEって何が違うの？」「gRPCが使えないシステムがある？」「MQTTとSQS、どっちも"メッセージング"って言うのになぜ別物扱いなの？」

通信プロトコルを学ぼうとすると、似たような名前・似たような用途のものが乱立していて、全体像がつかめないまま個別の知識だけが積み上がりがちだ。

「とりあえずALBにしておこう」「なんとなくAPI GWかな」。そうして描いた構成図が、結合テストで初めて繋がらないことが判明する。原因を調べると、使いたいプロトコルをその入口サービスが対応していなかった、というパターンは珍しくない。

WebSocketをAPI Gatewayに繋ごうとして、REST APIやHTTP APIでは動かないことに気づく。昔gRPCをCloudFrontの後ろに置こうとして詰まった（2024年11月以降は対応済み）。MQTTをALBで受けようとして弾かれる。これらはすべて、「プロトコルがどの層で何をしているか」を理解していれば、設計段階で防げた問題だ。

REST、gRPC、WebSocket、MQTT、Kafka、Zigbee——これらを「なんとなく知っている」状態から「どこにどれを使うべきか判断できる」状態に引き上げるには、整理の軸が必要になる。

このドキュメントは、通信プロトコルを3つの大分類で整理した地図だ。

大分類A（HTTP系） は、私たちが日常的にWebで使うプロトコル群。さらにHTTPのバージョン変化（/1.1・/2・/3）の影響を受けるか受けないかで二分し、その中でリクエスト・レスポンス型／非同期メッセージング型／リアルタイムストリーミング型に細分化している。

大分類B（HTTP以外） は、WebRTC、MQTT、Kafka、SSH、RDPなど、独自プロトコルでTCP/UDPを直接使う世界。IoTや低レイテンシ通信、車載システムなど、HTTPでは届かない領域がここに集まる。

大分類C（IP以外） は、そもそもIPネットワーク上で動かない通信。EthernetやWi-FiのようにIPを「下から支える」もの（C-1）と、BLE・Zigbee・CAN busのようにIPとは独立した世界で動くもの（C-2）に分かれる。

さらにドキュメント後半では、これらのプロトコルとAWSサービスの対応関係——どの入口サービス（CloudFront・ALB・API GW・NLB）が何を受け付け、WAF・Shield・Network Firewallがどのレイヤーを守るのか——を整理している。

プロトコルの「なぜそう設計されているのか」という背景まで踏み込むことで、単なる用語集ではなく、技術選定の判断基準として使えるリファレンスを目指した。

大分類A：HTTP系

A-1：HTTPバージョンの影響を受けない

HTTPを使うが、アプリ層のプロトコル仕様がHTTP/1.1・HTTP/2・HTTP/3のどれでも動く設計。
バージョンが変わっても透過的に恩恵を受けられる。

HTTP/1.1なら、TCPで遅い（HOLブロッキング、コネクション数制限）
HTTP/2なら、TCPだが多重化で大幅改善
HTTP/3なら、UDPベース（QUIC）でさらに高速
FWの制約でUDP 443が開いていないと、HTTP/3は使えない

A-1-a 単方向（リクエスト→レスポンスの繰り返し）

REST API

「ステートレス」「リソース指向」「HTTPメソッドをそのまま使う（GET/POST/PUT/DELETE）」などの設計思想（アーキテクチャスタイル）
厳密な仕様はなく、準拠度も実装者によってまちまち。「RESTful」の解釈も人によって異なる
現在のWeb APIのデファクトスタンダード

GraphQL

Facebookが定めた仕様。クライアントが「必要なフィールドだけ」をクエリで指定できる思想が軸
エンドポイントは基本1つ（POST /graphql）で、クエリ内容で取得データを制御する
オーバーフェッチ・アンダーフェッチ問題を解決するために生まれた
サブスクリプション機能（リアルタイム更新）はWebSocketを内部で使うため、A-2のWebSocketにまたがることもある。（Apollo GraphQLなど、A-1-cのSSEで実装するケースも増えている）。

SOAP

W3Cが定めた厳密な仕様。XMLのエンベロープ構造でリクエスト・レスポンスを包む
RESTが「思想」なのに対し、SOAPは「プロトコル仕様」という違いがある
現在はRESTやgRPCにほぼ置き換えられているが、金融・官公庁など旧来のエンタープライズシステムに残っている
HTTP以外（SMTP等）でも動く設計だが、実態はほぼHTTP上で使われる

JSON-RPC / XML-RPC

軽量なリモートプロシージャコール（RPC）仕様。メソッド名と引数をJSONまたはXMLで送る
RESTのリソース指向とは異なり「関数を呼び出す」思想
シンプルな仕様のため組み込み系や内部通信で使われることがある

OData

MicrosoftがRESTを拡張して定めた仕様。フィルタ・ソート・ページングをURLクエリで標準化
Microsoft製品（Azure、SharePoint等）のAPIで採用されていることが多い

tRPC

TypeScript特化のRPCフレームワーク。型定義をサーバー・クライアント間で共有できる
仕様というよりライブラリだが、思想としては「型安全なJSON-RPC」に近い
Next.jsなどTypeScriptフルスタック環境での採用が増えている

WebHookについての補足

WebHookはREST・GraphQL・JSON-RPCなどと異なり、プロトコルでも仕様でもなくアーキテクチャパターンだ。そのためこの分類図には登場しないが、A-1-aの文脈で頻繁に出てくる概念なのでここで補足する。

何者か

「外部サービスでイベントが起きたときに、あらかじめ登録しておいたURLへHTTP POSTを送りつける」仕組み。プロトコルとしては普通のHTTPS POSTであり、A-1-aの範囲に完全に収まる。

REST APIやJSON-RPCとの決定的な違いは呼び出しの方向だ。REST・RPCは「クライアントが能動的にサーバーを呼ぶ」。WebHookは逆で「サーバーがイベントを契機にクライアントのURLを呼ぶ」。ペイロードの形式はWebHookの本質ではなく、RESTライクなJSONでもJSON-RPC形式でも成立する。GitHubやStripeがRESTライクなJSONを使っているのは慣習であって定義ではない。

誰が受け取れるか

WebHookを受け取るには、外部サーバーからのHTTP POSTが届く公開URLを持つサーバーが必要になる。これはブラウザや一般的なスマホ・PCには当てはまらない。

ブラウザはHTTPリクエストを送る側として設計されており、外から受け取るHTTPサーバーとして動く機能を持っていない。またほとんどの端末はNATの内側にいてグローバルIPを持たず、ファイアウォールやルーターが外からの着信をブロックするため、仮にブラウザに受け取る機能があっても届かない。

WebHookはサーバー間の仕組みと割り切るのが正しい理解だ。

ブラウザへイベントを届けたい場合

WebHookで受け取ったイベントをブラウザに転送したい場合は、サーバーが中継役になる構成をとる。

外部サービス
    ↓ WebHook（HTTPS POST）
自前サーバー   ← WebHookはここまで
    ↓ SSE または WebSocket
ブラウザ       ← SSE/WebSocketで転送

WebHookとSSE・WebSocketは競合する技術ではなく、この構成のように役割分担して組み合わせて使うのが定石になる。

なお開発・テスト時はngrokのようなトンネリングツールを使ってローカルサーバーにWebHookを届かせることができるが、これは本番で端末に直接届ける仕組みではない。

A-1-b 非同期メッセージング・イベント駆動（マイクロサービス）

HTTPSのAPIを叩いてメッセージを送受信するが、送信者と受信者が時間的に切り離されている点がA-1-aと異なる。
仲介者（ブローカー）が間に入ることで、送信者と受信者が互いを知らなくていい疎結合が実現される。

※ このカテゴリに属するのは「ブローカーをHTTPS APIで操作するもの」に限る
※ RabbitMQ・ActiveMQ・Redis Pub/SubなどHTTPを使わない独自プロトコルのブローカーはB-1に属する
※ リアルタイム性は低い（ミリ秒〜数秒の遅延）。「即時」ではなく「確実な配信」が目的

キューイング型（1対1、メッセージを溜めて順番に処理）

送信者はキューに積むだけ。受信者がポーリングして取り出す
処理失敗時のリトライやデッドレターキューが組み込まれている
ワーカーの非同期バッチ処理、タスクキューに適している

具体例：Amazon SQS、Azure Service Bus（キューモード）、Google Cloud Tasks

pub/sub型（1対多、トピックに対してブロードキャスト）

送信者はトピックに投げるだけ。複数のサブスクライバーに同時配信される
SNS→SQSの組み合わせ（ファンアウトパターン）がマイクロサービスでよく使われる

具体例：Amazon SNS、Google Cloud Pub/Sub、Azure Service Bus（トピックモード）

イベントバス型（ルーティング・フィルタリングが高機能）

イベントの内容に応じて配信先を動的にルーティングできる
AWSサービス間・SaaS・独自アプリのイベントを統合的に管理できる
pub/sub型より複雑なルーティングルールを書ける。イベント駆動アーキテクチャの中心的存在

具体例：Amazon EventBridge、Azure Event Grid、Google Eventarc

ストリーミング型（大量イベントを順序保証・高スループットで処理）

キューイング・pub/subより大量データの処理と順序保証に特化
Kafkaが代表格だが、KafkaはHTTPを使わない独自プロトコル（TCP）なのでB-1に属する

具体例：Amazon Kinesis（HTTPS APIで操作するためA-1に属する）、Azure Event Hubs

※ Kafkaは独自TCPプロトコルのためB-1

A-1-c サーバー→クライアントの単方向リアルタイム

SSE（Server-Sent Events）

HTTPレスポンスを「閉じずに流し続ける」だけの仕組み。特別なUpgrade不要
HTTP/2の多重化と特に相性が良く、コネクション占有問題が解消される
HTTP/3が使える環境なら自動的にSSEもHTTP/3で動く（WebSocketと違い別途仕様が不要）
A-1-aの通信と組み合わせることで、擬似的な双方向を実現できる

具体例：ClaudeのストリーミングレスポンスもSSEを使っている

A-2：HTTPバージョンの影響を受ける

アプリ層のプロトコル仕様が、特定のHTTPバージョンの機能・接続モデルに依存して設計されている。
バージョンが変わるたびに別途対応仕様（RFC）が必要になる構造的な問題を抱えている。

WebSocket　双方向リアルタイム

HTTP/1.1の「コネクションをまるごとUpgradeする」モデルに依存して設計された
実質HTTP/1.1ベース（TCP）の実装のみ普及している
HTTP/2（RFC 8441）、HTTP/3（RFC 9220）上の仕様はあるが、実装・対応は限定的
UDPベースのHTTP/3で高速化できないため、最小遅延要件のゲーム等には限界がある

※ HTTP/2はコネクション内に複数ストリームを多重化する設計で、「コネクションをまるごと渡す」HTTP/1.1の発想と合わないので普及していない。
※ 後付けで対応しようとすると毎回新しい仕様が必要になる構造的な問題

具体例：個人開発オンラインゲーム、チャットアプリ

gRPC　双方向ストリーミング（マイクロサービス間通信）

HTTP/2のストリーム多重化を前提とした設計のため、HTTP/1.1では動かない
HTTP/3対応（gRPC-over-QUIC）は仕様策定中で、まだ普及していない
WebSocketと同じく「特定HTTPバージョンの機能に依存して設計した」ケース

※ 単方向・双方向ストリーミングの4パターンをサポート
※ Protocol Buffersによるバイナリシリアライズで高速・軽量
※ ブラウザからの直接利用は制約があり、grpc-webという別レイヤーが必要

具体例：マイクロサービス間のAPI通信、内部サービス間の高速RPC

WebTransport　双方向リアルタイム（次世代）

HTTP/3（QUIC）ベース＝UDPで動く
WebSocketの課題（HTTP/1.1依存、TCP固定）を解決する本命
QUICの特性（ストリームの独立性、低レイテンシ）をフルに活かせる設計
ブラウザ・サーバーの実装はまだ途上だが、今後の双方向リアルタイム通信の主役候補

具体例：個人開発オンラインゲームの将来的な選択肢

大分類B：HTTP以外

B-1：リアルタイム通信

WebRTC　P2P双方向リアルタイム（音声・映像・データ）

UDPベース（SRTP/DATAチャンネル）で動く。低遅延が特徴
ブラウザ同士がP2Pで直接通信するため、サーバーを経由しない
ただしP2P接続確立のためにシグナリングサーバー（WebSocketなどで実装）が必要
NATを越えるためにSTUN/TURNサーバーも必要なケースがある

※ 大規模になるとメッシュ型では限界があり、SFU/MCUサーバーを使う構成になる

具体例：ZoomやGoogle Meet、ブラウザ間のビデオ通話

MQTT　pub/subリアルタイム通信（IoT向け）

TCP上で動く独自プロトコル（デフォルトTCP 1883、TLS使用時は8883）
ブローカーを介したpub/subモデル。極めて軽量でリソース制約の大きい環境向けに設計されている
QoSレベル（0/1/2）で配信保証の強度を選択できる

※ SQS・SNSはHTTPS APIを叩く設計なのでA-1に属するが、MQTTはHTTPを使わない独自プロトコルなのでB-1に属する

具体例：センサーデータの収集、スマートホームデバイスの制御

非HTTPブローカー（独自プロトコル型メッセージング）

A-1-bの「HTTPSで操作するブローカー」と思想は同じだが、プロトコルレイヤーが異なる。

Kafka

TCP上で動く独自バイナリプロトコル（HTTPではない）
大量イベントを順序保証・高スループットで処理するために設計されている
A-1-bのSQS/SNSと並んでマイクロサービスのイベント駆動でよく使われるが、レイヤーが異なる
リアルタイム性よりも「大量データの順序保証・耐障害性」が主目的

具体例：ログ収集、リアルタイム分析パイプライン、マイクロサービス間の大量イベント処理

RabbitMQ

AMQP（Advanced Message Queuing Protocol）という独自プロトコル（TCP）で動く
キューイング・pub/subの両方をサポート。Kafkaより軽量でシンプルな用途に向いている

ActiveMQ

AMQP・STOMP・OpenWireなど複数の独自プロトコルをサポート
Javaエンタープライズ環境でよく使われる老舗のメッセージブローカー

Redis Pub/Sub

RedisのTCP接続上で動くpub/sub機能
超低遅延だがメッセージの永続化がない（消えても構わないリアルタイム通知向け）

独自UDPプロトコル　双方向リアルタイム（最小遅延）

独自のプロトコルや、ゲームエンジンのサービスが定義したプロトコルで通信
UDPを直接使うため、最小遅延を実現できる
信頼性制御や順序保証は自前で実装する必要がある

具体例：FPSオンラインゲームなど

RDP（Remote Desktop Protocol）

Microsoftが定義した独自プロトコル
TCP 3389（デフォルト）。UDPも使える（HTTP/3とは別物）
画面転送＋入力転送の双方向リアルタイム通信

具体例：Windowsリモートデスクトップ

SSH（Secure Shell）

TCP 22
ターミナルで打ったコマンドが即座に返ってくる、対話的な双方向リアルタイム通信
暗号化はSSH独自のレイヤーで行う（TLSではない）

具体例：サーバーへのリモートログイン

B-2：リアルタイム以外

以下はリアルタイム双方向通信とは性質が異なるため、このドキュメントでは詳細を省いている。

DNS（UDP 53）は「名前解決」のための単発の問い合わせ→応答で完結する。セッションを張り続けるものではない。

NTP（UDP 123）は時刻同期のための単発の問い合わせ→応答。定期的に実行されるが、リアルタイム性や双方向性はない。

メール（SMTP/IMAP/POP3）は非同期の「蓄積→転送」モデルで、リアルタイム性を前提としない設計。

FTP（TCP 20/21）はファイル転送専用で、「ファイルを送る/受け取る」という一方向の操作が目的。

これらに共通するのは「リクエスト→レスポンスで完結する」か「非同期で完結する」という点で、持続的なセッションやリアルタイム性を必要としない。

大分類C：IP以外の通信

大分類A・BはすべてIPネットワーク上で動く。
CはIPを使わない、またはIPの下のレイヤーで動く通信をまとめる。

Cをさらに2つに分ける：

C-1：IPの下のもの。この上にIPが乗る。IPのキャリアとして機能する
C-2：IPとは独立したもの。この上にIPが乗らない。IPとIP以外の両方で動く通信を含む

C-1：IPの下のもの（IPを乗せるキャリア）

IPパケットを運ぶ「1つ下の層」。これがなければIPは届かない。
宛先の識別にMACアドレスや物理ポートを使う。

Ethernet（IEEE 802.3）

有線LAN。MACアドレスでフレームを送受信する
スイッチがMACアドレステーブルを見てフレームを転送する
IPパケットをEthernetフレームのペイロードに乗せて運ぶ

Wi-Fi（IEEE 802.11）

無線LAN。MACアドレスで識別する点はEthernetと同じ
802.11a/b/g/n/ac/ax（Wi-Fi 6/7）などバージョンがある
IPパケットを無線のフレームに乗せて運ぶ

4G LTE / 5G（セルラー通信）

モバイルネットワーク。基地局経由でIPパケットを運ぶキャリア
物理層はLTE/NRの無線規格だが、その上にIPが乗る構造はEthernetと同じ
5Gのサブ6GHz・ミリ波は物理層の違い。IPを運ぶという役割は同じ

PPP（Point-to-Point Protocol）

2点間の直接接続でIPを運ぶプロトコル
ダイヤルアップ接続やWAN回線（専用線）で使われてきた
現在もPPPoEとしてフレッツ光等の接続に残っている

VLAN（Virtual LAN）

EthernetフレームにタグIDを付けて論理的にネットワークを分割する仕組み
物理的に同じスイッチでも異なるネットワークとして扱える
IPの下でVLANが通信を分離する

ARP（Address Resolution Protocol）

IPアドレスからMACアドレスを解決するプロトコル
「このIPを持っている機器のMACアドレスを教えて」とブロードキャストする
C-1とIPの橋渡し役。IPが実際に届くためにARPが必要

C-1補足：IPSecについて

※ IPSecは厳密には「プロトコル」ではなく「セキュリティフレームワーク（仕様群）」。
また「IPの下のキャリア」でもなく、IPと同じL3層で動くIPパケットの暗号化・認証の仕組み。
C-1のキャリア群とは性質が異なるが、ネットワークの基盤インフラとして関連が深いためここに記載する。

IPSec（Internet Protocol Security）

IPパケットを暗号化・認証するフレームワーク。プロトコルの集合体
HTTPSのようにアプリ層で暗号化するのではなく、IPパケットごと丸ごと暗号化する点が特徴
VPN（Virtual Private Network）の実装基盤として広く使われる

IPSecを構成する主なプロトコル：

AH（Authentication Header）：改ざん検知・送信元認証を提供。暗号化はしない
ESP（Encapsulating Security Payload）：暗号化＋認証を提供。実際はESPがほぼ使われる
IKE（Internet Key Exchange）：暗号化に使う鍵を安全に交換するプロトコル。IKEv2が現在の標準

動作モード：

トランスポートモード：IPヘッダーはそのまま、ペイロード部分だけを暗号化する。端末間の通信向け
トンネルモード：元のIPパケットをまるごと暗号化して新しいIPヘッダーで包む。VPNゲートウェイ間の通信向け

※ HTTPSはTLS（アプリ〜トランスポート層）で暗号化する。IPSecはIP層で暗号化する。どちらも暗号化だが守る層が異なる
※ AWS VPNやオンプレとのVPC接続（Site-to-Site VPN）はIPSec（IKEv2+ESP）を使っている

暗号化の仕組みの比較まとめ

IPSecはIPパケットをまるごと暗号化するため、A・Bすべてのプロトコルに対して下から横断的にかけられる。HTTPだろうがWebSocketだろうがSSHだろうが、IPパケットである限り関係なく暗号化できる。「インフラ層の暗号化」。

TLS/SSLはTCPコネクションの上で動くため、その上のアプリ層プロトコルごとに個別に対応が必要になる。HTTP+TLS=HTTPS、WebSocket+TLS=WSS、MQTT+TLS=MQTTS、という形で各プロトコルに依存する。「アプリ〜トランスポート層の暗号化」。

SSHはTLSを使わず独自の暗号化レイヤーを内包している特殊ケース。SSH自体がセキュアな通信を前提に設計されているため、TLSを外から被せる必要がない。SFTPもSFTP over SSHとして、SSH内で完結する。

A・B（アプリ層の通信：HTTP・WebSocket・MQTT等）
　↑　TLS/SSLは各プロトコルに個別にかかる（プロトコル依存）
　↑　SSHは独自暗号化を内包。TLS不要
IP層
　↑　IPSecはここでまるごと暗号化。A・B全部に横断的にかかる
C-1（Ethernet・Wi-Fi等）

C-2：IPとは独立したもの

IPを使わない独自プロトコルスタックで動く。
一部はIPと両立する設計（例：Modbus TCP）も持つため「IPとIP以外の両方を使う通信」を含む。

C-2-a：近距離・省電力無線通信

Bluetooth（IEEE 802.15.1）

数〜数十メートルの近距離無線通信。独自プロトコルスタックで動く
BLE（Bluetooth Low Energy）はIoTセンサー・ウェアラブル向けの省電力版
BLEは6LoWPAN経由でIPと繋げる構成もあるが、通常はIPなしで動く
スマートウォッチ・ワイヤレスイヤホン・キーボード等

Zigbee（IEEE 802.15.4）

超省電力のメッシュネットワーク通信。IPを使わない
スマートホームデバイス（電球・センサー・スイッチ等）
MQTTと比較されることが多いが、MQTTはTCP/IP上で動くのに対しZigbeeはIP不要
ZigbeeゲートウェイでIPネットワーク（A・B）と繋ぐブリッジ構成がよく使われる

Z-Wave

スマートホーム向けの独自無線プロトコル。IPを使わない
900MHz帯を使うためWi-FiやBluetoothと干渉しない
メーカー間の互換性（相互運用性）がZigbeeより担保されやすい

NFC（Near Field Communication）

数センチの超近距離通信。IPを使わない
交通系ICカード（Suica等）、スマートフォンの非接触決済
ISO 14443・ISO 18092等の規格

RFID

タグに電波を当てて識別情報を読み取る。IPを使わない
NFCはRFIDの一種。RFIDのほうが広義
物流・在庫管理・入退室管理等

C-2-b：車載・産業用バス通信

クローズドな環境でリアルタイム性・信頼性を最優先とした通信。

CAN bus（Controller Area Network）

車載ECU（電子制御ユニット）間の通信バス。IPを使わない
エンジン・ブレーキ・エアバッグ等の制御
マルチマスター型のシリアルバス。現代の車は数十〜百以上のECUがCANで繋がっている

LIN（Local Interconnect Network）

CANより低速・低コストな車載バス。IPを使わない
シート調整・ドアミラーなど低優先度の制御

Ethernet AVB / TSN（Time-Sensitive Networking）

車載や産業向けにEthernetを時間同期・低遅延化した規格
EthernetフレームベースなのでC-1に近いが、IPを使わない制御用途にも使われる
IPを乗せる場合はC-1、IP非使用の場合はC-2、両方使う構成もある
次世代車載ネットワークとして普及しつつある

C-2-c：組み込み・基板間通信

マイコン・センサー・モジュール間の超短距離通信。基板上の配線レベルで動く。IPを使わない。

I2C（Inter-Integrated Circuit）

2本の線（SDA・SCL）でマスター1台に複数のスレーブを繋げる
センサー・ディスプレイ・EEPROMとマイコンの接続に多用される

SPI（Serial Peripheral Interface）

I2Cより高速な4線式シリアル通信
SDカード・フラッシュメモリ・液晶ディスプレイ等

UART（Universal Asynchronous Receiver/Transmitter）

非同期シリアル通信の基本。2線（TX・RX）で1対1通信
デバッグ用コンソール・GPSモジュール・Bluetoothモジュールとの接続等

C-2-d：レガシーシリアル・産業プロトコル

RS-232

PCとシリアルデバイスを繋ぐ古典的な規格。IPを使わない
産業機器・計測器では今も現役

RS-485

RS-232の拡張版。マルチドロップ（1対多）が可能で長距離対応。IPを使わない
工場のPLC（プログラマブルロジックコントローラ）間通信等

Modbus（IPとIP以外の両方を持つ例）

産業機器向けの通信プロトコル。事実上の標準
Modbus RTU：RS-485上で動く。IPを使わない → C-2
Modbus TCP：TCP/IP上で動く → 大分類BのB-1相当
同じ「Modbus」という仕様がIPあり・なしの両方のキャリアに乗る典型例

C-1とC-2の違いのまとめ

C-1はIPを「乗せるための土台」であり、IPがなければC-1の存在意義が薄い。
C-2はIPとは無関係に独立して動く。IPと繋げたいときはゲートウェイ・ブリッジが必要になる。
Modbus・Ethernet AVB/TSNのように「IPあり・なし両方の顔を持つ」プロトコルもある。

AWSサービスとプロトコルの対応

入口（イングレス）：プロトコルと対応サービス

入口サービスはプロトコルを「理解して処理」する必要があるため、対応プロトコルが限定される。
どの入口を選ぶかが、受け付けられるプロトコルを決める。

プロトコル分類	対応する入口サービス	備考
REST / GraphQL（A-1-a）	CloudFront・API GW(REST,HTTP)・ALB	最も一般的な構成
非同期メッセージング（A-1-b） SQS / SNS / EventBridge	直接エンドポイント（AWS署名V4） API GW（REST API）経由も可	CloudFrontのオリジンにはできない直接エンドポイントはカスタムドメイン不可だが、API GW経由ならカスタムドメイン割り当て可能
SSE（A-1-c）	CloudFront・API GW・ALB	HTTP接続を維持するだけなので特別な対応不要
WebSocket（A-2）	ALB・API GW（WebSocket API）	NLBも素通し可（L4透過）
gRPC（A-2）	ALB（HTTP/2モード）・NLB・CloudFront	2024年11月にCloudFront対応
HTTP / HTTPS（A-1-a, A-1-c）	Verified Access（HTTPモード）	VPNなしのゼロトラストアクセス。L7専用（HTTP/HTTPS のみ）。WAF付与可。ID・デバイス検証を入口で実施
TCP（B-1系統）	Verified Access（TCPモード）	VPNなしのゼロトラストアクセス。WAF付与不可。ID・デバイス検証を入口で実施
MQTT（B-1）	NLB・AWS IoT Core（専用）	ALB・API GWは非対応。IoTデバイス向けにはIoT Coreが専用入口
独自TCP / UDP（B-1）	NLB	L4透過のためプロトコル不問
SSH / RDP（B-1）	NLB	同上
WebRTC（B-1）	NLB（シグナリング部分のみ）	P2P部分はAWSを経由しない。シグナリングサーバーをEC2/ECS上に置く構成

Route53はDNSレイヤーのため「入口」ではなく「入口への誘導」。
CloudFront・API GW・ALB・NLBにはAliasレコードで向けられる。
SQS・SNS・EventBridgeの直接エンドポイントにはカスタムドメインを割り当てられない。

gRPCとCloudFront
2024年11月に接続対応したが、HTTP/2とHTTP POSTを有効化した上でgRPCチェックボックスをオンにする必要あり
ただし制約もあって、Origin Failoverをサポートせず、Lambda@EdgeやOrigin Shieldもバイパスされ、WAFのリクエストボディ検査ルールも無視される。

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-using-grpc.html

Verified Accessの補足：HTTPモードとTCPモード

モード	対応プロトコル	WAF	ポリシー評価タイミング
HTTP/HTTPS	REST・GraphQL・SSE（A-1系）	付与可	リクエストごと
TCP	WebSocket・SSH・RDP・DB接続（A-2・B-1系）	付与不可	接続確立時のみ
※ TCPモードはNLBと同様にL7の中身を見ないため、
アプリケーション側でのバリデーションが重要になる。

入口のセキュリティ

入口のセキュリティは「どのレイヤーまで見るか」で担当サービスが分かれる。
レイヤーが上がるほど細かく見えるが、設定の複雑さも増す。

インターネット
    ↓
Shield（L3/L4：DDoS検知・緩和）
    ↓
Route53（DNS層：ルーティング操作の制御）
    ↓
CloudFront / ALB / API GW / NLB（入口サービス）
    ↓
WAF（L7：HTTPリクエスト内容の検査）← CloudFront・ALB・API GWにのみ付けられる
    ↓
バックエンド（EC2・Lambda等）

Shield：L3/L4 DDoS検知・緩和

AWSグローバルネットワーク全体のトラフィックを常時分析し、異常を自動検知・緩和する。

種別	内容
Shield Standard	全AWSアカウントで常時自動有効。追加設定不要・無償
Shield Advanced	保護対象リソースを明示的に登録する。高度な検知・DRT（DDoS Response Team）サポート・コスト補償付き

検知できるもの：

SYNフラッド・UDPリフレクション攻撃などのL3/L4 DDoS
BGP経路異常
大量パケットによる帯域消費攻撃

検知できないもの：

HTTPリクエストの中身（L7）→ WAFが担当
アプリケーションロジックの脆弱性

保護対象として登録できるリソース： CloudFront・ALB・NLB・EIP・Route53

WAF：L7 HTTPリクエスト検査・フィルタ

HTTPリクエストの「中身」を見てフィルタリングする。Shield・NLBでは見えないHTTPレイヤーをカバーする。

付けられる入口： CloudFront・ALB・API GW・AppSync
付けられない入口： NLB（L4透過のため、HTTPの中身を見ない）

WAFで制御できること：

種別	具体例
攻撃パターン検知	SQLインジェクション・XSS・コマンドインジェクション
IPベース制御	特定IPアドレス・CIDRのブロック・許可リスト
レートベース制御	同一IPからの過剰リクエスト（ブルートフォース・スクレイピング対策）
地理ベース制御	特定国からのアクセスをブロック
リクエスト内容の検査	URI・ヘッダー・クエリ文字列・ボディの内容でフィルタ
マネージドルール	AWSが提供する既製ルールセット（OWASP Top 10対応等）
Botコントロール	悪意あるBot・スクレイパーの検知・ブロック

NLBにはWAFを付けられない点に注意。
NLB経由でWebSocket・gRPC・独自プロトコルを受け付ける構成では、
L7のリクエスト検査ができないため、アプリケーション側でのバリデーションが重要になる。

ALB / API GW / NLB のログで見えるもの

WAF・Shieldの「検知・遮断」とは別に、入口サービス自身のログが通過したトラフィックを記録する。

サービス	ログ種別	見えるもの
ALB	アクセスログ	送信元IP・リクエストURI・HTTPメソッド・レスポンスコード・レイテンシ・User-Agent
API GW	アクセスログ・実行ログ	リクエスト詳細・認証結果・バックエンドの応答・エラー内容
NLB	フローログ（VPC Flow Logs）	送信元IP・宛先IP・ポート・プロトコル・バイト数（HTTPの中身は見えない）
CloudFront	アクセスログ	エッジロケーション・キャッシュヒット率・送信元IP・リクエスト詳細

これらのログはCloudWatch Logs・S3に送出でき、Athenaでのクエリ分析や
CloudWatchアラートと組み合わせることで、異常なアクセスパターンの事後検知に使える。

出口（イグレス）：基本的にプロトコル不問

出口インフラ（NAT GW・IGW・Egress-Only IGW）はIPパケットを転送するだけのため、
その中身のプロトコルを問わない。EC2・Lambda・ECSのコード内でHTTPだろうがMQTTだろうがgRPCだろうが、アウトバウンドは自由に使える。

プロトコルを制限したい場合は、以下でポート・ドメイン単位で制御する。

Security Group / NACL：ポート番号で制御
AWS Network Firewall：ドメイン・プロトコルレベルで制御（許可リスト方式）

出口のセキュリティ

プロトコル制限の手段

サービス	制御レベル	内容
Security Group / NACL	L4（ポート番号）	許可するポート・IPを指定。HTTPSなら443のみ開放するなど
Network Firewall	L4〜L7	ドメイン名・プロトコル・シグネチャでフィルタ。ステートフルなルールが書ける

Network Firewallで制御できること：

種別	具体例
ドメインフィルタ	`pypi.org`・`*.amazonaws.com` のみ許可し、それ以外への通信をすべて拒否
プロトコルフィルタ	HTTPS以外のアウトバウンドを拒否
シグネチャ検知	既知マルウェアのC2通信パターン・悪意あるペイロードの検知
TLSインスペクション	HTTPS通信を復号して中身を検査（別途設定が必要）

Network Firewallを使う場合、トラフィックは
プライベートサブネット → Network Firewall → NAT GW → IGW → インターネット
の順に経由する。NAT GW・IGWは引き続き必要。

例外：SES（送信メール）

SESは「外部SMTPサーバーにメールを送信する」出口を自身が持つため、プロトコルが決まっている。

用途	プロトコル	ポート
SESからの外部メール送信	SMTP	25 / 465（SMTPS）/ 587（STARTTLS）
アプリ→SESへの送信依頼	HTTPS（AWS API）	443

アプリがSESを呼ぶのはHTTPS（API）。
SESが外部メールサーバーに届けるのはSMTP。
この2つのプロトコルが混在する点に注意。

IP以外の出口：IoTデバイスとの通信

AWSからIPを使わないデバイス（センサー・組み込み機器・車載ECU等）と通信する場合、
AWS IoT Greengrassがゲートウェイとして機能し、IP世界とIP以外の世界を橋渡しする。

AWS IoT Core（クラウド側）
    ↕ MQTT over TLS（IPネットワーク）
AWS IoT Greengrass（エッジゲートウェイ）
    ↕ 各種IP以外のプロトコル（ローカル）
デバイス

ローカル側プロトコル	分類	対応方法
Modbus RTU（RS-485）	C-2-d	Greengrassコンポーネントでブリッジ
BLE / Bluetooth	C-2-a	Greengrass + BLEアダプター
Zigbee	C-2-a	Greengrass + Zigbeeゲートウェイコンポーネント
CAN bus	C-2-b	Greengrass + CANアダプター（産業・車載向け）
I2C / SPI / UART	C-2-c	Greengrassのローカルコンポーネントで直接制御

Greengrassはクラウドとの通信にMQTT（IP）を使い、ローカルデバイスとはIP以外のプロトコルで話す「通訳」として機能する。
クラウド側からは「すべてMQTTで話せるデバイス群」として見える。

Firewall Manager：入口・出口どちらでもない（管理プレーン）

Firewall Manager自身はトラフィックを通さない。
WAF（入口）・Network Firewall（入口+出口）・Shield・Security Groupのポリシーを、
複数アカウント・複数リージョンにわたって一元管理するための管理ツール。

Firewall Manager（管理プレーン）
    ├─ WAFポリシー             → CloudFront・ALB・API GW に適用（入口）
    ├─ Network Firewallポリシー → 各VPCに適用（入口+出口）
    ├─ Shield Advancedポリシー  → 保護対象リソースを一括登録
    └─ Security Groupポリシー   → EC2・ENIに適用

AWS Organizationsと連携し、新しいアカウントが作成されたときに
自動でポリシーを適用する「強制適用」ができる点が主な利点。

入口の選び方まとめ

やりたいこと	入口の選択
REST APIを公開、Lambdaを呼ぶだけ	HTTP API（API GW）
REST APIを公開、SQSやSNSに直接転送したい	REST API（API GW）
WebSocketを使いたい	ALB または REST API（API GW）
独自プロトコル・TCP/UDP直接	NLB
CDN・キャッシュ・WAFも使いたい	CloudFront + API GW or ALB
カスタムドメインにしたい	Route53 → CloudFront or API GW or ALB
AWSサービスに外部から直接繋ぎたい	直接エンドポイント（AWS署名V4）

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