今回は、AWSの通知・メール関連サービスである「SNS（Simple Notification Service）」と「SES（Simple Email Service）」の違いについて、インフラエンジニアの運用視点から解説していきます。
どちらも通知やメール送信に関連するサービスですが、運用における役割が大きく異なります。
この記事を読めば、アラート通知とレポート送信という運用の文脈で、それぞれのサービスを適切に使い分けられるようになります。
運用における位置づけ
インフラ運用の観点から見ると、SNSとSESは以下のように整理できます:
- SNS: 緊急性の高い「アラート通知」に最適 → 異常検知時の即時対応
- SES: 定期的な「レポート送信」や「ビジネスメール」に最適 → 情報共有と記録
この違いを理解することで、監視システムの構築や運用フローの設計がスムーズになります。
Amazon SNS（Simple Notification Service）とは
Amazon SNSは、AWSが提供するフルマネージド型のメッセージング・通知サービスです。主にシステム監視とアラート通知に使用され、異常が発生した際に即座に担当者へ通知する役割を担います。
SNSの主な特徴（運用視点）
SNSは以下のような運用上の特徴を持っています:
- 即時通知: リアルタイムでアラートを配信し、迅速な障害対応を実現
- 複数チャネル対応: メール、SMS、Slackなど、複数の方法で同時通知が可能
- CloudWatch連携: CPU使用率、ディスク容量、ネットワーク異常などを自動検知して通知
- シンプルな設定: 複雑な設定不要で、すぐにアラート通知システムを構築可能
SNSの運用における使用例
SNSは主に以下のような運用シーンで使用されます:
- 障害アラート: EC2インスタンスのダウン検知時にメールとSMSで緊急通知
- リソース監視: CPU使用率が閾値を超えた際の警告通知
- セキュリティアラート: 不正アクセス検知時の即座な通知
- ディスク容量警告: ストレージ使用率が80%を超えた際のアラート
- バックアップ失敗通知: 自動バックアップが失敗した際の即時通知
これらは全て「今すぐ対応が必要」な異常検知通知であり、担当者が即座に状況を把握して対処する必要があるケースです。
Amazon SES（Simple Email Service）とは
Amazon SESは、AWSが提供する高機能なメール送信サービスです。主に定期レポートの送信やビジネスメールの配信に使用され、運用状況の共有や記録を目的とします。
SESの主な特徴（運用視点）
SESは以下のような運用上の特徴を持っています:
- 大量メール送信: 数千件の日次レポートや週次レポートを効率的に配信
- HTMLメール対応: グラフや表を含むリッチな運用レポートを作成可能
- テンプレート機能: 定型フォーマットのレポートを簡単に自動生成
- 高い到達率: SPF/DKIM設定で迷惑メール判定を回避し、確実に届ける
- 送信履歴管理: バウンス（不達）やエラーの詳細な記録と分析が可能
SESの運用における使用例
SESは主に以下のような運用シーンで使用されます:
- 日次運用レポート: システムヘルスチェック結果、リソース使用状況のサマリー
- 週次/月次レポート: インフラ稼働状況、パフォーマンス分析結果の定期報告
- バックアップ完了レポート: 定期バックアップの成功/失敗状況の記録
- ログ分析結果: アクセスログやエラーログの集計結果レポート
- セキュリティレポート: 脆弱性スキャン結果、パッチ適用状況の報告
- ビジネスメール: ECサイトの注文確認、パスワードリセット、メルマガ配信など
これらは「定期的な情報共有」や「記録として残すべき報告」であり、緊急性は低いものの確実に届けて記録する必要があるケースです。
SNSとSESの比較表（運用視点）
両サービスの違いを運用の観点から整理しました:
| 項目 | SNS | SES |
|---|---|---|
| 運用における役割 | アラート通知（緊急対応） | レポート送信（情報共有） |
| 緊急性 | 高（即時対応が必要） | 低〜中（定期報告・記録） |
| 配信タイミング | リアルタイム（異常検知時） | 定期的（日次/週次/月次） |
| メール内容 | シンプルなテキスト通知 | グラフ・表を含むリッチなHTML |
| 配信方法 | SMS、Email、HTTP/HTTPS、Lambda、SQSなど | メール（SMTP、API） |
| 主な用途 | システム監視、障害通知 | 運用レポート、ビジネスメール |
| 想定送信数 | 少量（アラート発生時のみ） | 大量（定期的に多数送信） |
| CloudWatch連携 | 簡単（標準機能） | 可能（Lambda経由など） |
| テンプレート機能 | なし | あり（レポート定型化） |
| 到達率管理 | 基本的な機能 | SPF/DKIM/DMARC対応 |
| 料金（Email） | $2/100,000件 | $0.10/1,000件 |
| 運用例 | CPU使用率80%超過アラート | 日次システム稼働レポート |
運用における使い分けのポイント
実際の運用現場でどのように使い分けるべきか、具体的なシーンで解説します。
SNSを使うべき運用シーン
以下のような「今すぐ対応が必要」な場面ではSNSが適しています:
- 障害・異常の即時検知: サーバーダウン、サービス停止、ネットワーク障害など
- リソース枯渇の警告: CPU、メモリ、ディスク容量が閾値を超えた場合
- セキュリティインシデント: 不正アクセス、DDoS攻撃、異常なログイン試行
- バックアップ失敗: 自動バックアップが失敗した際の緊急通知
- 複数チャネルでの同時通知: メール、SMS、Slackなど、確実に担当者へ届ける必要がある場合
運用ポイント: 夜間や休日でも担当者が即座に気づけるよう、SMSとメールの両方で通知する設定が推奨されます。
SESを使うべき運用シーン
以下のような「定期的な報告・記録」が必要な場面ではSESが適しています:
- 定期運用レポート: 毎日/毎週/毎月のシステム稼働状況レポート
- パフォーマンスレポート: CPU、メモリ、ディスク使用率の推移グラフ付きレポート
- バックアップ状況報告: 成功/失敗の詳細記録を含む定期レポート
- セキュリティ定期報告: 脆弱性スキャン結果、パッチ適用状況のサマリー
- ビジネスメール: ユーザーへの通知メール（注文確認、パスワードリセットなど）
- 大量配信: 複数のステークホルダーへの一斉レポート送信
運用ポイント: HTMLメールでグラフや表を含めることで、視覚的に分かりやすいレポートを作成できます。
実際の運用設定例
運用現場で実際に使用する際の基本的な設定フローをご紹介します。
SNSでアラート通知を設定する手順
CloudWatchと連携したアラート通知の基本設定:
- SNSトピックの作成: 「production-alert」などの名前でトピック作成
- サブスクリプション登録: 担当者のメールアドレスとSMS用電話番号を登録
- CloudWatchアラーム設定: CPU使用率80%超過などの条件を設定
- 通知先にSNSトピック指定: アラーム発生時にSNSトピックへ通知
- 動作確認: テスト通知で正常に受信できるか確認
例えば、「EC2のCPU使用率が80%を超えたら、メールとSMSで即座に通知」といった設定が数分で完了します。
SESで運用レポートを送信する手順
定期レポート配信の基本設定:
- 送信元ドメイン/アドレスの検証: report@example.com などを登録
- サンドボックス解除申請: 本番環境で使用する場合は制限解除を申請
- SPF/DKIM設定: DNSレコードを設定して迷惑メール判定を回避
- レポートテンプレート作成: HTML形式で運用レポートの雛形を作成
- Lambda関数作成: CloudWatch Eventsで定期実行し、SES経由でメール送信
例えば、「毎朝8時にシステム稼働状況レポートをHTML形式で送信」といった自動化が実現できます。
併用する運用パターン
実際の運用では、SNSとSESを併用するケースも多くあります:
パターン1: 監視とレポートの分離
- SNS: CloudWatchアラームからの緊急通知（障害発生時のみ）
- SES: Lambda関数による日次レポート送信（毎日定時）
パターン2: 段階的な通知
- 第1段階（SNS）: 障害検知時に即座にSMSとメールで緊急通知
- 第2段階（SES）: 障害対応完了後、詳細な報告書をHTML形式で関係者へ送信
このように役割を分けることで、緊急性に応じた適切な通知システムが構築できます。
まとめ
SNSとSESは、どちらもAWSの通知・メール関連サービスですが、運用における役割が明確に異なります:
- SNSは、障害やリソース枯渇などの「アラート通知」に最適で、即時対応が必要な異常を検知して担当者へ緊急通知します
- SESは、日次/週次レポートなどの「定期報告」やビジネスメールに最適で、運用状況の記録と共有を目的とします
インフラエンジニアとしては、以下のように整理すると分かりやすいでしょう:
- 今すぐ対応が必要 → SNS（アラート）
- 定期的に報告・記録 → SES（レポート）
適切に使い分けることで、効率的で信頼性の高い運用監視システムを構築できます。まずはSNSでCloudWatchアラームと連携した基本的な監視通知を設定し、その後SESで定期レポート配信を自動化するのが、運用の第一歩としておすすめです。
両サービスとも無料利用枠があるため、実際の運用環境を想定したテスト環境で試してみることをおすすめします。
