Hibrit uygulamalar hem şirket içinde hem de AWS'de kaynakları kullanır. Kullanıcılar bazen uygulamaların kullanılamadığını bildirmektedir. Bir CloudWatch alarmı zaten Site-to-Site VPN tünel durumunu izlemektedir. Operasyon ekibinin, VPN tüneli çöktüğünde dahili bir biletleme sisteminde otomatik olarak yüksek öncelikli biletler oluşturulmasına ihtiyacı vardır. Hangi tasarım bu ihtiyacı karşılar?

Doğru cevap, CloudWatch alarmı için bir Amazon SNS topic oluşturup biletleme sisteminin endpoint'ini bu SNS topic'e abone yapmaktır. CloudWatch alarmları, durum değişikliklerinde SNS topic'lerine bildirim gönderebilir. Biletleme sistemi, SNS topic'e abone olarak bu bildirimleri doğrudan alabilir ve otomatik olarak yüksek öncelikli biletler oluşturabilir. Bu, mevcut CloudWatch alarmını kullanarak hızlı ve verimli bir entegrasyon sağlar. Diğer seçenekler neden yanlış: SQS kuyruğu kullanmak, mesajların işlenmesi için ek bir bileşen (örneğin, bir Lambda işlevi) gerektireceğinden gereksiz karmaşıklık yaratır. SQS, mesajları depolamak için tasarlanmıştır, doğrudan bilet oluşturmak için değil. CloudWatch alarmının doğrudan bir Lambda işlevini çağırması mümkün değildir. CloudWatch alarmları genellikle SNS topic'leri aracılığıyla veya EventBridge kuralları üzerinden Lambda işlevlerini tetikler. EventBridge kuralı oluşturmak, VPN tünel sağlığını doğrudan izlemek için ek bir yapılandırma gerektirir ve mevcut CloudWatch alarmının zaten bu izlemeyi yaptığı belirtilmiştir. SNS topic, mevcut alarmı kullanmanın en doğrudan yoludur.