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-1Slug :
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é
labavec 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 :
- Rôle IAM + instance profile sur EC2 (pas d’access keys dans l’AMI).
- VPC avec subnets dans au moins 2 AZ ; IGW si front public.
- Launch Template versionné pour reproduire le fleet / brancher un ASG plus tard.
- 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
- Démarrer avec AWS — compte, Free Tier, MFA, CLI
- AWS Cloud Computing — IaaS / PaaS / SaaS, Shared Responsibility
- IAM détaillé · VPC · EC2 + SSM · S3 sécurité
- Auto Scaling + Launch Template
- Docs AWS : IAM roles · VPC · Launch Templates · S3
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.



