Friends Don’t Let Friends Build Landing Zones

Over the last few years Gerald Bachlmayr and Andrew Khoury have been responsible for building many Landing Zone implementations for a variety of customers across several industries.

In this blog post we’ll explain what a Landing Zone is, why you need one, and how they’re typically built in Enterprise environments. We’ll give you our recommendations for what to focus on in your cloud journey, and explore what happens when you leverage Amazon’s Landing Zone solution instead of building your own.

Why do we need Landing Zones?

Before you can launch production-ready applications in the cloud, your organisation needs to build and configure the fundamental components to support the applications you plan to build and run:

• Security & Compliance: consider and build rules for compliance and security
• Account Management: create new AWS Accounts and manage updates to each Account
• Connectivity: consider connectivity between public cloud, on-prem, third parties, public users
• Operational: implement backups, monitoring, alerts and tagging
• Costs: report on cost and usage with the ability to implement cost optimisation
• Segregation of Duty: Can be enforced by account separation

A Landing Zone addresses the above challenges. No matter your situation — whether you are a startup or an enterprise, going for IaaS or all in on serverless, you need some kind of Landing Zone — even if it is a basic stripped down version. A famous thinker — Bob the Builder — once said: “Always start with the foundation”. And that’s just what a Landing Zone provides: a pre-templated foundation for a production-ready cloud platform that covers all of the above pillars.

In addition to fundamental components for the cloud, we’ve seen many enterprise organisations that have the following issues with their on-prem environments:

• Data center cannot scale and/or is lacking features
• Disaster Recovery is a painful process
• Not enough environments
• It takes too long to create new environments
• Environments are inconsistent

What is a Landing Zone?

You might already know “Landing Zone” by one of it’s many other names in the industry:

• Platform
• Foundations
• Scaffolding
• Building blocks
• Platform as a service
• Factory
• Cloud control plane

As you can see Landing Zones come in all sorts of shapes and sizes. It can be tempting to build your Landing Zone manually to save time and make changes quickly (in the short term). Landing Zones can also be partially, or fully automated which will offer long-term benefits of consistency and quicker updates in the future. You may write the code from scratch or bring in a vendor with pre-defined templates or experience. You might also choose to consume your Landing Zone as a service that’s automatically updated for you. All these are considered landing zones.

For the rest of this article we will use the following as our definition of a Landing Zone:

“The creation, configuration, and management of public cloud accounts for enterprise customers, in a way that’s secure and production-ready.”

Undifferentiated Heavy Lifting & Your Value Stream

The effort involved in building a Landing Zone yourself does not providing any immediate value to your business. Landing Zones aren’t your core business offering. Like email servers or your physical office space, Landing Zones are a thing that every business needs, but they don’t provide a unique advantage to your business. In the startup world we’d say “They don’t form part of your Unique Selling Proposition”.

There’s a special name for these email servers, office spaces and Landing Zones. Undifferentiated Heavy Lifting (UHL). By reducing your time and effort spent on UHL your business can focus on the things that provide it the most value. We call this the value stream and we can measure it by looking at how easily you can go from an idea to delivering a valuable product or service (or improvement) to your customer.

A value-stream focused enterprise journey

All too often we see enterprise customers take a waterfall approach to their cloud journey. The risk is a drawn out process that spends too much time in the UHL area — and delivering something that doesn’t meet the needs of its consumers (delivery teams / developers). This takes focus away from the primary objective of the business — delivering a valuable service to your customer. It not uncommon to see these types of projects take many months to complete with no applications deployed.

What’s our recommended approach?

• Deliver in smaller increments so that learnings can be fed in as improvements in future iterations
• Optimise for building & deploying apps
• Offload as much UHL as is possible/practical for your business

This approach has strong ties back to Agile, developing a minimum viable/loveable product (MVP) & continuous improvement driven by a shorter feedback loops.

Letting AWS do the heavy lifting

Using a solution like AWS Landing Zone takes the undifferentiated heavy lifting out of your organisation, allowing you to focus on delivering value to your customers. AWS provides a CloudFormation template that will create a Landing Zone comprising four AWS accounts as shown in the following diagram:

New accounts can be created via the Account Vending Machine, which is a Service Catalog Product created by the Landing Zone. It includes the Security Baseline defined by CloudTrail, Config, VPC FlowLogs, and IAM, notifications.

During the nearly four hour setup time you can lean back and have a look in CloudFormation and CodePipeline to see what resources are created:

Lessons Learnt using AWS Landing Zone

During setup there are still some things that need to be considered or done manually:

1. Master Account Creation — Is still a manual process and you need to go through the phone number verification process either via SMS or a phone call.
2. Increase Two Service Limits — before you run the CloudFormation template. The two limits that need to be increased are the maximum number of accounts (maybe start with 10) and the maximum number of Stack Sets needs to be larger or equal 50.
3. Email Addresses — You need an email address (or distribution list) for each of the four AWS accounts for the setup process. You cannot reuse email addresses that are already AWS root account holders.
4. Around 4 Hours — is how long the actual deployment process takes.
5. CloudTrail, Config, VPC FlowLogs — are turned on and you will be immediately charged. When we tried it the cost was around AUD 180 — obviously this also depends on the exchange rate.
6. MFA — Having four new account also means that you have four root account holders. Don’t forget to enable MFA straight after the setup.

Things that we learned after we deployed and had been up and running a while:

1. Account creation for workloads — is super-easy out of AWS Organizations and the billing can be linked to the Master Account
2. Service Catalogue — is a very powerful tool. It enables you to create portfolios for your organisation and add products to the portfolio (i.e. AWS services). By doing this you can centrally control access to services.
3. Drift Management — is per default disabled and you need to enable it for CloudFormation Stacks.
4. Direct Connect support for Transit Gateway — is only available in four regions so far and not yet in Sydney. If you want your paired VPCs (for example in workload accounts outside the Landing Zone) to talk to on-premise then you will need to look for an alternative solution: E.g. via the multi-account Direct Connect feature, which requires the peered account to be part of your AWS Organizations billing setup; or via a virtual private gateway in the peered workload accounts.
5. Level of complexity — The Landing Zone follows deployment best practices. E.g. Keep log files in a seperate account and so on. This brings some complexity and that includes the route tables for your on-premise connectivity after the Direct Connect setup.
6. Logging — CloudTrail, FlowLogs and Config give you a good coverage for your AWS footprint. If you deploy any applications into your Landing Zone you will still need and application logging capability and alerts for your app.
7. Cost optimisation — You still require services like Trusted Advisor to make sure you don’t have unused resources.

Our Tips and Conclusion

We recommend keeping it simple and as much out-of-the-box as possible. Run any other custom built add-ons later on to make upgrades easier.

Review Trusted Advisor after the setup to see if you are being billed for t resources. Stick to the best practices and manage all changes via code — CloudFormation is your second best friend — after AWS Landing Zone, of course.

AWS Landing Zone is not a silver bullet that fits every single use case. The deployment architecture brings some complexity and is therefore better suited for multi-account environments. You will still need to apply best practises and the Well Architected Framework whitepaper will provide you some good guidance. And remember: UHL (undifferentiated heavy lifting) does not help your core business: Friends don’t let friends build Landing Zones.

Authors: Gerald Bachlmayr, Andrew Khoury