🔔 EC2 Auto Scaling SNS通知

レストランの人員管理で理解する！4つの通知イベント完全ガイド

🍽️ レストランの人員管理で例えると超わかりやすい!

Auto Scaling = レストランの自動人員調整システム

お客様が増えたらスタッフを増やし、減ったらスタッフを減らす。
このとき、マネージャー（あなた）に リアルタイムで通知 が届きます。

4つの通知イベント で、スタッフの出勤・退勤状況を完全把握！
成功も失敗も、すべて通知されるので安心です✨

✅
INSTANCE_LAUNCH
autoscaling:EC2_INSTANCE_LAUNCH
インスタンスが正常に起動した
🍽️ レストランのたとえ
「新しいスタッフが無事に出勤しました！」

お客様が増えてきたので、予備のスタッフを呼び出し。
スタッフは無事に到着し、制服に着替えて、準備完了！
すぐにサービスを開始できる状態になりました。
📋 いつ通知される？
• EC2インスタンスが正常に起動
• ヘルスチェックに合格
• Auto Scaling グループに追加完了
• トラフィックを受け取る準備完了
💡 この通知でできること
• 新インスタンスのIPアドレスを記録
• モニタリングツールに自動登録
• Slackに「スケールアウト成功」を通知
• ログ管理システムへの登録
🎯 重要ポイント
良いニュース！ キャパシティが増加しました。
システムが正常に拡張されたことを確認できます。
❌
INSTANCE_LAUNCH_ERROR
autoscaling:EC2_INSTANCE_LAUNCH_ERROR
インスタンスの起動に失敗した
🍽️ レストランのたとえ
「スタッフが出勤できませんでした！」

お客様が増えたので予備スタッフを呼んだけど...
• 体調不良で来れなかった（インスタンス起動失敗）
• 制服が見つからない（AMIの問題）
• 交通手段がない（ネットワークエラー）

⚠️ 人手不足のまま！緊急対応が必要！
📋 いつ通知される？
• EC2インスタンスの起動に失敗
• AMIが見つからない/削除されている
• インスタンスタイプが利用不可
• サブネットに空きIPがない
• IAMロールの権限不足
💡 この通知でできること
• 緊急アラートをPagerDutyに送信
• オンコールエンジニアに即座に通知
• 自動でインシデントチケット作成
• ロールバックの検討開始
🚨 重要ポイント
緊急事態！ 即座の対応が必要です。
キャパシティが予定より少ない状態が続きます。
根本原因を特定し、設定を修正しましょう。
👋
INSTANCE_TERMINATE
autoscaling:EC2_INSTANCE_TERMINATE
インスタンスが正常に終了した
🍽️ レストランのたとえ
「スタッフが無事に退勤しました！」

お客様が減ってきたので、余剰スタッフに退勤指示。
スタッフは引継ぎを完了し、制服を返却して、
きちんと挨拶してから帰宅しました。

次のシフトに備えて、しっかり休んでもらいます。
📋 いつ通知される？
• スケールイン（縮小）が実行された
• インスタンスが正常にシャットダウン
• ELBから正常に切り離された
• リソースが正常に解放された
💡 この通知でできること
• モニタリングツールから削除
• ログを永久保存場所にアーカイブ
• コスト削減を確認・記録
• インベントリ管理システムを更新
🎯 重要ポイント
正常な動作！ スケールインが成功しました。
不要なリソースが適切に削減され、コスト最適化されています。
⚠️
INSTANCE_TERMINATE_ERROR
autoscaling:EC2_INSTANCE_TERMINATE_ERROR
インスタンスの終了に失敗した
🍽️ レストランのたとえ
「スタッフが退勤できませんでした！」

余剰スタッフに退勤指示を出したけど...
• 重要な作業が終わってない（接続が残っている）
• ロッカーの鍵が開かない（終了保護がON）
• 引継ぎが完了してない（ドレイン中）

⚠️ 予定より人員が多いまま！コスト増加！
📋 いつ通知される？
• インスタンスの終了保護がON
• ELBからの切り離しに失敗
• スナップショット作成中
• ライフサイクルフックでタイムアウト
• AWS側のサービス障害
💡 この通知でできること
• インスタンスの状態を手動確認
• 終了保護の設定を確認
• 強制終了の検討
• コスト超過アラートを発行
🚨 重要ポイント
要注意！ 不要なリソースが残り続けます。
予定外のコストが発生する可能性があります。
手動での介入が必要な場合もあります。

📊 通知の流れ - どうやって届く？

⚙️
Auto Scaling
イベント発生
→
📢
Amazon SNS
トピックに配信
→
📧
サブスクライバー
Email/Lambda/SQS
→
👤
あなた
通知を受信

🎬 実際のシナリオで理解しよう

📈 シナリオ1: ランチタイムの急な混雑
1
🍽️ 午前11時: お客様が急増
Webサイトへのアクセスが急増。CPU使用率が70%を超える。
レストラン: ランチタイムでお客様が殺到！
2
⚙️ Auto Scalingが起動
Auto Scalingが負荷を検知し、新しいインスタンスを2台起動することを決定。
レストラン: マネージャーが「スタッフ2名を追加で呼んで！」
3
✅ INSTANCE_LAUNCH 通知
1台目が正常に起動！SNS経由でメール受信。
「i-0abc123が起動しました。ELBに追加されました」
レストラン: 「太郎さんが到着！制服に着替えてサービス開始！」
4
❌ INSTANCE_LAUNCH_ERROR 通知
2台目の起動に失敗！AMIが見つからないエラー。
「i-0def456の起動に失敗しました。ImageId 'ami-xxx' が見つかりません」
レストラン: 「花子さんが来れない！制服が無くなってる！」
→ 緊急対応が必要！
📉 シナリオ2: 深夜の静かな時間
1
🌙 午前2時: お客様が減少
アクセスが大幅に減少。CPU使用率が20%まで低下。
レストラン: 深夜でお客様がほとんどいない。
2
⚙️ スケールイン決定
Auto Scalingが余剰インスタンスを検知し、2台を終了することを決定。
レストラン: 「スタッフ2名、退勤してOKです」
3
👋 INSTANCE_TERMINATE 通知
1台目が正常に終了！SNS経由でメール受信。
「i-0abc123が正常に終了しました」
レストラン: 「太郎さんが引継ぎ完了して退勤しました」
4
⚠️ INSTANCE_TERMINATE_ERROR 通知
2台目の終了に失敗！終了保護がONになっていた。
「i-0def456の終了に失敗。終了保護が有効です」
レストラン: 「花子さんがまだ重要な作業中で帰れない！」
→ コストが増加し続ける！手動確認が必要！

⚖️ 成功通知 vs エラー通知

✅ 成功通知（良いニュース）

INSTANCE_LAUNCH
• システムが正常に拡張された
• キャパシティ増加
• 負荷に対応できる状態
• 🍽️ スタッフが増えた！
INSTANCE_TERMINATE
• 不要なリソースを削減
• コスト最適化達成
• 適切なスケールイン
• 🍽️ 余剰スタッフが減った！

❌ エラー通知（要対応）

INSTANCE_LAUNCH_ERROR
• キャパシティ不足が続く
• パフォーマンス低下のリスク
• 即座の対応が必要
• 🍽️ 人手不足！緊急事態！
INSTANCE_TERMINATE_ERROR
• 不要なリソースが残る
• コスト増加が続く
• 手動介入が必要
• 🍽️ 余剰人員が残ってる！

💼 実際の活用例

📧

メール通知

使い方:
SNSトピックにメールアドレスをサブスクライブ。
全イベントをメールで受信。

こんな人に:
• 小規模チーム
• シンプルな監視
• 手動対応が中心

💬

Slack/Teams連携

使い方:
Lambda関数でSNSメッセージを整形してSlackに投稿。

こんな人に:
• チャットツール中心の運用
• リアルタイムな情報共有
• 複数人での監視

🤖

自動対応システム

使い方:
Lambda関数で自動対応。
• LAUNCH → モニタリング登録
• LAUNCH_ERROR → 再試行
• TERMINATE → ログ保存

こんな人に:
• 大規模運用
• 完全自動化
• 24時間監視

📊

ログ分析・監視

使い方:
SNS → SQS → データ分析基盤
スケーリングパターンを分析。

こんな人に:
• データドリブンな運用
• コスト最適化
• パターン分析

🚨

PagerDuty連携

使い方:
エラー通知だけをPagerDutyに送信。
オンコールエンジニアに即座にエスカレーション。

こんな人に:
• エンタープライズ運用
• 24/7サポート体制
• インシデント管理

📝

チケット自動作成

使い方:
エラー通知をJira/ServiceNowと連携。
自動でインシデントチケット作成。

こんな人に:
• ITIL準拠の運用
• トラッキング重視
• 大規模組織

⚙️ 設定方法

📋 AWS CLIでの設定例 
# 1. SNSトピックを作成
aws sns create-topic --name autoscaling-notifications

# 2. メールアドレスをサブスクライブ
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:autoscaling-notifications \
  --protocol email \
  --notification-endpoint your-email@example.com

# 3. Auto Scaling グループに通知設定を追加
aws autoscaling put-notification-configuration \
  --auto-scaling-group-name my-asg \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:autoscaling-notifications \
  --notification-types \
      "autoscaling:EC2_INSTANCE_LAUNCH" \
      "autoscaling:EC2_INSTANCE_LAUNCH_ERROR" \
      "autoscaling:EC2_INSTANCE_TERMINATE" \
      "autoscaling:EC2_INSTANCE_TERMINATE_ERROR"
📋 CloudFormationでの設定例 
Resources:
  # SNSトピック
  AutoScalingNotificationTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: autoscaling-notifications
      Subscription:
        - Endpoint: your-email@example.com
          Protocol: email

  # Auto Scaling グループ
  MyAutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AutoScalingGroupName: my-asg
      MinSize: 1
      MaxSize: 10
      DesiredCapacity: 2
      NotificationConfigurations:
        - TopicARN: !Ref AutoScalingNotificationTopic
          NotificationTypes:
            - autoscaling:EC2_INSTANCE_LAUNCH
            - autoscaling:EC2_INSTANCE_LAUNCH_ERROR
            - autoscaling:EC2_INSTANCE_TERMINATE
            - autoscaling:EC2_INSTANCE_TERMINATE_ERROR
💡 通知設定のベストプラクティス
1. 最初は全通知を有効にしよう：
まずは4つ全ての通知タイプを有効にして、システムの動きを理解しましょう。
慣れてきたら、必要な通知だけに絞り込むこともできます。

2. エラー通知は必須：
LAUNCH_ERRORとTERMINATE_ERRORは必ず設定してください。
これらは即座の対応が必要な重大イベントです。

3. 通知先を使い分ける：
• 成功通知 → 情報共有用のSlackチャンネル
• エラー通知 → 緊急対応チームのPagerDuty
複数のSNSトピックを使い分けることで、適切な通知ルーティングができます。

4. Lambda関数で通知を整形：
SNSからの生メッセージは読みにくいので、Lambda関数で整形すると便利です。
• インスタンスID
• 発生時刻
• エラー理由
• 推奨アクション
これらを見やすくフォーマットして通知しましょう。

5. 通知の重複に注意：
複数のAuto Scaling グループが同じSNSトピックを使う場合、
どのASGからの通知か分かるように、グループ名を明確にしましょう。

6. テストを忘れずに：
設定後は必ず手動でスケールアウト/インを実行して、
通知が正しく届くことを確認しましょう！

🎓 まとめ

🍽️ レストランの人員管理 = Auto Scaling通知

スタッフの出勤・退勤をリアルタイムで把握するように、
EC2インスタンスの起動・終了を即座に知ることができます

✅
LAUNCH

新スタッフ出勤
キャパシティ増加
良いニュース！
❌
LAUNCH_ERROR

スタッフ来れず
人手不足継続
緊急対応必要！
👋
TERMINATE

スタッフ退勤
コスト最適化
正常な動作！
⚠️
TERMINATE_ERROR

退勤できず
コスト増加
手動確認必要！

🎯 重要なポイント：

✅ 成功通知 = 情報共有・記録用
❌ エラー通知 = 即座の対応が必要

エラー通知は必ず見逃さないように、
適切なアラートシステムに連携させましょう！

Auto Scaling通知を適切に設定することで、
システムの健全性を常に把握 し、
問題に素早く対応 できるようになります！🎉

Created by SSuzuki1063

AWS SAP Learning Resources