Skip to main content

Deploy a IaaS architecture on an Innovate Landing Zone

Use Case​

You may want to use this architecture if :

  • You have specific workload that runs on Virtual Machine only
  • You want to lift and shift an existing On Premises solution
  • You want to expose your workload on Internet (If not, you should use a Protect Landing Zone)
  • You want to benefit from the monitoring and patch management we set up for you on an Innovate Landing Zone
  • You don't want your data to be exposed directly on Internet

Architecture / Design​

Innovate Landing Zone - IaaS Architecture example

This architecture shows a way to deploy a IaaS architecture on an Innovate Landing Zone.

The application is composed of :

  • A pool of servers exposed to users requests (front)
  • A pool of servers running background services (back)
  • Azure Managed Services for things like Database, Blob Storage, Key Vault, Monitoring,...

The goal of this architecture is to limit Internet Exposure to the Application Gateway (+ Web Application Firewall) only, and to connect to Azure Managed Services using Private Endpoints.

The monitoring and the patch management of the IaaS resources are handled by adding a Log Analytics Workspace and configuring Azure Monitor.

A public DNS Zone can be delegated (for a domain under thalesdigital.io) in the Landing Zone.

Each subnet within the Virtual Network is configured with a Network Security Group (NSG) to filter 'Inbound' connections and deny Internet exposure on subnets (except for the one with the Application Gateway).

Considerations​

The Innovate Landing Zone comes with a built-in Log Analytics Workspace and an Automation Account. Everything else must be deployed (ideally using IaC scripts).

Monitoring and Patch Management​

When deploying Virtual Machines, a set of policies in the Innovate Landing Zone will deploy monitoring agents automatically configured to send logs to the Log Analytics Workspace of the Landing Zone, and onboard the Virtual Machines with the Automation Account to provide Patch Managemnt Capabilities.

Refer to our documentation for more infos :

Virtual Network​

When deploying the Virtual Network, you can use the IP Ranges that you want if you do not need any peering with others Network.

If you need a specific peering to access a specific resources, contact the IT Network Team. They will provide you a specific IP Range and perform the peering.

This architecture requires at least 2 subnet to setup private endpoints :

  • The first one dedicated to PostgreSQL Flexible Server
  • The second one to host private endpoint for other Azure Managed Resources

Load Balancers and Public IPs​

The Load Balancers and Publics IPs must be deployed using a Standard SKU.

Network Security Groups​

The Network security groups must comply with the following rules :

  • Only port 443 and 80 can be exposed to Internet (globally)
  • Any other port can be exposed to a single Internet IP per rule
  • All port can be exposed to private IP Ranges (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12)

Since Public IPs must use the Standard SKU, a Network Security Group is mandatory per subnet.

PostgreSQL​

The Flexible SKU for PostgreSQL needs a delegated subnet in case of a private deployment like the one we recommend.

Private DNS Zones​

A private DNS zones is created for each type of Azure Managed Resource (Storage Account, Key Vault, PostgreSQL). Each one of the private DNS zones are linked to the VNet.

Certificate Management​

If you need to configure public certificate renewal on the application gateway, please refer to our documentation

Troubleshooting​

Consult Troubleshooting page