How to diagnose Control Tower Landing Zone setup failure due to incorrect bucket policy for logging bucket?

We had the same issue when setting up control tower with KMS encryption enabled. We found the issue to be that AWS Config could not use the KMS key due to the KMS key resource policy being set up wrong by us when creating the key. When using the policy documented for AWS Config our issue was that we did not use the correct account as the sourceAccountID. We typed in the controltower account id, but what fixed it for us was changing that to the Log Archive account id.

KMS key policy granting config access to the key (cloudtrail also needs access as described in the control tower doc)

{
    "Id": "Policy_ID",
    "Statement": [
        {
            "Sid": "AWSConfigKMSPolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "config.amazonaws.com"
            },
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": "<myKMSKeyARN>",
            "Condition": { 
                "StringEquals": {
                    "AWS:SourceAccount": "<myLogArchiveAccountID>"
                }
            }
        }
    ]
}

It sounds like you have encountered an issue with the bucket policy for the logging bucket during the setup of your Control Tower Landing Zone. Here are a few things you can try to diagnose and resolve the issue:

Review the bucket policy: Check the bucket policy for the logging bucket, "aws-controltower-logs-1111111111111-us-west-2", to see if it is incorrect or if there are any issues with the permissions. Verify that the policy allows the necessary permissions for Control Tower to write logs to the bucket.

Check the IAM roles: Verify that the IAM roles used by Control Tower have the necessary permissions to access the logging bucket.

Check the stack set: Review the CloudFormation stack set used by Control Tower to see if there are any issues with the parameters or settings. This can be done in the AWS Systems Manager, under the “StackSets” page.

Check the CloudTrail: Check if there are any CloudTrail logs that might provide more information on the failure, specifically the Control Tower Management Events.

Contact AWS Support: If you are unable to diagnose and resolve the issue, you may want to contact AWS Support for further assistance.

It's important to note that Control Tower is designed to create the necessary resources and policies automatically during the setup process, but in some cases, issues may occur that prevent the setup from completing successfully. If you find out that it's a bug in the Control Tower, please contact AWS Support with the details of the issue, so they can investigate and fix the problem.

I am having the same issue.

I had a similar issue when upgrading from Control Tower 2.9 to 3.1. Just selecting the KMS key encryption option caused the update to fail. (I selected an existing key thinking Control Tower had obviously created it for this purpose as it had alias of "ControlTowerV3"). Unselecting the option enabled the update to work but leaves me without customer-managed KMS key encryption for now and will check with support if I should be getting Control Tower to create a new key or if I should amend the policy on the existing key...

Hi, I just got this working after enabling encryption to the AWS Control Tower update.

{
            "Sid": "AWSConfigCloudTrailKMSPolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": ["config.amazonaws.com", "cloudtrail.amazonaws.com"]
            },
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": "<KMS_ARN>"
 }

Check this for more fine-grained permissions