Alert on 5 bastion failed logins in 5 minutes via CloudWatch metric-filter alarm and SNS message filtering
Short answer
C CloudWatch agent, failed-login metric-filter alarm, and SNS message filtering to the assigned admin, with no EventBridge needed.
Question
Key Takeaways
CloudWatch metric filters convert log patterns into CloudWatch metrics that an alarm can threshold (5 in 5 minutes). SNS message filtering routes the notification to the correct subscriber based on message attributes (e.g., the bastion host identifier), satisfying the per-host admin requirement without EventBridge. EventBridge is unnecessary when a CloudWatch alarm already delivers to SNS.
The company needs native notification when a bastion host sees 5 failed authentication attempts within 5 minutes, routed only to the administrator assigned to that host. The CloudWatch agent ships the OS auth logs to CloudWatch Logs; a metric filter counts failed login attempts and a CloudWatch alarm triggers at the threshold, sending to an SNS topic that uses subscription message filtering so only the designated admin (matched by a bastion-host attribute) receives the alert.
Common mistake: Adding EventBridge between the metric filter and the alarm (option A); CloudWatch alarms deliver directly to SNS, so EventBridge is redundant. Or relying on SSM Agent/Run Command (options B/D) to collect logs—the CloudWatch agent is the native log-collection path for this pattern.
Expert Analysis
Why the Answer Is Correct
The CloudWatch agent forwards the bastion's OS logs to CloudWatch Logs. A metric filter tallies failed login attempts and a CloudWatch alarm fires when 5 occur in 5 minutes, notifying an SNS topic. SNS message filtering scopes delivery to the subscriber associated with that specific bastion host, meeting the designated-admin requirement natively and simply.
Why the Other Options Are Wrong
A inserts EventBridge between the metric filter and the alarm; CloudWatch alarms already notify SNS directly, so EventBridge adds no value. B and D use the SSM Agent and Run Command document to configure logging, which is a heavier path than the CloudWatch agent for log collection, and the decisive per-host routing is better done with SNS filtering than instance tags. C is the streamlined native solution.
Community Comment Notes
Community favored C (57 votes). Commenters noted no EventBridge is needed—metric filter plus CloudWatch alarm to SNS suffices, and SNS message filtering controls recipient. A minority picked A for tag-based routing, but C's SNS filtering is simpler and meets the per-host requirement.
Official Reference
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CountingFindingLogs.html
This link opens the official vendor documentation in a new tab.
Community Votes
66% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 7 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 7
-
IPLogic 👍 1 Answered CCloudWatch Agent and Logs: The Amazon CloudWatch agent is configured to collect operating system logs, making it an ideal choice for monitoring failed login attempts. CloudWatch Alarm and Metric Filter: Creating a CloudWatch alarm based on a metric filter for failed login attempts ensures that you can set up precise conditions, such as 5 failed attempts within a 5-minute period. SNS and Messaging Filters: Amazon SNS is used to send alerts when the threshold is exceeded. SNS messaging filters can be used to control who receives notifications, ensuring that only the designated system administrator for the specific bastion host is notified. Option A includes using EventBridge to configure the alarm, which is an additional layer that isn't necessary for this specific requirement.
-
Pmktechno 👍 1 Answered AAmazon CloudWatch agent can collect operating system logs, including login attempts. Amazon EventBridge can be used to create rules that trigger alarms based on specific patterns in the logs, such as failed login attempts. Amazon SNS can send notifications when the alarm threshold is exceeded. Using EC2 instance tags allows you to direct notifications to the appropriate SNS topics, ensuring that only the designated system administrator for the specific bastion host receives the alerts. This solution leverages native AWS services effectively and minimizes operational overhead by automating the detection and notification process.
-
phmeeeee 👍 1 Answered CC - Retreiving the logs and send it to CloudWatch -> Create metrics filter -> Send alarm when over threshold -> SNS to designated system administrator. A - We are no need EventBridge to send the event based on cloudwatch metrics filter. B&D - is allow you to manage the EC2 instance like patch or automation and not for collect the log or log pasring.
-
723993f 👍 1 Answered Athe difference between A and C is that A uses event bridge and tags that can be referenced to route the request to a different sns topic each time, while C uses a single sns and no eventbridge A is the answer because correct routing is an important aspect in the requirements
-
chang4li 👍 1 Answered D"must notify only the designated system administrator who is assigned to the specific bastion host."
Show 2 more comments
-
k23319 👍 1 Answered CNo need for Eventbridge, use cloudwatch alarms
-
koo_kai 👍 1 Answered CUse metrics filter
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.