AWS Landing Zone

Say, you are a general who needs to plan landing of helicopters in the middle of war zones. What will be your considerations?

• Terrain

• Safety

• Markings

• ATC availability

• Proximity to warzone

• Support teams

• Covering fire teams

• Strategy teams

• Information

• Etc.

There are a lot of teams that have different purposes and different command. And an effective management means effective deployment.

A bit of a heavy example, but much like war zone deployments, an organization needs to be mindful of how quickly, effectively, efficiently, and securely it can deploy its requirements and where.

What is a Landing Zone in Cloud? How Does AWS define it?

A very common answer we get for landing zone is where all the infrastructure that you want will land in the cloud of your choice. While the answer is not entirely wrong, there is more to it.

As the scope of your organization grows, this becomes the one stop that makes or breaks how easily you can scale up, securely, with proper networks, easy administration, and faster deployments. And this is precisely more than one solution that fits the requirements. Each organization can have different requirements.

AWS defines a landing zone as a well-architected, multi-account AWS environment that is scalable and secure. This involves technical and business decisions to be made in accordance to the account structure, network and access management.

 

What are the valid questions to be asked?

As a thumb rule it is always better to have multiple accounts for a bigger organization.

AWS prescribes the following questions to create additional AWS accounts if you answer yes to any of the following questions:

• Does your business require administrative isolation between workloads?

• Does your business require limited visibility and discoverability of workloads?

• Does your business require isolation to minimize the scope of impact?

• Does your business require strong isolation of recovery and/or auditing data?

Let’s dig a little deeper into understanding the above questions.

The basis is simple yet complicated:

• What kind of isolation is the organization looking for?

  • Workload/ Development lifecycle – An environment-based approach (Eg: DEV, SIT, QA, PRD)

  • BU – A business unit level separation (Eg: Admin, Testing, Developer)

  • Organizational level – A organization pyramid level separation (Eg: Managers, Associates, Snr Developers)

  • Data sensitivity – Data sensitivity level distinction (Eg: Public, Private, Confidential)

  • Etc.

• What is the visibility of your workload?

  • Who can see what? – As the question suggests, this means limiting who can see what.

• Do you need different limits on different workloads?

  • Need to put quotas on certain groups/BUs? – Different groups can have different requirements

  • Cost restrictions (POCs/experimental projects)? – Some requirements need to have a capex set so that the billing is not extended beyond expectations

  • Etc.

• What are your audit requirements?

  • Isolate audits on certain accounts? – Some accounts do not need to know the audits

  • Specific accounts with audit access only? – Some accounts only need to know the audits

  • Etc.

• Requirements for specific resource types?

  • Requirement of HA? – What is the type and exact requirement for HA or how much of a failure is accounted for.

  • Requirement of DR? - RPO and RTO.

  • Requirement of higher performance high cost infra? – Requirement of HPCs, etc. Usage of Reservations at an individual account level.

  • Etc.

• What is failure for you?

  • Expected security threats. - Different applications might have different security profiles, requiring different control policies and mechanisms around them.

  • Disaster scenarios – What will happen when a disaster happens. Can you sustain it and how to recover.

  • Impact zone/blast radius – If attacked, can we reduce the impact and how we can reduce it.

  • Etc.

• How quickly can you deliver?

  • Automation requirements – Creating repeatable, consistent, and reliable delivery. What is the level required?

  • Small but continuous improvement – Ability to deliver in small but solid increments/improvements.

  • Etc.

Summary

The above questions are valid for any Landing Zone discussion. If you are a Cloud solutions Architect, then ideally create a triage document to understand the requirements and keep improving with lessons learned.

For the AWS Landing zone we can have 2 ways of deployment:

• AWS Control Tower – AWS managed service that lets you create a Landing zone with AWS-provided guardrails and compliance policies applied by default. - Will discuss it in detail in another blog entry on how to?

• Custom-built landing zones – This will be more customizable. A lot more responsibilities. – Will follow-up with an example blog soon.

Images Courtesy:

DALL-E 3