Skip to main content

AWS : Free Tier, EC2 et IAM

· 13 min read

Amazon Web Services (AWS) est l'une des premières plateformes cloud au monde. Ses services fondamentaux comme EC2 et IAM permettent de déployer et gérer une infrastructure complète sans matériel physique.

Créer un compte AWS Free Tier​

AWS reste le leader incontesté du marché du cloud avec une part de marché significative. Pour un ingénieur ou un développeur souhaitant maîtriser les technologies cloud, l'accès à une plateforme de qualité production est essentiel. L'offre Free Tier permet d'explorer AWS à coût zéro pendant une période initiale, ce qui en fait un point de départ idéal.

Structure et avantages du Free Tier​

AWS propose plusieurs niveaux d'offres gratuits adaptés à différents usages. Le forfait principal offre un crédit de 200 USD valable pendant 12 mois pour explorer les services. Ce crédit couvre une majorité des cas d'usage basiques :

  • EC2 : 750 heures de t2.micro par mois (suffisant pour une instance 24/7)
  • S3 : 5 GB de stockage
  • RDS : 750 heures de db.t2.micro par mois
  • CloudWatch : Monitoring gratuit
  • Transferts de données : Jusqu'à 1 GB d'entrée/sortie gratuit par mois

Certains services restent gratuits indéfiniment, même après les 12 mois, à condition de rester dans les limites d'utilisation. Par exemple, AWS Lambda propose 1 million de requêtes gratuites par mois, DynamoDB offre 25 Go de stockage.

Les avantages principaux sont : aucun risque financier (aucune charge si les limites gratuites ne sont pas dépassées), accès complet à plus de 150 services AWS, durée suffisante pour apprendre (12 mois), et services identiques à ceux utilisés en production.

Inscription et accès​

L'inscription se fait via https://aws.amazon.com/fr/free/. Les étapes clés incluent : entrée des informations personnelles (email, nom, mot de passe), vérification de l'identité (AWS demande une carte bancaire pour vérification uniquement, pas de charge), validation par SMS, et sélection du plan de support gratuit (Basic Support).

Une fois inscrit, l'accès à la console se fait sur https://console.aws.amazon.com.

Il est crucial de mettre en place des garde-fous pour éviter les dépassements. AWS Budgets permet de définir des alertes automatiques qui vous notifient avant toute charge inattendue. Le template "Zero spend budget" est recommandé pour débuter : il crée une alerte dès que l'utilisation risque de dépasser le Free Tier. Ces pratiques de surveillance des coûts forment de bonnes habitudes pour la gestion en production.

Comprendre le modèle IAM​

Identity and Access Management (IAM) est le service AWS responsable de la gestion des accès et des permissions. C'est un composant critique de la sécurité infrastrukturelle qui doit être compris dès le départ, tant il influence toute l'architecture en production.

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

Modèle de sécurité basé sur les permissions​

AWS fonctionne selon un principe de permission explicite : par défaut, tout accès est refusé. Seules les actions explicitement autorisées sont possibles. Cette approche sécuritaire signifie que chaque utilisateur, chaque service, chaque ressource doit disposer des permissions minimales nécessaires à son fonctionnement.

Les quatre concepts clés d'IAM sont :

Users : Entités représentant des personnes ou des applications. Chaque utilisateur possède des identifiants uniques et des credentials de connexion. Un root user est créé automatiquement lors de la création du compte, mais il est recommandé de ne pas l'utiliser en production.

Groups : Ensemble logique d'utilisateurs partageant les mêmes permissions. Plutôt que d'assigner des permissions à chaque utilisateur individuellement, les groupes permettent une gestion centralisée et scalable.

Roles : Identités destinées à être assumées temporairement, généralement par des services ou des utilisateurs externes. Contrairement aux users, les roles n'ont pas de credentials permanentes mais génèrent des tokens temporaires.

Policies : Documents JSON définissant précisément les actions autorisées (Allow) ou refusées (Deny) sur les ressources AWS. Une policy peut être attachée à des users, groups, ou roles pour définir leurs permissions.

Bonnes pratiques dès le départ​

Appliquer les bonnes pratiques dès le début forme de solides habitudes. Ne jamais utiliser le root user après la création initiale du compte, créer un utilisateur IAM administrateur avec authentification multifacteur (MFA), utiliser des groupes pour simplifier la gestion des permissions, et régulièrement auditer les accès sont les règles de base.

Pour un projet personnel, créer au minimum un utilisateur IAM avec permissions complètes et l'utiliser comme administrateur du compte libère le root user, qui ne devrait être utilisé que pour les changements critiques (récupération de compte, modifications de facturation).

Lancer une instance EC2​

Le lancement d'une instance EC2 est un processus guidé composé de plusieurs étapes. L'objectif est de configurer tous les paramètres nécessaires pour que la machine virtuelle démarre correctement et soit accessible.

Nommage et identification​

Chaque instance doit recevoir un nom permettant de l'identifier facilement dans la console. Ce nom est en réalité une étiquette (tag) avec la clé "Name". Pour un projet de test, un simple "Test Instance" suffit. Ce nommage devient critique en production où vous aurez potentiellement des dizaines ou centaines d'instances : une politique de nommage cohérente (par exemple projet-env-role-numero) facilite la gestion et l'automatisation.

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

Une AMI est un modèle prêt à l'emploi contenant un système d'exploitation complet et un ensemble de logiciels préconfigurés. AWS propose plusieurs AMI de démarrage rapide gratuites : Amazon Linux, Ubuntu, Debian, CentOS. Le choix dépend de votre préférence et de votre expérience. Amazon Linux est optimisé pour AWS, Ubuntu offre une large communauté de développeurs, Debian est minimaliste.

Pour débuter, choisissez simplement Amazon Linux 2 ou Ubuntu. Ces AMI sont disponibles dans le Free Tier.

Configuration du type d'instance​

Le type d'instance détermine les ressources matérielles : processeur, mémoire, réseau. AWS propose plusieurs familles (t2, t3, m5, etc.). Le type t3.micro est inclus dans le Free Tier (750 heures par mois) et convient parfaitement pour apprendre, tester une application, ou servir une charge très légère.

Ne modifiez pas le type par défaut proposé pour une première instance. Vous pouvez toujours le changer plus tard.

Paire de clés SSH​

Avant de lancer l'instance, vous devez créer ou sélectionner une paire de clés SSH. La paire de clés se compose d'une clé publique (stockée sur l'instance) et d'une clé privée (conservée sur votre ordinateur local). La clé privée est votre secret : ne la partagez jamais.

AWS vous permet de télécharger la clé privée une seule fois lors de la création. Si vous la perdez, vous ne pourrez plus accéder à l'instance. Stockez-la dans un endroit sûr, comme ~/.ssh/ sur Linux/Mac ou C:\Users\VotreNom\.ssh\ sur Windows.

Nommez votre paire de clés de manière explicite (ex: aws-key-2026) pour éviter confusion avec d'autres clés.

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

AWS crée automatiquement un VPC (Virtual Private Cloud) par défaut pour votre compte. Les instances doivent être lancées dans ce VPC, idéalement dans un sous-réseau public pour un accès Internet. Le sous-réseau par défaut est public et attribue une adresse IP publique à votre instance, ce qui la rend accessible depuis Internet.

Pour un test, gardez les paramètres par défaut. En production, une segmentation réseau appropriée devient critique pour la sécurité.

Pare-feu (Security Group)​

Un Security Group fonctionne comme un pare-feu applicatif. Il définit les règles de trafic entrant et sortant pour votre instance. Pour vous connecter en SSH, vous avez besoin d'une règle permettant le trafic sur le port 22 (SSH).

Pour débuter, autorisez SSH de n'importe où (0.0.0.0/0). En production, limitez toujours SSH aux adresses IP connues.

Stockage (EBS)​

Un volume EBS (Elastic Block Store) est le disque de votre instance. Le volume racine contient le système d'exploitation. Pour une instance de test, un volume de 8-20 GB suffit, sans chiffrement supplémentaire nécessaire.

Vérification et lancement​

Passez en revue le résumé de tous les paramètres. Vérifiez que vous avez sélectionné la paire de clés correcte et que le Security Group autorise SSH. Une fois satisfait, cliquez sur "Lancer l'instance".

L'instance démarre en quelques secondes. Vous pouvez suivre son état dans la console : elle passe de "Pending" à "Running". Notez son adresse IP publique (affichée dans les détails de l'instance) : vous en aurez besoin pour la connexion SSH.

Se connecter en SSH​

Une fois l'instance en état "Running" avec une adresse IP publique, vous pouvez établir une connexion SSH sécurisée depuis votre terminal local.

Préparation de la clé privée​

La clé privée téléchargée lors du lancement doit être protégée avec les permissions appropriées. Sur Linux/Mac, exécutez :

chmod 400 ~/.ssh/votre-cle.pem

Cette commande restreint l'accès à la clé : seul le propriétaire peut la lire. SSH refusera de fonctionner si la clé a des permissions trop larges.

Commande SSH​

La syntaxe SSH dépend du système d'exploitation de l'AMI utilisée :

ssh -i ~/.ssh/votre-cle.pem ec2-user@adresse-ip-publique

Remplacez votre-cle.pem par le chemin réel de votre clé et adresse-ip-publique par l'IP publique de votre instance.

Connexion et vérification​

La première connexion SSH vous affiche généralement une empreinte digitale de la clé hôte (host key fingerprint) pour vérifier que vous vous connectez au bon serveur. Acceptez-la en tapant "yes".

Une fois connecté, vous êtes en tant qu'utilisateur ec2-user, ubuntu, ou admin (selon l'AMI). Vous avez un accès utilisateur à l'instance. Pour les opérations d'administration (installation de logiciels, modifications système), utilisez sudo.

Accès root et administration​

L'utilisateur par défaut (ec2-user, ubuntu, admin) dispose de sudo sans mot de passe. Vous pouvez donc exécuter des commandes en root simplement en préfixant avec sudo :

sudo yum update

Fermeture de la connexion​

Tapez exit ou appuyez sur Ctrl+D pour fermer la connexion SSH. Votre instance reste active à moins que vous ne l'arrêtiez explicitement.

Installer Nginx​

Nginx est un serveur web léger et performant, idéal pour débuter avec une application web simple. L'installation est directe via le gestionnaire de paquets de votre système d'exploitation.

Installation​

Une fois connecté en SSH à votre instance, commencez par mettre à jour les paquets système :

sudo yum update -y

Installez ensuite Nginx :

sudo yum install nginx -y

Démarrage du service​

Après installation, démarrez le service Nginx :

sudo systemctl start nginx

Vérifiez que le service est bien actif :

sudo systemctl status nginx

Vous devez voir un statut "active (running)".

Pour que Nginx démarre automatiquement au redémarrage de l'instance :

sudo systemctl enable nginx

Configuration du Security Group​

Pour que Nginx soit accessible depuis Internet, vous devez autoriser le trafic HTTP (port 80) dans le Security Group de votre instance. C'est une étape critique souvent oubliée, qui explique pourquoi l'adresse IP publique ne charge pas initialement.

Dans la console AWS, allez à EC2 → Security Groups, sélectionnez le Security Group de votre instance, puis cliquez sur Edit inbound rules. Ajoutez une nouvelle règle :

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

Sauvegardez les modifications.

Accès au serveur web​

Récupérez l'adresse IP publique de votre instance (visible dans les détails EC2), puis accédez-y via HTTP dans votre navigateur :

http://votre-ip-publique

Vous devez voir la page de bienvenue Nginx, confirmant que le serveur est opérationnel. Cette page est servie depuis /usr/share/nginx/html/index.html.

Vérification locale​

Depuis la session SSH, vous pouvez aussi vérifier que Nginx écoute correctement :

sudo netstat -tlnp | grep nginx

ou

curl http://localhost

Ces commandes confirment que Nginx est bien configuré et accessible localement. L'absence de règle HTTP dans le Security Group était le blocage : même si Nginx tourne, le pare-feu AWS bloque l'accès externe sans cette règle explicite.

Gérer l'instance​

Le cycle de vie d'une instance EC2 comprend plusieurs états critiques pour la gestion des coûts et des ressources. Comprendre la différence entre "Stop" et "Terminate" est essentiel pour éviter des frais inattendus.

États d'une instance​

Une instance EC2 peut se trouver dans plusieurs états :

  • Running : L'instance est en cours d'exécution et vous facturation pour le calcul (CPU, mémoire)
  • Stopped : L'instance est arrêtée mais conserve ses données et peux être redémarrée. Vous êtes facturé pour le stockage EBS uniquement
  • Terminated : L'instance est supprimée définitivement. Les données sont perdues (sauf si à sauvegardé les volumes EBS). Pas de frais (ou frais minimaux pour EBS selon la configuration)

Stop vs Terminate​

Stop (Arrêt) : Comme éteindre un ordinateur à la maison. L'instance s'arrête mais subsiste. Vous pouvez la redémarrer plus tard. Les données sur le volume racine (EBS) sont conservées. Vous êtes facturé pour le stockage EBS (quelques centimes par mois) mais pas pour le calcul.

# Depuis la console AWS : clic-droit sur l'instance → Instance State → Stop

Terminate (Suppression) : Suppression définitive de l'instance. Les données du volume racine sont perdues par défaut (sauf si vous avez configuré "Delete on Termination = No"). Vous cessez immédiatement d'être facturé pour le calcul et le stockage racine.

# Depuis la console AWS : clic-droit sur l'instance → Instance State → Terminate

Facturation dans le Free Tier​

Dans le Free Tier (750 heures par mois de t3.micro gratuit) :

  • Running : Consomme vos 750 heures gratuites
  • Stopped : Ne consomme pas les heures gratuites, mais facturé pour EBS (~$0.10 par Go/mois)
  • Terminated : Pas de frais

Pour une instance de test à court terme (une journée d'apprentissage), il est judicieux de Terminate pour éviter les frais EBS. Pour une instance que vous revisiterez plus tard, Stop pour la conserver à bas coût.

Commandes via la console​

Arrêter (Stop) l'instance :

  1. Allez à EC2 → Instances
  2. Sélectionnez votre instance
  3. Clic-droit → Instance State → Stop
  4. Confirmez l'arrêt
  5. L'état change à "Stopped" en quelques secondes

Redémarrer (Start) l'instance :

  1. Allez à EC2 → Instances
  2. Sélectionnez votre instance (état "Stopped")
  3. Clic-droit → Instance State → Start
  4. L'instance redémarre, les données persistent

Supprimer (Terminate) l'instance :

  1. Allez à EC2 → Instances
  2. Sélectionnez votre instance
  3. Clic-droit → Instance State → Terminate
  4. Confirmez la suppression (attention : irréversible)
  5. L'instance disparaît après quelques secondes

Impact sur les données​

Le comportement des données dépend du type de stockage :

  • Volume EBS racine : Par défaut configuré à être supprimé avec l'instance. On peut le modifier lors du lancement pour le conserver.
  • Volumes EBS supplémentaires : Conservés indépendamment de l'instance, facturable séparément.
  • Stockage local de l'instance (ephemeral) : Perdu lors de l'arrêt ou la suppression.

Pour conserver des données importantes sans l'instance, transférez-les vers S3 (stockage objet) ou sur un volume EBS séparé.

Bonnes pratiques​

Pour débuter avec le Free Tier :

  • Terminate les instances de test après usage pour éviter les frais EBS
  • Stop les instances que vous réutiliserez régulièrement
  • Configurez des alarmes de coûts pour détecter les dépassements accidentels
  • Taguez clairement les instances ("Test", "Production", etc.) pour savoir lesquelles arrêter

Une fois familiarisé avec les bases, arrêter votre instance actuelle vous évitera des frais inattendus sur votre Free Tier.

0%