Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pratiques exemplaires en matière de réception de connexions entrantes vers Amazon ECS 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. Cependant, nous ne recommandons pas cette solution pour les applications de grande envergure. 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 services AWS 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 OSI (Open Systems Interconnection). 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, consultez la section Qu’est-ce qu’un Application Load Balancer ? dans le Guide de l’utilisateur des Application Load Balancer.

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 requête via la connexion interne.

Un Application Load Balancer présente les avantages suivants :

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, consultez la section Qu’est-ce qu’un Network Load Balancer ? dans le Guide de l’utilisateur des Network Load Balancer.

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 qui exécute 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.

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 les paramètres de résiliation de connexion pour les groupes cibles Network Load Balancer dans la Documentation Network Load Balancer.

Laisser le Network Load Balancer fermer les connexions au niveau de la quatrième couche peut entraîner l’affichage de messages d’erreur indésirables pour les clients, si ceux-ci ne les gèrent pas. Pour plus d'infirmations sur la configuration client recommandée, consultez la bibliothèque Builders ici.

Les méthodes de fermeture des connexions varient selon les applications, mais l’une d’entre elles consiste à s’assurer que le délai d’annulation de l’enregistrement de la 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 d’annulation de l’enregistrement de la cible du Network Load Balancer, consultez la Documentation du Network Load Balancer.

API HTTP Amazon API Gateway

Amazon API Gateway convient 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 la section Qu’est-ce qu’Amazon API Gateway ? dans le Guide du développeur API Gateway.

Le modèle de tarification pour Application Load Balancer et Network Load Balancer inclut un tarif horaire afin de maintenir les équilibreurs de charge disponibles pour accepter les connexions entrantes à tout moment. En revanche, API Gateway facture chaque requête séparément. Cela signifie que si aucune demande n’est reçue, il n’y a pas de frais. En cas de forte charge de trafic, un Application Load Balancer ou un Network Load Balancer peut traiter un plus grand volume de requêtes à un prix par requête inférieur à celui d’API Gateway. Cependant, si vous avez globalement peu de requêtes ou si vous connaissez des périodes de faible trafic, le prix cumulé pour l’utilisation de l’API Gateway devrait être plus rentable que de payer un tarif 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 requêtes du dorsal.

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 ci-dessous.

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 Field Notes : basé sur un conteneur sans serveur avec APIs Amazon ECS et Amazon API Gateway.