AWS Cloud Computing : fondamentaux IaaS, PaaS, SaaS et modèles de déploiement
À la fin de ce tutoriel, vous saurez définir le cloud computing, comparer les modèles public / privé / hybride / multi-cloud, choisir entre IaaS, PaaS et SaaS, et relier le Shared Responsibility Model aux services AWS de lab en
ca-central-1.Niveau : Débutant · Temps estimé : 40–50 min · Versions testées : AWS Management Console (2026), AWS CLI v2 · Dernière vérification : 2026-09-11 · Region :
ca-central-1Slug :
aws-cloud-computing· Série : AWS Solutions Architect · Mot-clé SEO : aws cloud computing← Précédent : Démarrer avec AWS · → Suivant : IAM : users, groupes, rôles, politiques · Hub : Démarrer avec AWS
Prérequis
- Compte AWS de lab (Free Tier) et profil CLI
lab— voir Démarrer avec AWS - Notions basiques réseau (IP, Internet) ; pas besoin d’avoir déjà lancé EC2
- Lecture seule pour le mini-lab :
ec2:DescribeRegions,sts:GetCallerIdentity
Coût estimé : 0 € — commandes de lecture seulement, aucune ressource facturable créée.
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
Ce que nous allons construire
Concepts cloud (NIST / AWS)
├── Définition + 5 caractéristiques
├── Modèles de déploiement : all-in-cloud · privé · hybride · multi-cloud
├── Modèles de service : IaaS · PaaS · SaaS
├── Shared Responsibility Model
├── Regions / AZ / Edge (ca-central-1)
└── Mapping labs : IAM · VPC · EC2 · S3
(Schéma — alt : « Pyramide cloud computing : déploiement, IaaS/PaaS/SaaS, responsabilité partagée, labs AWS ».)
Qu’est-ce que le cloud computing ?
Le cloud computing, c’est la livraison à la demande de services informatiques — serveurs, bases de données, logiciels, analytique, intelligence artificielle, stockage et networking — via Internet (The Cloud), avec un paiement uniquement pour ce que vous utilisez.
Concrètement : plus besoin d’un investissement massif en hardware avant de démarrer. Vous provisionnez via la console ou des API, vous libérez la capacité quand elle ne sert plus, et vous réduisez les coûts opérationnels (OpEx) tout en gagnant en efficacité (moins de racks, alimentation, cooling, patches physiques).
Les 5 caractéristiques (NIST / vocabulaire AWS)
| Caractéristique | Idée | Exemple AWS |
|---|---|---|
| On-demand self-service | Provisionner sans ticket humain | Lancer une EC2 en minutes |
| Broad network access | Accès via Internet / réseaux standards | Console, CLI, SDK |
| Resource pooling | Capacité mutualisée (multi-tenant) | Hyperviseurs, pools EBS/S3 |
| Rapid elasticity | Scale out / in rapidement | ASG, Lambda concurrency |
| Measured service | Usage mesuré et facturé | Billing, Cost Explorer |
Le cloud n’est pas « un serveur chez quelqu’un d’autre » : c’est une plateforme API-first, élastique et mesurée.
Pourquoi le cloud ? (CapEx → OpEx)
Avant le cloud : achat de serveurs (CapEx), délai de livraison, capacité « au pire cas ». Avec AWS :
- Pas d’investissement hardware initial pour expérimenter ou scaler
- Élasticité : montée en charge puis descente
- Vitesse : idée → prototype en heures
- Fiabilité : Regions multi-AZ, services managés
- OpEx pilotable avec budgets / alertes — voir Démarrer avec AWS
Attention : une mauvaise config (NAT Gateway oubliée, snapshots orphelins) coûte. Activez Free Tier + Budgets et nettoyez après chaque lab.
Modèles de déploiement
Le contenu historique parlait d’all-in-cloud et d’Hybrid Deployment. On les conserve et on les place dans le cadre examen. Deux facteurs décident : qui contrôle l’infrastructure et où elle réside.
All-in-cloud (cloud public)
Une application all-in-cloud est entièrement déployée dans le cloud : web, API, base, stockage, identity tournent chez le fournisseur. Sur AWS, « public » signifie que vous partagez l’infra physique du fournisseur — pas que vos données sont publiques. La sécurité dépend de votre IAM, VPC, chiffrement, etc.
Cloud privé
Infrastructure dédiée à une organisation (datacenter virtualisé, Outposts, cloud privé géré). Utile pour réglementation stricte, latence locale ou legacy. Plus cher et moins élastique que le public.
Hybrid Deployment (hybride)
Approche coutumière des grandes entreprises : on relie le cloud aux ressources on‑prem. Objectifs : garder des actifs stratégiques on‑prem, burst capacity, migration progressive. Sur AWS : VPN Site-to-Site, Direct Connect, Transit Gateway, AD hybride. Le ressenti doit être celui d’une seule organisation (réseau, identité, ops) — comme Exchange on‑prem ↔ Exchange Online, généralisé à n’importe quelle app.
Multi-cloud
Plusieurs fournisseurs (AWS + Azure + GCP) pour limiter le lock-in ou coller à des SaaS déjà choisis. Complexité ops en hausse. Pour cette série : AWS-first en ca-central-1.
| Modèle | Contrôle | Résidence | Cas d’usage |
|---|---|---|---|
| Public / all-in-cloud | Fournisseur (physique) ; vous (config) | Regions AWS | Labs, cloud-native |
| Privé | Vous / opérateur dédié | Datacenter / Outposts | Réglementation, legacy |
| Hybride | Partagé | On-prem et cloud | Migration, burst |
| Multi-cloud | Multiple | Plusieurs providers | Stratégie entreprise |
IaaS, PaaS, SaaS
Ce sont les modèles de service (qui gère quelle couche). Le live listait déjà IaaS / PaaS / SaaS — on densifie avec responsabilité et équivalents AWS.
IaaS — Infrastructure as a Service
Le fournisseur héberge les composants d’infrastructure d’un datacenter on‑prem : serveurs, stockage, networking, et la couche virtualisation / hypervisor. Vous gérez OS, runtime, applications et données.
Fournisseurs : Amazon Web Services, Google Compute Engine, Microsoft Azure.
Labs AWS : EC2, VPC, EBS, ELB.
PaaS — Platform as a Service
Le fournisseur livre une plateforme pour développer, exécuter et contrôler des apps sans construire ni maintenir toute l’infra. Idéal pour accélérer build/test/deploy.
Exemples : AWS Elastic Beanstalk, Google App Engine ; aussi App Runner. Vous apportez le code ; le fournisseur patch OS/runtime et orchestre le scaling plateforme.
SaaS — Software as a Service
Modèle qui permet de se connecter à des applications cloud via Internet. Solution complète, souvent en pay-as-you-go ou abonnement. Le vendor contrôle toute la pile ; accès typique via navigateur.
Exemples tiers (live) : Dropbox, Google G Suite (Workspace), Microsoft Office 365.
Exemples AWS : Amazon Chime, Amazon WorkMail.
| Couche | IaaS | PaaS | SaaS |
|---|---|---|---|
| Données / config métier | Vous | Vous | Vous (usage) |
| Application | Vous | Vous | Fournisseur |
| Runtime / OS | Vous | Fournisseur | Fournisseur |
| Virtualisation / serveurs / réseau physique | Fournisseur | Fournisseur | Fournisseur |
| Exemples AWS | EC2, VPC, EBS | Beanstalk, App Runner | Chime, WorkMail |
Règle examen : plus vous montez vers SaaS, moins vous gérez de couches — et moins de contrôle fin.
Shared Responsibility Model
- AWS : sécurité of the cloud (datacenters, hardware, hyperviseurs, Regions/AZ)
- Vous : sécurité in the cloud (IAM, réseau, chiffrement, patch OS sur EC2, données)
En IaaS (EC2) : vous patcher l’OS et durcir le SG. En PaaS : AWS gère plus la plateforme ; vous sécurisez app et secrets. En SaaS : comptes, MFA, partage, conformité d’usage. Suite concrète : IAM.
Regions, Availability Zones et Edge
- Region : zone géographique — lab série =
ca-central-1(Canada Central) - AZ : datacenters isolés dans la Region ; haute dispo = multi-AZ
- Edge locations : CloudFront / Route 53 proches des utilisateurs
IAM et certains services sont globaux ; EC2, VPC, buckets S3, RDS sont régionaux. Fixez une Region de lab. Chronologie / contexte : slug live aws-history-2.
Mapping services AWS pour vos labs
| Besoin | Service | Tutoriel |
|---|---|---|
| Identité & permissions | IAM | IAM |
| Réseau isolé | VPC, subnets, IGW | VPC |
| Compute IaaS | EC2 + SSM | EC2 |
| Stockage objet | S3 | S3 sécurité |
| Hub démarrage | Compte, MFA, CLI | Démarrer avec AWS |
Mini-lab conceptuel (lecture seule)
Objectif : valider Region + identité sans créer de ressource coûteuse.
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
aws ec2 describe-regions --query 'Regions[].RegionName' --output table
aws ec2 describe-availability-zones
--region ca-central-1
--query 'AvailabilityZones[].{Zone:ZoneName,State:State}'
--output table
Attendu : ARN IAM (pas root), Regions dont ca-central-1, AZ ca-central-1a/b/… en available. Si UnauthorizedOperation, corrigez le profil avant tout lab write.
Scénario examen SAA
Une entreprise modernise une app on‑prem. La DB clients doit rester au datacenter (réglementation) ; le front web doit scaler pour des pics marketing. Petite équipe, budget limité.
- Déploiement → Hybride (DB on‑prem + front/API AWS), pas all-in-cloud pur.
- Front scalable sans gérer les OS → souvent PaaS (Beanstalk / App Runner) ; IaaS EC2 si contrôle kernel / agents legacy.
- Messagerie Office 365 → SaaS (hors infra AWS).
Réponse modèle : hybride + PaaS web + SaaS productivité ; VPN/Direct Connect ; responsabilité claire DB on‑prem vs front cloud.
Erreurs fréquentes
| Erreur | Pourquoi ça fait mal | Correction |
|---|---|---|
| Confondre IaaS et PaaS | Mauvaise question SAA / mauvais service | Revoir le tableau de couches |
| « Public = données publiques » | S3 / SG ouverts « parce que cloud public » | Public = infra partagée ; sécurisez IAM/VPC/S3 |
| All-in-cloud vs régulation on‑prem | Non-conformité | Hybride ou privé |
| Changer de Region en plein lab | Ressources « disparues » | Fixer ca-central-1 |
| « AWS gère toute la sécu » | Root sans MFA, keys exposées | MFA + IAM least privilege |
| Créer des ressources sans budget | Facture surprise | Labs lecture seule + Budgets |
Quiz (5 questions)
1. Le cloud computing se caractérise surtout par :
– A. L’achat obligatoire de serveurs dédiés
– B. Livraison à la demande via Internet, paiement à l’usage
– C. Un seul datacenter mondial sans API
2. Une app entièrement hébergée chez AWS (web + DB + stockage) correspond à :
– A. Hybrid only
– B. All-in-cloud / cloud public
– C. SaaS uniquement
3. EC2 + VPC + EBS illustrent principalement :
– A. SaaS
– B. PaaS
– C. IaaS
4. Elastic Beanstalk et Google App Engine sont des exemples de :
– A. PaaS
– B. IaaS hyperviseur
– C. Edge locations
5. Dropbox, Google Workspace et Office 365 sont des exemples de :
– A. IaaS
– B. SaaS (pay-as-you-go / abonnement, pile gérée par le vendor)
– C. NACL
Réponses : 1‑B · 2‑B · 3‑C · 4‑A · 5‑B
Pour aller plus loin
- What is cloud computing? (AWS)
- Types of cloud computing
- Shared Responsibility Model
- Global Infrastructure
- AWS Well-Architected Framework
Maillage série AWS (P1)
| ← Précédent | Démarrer avec AWS |
| → Suivant | IAM : users, groupes, rôles, politiques |
| Aussi | VPC · EC2 + SSM · S3 sécurité · aws-history-2 |
Retour parcours AWS — hub de la série et leçons sœurs.
