Infrastructure Landing Zone Prerequisites

Introduction

A landing zone could have multiple usages. From hosting few microservices to serving a large entity with transversal services. A list of settings are provided to size properly your environment.

The purpose of this documentation is to show these settings and explains the impacts.

Known limitations

Updating the following settings will impact the availability of your environment. We strongly recommend identifying precisely the use cases you want to cover with a landing zone before using the postIT form.

Settings

Corporate Addon

Possible choices:

• disable (default)
• enable

By default, the infrastructure landing zone is exposed to internet facilitating the interaction with your users and partners. Indeed, the cloud pushes our developers and architects to switch from a network isolation pattern to an authentication everywhere pattern. All our cloud resources are integrated to an internal azure active directory where all users are multifactorial authenticated (credentials + microsoft authenticator with laptop compliance for specific use cases).

But, if you are not confident with this exposure (risk of a misconfiguration, data sensitivity or all your users are using a corporate laptop* connected RIE), you can ask during the creation process to enable a Corporate Addon. This addon will enforce the network configuration to forbid any internet exposition.

Warning / known limitations:

• The corporate addon can be enabled only at the creation of the environment.
• The corporate addon cannot be disabled
• The end-users access is only limited to corporate networks (with a corporate laptop)

corporate laptop* : business networks or laptops are not considered by the Security System Information team as a corporate environment. No exception will be given

Network Size

Possible choices:

• Small
• Medium
• Large (default)
• X Large

Each environment could be potentially interconnected to the Trustnest Network Backbone (mandatory for P2S & S2S VPN or private integration with a shared runner). To do so, Trustnest provides an IP plan (to avoid any overlap). A challenge is to avoid having too many IP that are allocated to a project but not used. That's why we have created the Network Size setting.

Table bellow provide the available Address sizes. An Azure Virtual Network will be provisioned in your future Landing zone using the selected address space size.

Size name	IP	CIDR Style
S	64	/26
M	128	/25
L	256	/24
XL	512	/23

Please read the following use cases to select the right size.

Note that we can extend the Address ranges upon request. You do not need to "anticipate" your needs. Just ask us what you need right now.

Environment not connected to Network backbone

If you are sure to never be connected to Trustnest Network Backbone, please select Small Size (S).

Basic Environment

Usually, a "basic" infrastructure landing zone is used to interconnect backend services:

• microservices with queuing or caching system
• frontend with databases

If you are looking to interconnect the previous system internally (without having any network flow on internet), you will use Network Interface Card (NIC) to bind each part of your system to a Virtual Network (Vnet). If your Vnet is not large enough, it will be impossible to perform your interconnection.

Note: Azure reserves some IP address for management purpose

Examples:

• connecting 30 virtual machines
• using key vault, storage accounts, managed databases services. Under 30 services

For this use case: Small Size (S) should be sufficient

Kubernetes Environment

Azure Kubernetes Services with CNI network configuration pre-allocate Network Interface Card to the Virtual network; and AKS reserves a NIC per container.

Few examples:

• An AKS of 10 nodes with max_pod_per_node at 30 will consume ~300 NIC. XL is required.
• An AKS of 3 nodes with max_pod_per_node at 50 will consume ~150 NIC. L is ok

Note: If you plan to have more than 400 pods on your cluster. We strongly recommend you to split your system in subsystem each hosted on a dedicated AKS cluster. If it's not possible, consider the usage of kubenet network configuration

For this use case: Large Size (L) should be sufficient

Shared Environment

If you share a landing zone to a large number of users, you will have a high number of cloud resources deployed. Even XL would be not sufficient.

First, we recommend splitting the environment in multiple landing zone. Second, consider the usage of a Demilitarized Management Zone (DMZ) where this zone will be used to interconnect services using load balancing or reverse proxy.

Environment Type

Possible choices:

• Production (default)
• Non Production

For both Production and Non-Production, the Service Level Objectives (SLO) are the same. It means that the performance and the stability will be the same for Production and Non-Production landing zone.

Non-production type is cheaper than Production. In some context, it allows you to optimize your cloud spend.

The difference is on the Service Level Agreement (SLA):

• For production, if the agreement is not respected by Microsoft Azure (availability of a service for instance), Microsoft will give you credit compensating the issues. These credit will reduce your cloud spend bill for the next period.
• For non-production, if the agreement is not respected by Microsoft Azure, you will not have any credit.