No wonder Ryan had issues with this one!
Firstly, as the guys have already noted: when creating the Alarm Threshold at 04:20 in the video, the "whenever" should be set to set to >0 (or >= 1).
Secondly, partly because the metric is being measured over a 5 minute interval rather than a shorter one, and partly I guess due to propagation delays from action to CloudTrail to CloudWatch, the alarm can take a LONG time to trigger.
I performed multiple logouts and logins as root, and it took between 5 minutes and 20 minutes for me to see the alarm status change, then another minute for the email to come through to my GMail.
Once I literally logged in as root, went out and made myself a toasted cheese sandwich, came back, sat down, clicked refresh a couple of times and finally saw the alarm state change (and email shortly after).
I’m currently sitting in front of the CloudWatch logs console with filter {$.userIdentity.type = "Root"} applied and I can see the following log entry:
{
"eventVersion": "1.05",
"userIdentity": {
"type": "Root",
"principalId": "393768429082",
"arn": "arn:aws:iam::393768429082:root",
"accountId": "393768429082",
"accessKeyId": ""
},
"eventTime": "2020-08-18T02:10:05Z",
"eventSource": "signin.amazonaws.com",
"eventName": "ConsoleLogin",
"awsRegion": "us-east-1",
"sourceIPAddress": "165.225.227.60",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36",
"requestParameters": null,
"responseElements": {
"ConsoleLogin": "Success"
},
"additionalEventData": {
"LoginTo": "https://console.aws.amazon.com/console/home?state=hashArgs%23&isauthcode=true",
"MobileVersion": "No",
"MFAUsed": "Yes"
},
"eventID": "34832c9d-8981-4b5e-9507-4d5c48a28ef3",
"eventType": "AwsConsoleSignIn",
"recipientAccountId": "393768429082"
}
The only problem? The timestamp on the log entry is 2020-08-18T12:22:13.588+10:00 – that’s 12 minutes after the event occurred!