Passer au contenu

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.

1 réponse
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
EXPERT

répondu il y a 2 ans

  • 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.

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.