[Guide pas à pas] Comprendre les rôles Azure : Rôles Azure RBAC vs Rôles Azure AD vs Rôles Classiques Azure

 

Introduction 

La notion de rôles dans Azure est souvent oubliée par les clients qui veulent aller « trop vite » et commencer à migrer/déployer des Workloads dans le Cloud.

Après plusieurs dizaines de missions autour d’Azure, j’ai constaté que la plupart des clients (pour ne pas dire tous ^_^), confondent toujours les rôles « RBAC » Azure de type « Owner, Contributor ou encore User Access Administrator« , avec les rôles Azure AD de type « Global Administrator /User Administrator ou encore Application Administrator/Developper« .

Sans parler des rôles Azure historiques « Classiques » de type « Administrateur de Comptes, Administrateur de Service ou encore Co-Administrateur« , introduits avec la toute première version d’Azure (Azure ASM : Azure Service Manager) dont peu de personnes connaissent l’existence.

Pour bien démarrer avec Azure, il est très important de comprendre chaque type de rôle, son utilité (quand et comment l’utiliser) et à quel niveau (Scope).

L’objectif du présent post est de vous présenter les différents rôles Azure, la différence entre eux, limitations relatives à chaque type de rôle et comment les implémenter dans vos environnements Cloud Azure.

Bonne lecture à tous !

 

Les rôles fournis avec Microsoft Azure

Trois types de rôles sont fournis aujourd’hui avec Microsoft Azure, à savoir :

• Les rôles Azure « Classiques » (rôles historiques)
• Les rôles Azure « RBAC »
• Les rôles Azure « Active Directory »

Reportez-vous aux sections suivantes pour en savoir plus !

Les rôles « Azure Classic » : Un peu d’historique

Quand Azure était proposé pour la première fois (sous le modèle de déploiement ASM : Azure Service Manager), la gestion des accès aux ressources se faisait via l’utilisation de trois rôles (Administrateurs) uniquement, à savoir :

• Administrateur de compte (Account Administrator)
• Administrateur de Service (Service Administrator)
• Co-Administrateur (Co-Administrator)

 

Lors de l’inscription à Microsoft Azure (création d’un nouveau compte/environnement Azure), le compte (Adresse Email) utilisé est automatiquement défini/déclaré en tant que « Administrateur de compte » et « Administrateur de Service ». Des Co-Administrateurs pourront ensuite être déclarés pour déléguer l’accès et la gestion des ressources Azure hébergées au niveau des abonnements.

Tip : Connectez-vous sur le Portail Azure, sélectionnez un de vos abonnements, et cliquez ensuite sur « Propriétés« , notez le nom du compte (Adresse Email) portant le rôle « Administrateur de compte » et « Administrateur de Service »

Les administrateurs « Classiques » ont un accès/contrôle total à la Souscription Azure. Ils peuvent gérer les ressources en utilisant le portail Azure ou via les API Azure ARM et ASM.

Note : Les Administrateurs de Services et les Co-administrateurs sont équivalents au rôle « Owner /Propriétaire » du nouveau modèle RBAC (Azure ARM) et offrent un accès total au niveau de l’abonnement. Le rôle « Administrateur de compte » quant à eux, ne permet pas la gestion des ressources. Cf tableau ci-dessous

Le tableau suivant décrit en détails les différences entre ces trois rôles Azure historiques :

Ce tableau peut être downloadé depuis ce lien Direct.

Vous aurez compris, avec Azure ASM, nous étions plus dans un modèle de Tout ou Rien (All-or-Nothing), car seuls les trois Administrateurs cités précédemment étaient disponibles, si votre politique de sécurité impose le principe du moindre privilège (PoLP : Principle of Least Privilege) et que vous deviez par exemple, limiter l’accès et la gestion de vos VMs Azure à un groupe d’utilisateurs spécifique, eh bien techniquement cela n’était pas possible, car tous les membres du groupe Azure AD auquel vous allez attribuer un des rôles Azure Classique se verront attribuer un rôle d’Administrateur (Co-Administrateur généralement), leur permettant automatiquement un accès total sur toutes les ressources Azure de votre abonnement.

Gérer l’attribution et la suppression des rôles Azure Classiques

Pour gérer l’attribution et la suppression des rôles Azure « Classiques », sélectionnez un abonnement,  groupe de ressources ou encore une Ressource Azure, et rendez-vous ensuite sous la Blade « Contrôle d’accès (IAM) » > onglet « Administrateurs Classiques » :

• La liste des Administrateurs Classiques (Administrateurs de Service et Co-Administrateurs) est affichée :

Note : le compte ayant servi à l’inscription sur Azure, est automatiquement déclaré en tant que « Administrateur de services fédérés ».

• Pour ajouter ou supprimer un Co-Administrateur, cliquez sur « Ajouter« , et sélectionnez ensuite « Ajoute un coadministrateur » :

N’hésitez pas à ajouter et supprimer un compte co-administrateur sur vos environnements de Test/Sandbox Azure et tester les droits qui lui seront attribuer.

 

En savoir plus sur les rôles Azure « Classiques »

Pour en savoir plus sur les rôles « Classiques » Azure, je vous invite à consulter cette documentation.

 

Ce qu’il faut retenir  

Azure étant proposé aujourd’hui qu’en mode ARM (Azure Resource Manager), la notion de rôles « Classiques » ne doit pas être prise en considération lors du design de votre modèle de délégation de droits Azure.

Le focus doit être porté sur les nouveaux rôles « RBAC » et « Azure AD ».

La section précédente avait simplement pour but de vous expliquer l’historique des premiers rôles apparus avec la première version d’Azure ASM.

 

Les rôles « Azure RBAC »

Avec l’introduction du modèle de déploiement Azure ARM (Azure Resource Manager), un nouveau modèle/système de gestion des droits d’accès a été introduit, il s’agit du modèle RBAC (Role-Based Access Control).

RBAC a permis à plusieurs entreprises ayant un niveau de sécurité « sérieux » de décoller et d’aller vers le Cloud.

Ce nouveau système de gestion de droits a résolu la problématique liée à l’ancien model de droit d’accès ASM offrant un niveau d’accès limité de type All-or-Nothing.

Azure RBAC permet en effet une gestion de droits d’accès plus fine et inclut (par défaut) plusieurs dizaines de rôles prédéfinis (Built-in) vous permettant de restreindre au maximum l’accès et la gestion à vos ressources et services Azure.

Microsoft a pensé son modèle RBAC de la manière suivante :

• Un type de rôle par Service/Offre Cloud (eg : Azure VM Contributor | Azure Sentinel Contributor…)
• Plusieurs profils au niveau du même rôle RBAC (eg : Azure Security Admin | Azure Security Reader …)

Note importante : les rôles Azure RBAC sont dédiés à l’accès et gestion des ressources Azure uniquement telles que les VMs Azure, Bases de données SQL Clusters HDI, Services Réseaux (VNET, Subnet, Gateway VPN, NSG, LB…) ou encore les WebApp, Mobile App…etc. La gestion de l’annuaire Azure AD et ses objets associés nécessitent d’autres droits /rôles (Rôles Azure AD), voir section suivante pour en savoir plus !

 

Il existe plus précisément (au moment de la rédaction du présent post) 166 rôles Azure intégrés (Built-in). Vous pouvez les visualiser depuis la Blade « Contrôle d’accès (IAM) » > « Rôles » :

RBAC vous permet de créer un modèle de délégation par profil (Build Team), par modèle de service Cloud (IaaS Builder, PaaS Contributor…) ou par offre Cloud(VM Builder, VNET Admin, Azure SQL Admin)…

 

Liste des « Built-in » Rôles RBAC Azure 

La liste complète des Built-in rôles RBAC Azure est disponible depuis l’URL suivante :

https://docs.microsoft.com/fr-fr/azure/role-based-access-control/built-in-roles

L’équipe Azure en charge de la partie RBAC mets régulièrement à jour cette liste, généralement après introduction d’un nouveau service /offre Cloud (eg : Azure Sentinel > introduction de nouveaux Built-in Roles : Azure Sentinel Contributor | Azure Sentinel Reader…).

Note : La suppression d’un service Cloud implique également la suppression des Built-in rôles RBAC associés. Avant de commencer vos travaux de conception du modèle RBAC, je vous recommande vivement de consulter cette page.

 

Les rôles RBAC fondamentaux 

Comme expliqué précédemment, il existe aujourd’hui plus de 150 Rôles RBAC Built-in.

Les 4 principaux rôles RBAC Built-in à retenir sont listés dans le tableau :

Rôle RBAC	Autorisations	Notes
Propriétaire (Owner)	Accès total à toutes les ressources Délégation de l’accès à d’autres personnes	L’administrateur de services et les coadministrateurs se voient attribuer le rôle Propriétaire/Owner au niveau de chaque abonnement. Ce rôle s’applique à tous les types de ressources.
Contributeur (Contributeur)	Création et gestion de tous les types de ressources Azure Ne peut pas attribuer/déléguer l’accès à d’autres personnes	Ce rôle s’applique à tous les types de ressources.
Lecteur (Reader)	Consultation/Lecture des ressources Azure uniquement	Ce rôle s’applique à tous les types de ressources.
Administrateur de l’accès utilisateur (User Access Administrator)	Gestion de l’accès utilisateur aux ressources Azure

 

Gérer l’attribution et la suppression des rôles Azure RBAC

Pour gérer l’attribution et la suppression des rôles Azure « RBAC », sélectionnez un abonnement, groupe de ressources ou une ressource et rendez-vous ensuite sous la Blade « Contrôle d’accès (IAM) » > onglet « Attributions de rôles » :

• Les attributions de rôles RBAC déclarées peuvent être consultées depuis cet onglet :

• Pour ajouter une nouvelle attribution de rôle, cliquez sur « Ajouter » et sélectionnez ensuite « Ajouter une attribution de rôle » :

• Dans l’exemple suivant, nous allons attribuer le rôle Virtual Machine Contributor (Contributeur de machines virtuelles) au groupe Azure AD « HK Run Team« .
  • Note : il faut cliquer ensuite sur « Enregistrer » pour que cette nouvelle attribution de rôle soit prise en compte.

• La nouvelle attribution de rôle RBAC (VM Contributor) apparaît désormais sous « Attribution de rôles« :

• Pour supprimer une attribution de rôle existante, il suffit de la sélectionner, et cliquez sur « Supprimer » :

• Vous serez invités à confirmer cette suppression en cliquant sur « Oui » :

 

Les Custom Rôles RBAC

Azure RBAC vous offre également la possibilité de créer vos propres rôles RBAC, appelés « Custom Roles » ou « Rôles personnalisés« .

Si les rôles RBAC « Built-In » fournis par défaut avec Azure ne répondent pas à vos besoins, vous pouvez créer vos rôles Custom et définir des droits/autorisations personnalisées.

Si votre politique de sécurité définit un modèle RBAC basé sur le concept du Least privilège, avec une utilisation de groupes (Azure AD) distincts permettant uniquement :

• La lecture et exportation de Logs Azure AD & des ressources
• Le démarrage, redémarrage et l’arrêt des services IaaS (VM) et PaaS (Serveurs SQL Azure)
• Création et lecture des règles NSG

vous avez la possibilité de créer des Custom Roles avec les autorisations nécessaires correspondant aux droits définis dans votre modèle de droit d’accès.

Un Custom Role est créé sur la base d’un fichier JSON, avec une structure (setting <> data value) spécifique.

L’exemple suivant, montre un Custom Role permettant uniquement le démarrage, arrêt et redémarrage des VMs Azure :

Je vous invite à consulter cet article pour en savoir plus sur les Azure Custom Roles.

 

Azure RBAC : Limitations

Il existe certaines limitations relatives à l’utilisation des rôles RBAC Azure, voir tableau ci-dessous :

ID Limitation	Description de la limitation
#1	Vous pouvez avoir jusqu’à 2 000 attributions de rôle dans chaque Souscription Azure
#2	Vous pouvez avoir jusqu’à 500 attributions de rôle dans chaque Management Group
#3	Vous pouvez avoir jusqu’à 5000 Custom roles par Tenant Azure

Note importante : la limitation #1 comprend l’attribution de rôles Built-in et Customs.

 

En savoir plus sur les rôles Azure « RBAC »

Pour en savoir plus sur les rôles RBAC Azure, je vous invite à consulter cette documentation.

 

Les rôles « Azure Active Directory »

Les rôles Administrateurs Azure AD (aka AAD) sont utilisés pour gérer les ressources de l’annuaire Azure AD, par exemple pour créer ou modifier des comptes utilisateurs Azure, attribuer des rôles d’administration à d’autres personnes ou gérer l’appartenance aux groupes Azure AD, réinitialiser les mots de passe des utilisateurs, gérer les licences utilisateur et encore gérer les propriétés du domaine Azure AD.

 

Liste des « Built-in » Rôles Azure AD 

La liste complète des Built-in rôles Azure AD est disponible depuis l’URL suivante :

https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#available-roles

Il existe (au moment de la rédaction du présent post) 56 rôles Built-in Azure AD.

L’équipe Azure en charge de la partie « IDentity/IAM | Azure AD » mets régulièrement à jour cette liste, je vous invite à consulter cette page avant de démarrer vos travaux de conception des droits Azure AD.

 

Les rôles Azure AD fondamentaux 

Les 3 principaux rôles Built-in Azure AD à retenir sont listés dans le tableau :

Rôle AzureAD	Autorisations	Notes
Administrateur général (Global Administrator)	·       Gestion de l’accès à toutes les fonctionnalités d’administration dans Azure Active Directory, ainsi que les services qui sont fédérés à Azure Active Directory ·       Attribution des rôles d’administrateur à d’autres personnes ·       Réinitialisation des mots de passe des utilisateurs et de tous les autres administrateurs	La personne/utilisateur qui déploie l’annuaire Azure Active Directory est automatiquement déclarée en tant qu’Administrateur général.
Administrateur d’utilisateurs (Users Administrator)	·       Création et gestion de tous les aspects liés aux utilisateurs et aux groupes ·       Gestion des tickets de support ·       Suivi de l’intégrité des services ·       Changement des mots de passe des utilisateurs, des administrateurs du support technique et autres administrateurs d’utilisateurs
Administrateur de facturation (Billing Administrator)	·       Achats ·       Gestion des abonnements Azure ·       Gestion des tickets de support ·       Suivi de l’intégrité des services

 

Gérer l’attribution et la suppression des rôles Azure AD

Pour gérer l’attribution et la suppression des rôles « Azure AD », cherchez et sélectionnez le service « Azure Active Directory », et rendez-vous ensuite sous la Blade « Rôles et Administrateurs »:

• La liste des rôles Azure AD vous est retournée (à droite)
• Vous pouvez également voir le rôle Azure AD qui vous est attribué actuellement sur Azure AD:

• Pour ajouter une attribution de rôle Azure AD, commencez par sélectionner (cliquer) sur le rôle en question (Users Administrator/Administrateurs d’utilisateurs dans l’exemple suivant), et cliquez ensuite sur « Ajouter des affectations« . Dans l’exemple ci-dessous, nous avons ajouté/déclaré l’utilisateur (Hicham KADIRI) en tant que « Users Administrator »:

• Les affectations de rôles Azure AD peuvent être consultés depuis le rôle Azure AD, ou en sélectionnant un compte utilisateurs et cliquant sur « Rôles affectés » :

• Pour supprimer une attribution/affectation de rôle Azure AD, il suffit de sélectionner le compte utilisateur, et cliquez sur « Supprimer les attributions« .

 

Les Custom Rôles Azure AD

Comme pour les rôles Azure RBAC, vous avez la possibilité de créer vos propres rôles Azure AD Custom et définir vos droits/autorisations personnalisées.

Les Custom Roles Azure AD sont créés à partir de fichiers JSON aussi, et disposent la même syntaxe/structure que les Custom Roles RBAC.

Si vous voulez en savoir plus sur les Custom Roles Azure AD, je vous recommande la consultation de cette page.

 

En savoir sur sur les rôles Azure Active Directory

Pour en savoir plus sur les rôles Azure AD, je vous invite à consulter cette documentation.

 

Quelle est la différence entre les rôles « Azure RBAC » vs « Azure AD » ? Se chevauchent-ils entre eux ? 

Comme expliqué précédemment, les rôles Azure RBAC sont dédiés à la gestion des droits d’accès au niveau des services /ressources Azure (Compute, Storage, Network…), alors que les rôles Azure AD, sont plutôt dédiés à la gestion des objets Azure AD et des ressources Office 365 associées.

L’image ci-dessous illustre la séparation (Scope) de ces deux types de rôles :

 

Note importante [ce qu’il faut retenir !] : les rôles RBAC vous permettent de définir un modèle de déléguation /droit d’accès aux ressources Azure (VM, Compte de Stockage, VNet, Base PaaS SQL, WebApp, Cluster HDI…), les rôles Azure AD quant à eux, vous permettent de définir un modèle de droit d’accès aux objets associés à l’annuaire Azure AD (objets Utilisateurs, Groupes, Apps…). De plus, Azure RBAC contrôle l’accès aux ressources Azure à l’aide d’Azure Resource Management (ARM) alors que les Custom Roles Azure AD contrôlent l’accès aux ressources Azure AD à l’aide de l’API Graph.

 

Ayant des étendues (Scopes) différents, les rôles Azure RBAC et Azure AD ne se chevauchent jamais entre eux.

Les droits attribués via les deux catégories de rôles (RBAC & Azure AD) sont uniques et définis à des scopes distincts (Ressources Azure <> annuaire Azure AD), par conséquent, aucun impact /chevauchement n’a lieu.

 

Licensing Azure RBAC vs Azure AD

Azure RBAC est un service gratuit :), aucune licence n’est requise pour implémenter vos rôles RBAC Built-in et Custom.
En revanche, la création de rôles Custom pour Azure AD, nécessite un niveau de Licensing Azure AD Premium 1 ou 2.

 

Élévation de privilège : From « Azure AD Global Administrator » to « User Access Admin » 

En tant qu’administrateur général (Global Administrator) dans Azure Active Directory (Azure AD), il est possible que vous n’ayez pas accès à tous les abonnements et groupes d’administration de votre annuaire. Cet article décrit les méthodes pour élever votre accès à tous les abonnements et groupes d’administration.

 

Pourquoi devez-vous élever votre accès ?

Si vous êtes Azure AD Global Admin, il peut vous arriver de vouloir effectuer les opérations suivantes :

• Récupérer l’accès à un abonnement ou groupe d’administration Azure quand un utilisateur a perdu cet accès
• Accorder à un autre utilisateur ou à vous-même l’accès à un abonnement ou groupe d’administration Azure
• Voir tous les abonnements ou groupes d’administration Azure au sein d’une organisation
• Autoriser une application d’automation (telle qu’une application de facturation ou d’audit) à accéder à tous les abonnements ou groupes d’administration Azure

 

Comment fonctionne l’accès avec élévation de privilèges ?

Les ressources Azure AD et Azure sont sécurisées de façon indépendante les unes des autres. Ainsi, les attributions de rôles Azure AD n’accordent pas d’accès aux ressources Azure et inversement, les attributions de rôles Azure n’accordent pas d’accès à Azure AD. En revanche, si vous êtes administrateur général dans Azure AD, vous pouvez vous attribuer à vous-même un accès à tous les abonnements et groupes d’administration Azure de votre annuaire. Utilisez cette fonctionnalité si vous n’avez pas accès aux ressources de l’abonnement Azure, comme les machines virtuelles ou les comptes de stockage, et que vous voulez utiliser vos privilèges d’administrateur général pour accéder à ces ressources.

Quand vous élevez votre accès, le rôle Administrateur de l’accès utilisateur vous est attribué dans Azure au niveau de l’étendue racine (/). Ceci vous permet de voir toutes les ressources et d’attribuer des accès dans n’importe quel abonnement ou groupe d’administration de l’annuaire. Les attributions de rôles Administrateur de l’accès utilisateur peuvent être supprimées à l’aide d’Azure PowerShell, d’Azure CLI ou de l’API REST.

Vous devez supprimer cet accès avec élévation de privilèges après avoir effectué les modifications nécessaires au niveau de l’étendue racine.

 

Comment élever l’accès d’un Global Administrator Azure AD

Suivez les instructions suivantes pour élever les privilèges d’un Compte Global Administrator Azure AD :

#1. Connectez-vous au Portail Azure ou au Centre d’administration Azure Active Directory en tant qu’administrateur général.

#2. Recherchez et sélectionnez Azure Active Directory

#3. Sous Gérer, sélectionnez Propriétés.

#4. Sous Gestion de l’accès pour les ressources Azure (Access management for Azure Resources), sélectionnez « Oui /Yes« :

Quand vous sélectionnez « Oui », le rôle Administrateur de l’accès utilisateur (User Access Administrator) vous est attribué dans Azure RBAC au niveau de la racine (/). Ceci vous accorde l’autorisation d’attribuer des rôles dans tous les abonnements et groupes d’administration Azure associés à cet annuaire Azure AD. Cette option est disponible seulement pour les utilisateurs auxquels le rôle Administrateur général a été attribué dans Azure AD.

Quand cette option est définie sur Non, le rôle Administrateur de l’accès utilisateur dans Azure RBAC est supprimé de votre compte d’utilisateur. Vous n’aurez plus la possibilité de vous attribuer des droits/rôles aux niveaux des abonnements et groupes d’administration Azure associés à votre Azure AD.

 

#5. Cliquez sur Enregistrer pour que la modification soit prise en compte.

Note importante : cette option n’est pas une propriété globale et s’applique uniquement à l’utilisateur connecté. Vous ne pouvez pas élever l’accès des autres utilisateurs Azure AD Global Admin.

 

#6. Déconnectez-vous et reconnectez-vous pour actualiser votre accès.

Vous devez maintenant avoir accès à tous les abonnements (Subscriptions) et à tous les groupes d’administration (Management Groups) de votre annuaire Azure AD.

 

Guide pas à pas sur « Azure RBAC » 

Je suis en train de finaliser un guide assez détaillé (step-by-step) sur le sujet « Azure RBAC ».

Ce guide sera bientôt disponible en téléchargement gratuit sur Slideshare, n’hésitez pas à vous abonner pour rester informé dès sa publication :).

 

Conclusion

La notion de rôles dans Azure est un item important à prendre en considération dans la phase « Design » de tout projet de migration vers Azure ou le déploiement d’infra Cloud Native.

Le modèle RBAC est un composant critique du modèle de gouvernance Global Azure, prenez donc le temps d’étudier le sujet avant de commencer à déployer vos Workloads dans le Cloud.

 

 

Optimisez votre consommation Azure : Les 12 Best Practices que vous devez connaître !

Introduction 

Pour certains : Cloud = réduction des coûts IT, alors que cela n’est pas forcément vraie !

Quand on adopte le Cloud, c’est surtout pour bénéficier de la puissance d’un CloudOs : puissance de calcul, Sclabilité, Fléxbilité …

Plusieurs clients déployant des Workloads dans le Cloud ou migrant celles hébergées initialement OnPrem, se rendent compte que les factures à la fin du mois peuvent vite devenir salées car souvent oublient de définir une gouvernance Azure « Financière » qui leur permettent de contrôler, comment les ressources Cloud sont déployées, consommées et monitorées.

J’ai décidé aujourd’hui de partager avec vous quelques Best Practices ainsi que des « Tips & Tricks » vous permettant de contrôler et d’optimiser votre conso Azure.

Plus précisément, nous allons parler des items suivants :

• Azure Advisor
• Les Reserved Instances
• Azure Hybrid Benefit
• Arrêts/Démarrages auto des VMs Azure
• Utilisation des Stratégies (Policies) Azure
• Utilisation des Tags
• Utilisation du Stockage Azure de type « Cool & Archive »
• Utilisation d’Azure Budgets
• Utilisation de l’Auto-Scaling
• Dimensionnement des ressources Azure
• Utilisation des Souscriptions Azure Dev/Test
• CleanUp des ressources Azure

 

Bonne lecture à tous :).

 

#1 : Azure Advisor

Azure Advisor est un Consultant Azure « Virtuel » et « Automatisé » qui vous aide à optimiser et sécuriser vos déploiements Cloud mais aussi à réduire vos coûts Azure. Il s’appuie sur tout un ensemble de « Best Practices » et règles de conformité/sécurité standards.

En effet, Azure Advisor examine la configuration de tous vos services Azure déployés et vous propose des recommandations dans les domaines suivants

• Haute Disponibilité
• Sécurité
• Performance
• Coût

 

Le périmètre d’analyse Azure Advisor est limité aux :

• Abonnements
• Groupes de Ressources

 

Vous pouvez utiliser Azure Advisor pour analyser/évaluer la configuration de vos ressources, Az Advisor pourra ensuite vous proposer des recommandations en cas de sous-utilisation de certaines Workload tels que les VM Azure.

Dans l’exemple suivant, Azure Advisor nous fait part de deux recommandations assez intéressantes :

• Downsizer plusieurs VM Azure car celles-ci sont sous-utilisées, cela nous fera apparemment économiser +2200€ /an
• Supprimer une Adresse/Interface IP Public qui n’est apparemment, associée à aucune ressource Azure, cela nous fera +30€ d’économie.

Azure Advisor : Pricing 

Azure Advisor est un service gratuit :).

A noter tout de même que vous avez la possibilité de souscrire à un panel d’options de support (AzAdvisor) à partir de 24€.

eBook Azure Advisor : j’ai récemment publié sur BecomeITExpert.com un eBook dédié à Azure Advisor, Cliquez ici pour en savoir plus.

 

#2 : Azure Reserved Instances

Azure Reserved Instances (Azure RI)  vous permettent de réduire considérablement votre consommation Azure (jusqu’à 72%) en vous engagement sur 1 ou 3 ans.

Le principe est simple : plus on s’engage dans le temps pour consommer, plus on obtient de remise.

En fonction de la durée d’engagement (1 ou 3 ans), vous pouvez obtenir des remises pouvant atteindre les -72%.

Tip : vous pouvez atteindre 80% de remise si vous activez l’Azure Hybrid Benefit‘. Voir section suivante pour en savoir plus.

 

Services concernés par Azure RI

Les réservations concerne uniquement le Compute (Puissance de calcul). Les RI peuvent être achetées pour les services Azure suivants :

• Azure VM
• Azure Cosmos DB
• Azure SQL Database
• Azure SQL Data Warehouse
• App Service

 

Note importante : les réduction de coût Azure via les RI concerne uniquement la puissance de calcul (Compute). Le coût relatif au stockage, réseau, licences (eg : Azure SQL) ne sont pas concernées les instances réservées.

 

Pré-requis 

Pour pouvoir acheter des instances réservées, vous devez avoir le rôle « Owner /Propriétaire » au niveau de l’abonnement.

 

Qui peut acheter des Instances réservées ?

Pour pouvoir acheter des instances réservées, vous devez avoir le rôle « Owner /Propriétaire » au niveau Souscription de type :

• [EA] Enterprise Agreement (Offres : MS-AZR-0017P ou MS-AZR-0148P)
• Pay-As-You-Go (Offres : MS-AZR-0003P ou MS-AZR-0023P)
• Microsoft Customer Agreement.

Si vous êtes CSP (Cloud Solution Provider), vous pouvez utiliser soit le Portail Azure ou le Centre Partenaire pour acheter des Réservation Azure..

Modalités de paiement 

Vous pouvez payer une réservation à l’avance ou tous les mois. Une même réservation avec paiement initial et avec paiements mensuels a le même coût total : vous ne payez pas de frais supplémentaires si vous optez pour le paiement mensuel.

• Note : Le paiement mensuel est disponible pour les réservations Azure, et non pour les produits tiers.

 

1 ou 3 ans ? combien puis-je économiser exactement ?

Seul la Calculatrice Azure peut répondre à ce type de question :).

Voyons combien nous coûtera une VM Windows « Standard_B4ms » réservée pendant 3 ans, et hébergée en France (Central).

• Rendez-vous sur Calculatrice Azure, et ajoutez « Machine Virtuelle« .
• Configurez les options suivantes :
  • Région : France Central
  • Guest OS : Windows
  • Niveau : Standard
  • SKU : B4ms

 

Pour du Pay-as-you-Go (sans engagement), cette VM nous coûtera 163,52$ /mois

Calculons maintenant le prix de cette même VM avec un engagement sur 3 ans (Réservation pendant 3 ans)

Comme indiqué dans la capture d’écran ci-dessus, nous économisons ~100$ /mois avec un RI de 3 ans : 3600$ sur les 3 ans, ce qui n’est pas négligeable du tout.

 

Acheter des Reserved Instance

Cliquez ici pour acheter des instances réservées Azure.

Ce Blade vous permet également de visualiser les RI déjà achetées !

Dans l’exemple suivant, nous allons acheter une instance réservée de VM, commencez par cliquer sur « Acheter maintenant »

Cliquez sur « Acheter » sous « Machine Virtuelle » :

Le Menu suivant apparaît, vous pouvez définir des filtres (eg : dureé d’engagement 1an ou 3 an, région Azure…) :

Il suffit de sélectionner la VM qui vous intéresse pour la réserver pendant 1 ou 3 ans, vous pourrons ainsi réduire votre conso Compute Azure.

Pour en savoir plus sur les instance Réservées Azure, je vous invite à consulter cette page.

Information utile

Les réservations peuvent être annulées à tout moment, vous switcherez automatiquement en mode Pay-as-you-Go dès annulation d’une réservation.

 

#3 : Azure Hybrid Benefit

Azure Hybrid Benefit est une option tarifaire qui vous permet d’étendre vos Licences Windows Server et SQL Server dans le Cloud Azure.

Si vous disposez des licences Windows Server ou SQL Server via contrat SA (Software Assurance) ou équivalent (Licences de type EAS, Abonnement SCE ou Abonnement Open Value), sachez que vous pouvez les réutiliser pour vos Workloads Azure (Azure VM, Azure SQL, ou SQL Server sur des VMs Azure), et réduire le coût de ces ressources de manière considérable.

Vous économisez généralement jusqu’à 80% quand vous combinez Azure Hybrid Benefit avec les instances réservées (RI) Azure.

 

Source : Microsoft Docs

 

Services concernés par Azure Hybrid Benefit

La liste des services/produits est la suivante :

• Windows Server Standard Edition avec Software Assurance
• Windows Server Datacenter Edition avec Software Assurance
• SQL Server Enterprise Core avec Software Assurance
• Azure SQL Database

 

HowTo : activer Azure Hybrid Benefit

Azure Hybrid Benefit peut être activé lors du déploiement d’une nouvelle VM, vous pouvez également l’activer sur des VMs existantes.

Il suffit de répondre « Oui » au niveau de l’option « Vous disposez déjà d’une licence Windows Server » lors du déploiement d’une nouvelle VM Azure.

Vous devez ensuite confirmer cela en cochant « Je confirme que j’ai une licence Windows Server avec Software Assurance… » :

Si vous avez oublié de le faire pour vos anciens déploiement VMs, vous pouvez toujours activer l’Azure Hybrid Benefit au niveau du Blade « Configuration » de vos VMs, voir exemple suivant :

Il s’agit ici d’une méthode manuelle, qui n’est bien évidemment pas la plus adaptée quand il s’agit d’un environnement Azure avec plusieurs dizaines ou centaines de VMs. Cela peut être réalisé de manière automatisée via des scripts PowerShell (Update-AzVM) ou Az CLI (az vm update).

Tip : les commandes PS et Az CLI qui vous permettent d’updater la configuration de vos VMs pour activer Azure Hybrid Benefit sont listées ci-dessous :

Commandes PowerShell

$vm = Get-AzVM -ResourceGroup "saisir_ici_leNom_de_votre_RG"

$vm.LicenseType = "Windows_Server"

Update-AzVM -ResourceGroupName "saisir_ici_leNom_de_votre_RG" -VM $vm

Commande Az CLI (2.0)

az vm update --resource-group "saisir_ici_leNom_de_votre_RG" --set licenseType=Windows_Server

 

Forcez l’utilisation d’Azure Hybrid Benefit

Perso, pour mes clients disposant déjà d’un contrat SA, je déploie plutôt une Policy Azure qui exige l’activation d’Azure Hybrid Benefit pour tout nouveau déploiement de VM, cela permet de s’assurer que toute VM déployée est configurée avec Hybrid Benefit.

Le code JSON de la Policy est le suivant :

{
"type": "Microsoft.Authorization/policyDefinitions",
"name": "enforce-hybrid-use-benefit",
"properties": {
"displayName": "Enforce hybrid use benefit",
"description": "This policy will enforce usage of hybrid use benefit.",
"parameters": {},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"in": [
"Microsoft.Compute/virtualMachines",
"Microsoft.Compute/VirtualMachineScaleSets"
]
},
{
"field": "Microsoft.Compute/imagePublisher",
"equals": "MicrosoftWindowsServer"
},
{
"field": "Microsoft.Compute/imageOffer",
"equals": "WindowsServer"
},
{
"field": "Microsoft.Compute/imageSKU",
"in": [
"2008-R2-SP1",
"2008-R2-SP1-smalldisk",
"2012-Datacenter",
"2012-Datacenter-smalldisk",
"2012-R2-Datacenter",
"2012-R2-Datacenter-smalldisk",
"2016-Datacenter",
"2016-Datacenter-Server-Core",
"2016-Datacenter-Server-Core-smalldisk",
"2016-Datacenter-smalldisk",
"2016-Datacenter-with-Containers",
"2016-Datacenter-with-RDSH"
]
},
{
"field": "Microsoft.Compute/licenseType",
"notEquals": "Windows_Server"
}
]
},
"then": {
"effect": "deny"
}
}
}
}

Après implémentation de cette Policy, si l’équipe Ops Azure tentent de déployer une nouvelle VM sans activation de l’Azure Hybrid Benefit, elle recevra le message d’erreur suivant :

 

Combien puis-je économiser avec Azure Hybrid Benefit ?

Microsoft propose un outil (Web) qui vous permet de calculer combine vous pourrez économiser avec l’activation de l’Azure Hybrid Benefit, l’outil est disponible depuis cet URL.

Dans l’exemple suivant, nous faisons un calcul simple sur la base de 100 Licences Windows Server (Datancer) qui seront activées dans Azure via l’offre Hybrid Benefit. Pour bénéfier de l’offre Hybrid Benefit, les VMs Azure sur lesquelles vos Licences SA seront activées doivent respecter certaines SKU, dans l’exemple suivant, la VM SKU D3 v2 est sélectionnée :

 

Comme montré dans la capture d’écran, grâce à Azure Hybrid Benefit, nous économisons presque 25.000€ /an pour 100 Licences Windows Server.

Cela dû au fait qu’avec Azure Hybrid Benefit, vous économiserez le coût de la Licence Windows Server (Standard ou Datacenter) et vous payerez uniquement les frais liés à l’infrastructure Azure hébergeant votre VM :

 

Consultez cette page pour en savoir sur Azure Hybrid Benefit

 

#4 : Configurer des arrêts/démarrages auto sur vos VMs

Planifier des arrêts et démarrages automatiques sur vos VMs Azure non critiques/hors production: Dev, Recette, Intégration, Sandbox…

Cela vous permet de réduire vos coûts Azure de manière considérable (jusqu’à 66%).

Prenons l’exemple d’une VM à 100$/mois qui est utilisée uniquement 7 ou 8 heures par jour, si vous planifiez son arrêt/démarrage automatique, vous serez facturés uniquement pendant les 7/8 heures d’exécution, vous paierez donc 100$ /3 = 33,33$ au lieu de 100$.

Options d’arrêt/démarrage auto

Il existe plusieurs options/fonctionnalités vous permettant de planifier des arrêts/démarrage auto de vos VMs.

• Fonctionnalité Buit-in appelée « Arrêt automatique« , disponible au niveau de chaque VM
  • • Notez que cette feature ne vous permet pas le démarrage automatique de la VM, cela devra donc se faire à la main ou via un scheduler/script.

• Utilisation d’Azure Automation : je vous invite à consulter cette page pour en savoir plus
  • Note : un post dédié à ce sujet est en cours de finalisation, n’hésitez pas à vous abonner sur mon Blog pour être informé dès sa publication.

 

#5 : Définir et Appliquer des Stratégies (Policies) Azure

Azure Policy une composante critique et importante du modèle de gouvernance global Azure.

Les Stratégies Azure vous permettent de définir vos standards de sécurité/conformité, et s’assurer que les ressources déployée sont « Compliant » depuis le déploiement jusqu’à exécution/utilisation.

Azure Policy peut être utilisé pour contrôler le type de SKU pouvant être déployé dans vos environnements Azure.

Le use-case qui revient le plus, est l’utilisation d’Azure Policy pour forcer l’utilisation de certains SKU de VM Azure (SKU Whitelisting) pour éviter l’utilisation de certains « SKU Monster » comme la M Serie (Up to 128 vCPUs /3.8TB de RAM) pouvant générer une consommation Azure très importante.

Dans l’exemple suivant, nous allons utiliser Azure Policy pour autoriser que les Azure VM SKU suivants :

D Serie, plus précisément :

• D1_v2
• D2_v2
• D3_v2

Pour ce faire, sélectionnez votre abonnement (ou un RG si vous souhaitez appliquer cette Stratégie au niveau d’un RG), cliquez sur « Stratégies« , cliquez ensuite sur « Assigner une stratégie« , l’assistant s’affiche et vous demande de renseigner certains valeurs de paramètres.

Cliquez sur … au niveau de la définition de la stratégie, et cherchez la définition SKU, comme montré dans la capture d’écran suivante :

Sélectionnez « Références SKU de machine virtuelle autorisées« , attribuez un nom à votre Policy Assignment, et cliquez sur Suivant pour continuer.

Sélectionnez les SKU de VM à autoriser (onglet « Paramètres« ), dans l’exemple suivant, nous allons sélectionner les 3 SKU suivants : D1_v2, D2_v2 et D3_v2

Enfin, cliquez sur « Vérifier + Créer » pour assigner votre Policy. Celle-ci apparaît désormais sous « Affectations » :

Comme montré dans la capture d’écran suivant, un Admin Azure tente de créer une VM en SKU G, le déploiement est refusé par la Policy que nous venons de définir, pour pouvoir déployer une VM Azure dans notre environnement, le SKU doit correspondre à D1_v2, D2_v2 ou D3_v2, Vous pouvez ainsi contrôler les coûts Azure générés par vos ressources IaaS Azure VM.

Guide pas à pas sur « Azure Policy »

Si vous voulez en savoir plus sur Azure Policy, je vous invite à consulter le guide pas à pas suivant :

[Azure Governance] Lesson 4 : Azure Policy from ☁ Hicham KADIRI ☁

Il s’agit d’un Slideshare, vous pouvez le consulter/télécharger directement depuis ce Link.

 

#6 : Forcer l’utilisation des Tags

Les Tags vous permettent d’organiser vos Ressources Azure de manière logique et par Catégorie.

L’utilisation de Tags dans Azure est primordial, car vous permettra de savoir :

• Qui est propriétaire de la ressource (Tag : ResourceOwner)
• La ressource appartient à quelle application (Tag : Application Name)
• S’agit d’une ressource Dev/PreProd/Prod [Tag : EnvironmentType) ?
• La ressource a été déployée pour quel besoin (Tag : Project Code)
• Qui contacter en cas de maintenance de la ressource, si la machine doit être Patchée et rebooté (Tag : TechnicalContact)
• A qui doit-on (re)facturer cette ressource la fin du mois ? si la notion du charge-Back est adoptée (Tag : CostCenter)
• …

 

Grâce aux Tags Azure, vous pouvez faire un regroupement des coûts (par Appli, par type d’environnement …), ces informations sont très précieuses aux yeux du DAF :).

Les Tags vous permettent de connaitre combien vous coûtent vos ressources Dev à un instant T. Quel est le ResourceOwner qui consomme le plus de Ressources Azure …

Vous aurez compris, Tagger les ressources Azure devient plus qu’une bonne pratique, mais un moyen efficace pour suivre et tracer qui, consomme, quoi dans vos environnements Azure.

 

Si vous voulez en savoir plus sur Azure Tags, je vous invite à consulter le guide pas à pas suivant :

[Azure Governance] Lesson 3 : Azure Tags from ☁ Hicham KADIRI ☁

Il s’agit d’un Slideshare, vous pouvez le consulter/télécharger directement depuis ce Link.

 

#7 : Configurer des niveaux d’accès de type « Cool & Archive »

Toutes les données que vous uploadez vers ou générez depuis Azure ne doivent pas nécessairement être stockées sur du stockage Haute Performance. si vous classifiez vos données et créez des catégories avec le niveau de performance exigé, vous allez vite vous rendre compte que plusieurs types de données ne nécessitent pas vraiment un type de stockage très performant.

Azure propose aujourd’hui différents niveaux d’accès au Blog Stockage : Hot, Cool et Archive.

Le niveau d’accès « Hot » est surement dédié aux données qui sont fréquemment utilisées.

Les deux autres Access Tiers (Cool & Archive) peuvent être configurée quand il s’agit des données rarement utilisées (fichiers de Backup, logs…)

Pour économiser le coût lié au Stockage Azure, il est est recommandé d’utiliser les niveaux d’accès Cool & Archive et de n’utiliser le niveau « Hot » que quand c’est nécessaire.

 

Pourquoi utiliser un stockage Cool & Archive plutôt que Hot ?

Voyons d’abord c’est quoi la différence entre les niveaux « Cool » et « Archive ».

Stockage Azure « Cool » 

Le niveau de stockage de type « Cool », concerne les données peu consultées qui doivent être stockées (archivées) pendant au moins 30 jours. Quelques scénarios typiques incluent la sauvegarde des données avant archivage (sur des systèmes d’archivage), des fichiers multimédias, des logs/fichiers d’audit ou encore des données utilisés pour de l’Analytics Big Data…

Stockage Azure « Archive »

Comme son nom l’indique, le niveau de stockage de type « Archive » est un stockage peu coûteux pour les données d’archivage qui seront rarement consultées/accédées. Ce niveau concerne les données qui resteront stockées (archiveées) pendant au moins 180 jours, comme par exemple les données de sauvegarde l’historique médical, les fichiers logs, enregistrements audios/tél…

Quels avantages ?

Le coût d’un compte de Stockage configuré avec les niveaux d’accès « Cool » ou « Archive » sont beaucoup moins cher que celui en niveau d’accès « Hot ».

Consultez le tableau ci-dessous pour en savoir plus

Note importante : l’Archive Storage reste le moins coûteux > le 1 GB est à 0,002$ seulement (pour les 50 premiers TB).

Vous pouvez consulter le document ci-dessous pour en savoir plus sur les niveaux d’accès à Azure Storage

https://docs.microsoft.com/fr-fr/azure/storage/blobs/storage-blob-storage-tiers

 

 

#8 : Pensez à configurer des alertes quand le Budget est dépassé 

Azure fournit aujourd’hui plusieurs outils de gestion des coûts Azure, tels que « Analyse de coût », « Alertes de coût » ou encore « Azure Budgets« .

Ces outils vous permettent d’analyser, évaluer et suivre votre consommation Azure en temps réel.

Nous allons nous intéresser à Azure Budget dans un premier temps.

Grace à Azure Budget, vous pouvez définir votre budget pour une Application, Groupe de ressource, un abonnement …

Azure Budget vous permet également de suivre la consommation de ce budget mais aussi et surtout être alerté en cas de dépassement.

Note importante : en cas de dépassement des seuils budgétaires définis, seules des notifications sont déclenchées (alerte par mail). Aucune de vos ressources n’est impactée ou arrêtée et votre consommation n’est pas arrêtée. Azure Budget est simplement utilisé pour définir un Quota, comparer et suivre les dépenses lors de l’analyse des coûts.

 

Dans l’exemple suivant, nous définissons un budget de 1000€ /mois pour un groupe de ressource dédiée à une Application métier appelée « HRApp » :

Les alertes (par Mail) suivantes sont positionnées/définies :

Enfin, vous pouvez suivre/monitorer la consommation du budget défini depuis la Blade « Budgets » de votre RG ou Abonnement (colonne « Progression ») :

 

Note importante : L’outil Azure Budget est disponible uniquement depuis les abonnements Azure de type EA.

 

#9 : Auto-Scaling 

Un Cloud (Public ou Privé) se caractérise par les notions d’Élasticité et l’auto-Scaling, ce sont aujourd’hui les arguments qui poussent une DSI d’aller vers le Cloud.

L’auto-scaling permet d’étendre ou réduire automatiquement votre environnement Cloud. Vous n’avez plus à intervenir pour déployer des VMs supplémentaires ou supprimer ceux dont vous n’avez plus besoin,

Si vous disposez d’un site web e-Commerce hébergé dans le Cloud, vous pouvez mettre en place des mécanismes d’auto-scaling pour étendre ou réduire les capacités de votre web site en fonction de la charge (nombre de visiteurs/visites..). Si des Pics d’activité se présentent, votre web site sera re-sizer automatiquement pour supporter cette montée en charge, et sera downsizer quand l’activité revient à la normale.

 

Scalabilité horizontale vs scalabilité verticale

Il existe deux types de Scaling : Horizontale et Verticale

Scaling Verticale

Le Scaling Verticale est le plus intuitif : cela revient à ajouter des ressources à une VM unique (en lui ajoutant de la RAM, en changeant son CPU pour un plus véloce…). C’est simple ! Mais :

• Le coût est rapidement exponentiel de la capacité matérielle.
• Cette solution a des limites : vous pourrez probablement multiplier par 2 les capacités de votre serveur, peut-être même par 5, mais pas par 100 !

Cela reste dans la majorité des cas la solution la plus pragmatique, et en particulier pour des applicatifs en production depuis de nombreuses années.

 

Scaling Horizontale

Le Scaling horizontale revient à ajouter de nouveaux serveurs réalisant le même type tâche. Cela permet de n’utiliser que des serveurs standards (on parle de commodity hardware). Mais les implications logicielles sont rapidement importantes !

• L’application doit être stateless (sans état) : cela signifie que les données sont stockées dans un autre service (dans votre base de données, dans un cache distribué…)
  C’est l’idéal. Vous devriez concevoir vos nouveaux développement avec cet objectif.
• Si votre applicatif stocke des données en local (par exemple des données de sessions utilisateurs stockée en RAM) : vous pouvez malgré tout scaler horizontalement s’il est possible de couper ces données en sous ensembles indépendants (on parle de sharding). Il est alors nécessaire de s’assurer que chaque client ne communique qu’avec un unique serveur. Cela passe par exemple par un proxy qui redirige le client vers un serveur applicatif donné en fonction des identifiants du client, on parle de sticky session.
• Si il n’est pas possible de sharder facilement vos données, alors vous ne pouvez pas scaler horizontalement sans modifier en profondeur votre applicatif. Vous devez, au moins temporairement, vous en tenir à un scaling vertical.

 

Options d’auto-scaling Azure

Azure propose plusieurs options d’auto-Scaling vous permettant d’auto-configurer les capacités de vos services Cloud, le but étant de payer uniquement les ressources/capacités dont vous avez besoin, uniquement lorsque vous en avez besoin et éviter de payer des ressources/capacités inutiles.

Il est recommandé de concevoir et mettre en place une stratégie d’auto-Scaling sur vos ressources de Production Azure.

Je vous invite à consulter le post ci-dessous pour en savoir plus sur les options d’auto-Scaling Azure :

https://docs.microsoft.com/fr-fr/azure/azure-monitor/platform/autoscale-overview

 

#10 : Azure Dev/Test Subscriptions ?

Si vous êtes abonnés « Visual Studio », que vous souhaitez Builder des environnements Azure de Dev & Test, il est recommandé de souscrire à l’offre Azure Dev/Test plutôt qu’un abonnement Azure standard.

Azure Dev/Test, qu’est-ce que c’est ? 

Azure Dev/Test est une offre Azure dédiée aux Développeurs (exclusivement aux individus et sociétés disposant d’un abonnement Visual Studio) ayant besoin d’environnement Sandbox pour concevoir, développer et tester des services & applications dans Azure.

Avec l’offre Azure Dev/Test, trois options sont disponibles :

Ce qu’il faut retenir :

• Offre « Particulier » : Si vous êtes un Freelance/Particulier et souhaitez avoir un environnement de Dev/Test sur Azure, cette offre est faite pour vous. Votre abonnement VS (Visual Studio) vous permettra d’avoir jusqu’à 130€ de crédit azure mensuel.  C’est à vous de décider comment vous utilisez votre crédit mensuel. Il existe plusieurs services Azure auxquels vous pouvez attribuer le crédit (cf liens ci-dissous). Les Software inclus dans votre abonnement Visual Studio peuvent être utilisé sur les VMs Azure sans frais supplémentaires. De plus, vous payez un tarif réduit pour les VMs Azure.
  Si vous dépassez le crédit inclut (130€ Max), vous serez facturés de manière mensuelle (dès réception de la facture). Pour finir, notez qu’un seul abonnement Azure Dev/Test (par abonnement VS) est autorisé
• Offre « Equipes » (Clients EA : Enterprise Agreement) : vous permet d’avoir plusieurs abonnements Azure Dev/Test pour vos différentes équipes de Dev. Vous n’avez pas besoin de saisir les infos de votre CB lors de la souscription à l’offre Azure Dev/Test, vous serez facturés dans le cadre de votre contrat EA. Contrairement à l’offre « Particulier », cette option vous offre la possibilité de donner la main à vos End users pour exécuter les tests (recette) et donner leurs feedbacks.
• Offre « Equipes » (Hors Clients EA) : si vous êtes abonnés VS mais ne disposez pas de contrat EA et souhaitez avoir des abonnements Azure Dev/Test, eh bien dans rentrez dans cette catégorie. La différence avec l’option précédente réside dans le fait que vous êtes facturés de manière mensuelle (par CB et à réception de la facture).

 

Quels avantages ?

Tout d’abord, il faut noter que les trois options listées précédemment vous permettent d’utiliser les Software inclus dans votre abonnement Visual Studio (environnements de Dev & Test uniquement) sans frais supplémentaires. Pour l’exécution de VMs Azure, vous bénéficiez d’un prix réduit basé sur le prix de VM Linux.

Reportez-vous au tableau ci-dessous pour en savoir plus sur les avantages/remises possibles avec l’offre Azure Dev/Test :

 

Créer votre abonnement Azure Dev/Test

L’option ajouter un nouvel abonnement vous redirige vers le Portail suivant, il suffit de sélectionner ‘Abonnement Dev/Test » et suivre l’assistant pour créer votre nouvel abonnement Azure Dev/Test :

Quelques liens utiles

Je vous invite à consulter les documents suivants pour en savoir plus sur l’offre Azure Dev/Test « Particulier », « Equipes /EA » et « Equipes /Hors EA » :

• Offre Particulier Azure Dev/Test
• Offre Equipes /EA
• Offre Equipes /Hors EA
• Pricing Azure Dev/Test

 

Si vous souhaitez donc déployer des Workloads (de Dev/Test) dans Azure, privilégiez l’utilisation d’Azure Dev/Test :).

 

#11 : Downsizer les ressources oversizées

Une autre bonne pratique consiste à auditer/analyser régulièrement (une fois /mois par exemple) les ressources Azure pour identifier d’éventuelles ressources sur-dimensionner. Vous pouvez ensuite procéder à une Downsizing de ces services/ressources pour réduire les coûts Azure associés.

Ces opérations peuvent être industrialisées/automatisées à l’aide d’options/features d’auto-scaling (Up & Down) fournis avec Azure (cf Section #9).

 

#12 : Pensez à faire le CleanUp

Planifiez des CleanUp régulièrement !

Si cela ne se fait pas de manière automatique (via des RunBooks + Tags « EndDate /Date_Suppression… »), je vous propose la méthode /process suivant :

• Auditer /Identifier toutes les ressources « Inactives » : WebApps, VMs … éteintes et ne présentant aucune activitée depuis plus de 3 mois
• Se référer aux Tags pour connaitre les Resources Owner (Propriétaire) de ces ressources
• Rentrer en contact avec ces personnes pour leur faire part de vos futures opérations (suppression des ressources)
• Obtenir un GO /Validation des responsables/Owner de ces ressources
• Planifier la suppression des ressources non utilisées.
• Reporter (un mail suffit) après la réalisation des actions de suppression.

 

On a tous connu des Devs ou Business Users qui ont déployés pleins de RG à des fins de tests, mais qui n’ont jamais pris le temps d’arreter ou supprimer ces ressources en fin de PoC/Sandbox.

Ce Process vous permet de faire le ménage de manière régulière pour économiser les frais associés aux ressources déployées mais aussi avoir une infrastructure Azure propre et Always UpToDate :).

 

What Else ?

Partagez ces 12 BP avec votre DAF, il va surement Liker le post :).

A bientôt, Stay tuned.

#HK

[Public Preview] Azure Bastion : Tout ce que vous devez savoir !

 

Introduction

Avec son offre « Azure VM », Microsoft offre à ses clients la possibilité de déployer des infrastructures IaaS (Infrastructure-as-a–Service) sous Windows Server/Client ou Linux.

Par défaut :

• Toute VM Windows (Client ou Server) déployée est exposée à Internet et est accessible via le protocole RDP (Remote Desktop Protocol : Port 3389.
• Toute VM Linux déployée est exposée à Internet et est accessible via le protocole SSH (Secure SHell) : Port 22

 

En effet, lors de la création d’une nouvelle VM Azure (Windows ou Linux), l’assistant Azure vous propose la création d’une interface (IP) Publique pour permettre l’accès à votre VM (via RDP ou SSH) depuis Internet.

Cela vous expose à un risque important car vos VMs écoutent sur des ports (22/SSH et 3389/RDP) considérés étant vulnérables et très ciblés par les Hacker. Sans parler des Bots qui scannent en permanence les réseaux IP des Cloud Providers (tels que MS, AWS, GCP..etc) et essayent de Brute-forcer les accès SSH/RDP sur toute VM écoutant sur ces ports.

Pour réduire ce risque, certaines sociétés exposent seulement une VM (aka Jumpbox) de rebond utilisée pour atteindre les autres VMs en Back-end. Or, ce dernier devient donc aussi vulnérable car écoute toujours sur les mêmes ports (SSH/RDP), en outre, cet environnement Jumpbox est rarement « Hardené » et restreint (IP filtering, OS Hardening, AppLocker, Real-tim monitoring…etc)

D’autres sociétés ayant un niveau de sécurité plus sérieux, construisent un « vrai » environnement Bastion à base de RDS (Remote Desktop Services), comprenant une Gateway RDS pour exposer uniquement le protocole SSL/TLS (HTTPS) et encapsuler le protocole RDP over HTTPS.

Pour construire un environnement Bastion basé sur RDS, plusieurs services de rôles (et plusieurs VMs) doivent être déployées et configurées.

L’infra Bastion Azure (IaaS) peut comporter jusqu’à 6 ou 7 VMs (coût assez important), de plus, cette infrastructure devenant le point d’entrée aux infras IaaS Azure, doit être sécurisée, monitorée en permanence, backupée….etc donc un effort de gestion et maintenance non négligeable pour une société souhaitant s’offrir ce niveau de sécurité.

Enfin, les sociétés ayant plus d’exigences Sécu, n’exposent aucune VM sur Internet, même s’il s’agit d’une VM RD Gateway avec de l’HTTPS only, et optent pour une solution « Privée » qu’est la mise en place d’un VPN Point-to–Site ou P2S (si l’équipe Admin Cloud ne comporte pas plus de deux ou trois personnes) ou VPN Site-to–Site (ou S2S) s’elles souhaitent interconnecter le réseau local (ou un réseau Admin Local spécifique) avec leur VNET Azure.

• Note : les deux VPN modes sont sécurisés
  • VPN S2S : IPSec /IKEv2
  • VPN P2S : OpenVPN ou SSTP « SSL/TLS based-authentification à base de certificat »

 

Ce 18 Juin 2019, l’équipe Azure Corp a annoncé la disponibilité d’un nouveau service de sécurité appelé « Azure Bastion« .

Ce service peut remplacer toutes les solutions citées ci-haut, et vous allez vite comprendre pourquoi :).

 

Azure Bastion : qu’est-ce que c’est ?

Azure Bastion est un service PaaS (Platform-as-a–Service) entièrement géré et maintenu par Microsoft (Sécurisation, Patch Management….), il fournit un accès RDP et SSH sécurisé à vos VMs Azure (Windows & Linux) directement via le portail Azure.

Azure Bastion est déployé/associé au niveau de chaque réseau virtuel (VNet) Azure et prend en charge toutes les VMs faisant partie du VNET.

Vos VMs ne sont jamais exposées sur Internet (pas d’@IP Publique), seul le service Azure Bastion est exposé et est accessible via HTTPS (via le Portail Azure).

Ce service peut remplacer votre infrastructure Bastion RDS traditionnelle, vous pouvez ainsi réduire le coût lié à l’infra VM Azure (plusieurs VMs > plusieurs centaines voire des milliers d’euros /mois, selon le sizing des VMs déployées) et réduire vos efforts de gestion, sécurisation, maintenance, backup…. (passage du mode IaaS au PaaS).

 

Azure Bastion est encore en « Public Preview », et est disponible uniquement pour les Régions Azure suivantes :

• West US
• East US
• West Europe
• South Central US
• Australia East
• Japan East

 

Azure Bastion : Big Picture

Le schéma suivant illustre l’accès RDP/SSH via Azure Bastion

source : Blog MS Azure

Pré-requis

Pour pouvoir déployer le service Azure Bastion, vous devez vérifier les deux prérequis suivants :

• Disposer d’un compte Azure, vous pouvez en créer-un gratuitement ici.
  • Note : Vous bénéficiez de 170€ de Crédit pour tout nouveau compte Azure créé.
• Enregistrer la fonctionnalité « AllowBastionHost » du fournisseur de ressources « Microsoft.Network » au niveau de votre abonnement, et ce en exécutant les commandes PS suivantes.
  • Note : les Commandes PS ci-dessous peuvent être exécutées depuis une instance PS locale ou directement depuis le Cloud Shell.

 

Tip : si votre compte Azure est associé à plusieurs abonnements, commencez par sélectionner celui pour lequel vous souhaitez enregistrer le service Azure Bastion (AllowBastionHost Feature), exécutez les commandes suivantes :

Maintenant que vous avez sélectionné votre abonnement, commencez par enregistrer la fonctionnalité « AllowBastionHost » en exécutant la commande suivante :

Register-AzureRmProviderFeature -FeatureName AllowBastionHost -ProviderNamespace Microsoft.Network

Exécutez ensuite la commande PS suivante pour enregistrer à nouveau votre abonnement avec le Provider NameSpace « Microsoft.Network » :

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

Enfin, exécutez la commande PS suivante pour vérifier que la Feature « AllowBastionHost » est bien enregistrée au niveau de votre abonnement :

Get-AzureRmProviderFeature -ProviderNamespace Microsoft.Network

Tip : La vérification de l’inscription/enregistrement du fournisseur de ressource ‘Microsoft.Network’ peut également être réalisée depuis le Portail Azure, en sélectionnant votre abonnement et cliquant sur le Blade ‘Resources providers’, voir capture d’écran ci-dessous :

Tous les prérequis ont été mis en place, maintenant nous allons découvrir comment déployer le service « Azure Bastion » et commencer à exploiter cette Amazing Feature :).

 

Méthodes de déploiement du Bastion Azure

Il existe deux méthodes de déploiement d’Azure Bastion :

• Déploiement depuis la Marketplace Azure
• Déploiement depuis les paramètres d’une VM Azure

 

HowTo : déployer Azure Bastion

Déployer un Bastion Azure depuis la Marketplace

Pour déployer le service Azure Bastion depuis la Marketplace, suivez les instructions suivantes :

• Connectez-vous sur le Portail Azure Preview, il est important d’utiliser ce lien plutôt que l’URL standard (https://portal.azure.com)
• Cliquez sur ‘Create a resource’
• Saisissez le mot ‘Bastion’ depuis la zone de recherche et sélectionnez ensuite ‘Bastion (preview)’ :

• Cliquez sur ‘Create’ pour continuer :

• Maintenant, sélectionnez/remplissez les informations suivantes et cliquez ensuite sur ‘Review + Create’.
  • Abonnement (Subscription)
  • Groupe de ressource (Resource Group)
  • Nom de l’instance Bastion Host Azure
  • Région de l’instance (sélectionnez l’une des 6 Régions prenant en charge Azure Bastion, voir la liste ci-haut)
  • Réseau Virtuel Azure (Virtual NETwork Azure) dans lequel le sous-réseau du Bastion Azure sera créé
  • Sous-réseau (Subnet) du Bastion Azure
    • Note importante : le Subnet qui sera dédié au Host Azure Bastion doit avoir les caractéristiques suivantes :
      • Doit avoir un Net(work)Mask ‘/27’
      • Doit être nommé ‘AzureBastionSubnet’
  • Nom de l’adresse IP Publique du Bastion vu qu’il sera exposé sur Internet (flux HTTPS Only !)
    • Note : l’@IP Publique qui sera attribuée au Bastion Host Azure sera statique, il s’agit d’un choix défini par défaut par Azure (non modifiable !)

• Le déploiement du service Azure Bastion démarre…

• Une fois déployé, le service Azure Bastion apparaît désormais dans le Groupe de Ressource spécifié lors du déploiement du Service Bastion Azure :

• Enfin, vous pouvez cliquer votre service Bastion pour afficher ses propriétés :

Déployer un Bastion Azure depuis les paramètres d’une VM Azure

Pour déployer/activer le service Azure Bastion depuis les Paramètres d’une VM Azure, suivez les instructions suivantes :

• Connectez-vous sur le Portail Azure Preview, il est important d’utiliser ce Lien plutôt que l’URL standard (https://portal.azure.com)
• Depuis le Blade « Toutes les ressources » ou « Virtual Machines » si vous l’avez « Favorisé », localisez et sélectionnez une VM Azure (Linux ou Windows)
• Cliquez sur « Connect » et cliquez ensuite sur « BASTION« 
• Si le service Bastion n’a jamais été déployé depuis la Marketplace comme montré précédemment, le bouton suivant (Use Bastion) s’affiche :

• Lorsque vous cliquez sur ce bouton, l’assistant de création du Bastion Host suivant s’affiche, vous êtes invité à renseigner les mêmes informations que celles demandées lors de la création du service Bastion depuis la Marketplace :

 

Note : si vous essayez d’activer Azure Bastion au niveau d’un VNET déployé sur une Région autres que celles (les 6 Régions) listées ci-haut, le message suivant vous est retourné :

 

HowTo : Se connecter aux VMs Azure via Azure Bastion

Pour se connecter à vos VMs Azure via Azure Bastion, rien de plus simple :

• Sélectionnez votre VM Azure,et cliquez sur « Connect« 
• Depuis la fenêtre qui s’affiche, cliquez sur « BASTION » et remplissez les informations de connexion/authentification :
• Dans l’exemple suivant, nous allons nous connecter (via RDP) à notre VM Azure Windows nommée « hkdemowsvm01« 

• Cette fois-ci, je me connecte en SSH à une VM Azure Linux « hkdemolinuxvm01 » :

Bien évidemment, les deux VMs (Windows & Linux) utilisées dans les exemples précédents ne sont pas exposées à Internet et ne disposent donc d’aucune Interface IP Publique :

hkdemowsvm01

hkdemolinuxvm01

 

HowTo : Copier/Coller du Texte

Seul le Clipboard (Copier/Coller) du Texte est autorisé à travers le service Azure Bastion (pour l’instant ^_^).

Pour les navigateurs Web prenant en charge l’accès avancé à l’API Presse-papiers, vous pouvez copier et coller du texte entre votre Device/PC local et la session distante (VM Azure cible) de la même manière que vous copiez et collez entre des applications hébergées sur une seule et même machine (locale).

Pour les autres navigateurs, vous pouvez utiliser la palette d’outils d’accès au presse-papiers Bastion.

Lors de la première connexion RDP ou SSH via Azure Bastion, vous serez invité à autoriser le Clipboard depuis votre Navigateur Web, le message suivant est affiché, et il suffit de cliquer sur « Allow » pour autoriser le Clipboard :

Comment ça marche ?

Une fois connecté (via RDP ou SSH) à une VM Azure, cliquez sur les deux Flèches situées à gauche de la fenêtre :

Copiez ensuite un texte depuis votre machine locale, notez qu’il est automatiquement ajouté à la boite de dialogue du Bastion Azure, voir capture d’écran ci-dessous :

Enfin, collez votre texte depuis la session distance Azure Bastion :

Azure Bastion : Limitations

Azure Bastion est déployé et associé au niveau Azure VNET, vous devez le déployer pour chaque VNET présent au sein de votre abonnement.

La prise en charge du VNET Peering n’est pas encore pris en charge, et Microsoft ne sait pas (pour l’instant) répondre à la question.

 

Conclusion 

Au moment de l’écriture de ce post, Azure Bastion est encore en « Public Preview », vous aurez compris : à ne pas déployer sur vos environnements Azure de Production.

Il présente encore quelques bugs et problèmes de stabilité, que j’ai d’ailleurs remontés à l’équipe Azure Corp.

Selon les infos communiquées par MS (NDA Comm), il sera GA (Generally Available) dans quelques mois.

Ce service Bastion pourra remplacer vos infrastructures Bastion de type RDS/RD Gateway (avec ou sans RD Web Access Portal). Vous passerez donc d’un mode IaaS (Infra RDS exécutée sur de plusieurs VMs Azure : coût important + effort de gestion) à une plateforme Bastion PaaS (Platform-as-a-Service) fully-managed par Microsoft, ce mode PaaS présente plusieurs avantages, à savoir : une plateforme always UpToDate et plus sécurisée.

 

Voilà :).

#HK

[Azure Free Training] Lesson4 : Tout ce que vous devez savoir sur « Azure Policy »

 

Liste des premiers modules de la série « Gouvernance Azure »

Les trois premiers modules de la série « Gouvernance Azure » sont disponibles depuis les URLs suivantes :

[Azure Free Training] Lesson1 : Définissez votre Convention de Nommage Azure

[Azure Free Training] Lesson2 : Protégez vos ressources Azure, Appliquez des « Locks Azure »

[Azure Free Training] Lesson3 : Tout ce que vous devez savoir sur Azure Tags

 

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (aka Onprem) vers Azure (Lift & Shift Mode) ou construire de nouvelles architectures Azure (« Cloud Native » Mode), notez que la Step1 de votre projet va consiste à définir un Modèle de Gouvernance Global pour Azure.

Comme illustré dans le schéma ci-dessus, le modèle de Gouvernance Azure (Azure Scaffold) est composé de :

• Convention de nommage (définition de vos naming standards pour vos ressources Azure)
• Modèle de délégation (RBAC)
• Policy (Stratégies Azure)
• Tags (Azure Resources Tags)
• Azure Locks
• Subscrption Design (Nombre d’abonnements à créer..etc)
• …Etc

 

Durant cette « Lesson 4 », nous allons découvrir un composant critique du Scaffold Azure qu’est « Azure Policy » ou « Stratégie Azure » en Français.

Azure Poliy est service de sécurité (et Gouvernance) Azure très puissant qui vous permet de définir et appliquer une politique de sécurité « Dès la concepton » (ou Security by Design en Anglais).

Azure Policy peut être utilisé pour renforcer la sécurité de votre environnement Azure en mettant en place des règles de sécurité telles que :

• Pas de déploiement de ressources Azure hors « France »
• Pas d’utilisation d’adresse IP Publique sur vos VMs
• Forcer l’utilisation de vos images Master Windows pour Azure VM
• Forcer le chiffrement des comptes de stockage Azure
• Auditer si des comptes propriétaires n’ont pas de MFA « activé »
• …

 

Avec Azure Policy, vos ressources Azure restent « Compliant » avec votre politique de sécurité existante, vous maitrisez aussi votre gouvernance global Azure en forçant vos règles/exigences de sécurité dès le déploiement de tout service Cloud Azure.

Consultez le document SlideShare ci-dessous pour en savoir plus, Enjoy :).

 

Step-by-step guide sur Azure Policy : Introduction & HowTo

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

[Azure Governance] Lesson 4 : Azure Policy from ☁ Hicham KADIRI ☁

Ce Slide a été rédigé en Anglais (pour atteindre un public plus large) mais sera bientôt disponible en Français sur la même plateforme.

 

Next Lesson ?

Je travaille actuellement sur les autres « Lessons/Modules » du modèle de Gouvernance Global Azure, à savoir :

• Azure RBAC
• Azure Resources Groups
• Azure Automation

 

N’hésitez pas à vous abonner à mon Blog (ou à mon profil SlideShare) pour rester informé de toute nouvelle publication.

Sinon, vos Comments/Feedbacks sont bien évidemment les bienvenus :).

#HK

[Azure Updates] Microsoft annonce des Disques Managed à 32 To /64 To

Microsoft vient d’annoncer la disponibilité des Managed Disks en « Large Size ».
En effet, vous pouvez désormais sélectionner/configurer des Disks Managés avec des tailles pouvant atteindre 32 To, voire 64 To en UltraSSD. Cette dernière est encore en mode « Preview ».

Pour en savoir plus :

https://azure.microsoft.com/fr-fr/blog/larger-more-powerful-managed-disks-for-azure-virtual-machines/

[Azure Free Training] Lesson3 : Tout ce que vous devez savoir sur Azure Tags

Liste des premiers modules de la série « Gouvernance Azure »

Les deux premiers modules de la série « Gouvernance Azure » sont disponibles depuis les URLs suivantes :

[Azure Free Training] Lesson1 : Définissez votre Convention de Nommage Azure

[Azure Free Training] Lesson2 : Protégez vos ressources Azure, Appliquez des « Locks Azure »

 

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (aka Onprem) vers Azure (Lift & Shift Mode) ou construire de nouvelles architectures Azure (« Cloud Native » Mode), notez que la Step1 de votre projet va consiste à définir un Modèle de Gouvernance Global pour Azure.

Comme illustré dans le schéma ci-dessus, le modèle de Gouvernance Azure (Azure Scaffold) est composé de :

• Convention de nommage (définition de vos naming standards pour vos ressources Azure)
• Modèle de délégation (RBAC)
• Policy (Stratégie Azure)
• Tags (Azure Resources Tags)
• Azure Locks
• Subscrption Design (Nombre d’abonnements à créer..etc)
• …Etc

 

Durant cette « Lesson 3 », nous allons découvrir la composante « Azure Tags » ou « Balises Azure » en Français.

Azure Tags vous permettent d’organiser, de manière logique les ressources Azure avec les propriétés que vous définissez. Les Tags deviennent très utiles lorsque vous devez organiser des ressources pour une meilleure gestion et/ou facturation (Billing) > eg : combine me coûte toutes les VMs de Production > il suffit de sélectionner toutes les VMs ayant comme Tag « Environnement=Production » pour le savoir :).

 

Step-by-step guide sur Azure Tags : Introduction & HowTo

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

[Azure Governance] Lesson 3 : Azure Tags from ☁ Hicham KADIRI ☁

Ce Slide a été rédigé en Anglais (pour atteindre un public plus large) mais sera bientôt disponible en Français sur la même plateforme.

 

Next Lesson ?

Je travaille actuellement sur les autres « Lessons/Modules » du modèle de Gouvernance Global Azure, à savoir :

• Azure Policies
• Azure RBAC
• Azure Resources Groups
• Azure Automation

 

N’hésitez pas à vous abonner à mon Blog (ou à mon profil SlideShare) pour rester informé de toute nouvelle publication.

Sinon, vos Comments/Feedbacks sont bien évidemment les bienvenus :).

#HK

[Azure Free Training] Lesson1 : Définissez votre Convention de Nommage Azure

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (aka Onprem) vers Azure (Lift & Shift Mode) ou construire de nouvelles architectures Azure (« Cloud Native » Mode), notez que la Step1 de votre projet va consiste à définir un Modèle de Gouvernance Global pour Azure.

Comme illustré dans le schéma ci-dessus, le modèle de Gouvernance Azure (Azure Scaffold) est composé de :

• Modèle de délégation (RBAC)
• Policies (Stratégies Azure)
• Tags (Azure Resources Tags)
• Abonnements (Azure
• Et Surtout la convention de nommage (Naming Convention/Standards) qui est un objet « transferve » du modèle de Gouvernance Azure.
• …

 

La convention de Nommage est l’une des composantes « Critique » de ce modèle de Gouvernance Azure.

En effet, définir une bonne convention de nommage vous facilitera la vie quand il s’agit de Reporter, faire du Billing Track, Localiser les ressources Cloud facilement….etc

Pour vous aider à construire ce modèle de Convention de Nommage Azure, je vous ai préparé un document détaillé (SlideShare) à travers lequel je vous explique toutes les contraintes et restrictions (Naming Rules Azure) à prendre en compte, et surtout mes Best Practices pour réussir la définition de votre Document de Convention de Nommage Azure.

 

Step-by-step guide : Comment construire sa convention de nommage Azure ?

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

[Azure Governance] Lesson 1 : Azure Naming Convention from ☁ Hicham KADIRI ☁

Ce Slide a été rédigé en Anglais (pour atteindre un public plus large) mais sera bientôt disponible en Français sur la même plateforme.

 

Next Module : Azure Locks

La deuxième Module « Azure Locks » est disponible à cet URL :

[Azure Free Training] Lesson2 : Protégez vos ressources Azure, Appliquez des « Locks Azure »

N’hésitez pas à vous abonner à mon Blog pour rester informé de toute nouvelle publication.

A bientôt,

#HK

[Azure VM] Quels sont les Rôles, Fonctionnalités et Logiciels « Serveur » que vous pouvez déployer sur une VM Azure ?

 

Lors de la phase « étude » d’un projet de migration de Datacenter vers Microsoft Azure, vous devez d’abord étudier, de manière approfondi les Workloads devant ET pouvant être migrées vers de la VM Azure.

Un client m’a récemment fait part du besoin suivant : je souhaiterais déployer une infra WDS (2012 R2 ou 2016) sur Azure (services WDS hébergé sur de la VM Azure).

Cette demande ne peut malheureusement être étudiée ni réalisée car :

WDS (Windows Deployment Services) est un rôle Windows non supporté sur une VM Azure

Vous aurez compris, il est primordial d’étudier et prendre connaissance de la liste complète des rôles, fonctionnalités et logiciels NON SUPPORTES sur une VM Azure avant de se précipiter et commencer à préparer et créer des environnements cibles unitelement … (perte de $$ et du time :)).

Nous allons découvrir à travers cet article les rôles Windows et composants serveurs que vous pouvez migrer « from OnPrem » ou directement déployer dans un environnement Azure VM (en mode IaaS  : Infrastructure-as-a–Service)

 

Rôles et Fonctionnalités Windows supportés sur une VM Azure

Les rôles suivants sont supportés sur une VM Azure exécutant Windows Server 2008 R2 ou ultérieur :

• Active Directory Certificate Services (AD CS) : certains Best Practices doivent être respectés pour déployer correctement une nouvelle PKI AD CS ou étendre votre PKI existante vers le Cloud Azure.
• Active Directory Domain Services (AD DS)
• Active Directory Federation Services (AD FS)
• Active Directory Lightweight Directory Services (AD LDS)
• Application Server
• DNS Server
• Failover Clustering *
• Services de fichiers
• Services de Stratégie et d’Accès Réseau
• Services d’impression et de Numérisation de document
• Services Bureau à distance (RDS : Remote Desktop Services **
• Web Server (IIS)
• Windows Server Update Service (WSUS)

 

*  : L’utilisation d’un Cluster à Basculement Windows Server sur une VM Azure présente certains prérequis :

Le Cluster à Basculement doit être exécuté sur les OS Windows Server suivants : Windows Server 2008 R2, 2012 ou 2012 R2

Pour les Cluster Windows Server 2008 R2 et 2012, le Hotfix 2854082 doit être installé sur tous les nœuds du Cluster

Le Cluster doit être accessible par une adresse IP unique

Le Cluster doit utiliser le Stockage Azure

** : si vous disposez déjà des CALs RDS Par-Utilisateur (avec un programme /contrat active SA « Software Assurance »), celles-ci peuvent être installées et utilisées sur un Windows Server « 2008 R2 ou ultérieur » qui tourne sous forme de VM Azure.

Notez donc que les rôles suivants ne sont pas supportés (au moment de la rédaction du présent article) sur une VM Azure exécutant Windows Server 2008 R2 ou ultérieur :

• DHCP Server
• Hyper-V
• Active Directory Rights Management Services (AD RMS)
• Windows Deployment Services (WDS)

 

En ce qui concerne les fonctionnalités Windows, celles listées ci-dessous ne sont pas supportées au moment de la rédaction de cet article:

• BitLocker (Chiffrement de disque OS non supporté, mais BitLocker peut être activé et utilisé sur des vDisks de données)
• iSNS (Internet Storage Name Service)
• Multipath I/O
• Equilibrage de la charge réseau (Network Load Balancing)
• Protocole PNRP (Peer Name Resolution Protocol)
• Service Routage et accès distant (RRAS : Routing and Remote Access service)
• DirectAccess
• Services SNMP
• Gestionnaire de stockage pour réseau SAN
• WINS (Windows Internet Name Service)
• Service de Réseau Local sans fil

 

Note importante : Si vous devez migrer des composants et/ou services d’infrastructure encore hébergés sur des VMs Windows Server 2003, je vous recommande la consultation de cet article pour prendre connaissances de certaines « Useful informations » concernant l’exécution de Windows Server 2003 sur une VM Azure

 

Logiciels & Composants Serveur supportés sur une VM Azure

Les logiciels et composants serveurs suivants peuvent être déployés et exécutés sur une VM Azure :

• Microsoft BizTalk Server 2013 ou ultérieur (Notez que certaines fonctionnalités BizTalk 2013 ne sont pas supportées en mode VM Azure)
• Microsoft Dynamics AX 2012 R3 ou ultérieur
• Microsoft Dynamics CRM 2013 ou ultérieur (Nécessite de l’Azure Premium Storage)
• Microsoft Dynamics GP 2013 ou ultérieur
• Microsoft Dynamics NAV 2013
• Exchange Server 2013 ou ultérieur
• Forefront Identity Manager 2010 R2 SP1 ou ultérieur
• Microsoft HPC Pack 2012 ou ultérieur
• Project Server 2013 ou ultérieur
• SharePoint Server 2010 ou ultérieur
• SQL Server 2008 ou ultérieur (version 64-bit uniquement)
• System Center 2012 Service Pack 1 (SP1) ou ultérieur
• Team Foundation Server 2012 ou ultérieur

 

En outre, deux autres points « importants » sont à retenir :

L’Upgrade d’OS (Guest OS) d’une VM Azure n’est pas supporté : Si vous souhaitez migrer vos Workloads vers des VMs Azure et migrer (upgrader) ensuite le Guest OS exécuté au niveau celles-ci, sachez que cette option n’est pas supportée. Pensez donc à migrer vos Guest OS (OnPrem) avant toute migration vers Azure.

Seuls les logiciels « Serveur » respectant la politique de Support Microsoft peuvent être hébergés et exécutés sur une VM Azure. Je vous invite à consulter cette page avant toute migration ou déploiement de logiciel serveur sur une VM Azure;

 

Lien utile ! 

Je vous recommande de consulter régulièrement cette page avant tout projet de migration vers des VMs Azure ou déploiement de nouveaux services ou composants en mode IaaS. Si de nouveaux rôles, fonctionnalités ou encore composants /logiciels serveurs sont pris en charge sur une VM Azure, cet article est automatiquement updaté par l’équipe Azure Corp.

Vous aurez compris, cette page est à garder dans son Folder « Web Favoris ».

HK.