It's been quite a few years since I first started playing with AWS Landing Zones. When I started in 2017 or 2018 the idea of a landing zone was a number of AWS Accounts where cross account access was through IAM roles, and each account individually connected to an Identity Provider (either Microsoft Active Directory or something similar).
I remember the first landing zone I was part of developing was basically a series of structured Cloudformation Templates which deployed Lambda functions, VPCs, NAT Gateways, etc to deliver a semi automated build for our customers. I remember it took several hours but the result was mostly consistent.
I say mostly because sometimes unexpected things did happen but it was a solution that I think worked well. AWS Organizations back in those days really only served the purpose of Consolidated Billing and things like Service Control Policies, etc. didn't exist.
AWS didn't really have a landing zone back then. Their first Landing Zone solution did come out in around 2018 but it wasnt really until AWS Control Tower Came out in 2019 that there was actual disruption in the legacy ways of structuring accounts went out the window.
AWS Control Tower introduced a number of very cool things. Not all of these things were there on day one but over the years and versions has really enhanced this approach.
- Configurable Guard Rails (that were basically a managed set of Service Control Policies)
- Centralised Identity Management (using AWS Single Sign-On as it was called then)
- Delegated Management (to allow certain accounts to manage certain AWS services within the Organization such as Networking, Cloudformation Stacksets, Security and Firewalls)
- Customisation capabilities
- Centralised auditing and security.
I wanted to write this blog today to talk about where AWS is taking this Landing Zone Architecture and what I think are really good things to have in your AWS Control Tower Environment.
General Architectural Best Practices
AWS Control Tower is very flexible in terms of accomodating the best practices that I personally would recommend but I thought I would jot some of them here.
Isolate Backup Accounts and Backup Management Accounts
It has always been recommended to separate the Backup account (Where you might store Backup data of EC2 instances, Databases, etc.) from production work loads. But before AWS Backup existed there really wasn't a component in AWS Control Tower to accomodate that. Now there is:
- You can create a Backup account in a Control Tower Environment at Landing Zone Launch Time (which was introduced in
Improvements in API integrations and automation
I used to have a gripe back in the early days of AWS Control Tower about how much it was still a Click Op based solution (you needed to manage a lot of things from the AWS Management Console). I am glad that as the product has evolved, pretty much all of my main complaints have been resolved by the great team of developers in AWS.
Launching an AWS Control Tower Landing Zone via API
You never could do this in 2022 when I last deeveloped a Landing zone based on Control Tower using Automomation. I have to build Control Tower in the GUI and then I could run my pipeline against the newly created AWS Organizations Org.
Now, as long as you have API/CLI access to the Org Management account you can do it all through CLI or Code based approaches.
The Steps Below really cover it off and I think it is so easy to integrate into a DevOps approach if that's what you want to do.
Add comment
Comments