Le Blog Amazon Web Services

Aperçu des coûts de transfert de données pour des architectures de référence

Lors de la conception de l’architecture d’une solution sur AWS, les coûts de transferts de données sont souvent négligés. Prendre en considération les transferts de données lors des choix d’architecture peut vous aider à réduire les coûts. Cet article vous aidera à identifier de potentiels frais de transferts que vous pourriez rencontrer en opérant votre application sur AWS. Les frais de service ne sont pas couverts dans cet article, mais doivent être considérés avec soin lors de la conception de toutes architectures.

Transfert de données entre AWS et internet

Il n’y pas de frais pour le transfert de données entrantes à travers tous les services et toutes les régions. Le transfert de données depuis AWS à destination d’Internet est facturé par service, avec des tarifs propres à chaque région. Vous pouvez vous référer aux pages de tarification pour chaque service -par exemple, la page de tarification pour Amazon Elastic Compute Cloud (Amazon EC2) – pour plus de détails.

Transfert de données dans AWS

Le transfert de données dans AWS peut venir d’une de vos applications à destination d’autres service AWS, ou peut être entre différents composants de votre application.

Transfert de données entre votre application et d’autres services AWS

Lorsque votre application accède à des services AWS, vous pouvez générer des coûts de transfert de données.

Accéder à des services dans la même région AWS

Si une internet gateway est utilisée pour accéder à la terminaison publique de services AWS dans la même région (Image1 – Modèle 1), il n’y a pas de coût de transfert de données Si une NAT gateway (passerelle NAT) est utilisée pour accéder au même service(Image 1 – Modèle 2), il y a un coût de traitement des données facturé (par Gigaoctet (Go)) pour les données transitant par la passerelle.

Image1. Accéder à un service AWS dans la même région.

Accéder à des services à travers une autre région AWS

Si votre application accède à des services à travers différentes régions (Image 2), il y a un coût de transfert de données à travers les régions. La facturation dépend des régions de source et de destination (comme décrit sur Amazon EC2 Data Transfer pricing page).

Image 2. Accéder à des services AWS dans différentes régions.

Transfert de données dans différents composants de votre application

Des coûts peuvent être appliqués si différents composants de votre application transfèrent des données. Ces coûts peuvent varier et dépendent de la localisation des composants.

Composants d’une application dans la même région AWS

Le transfert de données dans la même zone de disponibilité est gratuit. Afin d’obtenir une application en haute disponibilité il est nécessaire de la déployer sur plusieurs zones de disponibilités.

Envisageons une application composée de deux serveurs applicatifs utilisant Amazon EC2 ainsi qu’une base de données exécutée sur Amazon Relational Database service (Amazon RDS) pour MySQL (Image 3). Pour de la haute disponibilité, chaque serveur applicatif est déployé sur une zone de disponibilité (Availability Zone : AZ) différente. Ici, des coûts de transfert de données s’appliquent pour les communications entre les instances EC2. La facturation s’applique aussi au transfert de données entre Amazon EC2 et Amazon RDS. Consultez le guide de tarification Amazon RDS for MySQL pour plus de détails.

Image 3. Composants d’une application à répartir sur deux sones de disponibilité.

Afin de minimiser l’impact d’une défaillance d’une base de données, activer une configuration Multi-AZ dans Amazon RDS afin de déployer une instance de secours dans une autre zone de disponibilité. La réplication entre les instances primaires et de secours ne génèrent pas de coûts de transferts supplémentaires. Néanmoins, des coûts de transfert de données seront appliqués pour des consommateurs en dehors de la zone de disponibilité de l’instance primaire actuelle. Un modèle habituel est de déployer vos applications sur plusieurs VPCs dans votre réseau AWS. Les deux approches pour activer la communication VPC à VPC sont VPC peering (appairage) et AWS Transit Gateway. Le transfert de données à travers la connexion VPC appairée qui reste dans la même zone de disponibilité est gratuit. Le transfert de données à travers la connexion VPC appairée qui traverse des zones de disponibilités va générer des coûts de transfert de données pour le trafic entrant/sortant.

Image 4. Connexion en VPC peering

Transit Gateway peut interconnecter des centaines ou milliers de VPC (Figure 5). Les éléments de coûts pour Transit Gateway incluent un coût à l’heure pour chaque VPC attaché, AWS Direct Connect, ou AWS Site-to-Site VPN. Des coûts de traitement des données s’appliquent par chaque Gigaoctet (Go) envoyé à partir d’un VPC, Direct Connect, ou VPN vers Transit Gateway.

Image 5. VPC appairé en utilisant Transit Gateway dans la même région

Composants d’une application dans des régions AWS différentes

Si les composants d’une applications communiquent à travers plusieurs régions utilisant une connexion VPC appairée ou Transit Gateway, des coûts de transfert de données supplémentaires sont appliqués. Si les VPC sont appairés à travers les mêmes régions, des coûts standards de transfert de données inter-région seront appliqués.

Image 6. VPC appairé à travers deux régions

Pour les Transit Gateway appairées, des frais de transfert de données sont appliqués uniquement du côté appairé. Les coûts de transfert ne s’appliquent pas pour les données envoyées à partir d’un attachement d’appairage à une Transit Gateway. Les coûts de transfert de données pour cette connexion appairée à travers une région sont en addition et facturés à l’autre attachement (Image 7).

Image 7. Appairage Transit Gateway à travers deux régions

Transfert de données entre AWS et datacenter on-premises

Lorsque votre application a besoin d’accéder à des ressources dans votre datacenter un transfert de données va s’effectuer. Il existe deux options communément utilisées afin d’arriver à cette connectivité : VPN Site-to-Site et Direct Connect.

Transfert de données à travers AWS VPN Site-to-Site

Une option afin de connecter votre application à un réseau on-premises est d’utiliser un ou plusieurs VPN Site-to-Site (Image 8 – Modèle 1). Ces coûts incluent une facturation à l’heure pour la connexion et un coût pour les données transférées à partir de AWS. Référez-vous à la tarification de VPN Site-to-Site pour plus de détails. Une autre option afin de connecter plusieurs VPN à un réseau on-premises est d’utiliser VPN Site-to-Site connecté à Transit Gateway (Image 8 – Modèle 2). Le VPN Site-to-Site sera considéré comme un autre attachement à la Transit Gateway. La tarification standard pour Transit Gateway est appliquée.

Image 8. Architectures VPN Site-to-Site

Transfert de données à travers AWS Direct Connect

Direct Connect peut être utilisé afin de connecter des charges de travail dans AWS vers un réseau sur on-premises. Direct Connect implique un coût pour chaque heure dont le port de la connexion est utilisé ainsi que les coûts de transfert de données sortant de AWS. Les données transférées vers AWS est de 0$ par Go dans toutes les régions. Le coût de transfert des données dépend de la région source ainsi que la localisation du fournisseur Direct Connect. Direct Connect peut aussi se connecter à Transit Gateway (via Direct Connect Gateway) si plusieurs VPC doivent être connectés (Image 9). Direct Connect est considéré comme un autre attachement sur la Transit Gateway et les coûts standards de Transit Gateway s’appliquent. Référez-vous à la page tarifaire de Direct Connect pour plus de détails.

Image 9. Schéma Direct Connect

Une Direct Connect Gateway (passerelle Direct Connect) peut être utilisée afin de partager Direct Connect à travers de multiples régions. En utilisant la passerelle Direct Connect, des coûts de transfert sortant seront appliqués basés sur la région source ainsi que la localisation du Direct Connect (Image 10).

Image 10. Direct Connect Gateway

Conseils généraux

Les coûts de transfert de données sont basés sur la source, la destination, ainsi que la quantité de trafic. Voici quelques conseils généraux lorsque vous débutez la planification de votre architecture :

  • Eviter de router le trafic vers internet lors d’une connexion aux services AWS depuis AWS en utilisant les terminaisons VPC (VPC Endoint) :
    • Les passerelles de terminaison VPC autorisent les  communications vers Amazon Simple Storage service (S3) et Amazon DynamoDB sans entrainer de coûts de  transfert de données dans la même région.
    • Les VPC endpoints ou Private Link sont disponibles  pour certains  services AWS. Ce type de terminaison génère un coût horaire  ainsi que des coûts de transfert de données.
  • Utiliser Direct Connect au lieu d’Internet afin  d’envoyer des données sur un réseau cas d’usage métier (business case).
  • Le trafic en dehors d’une zone de disponibilité génère habituellement des coûts de transfert de données. Dans la mesure du possible, utiliser des ressources dans la même zone de disponibilité.
  • Le trafic qui traverse les limites d’une région  génère habituellement des coûts de transfert de données. Eviter les  transferts de données à travers des régions, à moins que le cas d’usage métier (business case) le requière.
  • Utiliser le Free Tier d’AWS. Dans  certaines conditions, il vous est possible d’essayer une application gratuitement.
  • Utiliser le Calculateur de tarification AWS afin de vous aider à estimer le coût de transfert de données pour votre solution.
  • Utiliser un tableau de bord afin de mieux visualiser  les coûts de transfert de données – ce workshop  vous  montre comment.

Conclusion

AWS met à disposition la capacité de déployer à travers de multiples zones de disponibilités et régions. Avec quelques clics, vous pouvez créer une application distribuée. A mesure que l’empreinte à travers AWS augmente, il est utile de comprendre les différents coûts de transferts de données qui peuvent s’appliquer. Cet article de blog vous fournit les informations afin de prendre une décision éclairée et d’explorer les différentes solutions d’architecture pour économiser sur les coûts de transfert de données

Article original écrit par Birender Pal, Sebastian Gorczynski, et Dennis Schmidt Solutions Architect et adapté en français par Nabil Sekher, Solutions Architect Specialist