Connaître les coûts

Ce que vous saurez faire

Avant qu’Amira déploie quoi que ce soit, le responsable du soutien pose deux questions : combien cela coûtera-t-il, et comment arrêter les frais? Répondez aux deux avec des chiffres et une liste de chaque ressource et de la façon de l’arrêter.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 50 minutes

Ce que vous devez savoir

• La conception minimale et ses ressources, dans Régions et types de services : exemple détaillé : la conception minimale d’Amira.
• L’identité et son rôle, dans Identité et secrets : exemple détaillé : l’identité et son rôle.
• Le Key Vault facultatif, dans Identité et secrets : exercice supplémentaire facultatif : la clé dans Key Vault.

Ce qu’il vous faut sur votre ordinateur

• Vos notes de l’exercice guidé de Régions et types de services et d’Identité et secrets. L’exercice du module les transforme en fichier.
• Le dossier de projet ~/projects/ticket-api à la fin du module 3. L’exercice du module y ajoute docs/cloud-design.md. Si le dossier manque, copiez l’instantané end-of-m03, comme dans Utiliser un instantané.
• Python 3, pour un calcul facultatif.
• Aucun compte Azure. Les sorties Azure sont des sorties réelles, tirées de l’exécution réelle.

Les prix viennent de l’API Azure Retail Prices : région canadacentral, dollars américains, paiement à l’utilisation. Les prix changent : consultez la page actuelle avant de déployer. Les étapes Azure ont été exécutées avec Azure CLI 2.88.0 et l’extension containerapp 1.3.0b5, dans la région canadacentral.

Ce qui peut entraîner des frais

Sur votre ordinateur, un conteneur qui fonctionne tout le mois coûte seulement de l’électricité. Dans le nuage, chaque ressource possède un ou plusieurs compteurs : des éléments qu’Azure compte et facture. Ils se répartissent en quelques catégories :

Type de frais	Élément compté	Exemple dans la conception
Existence	Durée d’existence de la ressource, utilisée ou non	Le registre : par jour
Calcul	Durée d’exécution d’une copie de l’application, selon son processeur et sa mémoire	L’application conteneurisée : par vCPU-seconde et par Gio-seconde
Requêtes	Nombre de requêtes	L’application conteneurisée : par million de requêtes
Stockage	Go conservés, par mois	Le registre : images au-delà du stockage inclus
Données sortantes	Go qui quittent Azure vers Internet	Réponses aux clients
Journaux	Go de journaux recueillis	L’espace de travail Log Analytics

Une réplique est une copie en cours d’exécution du conteneur de l’application. L’application conteneurisée facture le calcul seulement pendant qu’au moins une réplique fonctionne. Les données sortantes quittent le réseau du fournisseur, par exemple les réponses envoyées à vos clients. Les données entrantes sont gratuites, et les 100 premiers Go de données sortantes par mois sont gratuits. Une petite API comme celle-ci reste bien en dessous de cette limite.

Voici les prix des ressources de la conception :

Compteur	Prix
Container Registry, Basic	0,1666 $ US par jour (environ 5 $ US par mois), tant que le registre existe, même si rien ne l’utilise
Container Registry, données stockées au-delà du stockage inclus dans Basic (10 Gio)	0,10 $ US par Go par mois
Container Apps, vCPU actif	0,000034 $ US par vCPU-seconde
Container Apps, mémoire active	0,000004 $ US par Gio-seconde
Container Apps, vCPU inactif (seulement avec un minimum d’une réplique ou plus)	0,000004 $ US par vCPU-seconde
Container Apps, requêtes	0,40 $ US par million
Log Analytics, données recueillies	les 5 premiers Go par mois pour chaque compte de facturation sont gratuits, puis 2,76 $ US par Go
Key Vault (facultatif), opérations	0,03 $ US par 10 000

Container Apps offre aussi un quota gratuit. Chaque mois civil, chaque abonnement reçoit gratuitement 180 000 vCPU-secondes, 360 000 Gio-secondes et 2 millions de requêtes. Une révision sans réplique n’entraîne aucun frais de calcul, et les requêtes des sondes de santé de la plateforme ne sont pas facturées.

Si vous n'avez pas encore de compte Azure

Le compte gratuit Azure offrait 200 $ US de crédit à utiliser en 30 jours et exige une carte de crédit. Azure for Students offrait 100 $ US de crédit pour 12 mois, sans carte, aux universitaires à temps plein ayant un courriel scolaire. Le crédit est de l’argent qu’Azure paie pour vous : les compteurs ci-dessus continuent de compter. Lisez les conditions actuelles avant de vous inscrire. Utilisez le parcours simulé du module 5 si vous préférez ne pas vous inscrire.

La carte des coûts de la conception de l'exercice. Chaque ressource facture un élément différent et possède sa propre façon d'arrêter les frais.

Description textuelle du diagramme

Le groupe de ressources rg-ticket-api-practice contient six ressources. Le registre ticketapi4821 facture 0,1666 $ US par jour tant qu’il existe, même quand rien ne l’utilise. Pour arrêter les frais, supprimez-le. L’application conteneurisée ticket-api facture le processeur et la mémoire par seconde pendant qu’une réplique fonctionne. Elle facture aussi les requêtes, au-delà du quota mensuel gratuit. À zéro réplique, il n’y a aucun frais de calcul. Supprimer l’application arrête tout. L’espace de travail Log Analytics, créé automatiquement par l’environnement, facture les Go de journaux au-delà de 5 Go par mois. Supprimez-le. L’environnement cae-ticket-api n’a aucuns frais propres dans cette conception, et l’identité id-ticket-api ne coûte rien. Les deux sont supprimés avec le groupe. Le Key Vault facultatif facture par 10 000 opérations. Après sa suppression, il reste en suppression réversible pendant 90 jours. Il ne facture rien alors, mais conserve son nom jusqu’à sa purge. Hors du groupe, les 100 premiers Go de données sortantes vers Internet par mois sont gratuits. Un budget envoie seulement une alerte : il n’arrête ni ne supprime rien. Les données de coûts peuvent arriver avec 8 à 24 heures de retard.

Exemple détaillé : un mois de l’API de billets

Le responsable du soutien demande : « Si on la laisse fonctionner, combien coûte-t-elle par mois? » Amira calcule le pire cas simple, étape par étape. Une réplique fonctionne tout le mois, au tarif actif, avec 0,25 vCPU et 0,5 Gio.

Étape	vCPU	Mémoire
Secondes en 30 jours	30 x 24 x 3 600 = 2 592 000 s	2 592 000 s
Utilisation : taille x secondes	0,25 x 2 592 000 = 648 000 vCPU-s	0,5 x 2 592 000 = 1 296 000 Gio-s
Moins le quota gratuit	648 000 - 180 000 = 468 000 vCPU-s	1 296 000 - 360 000 = 936 000 Gio-s
Multiplié par le tarif actif	468 000 x 0,000034 = 15,91 $ US	936 000 x 0,000004 = 3,74 $ US

Calcul : 15,91 + 3,74 = environ 19,66 $ US par mois. Ajoutez le registre, environ 5 $ US. Les requêtes sont gratuites jusqu’à 2 millions, et les journaux d’une petite API restent sous 5 Go. Le fonctionnement « en continu » coûte donc environ 25 $ US par mois.

Vous pouvez vérifier la partie calcul avec une ligne de Python :

Terminal

python3 -c "print(round((0.25*2592000-180000)*0.000034 + (0.5*2592000-360000)*0.000004, 2))"

La sortie :

19.66

Voici les autres cas, avec la même méthode :

Réglage	Calcul par mois	Avec le registre
Minimum d’une réplique, occupée tout le mois (tarif actif)	19,66 $ US	environ 25 $ US
Minimum d’une réplique, inactive tout le mois (tarif inactif : 0,000004 $ US pour le vCPU et la mémoire)	5,62 $ US	environ 11 $ US
Minimum de zéro réplique (passage à zéro), aucune requête	0 $ US	environ 5 $ US
L’exercice : environ 1 heure, puis suppression du groupe	0 $ US (dans le quota gratuit)	quelques cents : au plus une journée du registre, 0,17 $ US

Voyez le quota gratuit autrement : 180 000 vCPU-secondes correspondent à 200 heures d’une réplique de 0,25 vCPU. Le quota couvre l’exercice plusieurs fois. Il ne couvre pas une application oubliée qui fonctionne tout le mois.

Passage à zéro et requêtes que vous n’avez pas envoyées

Le passage à zéro signifie que la plateforme arrête toutes les répliques quand aucune requête n’arrive. Elle en redémarre une quand une requête arrive. Par défaut, Container Apps attend 300 secondes (5 minutes) sans requête avant de passer à zéro. La première requête suivante attend qu’une réplique démarre. Cette attente est un démarrage à froid. Lors de l’exécution réelle, la première requête après le déploiement a pris 18 secondes. Les requêtes suivantes ont pris moins d’une seconde.

L’exécution réelle a aussi montré quelque chose qui surprend beaucoup de gens. Quelques minutes après l’obtention de l’adresse publique de l’application, des requêtes que personne dans l’équipe n’avait envoyées sont arrivées. En voici une, tirée du journal de l’application (réel) :

2026-10-07T16:17:06.5051432Z stdout F INFO:     100.100.0.60:49464 - "GET / HTTP/1.1" 404 Not Found

Personne dans l’équipe n’a appelé /. Ces requêtes viennent de programmes qui parcourent Internet à la recherche de nouvelles adresses. Elles sont arrivées à 16 h 17, 16 h 19 et 16 h 27. Chacune a réveillé l’application ou relancé l’attente de 300 secondes avant le passage à zéro. L’application avait une réplique de 16 h 23 jusqu’à au moins 16 h 31.

Le sans serveur n’est pas gratuit

« Sans serveur » donne l’impression qu’il n’y a rien à payer ni à configurer. Les deux idées sont fausses :

• Il facture pendant qu’une réplique fonctionne. Le passage à zéro aide seulement si le minimum est de zéro et que rien n’envoie de requêtes. Un minimum d’une réplique, pour éviter les démarrages à froid, entraîne des frais chaque seconde du mois.
• Il exige une configuration. Vous choisissez la taille de chaque réplique, le nombre minimal et maximal de répliques, le trafic entrant, les sondes et les réglages (module 5). Les valeurs par défaut ne sont pas choisies pour votre budget. Par exemple, le maximum par défaut est de 10 répliques. Le cours fixe ce maximum à 2 pour qu’une avalanche de requêtes ne puisse pas en démarrer 10.
• Les autres ressources facturent quand même. Le registre facture chaque jour, qu’il y ait zéro réplique ou non.

Les budgets alertent. Ils n’arrêtent rien.

Un budget est un montant que vous fixez pour un périmètre, comme un abonnement ou un groupe de ressources, pour un mois. Quand les coûts atteignent un pourcentage de ce montant, par exemple 80 %, Azure envoie une alerte par courriel.

Un budget n’arrête, ne limite ni ne supprime rien. La documentation de Microsoft le dit directement : lorsqu’un seuil budgétaire est dépassé, « les ressources ne sont pas touchées et votre consommation n’est pas arrêtée ». Azure recueille aussi les données de coûts avec un délai, habituellement de 8 à 24 heures. Il vérifie les budgets une fois toutes les 24 heures. L’alerte peut donc arriver un jour après la dépense. AWS Budgets et les budgets Google Cloud servent aussi d’abord à alerter. Pour arrêter quelque chose, vous devez ajouter votre propre action ou automatisation.

Vous pouvez créer un budget dans le portail Azure : ouvrez le groupe de ressources, sélectionnez Budgets (budgets), puis Add (ajouter). Indiquez un montant et une adresse courriel. Le cours ne teste pas cette étape, et le budget est facultatif. Créez-en un si votre abonnement sert à autre chose que cet exercice. Puis rappelez-vous encore la règle : le budget vous avertit. Seule la suppression des ressources arrête les coûts.

Étiquettes et piège

Une étiquette est une paire name=value (nom=valeur) que vous ajoutez à un groupe de ressources ou à une ressource, par exemple purpose=practice. Les rapports de coûts peuvent regrouper les coûts par étiquette, et vous pouvez chercher des ressources par étiquette.

Le piège est apparu pendant l’exécution réelle. Le groupe a été créé avec --tags purpose=practice course=C18. Plus tard, alors que toutes les ressources étaient encore dans le groupe, Amira a cherché par étiquette :

Terminal (Module 5)

az resource list --tag purpose=practice -o table

La sortie était vide. Les ressources étaient là. Les ressources n’héritent pas des étiquettes de leur groupe de ressources. Le groupe avait l’étiquette, mais pas ses ressources. Pour ajouter une étiquette à chaque ressource, indiquez-la dans chaque commande de création (--tags). Vous pouvez aussi utiliser une Azure Policy qui copie les étiquettes du groupe. Pour vérifier le nettoyage, ne vous fiez pas à une recherche par étiquette. Vérifiez le groupe lui-même avec az group exists et az resource list -g.

Un inventaire des ressources

Un inventaire liste chaque ressource d’un déploiement, ses frais possibles et la façon de l’arrêter. Il inclut les ressources qu’Azure a créées pour vous. Vous le rédigez avant le déploiement, à partir de la conception. Après le déploiement, vous le comparez à la liste réelle. Au nettoyage, vous cochez chaque ligne. Le module 5 l’utilise.

La colonne la plus importante est « Peut-elle entraîner des frais, et comment les arrêter? ». Trois ressources exigent de l’attention :

• L’espace de travail Log Analytics. Personne ne l’a demandé. az containerapp env create a affiché Generating a Log Analytics workspace with name "workspace-..." (création d’un espace de travail Log Analytics nommé « workspace-… ») et l’a créé. Si vous supprimez seulement l’application et l’environnement, l’espace de travail reste.
• Le registre. Il facture chaque jour, même sans application.
• Le Key Vault (facultatif). Après sa suppression, il reste en suppression réversible pendant 90 jours. Il ne facture rien, mais son nom reste réservé. az keyvault list-deleted l’affiche, et az keyvault purge --name kv-ticket-api-4821 le supprime.

Certains éléments n’apparaissent pas du tout dans az resource list : l’attribution de rôle et un coffre en suppression réversible. Inscrivez-les quand même dans l’inventaire.

Exercice guidé : chiffrer votre conception

1. Prenez la liste des ressources de votre conception dans l’exercice guidé de Régions et types de services.
2. Pour chaque ressource, notez le type de frais du premier tableau : existence, calcul, requêtes, stockage, données sortantes, journaux ou aucuns.
3. Calculez le coût de l’exercice : une heure avec une réplique, puis suppression du groupe. Le calcul reste-t-il dans le quota gratuit?
4. Calculez le mois avec un minimum d’une réplique, occupée tout le mois. Utilisez le tableau de l’exemple détaillé.
5. Notez quelle ressource continue de facturer si vous supprimez seulement l’application conteneurisée.

Afficher les réponses attendues

• Registre : existence (par jour) et stockage seulement au-delà de 10 Gio. Application conteneurisée : calcul et requêtes. Espace de travail : journaux. Environnement, identité, attribution de rôle : aucuns frais. Key Vault : requêtes au coffre (opérations).
• Une heure : 0,25 x 3 600 = 900 vCPU-s et 0,5 x 3 600 = 1 800 Gio-s. C’est bien en dessous du quota gratuit, donc le calcul coûte 0 $ US. L’exercice coûte au plus une journée du registre, soit 0,17 $ US.
• Un mois au tarif actif avec un minimum d’une réplique : environ 19,66 $ US de calcul, plus environ 5 $ US pour le registre.
• Si vous supprimez seulement l’application, le registre facture encore chaque jour. L’espace de travail peut encore facturer les journaux. Supprimez le groupe entier.

À vous de jouer : le responsable veut éviter le démarrage à froid

Le responsable du service de soutien dit : « 18 secondes pour la première requête, c’est trop lent. Gardez une réplique en marche. » Modifiez la conception pour cette seule condition. Qu’est-ce qui change dans le coût, et que dites-vous au responsable?

Afficher une réponse

Fixez le minimum à 1 réplique. L’application ne passe alors jamais à zéro réplique. Elle entraîne donc des frais chaque seconde du mois. Si elle reste inactive la plupart du temps, le tarif d’inactivité s’applique : environ 5,62 $ US par mois pour le calcul. Quand les requêtes la gardent occupée, le tarif actif s’applique, jusqu’à environ 19,66 $ US. Ajoutez le registre, environ 5 $ US. Donnez la fourchette au responsable : de 11 $ US à 25 $ US par mois, aux prix de cette leçon. Proposez une alerte budgétaire sur le groupe. Précisez aussi qu’un budget avertit seulement. Pour arrêter les coûts, quelqu’un doit réduire le minimum ou supprimer l’application.

Erreur courante

Le passage à zéro réplique est configuré, mais l'application ne passe pas à zéro

Symptôme : L’application a un minimum de 0 réplique. Personne dans l’équipe ne l’utilise. Pourtant, le nombre de répliques reste à 1, et les frais de calcul augmentent. Lors de l’exécution réelle, l’application avait une réplique de 16 h 23 à au moins 16 h 31. L’équipe n’avait envoyé aucune requête.

Cause : Des requêtes que vous n’avez pas envoyées. Une adresse publique reçoit des requêtes de programmes qui parcourent Internet. Par exemple, le journal contient GET / de 100.100.0.60. Chaque requête relance l’attente de 300 secondes avant le passage à zéro réplique. Le mode serverless (sans serveur) a fait son travail : il a exécuté l’application parce que des requêtes arrivaient.

Solution :

1. Cherchez dans le journal de l’application des requêtes que votre équipe n’a pas envoyées. Par exemple, des chemins absents de votre API.
2. Gardez un nombre maximal de répliques bas (2 dans le cours). Une rafale de ces requêtes ne pourra pas démarrer beaucoup de répliques.
3. Pour un déploiement d’exercice, supprimez le groupe de ressources dès que vous avez vos preuves. Rien ne pourra alors réactiver l’application.
4. Pour un vrai service, ces requêtes sont normales. Incluez-les dans l’estimation. Assurez-vous que chaque point de terminaison qui entraîne des frais exige la clé d’API.

Pour un vrai service d’IA, c’est encore plus important. Un point de terminaison de modèle accessible à tous peut générer une grosse facture. Protégez-le avec une clé, limitez les répliques et surveillez les coûts.

Exercice du module

Exercice guidé → tâche autonome. Les exemples détaillés de ce module ont construit la conception d’Amira étape par étape. Rédigez maintenant votre propre conception pour le déploiement d’exercice, dans un fichier du projet. Le module 5 s’appuie sur ce fichier.

1. Dans ~/projects/ticket-api, créez le dossier docs et le fichier docs/cloud-design.md.
2. Rédigez une section Besoins du service : chaque besoin, son service de base et sa ressource Azure, selon vos notes de la leçon 1.
3. Indiquez la région et le groupe de ressources, avec les étiquettes.
4. Rédigez Identité et accès, selon votre plan d’accès de la leçon 2. Précisez que le compte administrateur du registre reste désactivé.
5. Rédigez Paramètres et secrets : chaque paramètre, sa valeur, son caractère secret ou non et son emplacement. N’écrivez pas la clé elle-même.
6. Rédigez les paramètres de calcul et une estimation des coûts : pour l’exercice et pour une réplique en marche tout le mois.
7. Rédigez l’inventaire des ressources, avec une colonne « Peut-elle entraîner des frais, et comment les arrêter? ». Incluez les ressources que vous n’avez pas créées vous-même et celles que az resource list n’affiche pas.
8. Rédigez les décisions : ce que vous avez exclu, et pourquoi.

Vérifiez votre fichier avec ces questions : permet-il à quelqu’un qui n’a pas lu ce module de tout supprimer? Nomme-t-il chaque ressource qui peut entraîner des frais? Contient-il une valeur secrète?

Afficher le corrigé : docs/cloud-design.md

docs/cloud-design.md

# Cloud design: ticket-api practice deployment

A minimal design to run `ticket-api:1.1.0` on Azure Container Apps for one practice session, then delete everything. Written before the deployment (Module 4). Module 5 builds it, and `DEPLOY.md` records what was made and removed.

Prices from the Azure Retail Prices API, canadacentral, USD, pay-as-you-go. Check the current prices before you deploy.

## What the service needs

| Need | Building block | Azure resource |
|---|---|---|
| Run the container from the image | Serverless containers | Container app `ticket-api` in the environment `cae-ticket-api` |
| A place for the image | Container registry | `ticketapi4821` (Basic) |
| A public HTTPS address | HTTPS ingress | The app's ingress: external, target port 8000 |
| Settings | The app's configuration | `REQUIRE_API_KEY=true`, `SHOW_DOCS=false` |
| The API key | A secret | Container Apps secret `api-key`, used as `API_KEY=secretref:api-key` |
| Permission to pull the image | A managed identity | `id-ticket-api` (user-assigned), role AcrPull on the registry |
| Logs | A log store | Log Analytics workspace (made automatically by the environment) |
| History records | Managed PostgreSQL | None: left out on purpose (see Decisions) |

## Region and resource group

- Region: `canadacentral` (the course's region; use the nearest region that has Container Apps). Every resource is in the same region.
- Resource group: `rg-ticket-api-practice`, tags `purpose=practice` and `course=C18`. Every resource goes in this group, so one delete removes them all.

## Identity and access

| Identity | Role | Scope | Why |
|---|---|---|---|
| Me (the person who deploys) | Owner or Contributor | My subscription, or only the practice group | Create and delete the practice resources |
| `id-ticket-api` | AcrPull | The registry `ticketapi4821` only | Pull the image, nothing more (least privilege) |

The registry's admin user stays **off**. No registry password exists in this design.

## Settings and secrets

| Name | Value | Secret? | Where |
|---|---|---|---|
| `API_KEY` | A new random key, made for this deployment | Yes | Container Apps secret `api-key`, referenced with `secretref:` |
| `REQUIRE_API_KEY` | `true` | No | Environment variable: without a key, the app does not start |
| `SHOW_DOCS` | `false` | No | Environment variable |
| `DATABASE_URL` | not set | (would be a secret) | Not used: history is off |

The key is never in the image, in Git, in a plain environment variable or in this file. Optional stretch: keep the key in a Key Vault (`kv-ticket-api-4821`) and reference it with `keyvaultref:` and `identityref:`; the identity then also gets Key Vault Secrets User on that vault only.

## Compute settings

0.25 vCPU and 0.5 GiB for each replica, minimum 0 replicas (scale to zero), maximum 2 replicas. The maximum is a cost limit as well as a scale limit.

## Cost estimate

| Case | Estimate |
|---|---|
| The practice: about 1 hour, then delete the group | A few cents: at most one day of the registry (US$0.17). The compute, the requests and the logs stay inside the monthly free amounts. |
| One replica running all month at the active rate | 648,000 vCPU-s - 180,000 free = 468,000 x US$0.000034 = US$15.91; 1,296,000 GiB-s - 360,000 free = 936,000 x US$0.000004 = US$3.74; total about **US$19.66** a month, plus the registry, about US$5. |
| The same with scale to zero and no traffic | US$0 for compute, plus the registry, about US$5 a month. |

Serverless is not free: it charges while a replica runs, and requests that I did not send can start a replica.

## Resource inventory

| Resource | Type | Made by | Can it charge? | How do I stop it? |
|---|---|---|---|---|
| `rg-ticket-api-practice` | Resource group | Me | No (it is a folder) | `az group delete --name rg-ticket-api-practice --yes`; this deletes everything in it |
| `ticketapi4821` | Container registry, Basic | Me | **Yes**: US$0.1666 a day while it exists, even if nothing uses it; storage above the 10 GiB included | Delete the registry (or the group) |
| `id-ticket-api` | User-assigned managed identity | Me | No | Delete it (or the group) |
| AcrPull for `id-ticket-api` on the registry | Role assignment | Me | No. Not listed by `az resource list` | Nothing to stop: Azure removes it with the registry and the identity (checked with `az role assignment list --all`). It is listed here so that I know it exists |
| `cae-ticket-api` | Container Apps environment (Consumption) | Me | No charge of its own in this design | Delete it (or the group) |
| `workspace-rgticketapipractice...` | Log Analytics workspace | **The environment, automatically** | **Yes**: per GB of logs above 5 GB a month (US$2.76 per GB) | Delete it (or the group). I did not ask for it, so I must look for it |
| `ticket-api` | Container app | Me | **Yes**: vCPU-seconds and GiB-seconds while a replica runs, and requests, above the monthly free grant | Scale to zero stops the compute charge; delete it (or the group) to stop everything |
| Data out to the internet | Egress | Responses to clients | Only above 100 GB a month | Delete the app |
| Optional: `kv-ticket-api-4821` | Key Vault | Me | **Yes**, a little: US$0.03 per 10,000 operations | Delete it (or the group), then `az keyvault purge --name kv-ticket-api-4821`. A deleted vault is soft-deleted for 90 days: no charge, but its name stays taken |
| Optional: a budget on the group | Cost Management budget | Me | No. It only sends an alert; it does not stop anything | Delete it after the practice |
| On my computer: the pushed image tags and the registry login | Local images, Docker credentials | Me | No | `docker image rm ticketapi4821.azurecr.io/ticket-api:1.1.0`, `docker logout ticketapi4821.azurecr.io` |

Checks after the clean-up: `az group exists --name rg-ticket-api-practice` returns `false`, and `az keyvault list-deleted` does not list the vault. Note: `az resource list --tag purpose=practice` is **not** a check, because the resources do not inherit the group's tag: it returned nothing even while the group still held its resources.

## Decisions

- **No database.** A managed PostgreSQL server charges for every hour that it exists. Without `DATABASE_URL`, the API classifies normally, and `/v1/history` returns `503 history_unavailable`. A real service adds Azure Database for PostgreSQL flexible server, in the same region, with `DATABASE_URL` as a secret.
- **No custom domain, no private network, no availability zones.** The platform's address and HTTPS are enough for a practice service.
- **No data that matters.** The practice uses a new key and test tickets only, and the service is deleted the same day.

Votre fichier peut utiliser d’autres mots et un autre ordre. Il est complet si son inventaire contient chaque ressource et une façon d’arrêter chacune. Vérifiez l’espace de travail créé par l’environnement, l’attribution de rôle et le coffre supprimé de façon réversible. Le fichier ne doit contenir aucune valeur secrète.

Vérification du module

Vérifiez votre compréhension

Rappel : qu'est-ce qu'un budget dans Azure, et que fait-il quand les coûts le dépassent?

Afficher la réponse

Un budget est un montant que vous fixez pour une portée et une période. La portée peut être un abonnement ou un groupe de ressources. La période est généralement un mois. Quand les coûts réels ou prévus atteignent un pourcentage choisi, Azure envoie une alerte, par exemple un courriel. Le budget n’arrête, ne limite et ne supprime rien : les ressources continuent de fonctionner et d’entraîner des frais. Les données de coûts peuvent aussi arriver avec un retard de 8 à 24 heures. Seule la suppression ou la modification des ressources arrête les coûts.

Vérifiez votre compréhension

Prédiction : Amira supprime l'application conteneurisée et l'environnement, mais pas le groupe de ressources. Deux semaines plus tard, que reste-t-il sur la facture, et pourquoi?

Afficher la réponse

Le registre : il coûte 0,1666 $ US par jour tant qu’il existe. Cela donne environ 2,33 $ US pour 14 jours, même sans application. L’espace de travail Log Analytics existe aussi encore. L’environnement l’a créé comme ressource distincte, et supprimer l’environnement ne le supprime pas. Il entraîne des frais seulement au-delà de 5 Go de journaux par mois, donc presque rien actuellement. Mais Amira doit encore se souvenir de cette ressource. L’identité ne coûte rien, mais elle est toujours là. Supprimer le groupe entier aurait tout retiré d’un coup.

Vérifiez votre compréhension

Vérification finale : listez chaque ressource de la conception qui pourrait encore entraîner des frais ou rester après l'exercice. Dites comment arrêter chacune.

Afficher la réponse

L’application conteneurisée ticket-api : le calcul pendant qu’une réplique fonctionne, et les requêtes. Le passage à zéro réplique arrête les frais de calcul; supprimer l’application arrête tous les frais. Le registre ticketapi4821 : chaque jour tant qu’il existe; supprimez-le. L’espace de travail Log Analytics créé automatiquement par az containerapp env create : par Go de journaux au-delà de 5 Go par mois; supprimez-le. Si vous l’avez créé, le coffre Key Vault : par tranche de 10 000 opérations. Supprimez-le, puis purgez-le. Un coffre supprimé reste récupérable pendant 90 jours et conserve son nom, mais n’entraîne plus de frais. Le transfert de données sortantes au-delà de 100 Go par mois s’arrête avec l’application. L’environnement, l’identité et l’attribution de rôle n’entraînent pas de frais. Supprimer le groupe de ressources rg-ticket-api-practice retire tout, sauf le nom du coffre supprimé de façon réversible. Un budget, si vous en avez créé un, ne coûte rien et n’arrête rien. Vérifiez avec az group exists et az keyvault list-deleted, pas avec une recherche par étiquette.

Récapitulatif

Ce module a associé l’API de billets aux services de base du nuage, avant de créer quoi que ce soit :

• Tous les nuages ont les mêmes services de base : calcul, stockage, bases de données, réseau et services gérés. Choisissez la région selon la distance, la résidence des données, le prix et les services offerts.
• Le mode sans serveur confie les serveurs au fournisseur. Votre image, ses paquets, vos paramètres, vos identités et le nettoyage restent votre responsabilité.
• Placez un déploiement d’exercice dans un seul groupe de ressources, pour tout retirer en une seule suppression.
• Donnez à l’application une identité gérée, avec le rôle minimal et la portée la plus restreinte (AcrPull sur un seul registre). Gardez la clé dans un secret de la plateforme ou dans Key Vault, jamais dans un paramètre ordinaire.
• Chaque ressource facture un élément différent : existence, calcul, requêtes, stockage, transfert sortant, journaux. L’exercice coûte quelques cents. Une application oubliée avec une réplique coûte environ 25 $ US par mois.
• Un budget envoie des alertes. Il n’arrête rien. Un inventaire des ressources indique comment arrêter chaque coût et inclut l’espace de travail que vous n’avez pas demandé.

Remise à zéro : ce module ne crée rien dans le nuage et ne modifie aucun code. Votre projet contient un nouveau fichier, docs/cloud-design.md. Pour recommencer, supprimez-le ou copiez l’instantané end-of-m04. Si vous avez créé une ressource Azure par vous-même pendant la lecture de ce module, supprimez maintenant son groupe de ressources.

Ensuite, vous réalisez la conception : vous envoyez l’image dans un registre et la déployez, sur Azure ou en simulation sur votre ordinateur.

Leçon suivante : Registre et déploiement