AWS Landing Zone Accelerator (LZA) Strengths and Weaknesses

Overview

The AWS LZA is an opinionated framework for deploying an AWS Organization and supporting infrastructure. This framework utilizes CDK and codebuild/pipeline in the org management account to orchestrate things like centralized logging, delegate security services, shared networking config, and a couple hundred other things.

Should I use it?

In my opinion this depends on a couple things.

1. Are you operating in a highly regulated environment with required adherence to strict security frameworks like HIPAA, NIST 800-53, ITSG-33, FEDRAMP Moderate, or CCCS-Medium?

If the answer above is no, the LZA is probably going to be overkill, but it depends on a few more things. If the answer above is yes, LZA has a couple example configs that have been used to obtain security compliance under multiple frameworks. Those can be found here.

2. Do you have the budget to support this decision?

The official docs here claim ~$430 USD/month, but this doesn’t include things like AWS Network Firewall, vpc endpoints, or workloads. The typical setup I’ve experienced runs at least $2000/month after bandwidth charges and you will likely need TWO of them (see pitfalls section below) This is no startup bootstrap framework.

3. Do you have the personnel needed to support an LZA?

This one is tricky, but you’re going to need someone to own this. The LZA pipeline is brittle, slow, and needs updating every couple months. Changes take a long time (more on that later) and you’ll want someone at least comfortable in the AWS console to keep it up to date and operating.

We’re going to use it. What can it control?

The answer here is just about anything. The framework lets you inject cloudformation templates that can be deployed to any OU or account in your organization, meaning you could control everything from the LZA pipeline. Obviously the issue with that idea is the deploy time of the LZA pipeline can be hours long.

As I’ve worked with this tool, I’ve found some natural boudaries show up given that long deploy time. First, and most obviously is the Network Firewall. If you’re using the network firewall from AWS you’re likely using it in a centralized way (hosting in one vpc, funneling traffic to that vpc via transit gateway) and that firewall will need to be changed often. Creating the policy in AWS is a good idea, but managing the rules in that policy best lies outside of it (either in a cdk pipeline, or similar IAC).

The second area that seems to stand out is IAM Identity center. This is another case where deploying for hours at a time is not an acceptable turnaround. Again, best left to a ci/cd pipeline. Both of these use cases are worthy of their own blog post.

Lastly, networking is a thing that should be controlled centrally. Managing vpc’s in a ‘network’ account and sharing select subnets out for things to be deployed in is a pattern that works very well for these type of regulated environments. The networking and subnets should be managed by the LZA.

Pitfalls

AWS Landing Zone Accelerator (LZA) Strengths and Weaknesses

Initial installation will likely be very smooth. If you set everything up exactly as you want from the get-go life will be great.

If you try to change things like transit gateway route tables, vpn connections, and even things as simple as default route in a transit gateway route table, you’re going to hit errors at the very end of your 1.5 hour pipeline run.

These errors can be vague and the path to fix them (in case of the transit gateway route table default route one) is to roll back, run the pipeline WITHOUT A DEFAULT ROUTE, and then run it again with the new route in place. Talk about disruptive.

LZA Pipeline Upgrades are not always backwards compatible

You read that right. Some require very specific two-step runs through to get the config to match the new pipeline version. Upgrades can be disruptive to the network stack.

You need a Test-LZA environment.

This is expensive, yes, but if you don’t like downtime you need it. If you’re not convinced read point one again. The issue I ran into there would have led to a 1.5 hour disruption in networking service. There are ways I probably could have made that time shorter, but not without a test lza to prove a theory before going to prod.

Conclusion

The lza is a useful, if deft beast. If you plan on changing something on anything more frequent than a quarterly basis, or delivery time for a fix should be less than 2 hours, do not configure it in the LZA. The LZA shines when needing to meet regulatory requirements for your environment.