We suggest we get started.
The aim of this webinar is to present Azure from a governance perspective, as well as the key architectural decisions involved in structuring a cloud platform. The topic is quite dense and the time is limited, so the pace will be fairly quick. As the session is being recorded, you will receive a link afterwards to watch it again.
Questions will be addressed at the end of the session. However, you can submit them throughout via the chat or the Q&A feature in Teams. They will be consolidated, and we will do our best to answer them within the available time. If needed, follow-up one-to-one discussions can be arranged.
We will begin with a brief introduction to PI Services by Coexya, then move on to Azure governance topics, followed by the main technical considerations around identity, networking, security, infrastructure and automation. Finally, we will share some feedback based on recent project experience.
PI Services by Coexya primarily supports clients with infrastructure consulting and audits, security, integration and deployment. We also provide support and managed services, across both IaaS and PaaS environments, particularly with a focus on securing and operating cloud platforms.
An Azure project typically revolves around several key areas, including governance, identity, security, management, infrastructure, networking and automation. One of the central concepts is the landing zone, which refers to a ready-to-use cloud environment made available to development teams. The objective is to give them enough flexibility to deploy new projects quickly, while still complying with the organisation’s governance, security and compliance requirements.
A landing zone also enables large-scale industrialisation, with reproducible environments such as development, testing and production. It facilitates onboarding for new projects or developers by providing a standardised framework with built-in best practices.
To structure these environments, Microsoft provides the Cloud Adoption Framework, which serves as a reference model. It covers all cloud-related aspects and helps organisations adopt proven best practices, whether designing a new architecture or assessing an existing one.
In Azure, the organisational structure is based on management groups, which allow subscriptions to be organised and governance rules to be applied consistently. Starting from a root group, environments are typically divided into several layers. A platform layer groups shared components such as networking, connectivity, DNS and firewalls. An identity layer handles authentication-related services. A management and security layer is used for centralised logging and monitoring, often leveraging a SIEM solution such as Microsoft Sentinel.
Applications are deployed within dedicated landing zones. These are often structured by application, with multiple environments, and include PaaS components such as App Services, Azure Functions, Key Vaults and storage accounts.
Governance relies on several key principles. It is essential to define a clear structure for resources, as well as a consistent naming convention from the outset. This convention should make it easy to identify resources, their environment, their location and their purpose, while also complying with Azure constraints.
Tagging also plays a crucial role, particularly for cost tracking and internal chargeback. It allows each resource to be associated with a project, a cost centre or a responsible owner.
Azure policies enable rules to be enforced automatically, for example to control data location, restrict public exposure of resources or ensure compliance with configuration standards. These policies can operate in audit mode, deny mode, or even apply automatic remediation.
Access management is another critical aspect. It relies on fine-grained delegation, typically based on groups, following the principle of least privilege. In some cases, custom roles may be created to meet specific requirements.
Cost management is also a key concern. Azure provides tools such as Cost Management and Advisor to analyse usage and identify optimisation opportunities. Best practices include setting up regular reporting, using reserved instances and optimising resource sizing. It is important to note that certain architectural choices, such as using private endpoints, can have a significant impact on costs.
From an identity and security perspective, several mechanisms should be implemented. These include enabling multi-factor authentication for sensitive accounts, using Privileged Identity Management to control elevated access, and setting up secure break glass accounts. Conditional access policies help strengthen security based on the context of each connection.
Centralised logging is essential for monitoring and incident detection. This is typically based on Log Analytics and can be complemented by a SIEM such as Sentinel. Secrets should be managed using services like Azure Key Vault, with particular attention given to their rotation.
From a networking standpoint, architectures are often based on a Hub and Spoke model, clearly separating shared components from application environments. Key considerations include IP addressing, traffic filtering, DNS resolution and connectivity with on-premise systems via VPN or ExpressRoute.
Since PaaS services are public by default, they can be secured using private endpoints. While this improves security, it also requires more advanced network and DNS management, and may introduce additional costs.
At the infrastructure level, several structuring decisions must be made, including the choice between IaaS, PaaS or containers, the redundancy strategy across regions or availability zones, and the approach to backup and disaster recovery.
Automation is also a key enabler. It relies on infrastructure as code, using tools such as Terraform or Bicep, as well as CI/CD pipelines. Services like Azure Functions, Logic Apps and Automation Accounts can be used to automate recurring tasks and improve operational reliability.
Finally, feedback from real-world projects shows that Azure architectures can vary significantly depending on the client context. Some environments are IaaS-focused, others heavily PaaS-oriented, with varying levels of automation and different architectural choices. Business constraints, security requirements and cost considerations all strongly influence these decisions.
In conclusion, an Azure project involves addressing a wide range of topics in a structured manner, in order to ensure architectural consistency, security and cost control.
As no questions were raised during the session, we remain available to discuss your needs or projects further.
Thank you for your attention.
The aim of this webinar is to present Azure from a governance perspective, as well as the key architectural decisions involved in structuring a cloud platform. The topic is quite dense and the time is limited, so the pace will be fairly quick. As the session is being recorded, you will receive a link afterwards to watch it again.
Questions will be addressed at the end of the session. However, you can submit them throughout via the chat or the Q&A feature in Teams. They will be consolidated, and we will do our best to answer them within the available time. If needed, follow-up one-to-one discussions can be arranged.
We will begin with a brief introduction to PI Services by Coexya, then move on to Azure governance topics, followed by the main technical considerations around identity, networking, security, infrastructure and automation. Finally, we will share some feedback based on recent project experience.
PI Services by Coexya primarily supports clients with infrastructure consulting and audits, security, integration and deployment. We also provide support and managed services, across both IaaS and PaaS environments, particularly with a focus on securing and operating cloud platforms.
An Azure project typically revolves around several key areas, including governance, identity, security, management, infrastructure, networking and automation. One of the central concepts is the landing zone, which refers to a ready-to-use cloud environment made available to development teams. The objective is to give them enough flexibility to deploy new projects quickly, while still complying with the organisation’s governance, security and compliance requirements.
A landing zone also enables large-scale industrialisation, with reproducible environments such as development, testing and production. It facilitates onboarding for new projects or developers by providing a standardised framework with built-in best practices.
To structure these environments, Microsoft provides the Cloud Adoption Framework, which serves as a reference model. It covers all cloud-related aspects and helps organisations adopt proven best practices, whether designing a new architecture or assessing an existing one.
In Azure, the organisational structure is based on management groups, which allow subscriptions to be organised and governance rules to be applied consistently. Starting from a root group, environments are typically divided into several layers. A platform layer groups shared components such as networking, connectivity, DNS and firewalls. An identity layer handles authentication-related services. A management and security layer is used for centralised logging and monitoring, often leveraging a SIEM solution such as Microsoft Sentinel.
Applications are deployed within dedicated landing zones. These are often structured by application, with multiple environments, and include PaaS components such as App Services, Azure Functions, Key Vaults and storage accounts.
Governance relies on several key principles. It is essential to define a clear structure for resources, as well as a consistent naming convention from the outset. This convention should make it easy to identify resources, their environment, their location and their purpose, while also complying with Azure constraints.
Tagging also plays a crucial role, particularly for cost tracking and internal chargeback. It allows each resource to be associated with a project, a cost centre or a responsible owner.
Azure policies enable rules to be enforced automatically, for example to control data location, restrict public exposure of resources or ensure compliance with configuration standards. These policies can operate in audit mode, deny mode, or even apply automatic remediation.
Access management is another critical aspect. It relies on fine-grained delegation, typically based on groups, following the principle of least privilege. In some cases, custom roles may be created to meet specific requirements.
Cost management is also a key concern. Azure provides tools such as Cost Management and Advisor to analyse usage and identify optimisation opportunities. Best practices include setting up regular reporting, using reserved instances and optimising resource sizing. It is important to note that certain architectural choices, such as using private endpoints, can have a significant impact on costs.
From an identity and security perspective, several mechanisms should be implemented. These include enabling multi-factor authentication for sensitive accounts, using Privileged Identity Management to control elevated access, and setting up secure break glass accounts. Conditional access policies help strengthen security based on the context of each connection.
Centralised logging is essential for monitoring and incident detection. This is typically based on Log Analytics and can be complemented by a SIEM such as Sentinel. Secrets should be managed using services like Azure Key Vault, with particular attention given to their rotation.
From a networking standpoint, architectures are often based on a Hub and Spoke model, clearly separating shared components from application environments. Key considerations include IP addressing, traffic filtering, DNS resolution and connectivity with on-premise systems via VPN or ExpressRoute.
Since PaaS services are public by default, they can be secured using private endpoints. While this improves security, it also requires more advanced network and DNS management, and may introduce additional costs.
At the infrastructure level, several structuring decisions must be made, including the choice between IaaS, PaaS or containers, the redundancy strategy across regions or availability zones, and the approach to backup and disaster recovery.
Automation is also a key enabler. It relies on infrastructure as code, using tools such as Terraform or Bicep, as well as CI/CD pipelines. Services like Azure Functions, Logic Apps and Automation Accounts can be used to automate recurring tasks and improve operational reliability.
Finally, feedback from real-world projects shows that Azure architectures can vary significantly depending on the client context. Some environments are IaaS-focused, others heavily PaaS-oriented, with varying levels of automation and different architectural choices. Business constraints, security requirements and cost considerations all strongly influence these decisions.
In conclusion, an Azure project involves addressing a wide range of topics in a structured manner, in order to ensure architectural consistency, security and cost control.
As no questions were raised during the session, we remain available to discuss your needs or projects further.
Thank you for your attention.