Skip to content

Control Tower Issues Are they common?

0

Hello,

We have recently setup our Landingzone via control tower and I was wondering if it is common to run into the following issues:

  1. When we first attempted to created the LZ it failed becuase the log-archive account did not have access to the S3 bucket to be able to perform loggin operations? I fixed this by disabling logging, initially and once it created the LZ I went back and enabled logging --> worked perfect 2.Noticed that Account factory was having issues in that it could not find a "Landing Path" --> Fixed this by performing an update on the LZ without any changes (Maybe a drift occurred?)
  2. Went into Cloud Trails and noticed that I was getting permission denied in the log-archive account in the S3 Bucket where the logs were stored and that Trails were no longer logging. I fixed this by moving the log-archive account into a Break Glass OU then went back and "selected fix bucket policy" Once this was done tails started logging again. I moved the log-archive account from the BG ou back our Security OU, but now we have drift because the SCP policy on the bucket is different then what the current S3 bucket policy is. Is it normal to have to up date the SCP because CT is to restrictive?

asked a year ago362 views

2 Answers
0

Yes, the issues you're encountering with AWS Control Tower are relatively common challenges that many organizations face during setup and maintenance of their landing zones.

For your first issue with the log-archive account lacking S3 access permissions, this is a known problem. When configuring Control Tower landing zone, S3 buckets like "aws-controltower-logs-" and "aws-controltower-s3-access-logs-" are created in the log archive account. Your workaround of temporarily disabling logging and then re-enabling it is a valid approach to resolve this permission issue.

Regarding the "no launch paths found" error with Account Factory, this is often related to governance drift in AWS Control Tower. Drift occurs when changes are made outside of Control Tower that affect its managed resources. Your solution of updating the landing zone without changes is a correct approach to resynchronize Control Tower with the current state of your AWS organization.

The permission denied errors in CloudTrail and S3 bucket policy issues are also common. AWS Control Tower implements strict security controls by default, and sometimes these controls can be too restrictive for certain operational needs. Moving the account to a different OU temporarily to fix the bucket policy is a creative workaround. The drift you're experiencing now is expected since you've modified resources that Control Tower manages.

It's not uncommon to need to adjust SCPs (Service Control Policies) when Control Tower's default policies are too restrictive for your specific use cases. Many organizations find they need to customize these policies to balance security requirements with operational needs.

To resolve the current drift, you might need to re-register the OU or update the landing zone. For ongoing management, consider planning your Control Tower implementation with these potential issues in mind, and establish processes for handling drift when it occurs.
Sources
Troubleshooting - AWS Control Tower
Control Tower Fails by S3 access | AWS re:Post
Control Tower set up landing zone problem | AWS re:Post
Types of governance drift - AWS Control Tower

answered a year ago

AWS
EXPERT

reviewed 9 months ago

0

Aside from the questions what I did so far to resolve is the following:

  1. Account factory could not find the "Landing Path" I simply updated control tower (No actual updates) but typically done to correct dirift. This fixed our account factory problem.
  2. For Cloud Trails not being able to log to the Control S3 bucket, I simply created a break glass OU (No SCP's applied) moved our log-archive account this ou. Switched to the log-archive user, navigated to the s3 bucket and selected the "Fix Bucket policy" once this was done Trails started logging to the bucket. Finished up by moving the log-archive account back the security ou
  3. Once all that is done it will create a DRIFT on the security OU (SCP policy being different then the Bucket policy) I updated the SCP to reflect the bucket changes and now the security ou is back in a compliant state

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.