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.
# Réseaux
Le déploiement d'un Outpost dépend d'une connexion résiliente à son AZ d'ancrage pour que les opérations de gestion, de surveillance et de service fonctionnent correctement. Vous devez configurer votre réseau sur site de manière à fournir des connexions réseau redondantes pour chaque rack Outpost et une connectivité fiable vers les points d'ancrage dans le cloud. AWS Tenez également compte des chemins réseau entre les charges de travail des applications exécutées sur l'Outpost et les autres systèmes sur site et dans le cloud avec lesquels elles communiquent : comment acheminerez-vous ce trafic sur votre réseau ?
**Topics**
+ [Rattachement au réseau](network-attachment.md)
+ [Connectivité d'ancrage](anchor-connectivity.md)
+ [Routage des applications et des charges](applicationworkload-routing.md)
# Rattachement au réseau
Chaque AWS Outposts rack est configuré avec des top-of-rack commutateurs redondants appelés Outpost Networking Devices ()ONDs. Les serveurs de calcul et de stockage de chaque rack se connectent aux deux ONDs. Vous devez connecter chaque OND à un commutateur distinct appelé périphérique réseau client (CND) de votre centre de données afin de fournir divers chemins physiques et logiques pour chaque rack Outpost. ONDs connectez-vous au vôtre via CNDs une ou plusieurs connexions physiques à l'aide de câbles à fibres optiques et d'émetteurs-récepteurs optiques. Les [connexions physiques](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity) sont configurées dans des [liens de groupes d'agrégation de liens logiques (LAG)](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation).
![\[Schéma illustrant un avant-poste à plusieurs racks avec des connexions réseau redondantes\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
Les liaisons OND vers CND sont toujours configurées dans un LAG, même si la connexion physique est un seul câble à fibre optique. La configuration des liens en tant que groupes LAG vous permet d'augmenter la bande passante des liens en ajoutant des connexions physiques supplémentaires au groupe logique. Les liaisons LAG sont configurées comme des jonctions Ethernet IEEE 802.1q afin de permettre une mise en réseau séparée entre l'Outpost et le réseau local.
Chaque avant-poste possède au moins deux réseaux logiquement séparés qui doivent communiquer avec ou via le réseau du client :
+ **Réseau de liaison de service** : attribue les adresses IP des liaisons de service aux serveurs de l'avant-poste et facilite la communication avec le réseau local pour permettre aux serveurs de se reconnecter aux points d'ancrage de l'avant-poste dans la région. Lorsque vous avez plusieurs implémentations de rack dans un seul Outposts logique, vous devez attribuer un lien de service /26 CIDR à chaque rack.
+ **Réseau de passerelle local** : permet la communication entre les sous-réseaux VPC de l'avant-poste et le réseau local via la passerelle locale de l'avant-poste (LGW).
Ces réseaux séparés se connectent au réseau local par un ensemble de [connexions point-to-point IP via les liaisons LAG](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity). Chaque liaison LAG OND vers CND est configurée avec un VLAN IDs, des sous-réseaux IP point-to-point (/30 ou /31) et un peering eBGP pour chaque réseau séparé (lien de service et LGW). Vous devez considérer les liens LAG, avec leurs sous-réseaux point-to-point VLANs et sous-réseaux, comme des connexions de couche 3 segmentées de couche 2 et routées. Les connexions IP routées fournissent des chemins logiques redondants qui facilitent la communication entre les réseaux séparés de l'Outpost et le réseau local.
![\[Schéma illustrant le peering des liens de service\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[Schéma illustrant le peering de la passerelle locale\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
Vous devez mettre fin aux liaisons LAG de couche 2 (et leurs VLANs) sur les commutateurs CND directement connectés et configurer les interfaces IP et le peering BGP sur les commutateurs CND. Vous ne devez pas combler le LAG VLANs entre les commutateurs de votre centre de données. Pour plus d'informations, consultez la section [Connectivité de la couche réseau](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) dans le *guide de AWS Outposts l'utilisateur*.
Au sein d'un avant-poste logique à plusieurs racks, ONDs ils sont interconnectés de manière redondante pour fournir une connectivité réseau hautement disponible entre les racks et les charges de travail exécutées sur les serveurs. AWS est responsable de la disponibilité du réseau au sein de l'avant-poste.
## Pratiques recommandées pour une connexion réseau à haute disponibilité sans ACE
+ Connectez chaque périphérique réseau Outpost (OND) d'un rack Outpost à un périphérique réseau client (CND) distinct du centre de données.
+ Mettez fin aux liaisons de couche 2 VLANs, aux sous-réseaux IP de couche 3 et au peering BGP sur les commutateurs CND (Customer Networking Device) directement connectés. Ne reliez pas l'OND au CND VLANs entre le réseau local CNDs ou à travers celui-ci.
+ Ajoutez des liens vers les groupes d'agrégation de liens (LAGs) pour augmenter la bande passante disponible entre l'avant-poste et le centre de données. Ne vous fiez pas à la bande passante globale des différents chemins empruntant les deux ONDs.
+ Utilisez les différents chemins via le redondant ONDs pour fournir une connectivité résiliente entre les réseaux Outpost et le réseau sur site.
+ Pour obtenir une redondance optimale et permettre une maintenance OND sans interruption, nous recommandons aux clients de configurer les publicités et les politiques BGP comme suit :
+ L'équipement réseau du client doit recevoir des publicités BGP d'Outpost sans modifier les attributs BGP et activer le BGP multipath/load-balancing to achieve optimal inbound traffic flows (from customer towards Outpost). AS-Path prepending is used for Outpost BGP prefixes to shift traffic away from a particular OND/uplink au cas où une maintenance serait requise. Le réseau client doit préférer les itinéraires depuis Outpost avec un chemin AS-Path de longueur 1 aux itinéraires avec un chemin AS de longueur 4, c'est-à-dire réagir au préfixe AS-Path.
+ Le réseau client doit annoncer des préfixes BGP identiques avec les mêmes attributs à tous les ONDs utilisateurs d'Outpost. Par défaut, le réseau Outpost équilibre la charge du trafic sortant (vers le client) entre toutes les liaisons montantes. Les politiques de routage sont utilisées du côté de l'avant-poste pour détourner le trafic d'un OND particulier au cas où une maintenance serait requise. Les mêmes préfixes BGP du côté du client ONDs sont nécessaires pour effectuer ce transfert de trafic et effectuer la maintenance de manière non perturbatrice. Lorsqu'une maintenance est requise sur le réseau du client, nous recommandons d'utiliser le préfixe AS-Path pour éloigner temporairement le trafic d'une liaison montante ou d'un appareil en particulier.
## Pratiques recommandées pour une connexion réseau à haute disponibilité avec ACE
Pour un déploiement multirack avec quatre racks de calcul ou plus, vous devez utiliser le rack Aggregation, Core, Edge (ACE), qui servira de point d'agrégation réseau pour réduire le nombre de liaisons fibre optique vers vos périphériques réseau sur site. Le rack ACE fournit la connectivité ONDs au rack de chaque Outposts. Il AWS sera donc responsable de l'allocation et de la configuration de l'interface VLAN entre ONDs les périphériques réseau ACE.
Des couches réseau isolées pour les réseaux Service Link et Local Gateway sont toujours nécessaires, qu'un rack ACE soit utilisé ou non, qui vise à disposer de sous-réseaux IP VLAN point-to-point (/30 ou /31) et d'une configuration d'appairage eBGP pour chaque réseau séparé. Les architectures proposées doivent suivre l'une des deux architectures suivantes :
![\[Appareils réseau pour deux clients\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ Avec cette architecture, le client doit disposer de deux périphériques réseau (CND) pour interconnecter les périphériques réseau ACE, assurant ainsi la redondance.
+ Pour chaque connexion physique, vous devez activer un LAG (pour augmenter la bande passante disponible entre l'Outpost et le centre de données), même s'il s'agit d'un port physique unique, et il transportera deux segments de réseau, avec 2 point-to-point VLANs (/30 ou /31), et des configurations eBGP entre et. ACEs CNDs
+ En régime permanent, le trafic est équilibré selon le schéma ECMP (Equal-cost Multipath) activé, et les préfixes du client sont annoncés avec la même métrique BGP sur les 4 connexions d'to/from the customer network from the ACE layer, 25% traffic distribution across the ACE to customer. In order to allow this behavior, the eBGP peering’s between ACEs and CNDs must have BGP multipath/loadappairage eBGP.
+ Pour obtenir une redondance optimale et permettre une maintenance OND sans interruption, nous recommandons aux clients de suivre les recommandations suivantes :
+ Le périphérique réseau du client doit annoncer des préfixes BGP identiques avec les mêmes attributs à tous les ONDs utilisateurs d'Outpost.
+ Le périphérique réseau du client doit recevoir des publicités BGP d'Outpost sans modifier les attributs BGP et pour activer le multichemin/l'équilibrage de charge BGP.
![\[Appareils réseau pour quatre clients\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
Grâce à cette architecture, le client disposera de quatre périphériques réseau (CND) pour interconnecter les périphériques réseau ACE, offrant ainsi une redondance et la même logique réseau VLANs, y compris l'eBGP et l'ECMP applicables à une architecture à 2 CND.
# Connectivité d'ancrage
Un [lien de service Outpost](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) se connecte à des points d'ancrage publics ou privés (mais pas aux deux) dans une zone de disponibilité (AZ) spécifique de la région parent de l'Outpost. Les serveurs Outpost initient des connexions VPN de liaison de service sortantes à partir de leurs adresses IP de liaison de service vers les points d'ancrage de l'AZ d'ancrage. Ces connexions utilisent les ports UDP et TCP 443. AWS est responsable de la disponibilité des points d'ancrage dans la Région.
Vous devez vous assurer que les adresses IP du lien du service Outpost peuvent être connectées via votre réseau aux points d'ancrage de l'AZ d'ancrage. Les adresses IP du lien de service n'ont pas besoin de communiquer avec les autres hôtes de votre réseau local.
Les points d'ancrage publics se trouvent dans les [plages d'adresses IP publiques](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) de la région (dans les blocs CIDR du EC2 service) et sont accessibles via Internet ou des interfaces virtuelles publiques [AWS Direct Connect](https://aws.amazon.com/directconnect/)(DX) (VIFs). L'utilisation de points d'ancrage publics permet une sélection plus flexible du chemin, car le trafic des liaisons de service peut être acheminé sur n'importe quel chemin disponible pouvant atteindre avec succès les points d'ancrage sur l'Internet public.
Les points d'ancrage privés vous permettent d'utiliser vos plages d'adresses IP pour la connectivité d'ancrage. Les points d'ancrage privés sont créés dans un [sous-réseau privé au sein d'un VPC dédié à](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity) l'aide d'adresses IP attribuées par le client. Le VPC est créé dans le propriétaire de la Compte AWS ressource Outpost et vous êtes chargé de vous assurer que le VPC est disponible et correctement configuré. [Utilisez une politique de contrôle de sécurité (SCP) dans AWSOrigamiServiceGateway les Organizations pour empêcher les utilisateurs de supprimer ce Virtual Private Cloud (VPC). Les points d'ancrage privés doivent être accessibles via Direct Connect private. VIFs](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/)
Vous devez fournir des chemins réseau redondants entre l'avant-poste et les points d'ancrage de la région, les connexions se terminant sur des appareils distincts situés à plusieurs endroits. Le routage dynamique doit être configuré pour rediriger automatiquement le trafic vers des chemins alternatifs en cas de défaillance des connexions ou des périphériques réseau. Vous devez prévoir une capacité réseau suffisante pour garantir que la défaillance d'un chemin WAN ne submerge pas les chemins restants.
Le schéma suivant montre trois Outposts dotés de chemins réseau redondants vers leur point d'ancrage AZs , AWS Direct Connect ainsi que d'une connexion Internet publique. L'avant-poste A et l'avant-poste B sont ancrés dans différentes zones de disponibilité dans la même région. L'avant-poste A se connecte aux points d'ancrage privés de l'AZ 1 de la région 1. L'avant-poste B se connecte aux points d'ancrage publics de l'AZ 2 de la région 1. L'avant-poste C se connecte aux points d'ancrage publics de l'AZ 1 de la région 2.
![\[Schéma illustrant la connectivité d'ancrage hautement disponible AWS Direct Connect et l'accès public à Internet\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
L'avant-poste A dispose de trois chemins réseau redondants pour atteindre son point d'ancrage privé. Deux voies sont disponibles via des circuits Direct Connect redondants situés sur un seul emplacement Direct Connect. Le troisième chemin est disponible via un circuit Direct Connect à un deuxième emplacement Direct Connect. Cette conception permet de maintenir le trafic des liaisons de service de l'Outpost A sur les réseaux privés et assure la redondance des chemins, ce qui permet de faire face à la défaillance de l'un des circuits Direct Connect ou à la défaillance d'un emplacement Direct Connect complet.
L'avant-poste B dispose de quatre chemins réseau redondants pour atteindre son point d'ancrage public. Trois chemins sont disponibles via un VIFs approvisionnement public sur les circuits et emplacements Direct Connect utilisés par Outpost A. Le quatrième chemin est disponible via le WAN du client et l'Internet public. Le trafic des liaisons de service de l'Outpost B peut être acheminé par n'importe quel chemin disponible permettant d'atteindre les points d'ancrage sur l'Internet public. L'utilisation des chemins Direct Connect peut fournir une latence plus constante et une meilleure disponibilité de bande passante, tandis que le chemin Internet public peut être utilisé pour des scénarios de reprise après sinistre (DR) ou d'augmentation de bande passante.
L'Outpost C dispose de deux chemins réseau redondants pour atteindre son point d'ancrage public. L'Outpost C est déployé dans un centre de données différent de celui des Outposts A et B. Le centre de données de l'Outpost C ne dispose pas de circuits dédiés connectés au WAN du client. Au lieu de cela, le centre de données dispose de connexions Internet redondantes fournies par deux fournisseurs de services Internet différents (ISPs). Le trafic des liaisons de service d'Outpost C peut être acheminé via l'un des réseaux ISP pour atteindre les points d'ancrage sur l'Internet public. Cette conception offre la flexibilité nécessaire pour acheminer le trafic des liaisons de service sur n'importe quelle connexion Internet publique disponible. Cependant, le end-to-end chemin dépend des réseaux tiers publics où la disponibilité de la bande passante et la latence du réseau fluctuent.
Le chemin réseau entre un avant-poste et ses points d'ancrage de liaison de service doit respecter les spécifications de bande passante suivantes :
+ 500 Mbits/s à 1 Gbit/s de bande passante disponible par rack Outpost (par exemple, 3 racks : bande passante disponible de 1,5 à 3 Gbit/s)
## Pratiques recommandées pour une connectivité d'ancrage à haute disponibilité
+ Fournissez des chemins réseau redondants entre chaque avant-poste et ses points d'ancrage dans la région.
+ Utilisez les chemins Direct Connect (DX) pour contrôler la latence et la disponibilité de la bande passante.
+ Assurez-vous que les ports TCP et UDP 443 sont ouverts (sortants) entre les blocs CIDR Outpost Service Link et les [plages d'adresses EC2 IP de la région parent](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html). Assurez-vous que les ports sont ouverts sur tous les chemins réseau.
+ Gardez une trace des plages d'adresses EC2 IP Amazon sur votre pare-feu si vous utilisez un sous-ensemble de plages d'adresses CIDR pour la région.
+ Assurez-vous que chaque chemin répond aux exigences de disponibilité de bande passante et de latence.
+ Utilisez le routage dynamique pour automatiser la redirection du trafic en cas de défaillance du réseau.
+ Testez le routage du trafic de liaison de service sur chaque chemin réseau planifié pour vous assurer que le chemin fonctionne comme prévu.
# Routage des applications et des charges
Il existe deux voies pour sortir de l'Outpost pour les charges de travail des applications :
+ Le chemin du lien de service : considérez que le trafic des applications concurrencera le trafic du plan de contrôle des Outposts, en plus de limiter le [MTU à](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links) 1 300 octets.
+ Le chemin de la passerelle locale (LGW) : considérez que le réseau local du client autorise l'accès à la fois aux applications locales et au. Région AWS
Vous configurez les tables de routage du sous-réseau Outpost pour contrôler le chemin à emprunter pour atteindre les réseaux de destination. Les itinéraires pointés vers le LGW dirigeront le trafic depuis la passerelle locale vers le réseau local. Les itinéraires pointant vers les services et ressources de la région, tels que Internet Gateway, NAT Gateway, Virtual Private Gateway et TGW, utiliseront le [lien de service](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) pour atteindre ces cibles. Si vous disposez d'une connexion d'appairage VPC avec plusieurs connexions VPCs sur le même avant-poste, le trafic entre les deux VPCs reste sur l'avant-poste et n'utilise pas le lien de service vers la région. *Pour plus d'informations sur le peering VPC, consultez Connect [using VPCs VPC peering dans le guide de l'utilisateur Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html).*
![\[Schéma illustrant une visualisation du lien de service Outpost et des chemins du réseau LGW\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
Lorsque vous planifiez le routage des applications, veillez à prendre en compte à la fois le fonctionnement normal et le routage limité et la disponibilité des services en cas de défaillance du réseau. Le chemin du lien de service n'est pas disponible lorsqu'un avant-poste est déconnecté de la région.
Vous devez prévoir différents chemins et configurer le routage dynamique entre l'Outpost LGW et vos applications, systèmes et utilisateurs critiques sur site. Les chemins réseau redondants permettent au réseau d'acheminer le trafic en cas de panne et de garantir que les ressources locales seront en mesure de communiquer avec les charges de travail exécutées sur l'avant-poste en cas de défaillance partielle du réseau.
Les configurations de routage VPC d'Outpost sont statiques. Vous configurez les tables de routage de sous-réseau via la AWS Management Console CLI et d'autres outils d'infrastructure en tant que code (IaC) ; toutefois, vous ne pourrez pas modifier les tables de routage de sous-réseau lors d'un événement de déconnexion. APIs Vous devrez rétablir la connectivité entre l'avant-poste et la région pour mettre à jour les tables de routage. Pour les opérations normales, utilisez les mêmes itinéraires que ceux que vous prévoyez d'utiliser lors d'événements de déconnexion.
Les ressources de l'Outpost peuvent accéder à Internet via le lien de service et une passerelle Internet (IGW) dans la région ou via le chemin de la passerelle locale (LGW). Le routage du trafic Internet via le chemin LGW et le réseau local vous permet d'utiliser les points d'entrée/sortie Internet existants sur site et peut entraîner une latence plus faible, des frais de sortie de AWS données plus élevés et moins élevés MTUs par rapport à l'utilisation du chemin de liaison de service vers un IGW de la région.
Si votre application doit s'exécuter sur site et être accessible depuis l'Internet public, vous devez acheminer le trafic de l'application via vos connexions Internet locales vers le LGW pour atteindre les ressources de l'Outpost.
Bien que vous puissiez configurer des sous-réseaux sur un avant-poste, comme les sous-réseaux publics de la région, cette pratique peut s'avérer indésirable dans la plupart des cas d'utilisation. Le trafic Internet entrant entrera par le lien de service Région AWS et sera acheminé vers les ressources exécutées sur l'avant-poste.
Le trafic de réponse sera à son tour acheminé via le lien de service et sera renvoyé via les connexions Internet Région AWS de celui-ci. Ce schéma de trafic peut ajouter de la latence et entraîner des frais de sortie de données lorsque le trafic quitte la région pour se rendre à l'avant-poste et lorsque le trafic de retour revient par la région et sort vers Internet. Si votre application peut être exécutée dans la région, la région est le meilleur endroit pour l'exécuter.
Le trafic entre les ressources VPC (dans le même VPC) suivra toujours la route CIDR VPC locale et sera acheminé entre les sous-réseaux par les routeurs VPC implicites.
Par exemple, le trafic entre une EC2 instance exécutée sur l'Outpost et un point de terminaison VPC dans la région sera toujours acheminé via le lien de service.
![\[Schéma illustrant le routage VPC local via les routeurs implicites\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## Pratiques recommandées pour le routage des applications et des charges de travail
+ Utilisez le chemin de la passerelle locale (LGW) au lieu du chemin du lien de service dans la mesure du possible.
+ Acheminez le trafic Internet sur le chemin LGW.
+ Configurez les tables de routage du sous-réseau Outpost avec un ensemble standard de routes. Elles seront utilisées à la fois pour les opérations normales et lors des événements de déconnexion.
+ Fournissez des chemins réseau redondants entre l'Outpost LGW et les ressources applicatives critiques sur site. Utilisez le routage dynamique pour automatiser la redirection du trafic en cas de défaillance du réseau sur site.