Optimisation des coûts AWS : économisez 30 à 50 % sur votre facture d'infrastructure cloud

Réduisez les coûts AWS de 30 à 50 % grâce à des stratégies de dimensionnement approprié, d'instances réservées, d'instances ponctuelles, de mise à l'échelle automatique et d'optimisation du stockage pour les applications Web et les ERP.

E
ECOSIRE Research and Development Team
|16 mars 20268 min de lecture1.8k Mots|

Optimisation des coûts AWS : économisez 30 à 50 % sur votre facture d'infrastructure cloud

L'organisation moyenne gaspille 32 % de ses dépenses cloud en ressources inutilisées ou surprovisionnées. Pour une entreprise dépensant 5 000 $ par mois sur AWS, cela représente 19 200 $ par an gaspillés. L’optimisation des coûts du cloud ne consiste pas à rogner sur les raccourcis : il s’agit plutôt de payer uniquement pour ce que vous utilisez réellement.

Ce guide couvre l'ensemble des stratégies de réduction des coûts AWS, depuis les gains rapides qui permettent d'économiser de l'argent ce mois-ci jusqu'aux changements architecturaux qui aggravent les économies au fil du temps.

Points clés à retenir

  • Le dimensionnement à lui seul permet d'économiser 20 à 40 % en faisant correspondre les types d'instances à l'utilisation réelle des ressources.
  • Les instances réservées et les plans d'économies offrent des remises de 30 à 60 % pour les charges de travail prévisibles.
  • Les instances Spot réduisent les coûts de calcul de 60 à 90 % pour les charges de travail tolérantes aux pannes
  • Les politiques de cycle de vie du stockage empêchent les coûts S3 d'augmenter indéfiniment

Le cadre d'optimisation des coûts

Ordre prioritaire

Optimisez dans cet ordre pour un retour sur investissement maximal avec un minimum d'effort :

  1. Éliminer le gaspillage (immédiat, sans risque)
  2. Instances de bonne taille (1 à 2 semaines, faible risque)
  3. Utiliser des modèles de tarification (plans réservés, spot, plans d'épargne)
  4. Optimiser l'architecture (mois, nécessite une ingénierie)

Étape 1 : Éliminer les déchets

Rechercher les ressources inutilisées

# Find unattached EBS volumes (you are paying for storage with no use)
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType}' \
  --output table

# Find unused Elastic IPs
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocationId:AllocationId}' \
  --output table

# Find idle load balancers (no targets)
aws elbv2 describe-target-groups \
  --query 'TargetGroups[*].{ARN:TargetGroupArn,Name:TargetGroupName}' \
  --output table

# Find stopped instances still consuming EBS
aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=stopped \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,Type:InstanceType,StopTime:StateTransitionReason}' \
  --output table

Sources de déchets courantes

Source de déchetsCoût mensuel typiqueCorriger
Volumes EBS non attachés10-100 $ par volumeSupprimer ou prendre un instantané et supprimer
Instances arrêtées avec EBS20-200 $ par instanceTerminer ou créer AMI
IP Elastic inutilisées3,60 $ chacunLibération
Anciens instantanés0,05 $/GoPolitique de cycle de vie
Passerelles NAT surdimensionnées32 $+ par passerelleConsolider, utiliser les points de terminaison d'un VPC
Instances RDS inactives50-500$+Arrêter ou mettre fin aux instances de développement

Étape 2 : Redimensionnement approprié

Analyser l'utilisation réelle

# Get average CPU utilization over the last 14 days
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average Maximum \
  --output json

Matrice de décision de dimensionnement approprié

Processeur moyenCPU de pointeActions
<10%<30%Réduire la taille en 2 étapes (par exemple, xlarge à moyen)
10-30%<60%Réduire la taille d'une étape (par exemple, xlarge à large)
30-60%<80%Taille actuelle appropriée
>60%>80%Envisagez une migration ou une mise à l'échelle automatique

Optimisation des types d'instances

Instance actuelleDe bonne tailleÉconomies mensuelles
m5.xlarge (140 $)m5.large (70 $)70 $ (50%)
r5.2xlarge (365 $)r6g.xlarge (146 $)219 $ (60%)
t3.large (60 $)t3.moyen (30 $)30 $ (50%)
c5.xlarge (124 $)c6g.large (62 $)62 $ (50 %)

Le passage aux instances Graviton (ARM) (r6g, c6g, m6g) permet de réaliser des économies supplémentaires de 20 % avec des performances égales ou supérieures pour la plupart des charges de travail.


Étape 3 : Modèles de tarification

Instances réservées et plans d'épargne

FonctionnalitéInstances réservéesCalculer les plans d'épargnePlans d'épargne EC2
Remise30-60%30-54%40-60%
FlexibilitéType/région d'instance spécifiqueToute famille/région d'instanceFamille/région de cas spécifique
Engagement1 ou 3 ans1 ou 3 ans1 ou 3 ans
Idéal pourCharges de travail stables et prévisiblesCharges de travail mixtesFamilles de circonstances spécifiques

Recommandation : Commencez par des plans d'économies de calcul pour plus de flexibilité. Engagez-vous à respecter l'utilisation de base minimale dont vous avez confiance.

Instances ponctuelles

Les instances ponctuelles offrent des réductions de 60 à 90 %, mais peuvent être interrompues avec un préavis de 2 minutes.

Convient pour :

  • Exécuteurs de build CI/CD
  • Traitement par lots et pipelines de données
  • Environnements de développement et de staging
  • Serveurs Web sans état derrière un équilibreur de charge (avec repli à la demande)

Pas bon pour :

  • Bases de données
  • Applications à instance unique
  • Charges de travail avec état sans point de contrôle
# Launch template with Spot Instance
Resources:
  SpotFleet:
    Type: AWS::EC2::SpotFleet
    Properties:
      SpotFleetRequestConfigData:
        AllocationStrategy: lowestPrice
        TargetCapacity: 5
        LaunchSpecifications:
          - InstanceType: t3.large
            ImageId: ami-0123456789abcdef0
          - InstanceType: t3.xlarge
            ImageId: ami-0123456789abcdef0
          - InstanceType: m5.large
            ImageId: ami-0123456789abcdef0

Étape 4 : Optimisation du stockage

Politiques de cycle de vie S3

{
  "Rules": [
    {
      "ID": "ArchiveOldBackups",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "backups/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        },
        {
          "Days": 365,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 730
      }
    }
  ]
}

Tarification de la classe de stockage S3

Classe de stockagePrix ​​par Go/moisRécupérationIdéal pour
Norme0,023 $InstantanéDonnées actives
Norme-IA0,0125 $Instantané (récupération de 0,01 $/Go)Accès mensuel
Glacier instantané0,004 $Instantané (récupération de 0,03 $/Go)Accès trimestriel
Glaciers0,004 $1-12 heuresAccès annuel
Archives approfondies0,00099 $12 heuresConformité, à long terme

Optimisation EBS

# Convert gp2 volumes to gp3 (20% cheaper, better performance)
for vol_id in $(aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 --query 'Volumes[*].VolumeId' --output text); do
  echo "Converting $vol_id from gp2 to gp3"
  aws ec2 modify-volume --volume-id "$vol_id" --volume-type gp3
done

Étape 5 : mise à l'échelle automatique

Mise à l'échelle basée sur la planification

La plupart des applications B2B voient 70 % de trafic en moins en dehors des heures de bureau :

# Scale down at night
aws autoscaling put-scheduled-action \
  --auto-scaling-group-name production-asg \
  --scheduled-action-name scale-down-night \
  --recurrence "0 20 * * 1-5" \
  --desired-capacity 2 \
  --min-size 1

# Scale up in the morning
aws autoscaling put-scheduled-action \
  --auto-scaling-group-name production-asg \
  --scheduled-action-name scale-up-morning \
  --recurrence "0 7 * * 1-5" \
  --desired-capacity 5 \
  --min-size 3

Planification de l'environnement de développement

Arrêtez les environnements hors production en dehors des heures de travail :

# Stop dev/staging instances at 7 PM
aws ec2 stop-instances --instance-ids i-dev123 i-staging456

# Start at 8 AM
aws ec2 start-instances --instance-ids i-dev123 i-staging456

Économies mensuelles : exécuter des instances de développement 10 heures/jour au lieu de 24 permet d'économiser 58 %.


Liste de contrôle pour l'examen mensuel des coûts

  • Examinez AWS Cost Explorer pour détecter les anomalies
  • Vérifier les ressources inutilisées (volumes, IP, instantanés)
  • Valider les recommandations de bon dimensionnement (AWS Compute Optimizer)
  • Examiner la couverture de l'instance réservée/du plan d'épargne
  • Vérifier la croissance du stockage S3 et l'efficacité de la politique de cycle de vie
  • Vérifiez les coûts de transfert de données (souvent 10 à 15 % de la facture totale)
  • Vérifier que les seuils de mise à l'échelle automatique correspondent aux modèles de trafic actuels
  • Rechercher les ressources orphelines des déploiements ayant échoué

Questions fréquemment posées

Quel est le gain le plus rapide en matière de réduction des coûts AWS ?

Supprimez les ressources inutilisées. La plupart des comptes AWS disposent de centaines de dollars par mois en volumes EBS non attachés, en adresses IP Elastic inutilisées, en anciens instantanés et en instances arrêtées. Cela prend moins d’une heure et permet d’économiser de l’argent immédiatement. La deuxième victoire la plus rapide consiste à convertir les volumes EBS gp2 en gp3 – des performances identiques ou supérieures à un coût inférieur de 20 %.

Devrions-nous utiliser des Savings Plans ou des instances réservées ?

Calculez les plans d’épargne pour la plupart des entreprises. Ils offrent des remises comparables aux instances réservées mais avec plus de flexibilité : vous n'êtes pas limité à un type d'instance spécifique. Utilisez les instances réservées EC2 uniquement lorsque vous êtes certain des types d'instances pendant 1 à 3 ans.

Comment suivre les coûts AWS par projet ou par équipe ?

Utilisez les balises de ressources AWS. Marquez chaque ressource avec les balises project, team, environment et cost-center. Activez les balises de répartition des coûts dans la console de facturation. Créez des rapports Cost Explorer regroupés par balise pour voir les dépenses par projet. Appliquez le balisage avec les règles AWS Config qui signalent les ressources non balisées.

Le passage aux conteneurs est-il plus rentable ?

Les conteneurs améliorent l'utilisation des ressources de 30 à 50 % par rapport à l'exécution d'une application par serveur. ECS Fargate et EKS simplifient la gestion des conteneurs mais ajoutent une tarification par tâche. Pour la plupart des PME, EC2 avec Docker Compose offre le meilleur équilibre entre simplicité et coût. Consultez notre Guide de déploiement Docker pour plus de détails sur la mise en œuvre.


Ce qui vient ensuite

L'optimisation des coûts est une pratique continue et non un projet ponctuel. Planifiez des révisions mensuelles des coûts et intégrez la surveillance des coûts dans votre configuration d'alerte de production. Pour connaître la stratégie d'infrastructure complète, consultez notre guide DevOps pour les petites entreprises.

Contactez ECOSIRE pour des conseils en optimisation des coûts AWS, ou explorez nos services d'assistance Odoo pour une infrastructure gérée avec optimisation des coûts intégrée.


Publié par ECOSIRE – aider les entreprises à optimiser leurs dépenses en infrastructure cloud.

E

Rédigé par

ECOSIRE Research and Development Team

Création de produits numériques de niveau entreprise chez ECOSIRE. Partage d'analyses sur les intégrations Odoo, l'automatisation e-commerce et les solutions d'entreprise propulsées par l'IA.

Discutez sur WhatsApp