Lazy Tab Navigation Concept

How to Implement a Lazy Tab Navigation System in Angular

How to Implement a Lazy Tab Navigation System in Angular

In this blog post you’ll learn why you’d want and how to implement a lazy tab navigation system in Angular.

Why go for a lazy tab navigation system?

We at meshcloud provide a solution to manage cloud access, users and projects across cloud platforms. One of our main goals is to make the interaction with the cloud as easy as possible. Besides that we want to decrease the effort of management workflows to a minimum because cloud management is a complex topic with a lot of items to manage.

But how do we want to achieve this?

It is mostly a user facing topic. Therefore we’ve improved user experience in our Angular SPA (Single Page Application) and decreased the necessary interactions for specific management workflows. It is important to navigate between the sections without lagging or freezing.

It is really easy to say that the improvement of the user experience is the key. But what makes the difference to support user friendly behavior?

We’ve invested a lot of time to find a proper solution. We came up with a lazy tab navigation system is what we need which covers all mentioned challenges.
Lazy Tab Navigation Example

What is a lazy tab navigation system?

As the name suggests, the idea is a tab navigation system in which the content is loaded lazy. This will enable us to implement scalable views with a lot of clearly separated sections. But first to the general tab navigation system.

1. Tab navigation system

The tab navigation system is a central component which coordinates the tab creation and holds the tab state. We’ve decided to handle the tab creation based on the route config. This makes total sense because the routes are uniquely identifiable. This means we can automatically prevent the creation of multiple tabs which correspond to the same section. Besides that we have the possibility to create deep links to specific tab sections. This enables us to reference specific tab sections within other views. In general we’ll determine the tab state based on the activated route.

2. Lazy Loading

The other aspect is the lazy loading. Lazy loading is a central Angular feature. It is a design pattern that loads NgModules as needed. For comparison, there is the option to load NgModules eagerly. With eager loading all NgModules are loaded when accessing the web application. This increases the bundle size and for large applications it is not a best practice due to the load time. Eager loading is for a tab navigation system not an option because we’ve a lot of different sections. And we want to allow multiple sub-sections. This would mean that we load every section content up front. From the performance and UX perspective this is not a good approach.

If we now combine the tab navigation system approach with the lazy loading feature we’ll get a really flexible and scalable pattern. The tab navigation system takes the role of describing the context. It is kind of a container which defines the available routes and manages the tabs. In conjunction with the lazy loading feature, we are able to load the content of the respective tab in a dedicated manner.
Lazy Tab Navigation Concept

What is necessary to implement the lazy tab navigation system?

We’ve got an overview about the lazy tab navigation system from the conceptual perspective. Now we’ll take a look at the technical realization and how we’ve implemented this approach.

We need a shared component which covers all criteria of the tab navigation system. This includes the tab creation based on the router config and tab selection based on the activated route. We call the component RouterOutletNavComponent.

Besides that we’ve defined an interface which describes each tab:

  • displayName
  • routerLink
  • selected

Our interface declares additional properties. For example to show/hide a tab depending on a specific condition and to attach a badge with countable information. But this is not relevant for the general implementation. So we’ll leave it out for now.

We call the tab interface RouterOutletNavTab.

Sure, we didn’t implement the tab creation and tab selection logic within the component. We’ve implemented a service that exposes the functionality. This is a best practice to increase modularity and reusability. The component should only handle the user experience. With a clear separation we’ll also increase the testability of the functionalities. This approach should be followed every time ;)

We call the service RouterOutletNavService.

Now let's combine the RouterOutletNavComponent, RouterOutletNavTab and RouterOutletNavService. ****

@Component({
  selector: 'mst-router-outlet-nav',
  templateUrl: './router-outlet-nav.component.html',
  styleUrls: ['./router-outlet-nav.component.scss']
})
export class RouterOutletNavComponent implements OnInit, OnDestroy {

    @Input()
  public readonly styleClass: RouterOutletNavStyleClass = 'nav-child';

  public tabs: RouterOutletNavTab[];

  private sub: Subscription;

  constructor(
    private readonly router: Router,
    private readonly activatedRoute: ActivatedRoute,
    private readonly routerOutletNavService: RouterOutletNavService
  ) {
    this.tabs = this.routerOutletNavService.initializeTabs(this.activatedRoute);
  }

  ngOnInit() {
    /**
     * Select initial tab and navigate to child route.
     */
    this.setupInitiallySelectedTab()
      .subscribe((routerLink: string) => this.routerOutletNavService.selectTab(routerLink, this.tabs));

    /**
     * We listen to the router events to select the specific tab.
     */
    this.sub = this.router.events
      .pipe(
        filter(x => x instanceof NavigationEnd),
        switchMap((x: NavigationEnd) => {
          /**
           * If the firstChild is available then we don't determine the first child tab.
           */
          if (this.activatedRoute.firstChild) {
            return of(x.urlAfterRedirects);
          }

          /**
           * If child route doesn't exists then we'll determine the child route and select the tab.
           */
          return this.navigateToFirstChildRoute();
        })
      )
      .subscribe({
        next: (routerLink: string) => this.routerOutletNavService.selectTab(routerLink, this.tabs)
      });
  }

  ngOnDestroy(): void {
    this.sub.unsubscribe();
  }

  private setupInitiallySelectedTab(): Observable<string> {
    /**
     * If childs are applied for example in case of redirection then we'll use the existing destination url.
     */
    const currentUrl = this.router.url;
    if (this.activatedRoute.firstChild) {
      return of(currentUrl);
    }
    return this.navigateToFirstChildRoute();
  }

  private navigateToFirstChildRoute(): Observable<string> {
    return this.routerOutletNavService.findFirstChildRoute(this.tabs)
      .pipe(
        take(1),
        /**
         * This side effect is necessary to apply the determined tab route.
         */
        tap((routerLink: string) => {
          const extras = {
            relativeTo: this.activatedRoute,
            replaceUrl: true
          };

          this.router.navigate(['./', routerLink], extras);
        })
      );
  }
}

We want to support not only a tab navigation system. We want to support a lazy tab navigation system. So it is necessary to embed a RouterOutlet into the tab container. For the styling we use Bootstrap as external dependency.

The corresponding HTML file would look like this:

<div [ngClass]="styleClass">
  <ul class="container nav nav-tabs">
    <ng-container *ngFor="let t of tabs">
      <li class="nav-item">
        <a class="nav-link" [class.active]="t.selected" [routerLink]="[t.routerLink]" [id]="t.routerLink">
          {{t.displayName}}
        </a>
      </li>
    </ng-container>
  </ul>

  <div class="tab-content p-4">
    <router-outlet></router-outlet>
  </div>
</div>

It is a valid use case to nest multiple lazy tab navigation systems. But for simplification we allow only one additional layer. Therefore we’ve defined two different css classes ‘nav-root’ and ‘nav-child’ to tell the levels apart.

We call the style class type RouterOutletNavStyleClass.

export type RouterOutletNavStyleClass = 'nav-root' | 'nav-child';

Very well done. We've implemented our shared lazy tab navigation system.

Now we have to feed the tab navigation system with the corresponding data. The information about the router link and if a tab is selected will be determined based on the route config and activated route. It is really important to declare the available routes with the lazy loading approach from Angular.

But how do we get the display name of each tab? Sure, we could use the route path name. But the name is our uniquely identifiable name. It could also be a human unreadable string. From the user perspective, it is not a good approach to use an identifier string as tab display name. Besides that we need a way to determine some data up front. Keep in mind, besides the display name we’ve also a condition and badge information in place. So we need the possibility to attach specific session data to each tab. Therefore we need to declare a resolver which returns a RouterOutletNavSessionData observable.

We call the abstract resolver class RouterOutletNavSessionResolver.

export interface RouterOutletNavTabData {
  displayName: string;
}

export interface RouterOutletNavSessionData {
  [key: string]: RouterOutletNavTabData;
}

export abstract class RouterOutletNavSessionResolver implements Resolve<RouterOutletNavSessionData> {

  abstract resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<RouterOutletNavSessionData>;

}

Now we’ve everything in place to use the lazy tab navigation system within a specific use case.

Lazy tab navigation system in action

At this point it makes sense to apply the lazy tab navigation system to one of our use cases. We’ve mentioned at the beginning that we provide a solution to manage cloud tenants. This includes for example the customer management. Within a customer we can manage projects, users, financials and much more. So it makes total sense to use the lazy tab navigation system with one additional level to make the management as easy as possible.

We’ll only consider the customer root level. The nested levels are out of scope for now. But in general they follow the same approach.

Our top level component would be the CustomerManagementComponent. This component declares the RouterOutletNavComponent within the HTML file and applies the ‘nav-root’ style class.

...
<mst-router-outlet-nav styleClass="nav-root"></mst-router-outlet-nav>
...

Then we’ll add all available routes to the CustomerManagementRoutingModule. Besides that, it's important to add a CustomerManagementNavSessionResolver to determine the session data up front. This provides our basis for the tab creation.

@Injectable({
  providedIn: 'root'
})
export class CustomerManagementNavSessionResolver extends RouterOutletNavSessionResolver {

  resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<RouterOutletNavSessionData> {

    const sessionData = {} as RouterOutletNavSessionData;

    sessionData['projects'] = this.getProjectsNavTabData();
    sessionData['access-control'] = this.getAccessControlNavTabData();
    sessionData['financials'] = this.getFinancialsNavTabData();
    ...

    return of(sessionData);
  }

  private getProjectsNavTabData(): RouterOutletNavTabData {
    return {
      displayName: 'Projects'
    };
  }

  private getAccessControlNavTabData(): RouterOutletNavTabData {
    return {
      displayName: 'Access Control'
    };
  }

  private getFinancialsNavTabData(): RouterOutletNavTabData {
    return {
      displayName: 'Financials'
    };
  }

  ...
}
const routes: Routes = [
  {
    path: '',
    component: CustomerManagementComponent,
    resolve: {
      session: CustomerManagementNavSessionResolver
    },
    children: [
      {
        path: 'projects',
        loadChildren: () => import('./projects').then(m => ...)
      },
      {
        path: 'access-control',
        loadChildren: () => import('./access-control').then(m => ...)
      },
      {
        path: 'financials',
        loadChildren: () => import('./customer-financials').then(m => ...)
      },
      ...
    ]
  }
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class CustomerManagementRoutingModule { }

That's it. No additional steps are necessary. We can easily add tabs and nested lazy tab navigation systems to the CustomerManagementComponent. For example we could think about a settings section or projects overview section. There are no limits to the imagination.

As inspiration our customer management view looks like this:
Lazy Tab Navigation Angular


Azure Landing Zone Workflow

Azure Landing Zone Comparison

Azure Landing Zone Comparison

If you are trying to set foot on the cloud adoption path, whether you want to develop your application from scratch (cloud-native) or migrate already existing infrastructure to this cloud environment, the chances of coming across the term “Landing Zone” is fairly high.

In this blog post, we try to make your life a little easier by clarifying what a “Landing Zone” is and how you can choose between different tools to deploy a Microsoft Azure Landing Zone. If you use GCP read the Google Cloud Landding Zone Comparison blog post.

What is a Landing Zone?

A landing zone is an environment for hosting your workloads, pre-provisioned through code. There is quite a handful of different areas and subjects that should be covered here that we call Blocks. Based on our Cloud Foundation Maturity Model, you can quickly understand which CFMM blocks are crucial to acquire in your environment. Additionally, you can use this great model as a starting point for designing or scaling your Landing Zone.

What does Landing Zone mean in Azure?

In Microsoft terms, “an Azure Landing Zone is the output of a multi-subscription Azure environment that accounts for scale, security, governance, networking, and identity. An Azure landing zone enables application migration, modernization, and innovation at enterprise-scale in Azure. This approach considers all platform resources that are required to support the customer's application portfolio and doesn't differentiate between infrastructure as a service or platform as a service.”

How can you deploy a Landing Zone in Azure?

In general, this is a choice that you have to make based on

  • Your organization's requirements
  • Whether you work in a team or alone
  • Your knowledge and expertise in Infrastructure as Code
  • Your preferences

As you can see in the chart below, we have two major distinctions here. The first one is the toolsets that you can use from Azure portal which we call it the Hybrid ClickOps approach, and the second one as you may have already guessed is using Infrastructure as Code or GitOps Approach. Both approaches have pros and cons, which you’ll find later in this blog.
Azure Landing Zone Workflow

First Approach - Hybrid ClickOps

If it is important for your company to have their baselines by the provider’s recommendation and you don’t want to put a lot of time into building a Landing Zone, or don’t have enough platform engineers with the right expertise in your team, pursuing the Hybrid ClickOps approach (i.e. clicking through Azure portal to create resources) is most likely the first idea that comes to mind. Microsoft has published a ready-made deployment experience called “Accelerator”. It is based on the Azure landing zone conceptual architecture which Microsoft claims fulfils most of their clients’ goals. With just a couple of clicks and giving some inputs you can have a landing zone and complying most of Microsoft’s best practices at the same time. You can also choose to go enterprise and deploy it with multiple subscriptions or go small and deploy all the required resources with using only one subscription. It is worth mentioning that we call it Hybrid ClickOps since there are JSON ARM templates behind the scenes which going to deploy all the resources for you.

Second Approach - GitOps

If you are a platform engineer who was asked to build a landing zone for your company, working as a team or just by yourself, you most likely prefer to go for Infrastructure as Code (IaC) for most of the scenarios you are facing. As the most popular IaC tools at the time of writing this document is Terraform, we are going to get a little more into two not entirely different instruments for that purpose.

When you search in google for Azure Landing Zone with Terraform, you’ll most likely land on one implementation approach. In reality, there are multiple implementation options that Azure presents which are illustrated in this overview. As much as Microsoft explains the different options in their documentation, it can still be a daunting task for a platform engineer to figure out where to start. One thing we noticed was that the naming can be confusing between the two; there is “Azure Landing Zone Terraform Module”, which is also referenced as “Enterprise Scale Terraform Module”. There is also “CAF Terraform Modules” that also includes different implementation approaches (using a starter project with rover/standalone or using a super module, which will be discussed further in this blog post).

These two Terraform options are not that much different from each other since CAF Terraform modules are based on Azure landing zone terraform modules (Enterprise scale). The CAF Terraform modules split up the ALZ modules into different levels and add additional application landing zone related functionality that make it a more holistic, but also more opinionated solution.

1. Azure landing zone terraform module - Enterprise Scale

Azure landing zone terraform modules (also referred to as enterprise scale terraform modules) are a recommended approach by Microsoft to its customers. As a starting point, you can call up a single module with input parameters and it will bring up almost 180 resources as a baseline to build landing zones. Those resources contain a hierarchy of management groups (Decommissioned, Landing Zones, Platform, Sandboxes) with IAM resources and policies suitable for most enterprises, which can be further customized and expanded to what an organization sees fit.
Azure Landing Zone Terraform Module

As you can see from the diagram directly above, it is based on the azure landing zone conceptual architecture but it focuses on the resource hierarchy. It shows what this TF module covers; anything greyed out is not covered by this module.

Examples and considerations needed to execute this module are described in their github page’s wiki.
These examples are designed to help build an understanding of how to use the module, ranging from basic deployments (level 100) covering the core resource hierarchy from Enterprise-scale, through to more advanced (Level 300) scenarios.

Caveats:

  • The module does not create necessary storage for your terraform states - this is a drawback for teams not leveraging Terraform Cloud/Terraform Enterprise.
  • No step-by-step walk-through
  • Does not support different deployment modes out of the box, e.g. with an MCA setup, you cannot create new subscriptions and have to use pre-provisioned subscriptions.

2. Azure CAF Terraform Landing Zones

This approach can be applied in multiple ways, of which both can be incorporated as standalone in your deployment or using the publisher’s recommended tool called rover.

Rover is a container that includes the required tools to deploy landing zones (e.g. az cli, ansible-playbook, terraform, etc.). It provides many benefits such as facilitating consistent developer experience and the transition to automate with CI/CD. More details can be found here.

The two ways are as follows:

  1. CAF supermodule
    This is a Terraform supermodule published in the aztfmod github repository and verified by Microsoft which tries to take the modular approach.

  2. Starter project
    This is a step-by-step guided approach to deploy Azure landing zones. It will guide you through preparing remote storage for your terraform states and continue deploying your landing zones. At first, it might be a little difficult to know your way around different files and folders in the repo, but you will get around it eventually. The nice thing is, that it generates an understandable Readme file for the next step that you can follow.

Another thing is it segregates the environment into 5 different levels and in each level, you have a different state file. As a consequence, different teams with different levels of permission can work with the state file at the same time and only have the right access on their own respective level.
A deployment will typically contains:

  • A couple of level 0 landing zones. Level 0 contains Core platform automation like storage accounts, Key Vault, RBAC
  • Few level 1 and 2 landing zones which are Core platform governance and Core platform connectivity respectively
  • Many level 3 landing zone, that is Application landing zones vending machine. this level would usually include components like virtual network blocks, virtual network peering objects to hubs, route tables
  • Many level 4 applications will exist in an environment, like Azure Kubernetes Services Cluster, API Management services and all its dependency to deliver a service

Caveats:

  • Generally, it is harder to work with it without using Rover since all the documentation is around using this tool
  • You can use the modules as standalone but you should have an updating process in place, so when one module gets updated, all the related modules receive the updates as well.
  • A subscription vending machine is a mechanism to generate subscriptions when you have an Enterprise or Microsoft Customer Agreement, but the documentation is not published yet

Comparing the Options

For this comparison, we assign 1 to 3 ⭐ for different aspects that we look at for these options. If a certain aspect is not covered at all we assign a ❌. Additionally, you can find some details about why we rated an aspect. These details also provide a deeper insight into how these aspects are covered within the options.

Feature Comparison

The feature comparison is based on the Cloud Foundation Maturity Model (CFMM). You can read details of what these blocks mean on the CFMM website. You can also follow the links in every row that redirect you directly to the details of the according CFMM block.

Azure landing zone accelerator (Enterprise-scale for small enterprises) Azure landing zone accelerator (Enterprise scale) Azure landing zone terraform module (Enterprise scale) Azure CAF Terraform modules
Resource Hierarchy ⭐⭐⭐ It creates a nice resource hierarchy with different levels. There is Platform MG which is dedicated to all the services and resources which need to be managed centrally. And the Landing Zones MG for the environments with internal or external connections. ⭐⭐⭐ It creates a nice resource hierarchy with different levels. There is Platform MG which is dedicated to all the services and resources which need to be managed centrally. And the Landing Zones MG for the environments with internal or external connections. ⭐⭐⭐ The resource hierarchy it creates is based on the Azure landing zone conceptual architecture as part of the “Core Resources”. The hierarchy is meant to be customized under the Landing zones level. ⭐⭐⭐ The resource hierarchy it creates is also based on the Azure landing zone conceptual architecture as part of the “Core Resources”. The hierarchy is meant to be customized under the Landing zones level.
Resource Policies ⭐⭐⭐ Assign different policies and initiatives based on Microsoft Cloud Adaption Framework(check here). Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc. ⭐⭐⭐ Assign different policies and initiatives based on Microsoft Cloud Adaption Framework(check here). Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc. ⭐⭐⭐ Assign different policies and initiatives based on Microsoft Cloud Adaption Framework(check here). Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc. ⭐⭐⭐ Assign different policies and initiatives based on Microsoft Cloud Adaption Framework(Check here). Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc.
Centralized Audit Logs ⭐⭐⭐ Deploy Log Analytic Workspace and Enable logging through policy. ⭐⭐⭐ Deploy Log Analytic Workspace and Enable logging through policy. ⭐⭐⭐ Deploys log analytics workspace that enables centralized audit logging as part of the “Management Resources” module ⭐⭐⭐ Deploys log analytics workspace that enables centralized audit logging as part of the “Management Resources” module
Cloud Tenant Tagging ⭐ Provides a default_tags variable that can be adapted and applied to multiple resources and resource groups. Additionally base_module_tags includes a tag that shows the deployment source (i.e. terraform), this is by default enabled but can be disabled with disable_base_module_tags. One downside is that it is not clear which Azure objects will be tagged from the module structure. But there isn’t any policies forcing the tags to inherit. ⭐⭐⭐ You can set Multiple parameters here like: inherit_tags, global_tags_propagated, and tags based on a set of common criteria (naming convention, prefixes, region of the deployment, name of the environment, tags inheritance settings, etc.)
Tenant Provisioning/Deprovisioning ⭐⭐⭐ There is a mechanism called subscription vending machine to create subscriptions for EA and MCA. You can give it the name of subscription under the subscriptions setting and it will re-use your current subscription or create one.
Playground/Sandbox Environments ⭐ A sandbox management group will be created without any special policy. ⭐ A sandbox management group will be created without any special policy. ⭐ A sandbox management group will be created without any special policy. ⭐ A sandbox management group will be created without any special policy.
Privileged Access Management (PAM ⭐⭐ Service Principals created and have privilege only on each specific level, You can impersonate them to deploy modules from that level
Service Account Management
Virtual Networks ⭐⭐⭐ Can deploy Hub and spoke with Azure Firewall, Hub and spoke with your own third-party NVA, Virtual WAN (Microsoft managed) ⭐⭐⭐ Can deploy Hub and spoke with Azure Firewall, Hub and spoke with your own third-party NVA, Virtual WAN (Microsoft managed) ⭐⭐⭐ By adding deploy_connectivity_resources = true to the module’s input parameters, the module sets up a hub network with a firewall and gateway subnets. These can be further customized by tweaking some networking settings; more details here. ⭐⭐⭐ It can be implemented by running different modules in Level2/connectivity. Modules contain AZ firewall, hub and spoke, vWan, private DNS,…
On-Prem Connect ⭐⭐ You can choose to deploy the on-premises connectivity using the Virtual WAN or Azure Hub and Spoke. ⭐⭐ You can choose to deploy the on-premises connectivity using the Virtual WAN or Azure Hub and Spoke. Here we can define a subscription specific to this connectivity appliance. ⭐⭐⭐ You can connect to your on-premise networks by choosing the matching option and configurations. You have the option of using Virtual WAN and then you are able to make the connection between your on-premises via VPN or Express route. for using azure arc you have to understand key network design considerations and recommendations for working with Azure Arc, include Azure Arc-enabled resources and add them to your landing zone. ⭐⭐⭐ You can connect to your on-premise networks by choosing components like classic Virtual Network-based Hub and Spoke, Azure Virtual WAN, Azure Virtual WAN regional hub, site-to-site, point-to-site and ExpressRoute connectivity objects, or third parties Network Virtual Appliances which reside in Level 2. for using azure arc you have to understand key network design considerations and recommendations for working with Azure Arc and add them to your landing zone.
Cloud Interconnect ⭐⭐ You can choose to deploy the connection between clouds using the Virtual WAN or Azure Hub and Spoke. ⭐⭐ You can choose to deploy the connection between clouds using the Virtual WAN or Azure Hub and Spoke. Here we can define a subscription specific to this connectivity appliance. ⭐⭐⭐ You can have your connection between clouds by choosing the matching option and configurations. You have the option of using Virtual WAN and then use site to site VPN or any other means afterward. ⭐⭐⭐ You can have your connection between clouds by choosing components like classic Virtual Network-based Hub and Spoke, Azure Virtual WAN, Azure Virtual WAN regional hub, site-to-site, point-to-site and ExpressRoute connectivity objects, or third parties Network Virtual Appliances which reside in Level 2.
Managed Key Vault ⭐⭐ Creates a key vault in each level for storing the credential of the service principals and use it to impersonate and access only on the respective level.
Automation in CI/CD ⭐⭐ with Azure DevOps or Github actions, and specifying security principal ⭐⭐ with Azure DevOps or Github actions, and specifying security principal ❌ Should be done manually by yourself. ⭐⭐⭐ There is a thorough documentation about how to use rover with CI/CD tools

Non-Functional Comparison

Azure landing zone accelerator (Enterprise-scale for small enterprises) Azure landing zone accelerator (Enterprise scale) Azure landing zone terraform module (Enterprise scale) Azure CAF Terraform Modules
Extensibility/Modularity/Scalability ⭐ It deploys around 73 resources in one subscription and different resource groups. scalability is not something we expect from this tool, but we can change some parameters or pass some JSON templates to customize it for our needs. In general, Microsoft recommend this approach for smaller companies without much resources. ⭐ ⭐ It deploys around 73 resources in 4-5 Subscriptions. 3 of them are for platform landing zones (i.e. Management, Identity, Connectivity) and the other 2 for your application landing zone (i.e. Corp and Online) The scalability is not something we expect from this tool, but we can later change some parameters or pass some JSON templates to customize it for our need. ⭐⭐ The approach is modular. Extending it by, for example, inserting new custom modules is not documented and can be a daunting task. You can customize landing zones (under the landing zone management group) by adapting the module’s input parameters. ⭐⭐⭐ This approach is completely modular , you can even use the modules standalone by feeding values to the variables existing in the super module. Or use rover which incorporates a yaml file called ignite.yaml (It’s a config file containing values for the variables that you can easily change. It generates the related files based on this data. It uses Infrastructure as data. This means you only need to specify data and it will do the rest)
Terraform ⭐⭐⭐ All terraform resources can be created by calling one module Azure/caf-enterprise-scale/azurerm and supply it with a wide range of input parameters. ⭐⭐⭐ There are a lot of different modules and examples covering most aspects, and can be called directly from terraform and azureCAF provider by aztfmod.
Learning Curve ⭐⭐⭐ Deployment of a minimum featured landing zone based on Best practices for security and governance is not a hard thing to do. There are some amount of options and checkboxes so you will have some idea about what it will implement. ⭐⭐⭐ Deployment of a minimum featured landing zone based on Best practices for security and governance is not a hard thing to do. There are some amount of options and checkboxes so you will have some idea about what it will implement. ⭐ Steep learning curve. Its documentation does not provide a walkthrough approach. It does provide examples that can be used as is, but is not easy to dig deeper on what will happen under the hood by going through the submodules. ⭐⭐ There is a quite good documentation with showing steps of how to run it using rover. But for using terraform standalone you couldn’t find much information
Community ⭐ Doesn’t have much discussion around it ⭐ Doesn’t have much discussion around it ⭐⭐ Their repo has 300 stargazers at the time of writing. They also have a community in gitter where you can find answers to encountered issues, or also ask. ⭐⭐ Their repo has 285 stargazers at the time of writing. They also have a community in gitter where you can find answers to encountered issues, or also ask.
Time To Success ⭐⭐⭐ Very quick. If you know how your environment should look like. In less than an hour you can have a safe guarded environment up and running ⭐⭐⭐ Very quick. If you know how your environment should look like. In less than an hour you can have a safe guarded environment up and running ⭐⭐ Quite quick to get up and running using their level 100 example (default configuration). Creating the initial ~180 resources takes around 35 minutes. ⭐⭐ It needs some time to understand it first and then start using it, then with rover, it would take around 2-3 hours to have an environment with some policies and hierarchies up and running.

Conclusion

If you neither have much time to start your journey in Azure, nor the required skills to develop your own landing zone with an IaC, the Azure landing zone accelerator (Enterprise Scale) could be the best choice. Otherwise, you are better off going for one of the IaC solutions.

The choice between which terraform-based tool to use has to be made by a organization’s roadmap, but there are some aspects to consider:

Choose Azure landing zone terraform module (Enterprise-Scale) when:

  • You are working with a company who seeks Microsoft’s support, since it is their recommendation to customers.
  • You only need to have a platform landing zone in place or as a starting point
  • The foundation that it is going to deploy is enough and you are able to further tailor it to your need
  • You or your company can only trust what the provider releases itself since this tool is considered as the 3rd party approach

Choose CAF terraform modules when:

  • You like to benefit from Rover because:

    It contains the versioned tool set you need to apply landing zones

    It contains Rover Ignite, which ingesting YAML files as templates that will generate both the tfvars files and readme files

    Native integration with Visual Studio Code, GitHub Codespaces

    Helps you store and retrieve Terraform state files transparently on Azure storage account

    Facilitates the transition to CI/CD

  • Have an application-level Landing zone. A landing zone for application is split between two levels:

    Level 3 includes components of an application that are typically delegated to platform operations teams; you can generate level 3 landing zones with Application landing zones vending machine

    Level 4 contains the application configuration delegated for application teams for example Azure Kubernetes Services Cluster, API Management services; you can have them from Azure landing zones solution accelerators, a custom solutions implemented using CAF module or any other Terraform code

  • You like its step by step guide and more thorough documentation
  • You don’t want to put your time on segregating terraform state and making team collaboration mechanisms since it contains this feature out of the box
  • You want to incorporate some of its specific modules in your current environment

Did this blog post help you decide which Landing Zone Solution you will apply to your Azure Tenant? Did you already gather your own insights to building an Azure Landing Zone and want to back up, add or discuss insights from this blog post, please do so and leave a comment! We look forward to hearing about your experience.


AWS Landing-Zone Solution Comparison

AWS Landing Zone Comparison

AWS Landing Zone Comparison

You are on your path to migrate your teams’ workloads to AWS, whether from on-premise or from other cloud providers? Then you have most probably stumbled upon the term “Landing Zones” being an important piece in the puzzle to a smoother cloud migration journey. If this term does not ring a bell, check out our blog post about landing zone lifecycle. Simply put, landing zones should set your foundation in AWS according to your organization’s security and compliance requirements.

It is not often the case that only one landing zone solution exists. This poses the challenge of choosing the right landing zone implementation for the right use case.

In this blog post we go through AWS’ ecosystem on landing zones. The goal is that after you finish reading, you will have a clearer picture on different AWS landing zone solutions to help you choose the landing zone solution that fits most to your organization.

ℹ️ Note that custom-built landing zone solutions are out of the scope of this blog post.
💡 If you are interested in Landing Zone solutions for Azure or GCP, please have a look at our comparison blog posts of these cloud platforms.

AWS Landing Zone Ecosystem

When starting your journey to search for a best fit landing zone option to pursue, you will most certainly come across different solutions. We will mainly describe a set of landing zone solutions that are provided and maintained, or recommended by AWS, namely AWS Control Tower (with plain account factory or account factory for terraform) and AWS Landing Zone Accelerator.

There are other solutions that we will not cover in the comparison, namely AWS Landing Zone and AWS Secure Environment Accelerator (SEA). The former being on long term support and not receiving more features, as well as not being recommended by AWS. The latter being targeted on governmental and public sector environments that require high-level of restrictions. We will give a brief explanation on each solution, but if you are interested in comparing these solutions as well, let us know know in the comments ⬇️ .

AWS Control Tower (CT)

We recommend that all new landing zones start with AWS Control Tower. AWS Control Tower helps you build out an initial prescriptive landing zone configuration, use out-of-the-box guardrails and blueprints, and create new accounts using AWS Control Tower account factory.
-AWS Documentation

This is the first solution you will probably come across. AWS repeatedly recommends this approach going forward. Unless you already have your landing zone setup customized with older approaches, you should definitely try it out.

AWS Control Tower’s main functionality is that it sets up a basic landing zone for you using multiple AWS services behind the scenes, such as AWS Organizations and AWS CloudFormation StackSets. It is pretty easy to set up as AWS provides a step-by-step walkthrough (i.e. a wizard). In that wizard, you will first choose the region of your control tower, and also have the option to deny services in regions you specify. Then you configure organizational units (OUs), shared accounts, CloudTrail (e.g. log retention periods) and encryption. Eventually, control tower will create the following:

  1. Two Organizational Units (OUs)
    Security: This OU contains shared accounts (log archive and audit accounts).
    Sandbox: This OU will be empty, to be filled with user provisioned accounts. Although its name indicates an environment with loose restrictions, by default it includes similar guardrails as all other OUs.
  2. Three shared accounts; management account (note that this account already exists, and is the account from which you setup CT) as well as already mentioned accounts under Security OU (log archive and audit accounts).
  3. A native cloud directory with preconfigured groups and single sign-on access.
  4. 20 preventive guardrails to enforce policies (using Service Control Policy (SCP)) and 3 detective guardrails to detect configuration violations (using AWS Config).

AWS Control Tower also offers an account factory where you can manually provision accounts or enroll existing accounts. These accounts are then governed by control tower. AWS also offers a framework around account factory to enable automation using a GitOps workflow which we explain in more details below.

AWS Control Tower Account Factory for Terraform (AFT)
AWS Control Tower Account Factory for Terraform
AFT is built on top of AWS Control Tower. It provides automation around account provisioning and further customizations using a GitOps approach.

AFT can be set up after setting up control tower, and is done mainly through two parts; manually creating the AFT management account and then applying the AFT terraform module. After applying the module, there will be 4 empty repositories (aft-account-customizations, aft-account-provisioning-customizations, aft-account-request, aft-global-customizations) in your configured VCS (e.g. CodeCommit, GitHub, etc.) that you need to populate with source repositories.

As shown in the “AFT Deployment Module” diagram above, AFT performs multiple automated steps to provision and modify accounts, as well as create custom resources. This is done by providing an interface to users (e.g. developers). For example, users can create a commit to aft-account-request repository (directly or through a pull-request based flow) with a main.tf file that calls the account request. The commit then triggers the configured workflow to provision an AWS account governed by CT.

AWS provides various resources to get more familiar with AFT. For information on broad concepts and some technical details, we recommend you check AWS AFT documentation. For a deep dive technical guidance, we recommend you go through AWS Control Tower Immersion / Activation Day - AFT workshop.

Landing Zone Accelerator on AWS

Landing Zone Accelerator on AWS is the latest approach by AWS to provide a solution for a secure Landing Zone based on best practices.

It is recommended to be used together with AWS Control Tower. But it also works in regions that don’t support Control Tower. In that case, it uses AWS Organizations directly and creates the intended OUs with according policies applied. It also works with AWS CloudGov (US), which is not supported by AWS Control Tower. So it is a solution that can be used by every AWS customer.

The Accelerator is completely executed via AWS native services. An AWS CloudFormation Stack is used to roll out a CodePipeline that creates and updates the Landing Zones according to the configuration that can be customized to your needs.

AWS Landing Zone Accelerator

The CodePipeline is the central component of it. It does the initial role out of the Landing Zone and also enables Continous Integration and Deployment. All that is needed to roll out changes to the Landing Zone is a commit to the Config Code Repository with the config changes you would like to apply.

Rolling it out will actually result in the following environment.

Resource Hierarchy AWS Landing Zone Accelerator

With this Resource Hierarchy responsibilities are clearly segregated into different OUs and accounts.

💡 If you try to roll out the Accelerator, please use the this page from the AWS documentation to get a step-by-step guide including pre-conditions. Without this page you will easily miss some important steps.

And when using the Accelerator in combination with AWS Control Tower, you have to make sure that you enter the management, audit and logging account email addresses of the accounts that were already created by Control Tower as the landing zone accelerator builds on top of it. Otherwise you will run into a code pipeline prepare stage issue.

AWS Landing Zone

AWS Landing Zone is currently in long-term support and will not receive any additional features. Customers who want to set up a new landing zone should review AWS Control Tower and Customizations for AWS Control Tower .
-AWS Documentation

This is the old approach on building an AWS landing zone which is based on AWS Organizations. One of its key components is the Account Vending Machine (AVM) which is a Service Catalog product that enables preconfigured account provisioning. It creates a multi-account structure; a security, logging, and a shared services account under a “Core OU”.

At the time of writing, searching over AWS Landing Zone in AWS documentation does not provide enough information and you will be redirected to AWS Control Tower in many occasions.

If you are already using this solution and are actually happy with it, let us know in the comments below!

AWS Secure Environment Accelerator (ASEA)

This solution has been around since 2020 and was initially built with focus on the Government of Canada. The main target of this project is environments that require high-level of security and restrictions such as governments and public sector organizations. It offers an opinionated and prescriptive architecture for your AWS multi-account setup, while also making it possible to customize as needed. It provides sample configurations that will build you an end-to-end landing zone.

There is extensive AWS secure environment accelerator documentation that will lay out details on the solution including workshops for both administrators and project teams.

If you are already using this solution and are actually happy with it, let us know in the comments below!

Comparing the Options

For this comparison, we assign 1 to 3 ⭐ for different aspects that we look at for these options. If a certain aspect is not covered at all we assign a ❌. Additionally, you can find some details about why we rated an aspect. These details also provide a deeper insight into how these aspects are covered within the options.

Feature Comparison

The feature comparison is based on the Cloud Foundation Maturity Model (CFMM). You can read details of what these blocks mean on the CFMM website. You can also follow the links in every row that redirect you directly to the details of the according CFMM block.

AWS Control Tower with Account Factory AWS Control Tower with AFT AWS Landing Zone Accelerator
Resource Hierarchy ⭐⭐ Creates 2 Organizational units (OUs), Security and Sandbox. It also creates 3 shared accounts; a standalone management account (not belonging to an OU), and log archive and security audit in the Security OU. The Sandbox OU remains empty to contain the new provisioned accounts. You can create new OUs based on your desired structure. They will be governed by CT. AWS also offers a sample hierarchy with additional OUs that you can manually include. ⭐⭐⭐ Additional to what CT provides, AFT offers a GitOps approach to provision accounts under specified OUs through an automated workflow. ⭐⭐⭐ By default it creates 2 OUs, Infrastructure and Security. You can easily define more OUs in the config. Another great feature it provides is the option to use a Quarantine OU where almost everything is forbidden. It is used for newly created accounts that are still under construction by the accelerator. That way unintended access or changes during creation can be avoided.
Resource Policies ⭐⭐⭐ AWS Control Tower sets up 20 preventive guardrails (implemented by SCPs) and 3 detective guardrails (implemented by AWS Config). Those are the “Mandatory” guardrails enabled by default that we see are reasonable, such as disallowing deletion of the log archive bucket, disallowing changes to AWS IAM roles set up by CT and CloudFormation, etc. There are also more guardrails available that are not enabled by default, which are “Elective” and “Strongly Recommended” guardrails. Newly provisioned accounts with Account Factory inherit guardrails from their parent OU. ⭐⭐⭐  Accounts provisioned through AFT also inherit all guardrails from their parent OU which is covered by CT. Additional policies can be applied through AFT customization framework. ⭐⭐⭐ Reasonable guardrails are applied to the default domains Infrastructure, Security and Quarantine. It is easy to also define additional guardrails or to define them for additional, custom OUs.
Centralized Audit Logs ⭐⭐⭐ Enables CloudTrail service to aggregate action and event logs into the shared Log Archive account from different AWS accounts and records them in CloudWatch. With CT release ≥ 3.0, an organization trail is created to gather event logs on an organization level instead of a member trail that gathers logs on a per account basis. ⭐⭐⭐ With AFT, you can also enable CloudTrail data events. Data events are events performed on or within a resource. These are disabled by default as they often incur high costs. This is done when deploying AFT by setting aft_feature_cloudtrail_data_events to true. ⭐⭐⭐ Uses the Log Archive Account to store the logs. It can be configured easily which logs shall be included.
Cloud Tenant Tagging ❌ No AWS account is tagged when setting up CT. ⭐ By default provisioned accounts are not tagged. It is possible to tag those accounts through a terraform variable account_tags. ❌ Only Tag Policies on the org level can be defined. They only ensure that if a certain tag is set, it complies with the definition in this policy. The policy will ignore those resources if no tags are set at all. During account creation , no tags can be set. So the tagging of Resources must be done outside of the accelerator.
Tenant Provisioning/Deprovisioning ❌ Initial provisioning of your multi AWS accounts. This does not qualify as tenant provisioning/deprovisioning, which is partly covered by account factory. ⭐⭐ AFT’s main functionality is automation around tenant provisioning. Deprovisioning is not supported. Removing the aft-account-request terraform for a specific account only removes it from AFT management. ⭐ Workload Accounts can be defined in the accounts-config.yaml. Only the very basic account information can be entered here. Tags, Service Accounts, etc cannot be defined for workload accounts.
Playground/Sandbox Environments ❌ Creates a Sandbox OU. However, it also has the same guardrails as the Security OU. ❌ No predefined Sandbox OU is available
Privileged Access Management (PAM) ⭐⭐⭐ Uses IAM Identity Center service to offer preconfigured groups. You can then add users to those groups based in their role in the organization. ⭐⭐⭐ By default, the user email set in the account request is assigned AdministratorAccess to the account. Additionally, groups created with CT are assigned with specific permissions. That is, AWSSecurityAuditPowerUsers group is assigned. AWSPowerUserAccess, AWSControlTowerAdmins group is assigned AWSOrganizationsFullAccess, AWSSecurityAuditors group is assigned AWSReadOnlyAccess to that account. ⭐⭐⭐ By default it defines only an Administrator group. But as you can base it on AWS Control Tower, you can make use of the advanced default roles created by AWS Control Tower.
Service Account Management
Virtual Networks ⭐⭐⭐ CT creates a default VPC with 3 subnets in the management account per availability zone. You can edit VPC configurations for new provisioned accounts with the account factory. For example, you can allow internet access for created subnets, which will lead to the creation of a NAT Gateway. When provisioning a new account, CT automatically deletes the default VPC and creates a new VPC configured by CT. ⭐⭐⭐ Similar to normal account factory, with addition to AFT customization framework that allows you to include additional terraform resources. ⭐⭐⭐ It provides a reasonable default network setup in the network-config.yaml. Additionally the default config contains a lot of additional options as commented code. You just have to active them and adapt to your needs.
On-Prem Connect ❌ CT workflow does not offer on-prem connection out of the box. It can however be implemented using Transit Gateways and Site-to-site VPN. AWS Control Tower workshop provides a detailed guide on interconnecting control tower accounts VPCs as well as connecting them to on-prem. ❌ While it is not supported out of the box by e.g. switching on a flag, AFT customization framework enables administrators to include terraform resources as they see fit. There are a bunch of “Site-to-Site VPN” terraform resources available that can be leveraged. ⭐⭐ It provides a TransitGateway in the network config to connect easily to a hub that makes the on-prem connect. As also directConnectGateways can be defined in the network config, everything that is needed to establish an on-prem connection is available.
Cloud Interconnect ❌ Similar to on-prem connect, CT does not offer cloud interconnect out of the box, but can be implemented as an “on-prem” connection. Additionally, AWS Control Tower workshop offers guidance on interconnecting AWS accounts VPCs. ❌ Same as for CT itself applies. ⭐⭐ In the network config directConnectGateways can be defined to connect to networks at other cloud providers.
Managed Key Vault
Automation in CI/CD ❌ Runs automation under the hood, not configurable by the user. ⭐⭐⭐ Automation is the core of AFT. It sets up a pipeline that is triggered by a code change in a version control system (VCS). It uses AWS CodeCommit natively, but also supports other alternatives such as GitHub and BitBucket. ⭐⭐ The whole Accelerator framework is based on AWS CodeBuild and CodePipelines. Any updates to the config is rolled out via that pipeline. The only downside is, that you can only use the AWS Services for it. Integrating it into any other CI/CD tool is not possible.

Non-Functional Comparison

AWS Control Tower with Account Factory AWS Control Tower with AFT AWS Landing Zone Accelerator
Extensibility/Modularity/Scalability ⭐⭐ CT only provides the baseline setup. It can be extended with “Customization for Control Tower - CfCT”. You can also create your own OU structure to which CT will also apply guardrails. ⭐⭐⭐  In addition to what can be extended and customized in CT, AFT provides a customization framework that allows users to include AWS resources with terraform. ⭐⭐ You can customize the config rather easily to your needs. But it seems like it is not possible to add completely new modules for other services easily to the Accelerator. As they have a DSL to define all the resources via their config it feels like you are pretty locked to the config options that are provided by the accelerator. But the config actually covers quite a lot of services (35+ services are mentioned in the AWS docs) and seems to be sufficient for many use-cases. But if you want to integrate an AWS service into your Landing Zone that is not yet supported by the accelerator, it looks like you have to create a Pull Request to the accelerator to get it in.
Terraform ⭐⭐ As its name suggests, it offers a workflow based on terraform. It requires a bit of ClickOps initially to create the AFT management account. ❌ It is completely based on AWS CloudFormation.
Learning Curve ⭐⭐ ⭐ It is easy to start with CT and set it up. Having an advanced AWS knowledge is not required. ⭐⭐ There are many AWS services involved in the workflow, making it a bit harder to grasp. Also, AWS account provisioning is not directly performed via terraform but an account request is created which triggers an account provisioning process. ⭐⭐ Except for some current issues, that should be related to the accelerator being quite new on the market, rolling it out is rather easy. You only have to deploy a StackSet and the rest of the bootstrapping is done automatically for you. As a next step you have to set the configuration you like to have in 6 yaml files, that are rather easy to understand. You also get a good reference implementation based on best practices where you can copy and adapt your own configuration.
Community ⭐ Scattered community across multiple platforms. There doesn’t seem to be a specific place to ask questions but you can find some answers on different platforms such as stackoverflow. ⭐⭐ In addition to different community platforms, you can open a GitHub issue in AFT repo in case you encounter problems. AFT maintainers seem to be responsive to issues, but they still don’t accept contributions at the time of writing. ⭐ As it is a rather new solution you cannot find a lot around this yet. The GitHub Repo only has 75 stars and 12 contributors yet. Only a few issues exist yet in the GitHub repo and the responsiveness of the developers is rather low at the moment. At least 2 tickets we created or commented in did not get any response from official contributors within more than a week. Eventhough community around it is still rather low, an advantage is that AWS Support fully covers support for it.
Costs ⭐⭐⭐ There are costs associated with services that CT uses such as CloudTrail and S3 buckets. The resources it creates can incur costs depending on the usage, for example the more accounts created, the more logs are ingested into the log archive account. AWS has a pricing page with details on different scenarios and how much cost is associated. Another example is, in account factory settings, you can allow internet access for created subnets in the new account, which will lead to the creation of a NAT Gateway and drive some cost. ⭐⭐ There are no additional costs for AFT but also for resources it creates. Transparency in AFT is limited and you need to figure out which options to enable/disable to control which resources are created. For example, AFT will by default create AWS PrivateLinks. In order to disable that, you need to set aft_vpc_endpoints=false when deploying the AFT terraform module. ⭐ AWS is very transparent around costs that are associated with running the best-practice landing zone. At the time of writing this article it is ±360€ per month. If you are not using all resources that are configured in the default landing zone you can save a bit of money. Main cost drivers are the KMS and the networking.
Time To Success ⭐⭐⭐ Setting up AWS Control Tower for the first time takes 1-2 hours, which includes going through “set up your landing zone” that takes roughly 15-30 minutes. This assumes that you do not have an existing setup that you need to decommission; as that will increase the time to success. ⭐⭐ Setting up AFT technically takes around ~1 hour, which includes creating the AFT management account and deploying the AFT terraform module. Post-steps like populating your repositories for automation would rather be quick. All in all, assuming the process goes smoothly, setting up CT with AFT would take ~4 hours. ⭐⭐ The concept of AWS accelerator is quite promising to set up a secure Landing Zone rather quickly due to the best practice defaults and the easy to understand configuration. But currently there is the downside that if something goes wrong while rolling out the pipeline you might receive really bad error messages that don’t help you resolving the issue. This can delay the time to success significantly. But these issues could vanish over time when the accelerator becomes more mature.

Find your way to building AWS Landing Zones

Building your landing zone in AWS eventually implies it will be built on top of either AWS Organizations directly or AWS Control Tower to enable your multi-account setup. Using either of these would also impact your decision on which landing zone solution to pursue. AWS Organizations is merely a tool that enables a multi-account setup but does not actually build a landing zone, while AWS Control Tower provides an abstraction to multiple AWS services including AWS Organizations and builds a basic landing zone that you can extend atop. The below simplified flow chart conveys the relation between the different solutions.

AWS Landing-Zone Solution Comparison

Unless you are using a region that is not supported by AWS Control Tower or you need absolute control over all the components of your landing zone, you should always go with AWS Control Tower. Most solutions nowadays support it, and it is highly recommended by AWS. But besides the guardrails it provides, there isn’t much that it adds in the meantime and it can be considered a very basic landing zone when used solo. Therefore, if you’re only interested in a basic landing zone setup that only provides you with a multi-account framework with a set of preventive and detective guardrails, then you should definitely consider AWS Control Tower.

From there you can choose to stay with only Account Factory in which you will pretty much only benefit from CT’s guardrails when provisioning accounts, or go for Account Factory for Terraform which additionally provides a GitOps based framework to automatically provision accounts with customization capabilities.

If you’re interested in an end-to-end landing zone solution, then consider AWS Landing Zone Accelerator. It is a solution that promises to build full-fledged AWS landing zones with automation capabilities. It supports both AWS Control Tower and AWS Organizations. This solution was first released on 23 May 2022 which is fairly new. We identified that the product itself and its documentation is not yet battle proven and you can run in some unexpected issues when trying to roll it out. As of this writing, we stumbled across a blocker that prevented us from actually deploying it and therefore we cannot provide a full recommendation yet. We like the simplicity and customizability of the config files that are steering the AWS Accelerator and the understandable pipeline that deploys it. But we are wondering whether more extensive customization that goes beyond the services and features supported by the configuration files of AWS Accelerator are feasible.

The different solutions presented in this blog post are actually not really alternatives that compete against each other. Instead they combine and extend each other very well. For a full-fledged Landing Zone we therefore recommend the combination of AWS Control Tower with AFT for automated account provisioning and Landing Zone Accelerator on AWS to add further highly recommended features to your Landing Zone.

Best-Practice AWS Landing Zone Solution Diagram

If the concerns we mentioned regarding the production-readiness of AWS Landing Zone Accelerator, or if you need to have full control over your landing zones, then go for a custom-built landing zone, either via an AWS partner or with your AWS team.

Did this blog post help you decide which Landing Zone Solution you will apply to AWS? Did you already gather your own insights to building an AWS Landing Zone and want to back up, add or discuss insights from this blog post, please do so and leave a comment! We look forward to hearing about your experience.


CheckList

Google Cloud Landing Zone Comparison

Google Cloud Landing Zone Comparison

When researching how to set up your Landing Zone in GCP you come across different options provided by Google. In this blog post, we compare several key aspects of the different solutions. We had a deep look into these solutions and rolled them out in a GCP Test Organization to evaluate how they perform. After reading this blog post you will understand what the different options are, which features they provide, how easy it is to use them and which option fits best to your use-case.

Your Options to Create Google Landing Zones

Google Cloud setup checklist

In the GCP web console, you can easily set up a basic cloud foundation via a wizard called “Set up your Foundation”. It is based on the Cloud setup checklist by Google. It covers the most relevant topics that should be considered for a secure and scalable cloud foundation.

It does not apply most of the configuration directly via the web console but generates Terraform Modules. So the wizard is a nice and handy frontend for configuring some Terraform. You are guided very well through the different things that will be applied and how they are configured.

Google Cloud Checklist

Cloud Foundation Toolkit - Example Foundation

Based on the Cloud Foundation Toolkit, Google provides a Terraform Example Foundation. It can be used as a basis and customized to individual needs. It already applies best practices and reasonable defaults that should fit many companies.

Terraform Modules are structured into different stages (bootstrap, org & resource hierarchy, environments, networking, projects, and app infrastructure). After bootstrapping the basic structure and projects by executing Terraform, it provides the option to roll out the remaining stages via CICD. Google Cloud Build and Jenkins are supported for this. But you still have to prepare the different stages by executing several commands manually before the deployment is triggered via CICD. For execution via CICD, it uses a Google Cloud Git repository per stage.

[cta_box title="Do you need support building your Landing Zone?" text="Book a free expert call here, to learn more about modular Landing Zone Best-Practices." background-color="000000" button_text="Book Free Expert Call →" button_url="https://app.harmonizely.com/meshcloud/livedemo"]

💡 We did not complete rolling out the Example Foundation as we ran into permission issues we couldn’t figure out. As we came to the conclusion that Fabric FAST is the more mature and future-proof approach, we decided not to dig deeper into rolling out the example foundation. Details about this can be found in the next sections.

Cloud Foundation Fabric FAST

Cloud Foundation Fabric is the latest approach by Google to provide a landing zone solution based on the Cloud Foundation Toolkit that is easier to apply, extend and roll out than the Terraform Example Foundation mentioned before. The result of this is the production-ready blueprint for a secure organization called Fabric FAST. It is a set of Terraform modules structured into stages (bootstrap, cicd, resource hierarchy, security, network, project factory, data platform).

Fabric FAST comes from engineers in Google Cloud's Professional Services Organization, with a combined experience of decades solving the typical technical problems faced by GCP customers.

Beyond setting up and configuring a secure Organization and Resource Hierarchy it also provides a Project Factory which enables a GitOps Workflow to provision new projects.

Initially, you need a Super Admin for Google Workspace to set up some groups and assign people to these groups. Afterward, everything is done via Terraform.

Stages of Fabric FAST

Comparing GCP Landing Zone Options

For this comparison, we assign 1 to 3 ⭐ for different aspects that we look at for the three options. If a certain aspect is not covered at all we assign a ❌. Additionally, you can find some details about why we rated an aspect. These details also provide a deeper insight into how these aspects are covered within the options.

GCP Landing Zone Feature Comparison

The feature comparison is based on the Cloud Foundation Maturity Model (CFMM). You can read details of what these blocks mean on the CFMM Website. You can also follow the links in every row that redirect you directly to the details of the according CFMM block.

Checklist Fabric FAST Example Foundation
Resource Hierarchy ⭐⭐ You can pick from 4 different hierarchies, which makes it quite easy to find a hierarchy that matches your needs. Using even more custom ones is also possible by adapting the generated Terraform code in the end. ⭐⭐ A hierarchy that fits many companies is applied by default. It is divided into common branches like networking or security. A “Teams” branch contains all end-user projects. It can be easily customized via input variables (also see Tenant Provisioning below). Applying a completely different structure requires adaption to the Terraform files. For other hierarchy structures, you can also use blueprints provided outside the context of fast stages, see “example foundations”. ⭐ The example foundation only rolls out one specific resource hierarchy, which is separated by environment (dev, non-prod, prod). Using custom hierarchies has to be implemented on your own.
Resource Policies ⭐ 3 basic policies can be applied manually via an optional step in the wizard, they are not part of the generated Terraform code. ⭐⭐⭐ Reasonable defaults are set and additional helpful policies are proposed via code comments in the terraform files. They can be enabled on demand. ⭐⭐⭐ A good amount of reasonable default policies are rolled out via Terraform. They match the best practices provided by GCPs Cloud Foundation Toolkit.
Centralized Audit Logs ⭐⭐ Basic centralized logging is configured by default. You have to follow manual steps to push logs to BigQuery, SIEM, etc. ⭐⭐⭐ By default, it captures logs from GCP’s Cloud Audit and VPC Service Control violations. It can be further customized to capture even more logs by configuring what is so-called log sinks. That way you can i.e. push logs to BigQuery or a SIEM solution. ⭐⭐⭐ Centralized Audit Logs are applied and you can configure exports to BigQuery, pub/sub systems, and more.
Cloud Tenant Tagging ⭐⭐ Tenants can be tagged via the project’s YAML file of the project factory. Defaults that shall be applied to all projects can also be defined. Tags cannot be defined at the Team level yet. ⭐ It sets some default labels like environment, security contact, etc for all projects. But adding any custom tags requires modification of the terraform files.
Tenant Provisioning/Deprovisioning ⭐⭐ With the project factory, GitOps-based tenant provisioning can be applied. As the project configs should better be reviewed by a cloud foundation member, it is not full self-service for the end users. When removing the project definition again, the tenant will be deprovisioned by terraform. ⭐ With stage 4-projects you can define projects, but you have to touch Terraform files to create or change projects. This feels more like coding instead of configuring it as it is done with Fabric FAST. So this approach of modifying Terraform does not seem to result in the best GitOps flow for managing projects.
Playground/Sandbox Environments ⭐⭐ It provides a dedicated folder for Sandbox environments. This folder has different and softer org policies applied. That allows for quicker evaluation as more complex, but secure policies don’t have to be applied here. Sandbox projects can be created via the Project Factory just like normal projects. They are just put into the Sandbox folder. Automatic expiration of Sandbox environments is not part of Fabric FAST. It has to be implemented in the GitOps flow around it. ❌You could consider adding “Sandbox” as an additional environment with some special policies applied, but the example foundation does not provide any guidance for this.
Privileged Access Management (PAM) ⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning only necessary roles for each group. ⭐⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning only necessary roles for each group. Furthermore, service accounts are created for automation that can be impersonated by selected groups. ⭐⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning necessary roles for each group. Furthermore, service accounts are created for automation that can be impersonated by selected groups.
Service Account Management ⭐⭐⭐ With the project factory, project configuration can also include service accounts provisioning alongside their permissions. By default, iam.disableServiceAccountKeyCreation organization policy is enforced on organization-level. This is a best practice that makes use of Workload Identity Federation (WIF) as an alternative to key creation. ⭐ I couldn’t find out for sure, but one service account seems to be created per project. This SA can then be impersonated by the Cloud Build SA to perform CI/CD tasks within the project. By default, iam.disableServiceAccountKeyCreation organization policy is enforced on organization-level. This is a best practice that makes use of Workload Identity Federation (WIF) as an alternative to key creation.
Virtual Networks ⭐ Separate networks per environment are created and some basic firewall rules are applied. That way you can have the connectivity within one environment (e.g. all production services can talk to each other securely via a VPC). Advanced options like configuring peering or VPN approaches are not provided. ⭐⭐⭐ Offers sophisticated virtual network setups based on the “hub and spoke” design. One can choose the type of connectivity between the hub and spokes, which are: VPC Peering, Network Virtual Appliances (NVA), or VPN ⭐⭐⭐ Offers sophisticated virtual network setups. One can choose the type of connectivity between Dual SVPC or Hub & Spoke.
On-Prem Connect ⭐⭐⭐ On-prem VPN is offered with all 3 setups of the networking stages. ⭐⭐⭐ On-Prem connectivity is provided in 3 different ways for all network setups mentioned above.
Cloud Interconnect Network Documentation only mentions that Cloud Interconnects should be done similar to the HA VPN setup. So it seems like the basis is there, but no specific support for setting up a concrete inter-connect. ⭐⭐⭐ It supports Direct and Partner Interconnect.
Managed Key Vault ⭐⭐⭐ A Cloud KMS is rolled out to every environment so e.g. all production services have a way to reliably and securely share secret keys. ❌ One of the sample projects creates a KMS, but only within the project.
Automation in CI/CD ⭐⭐ Supports automation with GitHub Actions, GitLab, and Source Repo. An in-depth look into the terraform code might be needed to get it to work. While it provides a great benefit, it could use more directed documentation. You can add this automation whenever you like. Even if you applied Terraform manually for some time, you can still add CI/CD later on. ⭐ Cloud Build or Jenkins can be used to roll out the Foundation. Additionally, Google Cloud Build seems to be set up for all end-user projects, so they can also quickly start with CI/CD. With Cloud Build and Jenkins, only 2 established CI/CD solutions are provided. Modern CI/CD tools such as GitHub Actions or GitLab are not supported.Documentation for rolling out the modules is heavily centered around using a CI/CD tool. So you are triggered to use it right from the beginning instead of growing your solution to using CI/CD over time to keep complexity as low as possible at the beginning.

GCP Landing Zone Non-Functional Comparison

Checklist Fabric FAST Example Foundation
Extensibility/Modularity/Scalability ⭐ The checklist generates Terraform code to roll out the resource hierarchy, networking, audit logging, and a basic IAM approach. Sadly org policies are not applied via Terraform. In general, you can extend those easy-to-understand templates with whatever you need. But they don’t provide any sophisticated structure or approaches that help you scale your foundation to something big. ⭐⭐⭐ It contains several ready-made terraform modules that the different stages utilize. Each stage has outputs that are used as input variables for the next stage. It can therefore be extendable as long as a “contract” regarding input and output variables is followed. tfvars files are created and uploaded to GCP buckets that can be accessed by different stages. ⭐⭐ Terraform code is structured into different stages. So this Terraform Module structure supports scaling. The generated default projects might be a bit cumbersome to be replaced by the projects you really want to have. In general, the example foundation is not as configurable as Fabric FAST and e.g. relies quite heavily on a folder structure based on the different environments.
Terraform ⭐ Terraform is actually generated for most of the configs, but e.g. org policies are not part of that terraform code but have to be applied manually in a guided dialog in the GCP web console. Additionally, the Terraform modules are very basic and don’t provide a structure that is ready for scaling them to way more modules in the future. ⭐⭐⭐ A sophisticated structure for the Terraform modules is applied. Especially structuring them into different stages makes it scalable. Additionally transferring input from one module to the next is handled in a reasonable way. Using TerraGrunt might enhance this transfer even more. ⭐⭐ It’s a structured and sophisticated Terraform structure. But transferring data between the steps must be done completely manually. A more automated approach like TerraGrunt is not being used here.
Learning Curve ⭐⭐⭐ The learning curve is very low. You simply follow the wizard and everything you need to know is explained to a sufficient degree on the wizard pages. That way you can easily and quickly understand what it does and how to configure it. ⭐ Documentation guides through the stages, but several questions and details remain open and you have to look into the TF modules to understand details or how to customize certain areas. Especially the way IAM and PAM are handled is not documented well and is not easy to understand. Also, parameter documentation is very basic and is therefore not always helpful. ⭐ Documentation in the READMEs for the different stages is rather short and only explains the most important things. Details have to be read up in the general Google CFT docs. But it is also quite hard to understand what the modules are doing while applying them, as the steps you have to do manually are not providing you insight into the modules. It’s just some git, copy, etc commands you have to execute step by step for every stage.
Community ⭐ As the checklist is well guided by the wizard and in general it creates easily understandable Terraform modules there is not really a need for a community around it. ⭐ it is really hard to currently find resources on Fabric FAST besides the documentation by Google. Looking at the contributors and the activity on the Repo it is quite active. There are around 70 internal and external contributors to that repository. We expect the community to grow in the future. ⭐⭐ It seems to be the most commonly used solution for GCP at the moment. You can find several blog posts about it and more.
Time To Success ⭐⭐⭐ If you have a user who is Super Admin and Org Admin at hand you can really quickly set up your landing zone. Within a few hours you have everything configured and applied and you understand what it does. ⭐⭐ Considering the quite big scope of Fabric FAST, you can also rather quickly achieve your goal of a landing zone. It most likely will take you 1-2 days to go through all stages and apply them according to your needs and to roughly understand what is deployed. For understanding the Landing Zone you built here more deeply requires a few more days. ⭐⭐ Google says you can set up your foundation within a day. Looking at the problems we had when trying to roll it out, I think it takes longer. The process is also quite error-prone as you have to execute that many commands manually. Understanding more deeply how the Landing Zone you applied here behaves exactly requires additional effort.

Which GCP Landing Zone Should I Pick?

The Terraform Example Foundation from the CFT should not be used anymore as Fabric FAST supersedes it and provides a way cleaner and usable approach. With the Example Foundation you have to execute >20 commands per stage manually (there are 6 stages in total). We also heard from one of the Google Consultants, that Fabric Fast is the direction they want to go to in future. As we tried to roll out the Example Foundation, we noticed that it is way more painful to use than Fabric FAST and it feels way more hacky.

The Google Cloud Setup Checklist is a nice and small solution that fits well for smaller companies or companies just wanting to get started quickly with their Cloud Journey in a reasonably secure environment. It also allows growing your foundation step-by-step by extending the generated Terraform modules to your needs.

But, if you have a really big cloud foundation in mind, the Terraform Modules provided by the Cloud Setup Checklist might not suffice to scale them to something large. It also doesn’t contain solutions for advanced problems many companies face. If you want to grow your Cloud Foundation Landing Zone, you should better consider starting with Fabric FAST right from the beginning as it applies a sophisticated IAM and PAM concept and a scalable structure to organize your Terraform modules with those stages. It also provides more features that make sense for many companies.

Starting with the Google Cloud Setup Checklist first, and adopting Fabric FAST later on is also a feasible option. Both use the same user groups and adopting the resource hierarchy, networking, and audit logging should also be possible as they don’t differ drastically.

Did this blog post help you decide which Landing Zone Solution you will apply to our GCP Org? Did you already gather your own insights to building a GCP Landing Zone and want to back up, add or discuss insights from this blog post, please do so and leave a comment! We look forward to hearing about your experience.


Automated Self-Service for Azure Networking Services

Automated Self-Service for Azure Networking Services

Automated Self-Service for Azure Networking Services

Summary: Many cloud and networking teams struggle to provide their organization’s application teams with the Azure networking services they need. Why is that? As organizations strive to move to the cloud the high demand for networking services meets manual processes. The result is a real bottle-neck that slows down cloud adoption. Read this article to learn how to offer Azure networking in fully automated self-service with a solution developed by meshcloud. Additionally we offer a free demo.

The Problem: High demand for integrating applications into Azure meets manual network processes creating a cloud adoption bottle-neck

Organizations that move to the cloud and to Azure specifically encounter a high demand for integrating applications into their virtual networks. To offer on-prem or secure cloud connectivity they might build a hub-and-spoke architecture, having to create the spokes manually every time. A real bottleneck for the organization's cloud transformation and not a scalable solution.

The solutions offered by Azure are complex and lack central transparency and control. Organizations need to be able to offer Azure connectivity in a scalable and secure way that allows central control.

Most organizations either don’t have an automated solution implemented at all or don’t know how to realize the architecture for Azure networking services and offer them to their application teams.

Often Network Engineers use an ITSM or even email and phone to give the access to virtual networks the application teams need. They set up networks manually for each request they get.

In a better case scenario they get pull requests for a terraform deployment from application teams and approve them to roll out networking architecture.

The Solution: meshStack and UniPipe Service Broker let you provide Azure networking in fully automated self-service

With meshStack - meshcloud’s Cloud Foundation Platform - and UniPipe - meshcloud’s GitOps-based Service Broker solution - it is possible to offer Azure networking in fully automated self-service. The central cloud team and the network engineers can set up an Azure networking service broker in less than an hour. With this in place the application teams can book and use the integration of their application into the organization’s virtual network within minutes.

How it works

Central Cloud Team & Network engineers

  1. Create a Git repository that will be used for GitOps by UniPipe Service Broker. Data about all requested services and their status is stored in it.
  2. Add the Azure Networking Service Terraform Module provided by meshcloud to this repository. If needed you can modify the Terraform modules to your needs.
  3. Deploy and with only a few steps configure UniPipe Service Broker and UniPipe Terraform Runner docker containers.
    You can use Azure IPAM to automatically assign unique IP ranges.
    OR you can add a manual step to the Service processing in which a network operator assigns an IP range.
  4. Register the new Service Broker in meshStack, so its services appear in the marketplace.
  5. Add the service as a required service to your meshLandingZone, which will be applied after creating a new project.
  6. Enjoy your running and integrated Azure Networking Service

Application Team

  1. Create a new project in meshStack.

  2. During project creation you can pick a plan (On-Prem connectivity or Cloud-only connectivity), provide information about the vNet size and the target location in Azure.
    Automated Self-Service for Azure Networking Services

  3. After project creation the network will be successfully deployed into your Azure subscription and you can start using it within your application.

Conclusion: High demand needs automated supply to keep your cloud adoption goals in focus

meshcloud’s solution solves your scalability challenges when it comes to integrating applications into your organization’s Azure networking. Automating the provisioning of Azure networking services removes a common bottle-neck and enables networking and application teams to reach their cloud adoption goals.


Landing Zone Heroes

Mastering Landing Zones Like a Superhero

How to build a Landing Zone in Azure with our construction-kit

All beginnings are difficult. This is particularly true for your first cloud project. The sheer amount of settings, in order to provide a safe, compliant and productive environment for your organization, is almost overwhelming.

To turn your cloud journey from “zero to hero”, we equip you with our cloud superpowers: our Landing Zone construction-kit enables Enterprise Architects and Platform Engineers to deploy a Landing Zone from scratch.

Exploit the full potential of the cloud

In this blog post we want to show you how you can build a ready to use Landing Zone with our Landing Zone construction-kit and become the hero your company needs!

But before we are getting into the demo, let’s see how Landing Zones help your organization getting started on their cloud journey and how you can exploit the full potential of the cloud.

By enabling the DevOps teams in your company to build scalable applications without compromising security or compliance, Landing Zones are perfect for any greenfield cloud project.

Landing zone Heroes

Benefits of using Landing Zones

  • Ensuring security & compliance
  • Preventing misconfiguration of cloud environments
  • Supporting cloud-native services
  • Saving platform engineering resources
  • Ruling the huge surface area of cloud services

Do you really need it? Test yourself!

If you're not convinced whether Landing Zones are what you need, then you might check if you find yourself in one of the following scenarios:

  • If you are uncertain what a good base security configuration is…
  • If your application teams are hesitant when it comes to the cloud, as they are not familiar with the services…
  • If you are in lack of resources for the implementation of automation and security assets...

… then Landing Zones are what you and your organization need. Now, after seeing what superpowers our Landing Zone construction-kit holds for you, let’s get down to business and create a ready to use Landing Zone in Azure.

How to: Building a Landing Zone in Azure

meshcloud has developed a lightning fast way to build an out-of-the-box Landing Zone with a Landing Zone-Kit. Keep on reading or check our video to see how to get a working Landing Zone in Azure with all basic resources that are typically included.

Azure Landing Zones Terraform Module

Building a Landing Zone in Azure can be a daunting task, especially since Microsoft provides various options to pursue, from Azure resource manager (ARM) templates to Terraform modules. If you’d like to see how the different ways compare, check out our Azure Landing Zone Comparison. In the end, any approach will implement the Azure Landing Zone conceptual architecture (also called enterprise scale in other contexts), or part of it.

Azure Landing Zone conceptual architecture

That already seems like a lot, doesn’t it? Certainly not something that a solo Platform Engineer or an Enterprise Architect will find easy to do. But that’s fine, since Azure already has a ready-to-use Terraform module that will create the baseline of that architecture (image below).

Azure Landing Zone conceptual architecture (Azure enterprise-scale Terraform Module)
Azure Landing Zone conceptual architecture (Azure enterprise-scale Terraform Module)

There are many good reasons to start out with Azure Landing Zones Terraform module:

  • Microsoft recommends it for most organizations.
  • It is lightweight, and quick to deploy.
  • Their repository includes a Wiki with detailed examples to use.
  • It paves your way to adopting GitOps from the get go.
  • It prepares your Landing Zones setup for scale.

There are some remaining questions which are not answered by using this module:

  • How can I store the terraform state of this module?
  • How can I restrict access to the terraform state file to specific users?
  • As a Platform Engineer or an Enterprise Architect, I have other resources I want to include to my cloud foundation that are not covered by this module, how can I do that?

These questions are answered by the previously mentioned Landing Zone Construction-Kit. In the next section, we will explain how to use this tool to become the new superhero by setting up a new Landing Zone with only a few quick commands.

In one hour, you will have ready-to-use Landing Zones to start your compliant and secure Cloud Journey.

How to: Using the Landing Zone construction-kit to build Landing Zones in Azure

We will utilize the collie command line tool. We are using collie because it gives you a fully automated deployment process and requires very few manual steps from your side. Let’s jump in.

Prerequisites

Before building Landing Zones we will need to have the following:

  • An Azure Active Directory (AAD) Tenant
  • An Azure subscription
  • A high privileged user (With Global Administrator role and User Access Admin on the root management group)

Preparation

Follow collie-cli installation guidelines to install collie-cli. After that, we will check that collie works properly.

  1. collie -V

We see that collie is installed, and is also checking if all dependencies are installed.

After installing collie and its required dependencies, login with az cli to the AAD tenant where you will deploy your landing zones.

  1. az login --tenant <aadTenantPrimaryDomain>

Configuration
At the beginning you will want to create a new cloud foundation with collie which makes it super simple to organize your code and later manage multiple of them.

  1. mkdir cloudfoundation && cd cloudfoundation
  2. collie init
  3. collie foundation new tutorial

When creating your new tutorial foundation you will go into interactive mode and be prompted to add a new cloud platform and configure it for your foundation.

Save and exit
Save and exit

As you can see from the screenshots above, first select add cloud platform, then choose Azure as your new platform, and finally configure your cloud platform and the Azure subscription that you will create all resources in.

Once you’re done, select save and exit.

Bootstrapping Action

Now, in order to actually build a Landing Zone, we simply make use of the Azure Landing Zones Terraform Module and include it in the Landing Zone construction-kit framework.

Let’s execute the following:

  1. collie kit bundle tutorialbundle
Selecting the KitBundle for Azure Enterprise Scale Modules
Selecting the KitBundle for Azure Enterprise Scale Modules
Configuring the KitBundle
Configuring the KitBundle

What this does is the following:

  1. Downloads the required kits (bootstrap and base)
  2. Queries basic information required to configure the inputs of your foundation. These are inputs that will be passed to the downloaded kits.
  3. Bootstraps your foundation; by creating an Azure object storage to store Terraform state and creating a service principal with required permissions to deploy your Landing Zones. This will also reconfigure the Terraform backend, and prompt you to migrate the Terraform state to the newly created storage!
Bootstraping at work: Terraform asks to migrate its state to the new remote storage
Bootstraping at work: Terraform asks to migrate its state to the new remote storage

Rolling out the Landing Zone

Now all you need to do is to deploy your Landing Zones with this command:

  1. collie foundation deploy tutorial --module base
Collie instructs Terraform to rollout Azure Enterprise Scale-Kit
Collie instructs Terraform to rollout Azure Enterprise Scale-Kit

This uses the previously configured inputs to deploy the Azure Zanding Zone Terraform module. It will take roughly 30 minutes to create all the cloud resources.

That's it!

Now you have deployed your Landing Zones with our bootstrap module and Azure Enterprise Scale module

  • You have your Terraform state managed in your new object storage
  • Access to that storage is restricted to specific users (those included in the foundation platform engineers group).
  • Your foundation has everything defined as code and you can utilize the Landing Zone Construction Kit to update your Zanding Zones.

How great is that? Almost no work starting from nothing to deploying your first Landing Zones that can otherwise take days, weeks or even longer! And the best thing is that everything is kept open and modular, so you can adopt the Landing Zone to your wishes and make it your own. But you have been kick-started with all the best practices recommended and developed by Azure.

What's next?

You have seen how easy it is now to set up a working Azure Landing Zone that follows Azure’s best practices. Now, you have everything at hand to go from “zero to hero”. Deploying Landing Zones, that is day 1 of Cloud Landing Zones lifecycle, is already a huge step towards a smooth cloud journey. But what about operating them (i.e. day 2)?

On a larger scale, when deploying multiple Landing Zones, their management becomes essential. Upgrading your Landing Zones when new functionalities arrive, when a fix is needed, or when a new security vulnerability is identified should be as fast and effortless as possible. This is where meshcloud’s meshStack comes into play.

Book a demo now!