Environnements de préproduction sur AWS sans doubler la facture

La peur qu’un environnement de préproduction double la facture AWS vient du fait qu’on copie les mauvaises choses. Un environnement de préproduction utile copie l’architecture de la production — mêmes services, même topologie, même pipeline de déploiement — mais pas sa capacité ni sa disponibilité. Des instances plus petites, une AZ au lieu de trois, du calcul qui dort en dehors des heures de travail, du Spot là où l’interruption est sans conséquence, et des dates d’expiration fermes sur tout ce qui est expérimental placent normalement la préproduction bien sous le quart de la facture de production. Les environnements qui coûtent discrètement aussi cher que la production, ce sont ceux que personne n’a conçus; ils ont été clonés.

Ce qui se passe

Trois mécaniques de coût expliquent presque toutes les factures hors production gonflées.

Le calcul se facture à l’heure, qu’on s’en serve ou non. Une flotte de préproduction qui reflète la production tourne 168 heures par semaine pour servir peut-être 50 heures d’usage réel. L’arrêter les soirs et les fins de semaine retire environ 70 % de ses heures de calcul sans aucun impact sur les gens qui l’utilisent — c’est le plus gros levier, et c’est un pur horaire, aucune ingénierie.

La parité a été copiée à la mauvaise couche. Les bases Multi-AZ, les répartitions sur trois AZ et les passerelles NAT par AZ existent pour que la production survive aux pannes. La préproduction n’a pas besoin de survivre aux pannes; elle a besoin de se comporter comme la production pour les tests. Une AZ, une NAT (ou aucune, avec des points de terminaison VPC pour S3 et DynamoDB) et des bases Single-AZ préservent la parité de comportement tout en coupant la taxe de disponibilité. Les passerelles NAT méritent une mention spéciale : des frais horaires plus un tarif au Go traité, par passerelle, et une passerelle oubliée dans chacune de trois AZ est une ligne récurrente qui ne sert personne.

Rien n’expire par défaut. Les grappes de tests de charge, les piles de preuve de concept et les copies « temporaires » vivent éternellement, sauf si quelque chose les tue. Volumes, instantanés et vieilles AMI s’empilent derrière.

Notez ce qui n’est pas sur la liste : les données. La préproduction a normalement besoin de données à l’image de la production, à échelle réduite, anonymisées — ce qui réduit aussi le stockage et les temps de restauration.

Quoi vérifier en premier

• Ce que coûte la préproduction aujourd’hui : Cost Explorer filtré par votre étiquette d’environnement. Si vous ne pouvez pas filtrer par étiquette, c’est la trouvaille numéro un.
• Ce qui tourne à 3 h du matin un dimanche hors production, et pourquoi.
• Les indicateurs Multi-AZ sur les bases hors production, et le compte de passerelles NAT hors production.
• Tout ce qui est étiqueté (ou devinable comme) preuve de concept avec une date de création de plus de 60 jours.
• Si les types d’instances de préproduction ont été choisis ou hérités — une flotte de famille m qui flâne à 3 % de CPU répond à la question.

Comment vérifier

Mettez d’abord un chiffre dessus :

# Dépense du mois dernier pour l'étiquette d'environnement staging
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Tags":{"Key":"environment","Values":["staging"]}}' \
  --group-by Type=DIMENSION,Key=SERVICE

Puis trouvez le gaspillage toujours-allumé :

# Bases hors production en Multi-AZ (la taxe de haute dispo payée en préproduction)
aws rds describe-db-instances \
  --query 'DBInstances[?MultiAZ==`true`].[DBInstanceIdentifier,DBInstanceClass]'

# Passerelles NAT — chacune est un frais horaire toujours actif
aws ec2 describe-nat-gateways \
  --filter Name=state,Values=available \
  --query 'NatGateways[].[NatGatewayId,VpcId]'

# Volumes détachés laissés par des expériences supprimées
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,CreateTime]'

Billing and Cost Management > Cost Explorer, groupé par l’étiquette d’environnement, montre la tendance; calculator.aws chiffre la cible redessinée pour que l’économie soit un engagement, pas un espoir.

Le plan d’exécution

1. Étiqueter d’abord, sinon rien n’est mesurable. Une étiquette environment imposée sur chaque ressource, appuyée par une politique d’étiquettes. Une ligne de filtre dans Cost Explorer rembourse cet effort pour toujours.
2. Mettre le calcul à l’horaire des heures de travail. Arrêtez les instances EC2 et Aurora/RDS en dehors de 7 h à 19 h en semaine — des règles EventBridge Scheduler ou la solution AWS Instance Scheduler font toutes deux le travail. La mise en garde honnête : une instance RDS arrêtée redémarre automatiquement après sept jours, donc l’ordonnanceur doit la ré-arrêter, pas supposer qu’elle reste couchée.
3. Couper la taxe de disponibilité. Single-AZ pour les bases de préproduction, une seule passerelle NAT (ou des points de terminaison de passerelle VPC et aucune), pas de réplicas inter-régions. Gardez les versions de moteur et groupes de paramètres identiques à la production — c’est cette parité-là qui attrape les bogues.
4. Dimensionner pour le test, pas pour la foule. La préproduction sert une poignée d’ingénieurs, pas la clientèle. Deux tailles plus bas est la zone d’atterrissage habituelle; les instances à éclatement conviennent bien au profil oisif-presque-toute-la-journée. Montez temporairement pour les tests de charge, puis redescendez — la capacité est une location à l’heure, utilisez-la comme telle.
5. Faire tourner les paliers sans état sur Spot. Une interruption en préproduction coûte une reprise, pas des revenus. La mécanique pour mélanger le Spot sans se blesser est couverte dans instances mixtes Spot et On-Demand.
6. Donner une expiration à chaque expérience. Une étiquette expires et une Lambda planifiée qui signale (puis arrête, puis détruit) tout ce qui dépasse sa date. Brutal, et ça fonctionne.
7. Tenir les engagements loin du hors-production. Les Savings Plans et les instances réservées appartiennent aux socles stables de production; une flotte de préproduction à l’horaire et redimensionnée est exactement l’usage qu’on ne veut pas verrouiller. La logique de décision est dans la décision RI, Savings Plans et Spot.

Quand c’est la mauvaise approche

La semaine avant un grand lancement, un clone de préproduction à pleine échelle pour les tests de charge est de l’argent bien dépensé — bâtissez-le, testez, démontez. Les régimes de conformité qui exigent que la préproduction reflète les contrôles de production réduisent votre marge sur certains points. Et n’arrêtez pas à l’horaire un environnement que des partenaires externes ou des suites d’intégration automatisées frappent jour et nuit sans convenir des heures d’abord; l’économie ne vaut pas de devenir l’équipe dont l’environnement est toujours en panne.

Erreurs fréquentes

• Cloner la production avec Terraform en un après-midi et hériter du Multi-AZ, de trois passerelles NAT et de tailles d’instances de production que personne n’a réexaminées.
• Mettre les instances à l’horaire mais laisser les services chers toujours allumés — répartiteurs de charge oisifs, grappes ElastiCache surdimensionnées, tout ce qui est en capacité provisionnée.
• Casser la parité aux mauvais endroits : d’autres versions de moteur ou groupes de paramètres en préproduction, puis s’étonner que la production se comporte autrement.
• Oublier que les instances arrêtées facturent encore leurs volumes EBS — arrêter n’est pas supprimer, et les volumes d’expériences s’accumulent de toute façon.

Garder le contrôle

• Une revue Cost Explorer mensuelle de dix minutes sur le hors-production, groupée par service, avec le mois précédent comme référence.
• Des alertes budgétaires sur les comptes ou étiquettes de préproduction, réglées juste au-dessus de la dépense normale, pour que la dérive s’annonce elle-même.
• Les demandes de nouvel environnement passent par un gabarit avec horaire et expiration intégrés, pas des copies de production faites à la main.
• Un balayage trimestriel des volumes détachés, des instantanés vieillissants et des instances arrêtées-mais-jamais-détruites.

Une préproduction qui coûte le dixième de la production et attrape quand même les bogues, ce n’est pas un truc; c’est une décision de conception prise une fois et tenue par l’horaire. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.