Migrating to AWS: What is a Landing Zone and Why is it Essential to Success?

Having assisted hundreds of customers in the last 3 years, we have discovered a recurring theme: organisations are commonly finding themselves in difficulty, following what they previously considered to be a “successful” migration to the Cloud.

Occasionally, this occurs immediately after go-live.  Perhaps more concerning is that we have found a growing number of customers experiencing problems several months after completing their migration, as they attempt to modernise or scale their migrated workloads.  Unpicking these issues can be technically challenging and often disruptive to a business.

The success of a migration project cannot be measured solely by a workload being able to operate in the Cloud; there are many more considerations. Having the right Landing Zone, for example, is always key to every successful AWS migration delivered by Ubertas Consulting.

Download Now: Maximise Your Cloud Benefits with AWS
[Guide]

The AWS Landing Zone

Establishing a well-considered Landing Zone de-risks your migration and is a foundation for all aspects of operating effectively on AWS.  Being Well-Architected is vital from the very start; the Landing Zone should adhere to the principles of the AWS best practice “Well-Architected Framework” and provide, without compromise, the fundamentals of security, governance, and compliance, whilst offering enough scalability and flexibility to cater for large-scale growth within your enterprise.

The core constituents of the AWS Landing Zone are:

• Control Tower
• Account Factory
• AWS Organizations
• AWS Identity and Access Management (formerly AWS SSO)

1. Control Tower (Landing Zone)

AWS Control Tower encompasses a group of enterprise governance and compliance tools, hence its name.

All these feature’s pivot around the ‘Landing Zone’ – a managed service providing blueprint standards for creating, configuring, and governing your AWS Organization and the AWS accounts within it. The Landing Zone must be enabled once per AWS Organization – a process that usually takes around 60 minutes – before further steps can be taken.

Enabling the Landing Zone will apply numerous guardrails to your AWS Organization, consisting of detective controls (AWS Config rules) and preventative controls (Service Control Policies (SCPs)). AWS CloudTrail will also be deployed.

2. AWS Account Factory

Once Landing Zone is enabled, Account Factory can be used to create new AWS accounts from a configurable baseline or standard. A common pattern is to employ Account Factory Terraform or Account Factory customisations; this ensures that customer-authored changes to Account Factory are kept with Infrastructure-as-Code (IaC) control.

3. AWS Organizations

AWS Organizations house your AWS accounts and any list of Organisational Units (OUs) that you define. You can use OU’s to organise your accounts by business department or function, by customer, or by environment, for example.

4. AWS Identity & Access Management (IAM)

When operating multiple accounts within a growing AWS Organization, it is a strongly recommended best practice to provide access via a centralised Identity Provider (IdP), with federated access between accounts.  AWS offers a native SSO capability, which is SAML and SCIM compatible, that your teams can use to securely access your AWS accounts based on their role. IAM roles can be matched to their job roles, or against a temporary requirement (i.e., least-privilege access policy).

If you already have an Identity Provider (IdP), then you can simply integrate with that via SAML. SCIM can be configured to automatically synchronise your users and groups into AWS, where you can assign SSO roles ad hoc.

A Solution Architects View: 10 important technical attributes of a landing zone

Our team of experienced Solution Architects at Devoteam, have listed the 10 most important technical attributes of a Well-Architected Landing Zone:

1. Employing Transit Gateway (TGW) networking between AWS accounts
2. Creating a single ‘network’ AWS account to route all outbound traffic via a single Network Address Translation Gateway (NATGW)
3. Enforcing encryption-at-rest and using a centralised AWS account to manage KMS keys
4. Using AWS security services to govern and monitor all AWS accounts
5. Governing how VPC’s (Virtual Private Cloud) can be configured, such as preventing the use of public subnets if they are allowed, for example
6. Configuring Account Factory to provision new AWS accounts to an agreed standard
7. Provisioning SSO access across your AWS accounts
8. Using a centralised VPN to access private AWS resources
9. Inviting existing customer AWS accounts to safely join your AWS organisation
10. Adding Service Control Policies (SCPs) to govern your whole AWS organisation or selected Organisational Units (OUs)

Each of the above could warrant a blog post of its own.  For now, we would recommend reading the following:

• Network Gateway – AWS Transit Gateway – Amazon Web Services
• NAT Gateway Use Cases – Amazon Virtual Private Cloud
• Key Usage — AWS Key Management Service — Amazon Web Services
• VPC with Public and Private Subnets (NAT) – Amazon Virtual Private Cloud
• What is IAM Identity Center? – AWS IAM Identity Center (Successor to AWS Single Sign-On)

Conclusion

When you are considering your next AWS migration, it is vital that you take the time to plan and understand your target operating model and design a Landing Zone that suits your exact needs. You should leverage the Well-Architected Framework and the vast array of AWS guidance and experience in the AWS community. If you adopt this approach, then you will avoid the challenging task of correcting your AWS workloads post-migration, along with the risks associated with doing so.