Services AWS essentiels : IAM, VPC, EC2, S3, RDS, Lambda et ce qui les relie

Amazon Web Services publie bien plus de deux cents services, et pourtant un système de production typique en utilise peut-être une quinzaine — toujours à peu près les mêmes. Ce guide en fait le tour : à quoi sert chacun, quelles décisions vous prenez en le configurant, et comment il s'emboîte avec ses voisins. Il suppose que vous avez lu le guide sur les fondamentaux du cloud et que vous savez ce que sont une région, une zone de disponibilité et le modèle de responsabilité partagée. Les noms de services sont les noms officiels actuels ; lorsqu'AWS a récemment renommé un service, l'ancien nom est mentionné une fois.

Comptes, organisations et IAM

Tout, dans AWS, vit à l'intérieur d'un compte, qui est à la fois une frontière de facturation et une frontière de sécurité étanche. Les entreprises fonctionnent rarement avec un seul compte : AWS Organizations permet de créer de nombreux comptes sous un compte de gestion, de les regrouper en unités organisationnelles et d'appliquer des service control policies (SCP) qui plafonnent ce que toute identité de ces comptes a le droit de faire — par exemple interdire la création de ressources hors des régions approuvées. Des comptes distincts pour la production, l'hors-production, l'outillage de sécurité et l'archivage des logs constituent le socle standard.

À l'intérieur d'un compte, AWS Identity and Access Management (IAM) décide qui peut appeler quelle API sur quelle ressource. Le vocabulaire :

• Les principals sont les identités : utilisateurs IAM (longue durée, avec mot de passe ou clés d'accès), rôles IAM (endossés temporairement, sans identifiants permanents) et identités fédérées issues d'un fournisseur externe via IAM Identity Center ou SAML/OIDC.
• Les politiques sont des documents JSON qui autorisent ou refusent des actions sur des ressources, éventuellement sous conditions. Les politiques basées sur l'identité s'attachent aux principals ; les politiques basées sur les ressources s'attachent à la ressource elle-même (un bucket S3, une file, une clé KMS).
• Les rôles sont les bêtes de somme. Un rôle possède une trust policy qui dit qui peut l'endosser, et des politiques de permissions qui disent ce que celui qui l'endosse peut faire. Instances EC2, fonctions Lambda, tâches ECS et pods Kubernetes obtiennent tous leurs permissions en étant associés à un rôle ; la plateforme injecte des identifiants de courte durée renouvelés automatiquement.

La logique d'évaluation s'énonce simplement et mérite d'être apprise par cœur : tout est refusé par défaut ; un Allow explicite dans une politique applicable accorde l'accès ; un Deny explicite, où qu'il soit, l'emporte sur tous les Allow ; les SCP et les permission boundaries fixent un plafond extérieur que les politiques d'identité ne peuvent pas dépasser.

Voici une politique de moindre privilège pour un service qui lit des objets sous un préfixe de bucket et écrit dans une file :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadInvoices",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-billing-prod/invoices/*"
    },
    {
      "Sid": "ListInvoicePrefixOnly",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::acme-billing-prod",
      "Condition": { "StringLike": { "s3:prefix": ["invoices/*"] } }
    },
    {
      "Sid": "EnqueueWork",
      "Effect": "Allow",
      "Action": ["sqs:SendMessage"],
      "Resource": "arn:aws:sqs:eu-west-1:123456789012:invoice-processing"
    }
  ]
}

Chaque ressource est identifiée par un Amazon Resource Name (ARN) de la forme arn:partition:service:region:account-id:resource. Les services globaux comme S3 et IAM laissent le champ de région vide. Les jokers dans le champ Resource sont à l'origine de la plupart des politiques trop permissives : "Resource": "*" combiné à "Action": "s3:*" donne au principal tous les buckets du compte.

Réseau : le VPC

Un Amazon Virtual Private Cloud (VPC) est un réseau logiquement isolé dans une région, avec une plage CIDR IPv4 de votre choix (et, en option, de l'IPv6). À l'intérieur, vous créez des sous-réseaux, chacun rattaché à une zone de disponibilité. Un sous-réseau est public si sa table de routage envoie 0.0.0.0/0 vers une internet gateway ; sinon, il est privé. Cette distinction relève entièrement du routage — il n'existe aucun autre indicateur.

Une topologie classique pour une application trois tiers sur trois zones :

VPC 10.20.0.0/16 (eu-west-1)
├── public-a  10.20.0.0/24   ALB nodes, NAT gateway      → route 0.0.0.0/0 → internet gateway
├── public-b  10.20.1.0/24   ALB nodes, NAT gateway
├── public-c  10.20.2.0/24   ALB nodes, NAT gateway
├── app-a     10.20.10.0/24  EC2 / ECS tasks             → route 0.0.0.0/0 → NAT gateway (same AZ)
├── app-b     10.20.11.0/24
├── app-c     10.20.12.0/24
├── data-a    10.20.20.0/24  RDS primary                 → no default route at all
├── data-b    10.20.21.0/24  RDS standby
└── data-c    10.20.22.0/24

Les instances applicatives sont placées dans des sous-réseaux privés et sortent vers Internet via une NAT gateway située dans un sous-réseau public. Déployez une NAT gateway par zone : une passerelle unique partagée crée une dépendance inter-zones et des frais de transfert de données entre zones. Les sous-réseaux de bases de données n'ont aucune route vers Internet.

Le contrôle du trafic repose sur deux couches. Les security groups sont des pare-feu stateful attachés aux interfaces réseau, et leur meilleur atout est qu'une règle peut référencer un autre security group : « autoriser le 5432 depuis le security group du tier applicatif » survit au remplacement des instances, ce qui n'est pas le cas des règles fondées sur les IP. Les network ACL sont des listes stateless au niveau du sous-réseau ; laissez-les à leur valeur par défaut permissive, sauf besoin de blocage précis.

Deux autres briques apparaissent dans presque tous les VPC réels. Les VPC endpoints permettent aux sous-réseaux privés d'atteindre des services AWS comme S3, DynamoDB, Secrets Manager et ECR sans passer par Internet ni par une NAT gateway. Le VPC peering ou, à grande échelle, AWS Transit Gateway relie les VPC entre eux et aux réseaux on-premise via AWS Site-to-Site VPN ou AWS Direct Connect.

Calcul : EC2, conteneurs et Lambda

Amazon Elastic Compute Cloud (EC2) fournit des machines virtuelles. Les choix qui comptent au lancement sont l'Amazon Machine Image (AMI), le modèle de disque de démarrage ; le type d'instance, dont la lettre de famille indique la vocation (usage général, optimisé calcul, mémoire ou stockage, accéléré) et dont la taille fixe les vCPU et la mémoire ; le sous-réseau et les security groups ; l'instance profile IAM qui porte son rôle ; et les user data, un script exécuté au premier démarrage. Les instances ont un cycle de vie (pending, running, stopping, stopped, terminated) et, point important, le disque instance store de certains types disparaît à l'arrêt, alors que les volumes EBS persistent.

Les options d'achat changent la facture sans changer la machine : On-Demand pour la souplesse, Savings Plans ou Reserved Instances pour des remises contre engagement sur les charges stables, et Spot Instances — de la capacité excédentaire qu'AWS peut récupérer avec un préavis de deux minutes — pour les traitements batch interruptibles et les charges stateless.

Un Auto Scaling group maintient un nombre souhaité d'instances à partir d'un launch template, remplace les instances défaillantes, les répartit sur les sous-réseaux que vous indiquez et ajuste leur nombre selon des politiques de scaling (le target tracking sur le CPU ou le nombre de requêtes est le point de départ habituel). Devant lui, Elastic Load Balancing propose un Application Load Balancer pour HTTP/HTTPS avec routage par chemin et par hôte, un Network Load Balancer pour TCP/UDP à très haut débit avec IP statiques, et un Gateway Load Balancer pour les appliances virtuelles.

# Launch one instance in a private subnet with a role and a startup script
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.small \
  --subnet-id subnet-0a1b2c3d \
  --security-group-ids sg-0f1e2d3c \
  --iam-instance-profile Name=order-service-profile \
  --user-data file://bootstrap.sh \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=service,Value=orders},{Key=env,Value=prod}]'

Les conteneurs disposent de deux orchestrateurs. Amazon Elastic Container Service (ECS) est l'ordonnanceur maison d'AWS, plus simple à exploiter, avec AWS Fargate comme mode de lancement serverless qui supprime toute gestion d'hôtes. Amazon Elastic Kubernetes Service (EKS) fait tourner Kubernetes upstream pour les équipes qui recherchent la portabilité ou maîtrisent déjà Kubernetes ; le guide des fondamentaux de Kubernetes détaille le modèle d'orchestration lui-même. Tous deux récupèrent leurs images dans Amazon Elastic Container Registry (ECR).

AWS Lambda exécute une fonction en réaction à un événement — une requête HTTP via API Gateway ou une function URL, un nouvel objet S3, un message dans une file, une planification — sans aucune instance à gérer. Vous choisissez un runtime (Java, Python, Node.js, .NET, Go, et des runtimes personnalisés via des conteneurs), une taille mémoire qui détermine aussi la part de CPU, et un timeout dont la limite haute se compte en minutes. Lambda convient aux charges événementielles, en rafales ou de type « glue » ; les processus de longue durée, les charges qui exigent des connexions persistantes et tout ce qui est sensible à la latence des cold starts tournent mieux sur des conteneurs.

Stockage : EBS, EFS et S3

Amazon Elastic Block Store (EBS) fournit des volumes en mode bloc qui s'attachent à une instance EC2 de la même zone de disponibilité — le disque d'une machine virtuelle. Les types de volumes arbitrent entre coût, débit et IOPS ; le SSD à usage général (gp3) est le choix par défaut, le SSD à IOPS provisionnées (io2) existe pour les bases de données exigeantes. Les snapshots sont des copies incrémentales stockées dans S3 ; c'est ainsi qu'on sauvegarde et qu'on clone des volumes. Comme un volume est lié à sa zone, une instance d'une autre zone ne peut pas le monter ; cette contrainte suffit à écarter EBS comme stockage partagé.

Amazon Elastic File System (EFS) est un système de fichiers NFS managé, montable simultanément depuis de nombreuses instances réparties sur plusieurs zones, pour les charges qui ont réellement besoin d'un système de fichiers POSIX partagé, comme les CMS ou les applications migrées en lift-and-shift qui écrivent dans un répertoire commun.

Amazon Simple Storage Service (S3) est du stockage objet : les buckets contiennent des objets adressés par clé, accessibles en HTTPS, sans sémantique de système de fichiers et avec une capacité pratiquement illimitée. C'est l'emplacement par défaut des sauvegardes, des logs, des sites statiques, des fichiers de data lake, des médias et de tout ce qui s'écrit une fois pour être lu un grand nombre de fois. Les fonctionnalités à connaître dès le premier jour :

• Les classes de stockage (Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant/Flexible/Deep Archive) arbitrent la vitesse de récupération et le coût par requête contre le coût de stockage ; les lifecycle rules déplacent les objets d'une classe à l'autre et les font expirer.
• Le versioning conserve chaque écrasement et chaque suppression : c'est votre protection contre les suppressions accidentelles et les écrasements façon ransomware.
• Block Public Access au niveau du compte doit rester activé, sauf si vous servez délibérément un site public.
• Le chiffrement côté serveur est activé par défaut ; vous pouvez choisir une clé gérée par AWS ou votre propre clé dans AWS Key Management Service (KMS).
• Les URL pré-signées donnent un accès limité dans le temps à un objet précis sans rendre le bucket public.

aws s3api put-bucket-versioning --bucket acme-billing-prod \
  --versioning-configuration Status=Enabled
aws s3 cp ./reports/2026-09.pdf s3://acme-billing-prod/reports/2026-09.pdf \
  --storage-class STANDARD_IA

Bases de données : RDS, Aurora et DynamoDB

Amazon Relational Database Service (RDS) exécute des instances managées de PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server et Db2. AWS se charge du provisionnement, des correctifs pendant une fenêtre de maintenance, des sauvegardes automatiques avec restauration à un instant donné et — lorsque Multi-AZ est activé — d'une instance de secours répliquée de façon synchrone dans une autre zone, avec basculement automatique. Les read replicas sont des copies asynchrones destinées à absorber les lectures ; elles ne remplacent pas le Multi-AZ. Le schéma, les requêtes, les index et le parameter group restent sous votre responsabilité.

Amazon Aurora est le moteur relationnel maison d'AWS, compatible au niveau du protocole avec PostgreSQL et MySQL, avec un stockage répliqué en six exemplaires sur trois zones et un basculement qui se compte en secondes. Les variantes Aurora Serverless ajustent la capacité à la charge. Choisissez Aurora quand vous voulez l'ergonomie de RDS avec une meilleure disponibilité et une montée en charge des lectures, sans être lié à un autre moteur.

Amazon DynamoDB est une base clé-valeur et document entièrement managée, avec une latence constante de quelques millisecondes à n'importe quelle échelle. Les tables ont une clé de partition (et éventuellement une clé de tri), et vous interrogez par ces clés ou via des index secondaires conçus à l'avance. La capacité est à la demande ou provisionnée ; il n'y a ni serveur, ni correctifs, ni pool de connexions à dimensionner. Le prix de cette simplicité : les modèles d'accès doivent être connus et modélisés dès le départ.

Amazon ElastiCache (Redis ou Valkey, et Memcached) couvre le cache et le stockage de sessions ; Amazon OpenSearch Service couvre la recherche plein texte et l'analyse de logs.

Messaging et intégration

Découpler les composants avec des files et des événements, c'est ainsi que les architectures AWS absorbent les pics et isolent les pannes.

Amazon Simple Queue Service (SQS) est une file de messages. Les files standard offrent une livraison at-least-once avec un ordre best-effort et un débit quasi illimité ; les files FIFO garantissent l'ordre et un traitement exactly-once au sein d'un message group, pour un débit moindre. Un consommateur reçoit un message, le traite puis le supprime ; s'il ne le supprime pas avant l'expiration du visibility timeout, le message réapparaît, et après un nombre de tentatives configuré, il atterrit dans une dead-letter queue.

Amazon Simple Notification Service (SNS) fait du publish/subscribe : un topic diffuse un message à de nombreux abonnés — files SQS, fonctions Lambda, endpoints HTTPS, e-mail, SMS. Le fan-out SNS vers SQS est le pattern standard quand plusieurs services ont besoin du même événement.

Amazon EventBridge est un bus d'événements doté de règles fondées sur le contenu, qui routent les événements des services AWS, de vos applications et de partenaires SaaS vers des cibles, ainsi qu'un planificateur. Il remplace l'ancien CloudWatch Events. Pour orchestrer des workflows en plusieurs étapes avec reprises et branchements, AWS Step Functions fournit une machine à états.

Edge, DNS et observabilité

Amazon Route 53 est un DNS avec health checks et politiques de routage (pondéré, par latence, failover, géolocalisation) qui font du DNS un outil d'aiguillage du trafic. Amazon CloudFront est le CDN : il met en cache dans des edge locations, termine le TLS avec des certificats d'AWS Certificate Manager et se place devant des buckets S3, des load balancers ou n'importe quelle origine HTTP. AWS WAF s'attache à CloudFront ou à un ALB pour filtrer les requêtes.

Amazon CloudWatch collecte métriques, logs et alarmes. Chaque service émet des métriques automatiquement ; vos applications envoient leurs logs via l'agent CloudWatch ou le runtime Lambda ; les alarmes se déclenchent sur des seuils et peuvent actionner l'Auto Scaling ou des notifications SNS. AWS CloudTrail enregistre chaque appel d'API dans le compte — qui a fait quoi, d'où et quand — et constitue votre piste d'audit ; activez-le dans toutes les régions et livrez-le dans un bucket verrouillé du compte d'archivage des logs. AWS X-Ray ajoute le tracing distribué.

La configuration et les secrets ont aussi leur place : AWS Systems Manager Parameter Store pour les valeurs de configuration et AWS Secrets Manager pour les identifiants, avec rotation automatique. Les lire au démarrage grâce au rôle de l'instance, c'est ce qui remplace, côté cloud native, les fichiers de propriétés contenant des mots de passe — une pratique que le guide des twelve-factor apps approfondit.

Assembler le tout avec CloudFormation

AWS CloudFormation décrit les ressources dans des templates YAML ou JSON et les crée, les met à jour ou les supprime sous forme de stack. C'est l'option d'infrastructure as code native ; Terraform et l'AWS CDK sont des alternatives courantes, que le guide de l'infrastructure as code compare. Voici une stack minimale avec une file, sa dead-letter queue et un rôle qu'un service pourrait endosser :

AWSTemplateFormatVersion: "2010-09-09"
Description: Invoice processing queue and worker role

Resources:
  InvoiceDlq:
    Type: AWS::SQS::Queue
    Properties:
      MessageRetentionPeriod: 1209600          # 14 days, the maximum

  InvoiceQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 120                    # longer than the worst-case processing time
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt InvoiceDlq.Arn
        maxReceiveCount: 5

  WorkerRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal: { Service: ecs-tasks.amazonaws.com }   # only ECS tasks may assume it
            Action: sts:AssumeRole
      Policies:
        - PolicyName: consume-invoices
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action: [sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes]
                Resource: !GetAtt InvoiceQueue.Arn

Outputs:
  QueueUrl:
    Value: !Ref InvoiceQueue

Erreurs fréquentes

Des clés d'accès dans le code ou dans les variables de CI. Utilisez des rôles sur le calcul et la fédération OIDC depuis les systèmes de CI comme GitHub Actions ; si une clé doit exister, restreignez sa portée et mettez en place sa rotation.

Une seule NAT gateway, dans une seule zone. Quand cette zone tombe, tous les sous-réseaux privés perdent l'accès à Internet. Déployez-en une par zone et routez chaque sous-réseau privé vers la passerelle de sa zone.

Prendre les read replicas pour de la haute disponibilité. Un read replica est asynchrone et sa promotion est manuelle, sauf si vous l'automatisez. La fonctionnalité de disponibilité, c'est le Multi-AZ ; les read replicas servent à absorber les lectures.

Des buckets S3 publics par accident. Gardez Block Public Access activé au niveau du compte et servez le contenu public via CloudFront avec un origin access control.

Négliger CloudTrail et les tags de répartition des coûts. Sans CloudTrail, impossible de répondre à « qui a supprimé ça ? », et sans un schéma de tags cohérent service/env/owner, impossible de répondre à « qui paie pour ça ? ». Les deux coûtent peu à mettre en place dès le premier jour et sont pénibles à rattraper après coup.

Points clés à retenir

• Les comptes sont la frontière de sécurité et de facturation ; les charges de travail obtiennent leurs permissions via des rôles IAM à identifiants de courte durée, et les politiques refusent tout par défaut.
• Un VPC est votre réseau privé : les sous-réseaux publics routent vers une internet gateway, les privés passent par des NAT gateways par zone ou par des VPC endpoints, et les security groups se référencent entre eux plutôt que par IP.
• EC2 donne le contrôle total, ECS/EKS fait tourner des conteneurs, Lambda exécute des fonctions événementielles ; choisissez selon le niveau de contrôle requis et le profil d'utilisation, pas selon la mode.
• EBS est un disque lié à une zone, EFS un système de fichiers partagé, S3 le stockage objet durable avec versioning, lifecycle rules et Block Public Access.
• RDS et Aurora couvrent les besoins relationnels avec basculement Multi-AZ ; DynamoDB couvre l'accès par clé à n'importe quelle échelle quand les modèles d'accès sont connus à l'avance.
• SQS, SNS et EventBridge découplent les composants ; CloudWatch, CloudTrail et X-Ray vous disent ce qui se passe ; CloudFormation rend le tout reproductible.