Réception de connexions entrantes depuis Internet

Si vous gérez un service public, vous devez accepter le trafic entrant en provenance d'Internet. Par exemple, votre site Web public doit accepter les requêtes HTTP entrantes provenant des navigateurs. Dans ce cas, les autres hôtes sur Internet doivent également établir une connexion entrante avec l'hôte de votre application.

Une solution à ce problème consiste à lancer vos conteneurs sur des hôtes situés dans un sous-réseau public doté d'une adresse IP publique. Toutefois, nous ne le recommandons pas pour les applications à grande échelle. Pour ces derniers, une meilleure approche consiste à disposer d'une couche d'entrée évolutive située entre Internet et votre application. Pour cette approche, vous pouvez utiliser n'importe lequel des AWS services répertoriés dans cette section comme entrée.

Application Load Balancer

Un Application Load Balancer fonctionne au niveau de la couche application. Il s'agit de la septième couche du modèle d'interconnexion des systèmes ouverts (OSI). Cela rend un Application Load Balancer adapté aux services HTTP publics. Si vous avez un site Web ou une API REST HTTP, un Application Load Balancer est un équilibreur de charge adapté à cette charge de travail. Pour plus d'informations, voir Qu'est-ce qu'un Application Load Balancer ? dans le guide de l'utilisateur des équilibreurs de charge d'application.

Avec cette architecture, vous créez un Application Load Balancer dans un sous-réseau public afin qu'il dispose d'une adresse IP publique et puisse recevoir des connexions entrantes depuis Internet. Lorsque l'Application Load Balancer reçoit une connexion entrante, ou plus précisément une requête HTTP, il ouvre une connexion à l'application à l'aide de son adresse IP privée. Ensuite, il transmet la demande via la connexion interne.

Un Application Load Balancer présente les avantages suivants.

• Résiliation du protocole SSL/TLS : un Application Load Balancer peut garantir la sécurité des communications HTTPS et des certificats pour les communications avec les clients. Il peut éventuellement mettre fin à la connexion SSL au niveau de l'équilibreur de charge afin que vous n'ayez pas à gérer les certificats dans votre propre application.

• Routage avancé — Un Application Load Balancer peut avoir plusieurs noms d'hôte DNS. Il dispose également de fonctionnalités de routage avancées pour envoyer des requêtes HTTP entrantes vers différentes destinations en fonction de métriques telles que le nom d'hôte ou le chemin de la demande. Cela signifie que vous pouvez utiliser une seule Application Load Balancer comme entrée pour de nombreux services internes différents, voire des microservices sur différents chemins d'une API REST.

• Support du gRPC et websockets — Un Application Load Balancer peut gérer bien plus que du simple HTTP. Il peut également équilibrer la charge des services basés sur le gRPC et le websocket, avec le support HTTP/2.

• Sécurité — Un Application Load Balancer permet de protéger votre application contre le trafic malveillant. Il inclut des fonctionnalités telles que l'atténuation de la synchronisation HTTP et est intégré au AWS Web Application Firewall (AWS WAF). AWS WAF peut filtrer davantage le trafic malveillant susceptible de contenir des modèles d'attaque, tels que l'injection SQL ou les scripts intersites.

Network Load Balancer

Un Network Load Balancer fonctionne à la quatrième couche du modèle Open Systems Interconnection (OSI). Il convient aux protocoles non HTTP ou aux scénarios dans lesquels le end-to-end chiffrement est nécessaire, mais il ne possède pas les mêmes fonctionnalités spécifiques au protocole HTTP qu'un Application Load Balancer. Par conséquent, un Network Load Balancer convient parfaitement aux applications qui n'utilisent pas le protocole HTTP. Pour plus d'informations, voir Qu'est-ce qu'un Network Load Balancer ? dans le guide de l'utilisateur pour les équilibreurs de charge réseau.

Lorsqu'un Network Load Balancer est utilisé comme entrée, il fonctionne de la même manière qu'un Application Load Balancer. Cela est dû au fait qu'il est créé dans un sous-réseau public et possède une adresse IP publique accessible sur Internet. Le Network Load Balancer ouvre ensuite une connexion à l'adresse IP privée de l'hôte exécutant votre conteneur et envoie les paquets du côté public au côté privé.

Fonctionnalités du Network Load Balancer

Étant donné que le Network Load Balancer fonctionne à un niveau inférieur de la pile réseau, il ne possède pas le même ensemble de fonctionnalités que l'Application Load Balancer. Cependant, il présente les caractéristiques importantes suivantes.

• nd-to-end Chiffrement E : étant donné qu'un Network Load Balancer fonctionne au niveau de la quatrième couche du modèle OSI, il ne lit pas le contenu des paquets. Cela le rend adapté à l'équilibrage de charge des communications nécessitant un end-to-end chiffrement.

• Chiffrement TLS — Outre le end-to-end chiffrement, Network Load Balancer peut également mettre fin aux connexions TLS. Ainsi, vos applications principales n'ont pas à implémenter leur propre protocole TLS.

• Support UDP : étant donné qu'un Network Load Balancer fonctionne au niveau de la quatrième couche du modèle OSI, il convient aux charges de travail non HTTP et aux protocoles autres que TCP.

Fermeture des connexions

Comme le Network Load Balancer ne respecte pas le protocole d'application dans les couches supérieures du modèle OSI, il ne peut pas envoyer de messages de fermeture aux clients utilisant ces protocoles. Contrairement à l'Application Load Balancer, ces connexions doivent être fermées par l'application ou vous pouvez configurer le Network Load Balancer pour fermer les connexions de quatrième couche lorsqu'une tâche est arrêtée ou remplacée. Consultez le paramètre de terminaison de connexion pour les groupes cibles de Network Load Balancer dans la documentation de Network Load Balancer.

Si le Network Load Balancer ferme les connexions au niveau de la quatrième couche, les clients peuvent afficher des messages d'erreur indésirables s'ils ne les gèrent pas. Pour plus d'infirmations sur la configuration client recommandée, consultez la bibliothèque Builders ici.

Les méthodes pour fermer les connexions varient selon les applications, mais l'une d'entre elles consiste à s'assurer que le délai de désenregistrement cible du Network Load Balancer est plus long que le délai d'expiration de la connexion client. Le client devait d'abord expirer le délai imparti et se reconnecter progressivement à la tâche suivante via le Network Load Balancer, tandis que l'ancienne tâche épuisait lentement tous ses clients. Pour plus d'informations sur le délai de désenregistrement cible du Network Load Balancer, consultez la documentation du Network Load Balancer.

API HTTP Amazon API Gateway

L'API HTTP Amazon API Gateway est une entrée sans serveur adaptée aux applications HTTP présentant des pics soudains de volumes de requêtes ou de faibles volumes de requêtes. Pour plus d'informations, consultez Qu'est-ce qu'Amazon API Gateway ? dans le guide du développeur d'API Gateway.

Le modèle de tarification pour Application Load Balancer et Network Load Balancer inclut un prix horaire afin de maintenir les équilibreurs de charge disponibles pour accepter les connexions entrantes à tout moment. En revanche, API Gateway facture chaque demande séparément. Cela a pour effet que, si aucune demande n'est reçue, il n'y a aucun frais. En cas de forte charge de trafic, un Application Load Balancer ou un Network Load Balancer peut traiter un plus grand volume de demandes à un prix par requête inférieur à celui d'API Gateway. Toutefois, si vous avez un faible nombre de demandes dans l'ensemble ou si vous avez des périodes de faible trafic, le prix cumulé de l'utilisation de l'API Gateway devrait être plus rentable que le paiement d'une redevance horaire pour maintenir un équilibreur de charge sous-utilisé. L'API Gateway peut également mettre en cache les réponses de l'API, ce qui peut entraîner une baisse des taux de demandes du backend.

Les fonctions API Gateway utilisent un lien VPC qui permet au service AWS géré de se connecter aux hôtes du sous-réseau privé de votre VPC à l'aide de son adresse IP privée. Il peut détecter ces adresses IP privées en consultant les enregistrements de découverte de AWS Cloud Map services gérés par Amazon ECS Service Discovery.

API Gateway prend en charge les fonctionnalités suivantes.

• Le fonctionnement d'API Gateway est similaire à un équilibreur de charge, mais possède des fonctionnalités supplémentaires propres à la gestion des API

• L'API Gateway fournit des fonctionnalités supplémentaires concernant l'autorisation des clients, les niveaux d'utilisation et la modification des demandes/réponses. Pour plus d'informations, consultez les fonctionnalités d'Amazon API Gateway.

• L'API Gateway peut prendre en charge les points de terminaison de passerelle d'API périphériques, régionaux et privés. Les points de terminaison Edge sont disponibles via une CloudFront distribution gérée. Les points de terminaison régionaux et privés sont tous deux locaux d'une région.

• Terminaison SSL/TLS

• Routage de différents chemins HTTP vers différents microservices principaux

Outre les fonctionnalités précédentes, API Gateway prend également en charge l'utilisation d'autorisateurs Lambda personnalisés que vous pouvez utiliser pour protéger votre API contre toute utilisation non autorisée. Pour plus d'informations, consultez Notes de terrain : API basées sur des conteneurs sans serveur avec Amazon ECS et Amazon API Gateway.