What is a cloud landing zone

In the past seeing a company with a single monolithic cloud account was pretty normal. However, over years things have changed and nowadays modern infrastructures are often composed of several, dozens or even hundreds of individual cloud accounts as the company scales. This faces engineers with a problem of managing them concisely and reliably.

Ideally, each account that acts as a building block for a cloud presence of a company should contain a minimum security baseline, centralized log management, auditing, governance, and networking setup. Accounts should be built from the ground up according to the best practices and provide that baseline features out of the box making the process of adding a new account to the organization trivial. That baseline is what we call a landing zone.

Building a landing zone enables companies to efficiently utilize the multi-account structure in the cloud and that in turn enables quick growth through repeatable processes and automation. Therefore design and implementation of a landing zone should be one of the first steps that the company undertakes when preparing for the migration of their workloads.

Let’s dwell on landing zones in more detail. Although the concept of the landing zone is the same across all the hyper-scale cloud providers in this post I will discuss them based on usual Amazon Web Services implementations.

Security

A landing zone should provide a centralized Identity and Access Management solution. A typical setup consists of a single dedicated account where all user accounts are kept, usually integrated with a third-party identity provider like Microsoft Active Directory. Platform users would log in to that special account and use Cross-Account Roles to access all the other accounts. Using this approach users are kept in a single, centrally managed place that enables tight password rotation schedules, easy procedures for adding or removing users from the platform, or performing in-depth access auditing.

A good landing zone should also define a set of roles that will be used by engineers and administrators to manage the platform. They should be created according to the least privilege principle and reflect the organization’s engineering structure — an example roles layout might look as follows:

• DeveloperRole — a basic role for developers allowing read-only access to an application, compute, storage and database services on production and write access on development accounts,
• SecurityRole — a special role for security folks that gives access to various security and auditing services like AWS Config, AWS GuardDuty and so on,
• AuditRole — a special role giving access to audit logs (e.g. centralized CloudTrail) in logging and auditing account,
• OperatorRole — a basic role for DevOps/CloudOps Engineers used to manage the cloud infrastructure, provides administrator-level access to the majority of the services in the application accounts.

Logging and auditing

Usually, a landing zone contains two special accounts called e.g. audit and logging. The former account is used as centralized storage for the AWS CloudTrail data, S3 access logs, VPC flow logs, and other important data for security and auditing teams. The latter is used as centralized storage for application logs — all accounts in an organization are sending logs (using e.g. CloudWatch+Kinesis) to that central account where logs might be ingested to software like ElasticSearch allowing querying and running analytics.

The design of a landing zone should naturally provide the mechanisms for transferring the audit data or logs to proper data.

Shared Services

A shared services account is used to deploy various tools that are usually shared across the entire organization. An example of a service that gets deployed in Shared Services very often is the Microsoft Active Directory cluster.

Networking

A landing zone should provide a basic networking layout allowing connectivity between individual systems in your cloud organization. As part of a basic networking setup, a typical landing zone might define a special Transit account that will be hosting AWS TransitGateway. Other accounts would be attached to that TransitGateway and the routing would be configured using proper TransitGateway’s Route Table entries. Some landing zones strictly define the topology for the network in Cloud — for example, you can enforce Hub’n’Spoke model through the use of central TransitGateway.

The networking setup might also include things like VPC peerings, VPN/DirectConnect attachments, etc. Careful planning of your organization backbone network will save you a lot of troubles in the future usually introduced by chaotic setup composed of all the imaginable networking services (VPNs/Peerings) mixed with some random Route Tables and NACLs.

Organization and billing

Your AWS landing zone will usually be built around the concept of AWS Organization which is a higher-level entity that aggregates multiple AWS accounts that are centrally managed. In Organizations, you typically designate a single account as a payer account. This allows you to embrace the Consolidated Billing — all the payments are made from one central place and all the invoices are available in a single console. It greatly simplifies the management when you have several, or even dozens, of accounts.

During the design phase think about your organizational structure. For example, if you would like to see how much money each organizational unit, or an independent team, spends on AWS you can create for them a separate account. This will save you a lot of tags based billing analytics since to find out how much they spend you just look at the “Per-account billing” feature in Consolidated Billing that groups the billing per account.

Don’t be scared to go with a multi-account structure. For example, nowadays in AWS creation of a new account in your Organization is just an API call and the process can be entirely automated. With proper landing zone design and automation around it, you will be able to easily spin up and configure new accounts. And keep in mind that multi-account structure scales way better than single account structure.

Summary

A good landing zone is a very important thing in your company’s cloud journey. If done well it will enable smooth management and quick growth for your cloud presence.

Do you need help in designing a good landing zone for your company? Contact us at contact@kscloud.pl and we will be more than happy to help you!