🏗️ IaaS – Infrastructure as a Service (Cloud)

Panorama (non exhaustif)

Critères de choix

• Localisation des données / conformité (RGPD, souveraineté).
• Catalogue de services ( DB, IA, analytics, IoT…).
• Prix & modèle financier (capacité réservée, prix outbound, etc.).
• Écosystème, support, partenaires, marketplace.
• Verrouillage potentiel (services propriétaires vs open standards).

Lift & Shift

• Reprise quasi à l’identique de VMs on-prem → cloud.
• Permet de sortir rapidement d’un datacenter, ou d’un fournisseur.
• Souvent première étape avant refactor / modernisation.

DRP / PRA cloud

• Site de reprise d’activité sur IaaS (réplication de VMs / données).
• Automatisation de la bascule en cas de sinistre.

HPC, Big Data, IA

• Accès à des GPUs / instances très puissantes ponctuellement.
• Clusters éphémères (Spark, Dask, Ray…) pour calcul intense.
• Stockage objet pour data lakes / training sets.

Labs & sandboxes

• Environnements de test créés / détruits à la volée via IaC.
• Plateformes de formation (DevOps, Kubernetes, DBA, etc.).

VPC / Virtual Network

• Segment réseau isolé, avec range IP défini.
• Subnets publics (NAT, LB) / privés (backends, DB, batchs).
• Peering entre VPC, VPN avec on-prem, Direct Connect / ExpressRoute.

# Ex. Terraform (VPC AWS simplifié)
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = { Name = "ideo-lab-vpc" }
}
                    

Contrôles d’accès

• Security Groups : firewall “stateful” liés aux instances.
• Network ACLs : liste de contrôle plus bas niveau (stateless).
• WAF / reverse proxy pour la couche applicative.

Design classique : rien d’exposé directement, tout passe via des LB en front, WAF, voire un API Gateway pour les microservices.

Block storage

• Volumes attachés à une VM (EBS, Managed Disks, Persistent Disk…).
• Utilisé pour OS, DB, applications qui veulent du bloc.
• Performances : IOPS, throughput, provisionning, SSD vs HDD.

Object & File

• Object : buckets S3-like, idéal pour backups, assets, data lake.
• File : NFS géré (EFS, Azure Files…), pour partager un FS simple.
• Choix guidé par : taille, patterns d’accès, besoin POSIX ou non.

Types d’instances

• Généralistes : équilibre CPU/RAM pour apps web.
• CPU-optimised : calcul intensif (batch, encodage vidéo...).
• Memory-optimised : bases de données, caches in-memory.
• GPU : IA/ML, rendu 3D, HPC.

Modèles d’achat

• On-demand : flexible, mais plus cher.
• Reserved / Savings plans : engagement de durée pour réduire les coûts.
• Spot / preemptible : très économique mais interruptible.

Pattern classique : mélange on-demand (critique), reserved (steady-state), spot (batch / tolérant à l’interruption).

Shared responsibility

• Le provider sécurise le cloud : DC, hyperviseur, réseau physique.
• Tu sécurises ce que tu déploies dans le cloud : OS, apps, données.
• IAM = point central (comptes, rôles, permissions, MFA).

Bonnes pratiques

• Principe du moindre privilège (roles finement définis).
• Pas de clés d’accès exposées (repos Git, scripts…).
• Utilisation de services de secrets management (Vault, Secret Manager, KMS…).
• Logs centralisés (CloudTrail-like, logs firewall, WAF) + alerting.

Principales sources de coûts

• Instances compute (24/7 vs burst, taille choisie).
• Disques (taille provisionnée, IOPS, snapshots stockés).
• Stockage objet (volume, classes de stockage, durées).
• Trafic sortant (egress internet, inter-régions).

Levers d’optimisation

• Extinction / downscale des env non prod hors horaires.
• Usage de réservations / plans pour workloads stables.
• Choix de classes de stockage archive pour données froides.
• Réduction des “zombies” (volumes orphelins, IP inutilisées…).
• Tagging systématique pour savoir qui consomme quoi.

6 “R” (classiques)

• Rehost (lift & shift).
• Replatform (petits changements, ex : DB managée).
• Refactor (re-architecture profonde, microservices…).
• Retire (supprimer ce qui ne sert plus).
• Retain (ne pas migrer pour l’instant).
• Replace (changer de solution, ex : SaaS).

Approche pratique

• Cartographier le SI (applis, dépendances, data flows).
• Prioriser : quick wins vs blocs complexes.
• Planifier par vagues, avec critères de succès mesurables.
• Pilotage via un “cloud landing zone” bien définie (réseau, IAM, sécurité…).

Classiques

• Reproduire 1:1 le datacenter on-prem dans le cloud.
• Pas de tagging → impossible de comprendre la facture.
• Pas de séparation d’environnements / comptes.
• Tout mettre en public subnet avec SSH ouvert au monde…

Organisationnels

• Absence de gouvernance (IAM, comptes, budgets).
• Shadow IT : projets cloud non maîtrisés dans des comptes perso.
• Pas de formation des équipes ops & sécurité au modèle cloud.

Mots-clés

• IaaS = compute + storage + network as-a-service.
• Régions / AZ, VPC, IAM, LB, volumes, buckets.
• Infra as Code (Terraform, Pulumi, Ansible).
• FinOps, tagging, reserved / spot instances.
• Shared responsibility model.

Checklist design IaaS

• Réseau : VPC, subnets, VPN, règles de sécurité.
• Identité : IAM, rôles, MFA, comptes séparés.
• Logs : activés partout, centralisés, retenus.
• Coûts : budgets, alertes, tags, revue régulière.
• Automatisation : IaC + CI/CD pour l’infra.