Bonnes pratiques pour recevoir des 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 HTTP demandes 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 publicsHTTP. Si vous avez un site Web ou un HTTP RESTAPI, alors 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 HTTP demande, il ouvre une connexion avec 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.

• SSL/TLSrésiliation — Un Application Load Balancer peut garantir une HTTPS communication sécurisée et des certificats pour les communications avec les clients. Il peut éventuellement mettre fin à la SSL connexion 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 DNS noms d'hôtes. Il dispose également de capacités de routage avancées pour envoyer les HTTP demandes 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, ou même des microservices sur différents chemins d'un. REST API

• g RPC support et websockets — Un Application Load Balancer peut gérer bien plus que simplement. HTTP Il peut également équilibrer la charge des services basés sur g RPC et 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 les mesures d'atténuation HTTP de la désynchronisation 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'SQLinjection ou le cross-site scripting.

Network Load Balancer

Un Network Load Balancer fonctionne au niveau de la quatrième couche du modèle Open Systems Interconnection ()OSI. Il convient aux applications non protocolaires HTTP ou aux scénarios dans lesquels end-to-end le chiffrement est nécessaire, mais il ne possède pas les mêmes fonctionnalités HTTP spécifiques qu'un Application Load Balancer. Par conséquent, un Network Load Balancer convient parfaitement aux applications qui ne l'utilisent pas. 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 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.

• nd-to-end Chiffrement E : étant donné qu'un Network Load Balancer fonctionne au niveau de la quatrième couche du OSI modèle, 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.

• TLSchiffrement — Outre le end-to-end chiffrement, Network Load Balancer peut également mettre fin TLS aux connexions. De cette façon, vos applications principales n'ont pas à implémenter les leurs. TLS

• UDPsupport — Comme un Network Load Balancer fonctionne à la quatrième couche du OSI modèle, il convient aux HTTP charges de travail 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 OSI modèle, 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.

APIPasserelle Amazon HTTP API

Amazon API Gateway convient aux HTTP applications présentant des pics soudains de volumes de demandes ou de faibles volumes de demandes. Pour plus d'informations, consultez Qu'est-ce qu'Amazon API Gateway ? dans le Guide du développeur de 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 demande inférieur à celui d'un Gateway. API 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 la API passerelle devrait être plus rentable que le paiement d'une redevance horaire pour maintenir un équilibreur de charge sous-utilisé. La API passerelle peut également mettre en cache API les réponses, ce qui peut entraîner une baisse des taux de demandes du backend.

APIFonctions de passerelle qui utilisent un VPC lien permettant au service AWS géré de se connecter à des hôtes situés dans votre sous-réseau privéVPC, en utilisant 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.

APIGateway prend en charge les fonctionnalités suivantes.

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

• La API passerelle 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 la section Fonctionnalités d'Amazon API Gateway.

• La API passerelle peut prendre en charge les points de terminaison de API passerelle 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.

• SSL/TLSrésiliation

• Acheminement de différents HTTP chemins 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 vous API protéger contre toute utilisation non autorisée. Pour plus d'informations, consultez Notes de terrain : basé sur un conteneur sans serveur avec APIs Amazon et ECS Amazon Gateway. API