ある CloudOps エンジニアは、Amazon CloudWatch アラームの通知を Amazon SNS トピックから社内の HTTPS エンドポイントへ送っています。エンドポイントが応答しない間の通知が失われることがあります。 届かなかった通知を後から取り出せるように保持し、配信の失敗には運用チームが気付けるようにする必要があります。 これらの要件を満たすステップの組み合わせはどれですか。(2 つ選択)
配信できなかった SNS の通知を残し、配信の失敗をアラームで知らせる
HTTPS のサブスクリプションに、Amazon SQS キューをデッドレターキューとして設定する。
Amazon SNS のデッドレターキューは、配信できなかったメッセージを Amazon SQS キューに残す機能です。エンドポイントへの配信の再試行を使い切ったメッセージがキューに移されるので、エンドポイントの復旧後に取り出して再処理できます。
デッドレターキューはトピックではなくサブスクリプションに付け、再処理ポリシー (redrive policy) で退避先のキューを指定します。
AWS CloudTrail の証跡で Amazon SNS のデータイベントを記録し、トピックへの Publish の呼び出しを残す。
CloudTrail は、ユーザー・ロール・AWS のサービスが行った API の呼び出しを記録するサービスです。Amazon SNS では Publish と PublishBatch をデータイベントとして記録できるので、通知がいつトピックに発行されたかは残ります。
しかし記録されるのは発行の呼び出しで、トピックからエンドポイントへの配信が届いたかどうかは分かりません。記録の中のメッセージの本文も伏せられるため、届かなかった通知を後から取り出す用途にも使えません。
AWS Health Dashboard で、社内の HTTPS エンドポイントの障害を知らせるイベントを確認する。
AWS Health は、AWS のサービスとアカウント、AWS のリソースの状態の変化をイベントとして知らせるサービスです。AWS 側の障害や予定されたメンテナンスが、自分のアプリケーションに影響するかを確かめるときに使います。
しかし社内の HTTPS エンドポイントは AWS のリソースではないので、その障害はイベントになりません。また AWS Health は Amazon SNS の通知を保管しないため、届かなかった通知を後から取り出すこともできません。
Amazon SNS の配信に失敗した通知の数のメトリクスに、Amazon CloudWatch アラームを作成する。
Amazon SNS はトピックのメトリクスを Amazon CloudWatch に送ります。NumberOfNotificationsFailed は SNS が配信に失敗したメッセージの数で、HTTPS のエンドポイントでは再試行を含む失敗した配信の試行が数えられます。
このメトリクスに Amazon CloudWatch アラームを置けば、エンドポイントが応答せず配信が失敗した時点で運用チームに知らせられます。
AWS Config のマネージドルールで、Amazon SNS トピックの設定を継続的に評価する。
AWS Config は、AWS のリソースの設定を記録し、ルールで評価するサービスです。SNS トピックの暗号化などの設定が社内の基準に合っているかを確かめるときに使います。
しかし評価の対象はリソースの設定で、個々のメッセージの配信の成否は扱いません。届かなかった通知を残すことも、配信の失敗が起きたことを知らせることもできません。
Amazon SNS の「届かなかった通知」は、保全と検知を別のサービスで受け持ちます。
・保全は Amazon SQS のデッドレターキューで行います。サブスクリプションに設定すると、再試行を使い切った通知がキューに残り、後から取り出せます。
・検知は Amazon CloudWatch のアラームで行います。Amazon SNS は配信に失敗したメッセージの数を NumberOfNotificationsFailed メトリクスとして CloudWatch に送ります。
・AWS Config はリソースの設定を記録し、ルールで評価するサービスで、メッセージの配信は扱いません。
・AWS CloudTrail は API の呼び出しを記録するサービスで、SNS では Publish をデータイベントとして記録できますが、配信の成否は残りません。
・AWS Health は AWS のサービス・アカウント・リソースの状態の変化を知らせるサービスで、社内のシステムの障害は扱いません。