AWS ou Azure : comment choisir son cloud (et où se situe Google Cloud)

« AWS ou Azure ? » est l’une des premières questions posées lors d’un projet cloud, et souvent la plus mal posée. Les comparatifs qui alignent des centaines de services ne vous aident pas à décider : les deux plateformes savent héberger une application web, une base de données, un cluster Kubernetes ou un assistant d’IA. Ce qui fait la différence, c’est votre point de départ : vos outils, vos licences, vos équipes, vos données et vos contraintes réglementaires.

Cet article propose une grille de choix en huit critères, un tableau comparatif, et la place de Google Cloud dans cette décision. Chez Feekr, nous travaillons sur AWS comme sur Azure et nous n’avons pas de préférence commerciale : notre objectif est que le choix soit documenté et assumé. Pour une vue d’ensemble de nos sujets, voir notre page conseil cloud AWS et Azure.

AWS, Azure, Google Cloud : ce qui les distingue vraiment

Des fondations comparables

Les trois grands fournisseurs proposent le même socle : machines virtuelles, stockage objet et bloc, réseaux virtuels, bases de données managées, Kubernetes managé, fonctions serverless, outils de supervision, de sécurité et de gestion des coûts. Les noms changent (EC2, Azure Virtual Machines, Compute Engine ; EKS, AKS, GKE), les concepts restent très proches.

Les différences réelles sont ailleurs :

• L’écosystème. Azure est le prolongement naturel de l’environnement Microsoft : Entra ID, Microsoft 365, Windows Server, SQL Server, Power Platform.
• L’historique et la largeur du catalogue. AWS a ouvert le marché et propose un catalogue très large, avec un vivier important de compétences et de documentation.
• La donnée et l’analytique. Google Cloud est souvent retenu pour BigQuery et ses services de données, et pour son intégration avec les modèles Gemini.
• Le modèle d’organisation. AWS structure les environnements en comptes regroupés dans une organisation ; Azure en abonnements rangés sous des groupes d’administration, rattachés à un tenant Entra ID. Ces logiques influencent la façon de gérer les droits et la facturation.

Ce que disent les parts de marché (et ce qu’elles ne disent pas)

Selon Synergy Research Group, au deuxième trimestre 2026, Amazon détenait 28 % du marché mondial des services d’infrastructure cloud, Microsoft 20 % et Google 15 %. Ces chiffres confirment que les trois acteurs sont solides et durables. Ils ne disent rien de votre cas : un fournisseur plus gros n’est pas automatiquement plus adapté à une ETI dont les identités sont dans Entra ID, et un fournisseur plus petit n’est pas un risque s’il couvre vos besoins.

Et Google Cloud ?

Google Cloud dispose d’une région à Paris (europe-west9, trois zones) et d’un catalogue complet. Il mérite d’être étudié si la donnée et l’analytique sont au cœur de votre projet, si vos équipes utilisent déjà Google Workspace, ou si vous visez l’offre souveraine S3NS (voir plus bas). Dans la pratique, la majorité des entreprises que nous rencontrons arbitrent entre AWS et Azure : c’est pourquoi cet article se concentre sur ces deux plateformes, en signalant Google Cloud quand il change la donne.

La grille de choix en 8 critères

1. Votre écosystème Microsoft existant

C’est souvent le critère le plus structurant. Si votre entreprise utilise Microsoft 365, gère ses identités dans Entra ID et exploite un parc Windows Server et SQL Server, Azure offre une continuité réelle : mêmes outils d’administration, même support, mêmes contrats.

L’argument le plus concret est financier. Azure Hybrid Benefit permet de réutiliser vos licences SQL Server couvertes par la Software Assurance sur Azure SQL Database et SQL Managed Instance ; Microsoft annonce jusqu’à 30 % d’économies, voire plus, sur ces services. À l’inverse, depuis le 1er octobre 2022, les règles de licence Microsoft distinguent des « Listed Providers » (Alibaba, Amazon, Google et Microsoft) : l’avantage de virtualisation flexible introduit à cette date ne s’applique pas chez eux, et Microsoft oriente les clients vers l’achat de licences directement auprès du fournisseur. Les licences Windows Server et SQL Server se chiffrent donc différemment selon le cloud. Faites ce calcul avec votre contrat de licence sous les yeux, avant toute autre comparaison.

Un parc Microsoft n’impose pas pour autant Azure. Beaucoup d’entreprises gardent Microsoft 365 pour la bureautique et hébergent leurs applications sur AWS : c’est une combinaison courante et bien outillée.

2. L’identité : Entra ID n’oblige pas à choisir Azure

C’est une idée reçue fréquente. AWS IAM Identity Center prend en charge la fédération SAML 2.0 avec Microsoft Entra ID et le provisionnement automatique des utilisateurs et des groupes via SCIM 2.0. Vos collaborateurs se connectent à AWS avec leur compte Microsoft habituel, avec l’authentification multifacteur et l’accès conditionnel définis dans Entra ID, et les droits AWS sont attribués par groupe.

L’identité reste toutefois un chantier à part entière, quel que soit le cloud : séparation des comptes d’administration, accès d’urgence, comptes de service, cycle de vie des arrivées et départs. Notre fondateur a travaillé sur Azure à la refonte de l’identité d’un grand acteur du sport, avec Keycloak déployé sur Kubernetes : ce type de projet montre que l’architecture d’identité pèse souvent plus lourd que le choix du fournisseur.

3. Les compétences de vos équipes

Un cloud que personne ne sait exploiter coûte cher. Faites l’inventaire honnête des compétences internes : vos administrateurs viennent-ils du monde Windows et Active Directory, ou du monde Linux et open source ? Vos développeurs ont-ils déjà déployé sur l’une des deux plateformes ? Votre prestataire d’infogérance est-il à l’aise sur les deux ?

La montée en compétence est possible dans les deux sens, mais elle a un coût et une durée. Si vous choisissez la plateforme que vos équipes connaissent le moins, prévoyez la formation et un accompagnement dans le budget dès le départ. Décrire l’infrastructure en code (Terraform ou OpenTofu, utilisables sur AWS comme sur Azure) réduit aussi la dépendance aux clics dans une console et facilite le transfert de compétences.

4. Les services managés dont vous aurez besoin

Partez de votre architecture cible, pas du catalogue. Listez les briques indispensables (base PostgreSQL managée, Kubernetes, file de messages, stockage objet, CDN, annuaire, sauvegarde) et vérifiez pour chacune :

• sa disponibilité dans la région visée ;
• son niveau de maturité (disponibilité générale ou préversion) ;
• les compétences nécessaires pour l’exploiter ;
• son modèle de facturation.

Pour la plupart des besoins standard, les deux plateformes ont une réponse. Les écarts apparaissent sur des services précis : une base de données spécifique, un outil d’analytique, une intégration avec un logiciel métier. Ce sont ces écarts, identifiés sur votre propre liste, qui doivent peser dans la décision.

5. L’IA générative : Amazon Bedrock ou Microsoft Foundry

Il y a encore peu, la frontière était simple : les modèles d’OpenAI sur Azure, ceux d’Anthropic sur AWS. Ce n’est plus le cas.

• Amazon Bedrock est un service entièrement managé qui donne accès, selon AWS, à plus de 100 modèles de fondation, notamment d’Amazon (Nova), d’Anthropic (Claude), de DeepSeek, de Moonshot AI, de MiniMax, d’OpenAI et de xAI.
• Microsoft Foundry (anciennement Azure AI Foundry) regroupe agents, modèles et outils sous une même ressource Azure. Microsoft annonce plus de 10 000 modèles, de Microsoft, d’OpenAI, d’Anthropic, de Meta et d’autres. Les ressources Azure OpenAI existantes peuvent être converties en ressources Foundry.
• Côté Google, Vertex AI fait désormais partie de Gemini Enterprise Agent Platform, qui donne accès aux modèles Gemini et à des modèles partenaires comme Claude ou Mistral.

Le choix du modèle ne suffit donc plus à départager les plateformes. Regardez plutôt :

• La localisation des traitements. Sur Bedrock, l’inférence inter-régions peut être limitée à une zone géographique (par exemple l’UE) ou être globale ; AWS indique que le mode global coûte environ 10 % de moins mais peut traiter les requêtes dans n’importe quelle région commerciale. Sur Foundry, les déploiements « Data Zone » UE traitent les données dans la frontière de données de l’UE de Microsoft, tandis que les déploiements « Global » peuvent les traiter dans n’importe quelle région Azure. Pour des données sensibles, ce paramètre compte plus que le nom du modèle.
• La disponibilité réelle par région. Un modèle peut être disponible en mode global et pas encore dans une zone UE. Vérifiez la disponibilité exacte avant de concevoir l’architecture.
• L’intégration avec vos données. Si vos documents sont dans SharePoint et vos utilisateurs dans Microsoft 365, l’écosystème Microsoft simplifie certains cas d’usage. Si vos données applicatives sont déjà sur AWS, Bedrock évite des transferts inutiles.

Nous détaillons la mise en production de ces services dans notre approche de mise en production de l’IA.

6. Les régions en France et la conformité

Les trois fournisseurs ont des régions en France :

• AWS : Europe (Paris), eu-west-3, avec trois zones de disponibilité, activée par défaut.
• Azure : France Central (Paris), avec trois zones de disponibilité, et France South (Marseille), sa région appairée, dont l’accès est restreint à des scénarios spécifiques comme la reprise après sinistre.
• Google Cloud : europe-west9 (Paris), avec trois zones.

Pour les données de santé, l’hébergement doit être certifié HDS. AWS indique avoir obtenu la certification HDS version 2 le 21 avril 2026, avec des données au repos (sauvegardes comprises) devant résider dans une région de l’Espace économique européen, dont Paris. Microsoft indique un certificat HDS 2.0 délivré en octobre 2025, applicable aux services Azure listés conformes ISO/IEC 27001 et déployés notamment dans France Central et France South, avec des clauses contractuelles spécifiques à signer. Dans les deux cas, la certification du fournisseur ne couvre pas votre propre configuration : chiffrement, droits, journalisation et sauvegardes restent votre responsabilité. Notre fondateur conçoit et exploite des infrastructures AWS en Terraform, avec EKS, pour de l’hébergement de données de santé : c’est un sujet que nous connaissons de l’intérieur.

7. La souveraineté

Le mot recouvre des exigences très différentes. Il faut distinguer trois niveaux :

• La résidence des données : les données restent dans une région ou une zone géographique choisie. Les trois fournisseurs le permettent. Microsoft a achevé en février 2025 sa frontière de données de l’UE (EU Data Boundary), qui couvre Microsoft 365, Dynamics 365, Power Platform et la plupart des services Azure.
• L’exploitation européenne : AWS a ouvert le 15 janvier 2026 l’AWS European Sovereign Cloud, avec une première région dans le Brandebourg, en Allemagne. AWS la présente comme physiquement et logiquement séparée des autres régions et exploitée exclusivement par des résidents de l’UE. AWS précise qu’elle n’est pas encore dans le périmètre de sa certification HDS.
• La qualification SecNumCloud de l’ANSSI, exigée pour certaines données sensibles du secteur public. Elle passe par des offres opérées par des sociétés françaises : S3NS, filiale de Thales en partenariat avec Google Cloud, a annoncé en décembre 2025 la qualification de son offre PREMI3NS ; Bleu, coentreprise de Capgemini et Orange qui s’appuie sur les technologies Microsoft, n’était pas encore qualifiée en octobre 2026 et vise une qualification pour la fin de l’année.

Si SecNumCloud est une exigence ferme, la question n’est plus « AWS ou Azure » mais « quelle offre qualifiée, et quels services y sont réellement disponibles ». Ces statuts évoluent vite : vérifiez-les au moment de votre décision (informations vérifiées en octobre 2026).

8. Les coûts, les remises et les engagements

Comparer des prix catalogue service par service est rarement concluant : les écarts varient selon les services, les régions et les volumes. Ce qui pèse vraiment sur la facture :

• Les engagements. Chez AWS, les Savings Plans engagent sur une dépense horaire pendant un ou trois ans ; AWS annonce jusqu’à 72 % d’économies sur le calcul. Chez Azure, les savings plans fonctionnent sur le même principe (engagement horaire sur un ou trois ans), et les réservations offrent des remises plus fortes sur une ressource précise quand l’usage est stable.
• Les licences : Azure Hybrid Benefit d’un côté, règles des Listed Providers de l’autre (voir le critère 1).
• Les accords d’entreprise : remises négociées, crédits de migration, programmes partenaires. Ils dépendent de votre volume et de votre négociation, et ne se comparent qu’au cas par cas.
• Les coûts cachés : transferts de données sortants, passerelles NAT, journaux conservés trop longtemps, environnements hors production allumés en permanence.

Le meilleur indicateur n’est pas le fournisseur le moins cher sur le papier, mais celui dont vous saurez piloter la facture. C’est l’objet du FinOps, que nous détaillons dans notre article FinOps : définition et leviers sur AWS.

Tableau comparatif AWS, Azure, Google Cloud

Critère	AWS	Azure	Google Cloud
Point fort typique	Largeur du catalogue, vivier de compétences	Continuité avec l’écosystème Microsoft	Données et analytique, modèles Gemini
Organisation	Comptes dans AWS Organizations	Abonnements sous des groupes d’administration	Projets dans une organisation
Identité	IAM Identity Center, fédéré avec Entra ID si besoin	Entra ID natif	Cloud Identity, fédération possible
Kubernetes managé	Amazon EKS	AKS	GKE
IA générative	Amazon Bedrock	Microsoft Foundry	Gemini Enterprise Agent Platform
Région en France	Paris (3 zones)	France Central (3 zones), France South à accès restreint	Paris (3 zones)
HDS	Certification HDS v2 (avril 2026)	Certificat HDS 2.0 (octobre 2025)	Périmètre à vérifier auprès de Google
Souveraineté renforcée	AWS European Sovereign Cloud (Allemagne)	EU Data Boundary ; offre Bleu en cours de qualification SecNumCloud	Offre S3NS PREMI3NS qualifiée SecNumCloud
Engagements tarifaires	Savings Plans, Reserved Instances	Savings plans, réservations, Azure Hybrid Benefit	Remises sur engagement

Ce tableau résume des tendances et des faits vérifiés à la date de publication. Il ne remplace pas une étude sur votre propre liste de services.

Multicloud : une option, pas un objectif

Le multicloud est souvent présenté comme une protection contre la dépendance à un fournisseur. Dans les faits, exploiter sérieusement deux clouds double une partie du travail : deux modèles d’identité, deux réseaux, deux ensembles d’outils de sécurité, deux factures à piloter, et des compétences à entretenir des deux côtés.

Il se justifie dans des cas précis :

• un service propre à un fournisseur, indispensable à un projet ;
• une exigence réglementaire ou contractuelle ;
• une fusion ou une acquisition qui réunit deux environnements ;
• une stratégie de réversibilité assumée et financée.

Pour la réversibilité, deux éléments ont changé la donne. D’abord, les trois fournisseurs ont mis en place la gratuité des transferts de données sortants vers Internet pour les clients qui quittent leur plateforme, sous conditions (demande préalable au support, délai, périmètre), dans le sillage du règlement européen sur les données (Data Act). Ensuite, une infrastructure décrite en code (Terraform, OpenTofu) et des applications conteneurisées se déplacent beaucoup plus facilement qu’un environnement construit à la main. Pour la plupart des PME et ETI, un cloud principal bien maîtrisé, avec une réversibilité documentée, est un meilleur compromis qu’un multicloud subi. Notre accompagnement Kubernetes et Terraform vise justement cette portabilité.

Trois situations types

Pour rendre la grille concrète, voici trois profils fréquents. Ce sont des illustrations, pas des règles.

• Une ETI industrielle, 100 % Microsoft. Identités dans Entra ID, Microsoft 365, une trentaine de serveurs Windows et plusieurs bases SQL Server sous Software Assurance. Azure part avec une longueur d’avance grâce aux licences et à la continuité des outils. AWS reste envisageable, mais le calcul de licences doit être fait en premier.
• Un éditeur de logiciel SaaS. Stack Linux, conteneurs, équipe de développeurs habituée à l’open source. Les deux plateformes conviennent ; le choix se fera sur les compétences de l’équipe, les services managés visés et l’écosystème de clients (certains clients grands comptes imposent un fournisseur).
• Un acteur de santé. Données soumises à HDS, besoin d’IA pour exploiter des documents. AWS et Azure sont certifiés ; le choix se fera sur la localisation des traitements d’IA, l’existant applicatif et la capacité de l’équipe à sécuriser la configuration.

Comment Feekr vous aide à choisir

Nous intervenons sur les deux plateformes et n’avons aucun intérêt à vous orienter vers l’une plutôt que l’autre. Notre démarche est courte et factuelle :

1. Atelier de cadrage : objectifs, contraintes réglementaires, existant Microsoft, compétences internes, projets d’IA.
2. Inventaire et estimation : liste des services nécessaires, vérification de leur disponibilité dans les régions visées, projection de coûts avec les calculateurs officiels et vos licences.
3. Note de décision : un document court qui justifie le choix, liste les risques et prévoit la réversibilité.
4. Mise en œuvre si vous le souhaitez : landing zone décrite en code, identités, réseau, sécurité, puis migration.

Selon le résultat, nous vous accompagnons sur AWS ou sur Azure, pour la migration vers le cloud et pour la maîtrise des coûts. Si votre décision s’inscrit dans un projet de migration plus large, notre article sur la stratégie de migration vers le cloud et les 7R complète cette grille.

Prochaine étape

Si vous hésitez entre AWS et Azure, le plus efficace est de confronter la grille à votre situation réelle, avec vos licences, vos équipes et vos données. Nous pouvons mener cet exercice avec vous depuis Villeneuve-d’Ascq, en atelier sur site à Lille et dans la métropole ou à distance, et vous remettre une recommandation argumentée, quel que soit le fournisseur retenu.

[ VOS QUESTIONS ]

Questions fréquentes

AWS ou Azure : lequel choisir ?

Il n’y a pas de gagnant universel. Azure est souvent le choix naturel quand l’entreprise vit déjà dans l’écosystème Microsoft (Entra ID, Microsoft 365, Windows Server, SQL Server) et veut réutiliser ses licences. AWS est fréquemment retenu pour sa largeur de services, sa maturité sur les architectures cloud natives et le vivier de compétences. Le bon choix dépend de votre existant, de vos équipes, de vos contraintes de conformité et de vos projets d’IA.

Quelle est la différence entre AWS, Azure et Google Cloud ?

Les trois proposent du calcul, du stockage, des bases managées, Kubernetes, du serverless et des services d’IA. Les différences tiennent à l’écosystème (Microsoft pour Azure), à l’historique et à la largeur du catalogue (AWS), aux points forts sur la donnée et l’analytique (Google Cloud, avec BigQuery), et au positionnement de chacun sur l’IA générative. Selon Synergy Research Group, AWS reste le premier fournisseur mondial d’infrastructure cloud, devant Microsoft puis Google.

Azure est-il moins cher qu’AWS ?

Aucun des deux n’est moins cher par principe. Les prix varient par service, par région et selon les engagements (Savings Plans chez AWS, savings plans et réservations chez Azure). Pour un parc Windows Server ou SQL Server sous Software Assurance, Azure Hybrid Benefit peut peser lourd en faveur d’Azure. La seule comparaison fiable se fait sur votre inventaire réel, avec les calculateurs officiels des deux fournisseurs.

Peut-on utiliser Entra ID avec AWS ?

Oui. AWS IAM Identity Center prend en charge la fédération SAML 2.0 et le provisionnement automatique des utilisateurs et groupes depuis Microsoft Entra ID via SCIM 2.0. Vos collaborateurs se connectent à AWS avec leur compte Microsoft habituel, et les droits sont gérés par groupes.

Faut-il faire du multicloud ?

Pas par principe. Le multicloud double une partie des compétences, des outils de sécurité et de la gouvernance. Il se justifie quand un besoin précis l’impose : un service spécifique à un fournisseur, une exigence réglementaire, une acquisition, ou une stratégie de réversibilité assumée. Pour la plupart des PME et ETI, un cloud principal bien maîtrisé, décrit en code, est plus sûr.

Quel cloud choisir pour héberger des données de santé (HDS) ?

AWS et Microsoft Azure sont tous deux certifiés HDS. AWS indique avoir obtenu la version 2 du référentiel en avril 2026, avec des données au repos devant résider dans des régions de l’Espace économique européen comme Paris. Microsoft indique un certificat HDS 2.0 délivré en octobre 2025, couvrant notamment France Central et France South. Vérifiez le périmètre exact des services utilisés et signez les clauses contractuelles requises.

Sources

• Synergy Research Group : Q2 Cloud Market Passes $143 Billion (30 juillet 2026)
• AWS : AWS Regions (liste des régions et zones de disponibilité)
• Microsoft Learn : List of Azure regions
• Google Cloud : Regions and zones (Compute Engine)
• AWS : Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center
• Microsoft Learn : Azure Hybrid Benefit (Azure SQL Database et SQL Managed Instance)
• Microsoft Licensing : New options for partner hosted cloud (Listed Providers)
• AWS : What is Amazon Bedrock?
• AWS : Cross-Region inference (Amazon Bedrock)
• Microsoft Learn : What is Microsoft Foundry?
• Microsoft Learn : Deployment types in Microsoft Foundry Models
• Google Cloud : Gemini Enterprise Agent Platform release notes (changements de nom depuis Vertex AI)
• AWS : HDS (Hébergeur de Données de Santé)
• Microsoft Learn : Health Data Hosting (HDS) France
• Microsoft : Microsoft completes landmark EU Data Boundary (26 février 2025)
• Amazon : AWS launches AWS European Sovereign Cloud (15 janvier 2026)
• Next : SecNumCloud, Bleu vise désormais une qualification pour la fin d’année (octobre 2026)
• Business Wire : S3NS Announces SecNumCloud Qualification for PREMI3NS (décembre 2025)
• AWS : What are Savings Plans?
• Microsoft Learn : What are savings plans? (Azure)
• AWS News Blog : Free data transfer out to internet when moving out of AWS
• Microsoft Learn : Cancel your Azure subscription (free egress when leaving Azure)
• Google Cloud : Eliminating data transfer fees when migrating off Google Cloud