Aller au contenu principal

AWS : Free Tier, EC2 et IAM

· 15 minutes de lecture

Amazon Web Services (AWS) est l'une des principales plateformes cloud. Ses services fondamentaux, EC2 pour le calcul et IAM pour les identités et les permissions, permettent de déployer et gérer une infrastructure complète sans matériel physique. Cet article couvre la création d'un compte, le modèle de permissions IAM, puis le cycle de vie complet d'une instance EC2.

Créer un compte AWS Free Tier​

AWS détient la plus grande part du marché du cloud public (environ 30 % selon les estimations de Synergy Research). L'offre gratuite permet d'explorer la plateforme avec les mêmes services que ceux utilisés en production, sans engagement financier initial.

Structure du Free Tier​

L'offre gratuite a changé de modèle le 15 juillet 2025 :

  • Comptes créés depuis le 15 juillet 2025 : un plan Free fondé sur des crédits. Le compte reçoit 100 USD à l'inscription, et jusqu'à 100 USD supplémentaires en réalisant des activités guidées (lancer une instance EC2, créer un budget, etc.). Le plan gratuit dure 6 mois ou jusqu'à épuisement des crédits ; il faut ensuite passer au plan payant, faute de quoi le compte est fermé. Certains services coûteux ne sont pas accessibles pendant la période gratuite.
  • Comptes créés avant cette date : l'ancien modèle de 12 mois reste applicable, avec des quotas par service : 750 heures par mois d'instance t2.micro ou t3.micro selon la région (de quoi faire tourner une instance en continu), 30 Go de stockage EBS, 5 Go de stockage S3, 750 heures de db.t3.micro (ou db.t2.micro) sur RDS.

Dans les deux cas, des offres toujours gratuites subsistent dans certaines limites : 1 million de requêtes Lambda par mois, 25 Go de stockage DynamoDB, 10 métriques personnalisées et 10 alarmes CloudWatch, et 100 Go de transfert de données sortant vers Internet par mois (agrégés sur tous les services).

Les montants et limites évoluent régulièrement : la page officielle aws.amazon.com/free fait foi.

Inscription et accès​

L'inscription se fait via aws.amazon.com/fr/free. Les étapes clés : informations du compte (email, nom, mot de passe), vérification d'identité par carte bancaire (une autorisation temporaire, sans débit), validation par SMS ou appel, et choix du plan de support Basic, gratuit.

La console est ensuite accessible sur console.aws.amazon.com.

La première mesure consiste à mettre en place des garde-fous contre les dépassements. AWS Budgets envoie des alertes lorsque les dépenses réelles ou prévues dépassent un seuil. Le modèle Zero spend budget déclenche une alerte dès que la dépense dépasse 0,01 USD, c'est-à-dire dès qu'une ressource sort du périmètre gratuit. Une alerte n'arrête cependant aucune ressource : elle signale le dépassement, la correction reste manuelle ou doit être automatisée (actions de budget).

Comprendre le modèle IAM​

Identity and Access Management (IAM) est le service AWS responsable de l'authentification et des autorisations. Chaque appel à l'API AWS, qu'il provienne de la console, de la CLI ou d'un SDK, est évalué par IAM : sa compréhension conditionne la sécurité de toute l'architecture.

Accès à la console IAM : console.aws.amazon.com/iam

Modèle d'autorisation​

Par défaut, tout accès est refusé (implicit deny). Une action n'est possible que si une policy l'autorise explicitement. Chaque utilisateur, service ou ressource doit donc disposer des seules permissions nécessaires à son fonctionnement (principe du moindre privilège).

Les quatre concepts clés d'IAM sont :

Users : identités permanentes représentant une personne ou une application, avec des identifiants de longue durée (mot de passe pour la console, clés d'accès pour l'API). L'utilisateur root, créé avec le compte, dispose de tous les droits sans restriction possible par une policy IAM.

Groups : ensembles d'utilisateurs partageant les mêmes permissions. Les policies s'attachent au groupe plutôt qu'à chaque utilisateur.

Roles : identités sans identifiants permanents, destinées à être assumées par un service AWS (une instance EC2, une fonction Lambda), un utilisateur ou une identité externe (fédération OIDC, par exemple un workflow GitHub Actions). L'appel sts:AssumeRole renvoie des identifiants temporaires, valables de 15 minutes à 12 heures.

Policies : documents JSON qui listent des actions autorisées (Allow) ou refusées (Deny) sur des ressources, éventuellement sous conditions. Une policy s'attache à un user, un group ou un role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyOnOneBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    },
    {
      "Sid": "DenyOutsideParis",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": "eu-west-3" }
      }
    }
  ]
}

L'évaluation suit un ordre fixe : un Deny explicite l'emporte toujours, puis un Allow explicite autorise l'action, et en l'absence de l'un comme de l'autre, le refus implicite s'applique. Dans l'exemple ci-dessus, la lecture du bucket est autorisée, sauf si la requête vise une autre région que Paris : le Deny prime alors sur l'Allow.

Sécurisation initiale du compte​

Les règles de base : ne plus utiliser le compte root après la création du compte, activer l'authentification multifacteur (MFA) sur root et sur chaque identité humaine, attribuer les permissions via des groupes ou des rôles, et auditer régulièrement les accès (IAM Access Analyzer, rapport d'identifiants).

Pour un projet personnel, une identité d'administration distincte du root suffit au quotidien ; le root reste réservé aux opérations qui l'exigent (récupération de compte, certains paramètres de facturation, fermeture du compte). AWS recommande désormais IAM Identity Center pour les accès humains : la connexion passe par un portail et la CLI obtient des identifiants temporaires (aws sso login), ce qui évite de stocker des clés d'accès permanentes sur un poste de travail. L'article AWS CLI détaille ces modes d'authentification.

Lancer une instance EC2​

Le lancement d'une instance EC2 depuis la console suit un formulaire en plusieurs sections. Chacune correspond à un paramètre dont dépend le démarrage et l'accessibilité de la machine virtuelle.

Nommage et identification​

Le nom d'une instance est en réalité une étiquette (tag) de clé Name. En production, avec des dizaines ou des centaines d'instances, une convention de nommage cohérente (par exemple projet-env-role-numero) et des tags complémentaires (Environment, Owner, Project) facilitent la gestion, l'automatisation et la ventilation des coûts.

Sélection de l'Amazon Machine Image (AMI)​

Une AMI est un modèle contenant un système d'exploitation et, éventuellement, des logiciels préinstallés. La console propose des AMI de démarrage rapide : Amazon Linux, Ubuntu, Debian, Red Hat, SUSE, Windows Server. Amazon Linux est maintenu par AWS et optimisé pour EC2 ; Ubuntu et Debian offrent l'écosystème de paquets de leur distribution.

Amazon Linux 2023 (AL2023) est la version actuelle d'Amazon Linux : Amazon Linux 2 arrive en fin de support le 30 juin 2026. AL2023 utilise dnf comme gestionnaire de paquets (la commande yum reste disponible comme alias).

Configuration du type d'instance​

Le type d'instance détermine les ressources matérielles : vCPU, mémoire, bande passante réseau. Son nom encode la famille (t pour burstable, m pour usage général, c pour calcul, r pour mémoire), la génération et la taille : t3.micro désigne la taille micro de la troisième génération de la famille t.

Les instances t fonctionnent avec des crédits CPU : elles disposent d'une performance de base (10 % d'un vCPU pour un t3.micro) et accumulent des crédits lorsqu'elles restent en dessous, qu'elles consomment lors des pics. Selon la région, t2.micro ou t3.micro est éligible à l'offre gratuite ; les instances t3 sont configurées par défaut en mode unlimited, qui facture le dépassement une fois les crédits épuisés.

Paire de clés SSH​

Une paire de clés se compose d'une clé publique, injectée dans ~/.ssh/authorized_keys de l'utilisateur par défaut au premier démarrage, et d'une clé privée conservée sur le poste client. AWS génère des clés RSA ou ED25519, ou importe une clé publique existante.

Lorsque la paire est générée par AWS, la clé privée n'est téléchargeable qu'une seule fois. Sa perte rend impossible la connexion SSH par cette clé ; l'accès reste possible par EC2 Instance Connect ou AWS Systems Manager Session Manager s'ils sont configurés, ou en détachant le volume racine pour y déposer une nouvelle clé publique. La clé privée se range dans ~/.ssh/ sous Linux et macOS, ou C:\Users\<nom>\.ssh\ sous Windows, avec un nom explicite (par exemple aws-key-2026).

Configuration réseau (VPC et sous-réseau)​

Chaque région d'un compte AWS dispose d'un VPC (Virtual Private Cloud) par défaut, avec un sous-réseau public par zone de disponibilité. Une instance lancée dans ces sous-réseaux reçoit automatiquement une adresse IPv4 publique, ce qui la rend joignable depuis Internet.

Depuis février 2024, chaque adresse IPv4 publique est facturée (0,005 USD par heure, soit environ 3,6 USD par mois), qu'elle soit attachée ou non ; l'ancienne offre gratuite de 12 mois incluait 750 heures d'IPv4 publique par mois. L'adresse publique automatique change à chaque arrêt/démarrage de l'instance : une adresse fixe nécessite une Elastic IP.

Les paramètres par défaut conviennent à un test. En production, la segmentation en sous-réseaux publics et privés, décrite dans l'article VPC, devient nécessaire.

Pare-feu (Security Group)​

Un Security Group est un pare-feu réseau (couches 3 et 4 : protocole, port, adresse source) appliqué à l'interface réseau de l'instance. Il est stateful : une connexion autorisée en entrée voit automatiquement ses paquets de réponse autorisés en sortie, sans règle supplémentaire. Il ne contient que des règles d'autorisation ; tout ce qui n'est pas explicitement autorisé en entrée est bloqué.

La connexion SSH requiert une règle entrante sur le port TCP 22. L'option My IP de la console restreint la source à l'adresse publique du poste courant ; une source 0.0.0.0/0 expose le port SSH aux scans automatisés permanents d'Internet. Session Manager permet même de se passer de tout port entrant.

Stockage (EBS)​

Un volume EBS (Elastic Block Store) est un disque réseau attaché à l'instance. Le volume racine contient le système d'exploitation ; son type par défaut est gp3 (SSD à usage général). Pour une instance de test, 8 à 20 Go suffisent. Le chiffrement EBS, transparent pour l'instance et sans impact notable sur les performances, peut être activé par défaut pour tout le compte dans les paramètres EC2 de la région.

Vérification et lancement​

Le récapitulatif permet de vérifier la paire de clés et les règles du Security Group avant le lancement. L'instance passe ensuite de l'état pending à running en quelques secondes ; son adresse IPv4 publique apparaît dans les détails de l'instance.

Le même lancement s'effectue en une commande avec la CLI :

# AMI AL2023 la plus récente, résolue via un paramètre public SSM
aws ec2 run-instances \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --instance-type t3.micro \
  --key-name aws-key-2026 \
  --security-group-ids sg-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=test-instance}]'

Se connecter en SSH​

Préparation de la clé privée​

La clé privée téléchargée doit être lisible uniquement par son propriétaire, sans quoi le client OpenSSH refuse de l'utiliser (UNPROTECTED PRIVATE KEY FILE) :

chmod 400 ~/.ssh/aws-key-2026.pem

Commande SSH​

L'utilisateur par défaut dépend de l'AMI :

ssh -i ~/.ssh/aws-key-2026.pem ec2-user@<ip-publique>

Connexion et vérification​

À la première connexion, le client SSH affiche l'empreinte de la clé hôte du serveur et demande confirmation (yes) avant de l'enregistrer dans ~/.ssh/known_hosts. Cette empreinte peut être comparée à celle affichée dans la sortie console de l'instance (Get system log) pour exclure une interception.

Accès root et administration​

L'utilisateur par défaut (ec2-user, ubuntu, admin) dispose de sudo sans mot de passe :

sudo dnf update

Fermeture de la connexion​

exit ou Ctrl+D ferme la session SSH. L'instance continue de tourner, et d'être facturée, jusqu'à son arrêt explicite.

Installer Nginx​

Nginx permet de vérifier de bout en bout qu'une instance est joignable depuis Internet.

Installation​

Mise à jour des paquets puis installation :

sudo dnf update -y
sudo dnf install -y nginx

Démarrage du service​

# Démarrer immédiatement et activer au démarrage de l'instance
sudo systemctl enable --now nginx

# Vérifier l'état : "active (running)" attendu
sudo systemctl status nginx

Sur Ubuntu et Debian, le paquet démarre et active le service automatiquement ; sur Amazon Linux, l'activation est manuelle.

Configuration du Security Group​

Le Security Group créé au lancement n'autorise que SSH : l'adresse IP publique ne répond pas en HTTP tant qu'aucune règle n'autorise le port 80. Dans EC2 → Security Groups, sélectionner le Security Group de l'instance, puis Edit inbound rules, et ajouter la règle :

  • Type : HTTP
  • Port : 80
  • Protocol : TCP
  • Source : 0.0.0.0/0

Équivalent en CLI :

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

Accès au serveur web​

Depuis un navigateur :

http://<ip-publique>

La page de bienvenue de Nginx confirme que le serveur est opérationnel. Elle est servie depuis /usr/share/nginx/html/index.html sur Amazon Linux, et depuis /var/www/html/ sur Ubuntu et Debian.

Vérification locale​

Depuis la session SSH :

# Sockets en écoute et processus associés (netstat n'est plus installé par défaut)
sudo ss -tlnp | grep nginx

# Requête locale, sans passer par le Security Group
curl -I http://localhost

Si la requête locale réussit mais que l'accès externe échoue, le blocage se situe au niveau réseau (Security Group, ACL réseau, table de routage) et non dans Nginx : le Security Group filtre le trafic avant qu'il n'atteigne l'instance.

Gérer l'instance​

Le cycle de vie d'une instance EC2 détermine ce qui est facturé. La différence entre Stop et Terminate conditionne à la fois les coûts et la conservation des données.

États d'une instance​

  • Running : l'instance s'exécute ; le calcul est facturé à la seconde (minimum 60 secondes) pour Linux.
  • Stopped : l'instance est arrêtée mais conserve ses volumes EBS et peut être redémarrée. Le calcul n'est plus facturé ; le stockage EBS et les Elastic IP restent facturés.
  • Terminated : l'instance est supprimée définitivement. Les volumes marqués Delete on Termination (le volume racine par défaut) sont supprimés avec elle ; les autres volumes EBS subsistent et restent facturés.

Stop vs Terminate​

Stop : l'équivalent d'un arrêt de machine. Les données du volume racine EBS sont conservées ; le stockage reste facturé (quelques centimes par Go et par mois). Au redémarrage, l'instance peut être placée sur un autre hôte physique et reçoit une nouvelle adresse IPv4 publique, sauf Elastic IP.

# Arrêter une instance
aws ec2 stop-instances --instance-ids i-0123456789abcdef0

# La redémarrer
aws ec2 start-instances --instance-ids i-0123456789abcdef0

Terminate : suppression définitive. Les données du volume racine sont perdues, sauf si Delete on Termination a été désactivé. La facturation du calcul et du stockage racine s'arrête immédiatement.

# Supprimer définitivement une instance
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

La protection contre la suppression (termination protection, attribut DisableApiTermination) empêche une suppression accidentelle tant qu'elle n'est pas levée.

Facturation dans l'offre gratuite​

Avec l'ancien modèle de 12 mois (750 heures de t2.micro/t3.micro par mois) :

  • Running : consomme les heures gratuites
  • Stopped : ne consomme pas d'heures, mais le stockage EBS au-delà des 30 Go gratuits est facturé (environ 0,08 à 0,10 USD par Go et par mois selon la région pour gp3)
  • Terminated : plus aucun frais pour l'instance et son volume racine

Avec le plan Free à crédits, toutes ces consommations sont déduites des crédits.

Une instance de test d'une journée se supprime (Terminate) après usage ; une instance réutilisée régulièrement s'arrête (Stop) entre deux sessions.

Actions dans la console​

Arrêter (Stop) : EC2 → Instances → sélectionner l'instance → Instance State → Stop. L'état passe à stopped en quelques secondes.

Redémarrer (Start) : sélectionner l'instance en état stopped → Instance State → Start. Les données du volume EBS sont intactes.

Supprimer (Terminate) : sélectionner l'instance → Instance State → Terminate, puis confirmer. L'opération est irréversible ; l'instance reste visible environ une heure à l'état terminated.

Impact sur les données​

  • Volume EBS racine : supprimé avec l'instance par défaut ; le comportement se modifie au lancement ou ensuite via l'attribut DeleteOnTermination.
  • Volumes EBS supplémentaires : conservés indépendamment de l'instance par défaut, et facturés séparément.
  • Stockage d'instance (instance store) : disques physiquement attachés à l'hôte, présents sur certains types d'instances ; leur contenu est perdu à l'arrêt ou à la suppression.

Les données à conserver indépendamment de l'instance se placent sur S3 ou sur un volume EBS dédié, ou se protègent par des snapshots EBS. Ces options de stockage sont détaillées dans l'article stockage AWS.

Synthèse​

Pour un usage d'apprentissage :

  • supprimer (Terminate) les instances de test après usage, pour éviter les frais EBS et IPv4 ;
  • arrêter (Stop) les instances réutilisées régulièrement ;
  • configurer un budget avec alertes pour détecter les dépassements ;
  • taguer les instances (Environment=test, Owner=...) pour identifier celles qui peuvent être arrêtées.
0%