Guide

Faire passer les dépenses informatiques des achats initiaux importants de matériel à un modèle de paiement à l'utilisation.

→Tirer parti du modèle de consommation basé sur le cloud.

Pourquoi: Cela convertit les dépenses d'investissement (CapEx) en dépenses d'exploitation (OpEx) prévisibles, éliminant le besoin d'acquisition et de gestion de centres de données.

Comprendre la division des responsabilités en matière de sécurité et de gestion entre le fournisseur de cloud et le client.

→Le fournisseur est responsable de la sécurité *du* cloud ; le client est responsable de la sécurité *dans* le cloud. Le client est toujours propriétaire de ses données, identités et points de terminaison.

Pourquoi: En IaaS, le client gère l'OS et les couches supérieures. En PaaS, le fournisseur gère l'OS, et le client gère l'application et les données. En SaaS, le fournisseur gère tout sauf les données et la configuration d'accès.

Référence↗

Choisir un modèle de déploiement basé sur les exigences de contrôle, de location et d'emplacement.

→Utiliser Public (infrastructure partagée), Privé (infrastructure dédiée, sur site ou hébergée) ou Hybride (mélange de Public et Privé).

Pourquoi: L'Hybride est essentiel pour conserver les systèmes sur site pour la réglementation/latence tout en utilisant le cloud public pour l'évolutivité et les services modernes. Le Privé offre un contrôle maximal.

Sélectionner le bon modèle de service cloud en fonction du niveau de contrôle de gestion souhaité.

→IaaS (par exemple, Azure VMs) pour un contrôle maximal sur l'OS. PaaS (par exemple, Azure App Service, Azure SQL) pour se concentrer sur le code, pas sur l'infrastructure. SaaS (par exemple, Microsoft 365) pour les logiciels prêts à l'emploi.

Pourquoi: Le compromis est le contrôle versus la commodité. En passant d'IaaS à SaaS, le fournisseur gère une plus grande partie de la pile, réduisant ainsi la charge opérationnelle du client.

Gérer les pics de trafic dynamiques et imprévisibles versus une croissance planifiée et soutenue.

→Utiliser l'Élasticité pour la mise à l'échelle automatique (in/out) afin de correspondre à la demande en temps réel. Utiliser l'Évolutivité pour une augmentation planifiée de la capacité (out/up) afin de gérer la croissance projetée.

Pourquoi: L'Élasticité est automatisée et réactive, idéale pour les charges de travail en dents de scie afin d'optimiser les coûts. L'Évolutivité est un concept plus large d'ajout de capacité, qui peut être manuel ou automatisé.

Protéger contre la défaillance d'un composant au sein d'une région versus une panne régionale catastrophique.

→Mettre en œuvre la Haute Disponibilité (HA) en utilisant des Zones de Disponibilité pour survivre aux pannes de centres de données. Mettre en œuvre la Récupération d'Urgence (DR) en utilisant la réplication inter-régions (par exemple, GRS) pour survivre à une catastrophe régionale.

Pourquoi: La HA consiste à maintenir le service avec un minimum d'interruption. La DR consiste à récupérer le service après une panne majeure. La HA est généralement automatisée avec un basculement rapide ; la DR implique souvent un processus de récupération formel.

Déployer des ressources pour une entité gouvernementale nécessitant une conformité et une résidence des données spécifiques.

→Utiliser un cloud souverain comme Azure Government.

Pourquoi: Ce sont des instances Azure physiquement isolées, gérées par du personnel habilité, et conçues pour répondre à des normes de conformité gouvernementales strictes (par exemple, FedRAMP, DoD).

Concevoir une application résiliente capable de résister à une panne de centre de données.

→Déployer des ressources sur plusieurs Zones de Disponibilité au sein d'une même Région Azure.

Pourquoi: Les Zones de Disponibilité sont des centres de données physiquement séparés avec une alimentation, un refroidissement et un réseau indépendants. Cela offre une haute disponibilité au sein d'une région sans la latence des déploiements inter-régions.

Référence↗

Regrouper les ressources Azure associées pour une gestion unifiée, un contrôle d'accès et une facturation.

→Placer toutes les ressources d'une application dans un seul Groupe de Ressources Azure.

Pourquoi: Les groupes de ressources sont des conteneurs de métadonnées. La suppression d'un groupe de ressources supprime toutes les ressources qu'il contient, ce qui en fait une limite critique de gestion du cycle de vie.

Sélectionner le service de calcul approprié pour une charge de travail.

→VMs (IaaS) pour un contrôle total. App Service (PaaS) pour les applications web/API. Azure Functions pour le code serverless événementiel. AKS pour l'orchestration de conteneurs. ACI pour les instances de conteneurs simples.

Pourquoi: Le choix dépend du compromis entre le contrôle, la surcharge de gestion et le modèle architectural (par exemple, monolithique, microservices, événementiel).

Exécuter une application de microservices conteneurisée complexe nécessitant une mise à l'échelle automatique, une découverte de services et des mises à jour continues.

→Utiliser Azure Kubernetes Service (AKS).

Pourquoi: AKS est l'offre Kubernetes gérée pour l'orchestration de conteneurs à grande échelle. Utiliser AKS plutôt qu'ACI lorsque vous avez besoin de gestion de cluster et d'interactions de services complexes.

Exécuter un conteneur unique et simple pour une tâche de courte durée (par exemple, un travail par lots) sans gestion de l'infrastructure.

→Utiliser Azure Container Instances (ACI).

Pourquoi: ACI est le moyen le plus rapide et le plus simple d'exécuter un conteneur dans Azure. Il est serverless et facturé à la seconde, idéal pour les tâches sans besoins d'orchestration.

Établir une connexion dédiée, privée et à haute bande passante depuis un centre de données sur site vers Azure.

→Utiliser Azure ExpressRoute.

Pourquoi: ExpressRoute ne traverse PAS l'internet public, offrant une plus grande fiabilité, sécurité et une latence plus faible qu'un VPN Gateway, qui utilise un tunnel sur internet.

Référence↗

Distribuer le trafic aux VMs backend en fonction de règles au niveau réseau versus au niveau application.

→Utiliser Azure Load Balancer pour la distribution de Couche 4 (TCP/UDP). Utiliser Azure Application Gateway pour les fonctionnalités de Couche 7 (HTTP/HTTPS) comme le déchargement SSL et le routage basé sur l'URL.

Pourquoi: Choisir Application Gateway lorsque vous devez prendre des décisions de routage basées sur les en-têtes HTTP, les chemins ou les noms d'hôte. Load Balancer est plus simple et plus rapide pour le trafic non-HTTP.

Acheminer le trafic web mondial vers le backend optimal, fournir la mise en cache CDN et protéger avec un WAF.

→Utiliser Azure Front Door.

Pourquoi: Front Door est un point d'entrée global qui fonctionne à la Couche 7 et combine l'équilibrage de charge global, le CDN, le WAF et la protection DDoS en un seul service.

Stocker d'énormes quantités de données non structurées comme des images, des vidéos, des sauvegardes et des fichiers journaux.

→Utiliser Azure Blob Storage.

Pourquoi: Le stockage Blob est hautement évolutif et rentable pour les données d'objets. Il est distinct d'Azure Files (pour les partages de fichiers SMB) et d'Azure Disk Storage (pour les disques de VM).

Minimiser les coûts de stockage des données en fonction de leur fréquence d'accès.

→Utiliser les niveaux d'accès de Blob Storage : Chaud (accès fréquent), Froid (accès peu fréquent), et Archive (accès rare, rétention à long terme).

Pourquoi: Le niveau Archive a le coût de stockage le plus bas mais le coût d'accès et la latence les plus élevés (heures pour se réhydrater). Utiliser des politiques de gestion du cycle de vie pour automatiser le classement par niveau.

Choisir une stratégie de réplication de données pour se protéger contre les pannes matérielles, de centres de données ou régionales.

→LRS (centre de données unique), ZRS (entre AZs dans une région), GRS (vers une région secondaire), GZRS (ZRS dans la région primaire + LRS dans la région secondaire).

Pourquoi: ZRS protège d'une panne de centre de données. GRS/GZRS protège d'une catastrophe régionale. Le compromis est un coût plus élevé pour une plus grande résilience.

Autoriser une VM dans un VNet à accéder à un service PaaS (comme Azure SQL ou Storage) sans que le trafic ne quitte le réseau Microsoft.

→Créer un Private Endpoint pour le service PaaS au sein du VNet de la VM.

Pourquoi: Un Private Endpoint attribue au service PaaS une adresse IP privée de votre VNet, garantissant que tout le trafic transite par le backbone privé de Microsoft, et non par l'internet public.

Migrer un serveur de fichiers Windows sur site vers un service cloud géré accessible via le protocole SMB.

→Utiliser Azure Files.

Pourquoi: Azure Files fournit des partages de fichiers entièrement gérés qui peuvent être montés par des VMs cloud ou sur site, agissant comme un remplacement direct pour les serveurs de fichiers traditionnels.

Appliquer la gouvernance (politiques, RBAC) et gérer l'accès sur de nombreuses abonnements Azure.

→Organiser les abonnements en une hiérarchie de Groupes de Gestion.

Pourquoi: Les groupes de gestion sont une portée au-dessus des abonnements. Les politiques et les attributions de rôles appliquées au niveau d'un groupe de gestion sont héritées par tous les abonnements qu'il contient.

Référence↗

Appliquer les normes organisationnelles, telles que la restriction des déploiements à des régions spécifiques ou l'exigence de balises sur toutes les ressources.

→Utiliser Azure Policy.

Pourquoi: La Policy applique des règles sur les configurations des ressources. C'est pour la gouvernance, tandis que le RBAC contrôle les permissions des utilisateurs (actions).

Distinguer entre le contrôle des actions des utilisateurs et le contrôle des propriétés des ressources.

→Utiliser le Contrôle d'Accès Basé sur les Rôles (RBAC) pour définir les actions qu'un utilisateur peut effectuer (par exemple, "Contributeur" peut créer des VMs). Utiliser Azure Policy pour définir les configurations autorisées (par exemple, "Les VMs ne peuvent être que de taille D-series").

Pourquoi: Le RBAC concerne "qui peut faire quoi". La Policy concerne "ce qui est autorisé". Ils fonctionnent ensemble pour une gouvernance complète.

Protéger une ressource de production critique contre la suppression accidentelle, même par les administrateurs.

→Appliquer un Verrou de Ressource `CanNotDelete` à la ressource ou à son groupe de ressources.

Pourquoi: Les verrous de ressources remplacent les permissions RBAC. Un propriétaire ne peut pas supprimer une ressource verrouillée tant que le verrou n'est pas explicitement supprimé. Un verrou `ReadOnly` empêche toute modification.

Organiser logiquement les ressources pour le suivi des coûts, l'automatisation ou l'identification de la propriété.

→Appliquer des Balises (paires clé-valeur) aux ressources.

Pourquoi: Les Balises sont des métadonnées utilisées pour filtrer et regrouper les ressources à travers les groupes de ressources, permettant une analyse et une gestion puissantes des coûts.

Une balise appliquée à un groupe de ressources n'apparaît pas sur les ressources qu'il contient.

→Les Balises ne sont pas automatiquement héritées des groupes de ressources. Chaque ressource doit être balisée explicitement.

Pourquoi: Pour faire respecter l'héritage des balises, utilisez une Azure Policy avec un effet "Modify" ou "DeployIfNotExists" pour ajouter des balises du groupe de ressources parent.

Estimer les coûts futurs d'Azure versus le calcul des économies réalisées grâce à une migration sur site.

→Utiliser le Calculateur de Prix pour estimer le coût de services Azure spécifiques. Utiliser le Calculateur de Coût Total de Possession (TCO) pour comparer les coûts sur site versus les coûts Azure.

Pourquoi: Le Calculateur de Prix est destiné aux déploiements "greenfield" ou à l'ajout de nouveaux services. Le Calculateur TCO est destiné à l'élaboration d'une analyse de rentabilisation pour la migration.

Suivre les dépenses Azure actuelles, définir des alertes de dépenses et trouver des opportunités d'économies.

→Utiliser Azure Cost Management. Créer des Budgets pour déclencher des alertes lorsque les seuils de dépenses sont atteints.

Pourquoi: Les Budgets fournissent une notification proactive des dépenses, aidant à prévenir les dépassements de coûts. L'analyse de Cost Management aide à identifier les anomalies et les tendances de dépenses.

Réduire les coûts pour les charges de travail prévisibles et continues comme les VMs ou les bases de données.

→Acheter des Instances Réservées Azure ou des Plans d'Économie pour une durée de 1 ou 3 ans.

Pourquoi: Les Réservations offrent des remises importantes (jusqu'à 72%) par rapport aux tarifs "paiement à l'utilisation" en échange d'un engagement à long terme. Idéal pour les charges de travail à état stable.

Déployer l'infrastructure Azure de manière répétable, cohérente et sous contrôle de version.

→Utiliser l'Infrastructure as Code (IaC) déclarative avec des Modèles ARM (JSON) ou Bicep.

Pourquoi: Bicep est un langage spécifique au domaine (DSL) plus simple et plus concis qui est transpilé en ARM JSON, offrant une meilleure expérience d'édition et une meilleure lisibilité.

Gérer et gouverner les serveurs exécutés sur site ou dans d'autres clouds à l'aide des outils Azure.

→Intégrer les serveurs non-Azure à Azure Arc.

Pourquoi: Azure Arc projette des ressources externes dans Azure Resource Manager, vous permettant d'utiliser Azure Policy, RBAC et la surveillance pour les actifs hybrides et multi-cloud à partir d'un seul plan de contrôle.

Référence↗

Fournir une solution unique de gestion des identités et des accès basée sur le cloud pour toutes les applications.

→Utiliser Microsoft Entra ID (anciennement Azure AD).

Pourquoi: Entra ID est le plan de contrôle d'identité, offrant l'authentification unique (SSO), l'authentification multifacteur (MFA) et l'accès conditionnel pour les applications cloud et sur site.

Exiger la MFA pour les utilisateurs se connectant depuis un réseau non fiable mais pas depuis le bureau de l'entreprise.

→Configurer une politique d'accès conditionnel Microsoft Entra.

Pourquoi: L'Accès Conditionnel agit comme un moteur de politique "si-alors". Si une condition d'utilisateur/emplacement/appareil est remplie, alors un contrôle d'accès (comme l'exigence de MFA) est appliqué.

Permettre à une ressource Azure (comme une VM ou un App Service) de s'authentifier auprès d'un autre service Azure (comme Key Vault) sans stocker de secrets dans le code.

→Attribuer une Identité Gérée à la ressource et lui accorder des permissions RBAC sur le service cible.

Pourquoi: Azure gère automatiquement le cycle de vie des informations d'identification, éliminant le risque de fuite de secrets des fichiers de configuration ou du code.

Stocker et gérer en toute sécurité les secrets d'application, les clés et les certificats.

→Utiliser Azure Key Vault.

Pourquoi: Key Vault fournit un référentiel centralisé, sécurisé par le matériel et audité pour les secrets, les empêchant d'être codés en dur dans les applications.

Évaluer continuellement la posture de sécurité des charges de travail cloud, obtenir un Score de Sécurité et recevoir une protection contre les menaces.

→Utiliser Microsoft Defender pour le Cloud.

Pourquoi: Defender pour le Cloud fournit la gestion de la posture de sécurité du cloud (CSPM) et la protection des charges de travail du cloud (CWP) dans les environnements Azure, hybrides et multi-cloud.

Filtrer le trafic réseau au niveau du sous-réseau/NIC versus de manière centralisée pour l'ensemble du VNet.

→Utiliser des Groupes de Sécurité Réseau (NSG) pour le filtrage de paquets avec état de Couche 3/4 de base. Utiliser Azure Firewall pour un pare-feu centralisé et entièrement avec état en tant que service avec filtrage de Couche 7 et renseignement sur les menaces.

Pourquoi: Les NSG sont simples et distribués. Azure Firewall offre des capacités avancées et une gestion centralisée des politiques, souvent utilisé dans une topologie hub-spoke.

Réduire la surface d'attaque des VMs en maintenant les ports de gestion (RDP/SSH) fermés par défaut.

→Activer l'accès Juste-À-Temps (JIT) aux VMs dans Microsoft Defender pour le Cloud.

Pourquoi: Le JIT accorde un accès temporaire aux ports de gestion à la demande pour une durée limitée, les fermant automatiquement par la suite. C'est plus sécurisé que de laisser les ports constamment ouverts.

Surveiller la santé de l'infrastructure Azure versus les performances du code d'application.

→Utiliser Azure Monitor pour les métriques et les journaux de plateforme. Utiliser Application Insights (une fonctionnalité d'Azure Monitor) pour la Gestion des Performances des Applications (APM).

Pourquoi: Azure Monitor collecte les données d'infrastructure (CPU, mémoire). Application Insights fournit des diagnostics approfondis au niveau du code (temps de réponse, dépendances, exceptions).

Recevoir des alertes personnalisées concernant les pannes de services Azure, la maintenance planifiée et les avis de santé.

→Utiliser Azure Service Health.

Pourquoi: Service Health est personnalisé pour vos abonnements, régions et services, contrairement à la page publique Azure Status. Il concerne les problèmes de plateforme Azure, et non la santé de vos propres ressources.

Recevoir des recommandations personnalisées et exploitables pour optimiser les ressources Azure.

→Examiner les recommandations d'Azure Advisor.

Pourquoi: Advisor analyse votre configuration et la télémétrie d'utilisation et fournit des recommandations selon cinq piliers : Fiabilité, Sécurité, Performance, Coût et Excellence Opérationnelle.

Établir une base standardisée, gouvernée et évolutive pour toutes les charges de travail Azure dans une entreprise.

→Mettre en œuvre une architecture Azure Landing Zone.

Pourquoi: Les Landing Zones fournissent un cadre prescriptif issu du Cloud Adoption Framework, incluant la structure des groupes de gestion, la mise en réseau, l'identité et les politiques de gouvernance, pour accélérer l'adoption du cloud en toute sécurité.