CloudWatch anomaly detection via CloudFormation - "Invalid request provided"
0
I've been trying to set up log anomaly detection via Infrastructure as Code using CloudFormation. I'm getting an error when trying to deploy:
Resource handler returned message: "Invalid request provided: AWS::Logs::LogAnomalyDetector" (RequestToken: df2f2a83-49c7-d6e8-0b1e-a441e8230606, HandlerErrorCode: InvalidRequest)
In CloudTrail, the error shown is InvalidParameterException.
Below is my YAML code:
CloudTrailLogAnomalyDetector:
Type: AWS::Logs::LogAnomalyDetector
Properties:
DetectorName: "abnormal-login-patterns"
EvaluationFrequency: ONE_HOUR
FilterPattern: '{$.errorMessage = "Failed authentication" }'
LogGroupArnList:
- !GetAtt CloudTrailLogGroup.Arn
I believe there is something wrong with the FilterPattern value, but I couldn't find other examples. Apologies if this might be an obvious mistake.
- Language
- English
asked a year ago147 views
1 Answer
- Newest
- Most votes
- Most comments
0
Hello.
I was able to deploy it using the CloudFormation template below in my AWS account.
So I don't think "FilterPattern" is the problem.
Is the ARN obtained with "!GetAtt CloudTrailLogGroup.Arn" correct?
Is it possible for you to share the settings for "CloudTrailLogGroup"?
AWSTemplateFormatVersion: "2010-09-09"
Description: CloudWatch Logs Anomaly Detector
Resources:
CloudTrailLogGroup:
Type: AWS::Logs::LogGroup
Properties:
LogGroupName: my-log-group
CloudTrailLogAnomalyDetector:
Type: AWS::Logs::LogAnomalyDetector
Properties:
DetectorName: "abnormal-login-patterns"
EvaluationFrequency: ONE_HOUR
FilterPattern: '{$.errorMessage = "Failed authentication" }'
LogGroupArnList:
- !GetAtt CloudTrailLogGroup.Arn
Relevant content
asked 5 years ago
asked 2 years ago
asked 2 years ago
Hi Riku, thanks for your reply. This is the setting for CloudTrailLogGroup. The indentation is correctly, but I don't think I can format the comment.
CloudTrailLogGroup: Type: "AWS::Logs::LogGroup" Properties: LogGroupName: "/cloudtrail/logs" RetentionInDays: 90
It looks like the content you've shared is OK. Could you please share the entire CloudFormation? By the way, what kind of permissions are set for the IAM user you are using? Because CloudFormation creates AWS resources on your behalf, it may overwrite the actual error message with a different error message. Therefore, the request may be displayed as an invalid request (InvalidRequest) even though the request actually failed due to insufficient privileges of the IAM user (AccessDeniedException).
Hi Riku, This is part of a huge infrastructure, so I can't share the whole thing, but I should be able to share the two most relevant files via OneDrive link: https://1drv.ms/u/c/fa78a277efe35e5b/EbwDkm0tlshJlKG5A0UVWlUBr6Sp1sIwxnh4PWkJbRqUEw?e=6GK4pT
I've noticed something weird: the log anomaly detection DOES in fact get created, even if CloudFormation fails. However, if I try to remove it from the template and re-deploy, the workflow succeeds but the log anomaly detection is still there unaffected. I guess it's because CloudFormation fails so it doesnt think it's there.
Right, I've just tried redeploying the exact same template, no changes, and it worked fine. This is frustrating, because I have no idea what the issue was, therefore I can't fix it if it happens again... No idea. Thank you for your help, Riku.