DevOps Elastic Hayway
Document

SUBSCRIBE TO GET FULL ACCESS TO THE E-BOOKS FOR FREE 🎁SUBSCRIBE NOW

Professional Dropdown with Icon

SUBSCRIBE NOW TO GET FREE ACCESS TO EBOOKS

AWSLesson 3 / 4710 min readUpdated September 13, 2026

Meta description : AWS Fundamentals hands-on : IAM (rôles et moindre privilège), VPC/subnets, Launch Templates EC2 et S3 versionné. Tutoriel CLI v2 FR, région ca-central-1 — base SAA 2026.

À la fin de ce tutoriel, vous aurez une base opérationnelle AWS : identité (IAM / rôles), réseau (VPC multi-AZ), compute (Launch Template + EC2) et stockage objet (S3 versionné), le tout en AWS CLI v2 avec sorties attendues — sans écraser les pages sœurs du menu.

Niveau : Débutant · Temps estimé : 50–65 min · Versions testées : AWS Management Console (2026), AWS CLI v2, Ubuntu 24.04 LTS · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : aws-fundamentals · Série : AWS Solutions Architect · Remplace / fusionne : #990 (hub menu AWS Fundamentals) · Pages sœurs (ne pas supprimer) : aws-cloud-computing, aws-history-2, aws-sign-up, demarrer-avec-aws

← Précédent : AWS Cloud Computing · → Suivant : AWS History · Hub compte : Démarrer avec AWS

Statut : HOLD — draft only (ne pas publier sur WordPress)

Prérequis

  • [ ] Compte AWS de lab déjà créé et root sécurisé (MFA) — voir Démarrer avec AWS
  • [ ] Profil CLI nommé lab avec droits admin de lab (jamais le root)
  • [ ] Machine locale ou VM Ubuntu 24.04 LTS avec AWS CLI v2 installé
  • [ ] Notions cloud (IaaS / Region / AZ) — AWS Cloud Computing
  • [ ] Budget + alerte à 1–5 USD activés

Coût estimé : quelques cents si vous laissez une EC2 t3.micro tourner ; supprimez les ressources en fin de lab. Free Tier possible selon l’âge du compte.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
aws --version

Sortie attendue : un Account, un Arn utilisateur IAM (pas root), et une version CLI aws-cli/2.x.

Ce que nous allons construire

Lab AWS Fundamentals (ca-central-1)
  ├── IAM : rôle EC2 → S3 ReadOnly + instance profile
  ├── VPC /16 + 2 subnets (2 AZ) + Internet Gateway
  ├── Launch Template (Ubuntu 24.04) + run-instances
  ├── S3 : bucket unique + objet + versioning
  ├── Vérifications CLI (state, s3 ls, describe)
  └── Cleanup + erreurs fréquentes + FAQ SAA

(Schéma — alt : « Chaîne fundamentals AWS : IAM rôle, VPC multi-AZ, Launch Template EC2, bucket S3 versionné ».)

Ce hub enrichit /aws-fundamentals/ (#990, quasi vide) en FR SEO. Détails fins = leçons P1 ; ici : visite guidée des quatre piliers.

Étape 1 — Pourquoi ces quatre piliers ?

Pour l’examen Solutions Architect Associate et pour tout lab DevOps, quatre blocs reviennent sans cesse :

Pilier Service Question typique
Identité IAM Qui peut faire quoi, sans clés longues dans le code ?
Réseau VPC Où vivent mes instances, comment sortent-elles vers Internet ?
Compute EC2 + Launch Template Comment lancer une flotte reproductible ?
Stockage S3 Où stocker objets durables, versionnés, API-first ?

Maîtriser le fil IAM → VPC → EC2 → S3 évite 80 % des AccessDenied et des labs « qui marchent chez moi » non reproductibles.

Étape 2 — Identité : rôle IAM pour EC2 (pas de clés dans l’AMI)

Préférez un rôle EC2 avec politique gérée en moindre privilège — pas d’access keys longues sur l’AMI.

Créez d’abord la trust policy (EC2 peut assumer le rôle) :

cat > /tmp/trust-ec2.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
EOF

aws iam create-role 
  --role-name EC2S3ReadRole 
  --assume-role-policy-document file:///tmp/trust-ec2.json

aws iam attach-role-policy 
  --role-name EC2S3ReadRole 
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

aws iam create-instance-profile --instance-profile-name EC2S3ReadProfile
aws iam add-role-to-instance-profile 
  --instance-profile-name EC2S3ReadProfile 
  --role-name EC2S3ReadRole

En 2026, pour les humains, préférez IAM Identity Center (SSO) et des credentials temporaires plutôt que des access keys permanentes. Les rôles restent le standard pour les workloads.

Lien série : détails users / groupes / politiques dans IAM : users, groupes, rôles, politiques.

Étape 3 — Réseau : VPC, subnets multi-AZ, Internet Gateway

Toute charge utile sérieuse vit dans un VPC. Créez un /16, deux subnets publics dans deux AZ, et un IGW pour la sortie Internet.

VPC_ID=$(aws ec2 create-vpc --cidr-block 10.20.0.0/16 
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=lab-fundamentals-vpc}]' 
  --query Vpc.VpcId --output text)
echo "VPC_ID=$VPC_ID"

# Remplacez les AZ si besoin (aws ec2 describe-availability-zones)
SUBNET_A=$(aws ec2 create-subnet --vpc-id "$VPC_ID" --cidr-block 10.20.1.0/24 
  --availability-zone ca-central-1a --query Subnet.SubnetId --output text)
SUBNET_B=$(aws ec2 create-subnet --vpc-id "$VPC_ID" --cidr-block 10.20.2.0/24 
  --availability-zone ca-central-1b --query Subnet.SubnetId --output text)

IGW_ID=$(aws ec2 create-internet-gateway --query InternetGateway.InternetGatewayId --output text)
aws ec2 attach-internet-gateway --internet-gateway-id "$IGW_ID" --vpc-id "$VPC_ID"

RT_ID=$(aws ec2 describe-route-tables --filters "Name=vpc-id,Values=$VPC_ID" 
  --query 'RouteTables[0].RouteTableId' --output text)
aws ec2 create-route --route-table-id "$RT_ID" --destination-cidr-block 0.0.0.0/0 
  --gateway-id "$IGW_ID"
aws ec2 associate-route-table --route-table-id "$RT_ID" --subnet-id "$SUBNET_A"

Activez MapPublicIpOnLaunch sur le subnet public si besoin. Deux AZ préparent ASG et haute dispo.

Lien série : VPC : sous-réseaux et IGW · Security Groups vs NACLs.

Étape 4 — Compute : Launch Template puis instance

Les Launch Templates remplacent les Launch Configurations : versioning, mix d’instance types, user-data, profil IAM.

Récupérez une AMI Ubuntu 24.04 de votre Region (ne copiez pas un AMI ID d’une autre Region) :

AMI_ID=$(aws ec2 describe-images --owners 099720109477 
  --filters "Name=name,Values=ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*" 
            "Name=state,Values=available" 
  --query 'sort_by(Images,&CreationDate)[-1].ImageId' --output text)
echo "AMI_ID=$AMI_ID"

# Security group SSH/ICMP lab (restreignez votre IP en prod)
SG_ID=$(aws ec2 create-security-group --group-name lab-fundamentals-sg 
  --description "Lab fundamentals" --vpc-id "$VPC_ID" 
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG_ID" 
  --protocol tcp --port 22 --cidr 0.0.0.0/0

Créez le Launch Template (JSON) puis lancez une instance dans SUBNET_A :

cat > /tmp/lt-fundamentals.json << EOF
{
  "LaunchTemplateName": "lab-fundamentals-lt",
  "VersionDescription": "v1-ubuntu2404",
  "LaunchTemplateData": {
    "ImageId": "$AMI_ID",
    "InstanceType": "t3.micro",
    "IamInstanceProfile": { "Name": "EC2S3ReadProfile" },
    "SecurityGroupIds": ["$SG_ID"],
    "UserData": "IyEvYmluL2Jhc2gKZWNobyCIbGFiIGZ1bmRhbWVudGFscyBvayIgPiAvdmFyL2xvZy91c2VyLWRhdGEubG9nCg=="
  }
}
EOF

aws ec2 create-launch-template --cli-input-json file:///tmp/lt-fundamentals.json

IID=$(aws ec2 run-instances 
  --launch-template LaunchTemplateName=lab-fundamentals-lt,Version=1 
  --subnet-id "$SUBNET_A" --count 1 
  --query 'Instances[0].InstanceId' --output text)
echo "InstanceId=$IID"

aws ec2 describe-instances --instance-ids "$IID" 
  --query 'Reservations[0].Instances[0].State.Name' --output text

Attendez running (1–2 min). Le profil IAM permet ensuite aws s3 ls depuis l’instance sans aws configure local.

Lien série : EC2 + SSM · Auto Scaling + Launch Template.

Étape 5 — Stockage : bucket S3, objet, versioning

Noms de buckets globaux : ajoutez un suffixe unique (Account ID) :

ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
BUCKET="lab-fundamentals-${ACCOUNT}-cac1"

aws s3 mb "s3://${BUCKET}" --region ca-central-1
echo "hello fundamentals $(date -u +%Y-%m-%d)" > /tmp/sample.txt
aws s3 cp /tmp/sample.txt "s3://${BUCKET}/sample.txt"
aws s3api put-bucket-versioning --bucket "$BUCKET" 
  --versioning-configuration Status=Enabled
aws s3 ls "s3://${BUCKET}/"

Le versioning protège un rm accidentel. En prod : Block Public Access ON, SSE-S3/KMS, policies restrictives.

Lien série : S3 : bucket et sécurité · S3 versioning et réplication.

Étape 6 — Vérifications et nettoyage

Checklist rapide :

aws iam get-role --role-name EC2S3ReadRole --query Role.Arn
aws ec2 describe-vpcs --vpc-ids "$VPC_ID" --query 'Vpcs[0].CidrBlock'
aws ec2 describe-instances --instance-ids "$IID" --query 'Reservations[0].Instances[0].[State.Name,PublicIpAddress]'
aws s3api get-bucket-versioning --bucket "$BUCKET"

Cleanup (ordre important : instance → template → SG → subnets/IGW/VPC → rôle → bucket) :

aws ec2 terminate-instances --instance-ids "$IID"
# attendre terminated, puis :
aws ec2 delete-launch-template --launch-template-name lab-fundamentals-lt
aws s3 rb "s3://${BUCKET}" --force
# détacher IGW, supprimer subnets/SG/VPC, retirer rôle du profile, delete-role…

Pas d’EC2/IGW orphelins : cause n°1 des factures lab.

Erreurs fréquentes

Erreur Pourquoi ça fait mal Correction
AccessDenied sur S3/EC2 Politique IAM manquante ou mauvaise Region Vérifier rôle attaché + AWS_DEFAULT_REGION
AMI ID copié d’une autre Region InvalidAMIID.NotFound describe-images dans ca-central-1
Launch Template sans subnet / SG du même VPC Instance ne démarre pas / réseau isolé Aligner VPC, subnet, SG
CIDR qui se chevauchent Impossible de peer / routes ambiguës Plan d’adressage documenté (10.20.0.0/16)
Access keys dans user-data Fuite Git / logs Rôle IAM + instance profile
Bucket name déjà pris BucketAlreadyExists Suffixe Account ID
Oublier le cleanup Facture Script de destroy + Budget alert

Scénario examen SAA

Énoncé : Une startup lance un site vitrine + API. Elle veut zéro secret longue durée sur les VMs, une AZ de secours, et des assets (images) durables avec historique.

Réponses modèle :

  1. Rôle IAM + instance profile sur EC2 (pas d’access keys dans l’AMI).
  2. VPC avec subnets dans au moins 2 AZ ; IGW si front public.
  3. Launch Template versionné pour reproduire le fleet / brancher un ASG plus tard.
  4. S3 versionné pour les assets ; CloudFront en option (leçon suivante dans la série).

FAQ

Pourquoi préférer un rôle IAM à des access keys sur EC2 ?
Les credentials du rôle sont temporaires, tournées automatiquement, et auditées via CloudTrail. Les keys longues fuient facilement (Git, AMI, logs).

Launch Template vs Launch Configuration ?
Les Launch Configurations sont legacy. Les Launch Templates gèrent versions, paramètres avancés et ASG modernes.

Quelle Region pour un lab au Canada / Europe ?
Labs de cette série : ca-central-1. En Europe francophone, eu-west-3 (Paris) ou eu-west-1 sont courants — mais fixez une Region pour tout le lab.

Comment vérifier que l’instance atteint S3 ?
Via SSM ou SSH : aws s3 ls. Succès = le rôle attaché fonctionne (metadata service / IMDSv2).

Puis-je tout faire en Terraform ensuite ?
Oui. Importez ou recréez le stack déclarativement (S3 backend + lock DynamoDB). Ce hub reste CLI-first pour comprendre les API sous-jacentes.

Points clés à retenir

  • Les AWS Fundamentals opérationnels = IAM + VPC + EC2 (Launch Template) + S3
  • Jamais de keys longues dans une AMI ; toujours un rôle
  • VPC multi-AZ dès le premier lab sérieux
  • Bucket names globaux + versioning pour les labs durables
  • Cleanup et Budgets font partie du lab, pas un bonus

Pour aller plus loin

Maillage menu AWS (feuilles)

← Précédent menu AWS Cloud Computing
→ Suivant menu AWS History
Aussi AWS Certified Solutions Architect · AWS Sign Up
Note audit #990 était « images seules » (2 mots) ; ce draft enrichit sans supprimer les sœurs thin (#1250 aws-fundamentals-2, etc.)

Retour parcours AWS — hub de la série et leçons sœurs.

Share your love

Leave a Reply

Your email address will not be published. Required fields are marked *