Flux7 Blog

In its Cloud Adoption in 2020 report, O’Reilly found that 45% of enterprises expected to move 75% or more of their applications to the cloud this year with 25% reporting plans to move all their applications to the cloud. This trend has only escalated as a mid-year report by Flexera shows that 59% of enterprises expect cloud use to exceed their pre-COVID-19 plans. The one thing holding enterprises back? The fear of getting security wrong. 

Landing zones have traditionally been how enterprises would address this concern, as they use a best practice security approach to help ensure the safe setup of AWS accounts. Yet, with the introduction of AWS Control Tower, enterprises may consider migrating from AWS Landing Zone to AWS Control Tower. Today we’ll walk you through why you might want to migrate, but first, we’ll start with a little background.

What is AWS Control Tower?

Amazon knows that when you have multiple AWS accounts, it can be hard to manage, control and secure all of them in one go. Enter AWS Control Tower. It combines power and simplicity, making it easy to set up, govern and secure your multiple accounts using built-in services from AWS like AWS Organizations, AWS Service Catalog, AWS Single Sign-on, AWS IAM, AWS Config, AWS Cloudtrail, and more. This combination of services makes life easy and secure for your AWS accounts. You can also provision new accounts very quickly using the Control Tower dashboard with limited steps. Last, it also provides built-in guardrails to protect your accounts.

What are guardrails?

Guardrails play an important role when it comes to security or securing multiple accounts. It’s a policy control mechanism that is written in plain language. There are two types of guardrails — preventive and detective. Just like they sound, one is to prevent actions that can cause issues to your accounts, and the other is to detect and provide alerts. In this way, Control Tower provides ongoing management of your accounts to security policy. 

Why migrate from AWS Landing Zone to AWS Control Tower?

AWS Landing Zone’s strength is when you need to create a configurable landing zone with customization and Control Tower excels in providing you with a self-serve, easy to use landing zone with pre-configured blueprints and pre-configured guardrails. While they both help you set up your AWS accounts securely, you may consider migrating to Control Tower to obtain the benefits of AWS pre-configured ongoing security policy management. Also, as a managed service, AWS is actively adding new features to Control Tower compared to the legacy Landing Zone. Therefore, migrating to Control Tower drastically decreases maintenance overhead and allows you to get rid of constantly updating and adding new features to a Landing Zone.

In addition, AWS Control Tower brings with it a lot of benefits and an easier workflow. It has three main accounts, “Master”, “Audit” and “Log-Archive”. The Parent/ Master account has many advantages. It is easy to maintain, secure and govern. If you want to apply service control policies (SCPs) or guardrails you can directly apply to your Root OU (organizational unit) and it will apply to all the sub-accounts or OU.

Migration considerations

We recently migrated a customer from legacy AWS Landing Zone to AWS Control Tower. A leader in the manufacturing industry, this customer sought to move to Control Tower because they wanted to decrease maintenance overhead, decrease the amount of custom code, and get easy self-service user experience.

Before migration, we identified all potential approaches for AWS Landing Zone to AWS Control Tower migration. Of the several options, we’d like to walk you through what the options were, and why we chose the one we did for this customer and their use case.

Option 1: New Control Tower Organization and Application migration. This approach requires creating a new master account and a new organization, then deploying Control Tower in the new organization. After Control Tower is set up, you would create new accounts and migrate applications from legacy organizations. This approach may be interesting for customers that either want to start from scratch for different reasons or the complexity of your application migration is low.

Option 2: Convert the existing Landing Zone Organization to Control Tower. Recently AWS added a feature that allows it to convert existing Landing Zone organizations to Control Tower and enroll existing accounts to Control Tower. One of the benefits of this approach is that AWS provides scripts to migrate existing accounts in an automated way. That dramatically decreases migration time; we consider this approach the best-fit approach for Control Tower migration for most customers.

Option 3: New Control Tower Organization and existing account migration. This approach requires the same steps to set up the Control Tower organization as the first one. But instead of application migration, we will migrate the existing account. There are billing considerations that you need to be aware of before migrating accounts. When a member account leaves an Organization, all charges incurred by the account are charged directly to the standalone account. Even if the account move takes only a minute to process, it is likely that some charges are incurred by the member account. That increases migration complexity and doesn’t allow us to fully automate the process. The main use case for this approach is the migration of accounts between AWS Organizations. It can be used in addition to the first approach to migrate several accounts ‘as is’, for example, partner accounts where you don’t have full access.

Now that we’ve identified the three possible migration approaches and the primary  use cases, let’s analyze them more deeply: 

Given these benefits and limitations, let’s return to our customer and their requirements. The customer has around 100 AWS accounts and a variety of different application patterns. They are looking for an automated way to migrate to Control Tower as application migration could take months of work. So the choice was obvious. We chose Option 2, converting the existing Landing Zone organization to Control Tower.

Before migration began, there are several prerequisite activities we conducted:

1. Disable AWS Config on all AWS accounts that will be enrolled to Control Tower.
2. Ensure AWS accounts are in the same AWS Organization. If they are not, you need to move them to the right organization.
3. Create AWSControlTowerExecution IAM roles. The automated script will automatically create the roles. 

Following these prerequisites, we converted the customer’s Landing Zone to Control Tower. We used the NTT DATA Build Cloud Foundations solution to quickly establish a foundational architecture with Cloud Tower and to speed deployment of account creation with automation. As part of the Build Cloud Foundations architecture, the customer receives AWS Security Hub for security alerting and enablement of CIS AWS Foundations standards. 

Best practice recommendations

While Control Tower and Landing Zones each have their strengths, you may want to use Landing Zones in some instances and Control Tower in others. Fortunately, you can use both by adding Customizations for AWS Control Tower and deploying new resources to existing and new accounts within the organization. As you begin down the path to your AWS adoption, determine the level of customization you’ll need. 

Written by Kritika Agarwal & Artem Kobrin, Flux7 Labs

Flux7, an NTT DATA Company, is the only Sherpa on the DevOps journey that assesses, designs, and teaches while implementing a holistic solution for its enterprise customers, thus giving its clients the skills needed to manage and expand on the technology moving forward. Not a reseller or an MSP, Flux7 recommendations are 100% focused on customer requirements and creating the most efficient infrastructure possible that automates operations, streamlines and enhances development, and supports specific business goals.