Cloudformation-coverage-roadmap: AWS::RDS::DBCluster with it's associated AWS::Logs::LogGroup error

[yvele]

This is not specifically about a new attribute or a new option to support. So the issue temple does not feat really well in this case.

When creating a new AWS::RDS::DBCluster the cluster immediately starts logging in /aws/rds/cluster/${DBCluster}/error and then it is impossible to explicitly create the AWS::Logs::LogGroup in the CloudFormation template as the resource exists as soon as the DBCluster is created.

Here is an example that fails with this error:

CREATE_FAILED /aws/rds/cluster/apviz-api-sql-test-dbcluster-xxxxx/error already exists

  DBCluster:
    Type: AWS::RDS::DBCluster
    Properties:
      DatabaseName: foo
      Engine        : aurora
      EngineMode    : serverless
      EngineVersion : 5.6.10a

  DBClusterLogGroupError:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/rds/cluster/${DBCluster}/error
      RetentionInDays: 90

As you can see in order to create the log group, I need the DB cluster name... but the DB cluster will create the log group implicitly before I can create it explicitly using AWS::Logs::LogGroup.

Is there a workaround?

Or should we think about a new CloudFormation feature? Something like a way to "upsert" a AWS::Logs::LogGroup resource? Not failing if the log group already exists but update it. I'm not sure that's a good idea. 🤔

Or maybe a new resource that sets the default properties of any AWS::Logs::LogGroup created with a prefix e.g. /aws/rds/cluster/* 👍

For example we could have:

  LogGroupDefaultProperties:
    Type: AWS::Logs::LogGroupDefaultProperties
    Properties:
      LogGroupPattern: /aws/rds/cluster/*/error
      RetentionInDays: 90

Edit: Maybe it's much more of a AWS::Logs::LogGroup issue

[georgej-github]

I have not been able to reproduce this error, I was able to create rds log groups with CloudFormation for both serverless/provisioned. Has this issue perhaps been (silently) resolved, or is it perhaps a race condition between CFN/RDS that might be producing unpredictable behaviour ?

[schuch]

I ran into this today.

Having an Aurora MySQL database with audit logs enabled, I am unable to update my existing CFN stack with an AWS::Logs::LogGroup to specify a log retention period as infrastructure as code.

I think a nice solution would be to give AWS::RDS::DBCluster an explicit attribute for referencing an AWS::Logs::LogGroup instead of defining the log group name implicitly.