# Lab brief — investigate an ECS deployment regression / Énoncé de lab — enquêter sur une régression ECS

This exercise accompanies the CloudWatch Omni article and its editable AWS architecture diagram. It is a proposed staging lab, not a report of a deployed or measured experiment. The article contains the verified service capabilities, source links, collector configuration, and POC procedure. Use its source-check date when reviewing prerequisites; recheck AWS documentation before deploying.

## English

### Goal and prerequisites

Build an isolated staging environment in **one AWS account, in `eu-west-1`**, then investigate a controlled API latency regression. Explain which evidence supports the cause and which conclusions remain hypotheses. Use disposable resources and synthetic data only.

You need an AWS account with permission to provision the resources, a local AWS CLI with temporary credentials, a container build tool, and an infrastructure-as-code tool of your choice. Choose an explicit resource prefix and expiry date. Record the application image digest and infrastructure commit. A public HTTPS endpoint also requires an existing domain you control and an ACM certificate in the ALB’s Region; this repository connects no domain. Without that prerequisite, use an **internal HTTP ALB and a private test runner** with network access to it.

### Work to complete

1. **Create the network.** Use a VPC spanning two Availability Zones: public subnets for the internet-facing ALB and NAT gateway, private application subnets for Fargate, and private database subnets for the RDS subnet group. Route outbound application traffic through NAT and the internet gateway. For this disposable lab, one NAT gateway is a cost/resilience trade-off, not a high-availability recommendation. Restrict ALB ingress to your tester’s IP on HTTPS 443. Allow API port 8080 only from the ALB security group; allow PostgreSQL 5432 only from the task security group. Keep RDS non-public. Permit the task’s required outbound HTTPS traffic; add routes/security rules for the private-runner alternative if used.
2. **Deploy and instrument.** Create an ECR image, ECS cluster, Fargate service, ALB target group, and a small RDS PostgreSQL database. Require verified database TLS; store credentials in Secrets Manager, granting access only to the selected secret. Give the API a `/health` endpoint and one database-backed request path. Run the CloudWatch agent sidecar at version `1.300071.0` or later. Send OTLP to `localhost:4317` or `localhost:4318`, keeping these ports private to the task. Export to AWS over HTTPS with SigV4 and temporary task-role credentials. Use `CloudWatchAgentServerPolicy` as the documented telemetry prerequisite on the task role; review and scope permissions to the lab. Keep the execution role for ECR/container logs separate, adding secret access to the role that actually retrieves it.
3. **Make releases observable.** Attach `service.name`, `service.version`, `deployment.environment.name`, and a consistent release/commit identifier. Capture structured logs, traces, application metrics, and relevant ECS/RDS metrics. Create the Omni space through AWS setup, then verify its Dataset integration and log/trace forwarding in the same account and Region; setup creates the integration automatically. Verify that one request can be followed through its release, application span, and PostgreSQL span before introducing a fault.
4. **Run the experiment.** Save a baseline using the article’s fixed workload. Deploy a staging-only release that executes `SELECT pg_sleep(0.25)` on the tested database path. Repeat the identical workload and record its timestamps. With AWS DevOps Agent linked and its permissions/access prerequisites met, start an Omni investigation manually with `/investigation`; do not assume an alarm starts it. Without this integration, compare telemetry manually and do not claim an agent investigation. Validate the explanation against traces and SQL behavior. Roll back to the baseline task-definition revision, restoring its environment, secrets/configuration and pinned image digest, then repeat the workload.
5. **Remove resources.** Delete the service, load balancer, database, NAT gateway/EIP, disposable images, log groups, test secrets, and lab-created spaces/integrations as appropriate. Review snapshots, retained data, ENIs, and stack deletion failures. Preserve shared resources and the account’s existing configuration.

### Acceptance and hand-in

Submit your IaC and pinned image digests, the adapted EN or FR draw.io diagram, a redacted evidence bundle for baseline/regression/rollback, and the cleanup record. The bundle must show release attribution, authenticated ingestion, a database child span, and workload comparability. Explain the limits of the evidence. If the injected delay is not visible, diagnose instrumentation before claiming a root cause. Report observed results only: this brief claims no latency, MTTR, or cost outcome. ALB, Fargate, RDS, NAT, and telemetry are billable; inspect the current AWS pricing and set a budget for your own configuration.

## Français

### Objectif et prérequis

Construire un staging isolé dans **un seul compte AWS, en `eu-west-1`**, puis enquêter sur une régression contrôlée de la latence d’une API. Expliquer quelles preuves soutiennent la cause et quelles conclusions restent des hypothèses. Utiliser uniquement des ressources jetables et des données synthétiques.

Il faut un compte AWS autorisé à créer les ressources, AWS CLI avec des identifiants temporaires, un outil de construction d’image et un outil d’infrastructure as code au choix. Fixer un préfixe de ressources et une date d’expiration. Conserver le digest de l’image et le commit d’infrastructure. Un endpoint HTTPS public exige aussi un domaine déjà contrôlé et un certificat ACM dans la région de l’ALB ; ce dépôt ne connecte aucun domaine. À défaut, utiliser un **ALB interne en HTTP et un générateur de charge privé** disposant d’un accès réseau à l’ALB.

### Travail demandé

1. **Créer le réseau.** Prévoir un VPC sur deux zones de disponibilité : sous-réseaux publics pour l’ALB exposé et la passerelle NAT, sous-réseaux applicatifs privés pour Fargate et sous-réseaux privés de base pour le groupe de sous-réseaux RDS. Faire sortir le trafic applicatif via NAT et l’internet gateway. Pour ce lab jetable, une seule NAT constitue un compromis coût/résilience, pas une recommandation de haute disponibilité. Limiter l’entrée HTTPS 443 de l’ALB à l’IP du testeur. Autoriser le port 8080 de l’API uniquement depuis le security group de l’ALB, et PostgreSQL 5432 uniquement depuis celui de la tâche. Garder RDS privé. Autoriser les sorties HTTPS nécessaires ; adapter routes et règles pour le générateur privé si cette variante est choisie.
2. **Déployer et instrumenter.** Créer l’image ECR, le cluster ECS, le service Fargate, le target group ALB et une petite base RDS PostgreSQL. Imposer TLS avec vérification du serveur ; stocker les identifiants dans Secrets Manager et limiter l’accès au secret choisi. Fournir `/health` et un chemin d’API interrogeant la base. Exécuter le sidecar CloudWatch agent en version `1.300071.0` ou ultérieure. Envoyer OTLP vers `localhost:4317` ou `localhost:4318`, sans exposer ces ports hors de la tâche. Exporter vers AWS en HTTPS avec SigV4 et les identifiants temporaires du rôle de tâche. Utiliser `CloudWatchAgentServerPolicy`, prérequis documenté de télémétrie du rôle de tâche, puis revoir et limiter les permissions au lab. Garder un rôle d’exécution séparé pour ECR/logs ; autoriser le secret au rôle qui le lit réellement.
3. **Rendre les releases observables.** Ajouter `service.name`, `service.version`, `deployment.environment.name` et un identifiant de release/commit constant. Collecter logs structurés, traces, métriques applicatives et métriques ECS/RDS pertinentes. Créer l’espace Omni via la configuration AWS, puis vérifier son intégration Dataset et le transfert des logs/traces dans le même compte et la même région ; cette configuration crée l’intégration automatiquement. Avant toute injection, suivre une requête depuis sa release jusqu’aux spans applicatif et PostgreSQL.
4. **Conduire l’expérience.** Conserver une baseline avec la charge fixe de l’article. Déployer une release réservée au staging qui exécute `SELECT pg_sleep(0.25)` sur le chemin testé. Rejouer la même charge et noter ses horaires. Avec AWS DevOps Agent relié et ses prérequis de permissions/d’accès satisfaits, démarrer manuellement l’investigation Omni avec `/investigation` ; ne pas supposer qu’une alarme la déclenche. Sans cette intégration, comparer les signaux manuellement sans revendiquer une investigation d’agent. Valider l’explication contre les traces et le comportement SQL. Restaurer la révision de task definition de baseline, ses variables, secrets/configuration et son digest d’image figé, puis rejouer la charge.
5. **Nettoyer.** Supprimer service, ALB, base, NAT/EIP, images jetables, groupes de logs, secrets de test et espaces/intégrations créés pour le lab selon le cas. Contrôler snapshots, données conservées, interfaces réseau et échecs de suppression. Préserver les ressources partagées et la configuration existante du compte.

### Critères de réussite et rendu

Rendre l’IaC et les digests figés, le draw.io EN ou FR adapté, des preuves expurgées pour baseline/régression/rollback et le compte rendu de nettoyage. Montrer l’attribution à la release, l’ingestion authentifiée, un span enfant PostgreSQL et la comparabilité de la charge. Expliquer les limites des preuves. Si le délai injecté est invisible, diagnostiquer l’instrumentation avant d’affirmer une cause. Ne rapporter que des résultats observés : cet énoncé ne revendique aucun résultat de latence, MTTR ou coût. ALB, Fargate, RDS, NAT et télémétrie sont facturables ; consulter les tarifs AWS actuels et fixer un budget pour la configuration retenue.