Mise à jour: fin décembre 2015, AWS a annoncé une nouvelle fonctionnalité, une passerelle NAT gérée pour VPC . Ce service facultatif fournit un mécanisme alternatif permettant aux instances VPC dans un sous-réseau privé d'accéder à Internet, alors qu'auparavant, la solution commune était une instance EC2 sur un sous-réseau public au sein du VPC, fonctionnant comme une "instance NAT", fournissant une traduction d'adresses réseau ( techniquement, traduction d'adresse de port ) pour les instances d'autres sous-réseaux privés, permettant à ces machines d'utiliser l'adresse IP publique de l'instance NAT pour leur accès Internet sortant.
Le nouveau service NAT géré ne change pas fondamentalement l'applicabilité des informations suivantes, mais cette option n'est pas abordée dans le contenu qui suit. Une instance NAT peut toujours être utilisée comme décrit, ou le service Managed NAT Gateway peut être provisionné à la place. Une version étendue de cette réponse intégrant plus d'informations sur la passerelle NAT et la façon dont elle se compare à une instance NAT sera à venir, car elles sont toutes deux pertinentes pour le paradigme de sous-réseau privé / public dans VPC.
Notez que la passerelle Internet et la passerelle NAT sont deux fonctionnalités différentes. Toutes les configurations VPC avec accès Internet auront un objet virtuel Passerelle Internet.
Pour comprendre la distinction entre les sous-réseaux «privés» et «publics» dans Amazon VPC, il faut comprendre comment le routage IP et la traduction d'adresses réseau (NAT) fonctionnent en général, et comment ils sont spécifiquement mis en œuvre dans VPC.
La différenciation fondamentale entre un sous-réseau public et privé dans VPC est définie par la route par défaut de ce sous-réseau, dans les tables de routage du VPC.
Cette configuration, à son tour, dicte la validité de l'utilisation ou non des adresses IP publiques sur les instances de ce sous-réseau particulier.
Chaque sous-réseau a exactement une route par défaut, qui ne peut être que l'une des deux choses suivantes:
- l'objet "Passerelle Internet" du VPC, dans le cas d'un sous-réseau "public", ou
- un périphérique NAT - c'est-à-dire une passerelle NAT ou une instance EC2, remplissant le rôle "instance NAT", dans le cas d'un sous-réseau "privé".
La passerelle Internet n'effectue aucune traduction d'adresse réseau pour les instances sans adresse IP publique, de sorte qu'une instance sans adresse IP publique ne peut pas se connecter vers l'extérieur à Internet - pour effectuer des tâches telles que le téléchargement de mises à jour logicielles ou l'accès à d'autres ressources AWS telles que S3 1 et SQS - si la route par défaut sur son sous-réseau VPC est l'objet Passerelle Internet. Ainsi, si vous êtes une instance sur un sous-réseau "public", vous avez besoin d' une adresse IP publique pour effectuer un nombre significatif de choses que les serveurs doivent généralement faire.
Pour les instances avec uniquement une adresse IP privée, il existe un autre moyen d'accès sortant à Internet. C'est là qu'interviennent la traduction d'adresse réseau² et une instance NAT.
Les machines d'un sous-réseau privé peuvent accéder à Internet car la route par défaut sur un sous-réseau privé n'est pas l'objet VPC «Internet Gateway» - il s'agit d'une instance EC2 configurée en tant qu'instance NAT.
Une instance NAT est une instance sur un sous-réseau public avec une adresse IP publique et une configuration spécifique. Il existe des AMI prédéfinies pour cela, ou vous pouvez créer la vôtre.
Lorsque les machines à adresse privée envoient du trafic vers l'extérieur, le trafic est envoyé, par VPC, à l'instance NAT, qui remplace l'adresse IP source sur le paquet (l'adresse IP privée de la machine privée) par sa propre adresse IP publique, envoie le trafic sur Internet, accepte les paquets de réponse et les renvoie à l'adresse privée de la machine d'origine. (Il peut également réécrire le port source, et dans tous les cas, il se souvient des mappages afin de savoir quelle machine interne doit recevoir les paquets de réponse). Une instance NAT n'autorise aucun trafic entrant "inattendu" à atteindre les instances privées, à moins qu'il n'ait été spécifiquement configuré pour le faire.
Ainsi, lors de l'accès à une ressource Internet externe à partir d'un sous-réseau privé, le trafic traverse l'instance NAT et semble à la destination provenir de l'adresse IP publique de l'instance NAT ... de sorte que le trafic de réponse revient à l'instance NAT. Ni le groupe de sécurité affecté à l'instance NAT ni le groupe de sécurité affecté à l'instance privée ne doivent être configurés pour «autoriser» ce trafic de réponse, car les groupes de sécurité sont avec état. Ils se rendent compte que le trafic de réponse est corrélé aux sessions créées en interne, il est donc automatiquement autorisé. Le trafic inattendu est bien entendu refusé à moins que le groupe de sécurité ne soit configuré pour l'autoriser.
Contrairement au routage IP conventionnel, où votre passerelle par défaut se trouve sur votre même sous-réseau, la façon dont elle fonctionne dans VPC est différente: l'instance NAT pour un sous-réseau privé donné est toujours sur un sous-réseau différent, et cet autre sous-réseau est toujours un sous-réseau public, car l'instance NAT doit avoir une adresse IP externe publique et sa passerelle par défaut doit être l'objet VPC "Internet Gateway".
De même ... vous ne pouvez pas déployer une instance avec une adresse IP publique sur un sous-réseau privé. Cela ne fonctionne pas, car la route par défaut sur un sous-réseau privé est (par définition) une instance NAT (qui effectue un NAT sur le trafic), et non l'objet de passerelle Internet (qui ne le fait pas). Le trafic entrant d'Internet atteindrait l'adresse IP publique de l'instance, mais les réponses essaieraient d'acheminer vers l'extérieur via l'instance NAT, ce qui abandonnerait le trafic (car il serait composé de réponses à des connexions dont il n'a pas connaissance, donc elles serait considéré comme invalide) ou réécrirait le trafic de réponse pour utiliser sa propre adresse IP publique, ce qui ne fonctionnerait pas puisque l'origine externe n'accepterait pas les réponses provenant d'une adresse IP autre que celle avec laquelle ils essayaient d'initier des communications .
En substance, les désignations «privé» et «public» ne concernent donc pas vraiment l'accessibilité ou l'inaccessibilité à partir d'Internet. Ils concernent les types d'adresses qui seront attribuées aux instances de ce sous-réseau, ce qui est pertinent en raison de la nécessité de traduire - ou d'éviter de traduire - ces adresses IP pour les interactions Internet.
Étant donné que VPC a des routes implicites de tous les sous-réseaux VPC vers tous les autres sous-réseaux VPC, la route par défaut ne joue aucun rôle dans le trafic VPC interne. Les instances avec des adresses IP privées se connecteront à d'autres adresses IP privées dans le VPC "depuis" leur adresse IP privée, et non "depuis" leur adresse IP publique (si elles en ont une) ... tant que l'adresse de destination est une autre adresse privée au sein du VPC.
Si vos instances avec des adresses IP privées n'ont jamais, en aucune circonstance, besoin de générer du trafic Internet sortant, elles pourraient techniquement être déployées sur un sous-réseau «public» et seraient toujours inaccessibles depuis Internet ... mais dans une telle configuration, il leur est impossible de générer du trafic sortant vers Internet, qui comprend des connexions avec d'autres services d'infrastructure AWS, encore une fois, comme S3 1 ou SQS.
1. En ce qui concerne S3, en particulier, pour dire que l'accès à Internet est toujours nécessaire est une simplification excessive qui augmentera probablement de portée au fil du temps et se propagera à d'autres services AWS, à mesure que les capacités de VPC continueront de croître et d'évoluer. Il existe un concept relativement nouveau appelé point de terminaison VPCqui permet à vos instances, y compris celles qui n'ont que des adresses IP privées, d'accéder directement à S3 à partir de sous-réseaux sélectionnés dans le VPC, sans toucher à «Internet» et sans utiliser d'instance NAT ou de passerelle NAT, mais cela nécessite une configuration supplémentaire, et est utilisable uniquement pour accéder aux buckets dans la même région AWS que votre VPC. Par défaut, S3 - qui est, au moment de la rédaction de cet article, le seul service qui a exposé la capacité de créer des points de terminaison VPC - n'est accessible que depuis l'intérieur du VPC via Internet. Lorsque vous créez un point de terminaison VPC, cela crée une liste de préfixes (pl-xxxxxxxx) que vous pouvez utiliser dans vos tables de routage VPC pour envoyer le trafic lié à ce service AWS particulier directement au service via l'objet virtuel "VPC Endpoint". Cela résout également un problème de restriction de l'accès sortant à S3 pour une instance particulière, car la liste de préfixes peut être utilisée dans des groupes de sécurité sortants, à la place d'une adresse IP de destination ou d'un bloc - et un point de terminaison de VPC S3 peut être soumis à des déclarations de politique supplémentaires. , restreignant l'accès au godet de l'intérieur, comme souhaité.
2. Comme indiqué dans la documentation, ce qui est en fait discuté ici est la traduction des ports et des adresses réseau. Il est courant, bien que techniquement un peu imprécis, de se référer à l'opération combinée comme "NAT". Cela ressemble quelque peu à la façon dont beaucoup d'entre nous ont tendance à dire «SSL» alors que nous entendons en fait «TLS». Nous savons de quoi nous parlons, mais nous n'utilisons pas le mot le plus correct pour le décrire. "Remarque Nous utilisons le terme NAT dans cette documentation pour suivre les pratiques informatiques courantes, bien que le rôle réel d'un périphérique NAT soit à la fois la traduction d'adresse et la traduction d'adresse de port (PAT)."