Pourquoi me direz-vous ? Et bien pour des raisons de conformité, de performance ou de latence, il peut être crucial de savoir où se trouvent physiquement vos ressources Azure. Mais aussi pour des problèmes de capacités, il peut être nécessaire de savoir si les zones concernées ont assez de ressources pour héberger vos infrastructures.

Et cela vous permet aussi de gérer vos paramètres pour votre CI/CD pour s’assurer que les ressources se déploient dans les zones où les ressources sont disponibles.

Par exemple sur le firewall Azure, il y a en ce moment des contraintes sur les capacités comme le montre ce lien : Azure Documentation

Vous pouvez donc savoir quelle est la zone que vous utilisez pour votre souscription en utilisant la commande suivante :

az account list-locations --query "[?availabilityZoneMappings].{availabilityZoneMappings: availabilityZoneMappings, displayName: displayName, name: name}"

Cette commande vous donnera une liste de toutes les zones disponibles pour votre souscription, ainsi que les zones de disponibilité associées à chaque zone. Vous pourrez ainsi identifier la zone physique qui correspond à la zone logique que vous utilisez pour vos ressources Azure.

Et si vous préférez une interface graphique je vous recommande le site App Scout qui vous permettra de visualiser les différentes zones et leurs capacités en temps réel. C’est un outil très pratique pour gérer vos ressources Azure de manière efficace. Voici ce que cela donne pour la zone West Europe :

Il y a quelques années j’avais créé un système de Sandbox Azure qui me permet simplement de créer des resources group éphémères. Avec un simple script, je pouvais créer un resource group, faire mes tests, et ensuite la suppression est automatique en fonction de la date ajouté dans un tag. Rien de plus simple.

Maintenant pour faire cela, j’utilise principalement une fonction dans mon profil Powershell pour créer des resources groups. La fameuse fonction New-AzTestResourceGroup que certains d’entre vous l’ont peut être déja aperçu dans des démos que je fais.

Maintenant avec l’IA, c’est tellement plus rapide de dire à copilot “Créer moi un resource group demo-rg en France Central et ajoute moi un compte de stockage. Top au niveau de gain de temps, car en plus il va vous générer votre fichier de déploiement qui va bien. Cependant le resource group n’a pas toujours les bons tags.

Il y a une manière très simple de rajouter cela, il suffit de demander à Copilot de rajouter les différents tags que vous souhaitez à chaque fois que vous créer un resource group. Vous pouvez lui demander de scoper ce rajout à votre workspace. Mais aussi en global en ajoutant un fichier dans votre répertoire utilisateur.

Voici un exemple de fichier que vous pouvez ajouter dans votre répertoire utilisateur pour que Copilot puisse ajouter les tags automatiquement à chaque fois que vous créer un resource group.

# Azure Resource Group Tagging Convention

## Mandatory Tags for Resource Groups
When creating Azure resource groups, always add the following tags:

- **AutoDelete**: `true`
- **ExpirationDate**: Current date in format `YYYY-MM-DD` (e.g., 2026-03-05)

## Implementation
- Apply these tags when using Bicep, Terraform, ARM templates, or Azure CLI
- Use `resourceGroup()` function in Bicep or equivalent in other IaC tools
- Set tags at resource group creation time, not as an afterthought

Et pour le chemin il s’agit de celui ci : C:\Users\YourUserName\AppData\Roaming\Code\User\globalStorage\github.copilot-chat\memory-tool\memories

Et pouv finir voici de lien de l’aricle pour la sandbox : https://woivre.fr/blog/2018/11/sandbox-azure-pour-tout-le-monde

Voilà une petite astuce pour ne pas oublier de clean vos rsources après vos tests.

Si vous avez un environnement Azure que je qualifierais de standardisé et qui s’étend à plusieurs souscriptions. Il peut être tentant de vouloir refuser des recommandations ou du moins les reporter à plus tard.

Vous pouvez le faire rapidement via un script PowerShell ou autre. Pour cela, vous pouvez commencer par lister les différentes recommandations qui sont proposées via la commande suivante :

Get-AzAdvisorRecommendation -SubscriptionId <SubscriptionId>

Ensuite, vous pouvez filtrer les recommandations que vous souhaitez refuser ou reporter à plus tard. Par exemple, si vous souhaitez reporter une recommandation pour 90 jours, vous pouvez utiliser la commande suivante :

Disable-AzAdvisorRecommendation -RecommendationName e33855d4-7579-e4d0-c459-23fad3665bd6 -Day 90

Et si vous voulez simplement reporter un type de recommandation globalement , vous pouvez utiliser la commande suivante :

get-azAdvisorRecommendation | Where { $_.RecommendationTypeId -eq $recommendationId } | % { $_ | Disable-AzAdvisorRecommendation -Day 120 }

Allez objectif 2026, on gère les recommandations à l’échelle ! Et plus aucune active sans action planifiée !

Depuis un moment, Microsoft a mis à jour la configuration du boot diagnostics pour les machines virtuelles Azure. Désormais, il est possible de configurer le boot diagnostics sans avoir besoin de créer un compte de stockage dédié. Ou du moins il est maintenant entièrement managé par Microsoft.

Voici une requête Graph pour détecter toutes vos VMs qui ne sont pas encore passé sur ce nouveau mode de boot diagnostics :

resources
| where type =~ "microsoft.compute/virtualMachines"
| where properties.diagnosticsProfile.bootDiagnostics.enabled == true
| where isnotnull(properties.diagnosticsProfile.bootDiagnostics.storageUri)

Si cela peut vous éviter des storages dédiés au boot diagnostics, c’est toujours une ressource de moins à gérer et à sécuriser, et cela simplifie la configuration de vos machines virtuelles.

Alors concrétement que’est ce que cela change pour vous ? Et bien, si vous êtes en entreprise avec du Zero Trust, du hub & Spoke, cela ne change concrétement rien que pour vous. Car les subnets dans vos spokes sont par nature déjà privés, vu qu’ils passent par votre hub pour accéder à internet.

Par contre, pour les plus petits environnements, il faudra bien penser soit à remettre vos subnets en public, soit expliciter l’accès à internet via une NAT Gateway, un Firewall, ou un Load balancer avec une outbound rule ou une IP statique sur vos VMS.

Concrètement, votre route table que ce soit implicite ou explicite vers Internet est désactivée, il faut donc la remplacer par une route directe. Le plus simple est de mettre en place une NAT Gateway, mais attention au coût de cette dernière car le coût est aussi basé sur les datas qui transitent par celle ci.

Microsoft fourni des exemples pour le private subnet, je vous conseille d’y jeter un oeil : GitHub - Azure Networking Private Subnet Routing

Celle ci est très pratique, j’en conviens et je l’utilise régulièrement, mais elle peut aussi être dangereuse si elle est donnée à des personnes qui ne devraient pas l’avoir.

En effet la permission sur Windows tourne en temps que SYSTEM, et peut donc faire n’importe quoi sur la machine virtuelle, y compris installer des logiciels malveillants ou voler des données sensibles, ou désactiver des services de sécurité. Et sur Linux, ce n’est pas mieux elle tourne en tant que sudo, et peut aussi faire n’importe quoi.

Et pour couronner le tout, une fois que vous avez fait run, il n’est pas possible de stopper la commande, donc ne copiez pas des commandes que vous ne comprenez pas, ou que vous n’avez pas vérifiées, et ne les faites pas tourner sur des machines de production sans les avoir testées au préalable dans un environnement de test.

Donc ne donnez pas cette permission Microsoft.Compute/virtualMachines/runCommand/action à n’importe qui, et assurez vous que les personnes qui l’ont sont de confiance et savent ce qu’elles font. Où alors donnez le sur des machines dans des sandbox qui n’ont pas accès à vos environnements de production.

Précédemment, la réponse était très souvent quelque chose du genre “Désolé, il n’est pas possible d’agrandir un subnet, il faut en créer un nouveau et migrer les ressources ou garder 2 subnets disjoints. Il faudra bien le spécifier à chaque fois que vous faîtes des ouvertures de routes, ou que l’on doit modifier des routes tables”.

Bon maintenant, bonne nouvelle il est possible d’ajouter un deuxième address prefixe à votre subnet comme cela

$vnet = Get-AzVirtualNetwork -ResourceGroupName 'test-rg' -Name 'vnet-1'
Set-AzVirtualNetworkSubnetConfig -Name 'subnet-1' -VirtualNetwork $vnet -AddressPrefix '10.0.0.0/24', '10.0.1.0/24'
$vnet | Set-AzVirtualNetwork

L’avantage ici c’est que si vous avez la chance d’avoir des subnets joints comme dans l’exemple ci-dessus, vos ouvertures de routes passe simplement d’une 10.0.0.0/24 à un 10.0.0.0/23, et cela simplifie grandement vos opérations.

Mais aussi votre scale set à l’intérieur de votre subnet peut maintenant scale à 300 noeuds sans à avoir à déplacer votre workload dans un nouveau subnet. Mais aussi possible pour les GatewaySubnet si vous avez fait l’erreur de la créer en /29 pour mettre un simple Point to Site, et que vous voulez maintenant faire du VPN S2S ou du ExpressRoute.

Alors c’est certes quelque chose de bien connue, mais je vois tellement de personnes qui l’oublie ou qui se disent qu’ils ne seront pas touchés par ces limitations.

Donc commençons par la documentation officielle d’Azure qui liste les différentes limitations : https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

Ces limites peuvent vous paraître très lointaines par rapport à votre utilisation actuelle, mais vous pouvez les atteindre plus rapidement que vous ne le pensiez.

Par exemple mettre en place des bundles d’Azure Policy pour chaque type de resource et de risques, il y a une limite sur le nombre de définition custom par scope. Cela peut donc être un challenge au niveau de votre architecture de gouvernance, soit vous devez utiliser des initiatives, soit créer plusieurs scopes ou alors utilisez d’avantages de policy built-in.

Les custom role definition ont une limite au tenant aussi. Vous ne pouvez donc pas laisser tous vos utilisateurs créer des rôles personnalisés à tout va, sinon vous risquez d’atteindre cette limite plus rapidement que prévu, et de perdre la gouvernance sur les rôles qui existent.

Pour les gros utilisateurs d’Azure API Management, sachez entre autre qu’il y a des limites sur le nombre d’operations / instance. Et ce nombre comprend entre autre les opérations présente sur les révisions. Et par défaut le service n’offre pas de métrique simple pour vérifier si vous allez atteindre ou non cette limite, c’est donc à vous de la calculer et de bien gérer vos révisions non utilisées, ainsi que les API obsolètes.

De même pour Azure Firewall, il y a des limites sur le nombre de règles que vous pouvez créer. Et le calcul d’une règle correspond à 1 source, 1 destination, 1 port globalement. Donc si vous ajoutez la réglé Allow TCP 9093 from 10.0.0.0/24 and 10.0.1.0/24 to 10.1.0.0/24 cela correspond à 2 règles. Pour limiter cela il est possible de faire des ip groups, ou d’ouvrir en plus large quand cela est possible. Mais cela peut vite devenir un challenge de gérer ces règles, surtout si vous avez plusieurs équipes qui gèrent le firewall.

Mon conseil est donc pour chaque nouveau service que vous ouvrez sur votre plateforme, ou de chaque nouvelle fonctionnalité que vous offrez en self-service à vos utilisateurs, posez vous la question des limites et s’il est possible de les atteindre. Et n’oubliez pas que même si ces limites peuvent évoluer dans le temps, il est nécessaire d’appliquer tous vos processus régaliens autour de ces ressources comme l’inventaire et une gestion rigoureuse du cycle de vie.

Heureusement, Bicep propose un mode “local” qui vous permet de valider votre code Bicep sans avoir à déployer dans Azure. Cela peut être particulièrement utile pour vérifier la syntaxe, les types de ressources, et les dépendances entre les ressources.

Mais attention, cependant cela ne prend pas tout en compte, vu que vous ne déployez pas réellement les ressources.

Cela peut ppar contre être bien utile lorsque vous voulez vérifier rapidement la syntaxe, ou lorsque vous travaillez sur des fonctions personnalisées qui peuvent être complexes.

Pour cela il faut éditer votre fichier de configuration Bicep: bicepconfig.json

{
   "experimentalFeaturesEnabled": {
    "localDeploy": true
  }
}

Et vous pouvez ensuite éditer votre fichier bicep avec le targetscope à local :

targetScope = 'local'


var test = 'Hello, Bicep!'


output greeting string = test

ET franchement cela est bien pratique lorsque vous travaillez sur des fonctions un peu complexes ou vous pouvez calculer en local (et en mobilité sans une connexion internet)

Avant d’en parler un peu plus, je rappelle que déployer depuis votre VS Code par défaut c’est mal, il y a plein d’outils de CI/CD qui sont là pour ça, comme Github Actions. Mais bon pour des raisons de tests on va avouer que c’est quand même bien pratique.

Avant je faisais comme beaucoup avec la commande intégrée de Bicep: Deploy Bicep file…

Mais si vous créer un fichier de paramétrage de type bicepparam, il est possible d’afficher un panneau de déploiement qui ressemble à cela :

Et dans celui là ce qui va vous changer la vie (en tout cas la mienne) c’est le fait de pouvoir sélectionner un scope et qu’il le retienne. Donc pas besoin de spammer la toucher entrée après avoir lancé la commande Bicep: Deploy Bicep file…