Friends Don’t Let Friends Build Landing Zones

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
  • 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

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”.

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.

  • 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

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:

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.
  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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Gerald Bachlmayr

Gerald Bachlmayr

Principal Cloud Architect at Cuscal Payments