What is AWS Landing Zones, how does it relate to AWS Control Tower, and when might we want to use them? This article explains the high-level approaches of each and the benefits and limitations of each service:
What is AWS Landing Zones?
Landing Zones is not an AWS Service that you “use”; it is a “solution” comprising a package of CloudFormation templates intended to be deployed by an AWS partner or AWS ProServe (as recommended by AWS) to deliver infrastructure that follows AWS best practice, including (but not limited to):
1. A multi-account architecture that reduces your “blast-radius” and supports separation of concerns at an account level;
2. A security baseline that is applied across all of your accounts;
3. Optional centralised logging capabilities; etc.
When deployed, Landing Zones provides an AWS Account Architecture similar to the following:
Note: Greyed out items are optional
As part of a Landing Zones deployment, a CI/CD pipeline is also provided to update changes to AWS Accounts:
As illustrated, AWS Landing Zones also provides the ability to “vend” additional accounts (with baseline security) into a an isolated Organizations “OU”.
However, it should be noted that some users have reported that Landing Zone scripts are complex and difficult to customise.
What is AWS Control Tower?
AWS Control Tower (at the time of writing available in Ireland, Ohio, N. Virginia, and Oregon) takes the Landing Zone pattern to the next level – implementing it as an AWS Service, thus removing the complexity of Landing Zone CloudFormation templates.
AWS Control Tower applies pre-configured “guardrails” across your AWS Accounts (some of which are mandatory, such as default S3 encryption).
AWS Control Tower requires an empty AWS Organization, therefore it is unsuitable for use alongside existing infrastructure.
Naturally, as an AWS Service, it cannot be customised in the same way that AWS Landing Zones can. Further, AWS Control Tower does not provide an API for automation.
Both Services provide a self-service capability for “vending” new AWS Accounts for various business purposes.
So should I use AWS Landing Zones, Control Tower, or just carry on as I am?
The ultimate objective is to ensure you follow AWS’ best practices such as: deploying a multi-account architecture, centralising your logs, and applying a base security layer across your infrastructure. That’s why Landing Zones and Control Tower have been created – to embed those practices into your infrastructure.
Of the two services, Landing Zones provides greater flexibility but can be difficult to customise to meet your business requirements. For that reason – and because Control Tower is an AWS managed service – Control Tower is the easiest way to deploy “Landing Zones”.
Consequently, I will focus on AWS Control Tower to answer this question:
For advanced AWS Customers
If you already follow AWS best practice, are a customer with complex infrastructure requirements (e.g. 3rd party integration), or wish to extend your infrastructure beyond its base implementation, you may wish to consider continuing as-is.
Also consider tools such as AWS Config and AWS Security Hub to help you manage your infrastructure centrally.
AWS Config is a service enabling the assessment, audit, and evaluation of the configurations of your AWS resources. AWS Config continuously monitors and records AWS resource configuration, and automates the evaluation of recorded configurations against desired configurations.
AWS Security Hub is a central interface that aggregates, organises, and prioritises security alerts and findings across multiple AWS accounts, services, and AWS Partner solutions. This allows you to continuously monitor your environment using automated compliance checks based on AWS best-practice and certain industry standards your organisation may need to adhere to.
However, there is still a benefit in running a Proof-of-Concept with AWS Control Tower. Using it on an empty Account may reveal approaches that you wish to incorporate into your existing infrastructure.
For simple use-cases
For customers without an existing AWS footprint or with limited infrastructure, AWS Control Tower could be a good approach for deploying – and adding – accounts as your footprint grows.
For Sandboxes and Demo Accounts
In all scenarios, AWS Control Tower could be used to provision Proof-of-Concept, Sandbox, and Demo environments (e.g. where there is less need to customise “baseline” infrastructure). AWS Control Tower can deliver these accounts in a consistent way: better serving your business users, and empowering them to “vend” accounts for themselves.
Conclusion
As AWS’ customers consume services, AWS continually innovate to deliver easier ways for customer to use their cloud platform. However, this doesn’t mean each new AWS service requires immediate implementation. In this case, the end-result (a secure, scalable, and best-practice cloud infrastructure) is more important than how you got there!
Regardless, it is important to understand why AWS Control Tower deploys infrastructure in a certain pattern. Use the “Recommended Reading” section of this blog for a summary of the “Well Architected Framework” (essential reading!) and guidelines for multi-account architecture.
In short: Customers with a mature AWS environment may wish to continue as they are and use AWS Control Tower for delivering tactical infrastructure, but new customers – or those with simpler use-cases – may find AWS Control Tower an ideal cloud accelerator.
Note: This article is an opinion and does not constitute advice – any actions taken by a reader based on this article are at the discretion of the reader, who is solely responsible for the outcome of those actions.
AWS illustrations have been used as the basis for technical diagrams in this POST, and extended where relevant
