Aller au contenu
English
English
Cloud medium

Découvrir Amazon Web Services (AWS)

10 min de lecture

aws log

Amazon Web Services (AWS) est le premier fournisseur de cloud public par part de marché, devant Azure et Google Cloud. Lancé en 2006, il propose aujourd'hui plus de 200 services couvrant le calcul, le stockage, les bases de données, le réseau, l'IA et bien plus. Cette page situe ses services clés, son organisation en régions et zones de disponibilité, le rôle d'IAM, et les premiers pas avec l'AWS CLI.

AWS est né d'un besoin interne d'Amazon : industrialiser sa propre infrastructure. En 2006, deux services fondateurs ouvrent au public, S3 (stockage d'objets) et EC2 (machines virtuelles à la demande). Le catalogue s'est ensuite élargi à un rythme soutenu pour atteindre plus de 200 services.

Le modèle est le paiement à l'usage (pay-as-you-go) : on ne paie que les ressources consommées, sans investissement matériel. Pour un administrateur, l'intérêt est double : la mise à l'échelle quasi instantanée (ajouter ou retirer de la capacité selon la charge) et la suppression de la maintenance physique. La contrepartie, à surveiller dès le départ, est la maîtrise des coûts et le verrouillage fournisseur quand l'architecture repose sur des services propriétaires.

AWS reste le leader du marché, avec la plus grande largeur de catalogue et la plus grande profondeur de retours d'expérience, ce qui en fait souvent le choix par défaut en entreprise.

Quelques briques reviennent dans presque toute architecture AWS. Les voici, avec leur rôle.

ServiceRôle
EC2 (Elastic Compute Cloud)machines virtuelles à la demande
S3 (Simple Storage Service)stockage d'objets durable et scalable
RDS (Relational Database Service)bases relationnelles managées (MySQL, PostgreSQL...)
Lambdaexécution de code serverless, sans serveur à gérer
VPC (Virtual Private Cloud)réseau privé isolé (régional)
EKS (Elastic Kubernetes Service)Kubernetes managé
IAM (Identity and Access Management)identités et permissions
CloudFormationInfrastructure as Code native
CloudWatchmétriques, logs et alarmes
Route 53DNS et routage

Trois familles structurent la plupart des projets : EC2 + S3 + RDS pour héberger une application classique (calcul, fichiers, base), Lambda + API Gateway pour une approche serverless, et EKS pour des charges conteneurisées.

La largeur du catalogue. Avec plus de 200 services, AWS couvre des besoins très spécialisés (IoT, machine learning, calcul haute performance, migration) que les concurrents n'adressent pas toujours. Cette exhaustivité est son principal atout, et aussi sa principale complexité.

La maturité et l'écosystème. Antériorité de 2006 oblige, AWS dispose de la plus grande communauté, de la documentation la plus fournie et d'un vaste réseau de partenaires et de profils formés. Pour la plupart des problèmes, une solution existe et a déjà été documentée.

L'intégration entre services. EC2 sauvegarde vers S3, RDS s'expose dans un VPC, Lambda réagit à un événement S3, CloudWatch surveille le tout : les briques sont conçues pour se combiner, et IAM gouverne finement qui peut faire quoi sur chacune.

À l'inverse de Google Cloud, où le réseau VPC est global, le VPC d'AWS est régional : une architecture multi-régions impose de connecter explicitement les réseaux entre eux.

Aucun fournisseur n'est « meilleur » dans l'absolu ; le choix dépend du contexte.

  • AWS : le leader du marché, la plus grande largeur de catalogue et la maturité la plus établie. Le choix par défaut quand on veut le maximum de services et de retours d'expérience.
  • Azure : deuxième, fort sur l'intégration Microsoft (Active Directory, Windows, Microsoft 365), naturel pour les organisations déjà dans cet écosystème.
  • Google Cloud : troisième, différenciants sur la donnée (BigQuery), l'IA/ML et Kubernetes (GKE).

En pratique, le choix se décide sur les compétences en place, l'écosystème existant et la nature des charges. La largeur et la maturité penchent vers AWS, une stack Microsoft vers Azure, l'analytique et l'IA vers GCP.

AWS répartit ses ressources dans des régions (zones géographiques, comme eu-west-3 à Paris), elles-mêmes découpées en zones de disponibilité (Availability Zones, ou AZ) : des data centers isolés, mais reliés par un réseau à faible latence au sein d'une région.

Ce découpage gouverne des décisions d'architecture concrètes :

  • La haute disponibilité : pour résister à la panne d'un data center, on répartit ses instances sur plusieurs AZ d'une même région ; pour résister à la perte d'une région, sur plusieurs régions.
  • La latence : choisir une région proche des utilisateurs réduit le temps de réponse.
  • La conformité et le prix : la région détermine où résident les données (un enjeu réglementaire) et les tarifs, qui varient d'une région à l'autre.

C'est un arbitrage à poser dès le début d'un projet, car déplacer des ressources entre régions n'a rien d'automatique.

Tout AWS se pilote en ligne de commande avec l'AWS CLI, ce qui rend les opérations reproductibles et scriptables, là où la console web reste manuelle. La première décision n'est pas la commande à taper, c'est le type d'identifiant que vous allez utiliser.

Pour un humain, la documentation AWS porte un avertissement explicite : n'utilisez pas d'utilisateur IAM pour vous authentifier quand vous manipulez de vraies données, et préférez la fédération avec un fournisseur d'identité, IAM Identity Center en premier lieu. La raison tient en une phrase : une clé d'accès longue durée ne s'expire pas toute seule, et elle finit dans un historique Git ou un fichier de configuration oublié.

Fenêtre de terminal
aws configure sso # profil adossé à IAM Identity Center
aws sso login --profile mon-profil
aws sts get-caller-identity # vérifier l'identité active
aws s3 ls # lister ses buckets S3

La commande aws configure, qui saisit une clé d'accès et un secret, garde sa place pour une automatisation qui ne peut pas se fédérer, avec un utilisateur IAM dédié au moindre privilège et une rotation des clés. Sur une machine AWS, un rôle attaché à l'instance vaut mieux encore : il n'y a aucun secret à stocker.

Le service IAM est central : il définit les utilisateurs, les rôles et les politiques (qui peut faire quoi). Le principe directeur est le moindre privilège : n'accordez que les permissions strictement nécessaires, et n'utilisez jamais le compte racine au quotidien. C'est la première mesure de sécurité d'un compte AWS.

Pour découvrir sans frais, AWS propose un niveau gratuit, dont le modèle a changé en juillet 2025. Un nouveau compte reçoit désormais des crédits à dépenser et un plan gratuit limité dans le temps, là où l'ancien modèle offrait douze mois d'essai sur certains services. Des offres toujours gratuites, plafonnées, subsistent en parallèle. Comme ces conditions évoluent, vérifiez-les sur la page officielle du niveau gratuit avant de bâtir un plan de formation dessus, et posez une alerte de budget dès la création du compte.

  • AWS est le leader du cloud, avec plus de 200 services depuis 2006.
  • Les briques essentielles : EC2 (calcul), S3 (stockage), RDS (bases), Lambda (serverless), VPC (réseau), IAM (permissions).
  • Atouts : largeur du catalogue, maturité, écosystème ; vigilance sur les coûts et le lock-in.
  • L'infrastructure se code avec CloudFormation et se pilote avec l'AWS CLI (reproductibilité).
  • Architecture : répartir sur plusieurs zones de disponibilité pour la haute disponibilité ; le VPC est régional (contrairement à GCP).
  • Sécurité : IAM au moindre privilège, ne jamais utiliser le compte racine au quotidien.

Ces réponses couvrent les questions les plus posées sur AWS : sa définition, son positionnement face à Azure et Google Cloud, son coût et son niveau gratuit, les premiers pas avec l'AWS CLI et le rôle d'IAM.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens ce site gratuitement, sans publicité, sans profilage et sans compte à créer. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn