Forums aux questions sur Elastic Load Balancing

Application Load Balancer est compatible avec les cibles dotées de tout système d'exploitation actuellement pris en charge par le service Amazon EC2.

Un Application Load Balancer prend en charge l'équilibrage de charge des applications utilisant les protocoles HTTP et HTTPS (HTTP sécurisé).

Oui. La prise en charge du protocole HTTP/2 est activée de manière native sur un équilibreur de charge d'application. Les clients compatibles avec le protocole HTTP/2 peuvent se connecter à un équilibreur de charge d’application via TLS.

Vous pouvez transférer le trafic de votre Network Load Balancer qui prend en charge PrivateLink et une adresse IP statique par zone de disponibilité, vers votre Application Load Balancer. Créez un groupe cible de type Application Load Balancer, enregistrez-y votre équilibreur de charge d’application et configurez votre Network Load Balancer pour qu'il transfère le trafic vers le groupe cible de type Application Load Balancer.

Vous pouvez effectuer un équilibrage de charge pour les ports TCP suivants : 1-65535.

Oui. WebSockets et Secure WebSockets sont pris en charge de manière native et prêts à l'utilisation sur un équilibreur de charge d'application.

Oui. La traçabilité des requêtes est activée par défaut dans Application Load Balancer.

Bien qu’il y ait des similitudes, les fonctions diffèrent entre ces deux types d’équilibreurs de charge. Les équilibreurs de charge d'application constituent la base de notre future plate-forme d'équilibrage de charge au niveau de l'application.

Oui.

Oui.

Non, les Application Load Balancer requièrent un nouvel ensemble d’interfaces de programmation d’application (API).

La console d'ELB vous permettra de gérer les équilibreurs de charge d'application et les équilibreurs de charge classiques depuis la même interface. Si vous utilisez l'interface de ligne de commande (CLI) ou un kit SDK, alors vous utiliserez un « service » différent pour les équilibreurs de charge d'application. Par exemple, dans l'interface de ligne de commande, vous décrirez vos équilibreurs de charge classiques à l'aide de « aws elb describe-load-balancers » et vos équilibreurs de charge d'application avec « aws elbv2 describe-load-balancers ».

Non, vous ne pouvez pas convertir un type de programme d'équilibrage de charge en un autre.

Oui. Vous pouvez passer d’un Classic Load Balancer à un Application Load Balancer en utilisant l’une des options présentées dans ce document.

Non. Si vous avez besoin des fonctionnalités de type Layer 4, nous vous recommandons d'utiliser un Network Load Balancer.

Oui, vous pouvez mapper le port HTTP 80 et le port HTTPS 443 à un seul et même équilibreur de charge d'application.

Oui. Pour obtenir un historique des appels d’API d’Application Load Balancer effectués sur votre compte, utilisez AWS CloudTrail.

Oui, vous pouvez mettre fin à une connexion HTTPS sur l'équilibreur de charge d'application. Vous devez installer un certificat de protocole SSL sur votre équilibreur de charge. L'équilibreur de charge utilise ce certificat pour mettre fin à la connexion, puis déchiffre les requêtes des clients avant de les envoyer aux cibles.

Vous pouvez utiliser AWS Certificate Manager pour allouer un certificat SSL/TLS ou vous procurer le certificat auprès d’autres sources en créant une demande de certificat, en la faisant signer par une autorité de certification et en chargeant le certificat à l’aide du service AWS Certification Manager ou du service AWS Identity and Access Management (IAM).

Un équilibreur de charge d'application est intégré à AWS Certificate Management (ACM). L'intégration à l’ACM simplifie la liaison d'un certificat à l'équilibreur de charge, ce qui facilite l'ensemble du processus de transfert SSL. L'achat, le chargement et le renouvellement des certificats SSL/TLS constituent un processus manuel, chronophage et complexe. Grâce à l'intégration d'ACM dans les équilibreurs de charge d'application, l'ensemble du processus a été abrégé et comprend seulement une demande de certificat SSL/TLS approuvé et la sélection du certificat ACM pour permettre sa mise en service avec l'équilibreur de charge.

Non, avec un équilibreur de charge d'application, seul le chiffrement est pris en charge vers les systèmes dorsaux.

SNI est automatiquement activé lorsque vous associez plus d'un certificat TLS avec le même écouteur sécurisé sur un équilibreur de charge. De même, le mode SNI d'un écouteur sécurisé est automatiquement désactivé lorsque vous n'avez qu'un seul certificat associé à un écouteur sécurisé.

Oui, vous pouvez associer plusieurs certificats d'un même domaine à un écouteur sécurisé. Par exemple, vous pouvez associer :

• Des certificats ECDSA et RSA
• Des certificats avec différentes tailles de clés (par exemple, 2K et 4K) pour des certificats SSL/TLS
• Des certificats de domaine unique, multi-domaines (SAN) et génériques

Oui, le protocole IPv6 est pris en charge avec un Application Load Balancer.

Vous pouvez configurer des règles pour chacun des écouteurs sur l’équilibreur de charge. Ces règles incluent des conditions, ainsi que des actions correspondantes si la condition est remplie. Les conditions prises en charge sont les suivantes : en-tête de l'hôte, chemin, en-têtes HTTP, méthodes, paramètres de requête et routage sans classes entre domaines (CIDR) de l'adresse IP source. Les actions prises en charge sont les suivantes : redirection, réponse fixe, authentification et transfert. Une fois la configuration terminée, le programme d'équilibrage de charge utilise les règles pour déterminer le mode d'acheminement d'une requête HTTP en particulier. Vous pouvez utiliser plusieurs conditions et actions dans une règle et établir pour chaque condition une correspondance à de multiples valeurs.

Votre compte AWS est soumis à ces limites pour un Application Load Balancer.

Vous pouvez intégrer votre Application Load Balancer à AWS Web Application Firewall (WAF), un pare-feu d’applications web qui protège vos applications web des attaques en vous permettant de définir des règles en fonction des adresses IP, des en-têtes HTTP et des chaînes d’identifiant de ressource uniforme (URI) personnalisées. En utilisant ces règles, AWS WAF peut bloquer, autoriser ou suivre (compter) les requêtes Web envoyées à votre application Web. Consultez le guide du développeur AWS WAF pour en savoir plus.

Vous pouvez utiliser n’importe quelle adresse IP du VPC CIDR de l’équilibreur de charge pour les cibles contenues dans le VPC de l’équilibreur de charge et n’importe quelle adresse IP des plages RFC 1918 (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16) ou de la plage RFC 6598 (100.64.0.0/10) pour les cibles situées en dehors du VPC de l’équilibreur de charge (par exemple, les cibles dans les VPC appairés, Amazon EC2 Classic et sur des ressources locales accessibles par connexion AWS Direct Connect ou VPN).

Il existe plusieurs façons d'effectuer un équilibrage de charge hybride. Si une application s'exécute sur des cibles distribuées entre un VPC et des ressources locales, vous pouvez les ajouter au même groupe de sécurité grâce à leurs adresses IP. Pour effectuer une migration vers AWS sans impacter votre application, ajoutez progressivement des cibles du VPC au groupe de sécurité et supprimez les cibles locales de ce dernier. 

Si vous avez deux applications différentes de sorte que les cibles de l'une soient sur un VPC et celles de l'autre soient sur un emplacement local, vous pouvez placer les cibles du VPC dans un groupe cible et les cibles locales dans un autre groupe cible, pour ensuite utiliser le routage basé sur le contenu pour orienter le trafic vers chaque groupe. Vous pouvez également séparer les équilibreurs de charge pour les cibles du VPC et locales et utiliser l'équilibrage de charge pondéré en fonction du DNS pour effectuer une distribution entre les cibles du VPC et locales.

Vous ne pouvez effectuer d'équilibrage de charge sur des instances EC2 Classic si vous enregistrez leurs ID d'instance en tant que cibles. Cela dit, si vous liez ces instances EC2 Classic à l'équilibreur de charge du VPC avec ClassicLink et si vous utilisez les adresses IP privées de ces instances EC2 Classic en tant que cibles, vous pourrez alors effectuer un équilibrage de charge sur ces instances. Si vous utilisez aujourd'hui des instances EC2 Classic avec un équilibreur de charge classique, vous pouvez facilement effectuer une migration vers un équilibreur de charge d'application.

L'équilibrage de charge entre zones est déjà activé par défaut dans un équilibreur de charge d'application.

Privilégiez l'authentification des utilisateurs avec Amazon Cognito dans les cas suivants :

• Vous souhaitez apporter de la flexibilité à vos utilisateurs pour qu'ils puissent s'authentifier à l'aide d'identités de réseaux sociaux (Google, Facebook et Amazon) ou d'identités entreprise (SAML), ou encore par l'intermédiaire de vos propres répertoires d'utilisateurs avec le pool d'utilisateurs d'Amazon Cognito.
• Vous gérez plusieurs fournisseurs d'identité OpenID Connect et souhaitez créer une seule règle d'authentification dans ALB (Application Load Balancer) capable d'utiliser Amazon Cognito pour fédérer vos différents fournisseurs d'identité.
• Vous devez gérer activement des profils d'utilisateurs à l'aide d'un ou plusieurs fournisseurs d'identité OpenID Connect ou de réseaux sociaux depuis un même lieu centralisé. Par exemple, vous pouvez placer des utilisateurs dans des groupes et ajouter des attributs personnalisés pour représenter le statut des utilisateurs et contrôler l'accès pour les utilisateurs payant.

Autrement, si vous avez investi dans le développement de solutions IdP personnalisées et souhaitez simplement permettre l'authentification avec un seul fournisseur d'identité compatible avec OpenID Connect, privilégiez plutôt la solution OIDC native de l’équilibreur de charge d’application.

Les trois types de redirection suivants sont pris en charge.

HTTP vers HTTP
http://hostA vers http://hostB

HTTP vers HTTPS
http://hostA vers https://hostB
https://hostA:portA/pathA vers https://hostB:portB/pathB

HTTPS vers HTTPS
https://hostA vers https://hostB

Les types de contenu suivants sont pris en charge : text/plain, text/css, text/html, application/javascript, application/json.

Les requêtes HTTP(S) reçues par un équilibreur de charge sont traitées par des règles de routage basées sur le contenu. Si le contenu de la requête correspond à la règle—avec une action qui l'envoie à un groupe cible via une fonction Lambda comme cible—alors s'effectue l'appel de la fonction Lambda appropriée. Le contenu de la requête (y compris les en-têtes et le corps) est transmis à la fonction Lambda au format JavaScript object notation (JSON). La réponse de la fonction Lambda doit être au format JSON. La réponse de la fonction Lambda est convertie en réponse HTTP et envoyée au client. L'équilibreur de charge appelle la fonction Lambda grâce à l'API AWS Lambda Invoke et nécessite que vous accordiez au service Elastic Load Balancing des autorisations d’appel pour votre fonction Lambda.

Oui. L'équilibreur de charge d'application prend en charge l'appel de fonctions Lambda pour les requêtes via les protocoles HTTP et HTTPS.

Vous pouvez utiliser les fonctions Lambda en tant que cibles avec l’Application Load Balancer dans les régions AWS USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Californie du Nord), USA Ouest (Oregon), Asie-Pacifique (Mumbai), Asie-Pacifique (Séoul), Asie-Pacifique (Singapour), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Canada (Centre), UE (Francfort), UE (Irlande), UE (Londres), UE (Paris), Amérique du Sud (São Paulo) et GovCloud (USA-Ouest).

Oui, l’Application Load Balancer est disponible dans la zone locale de Los Angeles. Au sein de cette dernière, il fonctionnera sur un sous-réseau unique et se mettra automatiquement à l'échelle en fonction des différents niveaux de charge, et ce sans qu'aucune intervention manuelle ne soit nécessaire.

Vous êtes facturé pour chaque heure ou heure partielle pendant laquelle un Application Load Balancer fonctionne et selon le nombre d'unités de capacité d'équilibrage de charge (LCU) utilisées par heure.

Une LCU est une nouvelle mesure permettant de déterminer le montant à payer pour un équilibreur de charge d'application. Une LCU définit les ressources maximales consommées dans l'une des dimensions (nouvelles connexions, connexions actives, bande passante et évaluations de règles) dans lesquelles l'équilibreur de charge d'application gère votre trafic.

Non. Les Classic Load Balancers continueront d'être facturés en fonction de la bande passante et de l'utilisation horaire.

Nous présentons l’utilisation des quatre dimensions qui constituent une LCU via Amazon CloudWatch.

Non. Le nombre de LCU par heure sera déterminé en fonction des ressources maximales consommées parmi les quatre dimensions qui constituent une LCU.

Oui.

Oui. Pour les nouveaux comptes AWS, une offre gratuite d'Application Load Balancer est proposée, avec 750 heures et 15 LCU. Cette offre gratuite est réservée aux nouveaux clients AWS et est disponible pendant 12 mois après votre date d'inscription à AWS.

Oui. Vous pouvez utiliser les Classic Load Balancers et les équilibreurs de charge d'application respectivement à hauteur de 15 Go et 15 LCU. Les 750 heures de l'équilibreur de charge sont partagées entre les Classic Load Balancers et Application Load Balancers.

Une évaluation de règles se définit comme le résultat du nombre de règles traitées multiplié par le taux de demande moyen par heure.

La taille de la clé du certificat affecte uniquement le nombre de nouvelles connexions par seconde dans le calcul de la LCU pour la facturation. Le tableau suivant répertorie la valeur de cette dimension pour différentes tailles de clés pour les certificats RSA et ECDSA.

Certificats RSA
Taille de clé <= 2K 
Nouvelles connexions/sec : 25

Taille de clé <= 4K 
Nouvelles connexions/sec : 5

Taille de clé : <= 8K 
Nouvelles connexions/sec : 1

Taille de clé > 8K
Nouvelles connexions/sec : 0,25

Certificats ECDSA
Taille de clé <= 256
Nouvelles connexions/sec : 25

Taille de clé <= 384
Nouvelles connexions/sec : 5

Taille de clé<= 521 
Nouvelles connexions/sec : 1

Taille de clé > 521 
Nouvelles connexions/sec : 0,25

Non. Étant donné que l’équilibrage entre zones est toujours actif sur l’équilibreur de charge d’application, ce type de transfert de données régional ne vous est pas facturé.

Non. La facturation pour la fonctionnalité d'authentification dans un équilibreur de charge d’application n'est pas facturée séparément. Lorsque vous utilisez Amazon Cognito avec Application Load Balancer, la tarifications d'Amazon Cognito s'applique.

Vous êtes facturé comme d’habitude, pour chaque heure ou heure partielle de fonctionnement d’un Application Load Balancer et selon le nombre d’unités de capacité d’équilibrage de charge (LCU) utilisées par heure. Pour les cibles Lambda, chaque LCU offre un traitement d'octets par heure de 0,4 Go, 25 nouvelles connexions par seconde, 3 000 connexions actives par minute et 1 000 évaluations de règles par seconde. Pour la dimension d'objets traités, chaque LCU fournit 0,4 Go par heure pour les cibles Lambda contre 1 Go par heure pour tous les autres types de cibles, comme les instances Amazon EC2, les conteneurs et les adresses IP. Notez que les frais habituels liés à AWS Lambda s'appliquent aux appels de fonctions Lambdas par les équilibreurs de charge d'application.

Les Application Load Balancers émettent deux nouvelles métriques CloudWatch. La métrique LambdaTargetProcessedBytes indique les octets traités par les cibles Lambda, tandis que la métrique StandardProcessedBytes concerne les octets traités par tous les autres types de cibles.

Oui. Les instances Network Load Balancer prennent en charge les écouteurs TCP, UDP et TCP+UDP (couche 4), ainsi que les écouteurs TLS.

Un Network Load Balancer permet un équilibrage de charge TCP et UDP (couche 4). Il est conçu pour gérer des millions de requêtes par seconde ainsi que les schémas de trafic volatil soudains, le tout en proposant des latences extrêmement basses. En outre, le Network Load Balancer prend en charge la terminaison TLS, préserve l'adresse IP source des clients et permet une prise en charge stable des adresses IP, ainsi qu'une isolation zonale. Il prend également en charge les connexions à exécution longue, qui sont utiles dans le cas d'applications de type WebSocket.

Oui. Pour ce faire, vous pouvez utiliser un écouteur TCP+UDP. Par exemple, pour un service DNS qui utilise à la fois les protocoles TCP et UDP, vous pouvez créer un écouteur TCP+UDP sur le port 53 et l'équilibreur de charge traitera le trafic des requêtes UDP et TCP sur ce port. Vous devez associer un écouter TCP+UDP au groupe cible TCP+UDP.

Contrairement à un Classic Load Balancer, un Network Load Balancer préserve l’adresse IP source du client. Les clients peuvent utiliser le protocole proxy avec le Classic Load Balancer pour obtenir l'adresse IP source. Le Network Load Balancer fournit automatiquement une adresse IP statique par zone de disponibilité (AZ) à l'équilibreur de charge et permet également d’attribuer une adresse IP élastique par zone de disponibilité à l'équilibreur de charge. Le Classic Load Balancer ne prend pas en charge ces actions.

Oui. Vous pouvez migrer vers un Network Load Balancer depuis un Classic Load Balancer en utilisant l'une des options listées dans ce document.

Oui, consultez la documentation relative aux limites des Network Load Balancers pour en savoir plus.

Oui. Vous pouvez utiliser AWS Management Console, l'interface de ligne de commande AWS (CLI) ou l'API pour configurer un Network Load Balancer.

Non. Pour créer un Classic Load Balancer, utilisez l'API 2012-06-01. Pour créer un Network Load Balancer ou un Application Load Balancer, utilisez l'API 2015-12-01.

Oui, vous pouvez créer votre Network Load Balancer dans une seule zone de disponibilité en spécifiant un sous-réseau unique lors de la création de l’équilibreur de charge.

Oui. Vous pouvez utiliser les fonctionnalités de vérification de l'état et de basculement DNS d'Amazon Route 53 pour améliorer la disponibilité des applications exécutées derrière les Network Load Balancers. Lorsque vous utilisez le basculement DNS Route 53, vous pouvez exécuter des applications dans plusieurs zones de disponibilité AWS et désigner des équilibreurs de charge alternatifs pour le basculement entre les régions. 

Au cas où votre Network Load Balancer serait configuré pour des applications multi-AZ, si aucune instance Amazon EC2 saine n'est enregistrée avec l'équilibreur de charge pour cette zone de disponibilité, ou si les nœuds de l'équilibreur de charge d'une zone spécifique ne sont pas sains, alors Route 53 basculera sur d'autres nœuds de l'équilibreur de charge dans d'autres zones de disponibilité saines.

Non. Les adresses d'un Network Load Balancer doivent être entièrement commandées par vous ou par l'ELB. Ceci vise à garantir que toutes les adresses connues par vos clients ne changeront pas lors de l'utilisation d'adresses IP élastiques avec un Network Load Balancer.

Non, pour chaque sous-réseau associé dans lequel se trouve un Network Load Balancer, ce dernier peut uniquement prendre en charge une seule adresse IP publique/avec accès Internet.

Les adresses IP élastiques associées à votre équilibreur de charge seront renvoyées dans votre groupe attribué et pourront être réutilisées.

Un Network Load Balancer peut être configuré en tant qu’équilibreur de charge avec accès Internet ou équilibreur de charge interne, de la même façon qu’Application Load Balancer et Classic Load Balancer.

Non. Pour chaque sous-réseau associé dans lequel se trouve un équilibreur de charge, le Network Load Balancer ne peut prendre en charge qu'une seule adresse IP privée.

Oui. Configurez des écouteurs TCP acheminant le trafic vers les cibles implémentant le protocole WebSockets (https://tools.ietf.org/html/rfc6455 ). Etant donné que WebSockets est un protocole Layer 7 et que le Network Load Balancer fonctionne avec Layer 4, il n'existe pas de gestion spéciale du protocole WebSockets ou des autres protocoles de plus haut niveau dans le Network Load Balancer.

Oui. Vous pouvez utiliser n'importe quelle adresse IP du VPC CIDR de l'équilibreur de charge pour les cibles contenues dans le VPC de l'équilibreur de charge et n'importe quelle adresse des plages RFC 1918 (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16) ou de la plage RFC 6598 (100.64.0.0/10) pour les cibles situées en dehors du VPC de l'équilibreur de charge (EC2 Classic et emplacements locaux accessibles par connexion AWS Direct Connect). L'équilibrage de charge du type de cible d'adresse IP est pris en charge pour les écouteurs TCP uniquement et n'est pas pris en charge pour le moment pour les écouteurs UDP.

Oui, les Network Load Balancers peuvent être utilisés avec les écouteurs TCP et TLS pour configurer AWS PrivateLink. Vous ne pouvez pas configurer PrivateLink sur les Network Load Balancers avec des écouteurs UDP.

À la différence du protocole de datagramme utilisateur (UDP) qui fonctionne sans connexion, l’équilibreur de charge maintient l’état du flux UDP sur un hachage à 5 tuples, garantissant ainsi que les paquets envoyés dans le même contexte sont systématiquement transférés à la même cible. Le flux est considéré actif tant que le trafic est acheminé et jusqu'à ce que le délai d'inactivité soit atteint. Une fois le délai atteint, l'équilibreur de charge oubliera l'affinité et le paquet UDP entrant sera considéré comme un nouveau flux et sa charge sera équilibrée sur une nouvelle cible.

Le délai d’inactivité d’un Network Load Balancer pour les connexions TCP est de 350 secondes. Le délai d'inactivité pour les flux UDP est de 120 secondes.

Chaque conteneur ou instance peut désormais disposer de son groupe de sécurité et ne requiert aucun partage de règles de sécurité avec d’autres conteneurs. Vous pouvez attacher des groupes de sécurité à un ENI et chaque ENI d'une instance peut disposer d'un groupe de sécurité différent. Vous pouvez router un conteneur vers l'adresse IP d'un ENI spécifique pour associer un ou plusieurs groupes de sécurité par conteneur. L'équilibrage de charge à l'aide d'adresses IP permet également à plusieurs conteneurs s'exécutant sur une instance d'utiliser le même port (à savoir le port 80). La possibilité d'utiliser le même port sur plusieurs conteneurs permet aux conteneurs d'une instance de communiquer entre eux par des ports connus au lieu de ports aléatoires.

Il existe plusieurs façons d'effectuer un équilibrage de charge hybride. Si une application s'exécute sur des cibles distribuées entre un VPC et des ressources locales, vous pouvez les ajouter au même groupe de sécurité grâce à leurs adresses IP. Pour effectuer une migration vers AWS sans impacter votre application, ajoutez progressivement des cibles du VPC au groupe de sécurité et supprimez les cibles locales de ce dernier. Vous pouvez également séparer les équilibreurs de charge pour les cibles du VPC et locales et utiliser l'équilibrage de charge pondéré en fonction du DNS pour effectuer une distribution entre les cibles du VPC et locales.

Vous ne pouvez effectuer d'équilibrage de charge sur des instances EC2 Classic si vous enregistrez leurs ID d'instance en tant que cibles. Cela dit, si vous liez ces instances EC2 Classic à l'équilibreur de charge du VPC avec ClassicLink et si vous utilisez les adresses IP privées de ces instances EC2 Classic en tant que cibles, vous pourrez alors effectuer un équilibrage de charge sur ces instances. Si vous utilisez aujourd'hui des instances EC2 Classic avec un équilibreur de charge classique, vous pouvez facilement effectuer une migration vers un équilibreur de charge de réseau.

Vous pouvez activer l'équilibrage de charge entre zones uniquement après la création de votre Network Load Balancer. Vous pouvez le faire en modifiant la section des attributs d'équilibrage de charge, puis en cochant la case de prise en charge de l'équilibrage de charge entre zones.

Oui. Vous serez facturé pour les transferts de données régionaux entre les zones de disponibilités dans le Network Load Balancer lorsque l'équilibrage de charge entre zones est activé. Vérifiez les frais facturés dans la section dédiée aux transferts de données sur la page de tarification à la demande d’Amazon EC2.

Oui. Le Network Load Balancer prend actuellement en charge 200 cibles par zone de disponibilité. Par exemple, si vous vous trouvez dans deux zones de disponibilité, vous pouvez avoir jusqu'à 400 cibles enregistrées dans le Network Load Balancer. Si l'équilibrage de charge entre zones est activé, le nombre maximal de cibles passe de 200 cibles par zone de disponibilité à 200 par équilibreur de charge. Ainsi, dans l'exemple ci-dessus, lorsque l'équilibrage de charge entre zones est actif, seules 200 cibles peuvent être enregistrées dans votre équilibreur de charge et ce, même si votre équilibreur de charge se trouve dans deux zones de disponibilité différentes.

Oui, vous pouvez interrompre les connexions TLS dans le Network Load Balancer. Vous devez installer un certificat SSL sur votre équilibreur de charge. L'équilibreur de charge utilise ce certificat pour mettre fin à la connexion, puis déchiffre les requêtes des clients avant de les envoyer aux cibles.

L’IP source est préservée lorsque vous interrompez le protocole TLS sur le Network Load Balancer.

Vous pouvez utiliser AWS Certificate Manager pour allouer un certificat SSL/TLS ou vous procurer le certificat auprès d’autres sources en créant une demande de certificat, en la faisant signer par une autorité de certification, puis en chargeant le certificat avec le service AWS Certification Manager (ACM) ou le service AWS Identity and Access Management (IAM).

SNI est automatiquement activé lorsque vous associez plus d'un certificat TLS avec le même écouteur sécurisé sur un équilibreur de charge. De même, le mode SNI d'un écouteur sécurisé est automatiquement désactivé lorsque vous n'avez qu'un seul certificat associé à un écouteur sécurisé.

Le Network Load Balancer est intégré à AWS Certificate Management (ACM). Cette intégration simplifie la liaison d'un certificat à l'équilibreur de charge, ce qui facilite l'ensemble du processus de transfert SSL. L'achat, le chargement et le renouvellement des certificats SSL/TLS constituent un processus manuel chronophage et complexe. Grâce à l'intégration d'ACM dans Network Load Balancer, l'ensemble du processus a été réduit à une demande de certificat SSL/TLS approuvé et la sélection du certificat ACM pour permettre sa mise en service avec l'équilibreur de charge. Une fois le Network Load balancer créé, vous pouvez configurer un écouteur TLS, puis sélectionner un certificat ACM ou Identity Access Manager (IAM). L’expérience est équivalente à celle que vous vivez avec l’équilibreur de charge d’application ou dans Classic Load Balancer

Non, avec un Network Load Balancer, seul le chiffrement est pris en charge vers les systèmes dorsaux.

Un Network Load Balancer prend uniquement en charge les certificats RSA avec taille clé 2K. Actuellement, nous ne prenons pas en charge les clés de certificats RSA supérieures à 2K; ou les certificats ECDSA sur l’équilibreur Network Load Balancer.

Vous pouvez utiliser TLS Termination on Network Load Balancer dans les régions AWS USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Californie du Nord), USA Ouest (Oregon), Asie-Pacifique (Mumbai), Asie-Pacifique (Séoul), Asie-Pacifique (Singapour), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Canada (Centre), UE (Francfort), UE (Irlande), UE (Londres), UE (Paris), Amérique du Sud (São Paulo) et GovCloud (USA-Ouest).

Vous êtes facturé pour chaque heure ou heure partielle pendant laquelle un Network Load Balancer fonctionne et selon le nombre d'unités de capacité d'équilibrage de charge (LCU) utilisées par heure par celui-ci.

Une LCU est une nouvelle métrique permettant de déterminer le montant à payer pour un Network Load Balancer. Une LCU définit les ressources maximales consommées dans l'une des dimensions (nouvelles connexions/nouveaux flux, connexions actives/flux actifs et bande passante) dans laquelle le Network Load Balancer gère votre trafic.

Les métriques LCU du trafic TCP sont les suivantes :

• 800 nouvelles connexions TCP par seconde ;
• 100 000 connexions TCP actives (échantillonnées par minute) ;
• 1 Go par heure pour les instances Amazon EC2, les conteneurs et les adresses IP en tant que cibles.

Les métriques LCU du trafic UDP sont les suivantes :

• 400 nouveaux flux par seconde ;
• 50 000 flux UDP actifs (échantillonnés par minute) ;
• 1 Go par heure pour les instances Amazon EC2, les conteneurs et les adresses IP en tant que cibles.

Les métriques LCU du trafic TLS sont les suivantes :

• 50 nouvelles connexions TLS par seconde ;
• 3 000 connexions TLS actives (échantillonnées par minute) ;
• 1 Go par heure pour les instances Amazon EC2, les conteneurs et les adresses IP en tant que cibles.

Non, pour chaque protocole, seule l’une des trois dimensions (la plus utilisée au cours de l’heure) vous est facturée.

Non. Plusieurs requêtes peuvent être envoyées dans le cadre d'une même connexion.

Non, les Classic Load Balancers continueront d’être facturés en fonction de la bande passante et du tarif horaire.

Nous allons présenter l'utilisation des trois dimensions qui constituent une LCU par le biais d'Amazon CloudWatch.

Non. Le nombre de LCU par heure sera déterminé en fonction des ressources maximales consommées parmi les trois dimensions qui constituent une LCU.

Oui.

Oui. Pour les nouveaux comptes AWS, une offre gratuite de Network Load Balancer est proposée, avec 750 heures et 15 LCU. Cette offre gratuite est réservée aux nouveaux clients AWS et est disponible pendant 12 mois après votre date d'inscription à AWS.

Oui. Vous pouvez utiliser des équilibreurs de charge d’application et des Network Load Balancers pour 15 LCU chacun, et des Classic Load Balancers pour 15 Go, respectivement. Les 750 heures de l'équilibreur de charge sont partagées entre les équilibreurs de charge d'application, les Network Load Balancers et les Classic Load Balancers.

Il convient d'utiliser le Gateway Load Balancer lorsque vous déployez des appliances virtuelles en ligne dont le trafic réseau n'est pas destiné au Gateway Load Balancer lui-même. Gateway Load Balancer fait passer de manière transparente tout le trafic de la couche 3 par des appliances virtuelles tierces, et est invisible pour la source et la destination du trafic. Pour en savoir plus sur les différences entre ces équilibreurs de charge, consultez la page de comparaison des fonctionnalités.

Un Gateway Load Balancer fonctionne au sein d’une zone de disponibilité.

Un Gateway Load Balancer fournit à la fois une passerelle de couche 3 et des capacités d’équilibrage de la charge au niveau de la couche 4. Il s'agit d'un appareil BITW (bump-in-the-wire) transparent qui ne modifie en rien le paquet. Il est conçu de façon à traiter des millions de requêtes par seconde et les schémas de trafic volatil, et propose des latences extrêmement basses. Consultez les fonctionnalités du Gateway Load Balancer dans cette table. 

Gateway Load Balancer n'effectue pas de résiliation TLS et ne conserve aucun état d'application. Ces fonctions sont effectuées par les appliances virtuelles tierces vers lesquelles il achemine le trafic et desquelles il reçoit le trafic.

Un Gateway Load Balancer ne conserve aucun état d’application, mais il maintient la permanence des flux vers une appliance spécifique à l’aide de 5 tuples (pour les flux TCP/UDP) ou 3 tuples (pour les flux autres que les flux TCP/UDP).

Par défaut, un Gateway Load Balancer définit un flux comme étant une combinaison de 5 tuples comprenant une adresse IP source, une adresse IP de destination, un protocole IP, un port source et un port de destination. En utilisant un hachage à 5 tuples par défaut, Gateway Load Balancer garantit que les deux chemins de ce flux (c’est-à-dire source à destination et destination à source) sont systématiquement transférés vers la même cible. Le flux est considéré actif tant que le trafic est acheminé et jusqu'à ce que le délai d'inactivité soit atteint. Une fois le seuil du délai atteint, l’équilibreur de charge ignore l’affinité. Le trafic des paquets entrants est alors considéré comme étant un nouveau flux et sa charge peut être équilibrée sur une nouvelle cible.

La permanence à 5 tuples par défaut (adresse IP source, adresse IP de destination, protocole IP, port source et port de destination) fournit la répartition optimale du trafic vers les cibles et convient à la plupart des applications basées sur TCP et UDP, à quelques exceptions près. La permanence à 5 tuples par défaut ne convient pas aux applications basées sur TCP ou UDP qui utilisent des flux ou des numéros de ports distincts pour le contrôle et les données, tels que FTP, Microsoft RDP, Windows RPC et SSL VPN. Les flux de contrôle et de données de ces applications peuvent arriver sur différentes appliances cibles et causer des perturbations de trafic. Si vous souhaitez prendre en charge de tels protocoles, vous pouvez activer la permanence des flux GWLB au moyen de 3 tuples (adresse IP source, adresse IP de destination, protocole IP) ou de 2 tuples (adresse IP source, adresse IP destination).

Certaines applications n’utilisent pas du tout le transport TCP ou UDP, mais plutôt des protocoles IP tels que SCTP et GRE. Avec la permanence à 5 tuples par défaut de GWLB, les flux de trafic provenant de ces protocoles peuvent arriver sur différentes appliances cibles et provoquer des perturbations. Si vous souhaitez prendre en charge de tels protocoles, vous pouvez activer la permanence des flux GWLB au moyen de 3 tuples (adresse IP source, adresse IP de destination, protocole IP) ou de 2 tuples (adresse IP source, adresse IP destination).

Veuillez consulter la documentation sur la permanence des flux pour en savoir plus sur la modification du type de permanence.

Le délai d’inactivité d’un Gateway Load Balancer pour les connexions TCP est de 350 secondes. Le délai d'inactivité pour les flux autres que les flux TCP est de 120 secondes. Ces délais d'inactivité sont fixes et ne peuvent pas être modifiés.

En tant qu’interface transparente, GWLB lui-même ne fragmente ni ne réassemble les paquets.

GWLB transmet des fragments UDP vers/depuis les appliances cibles. Cependant, GWLB supprime les fragments TCP et ICMP car l'en-tête de couche 4 n'est pas présent dans ces fragments.

En outre, si l'appliance cible convertit le paquet entrant d'origine en fragments et renvoie les fragments nouvellement créés à GWLB, GWLB supprime ces fragments nouvellement créés car ils ne contiennent pas d'en-tête de couche 4. Pour éviter la fragmentation dans l’appliance cible, nous vous recommandons d’activer la trame jumbo sur votre appliance cible ou de configurer l’interface réseau de votre appliance cible pour utiliser le MTU maximum souhaité, ce qui permet d’obtenir un comportement de transfert transparent en conservant le contenu original du paquet. 

En cas de défaillance d'une seule instance d'appliance virtuelle, Gateway Load Balancer la supprime de la liste de routage et réachemine le trafic vers une instance d'appliance saine.

Si toutes les appliances virtuelles au sein de la zone de disponibilité tombent en panne, le Gateway Load Balancer interrompra le trafic réseau. Nous recommandons de déployer des Gateway Load Balancers dans plusieurs zones de disponibilité pour une plus grande disponibilité. Si toutes les appliances tombent en panne dans une même zone de disponibilité, des scripts peuvent être utilisés pour ajouter de nouvelles appliances ou pour diriger le trafic vers un Gateway Load Balancer dans une autre zone de disponibilité.

Oui, plusieurs Gateway Load Balancers peuvent pointer sur un même ensemble d'appliances virtuelles.

Un Gateway Load Balancer est un appareil BITW (bump-in-the-wire) transparent qui écoute tous les types de trafic IP (dont TCP, UDP, ICMP, GRE et ESP, entre autres). Ainsi, seul un écouteur IP peut être créé sur un Gateway Load Balancer.

Oui, veuillez consulter la documentation relative aux limites des Gateway Load Balancers pour en savoir plus.

Oui, vous pouvez utiliser la console de gestion AWS, la CLI AWS ou l’API pour configurer un Gateway Load Balancer.

Oui, vous pouvez créer votre Gateway Load Balancer dans une seule zone de disponibilité en spécifiant un sous-réseau unique lors de la création de l’équilibreur de charge. Toutefois, pour une amélioration de la disponibilité, nous vous recommandons d'utiliser plusieurs zones de disponibilité. Une fois créé, vous ne pouvez pas ajouter ou supprimer des zones de disponibilité à un Gateway Load Balancer.

Par défaut, l’équilibrage de charge entre zones est désactivé. Vous pouvez activer l'équilibrage de charge entre zones uniquement après la création de votre Gateway Load Balancer. Vous pouvez le faire en modifiant la section des attributs d'équilibrage de charge, puis en cochant la case de prise en charge de l'équilibrage de charge entre zones.

Oui, vous êtes facturé pour les transferts de données entre zones de disponibilité dans un Gateway Load Balancer lorsque l’équilibrage de charge entre zones est activé. Vérifiez les frais facturés dans la section concernant les transferts de données sur la page de tarification à la demande d'Amazon EC2.

Oui. Le Gateway Load Balancer prend actuellement en charge 300 cibles par zone de disponibilité. Par exemple, si vous avez créé un Gateway Load Balancer dans trois zones de disponibilité, vous pouvez avoir jusqu'à 900 cibles enregistrées. Si l'équilibrage de charge entre zones est activé, le nombre maximal de cibles passe de 300 cibles par zone de disponibilité à 300 par Gateway Load Balancer.

Vous êtes facturé pour chaque heure ou heure partielle de fonctionnement d’un Gateway Load Balancer et selon le nombre d’unités de capacité d’équilibrage de charge (LCU) utilisées par heure par celui-ci.

Une LCU est une métrique Elastic Load Balancing permettant de déterminer le montant à payer pour un Gateway Load Balancer. Une LCU définit les ressources maximales consommées dans l'une des dimensions (nouvelles connexions/nouveaux flux, connexions actives/flux actifs et bande passante) dans laquelle le Gateway Load Balancer gère votre trafic.

Les métriques LCU du trafic TCP sont les suivantes :

• 600 nouveaux flux (ou nouvelles connexions) par seconde.
• 60 000 flux (ou connexions) TLS actifs (échantillonnés par minute).
• 1 Go par heure pour les instances EC2, les conteneurs et les adresses IP en tant que cibles.

Non, seule l’une des trois dimensions (la plus utilisée au cours de l’heure) vous est facturée.

Non. Plusieurs requêtes peuvent être envoyées dans le cadre d'une même connexion.

Vous pouvez suivre l’utilisation des trois dimensions d’une LCU par le biais d’Amazon CloudWatch.

Oui.

Pour être performantes, les appliances virtuelles doivent présenter le moins de latence supplémentaire possible, et le trafic circulant vers et depuis l'appliance virtuelle doit suivre une connexion sécurisée. Les points de terminaison Gateway Load Balancer créent les connexions sécurisées à faible latence, nécessaires pour répondre à ces exigences.

Grâce à un point de terminaison Gateway Load Balancer, les appliances peuvent être installées sur différents comptes AWS et VPC. Cela permet de centraliser les appliances en un même endroit pour faciliter la gestion et réduire les frais généraux d'exploitation.

Les points de terminaison Gateway Load Balancer sont une nouvelle catégorie de points de terminaison d'un VPC qui utilise la technologie PrivateLink. Lorsque le trafic réseau est acheminé d'une source (une passerelle Internet, un VPC, etc.) vers le Gateway Load Balancer, et inversement, un point de terminaison Gateway Load Balancer assure une connectivité privée entre les deux. Tout le trafic passe par le réseau AWS et les données ne sont jamais exposées à l'internet, ce qui améliore à la fois la sécurité et les performances.

Une interface PrivateLink est couplée à un Network Load Balancer (NLB) afin de répartir le trafic TCP et UDP destiné aux applications web. En revanche, les points de terminaison Gateway Load Balancer sont utilisés avec les Gateway Load Balancers pour relier la source et la destination du trafic. Le trafic passe du point de terminaison de Gateway Load Balancer à Gateway Load Balancer à travers les appliances virtuelles, et revient à la destination par des connexions PrivateLink sécurisées.

Le point de terminaison Gateway Load Balancer est un point de terminaison d'un VPC, et il n'existe pas de limite du nombre de points de terminaison d'un VPC pouvant se connecter à un service qui utilise Gateway Load Balancer. Cependant, nous recommandons de ne pas connecter plus de 50 points de terminaison Gateway Load Balancer par Gateway Load Balancer, afin de réduire le risque d'un impact plus important en cas d'échec du service.

Le Classic Load Balancer prend en charge les instances Amazon EC2 avec tous les systèmes d'exploitation actuellement pris en charge par le service Amazon EC2.

L'équilibreur de charge classique prend en charge l'équilibrage de charge des applications utilisant les protocoles HTTP, HTTPS (HTTP sécurisé), SSL (TCP sécurisé) et TCP.

Vous pouvez effectuer un équilibrage de charge pour les ports TCP suivants :

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

Oui. Chaque Classic Load Balancer dispose d'un nom DNS IPv4, IPv6 et double pile (à la fois IPv4 et IPv6) associé. Le protocole IPv6 n'est pas pris en charge dans VPC. Vous pouvez utiliser un Application Load Balancer pour la prise en charge native d'IPv6 dans VPC.

Oui.

Si vous utilisez Amazon Virtual Private Cloud, vous pouvez configurer des groupes de sécurité pour la partie frontale de vos Classic Load Balancers.

Oui, vous pouvez mapper le port HTTP 80 et le port HTTPS 443 à un seul et même équilibreur de charge classique.

Le Classic Load Balancer ne limite pas le nombre de connexions qu'il essaye d'établir avec vos instances Amazon EC2 à charge équilibrée. Vous pouvez vous attendre à ce que ce nombre soit échelonné par rapport au nombre de demandes HTTP, HTTPS ou SSL ou au nombre de connexions TCP concurrentes que reçoit l'équilibreur de charge classique.

Vous pouvez équilibrer la charge des instances Amazon EC2 lancées à l’aide d’une AMI payante à partir d’AWS Marketplace. Toutefois, les Classic Load Balancers ne prennent pas en charge les instances lancées à l’aide d’une AMI payante à partir du site d’Amazon DevPay.

Oui. Consultez la page web dédiée à Elastic Load Balancing.

Oui. Pour obtenir un historique des appels d'API d'équilibreur de charge classique réalisés sur votre compte, il vous suffit d'activer CloudTrail dans AWS Management Console.

Oui, vous pouvez mettre fin à une connexion SSL sur les Classic Load Balancers. Vous devez installer un certificat SSL sur chaque équilibreur de charge. Les équilibreurs de charge utilisent ce certificat pour mettre fin à la connexion, puis déchiffrent les requêtes des clients avant de les envoyer aux instances dorsales.

Vous pouvez utiliser AWS Certificate Manager pour allouer un certificat SSL/TLS ou vous procurer le certificat auprès d’autres sources en créant une demande de certificat, en la faisant signer par une autorité de certification et en chargeant le certificat à l’aide du service AWS Identity and Access Management (IAM).

Les Classic Load Balancer sont maintenant intégrés à AWS Certificate Management (ACM). L'intégration à ACM simplifie la liaison d'un certificat à chaque équilibreur de charge, ce qui facilite l'ensemble du processus de transfert SSL. En général, l'achat, le chargement et le renouvellement des certificats SSL/TLS constituent un processus manuel chronophage et complexe. Grâce à l'intégration d'ACM dans les équilibreurs de charge classiques, l'ensemble du processus a été abrégé et comprend seulement une demande de certificat SSL/TLS approuvé et la sélection du certificat ACM pour permettre sa mise en service avec l'équilibreur de charge.

Vous pouvez activer l’équilibrage de charge entre zones en utilisant la console, la CLI AWS ou un kit SDK AWS. Pour en savoir plus, consultez la documentation dédiée à l’équilibrage de charge entre zones.

Non, vous n’êtes pas facturé pour les transferts de données régionaux entre des zones de disponibilité lorsque vous activez l’équilibrage de charge entre zones pour votre Classic Load Balancer.