The LZA’s flexibility makes it ideal for organisations with complex networking, regulatory, and operational needs.
In this post, we'll take a quick look at the AWS Landing Zone Accelerator, explore how it works, and offer some opinions on the pros and cons.
If you're not familiar with Cloud Landing Zones, be sure to read the other posts in this series first.
Provides an infrastructure foundation built on AWS best practices and global compliance frameworks.
Provides a GitOps approach for continual configuration updates and upgrades to your landing zone.
Provides you with a quick to deploy near-zero-code Landing Zone backed by AWS. Day 2 operations can be quite time consuming with delayed feedback for validation and change rollout.
Provided by AWS as an Open Source project, the Landing Zone Accelerator gives companies of all sizes the ability to deploy a cloud landing zone aligned with AWS' best practices with minimal configuration and little need for any code. With the ability to enable controls to help meet various global, regional and industry specific compliance frameworks, it’s no surprise the term 'accelerator' formed part of the name.
Behind the scenes the project makes use of the AWS CDK (Cloud Development Kit) to materialise CloudFormation templates, which are then deployed across accounts within your AWS Organisation. These CloudFormation templates make use of over 35 AWS services to provide the foundations of your landing zone.
If you're thinking to yourself "Isn't this just the AWS Control Tower?", then let's take a quick comparison to understand how these tools in our toolbox differ, but also how they can work together.
AWS Control Tower was launched back in 2019 with an aim for organisations using multiple AWS accounts to ensure governance at scale from a single unified interface. With Control Tower we can set up a basic landing zone that utilises AWS Organisations, AWS CloudTrail, AWS Config and AWS Identity Center (SSO) along with some mandatory controls to ensure basic governance is enforced and cannot be circumvented.
As well as allowing organisations to enrol existing accounts into Control Tower's purview, it also has the ability to vendor new accounts with functionality available to customise these new (and existing) accounts.
Now if I’m a multinational corporation with complex inter-regional networking needs, in need of a global network architecture that includes multiple VPCs with custom routing, VPN connections, and direct connect links, ensuring seamless connectivity across all regions and accounts, Control has nothing to offer.
If I’m a financial services firm subject to stringent regulatory requirements, and need to implement custom security controls and compliance checks that exceed the default options in Control Tower, such as enhanced encryption standards, detailed audit logs, and custom compliance reports tailored to specific regulatory frameworks like PCI-DSS or GDPR, again way outside the remit of Control Tower.
A corporation embracing agile and its decentralised approach and looking for platform engineering to enable product teams to be self-sufficient; you own it, you run it. Again, you're falling way short of the mark, and ultimately where a Landing Zone can help facilitate.
As stated earlier, the LZA is defined as a CDK project that optionally - although highly recommended - works alongside Control Tower. Where the LZA differs however is in the interface by which organisations deploy and maintain their landing zone. In addition to providing the basic governance controls, the LZA also allows companies to define many other resources within the same interface such as Accounts, VPCs, Identity Center Permission Sets, Transit Gateways, Service Control Policies and many more.
Using a GitOps style approach to provide continual configuration updates and drift detection, as well as a myriad of configurable options. This pattern of operation much more closely aligns with many cloud native tools for managing infrastructure that have exploded with the rise of Kubernetes.
The diagram below outlines the various components that make up an LZA.
Like any ready-made solution, there are of course a number of pros and cons, and they'll vary depending on what you want to get out of it and how your company operates. This is not an exhaustive list as these are subjective.
The obvious first pro, and really what the LZA is trying to achieve - is getting your day 1 landing zone delivered right out of the box. From cloning the repository to getting your base landing zone up and running, it's only going to take you a couple of hours. If you compare this with a traditional multi-account setup using Terraform, then you're saving weeks of work and all the trials and tribulations of managing multi-account providers, CI/CD etc. If you're time or resource constrained and just want to focus on what matters to you, then the LZA appeals a lot.
As we mentioned earlier, the LZA is very customisable, it's been designed with that in mind from the start. There are 7 top-level customisation files, all of which are in YAML file format and well structured. The configuration files are all kept in source control and support referencing any sensitive values in the SSM Parameter Store. As the LZA operates in a GitOps fashion, the changes you make to your configuration files are deployed continually allowing for incremental revisions, upgrades and new features.
It isn’t an exaggeration to say deploying a compliant, well-architected landing zone; taking in aspects of structure, policy, governance, auditability, networking, authentication and authorisation to name a few comes with a considerable high-bar of complexity, coupled with the admission that few people have the experience of building an entire ecosystem from scratch. Understanding of the inner workings and the plumbing underneath is a huge task alone.
The Landing Zone solution is backed and maintained by AWS, and for those who can afford business level support, you also have the ability to raise issues directly with the team behind the solution. But more than that, offloading the burden of maintaining, upgrading, reconfiguring, keeping abreast of the new capabilities in a never ending “AWS Services” tab, comes with significant benefits.
Having deployed, managed and customised a number of Landing Zone Accelerator engagements, here’s our top pains.
Cloudformation isn’t renowned for its speedy execution, and the first hurdle faced by engineering when using the Accelerator is speed. Those used to the de facto Terraform plan and apply workflow, and the quick turnabout will be shocked at the time it takes to move changes through the environment. You can pretty much expect every change, regardless of size, complexity or indeed criticality to take at least 1 hour plus to roll out. When accompanied with the second pain point detailed below has a compounding effect.
Localising all the configuration into a single location naturally has some benefits (centralised config management), but it also comes with serious drawbacks. Having a single repository for all configurations makes it difficult for teams to take custody of individual responsibility areas, such as account provisioning, security, organisational management etc. There is no clear accountability, or team alignment to how organisations operate.
While some of this could be mitigated by properly managing code owners in your repository, permissions etc, in the end, the entire Landing Zone solution is deployed as one. Traffic jams are common between teams, access controls between areas of concern difficult to enforce, and fundamentally potential blast radius, and the risk associated with change is considerably high.
For those who are keen in working in the open-source world, it should be noted that whilst the LZA code is published on GitHub, AWS do not provide timely or detailed responses to pull requests or issues raised through GitHub. This can be a source of frustration for those looking for rapid support with their landing zone, if they do not have a support plan as part of their AWS account.
From most of the conversations we have had with users of the LZA, the majority of infrastructure engineers are not overly familiar with the CDK and to some extent CloudFormation. It's probably fair to say that most engineers are more familiar with cloud agnostic tools such as Terraform or Pulumi, particularly if they work in either hybrid cloud or multi-cloud environments. This does make dissecting or augmenting the LZA codebase somewhat less approachable than a pure Terraform solution.
Here at Appvia we have extensive experience with both using and building cloud landing zones. The employee base is a diverse lot, spanning platform engineering, technical consultants and app development, we have been both consumers and builders. Accompanied with experience of using various solutions; open source and commercial, it’s fair to say we’ve had oversight from many angles.
Similar to all our engagements, before jumping into specifics though it’s always good to level-set and talk about our working and design principles:
When discussing landing zones we often choose to speak about them in two forms:
The latter point is most important. If the sole outcome of the landing zone becomes a collection of technical controls, knobs and dials, organisational levers to restrict people from doing things, chances are all you’ve achieved is a lot of friction downstream. A premeditated deluge of support tickets asking how to do this, why this is not working, what's the point of x etc. Pairing organisation policy with a way of working and common reusable patterns, allowing the teams to get on with it, in a decentralised approach.
While we definitely see the value for an organisation in adopting the AWS Landing Zone Accelerator for elements, our implementation takes a blended approach, capturing the best of both worlds.
Where the capabilities benefit from AWS Landing Zone Accelerator we retained within the framework, and the rest we captured in Terraform. The choice of separation is usually guided via the following principles:
A typical landing zone is below:
By modularising different components we can create distinct repositories that manage just a particular responsibility area that matches an organisation's structure and ways of working. For example, an organisation may have a dedicated security team and we can have a repository that's owned and managed by that team which covers security elements of the landing zone, such as Service Control Policies, User Identities and Permission Sets etc.
By taking advantage of this modular design, we are able to cater a landing zone for organisations of all shapes and sizes, whilst still having the heavy lifting and continual updates of the LZA from AWS.
In the next article we will deep dive into the individual components which makeup the landing zone and how they are stitched together.
