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.
# Connectivité réseau pour une architecture à comptes multiples
## Connecter VPCs
De nombreuses entreprises utilisent le peering VPC dans Amazon Virtual Private Cloud (Amazon VPC) pour connecter le développement et la production. VPCs À l'aide d'une connexion d'appairage VPC, vous pouvez acheminer le trafic entre deux VPCs en utilisant un adressage IP privé. Le connecté VPCs peut être différent Comptes AWS ou différent Régions AWS. Pour plus d'informations, veuillez consulter la rubrique [Qu'est-ce que l'appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) (documentation Amazon VPC). À mesure que les entreprises se développent et que VPCs leur nombre augmente, le maintien de connexions de peering entre toutes VPCs peut devenir un fardeau de maintenance. Vous pouvez également être limité par le nombre maximal de connexions d'appairage de VPC par VPC. Pour plus d'informations, veuillez consulter la rubrique [Quotas d'une connexion d'appairage de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) (documentation Amazon VPC).
Si vous disposez de plusieurs environnements de développement, de test et de préparation hébergeant des données non liées à la production sur plusieurs d'entre eux Comptes AWS, vous souhaiterez peut-être fournir une connectivité réseau entre tous ces environnements VPCs , mais interdire tout accès aux environnements de production. Vous pouvez l'[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)utiliser pour connecter VPCs plusieurs comptes. Vous pouvez séparer les tables de routage pour VPCs empêcher le développement de communiquer avec la production VPCs via la passerelle de transit, qui fait office de routeur centralisé. Pour plus d'informations, veuillez consulter la rubrique [Routeur centralisé](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-centralized-router.html) (documentation Transit Gateway).
Transit Gateway prend également en charge l'appairage avec d'autres passerelles de transit, y compris celles situées dans différents Comptes AWS ou différentes Régions AWS. Transit Gateway étant un service hautement disponible et entièrement géré, vous ne devez allouer qu'une seule passerelle de transit pour chaque région.
Pour plus d'informations et des architectures réseau détaillées, voir [Création d'une infrastructure AWS réseau multi-VPC évolutive et sécurisée](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) (AWS livre blanc).
## Connexion d'applications
Si vous devez établir une communication entre des applications différentes Comptes AWS dans le même environnement (tel que la production), vous pouvez utiliser l'une des options suivantes :
+ L'[appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) ou [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) peut fournir une connectivité au niveau du réseau si vous souhaitez ouvrir un accès étendu à plusieurs adresses IP et ports.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) crée des points de terminaison dans un sous-réseau privé du VPC, et ces points de terminaison sont enregistrés en tant qu'entrées DNS dans [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html). Avec DNS, les applications peuvent résoudre les points de terminaison et se connecter aux services enregistrés, sans avoir besoin de passerelles NAT ou de passerelles Internet dans le VPC.
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html) associe des services, tels que des applications, entre plusieurs comptes VPCs et les collecte dans un réseau de services. Les clients VPCs associés au réseau de service peuvent envoyer des demandes à tous les autres services associés au réseau de service, qu'ils soient ou non dans le même compte. VPC Lattice s'intègre à AWS Resource Access Manager (AWS RAM) afin que vous puissiez partager des ressources avec d'autres comptes ou via. AWS Organizations Vous ne pouvez associer un VPC qu'à un seul réseau de services. Cette solution ne nécessite pas l'utilisation de l'appairage de VPC ou de AWS Transit Gateway pour communiquer entre les comptes.
## Bonnes pratiques pour la connectivité réseau
+ Créez un réseau Compte AWS que vous utiliserez pour la mise en réseau centralisée. Nommez ce compte **network-prod** et utilisez-le pour AWS Transit Gateway Amazon [VPC IP Address](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) Manager (IPAM). Ajoutez ce compte à l'unité d'organisation **Infrastructure\$1Prod**.
+ Utilisez [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) (AWS RAM) pour partager la passerelle de transit, les réseaux de services VPC Lattice et les groupes IPAM avec le reste de l'organisation. Cela permet à tous Compte AWS les membres de votre organisation d'interagir avec ces services.
+ En utilisant des pools IPAM pour gérer IPv4 et IPv6 gérer les allocations de manière centralisée, vous pouvez permettre à vos utilisateurs finaux de s'approvisionner eux-mêmes VPCs en utilisant. [AWS Service Catalog](https://aws.amazon.com/servicecatalog/) Cela vous permet de dimensionner de manière appropriée VPCs et d'éviter le chevauchement des espaces d'adresses IP.
+ Utilisez une approche de sortie centralisée pour le trafic lié à Internet, et utilisez une approche d'entrée décentralisée pour le trafic entrant dans votre environnement depuis Internet. Pour plus d’informations, consultez [Sortie centralisée](centralized-egress.md) et [Entrée décentralisée](decentralized-ingress.md).
# Sortie centralisée
La *sortie centralisée* repose sur le principe d'utilisation d'un point d'entrée unique et commun pour tout le trafic réseau destiné à Internet. Vous pouvez configurer l'inspection à ce point d'entrée, et vous pouvez autoriser le trafic uniquement vers des domaines spécifiques ou uniquement via des ports ou des protocoles spécifiques. La centralisation des sorties peut également vous aider à réduire les coûts en éliminant le besoin de déployer des passerelles NAT dans chacun d'entre vous VPCs pour accéder à Internet. Cela s'avère avantageux du point de vue de la sécurité, en raison de la limitation de l'exposition aux ressources malveillantes accessibles de l'extérieur, telles que l'infrastructure de commande et de contrôle (C&C) des logiciels malveillants. Pour plus d'informations et pour connaître les options d'architecture relatives à la sortie centralisée, consultez la section [Sortie centralisée vers Internet](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html) (AWS livre blanc).
Vous pouvez utiliser [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html), qui est un pare-feu réseau dynamique et un service de détection et de prévention des intrusions, en tant que point d'inspection central pour le trafic sortant. Vous configurez ce pare-feu dans un VPC dédié pour le trafic sortant. Network Firewall prend en charge les règles dynamiques que vous pouvez utiliser pour limiter l'accès à Internet à des domaines spécifiques. Pour plus d'informations, veuillez consulter la rubrique [Domain List](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering) (documentation Network Firewall).
Vous pouvez également utiliser [Amazon Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) pour limiter le trafic sortant vers des noms de domaine spécifiques, essentiellement pour empêcher l'exfiltration non autorisée de vos données. Dans les règles DNS Firewall, vous pouvez appliquer des [listes de domaines](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html) (documentation Route 53), qui autorisent ou refusent l'accès à des domaines spécifiés. Vous pouvez utiliser des listes de domaines AWS gérées, qui contiennent des noms de domaine associés à des activités malveillantes ou à d'autres menaces potentielles, ou vous pouvez créer des listes de domaines personnalisées. Vous créez des groupes de règles de pare-feu DNS, puis vous les appliquez à votre VPCs. Les demandes DNS sortantes sont acheminées via un résolveur dans le VPC pour la résolution des noms de domaine, tandis que DNS Firewall filtre les demandes en fonction des groupes de règles appliqués au VPC. Les demandes DNS récursives qui accèdent au résolveur ne passent pas par la passerelle de transit et le chemin Network Firewall. Route 53 Resolver et DNS Firewall doivent être considérés comme un chemin de sortie distinct du VPC.
L'image suivante montre un exemple d'architecture pour une sortie centralisée. Avant le début de la communication réseau, les demandes DNS sont envoyées à Route 53 Resolver, où DNS Firewall autorise ou refuse la résolution de l'adresse IP utilisée pour la communication. Le trafic destiné à Internet est acheminé vers une passerelle de transit dans un compte de mise en réseau centralisée. La passerelle de transit transfère le trafic à Network Firewall pour inspection. Si la politique de pare-feu autorise le trafic sortant, le trafic est acheminé via une passerelle NAT, via une passerelle Internet et vers Internet. Vous pouvez l'utiliser AWS Firewall Manager pour gérer de manière centralisée les groupes de règles du pare-feu DNS et les politiques de pare-feu réseau au sein de votre infrastructure multi-comptes.
![\[Acheminement du trafic depuis d'autres comptes via le compte réseau et vers Internet.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/3_egress.png)
## Bonnes pratiques pour sécuriser le trafic sortant
+ Commencez dans [mode de journalisation uniquement](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html) (documentation Route 53). Passez en mode blocage après avoir vérifié que le trafic légitime n'est pas affecté.
+ Bloquez le trafic DNS vers Internet en utilisant des [AWS Firewall Manager politiques pour les listes de contrôle d'accès au réseau](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html) ou en utilisant AWS Network Firewall. Toutes les requêtes DNS doivent être acheminées via un résolveur Route 53, où vous pouvez les surveiller avec Amazon GuardDuty (si activé) et les filtrer avec le [pare-feu DNS Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) (si activé). Pour plus d'informations, consultez [Résolution des requêtes DNS entre VPCs et votre réseau](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) (documentation Route 53).
+ Utilisez les [listes de domaines gérées AWS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html) (documentation Route 53) dans DNS Firewall et Network Firewall.
+ Envisagez de bloquer les domaines de premier niveau inutilisés à haut risque, tels que .info, .top, .xyz ou certains domaines de code de pays.
+ Envisagez de bloquer les ports non utilisés à haut risque, tels que les ports 1389, 4444, 3333, 445, 135, 139 ou 53.
+ Comme point de départ, vous pouvez utiliser une liste de refus qui inclut les règles AWS gérées. Vous pouvez ensuite travailler au fil du temps à la mise en œuvre d'un modèle de liste d'autorisation. Par exemple, au lieu de n'inclure qu'une liste stricte de noms de domaine complets dans la liste d'autorisation, commencez par utiliser des caractères génériques, tels que *\$1.exemple.com*. Vous pouvez même autoriser uniquement les domaines de premier niveau auxquels vous vous attendez et bloquer tous les autres. Puis, au fil du temps, réduisez-les également.
+ Utilisez les [profils Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) (documentation Route 53) pour appliquer des configurations Route 53 liées au DNS sur de nombreuses VPCs et de différentes manières. Comptes AWS
+ Définissez un processus pour gérer les exceptions à ces meilleures pratiques.
# Entrée décentralisée
L'*entrée décentralisée* est le principe qui permet de définir, au niveau d'un compte individuel, la manière dont le trafic provenant d'Internet atteint les charges de travail de ce compte. Dans les architectures à comptes multiples, l'un des avantages de l'entrée décentralisée est que chaque compte peut utiliser le service ou la ressource d'entrée les plus appropriés pour ses charges de travail, comme un Application Load Balancer, Amazon API Gateway ou Network Load Balancer.
Bien que l'entrée décentralisée signifie que vous devez gérer chaque compte individuellement, vous pouvez administrer et maintenir vos configurations de manière centralisée via [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html). Firewall Manager prend en charge des protections telles que [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) et [Groupes de sécurité Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html). Vous pouvez AWS WAF l'associer à un Application Load Balancer CloudFront, Amazon, API Gateway ou. AWS AppSync Si vous utilisez un VPC sortant et une passerelle de transit, comme décrit dans [Sortie centralisée](centralized-egress.md), chaque VPC en étoile contient des sous-réseaux publics et privés. Cependant, il n'est pas nécessaire de déployer des passerelles NAT, car le trafic passe par le VPC sortant du compte de mise en réseau.
L'image suivante montre un exemple de personne Compte AWS possédant un seul VPC contenant une charge de travail accessible par Internet. Le trafic provenant d'Internet accède au VPC via une passerelle Internet et atteint les services d'équilibrage de charge et de sécurité hébergés dans un sous-réseau public. (Un *sous-réseau public* contient une route par défaut vers une passerelle Internet). Déployez des équilibreurs de charge dans des sous-réseaux publics et associez des listes de contrôle d' AWS WAF accès (ACLs) pour vous protéger contre le trafic malveillant, tel que les scripts intersites. Déployez des charges de travail hébergeant des applications dans des *sous-réseaux privés*, qui n'ont pas d'accès direct à Internet.
![\[Trafic provenant d'Internet accédant à un VPC via une passerelle Internet et des AWS WAFéquilibreurs de charge.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/4_ingress.png)
Si vous en avez beaucoup VPCs dans votre organisation, vous souhaiterez peut-être partager des points communs en Services AWS créant des points de terminaison VPC d'interface ou des zones hébergées privées dans un environnement dédié et partagé. Compte AWS Pour plus d'informations, consultez [Accès et Service AWS utilisation d'un point de terminaison VPC d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) (AWS PrivateLink documentation) et [Utilisation de zones hébergées privées](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (documentation Route 53).
L'image suivante montre un exemple de site hébergeant des ressources pouvant être partagées au sein de l'organisation. Compte AWS Les points de terminaison d'un VPC peuvent être partagés entre plusieurs comptes en les créant dans un VPC dédié. Lorsque vous créez un point de terminaison d'un VPC, vous pouvez éventuellement faire en sorte qu' AWS gère les entrées DNS pour le point de terminaison. Pour partager un point de terminaison, désactivez cette option et créez les entrées DNS dans une zone hébergée privée (PHZ) Route 53 distincte. Vous pouvez ensuite associer le PHZ à tous les éléments de votre organisation pour une résolution DNS centralisée des points de terminaison VPC. VPCs Vous devez également vous assurer que les tables de routage de la passerelle de transit incluent les itinéraires entre le VPC partagé et l'autre. VPCs Pour plus d'informations, consultez la section [Accès centralisé aux points de terminaison VPC de l'interface](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) (AWS livre blanc).
![\[Un compte partagé qui héberge des points de terminaison de service et des ressources à partager avec d'autres comptes membres.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/5_shared.png)
Un espace partagé Compte AWS est également un bon endroit pour héberger AWS Service Catalog des portefeuilles. Un *portefeuille* est un ensemble de services informatiques sur lesquels vous souhaitez mettre à disposition pour un déploiement AWS, et le portefeuille contient des informations de configuration pour ces services. Vous pouvez créer les portefeuilles dans le compte partagé, les partager avec l'organisation, puis chaque compte membre importe le portefeuille dans sa propre instance régionale de Service Catalog. Pour plus d'informations, veuillez consulter [Partage avec AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations) (documentation Service Catalog).
De même, avec Amazon VPC Lattice, vous pouvez utiliser le compte partagé pour gérer de manière centralisée votre environnement et vos modèles de services en tant qu'entités, puis configurer des connexions de compte avec les comptes des membres de l'organisation. Pour plus d'informations, consultez [Partager vos entités VPC Lattice (documentation VPC Lattice)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sharing.html).