Les bases d'Azure : hiérarchie des ressources, Entra ID, calcul, stockage et réseau

La plupart des ingénieurs découvrent Azure après un autre cloud, et la difficulté est rarement conceptuelle. Régions, machines virtuelles, stockage objet et bases de données managées fonctionnent comme on s'y attend. Ce qui ralentit, c'est qu'Azure ajoute un niveau de regroupement que les autres fournisseurs n'ont pas, un service d'annuaire doté de son propre modèle de permissions à côté de celui des ressources, et des conventions de nommage où un même mot change de sens selon le contexte. Ce guide a pour but de vous faire franchir ce cap en une seule lecture.

Nous supposons que vous savez ce que sont une région, une zone de disponibilité et le modèle de responsabilité partagée ; sinon, commencez par les bases du cloud. Tout ce qui suit utilise les noms de services actuels ; lorsqu'un service a été renommé récemment, l'ancien nom apparaît une fois pour que la documentation plus ancienne reste compréhensible.

La hiérarchie des ressources

Azure organise tout en quatre niveaux imbriqués, et savoir à quel niveau appartient un paramètre évite bien des recherches.

Microsoft Entra tenant           frontière d'identité — utilisateurs, groupes, inscriptions d'applications
└── Management group             stratégies et accès hérités par tout ce qui est en dessous
    └── Management group (…)     jusqu'à six niveaux de profondeur
        └── Subscription         frontière de facturation + frontière de quotas
            └── Resource group   frontière de cycle de vie — déployé et supprimé ensemble
                └── Resource     une VM, un compte de stockage, une base de données

Le tenant est l'annuaire. Une organisation n'en a généralement qu'un, et c'est là que vivent les identités ; ce n'est pas là que vivent les ressources.

L'abonnement (subscription) est à la fois le conteneur de facturation et le conteneur de quotas. Chaque ressource appartient à exactement un abonnement. Les organisations découpent leurs abonnements selon ce qu'elles veulent facturer, isoler ou limiter séparément : production et hors production, un par entité métier, un par plateforme majeure. Les quotas, c'est-à-dire le nombre de cœurs d'une famille de VM que vous pouvez faire tourner dans une région, s'appliquent par abonnement, ce qui est la raison concrète de ne pas tout mettre dans un seul.

Le groupe d'administration (management group) se place au-dessus des abonnements et existe pour ne pas avoir à répéter la gouvernance. Les attributions Azure Policy et les attributions de rôles appliquées à un groupe d'administration sont héritées par tous les abonnements situés en dessous. Une structure typique comporte un groupe racine, puis des groupes pour la plateforme et les landing zones, puis la production et la hors-production sous ceux-ci.

Le groupe de ressources (resource group) est un dossier qui a du mordant. Les ressources qu'il contient peuvent être déployées ensemble, étiquetées ensemble, recevoir des accès ensemble et, surtout, être supprimées ensemble. Regroupez par cycle de vie, pas par type de ressource : tout ce qui est créé et détruit comme un tout va dans le même groupe.

Identité : Microsoft Entra ID et attributions de rôles

L'accès dans Azure comporte deux volets que les débutants confondent souvent.

Microsoft Entra ID (anciennement Azure Active Directory) authentifie. Il contient les utilisateurs, les groupes, les principaux de service et les inscriptions d'applications, et il émet les jetons. Les rôles d'Entra ID (Global Administrator, User Administrator, Application Administrator) gouvernent l'annuaire lui-même : qui peut créer des utilisateurs, donner son consentement à des applications ou réinitialiser des mots de passe.

Azure RBAC autorise les actions sur les ressources. Une attribution de rôle associe trois éléments : un principal de sécurité (utilisateur, groupe, principal de service ou identité managée), une définition de rôle (un ensemble d'opérations autorisées comme Contributor, Reader ou Storage Blob Data Reader) et une étendue (groupe d'administration, abonnement, groupe de ressources ou ressource unique). Les permissions se propagent vers le bas : une attribution Reader à l'échelle d'un abonnement fait du principal un lecteur de tout ce qu'il contient.

Être Global Administrator dans Entra ID ne donne, par défaut, aucune permission sur les ressources, une séparation qui surprend lors du premier incident. À l'inverse, un Owner d'abonnement ne peut pas créer d'utilisateurs.

L'identité managée est la fonctionnalité à utiliser en permanence. Elle donne à une ressource Azure une identité dans l'annuaire, gérée par la plateforme : pas de secret client, pas de certificat, pas de rotation. Une application web dotée d'une identité managée peut lire un secret dans Key Vault ou écrire dans un compte de stockage sans rien d'autre dans sa configuration qu'un nom de ressource.

# Accorder à l'identité managée d'une application web l'accès en lecture à un compte de stockage
appId=$(az webapp identity assign -g rg-orders-prod -n app-orders --query principalId -o tsv)
scope=$(az storage account show -g rg-orders-prod -n storders --query id -o tsv)

az role assignment create \
  --assignee-object-id "$appId" --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" --scope "$scope"

Pour tout ce qui est privilégié, ajoutez Privileged Identity Management afin que les rôles soient activés pour quelques heures, sur justification, plutôt que détenus en permanence, et exigez l'authentification multifacteur via l'accès conditionnel. Les principes de conception plus généraux sont traités dans gestion des identités et des accès.

Calcul : quatre options et comment choisir

Azure propose de nombreux services de calcul ; en pratique, la plupart des décisions se résument à quatre.

Les Virtual Machines se déclinent en familles nommées selon leur usage : B pour burstable, D pour usage général, E pour optimisé mémoire, F pour optimisé calcul, L pour les charges riches en stockage. Les scale sets regroupent des VM identiques derrière des règles d'autoscaling ; c'est ainsi qu'on exploite une couche applicative à base de VM en production.

App Service est le chemin le plus court vers la production pour une application web typique. Il s'exécute sur un App Service Plan, l'unité que vous payez réellement et la raison des mauvaises surprises sur la facture : le plan est facturé que les applications qu'il héberge reçoivent du trafic ou non, et plusieurs applications peuvent partager un même plan. Les slots de déploiement permettent de pousser sur un slot de staging, de le préchauffer puis de le basculer en production, ce qui vous donne des mises en production sans interruption, sans le moindre travail d'infrastructure.

Azure Kubernetes Service fournit gratuitement un control plane managé ; vous payez les nœuds. C'est la bonne réponse si vous faites déjà tourner Kubernetes ou si le nombre de services justifie un ordonnanceur, et la mauvaise pour trois microservices sans équipe plateforme. Lisez les bases de Kubernetes avant de vous engager.

Azure Functions facture à l'exécution avec le plan Consumption et descend jusqu'à zéro instance, au prix de cold starts. Le plan Premium garde des instances chaudes et offre l'intégration au réseau virtuel ; le plan dédié exécute les fonctions sur un App Service Plan que vous payez déjà.

Comptes de stockage, niveaux d'accès et disques

Un compte de stockage est un espace de noms qui regroupe jusqu'à quatre services : Blob (objets), Files (partages SMB/NFS), Queue (messages simples) et Table (lignes clé-valeur). La quasi-totalité des nouveaux projets utilise Blob storage, idéalement avec l'espace de noms hiérarchique activé si des outils d'analytique doivent le lire.

Deux paramètres pèsent plus que tout sur la facture et le comportement.

La redondance. LRS conserve trois copies dans un seul datacenter. ZRS répartit les copies entre les zones de disponibilité de la région ; c'est le choix par défaut raisonnable pour tout ce qui est en production. GRS et GZRS répliquent de façon asynchrone vers une région secondaire appairée ; les variantes à accès en lecture (RA-GRS, RA-GZRS) permettent de lire la copie secondaire pendant une panne régionale.

Le niveau d'accès. Le niveau Hot coûte plus cher au gigaoctet par mois et moins cher en lecture ; Cool, Cold et Archive inversent progressivement ce rapport, Archive exigeant une réhydratation explicite qui prend des heures. Définissez une stratégie de gestion du cycle de vie plutôt que de déplacer les blobs à la main.

{
  "rules": [{
    "name": "invoices-lifecycle",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["invoices/"] },
      "actions": { "baseBlob": {
        "tierToCool": { "daysAfterModificationGreaterThan": 30 },
        "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
        "delete": { "daysAfterModificationGreaterThan": 2555 }
      }}
    }
  }]
}

Les disques managés sont indépendants des comptes de stockage et servent de support aux machines virtuelles. Les niveaux vont de Standard HDD à Ultra Disk en passant par Standard SSD et Premium SSD ; avec Ultra Disk, vous provisionnez les IOPS et le débit indépendamment de la capacité. Premium SSD v2 offre généralement le meilleur rapport qualité-prix pour des bases de données sur VM.

Bases de données

Azure SQL Database est le choix relationnel managé par défaut : sauvegardes automatiques avec restauration à un instant donné, correctifs automatiques, et au choix un modèle d'achat DTU (une abstraction groupée) ou le modèle vCore (cœurs et mémoire explicites, seul modèle compatible avec Azure Hybrid Benefit pour les licences existantes). Le niveau serverless met en pause une base inactive, ce qui est parfait pour les environnements de développement. Azure Database for PostgreSQL et for MySQL offrent le même service managé pour les moteurs open source.

Azure Cosmos DB est le service NoSQL distribué à l'échelle mondiale. Il se distingue par des écritures multirégions clés en main et cinq niveaux de cohérence explicites entre forte et éventuelle, qui permettent d'arbitrer délibérément entre latence et fraîcheur des données. La capacité se provisionne en unités de requête par seconde, fixes ou en autoscale, ou se facture à la requête en mode serverless. Cosmos DB récompense un modèle de données conçu autour de modèles d'accès connus et pénalise les requêtes inter-partitions ; choisissez-le pour ce profil de charge, pas comme remplaçant généraliste de SQL.

Azure Cache for Redis couvre le cache et l'état de session, et Azure Service Bus la messagerie durable avec files et topics, quand vous avez besoin d'ordre, de sessions ou de transactions plutôt que de la simple Storage Queue.

Réseau

Un réseau virtuel (VNet) est un espace d'adressage privé dans une région, découpé en sous-réseaux. Deux VNet peuvent être reliés par peering, qui n'est pas transitif : relier A à B et B à C ne connecte pas A à C, ce qui piège ceux qui construisent une topologie hub-and-spoke en s'attendant à ce que le hub route automatiquement. En hub-and-spoke, on place un pare-feu ou une appliance virtuelle réseau dans le hub et on ajoute des routes définies par l'utilisateur pour forcer le trafic à y passer.

Un groupe de sécurité réseau (NSG) est une liste de règles d'autorisation et de refus, avec état, évaluées par priorité et attachables à un sous-réseau ou à une interface réseau. Les règles peuvent référencer des balises de service comme Storage ou AzureMonitor au lieu de plages IP, et les groupes de sécurité d'application permettent d'écrire des règles sur des groupes logiques de VM plutôt que sur des adresses.

Les points de terminaison privés (private endpoints) sont le modèle important pour les services de plateforme. Par défaut, un compte de stockage ou une base Azure SQL expose un point de terminaison public protégé par des clés et des règles de pare-feu ; un point de terminaison privé lui attribue une IP privée dans votre VNet, si bien que le trafic ne traverse jamais internet. Associez-le à une zone DNS privée pour que le nom d'hôte habituel se résolve vers cette adresse privée.

La connexion au réseau on-premise passe par une passerelle VPN sur internet ou par ExpressRoute sur un circuit privé, et la répartition du trafic se fait avec Load Balancer (couche 4), Application Gateway (couche 7, avec un pare-feu applicatif web) ou Front Door (global, avec cache en périphérie).

Infrastructure as code avec Bicep

Les modèles ARM sont le format de déploiement JSON sous-jacent ; Bicep est un langage lisible qui se compile vers ce format, et c'est lui que vous devriez écrire. Il n'a pas de fichier d'état (le graphe de ressources dans Azure fait office d'état) et les déploiements sont déclaratifs et idempotents.

param location string = resourceGroup().location
param appName string

resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: '${appName}-plan'
  location: location
  sku: { name: 'P1v3', tier: 'PremiumV3' }
}

resource site 'Microsoft.Web/sites@2023-12-01' = {
  name: appName
  location: location
  identity: { type: 'SystemAssigned' }
  properties: {
    serverFarmId: plan.id
    httpsOnly: true
    siteConfig: {
      linuxFxVersion: 'JAVA|21-java21'
      minTlsVersion: '1.2'
      ftpsState: 'Disabled'
    }
  }
}

output principalId string = site.identity.principalId

az deployment group create \
  --resource-group rg-orders-prod \
  --template-file main.bicep \
  --parameters appName=app-orders \
  --what-if      # prévisualiser les changements avant de les appliquer

Terraform est tout aussi viable sur Azure et reste le meilleur choix si vous gérez aussi d'autres fournisseurs ; le raisonnement est détaillé dans infrastructure as code.

Le vocabulaire d'AWS à Azure

La correspondance est approximative (les équivalents diffèrent par leurs capacités, pas seulement par leur nom), mais elle raccourcit la traduction.

Les erreurs classiques des débutants

Tout mettre dans un seul abonnement. Quotas, périmètre des stratégies et imputation des coûts fonctionnent tous au niveau de l'abonnement. Séparer tôt la production de la hors-production ne coûte rien et épargne une migration plus tard.

Croire que Global Administrator donne accès aux ressources. Ce n'est pas le cas, et c'est voulu. Élevez vos accès explicitement et temporairement quand vous en avez réellement besoin.

Payer des App Service Plans que personne n'utilise. Le plan est facturé en continu. Les plans de développement laissés actifs sont, de loin, la cause la plus fréquente d'une facture Azure inexpliquée.

Oublier que le peering n'est pas transitif. Les spokes ne peuvent pas se joindre via un hub sans routes et sans une appliance au milieu.

Laisser les services de plateforme sur leur point de terminaison public. Les règles de pare-feu aident, mais points de terminaison privés et DNS privé forment le modèle qu'attendent les relecteurs pour tout ce qui contient des données réglementées.

Points clés à retenir

• Azure imbrique les ressources dans le tenant, le groupe d'administration, l'abonnement et le groupe de ressources ; les stratégies et les attributions de rôles se propagent vers le bas, et le groupe de ressources est l'unité de déploiement et de suppression.
• Entra ID authentifie et ses rôles d'annuaire gouvernent l'annuaire ; Azure RBAC autorise les actions sur les ressources au moyen d'attributions de rôles dont l'étendue peut se situer n'importe où dans la hiérarchie.
• Les identités managées éliminent complètement les secrets stockés et devraient être le moyen par défaut pour les charges de travail d'accéder au stockage, aux bases de données et à Key Vault.
• Les choix de calcul se ramènent aux VM, à App Service, à AKS et à Functions ; les décisions de stockage sont dominées par la redondance et le niveau d'accès, et des stratégies de cycle de vie devraient déplacer les données automatiquement.
• VNet, NSG, peering non transitif et points de terminaison privés définissent la posture réseau ; Bicep ou Terraform devraient décrire l'ensemble sous forme de code.