The resource with logical ID AccessLogsBucket in the src/rpdk/core/data/managed-upload-infrastructure.yaml template that the cloudformation-cli uses to create the CloudFormationManagedUploadInfrastructure stack, is currently described with ExpirationInDays: 3653: thus, assuming the intent is to permanently delete the objects in the logging bucket after 3653 days (that is, 10 years), this will not be the case in this configuration because the bucket is set to have VersioningConfiguration set to Status: Enabled. In this case, objects will be made noncurrent after 10 years, but not deleted; a delete marker will become the current version of these objects after 10 years. More information, see Deleting object versions from a versioning-enabled bucket.
In order to fulfill the assumed intent mentioned above, both logging bucket objects that will be made noncurrent after 10 years and expired object delete markers need to be set to be permanently deleted with additional lifecycle configuration.
The resource with logical ID
AccessLogsBucketin thesrc/rpdk/core/data/managed-upload-infrastructure.yamltemplate that thecloudformation-cliuses to create theCloudFormationManagedUploadInfrastructurestack, is currently described withExpirationInDays: 3653: thus, assuming the intent is to permanently delete the objects in the logging bucket after3653days (that is, 10 years), this will not be the case in this configuration because the bucket is set to haveVersioningConfigurationset toStatus: Enabled. In this case, objects will be made noncurrent after 10 years, but not deleted; a delete marker will become the current version of these objects after 10 years. More information, see Deleting object versions from a versioning-enabled bucket.In order to fulfill the assumed intent mentioned above, both logging bucket objects that will be made noncurrent after 10 years and expired object delete markers need to be set to be permanently deleted with additional lifecycle configuration.