Within the Cloud: A Personal Take on Enterprise Landing Zone Challenges

I’m a Senior Technology Architect at Accenture, based in Portugal. My role involves technology architecture, helping select tools, define procedures, norms and patterns to apply to each challenge that clients face in their day-to-day business activities. I also take part on the design and development of Cloud solutions on AWS and have developed fundamental knowledge and know-how on the other major CSPs (certified in Google and AWS as Professional Architect and Azure fundamentals).

At the heart of my personal take in this article is the importance of the Landing Zone in any Cloud environment as a mechanism for governed, compliant enterprise workload implementation by product or project teams. For all purposes, I’ll use AWS as the basis of my point-of-view going forward.

To start, what is an Enterprise Landing Zone (ELZ)?

An ELZ is the foundational building block in Cloud Computing that represents a pre-configured, well-architected, multi-account cloud environment designed to serve secure, scalable and governed starting point for enterprise organizations to be able to create and manage modern workloads on a given CSP. It is a definition that is independent of any CSP, and any CSP has its own variation on the definition.

These building blocks aim to allow scalable and repeatable growth through standardization and automation. In any well designed and implemented ELZ, security is built-in through guardrails and controls. The ELZ should be operational ready with a cross-account environment that support centralized logging and observability on all actions, such as management and data events. Lastly, it should enforce governance through policies, tagging and well-defined boundaries.

On AWS, the ELZ is based on a set of key elements:

a) AWS Organizations and the account strategy, what are the workloads Organizational Units (OUs) and accounts’, through Control Tower and Account Factory for Terraform;

b) the FinOps strategy and the tagging mechanisms applied or foreseen cost categories;

c) guidelines to deploy the cross-account observability and tools to be used or integrated;

d) which is the Identity Provider, how to integrate with on-premises or other Clouds authentication mechanisms, guardrails and controls to apply;

e) what are the Virtual Private Clouds (VPCs) to address workloads, how are networks segmented and their sizes, what are the models to inspect traffic, such as centralized vs decentralized, tools and platforms to integrate with and how to monitor and design inbound and outbound traffic.

1/ An ELZ should be designed in a minimalistic fashion and allow to scale

In the process of designing ELZs, it is key to state what may seem obvious, start small and leave room for improvements avoiding too strict decisions that can lead to rework later.

Don’t follow the temptation of transposing your current architecture into the Cloud. Each organization has it’s own data center and may already have it’s own Cloud provider it started using early without a proper ELZ design and implementation. It’s key to disregard these architectures whenever possible. Set the key requirements to follow for Cloud nativa, while adapting to needs of lift and shift migrations if they are considered.

In my experience, organizations have their existing architectures top-of-mind, and tends to influence design of a new ELZ. Avoiding that is achievable as a result of lenghty discussions that might minimally the impact the final design, but end up being necessary as part of the (re)skilling process which leads me to my second conclusion.

2/ An ELZ requires changes in behaviors, processes and culture (a.k.a. people)

An ELZ is an opportunity to revise the current infrastructure and requires investments upfront. This leads me to conclude it’s a bit of a cultural shift, more than an organizational one.

Without this, what will happen is that the change will be harder, slower and more expensive.

From a consultant point-of-view, this is an opportunity to position services. From a client perspective, it’s an opportunity to reorganize the skills, the processes and the behaviors.

Without both, it’s a lose-lose deal.

My experience with Software Engineering tells me an ELZ is like building a framework that follows best practices, it’s secure, scalable, observable and deploys guidelines on how to use. Without its implementation, in forms of workload definitions, it’s useless. It’s like an Infrastructure Engineer being told to build a monitor dashboard that connects to a infrastructure that he doesn’t know. What to monitor? Is it virtualized? What are the architectural capabilities that the infra responds to? Who is the business owner? You have these answers before monitoring. In the same way you have features before developing an application. Which leads me to the third topic.

3/ An ELZ requires workloads (or at least its planning)

Designing the ELZ without the clear direction of which workloads will be migrated or transformed into the Cloud makes the process harder.

If the organization hasn’t already planned with the current workloads, defined the strategy at least, this will surely impact your design negatively.

Prepare to start discussing what are the key applications to migrate, which are the fundamental elements that should be considered before starting the design.

Conclusion

An Enterprise Landing Zone on the Cloud is a mandatory element for application implementation or modernization in Cloud and it requires a fundamental culture and skills shift at IT organizations. Organizations should start with a secure and simple set-up, and scale the sophistication of the ELZ progressively alongside adoption of skilled (or re-skilled) professionals, implementation of new workloads and migration of existing workloads to the ELZ.

Conclusion

An Enterprise Landing Zone on the Cloud is a mandatory element for application implementation or modernization in Cloud and it requires a fundamental culture and skills shift at IT organizations. Organizations should start with a secure and simple set-up, and scale the sophistication of the ELZ progressively alongside adoption of skilled (or re-skilled) professionals, implementation of new workloads and migration of existing workloads to the ELZ.