An existing AWS organization does not have to be replaced to adopt AWS Control Tower. AWS supports adding Control Tower to an existing organization and extending governance to selected organizational units, or OUs. Start by deciding what you want Control Tower to manage and which parts of your current environment should remain in place. AWS deployment planning
For a team with running workloads, the following five decisions provide a starting point for an adoption plan.
Choose the scope of governance
With landing zone version 4.0, AWS documents a controls-only option for an established AWS Organizations environment. It lets you adopt managed controls without implementing a full landing zone. AWS controls-only environment The setup still creates a landing-zone configuration. AWS setup notes
Use your intended outcome to choose what to evaluate:
- Selected controls around an established foundation: evaluate the controls-only option with a list of required controls, their owners, and existing service integrations.
- A broader baseline for existing accounts: evaluate OU registration and account enrollment with the account prerequisites, existing policies, and resources that the baseline would manage.
- Unclear requirements or ownership: resolve those decisions before selecting an adoption path.
These are planning recommendations. Record the landing-zone version and exact controls before assessing compatibility. If you use the older AWS Landing Zone solution, AWS advises consulting your AWS solutions architect before enabling Control Tower because its pre-checks cannot determine interference with that deployment. AWS deployment planning
Resolve AWS Config compatibility before a pilot
The controls-only setup can begin without AWS Config for preventive and proactive controls. Detective controls require Config recording, which carries usage charges. Include the accounts, resources, and Regions in your cost review. AWS implementation process
Existing Config resources need a separate compatibility check. AWS documents a support allow-list process for enrolling eligible accounts that already have Config resources. It uses OU registration or re-registration with AWSControlTowerBaseline; it is not supported through ConfigBaseline enablement or reset, or through automatic enrollment. It also excludes the management account and configured service integration accounts. Existing Config enrollment requirements
Inventory the recorders, delivery channels, Regions, destinations, and owners. Resolve the applicable enrollment requirements and agree how recording continuity will be checked before changing resources.
The baseline choice matters: AWSControlTowerBaseline already includes Config functionality. AWS does not allow it and ConfigBaseline on the same OU. AWS baseline types
Map policy and Region effects
Compare the policies that apply now with those that would apply after the change. AWS's enrollment guidance calls out preserving the service control policies, or SCPs, applied in the account's current OU. Review the effective restrictions before moving accounts. AWS account enrollment behavior
AWSControlTowerBaseline retains landing-zone Region deny settings. An OU-level Region deny control cannot reopen a Region denied at the landing-zone level. ConfigBaseline does not enable that Region deny control as part of its setup. AWS baseline types Existing SCP restrictions still matter: an applicable explicit deny remains effective in the account's policy hierarchy. AWS SCP evaluation
A small pilot does not confine every effect to its accounts. AWS explains that trusted access lets Control Tower create roles, manage resources, and read data across the organization, including accounts that are not enrolled. Review that organization-wide relationship before setup. AWS organization governance
Separate governance from workload changes
When enrolling an existing account, Control Tower does not create a new virtual private cloud, or VPC, or remove its existing VPCs. Application access and deployment workflows still need testing against the proposed controls. AWS account enrollment behavior
For landing zone versions 3.1 and later, when the optional CloudTrail integration is selected, an existing account-level trail can overlap with the organization trail and produce duplicate charges. Identify retention requirements and downstream consumers, then validate the intended logging arrangement before removing anything. AWS CloudTrail enrollment considerations
If workloads also need to move, give that work its own dependency, validation, and recovery plan. The migration wave planning article addresses that separate decision.
Define acceptance and handoff before expanding
For adoption through OU registration, choose an approved pilot that represents the dependencies you need to test. AWS notes that an OU can register successfully while individual accounts fail enrollment. Verify each account's result before expanding. AWS OU registration
For a controls-only pilot, define acceptance around the selected controls and their prerequisites. Useful checks include:
- The intended controls and baseline state are visible for every target in scope.
- Required access and deployment workflows work, and intended restrictions take effect.
- Logging and configuration records reach the agreed destinations.
- Exceptions, incomplete operations, and recovery actions have named owners.
- The operating team can explain how it will review future changes and maintain the configuration.
Keep the decision record in the client's systems: selected approach, version, account and Region scope, retained services, expected changes, pilot evidence, and unresolved risks. These are suggested planning artifacts. The Ownership Standard explains the wider expectations for client-controlled work and handoff.
Uptempo's AWS Landing Zones service covers scoped foundation and governance engineering. Two ways to engage are:
- AWS project delivery through Consulting. Define the scope, deliverables, and acceptance criteria in a statement of work. For a Control Tower project, that could mean an agreed pilot and validation scope. Migration or lift-and-shift work can also be scoped around the AWS outcome required.
- AWS hour-pool backlog assistance through Support and Advisory. Purchase a monthly pool of engineering hours and prioritize AWS tasks together in a shared Jira backlog. Review completed and remaining tasks, time reports, and hours consumed against the pool. Work follows the agreed business-hours delivery boundary; the pool does not include monitoring or pager coverage.
Other AWS-focused engagements can be considered against their scope and delivery requirements. To discuss your need, Book Your Free AWS Assessment: one hour of verbal findings and recommendations, with no written deliverable.