SSM : patch, paramètres et Session Manager

À la fin de ce tutoriel, vous validerez Session Manager sur une EC2, stockerez un paramètre dans Parameter Store, et comprendrez Patch Manager / Run Command — administration sans SSH public en ca-central-1.

Niveau : Intermédiaire · Temps estimé : 55–65 min · Versions testées : SSM 2026, Amazon Linux 2023, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

Slug : aws-ssm-session-manager · Série : AWS Solutions Architect · Mot-clé SEO : AWS Systems Manager

← Précédent : CloudWatch · → Suivant : Lambda + API Gateway · Hub : Démarrer avec AWS

Prérequis

• EC2 avec instance profile AmazonSSMManagedInstanceCore (EC2 + SSM, IAM)
• Egress HTTPS ou VPC endpoints SSM si subnet privé
• Profil lab

Coût estimé : Session Manager / Parameter Store Standard ≈ gratuit à bas volume. Advanced parameters et Session logging vers S3/CloudWatch = coûts possibles. Surveillez surtout le volume des transcripts et le tier Advanced si vous dépassez les quotas Standard.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

EC2 (SSM Agent) ◄── Session Manager ── CLI/Console
       │
       ├── Run Command (uptime)
       └── Parameter Store /lab/app/db_url (SecureString)

(Schéma — alt : « SSM Session Manager + Parameter Store ».)

Étape 1 — Pourquoi SSM plutôt que SSH 0.0.0.0/0

Approche	Risque	Audit
SSH ouvert Internet	Élevé	Clés éparpillées
Bastion + SG	Moyen	Encore des .pem
Session Manager	Faible	IAM + CloudTrail

Pas de port 22 requis sur les security groups des instances. Idéal pour les labs et pour la production quand IAM et logging sont correctement gouvernés. L’authentification repose sur IAM (SSO, MFA, conditions IP ou tags), pas sur des clés privées à faire circuler. CloudTrail enregistre qui a démarré une session et sur quelle instance — un avantage net pour les audits.

Hybrid Activation (aperçu)

SSM gère aussi des serveurs on-prem via hybrid activations (code + ID). Hors lab EC2, mais explique pourquoi « Systems Manager » n’est pas limité au cloud. Une fois activés, ces nœuds apparaissent comme instances managées et peuvent recevoir Run Command, Patch Manager ou Session Manager selon le système d’exploitation.

Default Host Management Configuration

Au niveau compte/Organization, on peut appliquer automatiquement un rôle SSM aux nouvelles instances — réduit les oublis de instance profile. Vérifiez dans Preferences si votre org l’utilise. En lab solo, l’instance profile attaché explicitement reste la méthode la plus claire à documenter.

Étape 2 — Vérifier l’instance managée

aws ssm describe-instance-information 
  --query 'InstanceInformationList[].{Id:InstanceId,Ping:PingStatus,Agent:AgentVersion}'

PingStatus=Online requis. Sinon : policy IAM, agent, endpoints ssm, ssmmessages, ec2messages, DNS VPC. Attendez parfois une à deux minutes après le boot pour que l’agent s’enregistre. Sur Amazon Linux 2023, l’agent SSM est en général préinstallé ; vérifiez le service si le Ping reste ConnectionLost.

Étape 3 — Session interactive

INSTANCE_ID=i-0abc…
aws ssm start-session --target "$INSTANCE_ID"

Plugin Session Manager Manager requis sur le laptop (doc AWS). Sinon : console EC2 → Connect → Session Manager.

Dans la session : uptime, whoami (souvent ssm-user). Quittez proprement avec exit pour fermer la session côté contrôle. Les permissions ssm:StartSession et le document de session peuvent restreindre les utilisateurs ou les commandes autorisées.

Étape 4 — Run Command

aws ssm send-command 
  --document-name "AWS-RunShellScript" 
  --targets "Key=instanceIds,Values=$INSTANCE_ID" 
  --parameters 'commands=["uptime","cat /etc/os-release | head -3"]' 
  --comment "lab-run" 
  --query 'Command.CommandId' --output text

CMD_ID=…  # coller
aws ssm list-command-invocations --command-id "$CMD_ID" --details 
  --query 'CommandInvocations[0].CommandPlugins[0].Output'

Utile pour patch one-shot, inventaire, scripts sans ouvrir de shell. Ciblez aussi par tags (Key=tag:Environment,Values=lab) pour une flotte. Consultez le statut (Success / Failed) avant de parser la sortie ; un timeout trop court coupe les scripts longs.

Étape 5 — Parameter Store

aws ssm put-parameter 
  --name /lab/app/db_url 
  --type SecureString 
  --value "postgres://labadmin:REDACTED@lab-pg.internal:5432/app" 
  --overwrite

aws ssm get-parameter --name /lab/app/db_url --with-decryption 
  --query 'Parameter.Value' --output text

Types : String, StringList, SecureString (KMS).
Hierarchie /lab/app/... + IAM par chemin.
Advanced parameters : taille/throughput + (policies tier).

Ne committez jamais la valeur — uniquement le nom du paramètre dans Git. Les applications lisent le paramètre au démarrage (SDK / CLI) ; évitez de l’injecter en clair dans les User Data ou les logs CloudWatch.

Étape 6 — Patch Manager (aperçu)

Baselines + maintenance windows pour patcher des flottes. Pour l’examen : Patch Manager fait partie de Systems Manager ; en lab solo, un dnf update via Run Command suffit à illustrer. En prod, associez des patch groups via tags et planifiez les fenêtres hors pics de trafic pour limiter l’impact.

Étape 7 — Session logging (prod)

Envoyez les transcripts vers S3 / CloudWatch Logs via Preferences Document — audit compliance. Activez seulement si vous assumez le stockage. Chiffrez le bucket S3 et limitez l’accès lecture aux rôles audit ; sans logging, Session Manager reste pratique mais moins défendable en conformité.

Étape 8 — Vérification

aws ssm describe-instance-information
aws ssm get-parameter --name /lab/app/db_url --with-decryption

Checklist : Online · start-session OK · Run Command output · SecureString lisible avec droits · pas de SSH public requis.

Port forwarding & SSH over SSM

start-session + document port forwarding permet d’accéder à RDS privé / localhost sans bastion classique. SSH over SSM existe aussi (ProxyCommand) pour les outils qui exigent un client SSH — tout en gardant le plan de contrôle IAM. Typique : forward local vers le port 5432 d’une RDS privée pour un client SQL sur le laptop, sans ouvrir le SG de la base à Internet.

Secrets vs Parameter Store vs Secrets Manager

Parameter Store SecureString = config/secrets simples. Secrets Manager = rotation automatique (RDS), coût par secret. Ne mélangez pas : URLs non sensibles en String ; mots de passe en SecureString ou Secrets Manager. Pour une URL de connexion avec mot de passe, SecureString ou Secrets Manager ; pour un simple feature flag, un String Standard suffit.

Nettoyage

aws ssm delete-parameter --name /lab/app/db_url
aws ssm delete-parameter --name /lab/app/log_level 2>/dev/null || true
aws ssm delete-parameter --name /lab/app/feature_x 2>/dev/null || true
# terminer l'EC2 lab si plus besoin

Checklist flotte avant prod

1. Instance profile minimal + ssm:StartSession réservé aux admins SSO.
2. Endpoints ou NAT documentés pour subnets privés.
3. Patch baselines + maintenance window taguées Environment.
4. Parameter policies IAM par préfixe /prod/ vs /lab/.
5. CloudTrail activé pour auditer StartSession / PutParameter.

Sans ces cinq points, Session Manager reste un outil puissant mal gouverné.

Erreurs fréquentes

Symptôme	Cause	Correction
TargetNotConnected	Agent/IAM/endpoints	Policy core + réseau 443
start-session plugin missing	CLI locale	Installer session-manager-plugin
AccessDenied get SecureString	Manque kms:Decrypt	Droits KMS + ssm:GetParameter
Paramètre en clair dans Git	Anti-pattern	Nom seul + SecureString

VPC endpoints (rappel privé)

Sans NAT, créez des Interface endpoints pour :
– com.amazonaws.ca-central-1.ssm
– com.amazonaws.ca-central-1.ssmmessages
– com.amazonaws.ca-central-1.ec2messages

SG endpoints : allow 443 depuis SG instances. Private DNS activé sur le VPC. Sans Private DNS, l’agent peut résoudre les noms publics et échouer si aucune route Internet n’existe.

Automation documents

SSM Automation orchestre runbooks (AMI baking, DR). Plus puissant que Run Command simple — cité en examen Pro davantage qu’Associate, mais bon à connaître. Un runbook typique enchaîne arrêt, snapshot, patch, redémarrage avec rollback sur échec.

State Manager & Inventory (aperçu)

State Manager applique une config désirée en continu ; Inventory collecte OS/apps. Complètent Patch/Session pour une flotte. Hors lab minimal. Inventory alimente aussi des dashboards de conformité (versions d’agent, packages installés) utiles avant un patch massif.

Liens avec les tutos précédents

Le rôle lab-ec2-role + AmazonSSMManagedInstanceCore du parcours IAM/EC2 est le prérequis non négociable. Les endpoints Interface dans un subnet privé évitent NAT Gateway cher — design VPC avancé.

Coût Session logging

Logger toutes les sessions vers S3/CloudWatch est excellent pour l’audit, mais générez du volume. Activez sur les comptes prod admin ; sur un lab jetable, optionnel pour économiser stockage et complexité.

Lab bonus (5–8 min) — path hierarchy + Run Command par tag

# Paramètres liés (app config)
aws ssm put-parameter --name /lab/app/log_level --type String --value INFO --overwrite
aws ssm put-parameter --name /lab/app/feature_x --type String --value "false" --overwrite

aws ssm get-parameters-by-path --path /lab/app --recursive --with-decryption   --query 'Parameters[].{Name:Name,Type:Type}'

# Run Command ciblé par tag (si votre EC2 a Environment=lab)
aws ssm send-command   --document-name "AWS-RunShellScript"   --targets "Key=tag:Environment,Values=lab"   --parameters 'commands=["echo ok; date -u"]'   --comment "lab-by-tag"   --query 'Command.CommandId' --output text

Objectif : hiérarchie IAM-friendly (/lab/app/*) + ciblage flotte par tags. Supprimez ensuite les paramètres bonus.

Scénario examen classique

« Les admins ouvrent encore SSH 22 depuis 0.0.0.0/0 ; le RSSI exige MFA, audit, et zéro clé .pem sur les laptops. Les apps lisent une URL DB sans la committer. » → Session Manager (IAM + MFA conditionnelle) + CloudTrail + optionnellement session logging S3 ; secrets en SecureString Parameter Store (ou Secrets Manager si rotation RDS). Endpoints Interface SSM dans le subnet privé si pas de NAT. Pas de bastion « juste pour SSH » sauf contrainte outillage héritée (alors SSH over SSM / port forward).

Checklist lab anti-dérive SSM

1. Instance profile = AmazonSSMManagedInstanceCore (pas Admin) ; Region ca-central-1.
2. PingStatus=Online avant tout start-session / send-command.
3. Paramètres lab sous /lab/... ; jamais de secret en clair dans Git ou User Data.
4. Pas de port 22 ouvert « pour dépanner » — corrigez IAM/endpoints à la place.
5. delete-parameter + terminer l’EC2 lab ; désactivez session logging S3 si activé pour le test.

Documents SSM utiles (Associate)

Document	Usage
AWS-RunShellScript	Scripts one-shot
AWS-StartPortForwardingSession	Accès RDS privée
Patch baselines AWS	Départ Patch Manager

Plan de contrôle = IAM + documents ; plan de données = agent sur l’instance.

Quiz (5 questions)

1. Session Manager permet surtout de :
– A. Ouvrir 22 à Internet
– B. Administrer sans SSH public
– C. Remplacer S3

2. SecureString Parameter Store :
– A. Est toujours public
– B. Est chiffré via KMS
– C. Remplace ACM

3. Run Command sert à :
– A. Uniquement supprimer des VPC
– B. Exécuter des documents/scripts sur des instances managées
– C. Facturer Spot

4. Sans NAT en subnet privé, Session Manager exige surtout :
– A. Une EIP publique sur chaque EC2
– B. Des VPC endpoints ssm / ssmmessages / ec2messages
– C. Un Classic Load Balancer

5. get-parameters-by-path /lab/app sert surtout à :
– A. Supprimer le VPC
– B. Lister la hiérarchie de config sous un préfixe
– C. Remplacer Route 53

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

• Session Manager
• Parameter Store
• Run Command
• VPC endpoints for SSM
• Patch Manager
• Session logging

Maillage série AWS (P1)

← Précédent	CloudWatch
→ Suivant	Lambda + API Gateway
Aussi	IAM · EC2

---

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