15th December, 2021 –
If you’ve never used AWS before it can be a little daunting to get started. There are a huge amount of services that do an extremely wide range of things, and it can sometimes be difficult to pick the right one to use, and when you do decide on what you want to use you need to figure out how to configure it correctly.
AWS tends to provide its customers with building blocks they can use to build solutions and services on the platform, and while they do a pretty good job of giving customers advice on best practice ways to use and configure the services, this can also be a challenge for time-poor customers who just want to focus on their business problems, not on configuring cloud services.
As well as configuring the services and resources, an underlying platform configuration should also be implemented to ensure future services and resources get deployed on top of a best-practices foundation. Historically, customers would either attempt to do this themselves or rely on an AWS partner to assist them.
The partners would have a checklist of things they would implement in the customer’s account or accounts to bring them up to a base level of industry best practices. This model worked for a while, but AWS found that the barrier to entry into getting production workloads running on the platform was too high, and was costing customers too much in partner professional services fees.
Their solution was to introduce the concept of a “Landing Zone” around June 2018, which coincided with the release of their Landing Zone Solution. The idea of a Landing Zone was to provide an automated way to provision a best practice set of AWS accounts that would enable rapid deployment of production workloads into AWS.
Landing Zone Solution overview.
But, I’m getting ahead of myself – there’s a little history we need to cover to get some context before going into how the Landing Zone has evolved into what it is today, and to discuss what it might become.
Single accounts
In the dark old days, customers would have a single AWS account and would lump everything into it. They would split their development and production workloads using different VPCs (hopefully) and use basic IAM users and policies for their access controls.
Most underlying foundational services like logging, security guardrails, identity and networking were configured manually – if they were configured at all.
If I’m honest, it’s not very charitable to say “the dark old days” because I know of some organisations that are still using a single account. There are use-cases for single accounts, of course, but these days I’m seeing most customers adopt a multi-account strategy from the get-go (half because I tell them that’s the right thing to do, and half because they’ve heard and read the same thing elsewhere).
Multiple accounts
A multi-account structure is having multiple AWS accounts, generally consolidated under a master account (but not always) for billing, to logically separate your resources and services from each other, which can be beneficial for a multitude of reasons.
It made enforcing separation of services and resources between environments – e.g., development, testing and production – much easier. It allows more fine-grained access controls, more robust backup and disaster recovery strategies, more resilient networking infrastructure and easier to manage identity models.
Classic multi-account structure.
Creating new accounts was a manual process that had a laundry list of admin tasks associated with it to ensure it was set up correctly (security questions, credit card details, contact details, limit increases, billing consolidation, etc.).
AWS Organisations
In the really dark old days, the only way to link AWS accounts was through billing consolidation. AWS announced AWS Organisations at ReInvent 2016, which provided another way to link and managed AWS accounts together, solidifying a multi-account structure into accepted best practices.
Automated creation of accounts
With the introduction of AWS Organisations, quickly followed by the release of an Organisation’s API, it became possible to create AWS accounts automatically.
AWS Partners that were deploying multi-account structures for their customers on a regular basis used this API to automate the parts of the account creation process that were possible to automate. This was a huge improvement on manual account creation.
Landing Zone Solution v1.0
In June 2018, AWS finally announced an automated solution for deploying a best-practice set of AWS accounts, a security baseline, centralised logging and federated identities. Most partners who had written their own automation for creating and managing AWS accounts adopted the Landing Zone Solution.
The Landing Zone solution was only available to AWS partners to deploy for their customers, probably because it was such a complex solution that would require significant support to deploy and maintain.
Unfortunately, it wasn’t perfect. There were some bugs, it had a lot of moving parts and it was fairly opinionated in places. Because of its complexity, if you wanted to make changes to it you had to dig into a 5000 line CloudFormation template that was riddled with step functions, lambdas, CodePipelines and CodeBuild projects.
If you wanted to roll back a Landing Zone deployment, there were a specific set of steps you had to go through – and you had to find those steps out by trial an error.
Landing Zone Solution v2.0
After six months of deploying Landing Zone 1.0 for customers, AWS launched Landing Zone 2.0 which fixed a lot of the bugs and generally made the deployment a lot smoother. It was still unwieldy, though, if any changes to it were required, and updating from 1.x to 2.x was a challenge the first couple of times.
Partners slowly came to grips with it and generally bent it to their wills, which significantly reduced the time to market for new AWS customers and customers looking to transition from a single account or a legacy multi-account structure.
Control Tower
AWS listened to partners’ complaints about the Landing Zone solution and decided to take on the management of it behind the scenes. Control Tower is a managed service that does all the things that the Landing Zone solution does, but it abstracts away the nuts and bolts of the implementation.
It was announced to the public at ReInvent 2018 and became generally available in June 2019. It was no longer a requirement to go through an AWS partner, although the out-of-the-box Control Tower deployment still had a few rough edges and the assistance of an AWS partner was recommended.
Control Tower deploys the following:
- Multi-account environment using AWS Organisations
- Identity management via SSO and federation
- Centralised logging from CloudTrail and Config
- Cross account security audit capability
- Self-service account factory for new accounts
- Preventive and detective security guardrails
After a short time, the Landing Zone solution was deprecated in favour of the Control Tower.
Extending Control Tower
Control Tower doesn’t have a huge amount of configuration options for modifying what or how it deploys. If you want to make changes to the deployed resources or add your own extras, you can use the Control Tower Customisation solution.
If you dig into this thing, it looks very similar to the Landing Zone CloudFormation template, with the core stuff stripped out of it. It behaves in a fairly similar way, and generally works pretty well. You can define additions in a manifest file, and they will be deployed to OUs or accounts that you specify using CloudFormation.
Control Tower in Sydney!
New Zealand and Australia generally lag the rest of the world for releases of new AWS features and services, so it took a few months for Control Tower to arrive in Sydney. It was made available around March 2020.
Landing Zones of the Future
With Control Tower taking care of the basic leg-work for us, we can focus on extending it to meet individual customer use-cases. For example:
- NZISM (and other framework) compliance
- Security Hub enabled, aggregated and configured
- GuardDuty enabled, aggregated and configured
- AWS Config enabled, aggregated and configured
- CloudTrail configured to use appropriate encryption
At CCL, we deploy separate Service Catalogue products that extend the Control Tower Landing Zone that can be chosen at deploy time.
By automating the above, preferably with a one-click deploy, we can focus in on our customers business problems on day 0 instead of being bogged down by foundational services and governance.