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.
# Bonnes pratiques de mise en réseau d’Amazon ECS
Les applications modernes sont généralement construites à partir de plusieurs composants distribués qui communiquent entre eux. Par exemple, une application mobile ou Web peut communiquer avec un point de terminaison d’API, et l’API peut être alimentée par plusieurs microservices qui communiquent via Internet.
Pour plus d’informations sur les meilleures pratiques en matière de connexion des applications à Internet, consultez la section [Connexion d’applications Amazon ECS à Internet](networking-outbound.md).
Pour plus d’informations sur les meilleures pratiques en matière de réception de connexions entrantes vers Amazon ECS depuis Internet, consultez la section [Pratiques exemplaires en matière de réception de connexions entrantes vers Amazon ECS depuis Internet](networking-inbound.md).
Pour plus d'informations sur les meilleures pratiques pour connecter Amazon ECS à d'autres AWS services, consultez[Bonnes pratiques pour connecter Amazon ECS aux AWS services depuis votre VPC](networking-connecting-vpc.md).
Pour plus d’informations sur les pratiques exemplaires en matière de connexion de services au sein d’un VPC, consultez la section [Pratiques exemplaires en matière de connexion des services Amazon ECS dans un VPC](networking-connecting-services.md).
Pour plus d'informations sur les meilleures pratiques en matière de services réseau entre Comptes AWS et VPCs, consultez[Bonnes pratiques pour la mise en réseau des services Amazon ECS entre Comptes AWS et VPCs](networking-connecting-services-crossaccount.md).
Pour plus d’informations sur les pratiques exemplaires en matière de services permettant de résoudre les problèmes de réseau, consultez la section [AWS services de résolution des problèmes de réseau Amazon ECS](networking-troubleshooting.md).
# Connexion d’applications Amazon ECS à Internet
La plupart des applications conteneurisées comportent au moins certains composants qui nécessitent un accès sortant à Internet. Par exemple, le dorsal d’une application mobile nécessite un accès sortant aux notifications push.
Amazon Virtual Private Cloud propose deux méthodes principales pour faciliter la communication entre votre VPC et Internet.
## Sous-réseau public et passerelle Internet
![\[Schéma illustrant l’architecture d’un sous-réseau public connecté à une passerelle Internet.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/public-network.png)
Lorsque vous utilisez un sous-réseau public comportant une route vers une passerelle Internet, votre application conteneurisée peut être exécutée sur un hôte au sein d’un VPC sur un sous-réseau public. Une adresse IP publique est attribuée à l’hôte qui exécute votre conteneur. Cette adresse IP publique est routable depuis Internet. Pour plus d’informations, consultez [Passerelles Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) dans le *Guide de l’utilisateur Amazon VPC*.
Cette architecture réseau facilite la communication directe entre l’hôte qui exécute votre application et les autres hôtes sur Internet. La communication est bidirectionnelle. Cela signifie que non seulement vous pouvez établir une connexion sortante avec n’importe quel autre hôte sur Internet, mais que d’autres hôtes sur Internet peuvent également tenter de se connecter à votre hôte. Par conséquent, vous devez porter une attention particulière à votre groupe de sécurité et à vos règles de pare-feu. Ceci afin de garantir que d’autres hôtes sur Internet ne peuvent pas ouvrir de connexions que vous ne souhaitez pas voir ouvertes.
Par exemple, si votre application s’exécute sur Amazon EC2, assurez-vous que le port 22 pour l’accès SSH n’est pas ouvert. Dans le cas contraire, votre instance pourrait recevoir des tentatives de connexion SSH constantes de la part de robots malveillants sur Internet. Ces robots parcourent les adresses IP publiques. Une fois qu’ils ont trouvé un port SSH ouvert, ils tentent de forcer les mots de passe pour essayer d’accéder à votre instance. De ce fait, de nombreuses entreprises limitent l’utilisation des sous-réseaux publics et préfèrent que la plupart, sinon la totalité, de leurs ressources se trouvent dans des sous-réseaux privés.
L’utilisation de sous-réseaux publics pour la mise en réseau convient aux applications publiques qui nécessitent une bande passante importante ou une latence minimale. Les cas d’utilisation applicables comprennent les services de streaming vidéo et de jeux vidéo.
Cette approche réseau est prise en charge à la fois lorsque vous utilisez Amazon ECS sur Amazon EC2 et lorsque vous l’utilisez sur AWS Fargate.
+ Amazon EC2 : vous pouvez lancer des instances EC2 sur un sous-réseau public. Amazon ECS utilise ces instances EC2 comme capacité de cluster, et tous les conteneurs exécutés sur les instances peuvent utiliser l’adresse IP publique sous-jacente de l’hôte pour le réseau sortant. Cela s’applique à la fois aux modes réseau `host` et `bridge`. Cependant, le mode `awsvpc` réseau ne fournit pas d'adresses IP publiques ENIs à la tâche. Par conséquent, l’utilisation d’une passerelle Internet n’est pas possible.
+ Fargate : lorsque vous créez votre service Amazon ECS, spécifiez des sous-réseaux publics pour la configuration réseau de votre service et utilisez l’option **Attribuer une adresse IP publique**. Chaque tâche Fargate est mise en réseau dans le sous-réseau public et possède sa propre adresse IP publique pour une communication directe avec Internet.
## Sous-réseau privé et passerelle NAT
![\[Schéma illustrant l’architecture d’un sous-réseau privé connecté à une passerelle NAT.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/private-network.png)
Lorsque vous utilisez un sous-réseau privé et une passerelle NAT, vous pouvez exécuter votre application conteneurisée sur un hôte situé dans un sous-réseau privé. Ainsi, cet hôte possède une adresse IP privée qui est routable au sein de votre VPC, mais qui n’est pas routable depuis Internet. Cela signifie que les autres hôtes du VPC peuvent se connecter à l’hôte à l’aide de son adresse IP privée, mais que les autres hôtes sur Internet ne peuvent pas établir de communications entrantes avec l’hôte.
Avec un sous-réseau privé, vous pouvez utiliser une passerelle de traduction d’adresses réseau (NAT) pour autoriser un hôte d’un sous-réseau privé à se connecter à Internet. Les hôtes sur Internet reçoivent une connexion entrante qui semble provenir de l’adresse IP publique de la passerelle NAT située dans un sous-réseau public. La passerelle NAT est chargée de servir de pont entre Internet et le sous-réseau privé. Cette configuration est souvent préférée pour des raisons de sécurité, car elle signifie que votre VPC est protégé contre tout accès direct par des attaquants sur Internet. Pour plus d’informations, veuillez consulter [NAT Gateways (Passerelles NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l’utilisateur Amazon VPC*.
Cette approche de réseau privé convient aux scénarios dans lesquels vous souhaitez protéger vos conteneurs d’un accès externe direct. Les scénarios applicables incluent les systèmes de traitement des paiements ou les conteneurs stockant les données utilisateur et les mots de passe. La création et l'utilisation d'une passerelle NAT vous sont facturées dans votre compte. Les tarifs horaires d’utilisation de la passerelle NAT et de traitement des données s’appliquent également. Pour des raisons de redondance, vous devez disposer d’une passerelle NAT dans chaque zone de disponibilité. Ainsi, la perte de disponibilité d’une seule zone de disponibilité ne compromet pas votre connectivité sortante. De ce fait, si votre charge de travail est faible, il peut être plus rentable d’utiliser des sous-réseaux privés et des passerelles NAT.
Cette approche réseau est prise en charge à la fois lors de l’utilisation d’Amazon ECS sur Amazon EC2 et lors de son utilisation sur AWS Fargate.
+ Amazon EC2 : vous pouvez lancer des instances EC2 sur un sous-réseau privé. Les conteneurs qui s’exécutent sur ces hôtes EC2 utilisent le réseau des hôtes sous-jacents, et les requêtes sortantes passent par la passerelle NAT.
+ Fargate : lorsque vous créez votre service Amazon ECS, spécifiez des sous-réseaux privés pour la configuration réseau de votre service et n’utilisez pas l’option **Attribuer une adresse IP publique**. Chaque tâche Fargate est hébergée dans un sous-réseau privé. Son trafic sortant est acheminé via n’importe quelle passerelle NAT que vous avez associée à ce sous-réseau privé.
# 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 ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) dans le *Guide de l’utilisateur des Application Load Balancer*.
![\[Schéma illustrant l’architecture d’un réseau utilisant un Application Load Balancer.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/alb-ingress.png)
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 :
+ Résiliation SSL/TLS : un Application Load Balancer peut garantir une communication HTTPS sécurisée 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 requête. 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 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, consultez la section [Qu’est-ce qu’un Network Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) dans le *Guide de l’utilisateur des Network Load Balancer*.
![\[Schéma illustrant l’architecture d’un réseau utilisant un Network Load Balancer.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/nlbingress.png)
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.
+ End-to-end chiffrement : é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 dorsales 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 le protocole 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 les paramètres de résiliation de connexion pour les groupes cibles Network Load Balancer dans la [Documentation Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay).
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](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter).
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](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay).
## 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](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html).
![\[Schéma illustrant l’architecture d’un réseau à l’aide d’API Gateway.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/apigateway-ingress.png)
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.
+ 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 les request/response modifications. Pour de plus amples informations, consultez la section [Fonctionnalité d’Amazon API Gateway](https://aws.amazon.com//api-gateway/features/).
+ 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 à une région.
+ Résiliation SSL/TLS
+ Routage de différents chemins HTTP vers différents microservices dorsaux
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](https://aws.amazon.com/blogs/architecture/field-notes-serverless-container-based-apis-with-amazon-ecs-and-amazon-api-gateway/).
# Bonnes pratiques pour connecter Amazon ECS aux AWS services depuis votre VPC
Pour qu’Amazon ECS fonctionne correctement, l’agent de conteneur Amazon ECS exécuté sur chaque hôte doit communiquer avec le plan de contrôle Amazon ECS. Si vous stockez vos images de conteneur dans Amazon ECR, les hôtes Amazon EC2 doivent communiquer avec le point de terminaison du service Amazon ECR et avec Amazon S3, où les couches d’images sont stockées. Si vous utilisez d'autres AWS services pour votre application conteneurisée, tels que les données persistantes stockées dans DynamoDB, vérifiez que ces services disposent également de la prise en charge réseau nécessaire.
## Passerelle NAT
L'utilisation d'une passerelle NAT est le moyen le plus simple de garantir que vos tâches Amazon ECS peuvent accéder à d'autres AWS services. Pour plus d’informations sur cette approche, consultez la section [Sous-réseau privé et passerelle NAT](networking-outbound.md#networking-private-subnet).
![\[Schéma illustrant l’architecture d’un réseau utilisant une passerelle NAT.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/natgateway.png)
L’utilisation de cette approche présente les inconvénients suivants :
+ Vous ne pouvez pas limiter les destinations avec lesquelles la passerelle NAT peut communiquer. Vous ne pouvez pas non plus limiter les destinations vers lesquelles votre niveau dorsal peut communiquer sans interrompre toutes les communications sortantes de votre VPC.
+ Les passerelles NAT facturent chaque Go de données qui transite par elle. Si vous utilisez la passerelle NAT pour l’une des opérations suivantes, chaque Go de bande passante vous est facturé :
+ Téléchargement de fichiers volumineux à partir d’Amazon S3
+ Exécution d’un volume élevé de requêtes de base de données vers DynamoDB
+ Extraction d’une image d’Amazon ECR
De plus, les passerelles NAT prennent en charge une bande passante de 5 Gbit/s et s’adaptent automatiquement jusqu’à 45 Gbit/s. Si vous effectuez un routage via une seule passerelle NAT, les applications qui nécessitent des connexions à très haut débit peuvent se heurter à des contraintes réseau. Pour contourner le problème, vous pouvez répartir votre charge de travail sur plusieurs sous-réseaux et attribuer à chaque sous-réseau sa propre passerelle NAT.
## AWS PrivateLink
AWS PrivateLink fournit une connectivité privée entre VPCs les AWS services et vos réseaux locaux sans exposer votre trafic à l'Internet public.
Un point de terminaison de VPC permet des connexions privées entre votre VPC et les services AWS pris en charge, ainsi que les services de point de terminaison de VPC. Le trafic entre votre VPC et les autres services ne quitte pas le réseau Amazon. Un point de terminaison VPC ne nécessite pas de passerelle Internet, de passerelle privée virtuelle, de périphérique NAT, de connexion VPN ou Direct Connect de connexion. Les instances Amazon EC2 dans votre VPC ne nécessitent pas d’adresses IP publiques pour communiquer avec les ressources du service.
Le schéma suivant montre comment fonctionne la communication avec les AWS services lorsque vous utilisez des points de terminaison VPC au lieu d'une passerelle Internet. AWS PrivateLink fournit des interfaces réseau élastiques (ENIs) à l'intérieur du sous-réseau, et les règles de routage VPC sont utilisées pour envoyer toute communication au nom d'hôte du service via l'ENI, directement au service de destination. AWS Ce trafic n’a plus besoin d’utiliser la passerelle NAT ou la passerelle Internet.
![\[Schéma illustrant l'architecture d'un réseau utilisant AWS PrivateLink\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/endpointaccess-multiple.png)
Voici quelques-uns des points de terminaison de VPC courants utilisés avec le service Amazon ECS.
+ [Points de terminaison de passerelle pour Amazon S3](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)
+ [Point de terminaison de VPC DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html)
+ [Point de terminaison Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html)
+ [Point de terminaison Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)
De nombreux autres AWS services prennent en charge les points de terminaison VPC. Si vous utilisez intensivement un service AWS , vous devez consulter la documentation spécifique à ce service et savoir comment créer un point de terminaison de VPC pour ce trafic.
# Pratiques exemplaires en matière de connexion des services Amazon ECS dans un VPC
À l’aide des tâches Amazon ECS dans un VPC, vous pouvez diviser les applications monolithiques en parties distinctes qui peuvent être déployées et mises à l’échelle indépendamment dans un environnement sécurisé. Cette architecture est appelée architecture orientée services (SOA) ou microservices. Cependant, il peut être difficile de s’assurer que toutes ces parties, à la fois à l’intérieur et à l’extérieur d’un VPC, peuvent communiquer entre elles. Il existe plusieurs approches pour faciliter la communication, qui présentent toutes des avantages et des inconvénients différents.
## Utilisation de Service Connect
Nous recommandons Service Connect, qui fournit une configuration Amazon ECS pour la découverte de service, la connectivité et la surveillance du trafic. Avec Service Connect, vos applications peuvent utiliser des noms abrégés et des ports standard pour se connecter aux services du même cluster ou d'autres clusters, y compris VPCs au sein de la même région. Pour plus d’informations, consultez la section [Amazon ECS Service Connect](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html).
Lorsque vous utilisez Service Connect, Amazon ECS gère toutes les étapes de la découverte de services : création des noms susceptibles d’être découverts, gestion dynamique des entrées pour chaque tâche au démarrage et à l’arrêt des tâches, exécution d’un agent dans chaque tâche configuré pour découvrir les noms. Votre application peut rechercher les noms en utilisant les fonctionnalités standard pour les noms DNS et en établissant des connexions. Si votre application le fait déjà, vous n’avez pas besoin de modifier votre application pour utiliser Service Connect.
![\[Schéma illustrant l’architecture d’un réseau utilisant Service Connect.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/serviceconnect.png)
**Les modifications ne se produisent que lors des déploiements**
Vous fournissez la configuration complète dans chaque définition de service et de tâche. Amazon ECS gère les modifications apportées à cette configuration lors de chaque déploiement de service, afin de garantir que toutes les tâches d’un déploiement se comportent de la même manière. Par exemple, un problème courant avec le DNS en tant que découverte de service est le contrôle d’une migration. Si vous modifiez un nom DNS pour qu’il pointe vers les nouvelles adresses IP de remplacement, le délai TTL maximal peut être nécessaire avant que tous les clients commencent à utiliser le nouveau service. Avec Service Connect, le déploiement du client met à jour la configuration en remplaçant les tâches du client. Vous pouvez configurer le disjoncteur de déploiement et toute autre configuration de déploiement pour affecter les modifications de Service Connect de la même manière que pour tout autre déploiement.
## Utilisation de la découverte de service
Une autre approche de service-to-service communication est la communication directe utilisant la découverte de services. Dans cette approche, vous pouvez utiliser l'intégration de la découverte de AWS Cloud Map services avec Amazon ECS. À l'aide de la découverte de services, Amazon ECS synchronise la liste des tâches lancées avec AWS Cloud Map, qui conserve un nom d'hôte DNS qui correspond aux adresses IP internes d'une ou de plusieurs tâches provenant de ce service en particulier. D’autres services au sein d’Amazon VPC peuvent utiliser ce nom d’hôte DNS pour envoyer le trafic directement vers un autre conteneur en utilisant son adresse IP interne. Pour de plus amples informations, consultez [Découverte de service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html).
![\[Schéma illustrant l’architecture d’un réseau utilisant la découverte de service.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/servicediscovery.png)
Dans le schéma précédent, il existe trois services. `service-a-local` possède un conteneur et communique avec `service-b-local`, qui possède deux conteneurs. `service-b-local` doit également communiquer avec `service-c-local`, qui possède un conteneur. Chaque conteneur de ces trois services peut utiliser les noms DNS internes de AWS Cloud Map pour rechercher les adresses IP internes d'un conteneur auprès du service en aval avec lequel il doit communiquer.
Cette approche de service-to-service communication permet une faible latence. À première vue, c’est également simple, car il n’y a aucun composant supplémentaire entre les conteneurs. Le trafic passe directement d’un conteneur à l’autre.
Cette approche convient lorsque vous utilisez le mode réseau `awsvpc`, où chaque tâche possède sa propre adresse IP unique. La plupart des logiciels ne prennent en charge que l’utilisation d’enregistrements DNS `A`, qui se résolvent directement en adresses IP. Lorsque vous utilisez le mode réseau `awsvpc`, l’adresse IP de chaque tâche est un enregistrement `A`. Toutefois, si vous utilisez le mode réseau `bridge`, plusieurs conteneurs peuvent partager la même adresse IP. En outre, les mappages de ports dynamiques entraînent l’attribution aléatoire de numéros de port aux conteneurs sur cette adresse IP unique. À ce stade, un enregistrement `A` ne suffit plus pour la découverte de services. Vous devez également utiliser un enregistrement `SRV`. Ce type d’enregistrement permet de suivre à la fois les adresses IP et les numéros de port, mais nécessite que vous configuriez les applications de manière appropriée. Certaines applications prédéfinies que vous utilisez peuvent ne pas prendre en charge les enregistrements `SRV`.
Un autre avantage du mode réseau `awsvpc` est que vous disposez d’un groupe de sécurité unique pour chaque service. Vous pouvez configurer ce groupe de sécurité pour autoriser les connexions entrantes provenant uniquement des services en amont spécifiques qui doivent communiquer avec ce service.
Le principal inconvénient de la service-to-service communication directe utilisant la découverte de services est que vous devez implémenter une logique supplémentaire pour effectuer de nouvelles tentatives et faire face aux échecs de connexion. Les enregistrements DNS ont une période time-to-live (TTL) qui contrôle la durée pendant laquelle ils sont mis en cache. Il faut un certain temps pour que l’enregistrement DNS soit mis à jour et que le cache expire afin que vos applications puissent récupérer la dernière version de l’enregistrement DNS. Il se peut donc que votre application finisse par résoudre l’enregistrement DNS pour qu’il pointe vers un autre conteneur qui n’existe plus. Votre application doit gérer les nouvelles tentatives et avoir une logique lui permettant d’ignorer les mauvais dorsaux.
## Utilisation d’un équilibreur de charge interne
Une autre approche de service-to-service communication consiste à utiliser un équilibreur de charge interne. Un équilibreur de charge interne existe entièrement à l’intérieur de votre VPC et n’est accessible qu’aux services situés à l’intérieur de votre VPC.
![\[Schéma illustrant l’architecture d’un réseau utilisant un équilibreur de charge interne.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/loadbalancer-internal.png)
L’équilibreur de charge maintient une haute disponibilité en déployant des ressources redondantes dans chaque sous-réseau. Lorsqu’un conteneur du `serviceA` doit communiquer avec un conteneur du `serviceB`, il ouvre une connexion avec l’équilibreur de charge. L’équilibreur de charge ouvre ensuite une connexion vers un conteneur du `service B`. L’équilibreur de charge sert de lieu centralisé pour gérer toutes les connexions entre chaque service.
Si un conteneur du `serviceB` s’arrête, l’équilibreur de charge peut le retirer du groupe. L’équilibreur de charge effectue également des surveillances de l’état par rapport à chaque cible en aval de son pool et peut automatiquement supprimer les mauvaises cibles du groupe jusqu’à ce qu’elles redeviennent saines. Les applications n’ont plus besoin de connaître le nombre de conteneurs en aval. Ils ouvrent simplement leurs connexions à l’équilibreur de charge.
Cette approche est avantageuse pour tous les modes de réseau. L’équilibreur de charge peut suivre les adresses IP des tâches en mode réseau `awsvpc`, ainsi que les combinaisons plus avancées d’adresses IP et de ports en mode réseau `bridge`. Il répartit le trafic de manière uniforme entre toutes les combinaisons d’adresses IP et de ports, même si plusieurs conteneurs sont hébergés sur la même instance Amazon EC2, mais uniquement sur des ports différents.
Le seul inconvénient de cette approche est son coût. Pour être hautement disponible, l’équilibreur de charge doit disposer de ressources dans chaque zone de disponibilité. Cela entraîne des coûts supplémentaires en raison des frais généraux liés au paiement de l’équilibreur de charge et à la quantité de trafic qui passe par l’équilibreur de charge.
Cependant, vous pouvez réduire les frais généraux en faisant en sorte que plusieurs services partagent un équilibreur de charge. Cela convient particulièrement aux services REST qui utilisent un Application Load Balancer. Vous pouvez créer des règles de routage basées sur les chemins qui acheminent le trafic vers différents services. Par exemple, `/api/user/*` peut être acheminé vers un conteneur faisant partie du service `user`, alors que `/api/order/*` peut être acheminé vers le service `order` associé. Avec cette approche, vous ne payez que pour un Application Load Balancer et vous disposez d’une URL cohérente pour votre API. Cependant, vous pouvez répartir le trafic entre différents microservices sur le dorsal.
# Bonnes pratiques pour la mise en réseau des services Amazon ECS entre Comptes AWS et VPCs
Si vous faites partie d'une organisation composée de plusieurs équipes et divisions, vous déployez probablement des services de manière indépendante VPCs dans un environnement partagé Compte AWS ou dans VPCs des services associés à plusieurs personnes Comptes AWS. Quelle que soit la manière dont vous déployez vos services, nous vous recommandons de compléter vos composants réseau pour faciliter l'acheminement du trafic entre eux VPCs. Pour cela, plusieurs AWS services peuvent être utilisés pour compléter vos composants réseau existants.
+ AWS Transit Gateway — Vous devez d'abord envisager ce service réseau. Ce service sert de hub central pour le routage de vos connexions entre Amazon VPCs et Comptes AWS les réseaux locaux. Pour plus d’informations, consultez la section [Qu’est-ce qu’une passerelle de transit ?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) dans le *Guide des passerelles de transit Amazon VPC*.
+ Support Amazon VPC et VPN : vous pouvez utiliser ce service pour créer des connexions site-to-site VPN afin de connecter des réseaux locaux à votre VPC. Pour plus d'informations, voir [Qu'est-ce que c'est AWS Site-to-Site VPN ?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) dans le *guide de AWS Site-to-Site VPN l'utilisateur*.
+ Amazon VPC — Vous pouvez utiliser le peering Amazon VPC pour vous aider à en connecter plusieurs VPCs, que ce soit dans le même compte ou entre plusieurs comptes. Pour plus d’informations, consultez [Qu’est-ce que l’appairage de VPC ?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) dans le *Guide d’appairage de VPC Amazon*.
+ Partagé VPCs : vous pouvez utiliser un VPC et des sous-réseaux VPC sur plusieurs comptes. AWS Pour plus d'informations, consultez la section [Travailler avec le partage VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) dans le guide de l'*utilisateur Amazon VPC*.
# AWS services de résolution des problèmes de réseau Amazon ECS
Les services et fonctionnalités suivants peuvent vous aider à mieux comprendre les configurations de votre réseau et de vos services. Vous pouvez utiliser ces informations pour résoudre les problèmes de mise en réseau et optimiser vos services.
## CloudWatch Informations sur les conteneurs
CloudWatch Container Insights collecte, agrège et résume les métriques et les journaux de vos applications conteneurisées et de vos microservices. Les métriques incluent l’utilisation des ressources telles que l’UC, la mémoire, le disque et le réseau. Ils sont disponibles dans des tableaux de bord CloudWatch automatiques. Pour plus d'informations, consultez la section [Configuration de Container Insights sur Amazon ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS.html) dans le *guide de CloudWatch l'utilisateur Amazon*.
## AWS X-Ray
AWS X-Ray est un service de suivi que vous pouvez utiliser pour collecter des informations sur les requêtes réseau effectuées par votre application. Vous pouvez utiliser le SDK pour instrumenter votre application et capturer les délais et les codes de réponse du trafic entre vos services, et entre vos services et les points de terminaison des services. AWS Pour plus d'informations, veuillez consulter la rubrique [Présentation de AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) dans le *Guide du développeur AWS X-Ray *.
Vous pouvez également explorer AWS X-Ray des graphiques illustrant la manière dont vos services sont en réseau les uns avec les autres. Vous pouvez également les utiliser pour explorer des statistiques agrégées sur les performances de chaque service-to-service lien. Enfin, vous pouvez approfondir une transaction spécifique pour voir comment les segments représentant des appels réseau sont associés à cette transaction en particulier.
Vous pouvez utiliser ces fonctionnalités pour identifier s’il existe un goulot d’étranglement réseau ou si un service spécifique de votre réseau ne fonctionne pas comme prévu.
## Journaux de flux VPC
Vous pouvez utiliser les journaux de flux Amazon VPC pour analyser les performances du réseau et résoudre les problèmes de connectivité. Lorsque les journaux de flux VPC sont activés, vous pouvez capturer un journal de toutes les connexions de votre VPC. Il s'agit notamment des connexions aux interfaces réseau associées à Elastic Load Balancing, Amazon RDS, aux passerelles NAT et à d'autres AWS services clés que vous pourriez utiliser. Pour plus d’informations, consultez [Journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) dans le *Guide de l’utilisateur Amazon VPC*.
## Conseils d’optimisation du réseau
Il existe quelques paramètres que vous pouvez affiner afin d’optimiser votre réseau.
### nofile ulimit
Si vous vous attendez à ce que votre application génère un trafic élevé et gère de nombreuses connexions simultanées, vous devez tenir compte du quota système pour le nombre de fichiers autorisés. Lorsqu’un grand nombre de sockets réseau sont ouverts, chacun doit être représenté par un descripteur de fichier. Si votre quota de descripteurs de fichiers est trop faible, cela limitera vos sockets réseau. Cela entraîne des échecs de connexion ou des erreurs. Vous pouvez mettre à jour le quota spécifique au conteneur pour le nombre de fichiers dans la définition de tâche Amazon ECS. Si vous utilisez Amazon EC2 (au lieu de AWS Fargate), vous devrez peut-être également ajuster ces quotas sur votre instance Amazon EC2 sous-jacente.
### sysctl net
Une autre catégorie de paramètres réglables est celle des paramètres réseau `sysctl`. Vous devez vous référer aux paramètres spécifiques de la distribution Linux de votre choix. La plupart de ces paramètres ajustent la taille des tampons de lecture et d’écriture. Cela peut être utile dans certaines situations lors de l’exécution d’instances Amazon EC2 à grande échelle contenant de nombreux conteneurs.