☁️ AWS – Écosystème & Services Cloud

1.1 Vue d’ensemble – AWS Cloud & familles de services

AWS en 3 lignes

AWS (Amazon Web Services) est une plateforme de cloud public qui fournit des services d’infrastructure, de plateforme et de services managés, accessibles via API/console.

Paiement à l’usage (pay-as-you-go, reserved, spot).
Infrastructure globale multi-régions.
Énorme catalogue : compute, storage, réseau, data, IA, IoT, etc.

Vision “LEGO technique”

La philosophie AWS : des “briques” très spécialisées que tu composes :

EC2 pour la compute, S3 pour l’objet, RDS pour la DB, etc.
Tu designes tes architectures en assemblant ces briques.
Tout est pilotable par API → parfait pour DevOps/IaC.

Éléments de base d’un compte AWS

Un compte AWS (id à 12 chiffres, root account).
Une ou plusieurs régions où tu déploies tes ressources.
Des VPC pour segmenter ton réseau virtuel.
Des IAM users/roles pour les permissions.

Organisation cible “entreprise”

AWS Organisations pour gérer multi-comptes (prod, preprod, sandbox…).
Landing zone : standard de base (réseau, logs, sécurité).
Centralisation de la facturation & des politiques.

Familles de services (simplifiées)

Famille	Exemples
Compute	EC2, ECS, EKS, Lambda, Batch.
Storage	S3, EBS, EFS, FSx, Glacier.
Réseau & CDN	VPC, ELB, Route 53, API GW, CloudFront.
Data & Analytics	RDS, Aurora, DynamoDB, Redshift, EMR, Athena.
Sécurité	IAM, KMS, GuardDuty, WAF, Config.

Philosophie d’utilisation

Utiliser d’abord les services managés (RDS, DynamoDB…) plutôt que tout refaire sur EC2.
Penser infrastructure éphémère : tout se recrée via IaC.
Observabilité & sécurité intégrées dès le début (logs, IAM, KMS).

Cas d’usage classiques

Hébergement d’applications web / API à l’échelle mondiale.
Data platforms, data lakes & analytics.
HPC & simulations (EC2 + EFA + S3).
Modernisation d’applications legacy (lift & shift + refactor).

Contexte IDEO-Lab

Cluster EC2 / RDS pour labs DBA & tuning.
S3 + Glacier pour sauvegardes & archivage projets.
Lambda / API Gateway pour micro-services serverless de démonstration.

1.2 Global Infrastructure – Régions, AZ, Organisations, Landing Zone

Régions

Chaque région est une zone géographique séparée.
Choix selon latence, conformité, proximité des clients.
Ressources typiquement non répliquées cross-région par défaut.

AZ – Availability Zones

Plusieurs datacenters indépendants par région.
Design HA : répartir instances & DB sur plusieurs AZ.
Services managés peuvent gérer automatiquement multi-AZ (RDS, etc.).

AWS Organisations

Hiérarchie de comptes (organisation → OU → comptes).
Facturation consolidée, gouvernance centralisée.
Service Control Policies (SCP) pour restreindre ce qui est autorisé.

Patron multi-compte

root (organisation)
 ├── security (logs, SIEM, guardduty)
 ├── shared-services (AD, tooling)
 ├── sandbox (développeurs)
 ├── nonprod (dev / test / staging)
 └── prod (production)

Landing Zone

Architecture “socle” décrivant :
- Organisation des comptes.
- Structure réseau (VPC partagés, transit gateway…).
- Stratégie logs & sécurité.
Peut être gérée via AWS Control Tower ou IaC maison.

Pourquoi c’est critique

Évite de “bricoler” compte par compte.
Assure un minimum de standardisation & de sécurité.
Facilite le multi-environnements / multi-teams.

1.3 Compute AWS – EC2, Auto Scaling, ECS & EKS

EC2 & Auto Scaling

EC2 = VM gérée : choix type d’instance, OS, stockage.
Auto Scaling Group (ASG) : scale-out / in selon métriques.
Elastic Load Balancing : ALB (L7), NLB (L4).

# Exemple simplifié AWS CLI
aws ec2 run-instances \
  --image-id ami-123456 \
  --instance-type t3.micro \
  --subnet-id subnet-abc \
  --security-group-ids sg-xyz

Containers : ECS & EKS

ECS : orchestrateur Docker natif AWS.
EKS : Kubernetes managé.
Patterns :
- EC2 + ECS/EKS : clusters sur VMs.
- Fargate : containers serverless (pas de VM à gérer).

Idéal pour packager tes services IDEO-Lab en microservices, avec auto-scaling et intégration ALB / API Gateway.

1.4 Storage AWS – S3, EBS, EFS, classes & patterns

S3 – Object Storage

Buckets, objets, clés, versionning.
Classes : Standard, IA, One Zone, Glacier, Deep Archive.
Cas d’usage : backups, assets web, logs, data lake.

aws s3 mb s3://ideo-lab-demo
aws s3 cp fichier.txt s3://ideo-lab-demo/

EBS & EFS

EBS : volumes blocs attachés à EC2 (GP3, IO1/2, etc.).
EFS : NFS managé, partagé entre plusieurs instances.
Choix guidé par IOPS, throughput, taille, besoin POSIX partagé ou non.

2.1 Réseau & Edge – VPC, Route 53, CloudFront

VPC & Subnets

VPC = réseau virtuel isolé (CIDR 10.0.0.0/16 par ex.).
Subnets publics (NAT, LB) vs privés (app, DB).
Security Groups & NACL pour filtrage réseau.

DNS, CDN & Edge

Route 53 : DNS managé, health checks, routing policies.
CloudFront : CDN global (cache contenu S3 / HTTP).
Intégration avec WAF pour filtrage applicatif.

2.2 Databases & Analytics – RDS, Aurora, DynamoDB, Redshift…

Bases relationnelles

RDS : MySQL, PostgreSQL, MariaDB, Oracle, SQL Server managés.
Aurora : moteur compatible MySQL / PostgreSQL optimisé AWS.
Multi-AZ, sauvegardes automatiques, read replicas.

NoSQL & analytique

DynamoDB : key-value / document managé, hautement scalable.
Redshift : data warehouse colonne.
Athena : requêtes SQL serverless sur données S3.
OpenSearch : recherche & analytics (ex-Elasticsearch managé).

2.3 Serverless & Event-driven – Lambda, API GW, EventBridge, SQS/SNS

AWS Lambda

Fonctions exécutées à la demande (évènement, HTTP, cron…).
Pas de serveur à gérer, facturation à la durée & mémoire.
Intégration profonde avec S3, DynamoDB, EventBridge, SQS…

def handler(event, context):
    print("Hello from IDEO-Lab on AWS Lambda")
    return {"statusCode": 200, "body": "OK"}

API Gateway, SQS, SNS, EventBridge

API Gateway : front HTTP/REST/WS serverless (souvent → Lambda).
SQS : file de messages (decoupling asynchrone).
SNS : pub/sub notifications.
EventBridge : bus d’évènements (SaaS + AWS + custom), route vers cibles (Lambda, Step Functions…).

3.1 Sécurité AWS – IAM, KMS, GuardDuty, Shared Responsibility

IAM – identités & permissions

Users, Groups, Roles, Policies (JSON).
Principe du moindre privilège (least privilege).
Utiliser des roles plutôt que des clés longues durées.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:ListBucket"],
    "Resource": ["arn:aws:s3:::ideo-lab-demo"]
  }]
}

KMS, GuardDuty & Config

KMS : gestion des clés & chiffrement (EBS, S3, RDS…).
GuardDuty : détection de menaces managée.
Config : conformité & drift (état des ressources + règles).
CloudTrail : journal de tous les appels d’API (audit).

3.2 Observabilité – CloudWatch, CloudTrail, Logs & Metrics

CloudWatch

Métriques (CPU, mémoire, latence, custom metrics).
Logs (CloudWatch Logs), log groups / streams.
Alarms → SNS / PagerDuty / Slack.

Traçage & audit

CloudTrail pour l’audit des appels API.
X-Ray pour le tracé des requêtes applicatives.
Pattern : centraliser tous les logs dans un compte “sécurité”.

3.3 AWS & DevOps – CloudFormation, CDK, Terraform, Pipelines

CloudFormation

Templates YAML/JSON décrivant les ressources.
Stacks versionnées, rollback automatique en cas d’erreur.
StackSets pour multi-comptes / multi-régions.

CDK

AWS CDK permet de décrire l’infra en TypeScript, Python, etc. :

from aws_cdk import (
    aws_s3 as s3,
    Stack,
)
class IdeoLabStack(Stack):
    def __init__(self, scope, id, **kwargs):
        super().__init__(scope, id, **kwargs)
        s3.Bucket(self, "IdeoLabBucket",
                  versioned=True,
                  bucket_name="ideo-lab-demo-bucket")

Terraform / Pulumi

IaC multi-cloud, très utilisé avec AWS.
State dans S3 + DynamoDB pour le locking.
Modules réutilisables (VPC, ALB, EKS…).

Backend Terraform S3 (exemple)

terraform {
  backend "s3" {
    bucket = "ideo-lab-tf-state"
    key    = "aws/infra/terraform.tfstate"
    region = "eu-west-1"
    dynamodb_table = "tf-locks"
  }
}

Services CI/CD AWS

CodeCommit (Git), CodeBuild, CodePipeline, CodeDeploy.
Intégration avec GitHub, GitLab, Bitbucket.

Pattern typique

Push sur repo → pipeline lance tests → build image / artefact.
Déploiement automatisé sur ECS/EKS/Lambda/EC2.
Plan Terraform / CDK dans la pipeline pour l’infra.

4.1 Hybrid & Enterprise – Direct Connect, VPN, Outposts

Connectivité vers on-premise

VPN IPsec : tunnel chiffré via internet.
Direct Connect : lien réseau dédié, latence & bande passante garanties.
Transit Gateway : hub pour interconnecter VPC & sites distants.

Outposts & extensions

AWS Outposts : rack AWS dans ton datacenter (services AWS sur site).
Local Zones / Wavelength : latence ultra faible près des users.
Usage typique : contraintes réglementaires ou techniques fortes.

4.2 Cheat-sheet AWS – Services clés & commandes utiles

Services à connaître par cœur

Compute : EC2, ECS, EKS, Lambda.
Storage : S3, EBS, EFS, Glacier.
Réseau : VPC, ELB, Route 53, API GW, CloudFront.
Data : RDS, Aurora, DynamoDB, Redshift, Athena.
Sécurité : IAM, KMS, CloudTrail, GuardDuty, Config.
Outils DevOps : CloudFormation, CDK, CodePipeline.

CLI & patterns mentaux

# Profil & région
aws configure
aws sts get-caller-identity

# EC2
aws ec2 describe-instances
aws ec2 stop-instances --instance-ids i-xxxx

# S3
aws s3 ls
aws s3 sync ./static s3://ideo-lab-assets/ --delete

# CloudFormation
aws cloudformation deploy \
  --template-file stack.yml \
  --stack-name ideo-lab-core

Pense “tout en IaC” : rien de critique créé à la main.
Tagging systématique : env, owner, app, cost-center.
Multi-compte & multi-AZ par défaut pour la prod.

☁️ AWS – Écosystème & Services Cloud

Vue d’ensemble AWS

Global Infrastructure

Compute (EC2, ECS, EKS)

Storage (S3, EBS, EFS)

Réseau & Edge

Databases & Analytics

Serverless & Events

Sécurité, IAM & KMS

Supervision & Observabilité

DevOps & IaC

Hybrid & Enterprise

Cheat-sheet AWS