どーも！shihopowerです！
AWS SAP（Solutions Architect Professional）の対策をしていると、こんな問題に出会いました。
「GitサーバーのWebhookをAWSサーバーレスアーキテクチャに移行したい」
「Webhookってそもそも何？」 という状態だったので、基礎から調べ直し、AWSサービスとの関連性までまとめました。同じく「Webhookよくわからない」というSAP受験者の方の参考になれば嬉しいです！
目次
1. Webhookとは何か
通常のAPI（ポーリング）との違い
Webhookを理解するには、まず通常のAPIとの違いを押さえることが重要です。
通常のAPI（ポーリング方式）
クライアント →「何か変化ありましたか？」→ サーバー
クライアント ←「まだ何もないです」← サーバー
（これを定期的に繰り返す）
Webhook（イベント駆動方式）
サーバー →「イベント発生したよ！」→ 指定されたURL
（発生したときだけ通知）
| 比較項目 | 通常のAPI（ポーリング） | Webhook |
|---|---|---|
| 通信の開始 | クライアント側から | サーバー側から |
| 通信のタイミング | 定期的・常時 | イベント発生時のみ |
| 無駄なリクエスト | 多い | なし |
| リアルタイム性 | 低い | 高い |
具体的なユースケース
Webhookは「あるシステムでイベントが発生したとき、別のシステムへ自動通知したい」という場面で広く使われています。
代表的な例を挙げます。
- Gitサーバー：コードのPushやPull Requestが作成されたとき、CIツールへ通知
- ECサイト：決済が完了したとき、在庫管理システムへ通知
- 監視ツール：アラートが発生したとき、SlackやPagerDutyへ通知
今回のSAP問題では「GitサーバーでコードPushなどのイベントが発生したとき、AWS側の処理を自動で呼び出す」という使い方をしています。
WebhookはHTTPSを使う
Webhookは「HTTPリクエストを送信する」と説明されることが多いですが、実際の通信は HTTPS（HTTP + TLS暗号化） です。
| プロトコル | 説明 |
|---|---|
| HTTP | 通信プロトコルの総称（広義）。暗号化なし |
| HTTPS | HTTPにTLS暗号化を加えたもの。Webhookで使われるのはこちら |
AWSのエンドポイントはすべてHTTPSです。「HTTPリクエスト」という表現は広義では間違いではありませんが、実際にはHTTPSリクエストと理解しておきましょう。
2. WebhookのリクエストをHTTPSで受信できるAWSサービス一覧
GitサーバーなどがWebhookを送る場合、AWS側で「受け口（エンドポイント）」となるサービスが必要です。代表的なものを紹介します。
① ALB（Application Load Balancer）
Git サーバー ──HTTPS──▶ ALB ──▶ EC2 / コンテナ など
ロードバランサーとして機能し、背後のEC2インスタンスやコンテナへリクエストを振り分けます。今回のSAP問題の**移行前（既存構成）**がこのパターンです。バックエンドのサーバー管理が必要なため、運用オーバーヘッドが発生します。
② Amazon API Gateway
Git サーバー ──HTTPS──▶ API Gateway ──▶ Lambda など
APIのエンドポイントを提供するマネージドサービスです。デフォルトのエンドポイントURLは以下の形式で自動生成されます。
https://{api-id}.execute-api.{region}.amazonaws.com/{stage}/
複数のWebhookを単一エンドポイントで受け付け、パスやHTTPメソッドによってルーティングできます。認証・監視・スロットリングなど豊富な機能を備えています。
③ AWS Lambda 関数URL
Git サーバー ──HTTPS──▶ Lambda 関数URL ──▶ Lambda
Lambda関数に直接HTTPSエンドポイントを付与する機能です。API Gatewayを介さず、Lambda関数に直接リクエストを送れます。エンドポイントURLは以下の形式で自動生成されます。
https://{url-id}.lambda-url.{region}.on.aws/
シンプルな構成ですが、認証・ルーティング・スロットリングなどの高度な機能はAPI Gatewayと比べると限定的です。
④ AWS App Runner
Git サーバー ──HTTPS──▶ ALB ──▶ App Runner（コンテナ）
コンテナ化されたアプリケーションをHTTPSエンドポイントで公開できます。ただしコンテナのライフサイクル管理が必要なため、完全サーバーレスとはなりません。
⑤ Amazon ECS / AWS Fargate
Git サーバー ──HTTPS──▶ API Gateway / ALB ──▶ ECS / Fargate（コンテナ）
コンテナオーケストレーションサービスです。柔軟性は高いですが、ECSクラスター・タスク定義・コンテナ管理など構成要素が多く、運用オーバーヘッドが最も大きくなります。
3. 完全サーバーレスでWebhookを受け付ける2択
上記の中でサーバー管理が一切不要なのは、以下の2つです。
選択肢① API Gateway ＋ Lambda
Git サーバー
│
│ HTTPS POST
▼
Amazon API Gateway（単一エンドポイント）
├─ /webhook/push ──▶ Lambda 関数A
├─ /webhook/pr ──▶ Lambda 関数B
└─ /webhook/tag ──▶ Lambda 関数C
特徴：
- 複数のWebhookを単一エンドポイントで一元管理
- パスやメソッドでLambda関数にルーティング
- 認証・ログ・スロットリング・WAF連携など豊富な機能
- Webhookが増えてもGitサーバー側の設定変更不要
選択肢② Lambda 関数URL 単体
Git サーバー
├─ URL-A ──▶ Lambda 関数A（Webhook A用）
├─ URL-B ──▶ Lambda 関数B（Webhook B用）
└─ URL-C ──▶ Lambda 関数C（Webhook C用）
特徴：
- API Gatewayなしで直接Lambdaを呼び出せる
- 設定がシンプルで素早くデプロイ可能
- Webhookが増えるとGitサーバーへのURL登録が都度必要
- 認証・監視を各関数に個別設定する必要あり
2つの使い分け基準
| 比較項目 | API Gateway ＋ Lambda | Lambda 関数URL |
|---|---|---|
| Webhookの数 | 複数・今後増える予定 | 単一または少数で固定 |
| 管理の一元化 | ◎ 単一エンドポイント | △ URLが分散 |
| 高度な認証・制御 | ◎ 豊富な機能 | △ IAMのみ |
| シンプルさ | △ 設定項目が多い | ◎ すぐ動く |
| コスト | やや高め | 低め |
判断の目安：
- Webhookが複数あり、今後も増える可能性がある → API Gateway ＋ Lambda
- Webhookが1つでシンプルに済ませたい → Lambda 関数URL
4. まとめ
WebhookのリクエストをHTTPSで受信できるAWSサービスをまとめると以下のとおりです。
| サービス | サーバー管理 | 複数Webhook管理 | 特徴 |
|---|---|---|---|
| ALB | 必要 | △ | 既存構成に多い。背後にEC2等が必要 |
| API Gateway | 不要 | ◎ | 単一エンドポイントで一元管理。機能豊富 |
| Lambda 関数URL | 不要 | △ | シンプルで素早い。単一Webhookに最適 |
| App Runner | 一部必要 | △ | コンテナ管理あり |
| ECS / Fargate | 一部必要 | △ | 最も柔軟だが構成が複雑 |
完全サーバーレスでWebhookを受け付けるなら、API GatewayかLambda 関数URLの2択です。
複数のWebhookを管理するならAPI Gateway＋Lambda、シンプルに1つだけならLambda関数URLを選ぶとよいでしょう。
AWS SAPの対策をしていると、こういった「サービスの選択理由」を問われる問題が多く出てきます。単に正解を覚えるのではなく、各サービスの特性と使い分けの基準を理解しておくと、応用が利いて本番でも対応できると思います！
最後まで読んでいただきありがとうございました。参考になれば嬉しいです！