AWSサービスとプロトコルの対応
以下記事後半のAWSに関する実用的部分だけ再掲して記事にしました。
入口（イングレス）：プロトコルと対応サービス
入口サービスはプロトコルを「理解して処理」する必要があるため、対応プロトコルが限定される。
どの入口を選ぶかが、受け付けられるプロトコルを決める。
| プロトコル分類 | 対応する入口サービス | 備考 |
|---|---|---|
| REST / GraphQL（A-1-①） | CloudFront・API GW・ALB | 最も一般的な構成 |
|
非同期メッセージング（A-1-②） SQS / SNS / EventBridge |
直接エンドポイント（AWS署名V4） API GW（REST API）経由も可 |
CloudFrontのオリジンにはできない 直接エンドポイントはカスタムドメイン不可だが、API GW経由ならカスタムドメイン割り当て可能 |
| SSE（A-1-③） | CloudFront・API GW・ALB | HTTP接続を維持するだけなので特別な対応不要 |
| WebSocket（A-2） | ALB・API GW（REST 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等）
NLBにはWAFを付けられない点に注意。
NLB経由でWebSocket・gRPC・独自プロトコルを受け付ける構成では、
L7のリクエスト検査ができないため、アプリケーション側でのバリデーションが重要になる。
出口（イグレス）：基本的にプロトコル不問
出口インフラ（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 | ドメイン名・プロトコル・シグネチャでフィルタ。ステートフルなルールが書ける |
例外：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以外のプロトコル（ローカル）
デバイス
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） |