Beyond the Launchpad: Rethinking Cloud Landing Zones for Modern Enterprises

But what is a landing zone?

Landing Zone, also called a cloud foundation,  is a starting point from which an organization can quickly launch and deploy workloads and applications with confidence in the security and infrastructure of the environment.
A landing zone spans multiple areas and includes different elements, such as identity provisioning, resource management, security, and networking.

The idea of the landing zone is that it removes some configuration needs from the use-cases and adds things like governance and guardrail patterns on top.

Overall, a cloud landing zone helps organizations accelerate their cloud adoption while maintaining governance and best practices.

Diagram 1. shows an example implementation of a landing zone, it shows the different landing zone components, like:

• Cloud Identity and IAM for identity management
• Cloud Route, Cloud NAT and Cloud VPN as Networking components and
• Monitoring and Cloud Audit Logs are part of observability.

Diagram 1. Shows the typical elements of the Landing Zone

Currently available landing zones within SEB

Throughout the last six years of SEBs Cloud journey we have developed different flavors of these landing zones, namely:

1. Sandbox Landing Zone
2. Cloud Native Landing Zone
3. Data Science Workbench (DSW)
4. Cloud Data Analytics Platform (CDAP) 

Let's see when and how each of these can be used.

1. Sandbox Landing Zone

The Sandbox Landing Zone serves as a safe and accessible playground for experimenting with Google Cloud Platform (GCP) services. It offers a risk-free environment where users can explore, test ideas, and gain hands-on experience without affecting production systems.

Designed primarily for users new to GCP or cloud computing, the Sandbox provides a simplified setup consisting of a single GCP project. This design minimizes complexity, allowing users to focus on experimentation rather than project structure or governance.

To ensure security and cost control, only test data is permitted within the Sandbox. This restriction helps protect sensitive information while enabling users to freely test configurations and services.

Additionally, the Cloud Foundation team has implemented a sandbox cost cap, ensuring that spending cannot exceed five times the project’s allocated budget. This safeguard prevents unexpected cost overruns and promotes responsible cloud usage.
The Sandbox Landing Zone is temporary by design, with a 90-day lifecycle that can be extended upon request. This encourages short-term experimentation and efficient resource management.

Ordering and decommissioning a sandbox environment is intentionally simple – users can create and discard sandboxes easily, maintaining flexibility and agility.

All resource management within the Sandbox is performed through ClickOps in the Cloud Console, providing an intuitive experience for users with no prior GCP knowledge.

In essence, the Sandbox Landing Zone empowers new cloud users to test ideas quickly, safely, and at low cost, helping them build foundational knowledge before progressing to a Cloud Native Landing Zone for more advanced, production-ready solutions.

2. Cloud Native Landing Zone

The Cloud Native Landing Zone is designed to support the development and deployment of production-grade systems in the cloud. It provides the foundation for building robust, secure, and scalable applications, and serves as the primary environment for SEB’s feature teams.

This landing zone targets users with prior GCP experience who are ready to move beyond experimentation and manage full-fledged, production-ready workloads.

Each Cloud Native Landing Zone includes three core GCP projects, structured to support the complete application lifecycle:

• Development (DEV): For feature development and initial testing.
• Acceptance (ACC): For integration and acceptance testing prior to release.
• Production (PROD): For live, production deployments.

In addition, there are five supporting utility projects that enhance automation, monitoring, and security:

• One CI/CD project for managing pipelines and deployments.
• One monitoring project for observability and operational insight.
• Up to three optional key management projects, used when handling highly confidential data requiring additional isolation and control.

In this setup, test data is used in the DEV and ACC environments, while real data is permitted only in the PROD project – ensuring secure, realistic testing before production rollout.

The Cloud Native Landing Zone is a permanent environment, providing a stable and maintainable framework for continuous development and long-term operations.

To balance flexibility and governance, ClickOps is allowed in the DEV environment for ease of experimentation, whereas Infrastructure as Code (IaC) is mandatory for managing resources in ACC and PROD. This approach enables advanced configuration, automation, and consistency across deployments.

In summary, the Cloud Native Landing Zone delivers the structure, control, and scalability needed for SEB teams to build and operate cloud-native applications with confidence.

3. DSW Landing Zone

The Data Science Workbench (DSW) landing zone is a dedicated environment tailored for exploratory data analysis and machine learning development using production data. It equips data scientists and analysts with the tools they need to explore datasets, perform analyses, and develop machine learning models across all data sensitivity classifications.

Similar to the sandbox, the DSW serves as a temporary testing environment, but it is specifically designed for data science activities. Each DSW landing zone consists of a single GCP project focused entirely on supporting data exploration and model development. With proper data owner permissions, users can work with real datasets to generate insights and build models.

The DSW is temporary, with a standard lifetime of 180 days, enabling focused project development. Extensions are available if needed. After validating ideas and developing initial models, users are encouraged to transition their work to a Cloud Native Landing Zone for long-term production deployment.

4. Cloud Data Analytics Platform (CDAP)

The primary objective of the Cloud Data Analytics Platform (CDAP) is to democratize data analytics across SEB by providing teams with dedicated spaces for landing, curating, processing, analysing, and serving data.

CDAP enables the creation of data products using curated data applications – essentially reusable templates that allow teams to efficiently develop new data products.
 
The platform consists of a total of 24 projects. As illustrated in Diagram 2, each project includes three environments: Development (Dev), Acceptance (Acc), and Production (Prod).

Diagram 2. Shows the different CDAP components

One important consideration is that the enabled services vary across the CDAP projects. For example:

• The Processing project includes only data processing services, such as Dataflow and Dataproc.
• The Curated project includes only services like BigQuery and Data Catalog.

Similar to the Cloud Native Landing Zone, test data is used in the Dev and Acc environments, while real production data is accessible in the Prod projects (with proper permissions).

You can see the different Landing Zones with all of their notable capabilities in Diagram 3.

Diagram 3. Shows the different Landing Zones with their capabilities

Finding the Right Balance: How Many Landing Zones Are Enough?

It’s a fair question to ask: Do four landing zones truly meet the needs of the entire company?

For several years, SEB operated with just two landing zones – the Sandbox and the Cloud Native Landing Zone. These provided a solid foundation for most use cases. However, as the organization’s cloud adoption matured, the demand for more specialized environments grew. This led to the introduction of the DSW Landing Zone at the end of 2022, followed by CDAP in 2024.

This expansion highlights an important tradeoff: the balance between flexibility and manageability.

By increasing the number of landing zones, we can offer more tailored solutions for specific business or technical needs. At the same time, each additional landing zone brings added complexity – more platforms to maintain, more operational overhead, and a greater potential for user confusion when choosing the right environment.

Looking ahead, our goal is to refine this approach. Rather than continuously building new landing zones, we plan to leverage and extend existing ones through modular templates and reusable components.

This strategy will enhance maintainability, streamline operations, and still allow for the level of customization required to support diverse use cases across SEB.

Conclusion

Each GCP landing zone serves a distinct purpose, catering to specific user needs and project goals. The Sandbox is ideal for newcomers exploring cloud technologies, the Cloud Native Landing Zone supports experienced developers building production applications, the DSW Landing Zone provides an environment for machine learning ideation and development, and CDAP enables users to create and manage data products within the cloud.

By understanding these landing zones, organizations can better leverage cloud capabilities to drive innovation and efficiency in their cloud initiatives. Landing zones are a fundamental component of any technology company’s cloud journey and should be tailored to meet the organization’s evolving needs.

The number and type of landing zones are not fixed and can change over time. Early in a company’s cloud adoption, one or two landing zones may be sufficient. As cloud maturity grows, however, there may be a need for more specialized environments. While customization can be achieved by creating additional landing zones, an alternative approach is to reuse existing landing zones and apply different templates on top of them to achieve the desired functionality. Which approach proves more effective will depend on the company’s evolving requirements and experience.

Gergely Szilágyi
Product Owner of the Google Cloud Core Platform team