Pourquoi avons-nous besoin d'un sous-réseau privé dans VPC?

127

Il existe 4 scénarios dans la configuration d'AWS VPC. Mais regardons ces deux:

  • Scénario 1: 1 sous-réseau public.
  • Scénario 2: 1 sous-réseau public et 1 sous-réseau privé.

Étant donné que toute instance lancée dans un sous-réseau public n'a pas d'EIP (à moins qu'elle ne soit attribuée), elle n'est déjà pas adressable depuis Internet. Ensuite:

  • Pourquoi un sous-réseau privé est-il nécessaire?
  • Quelles sont exactement les différences entre les sous-réseaux privés et publics?
Tommy
la source
4
Le sous-réseau privé, même après avoir attribué une adresse IP publique aux machines à l'intérieur, est toujours inaccessible à partir de l'Internet public. Je crée des configurations VPC, par exemple avec un serveur Web dans un sous-réseau public et mon backend de base de données dans le sous-réseau privé. Je peux me connecter avec la passerelle client pour accéder aux machines sur un sous-réseau privé et public.
user602525

Réponses:

239

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)."

Michael - sqlbot
la source
16
Réponse détaillée, mais je me demande toujours. Quel est l'avantage d'un serveur sur un sous-réseau privé avec une instance NAT et un sous-réseau public de serveur avec une politique de sécurité stricte?
abhillman
13
@abhillman ce n'est pas vraiment un avantage. Il s'agit de la façon dont le réseau fonctionne, dans VPC. Toutes les instances d'un sous - réseau donné doivent utiliser la même passerelle par défaut, qui sera soit l'objet virtuel "Internet gateway", qui ne fera pas de NAT, soit une instance NAT, qui ne «fera pas» NAT . À moins que toutes vos machines n'aient des adresses IP publiques, ou qu'aucune d'entre elles n'en ait, vous souhaiterez les deux types de sous-réseaux. Si tout est un serveur Web connecté à Internet, bien sûr, vous n'aurez peut-être besoin que d'un sous-réseau public, et avec une configuration de sécurité correcte, il n'y a aucun inconvénient.
Michael - sqlbot
1
En fait, il est désormais possible d'accéder à certaines ressources AWS, telles que S3, à partir de VPC aws.amazon.com/blogs/aws/new-vpc-endpoint-for-amazon-s3 .
avloss
2
@avloss merci d'avoir attiré mon attention sur ce point et sa pertinence par rapport à cette réponse. Cela fait presque deux ans sans beaucoup de montage et vous avez raison - les choses continuent d'évoluer. Je mettrai à jour ceci pour mentionner les points de terminaison VPC.
Michael - sqlbot
4
@VirtualJasper vous ne devriez pas vouloir utiliser d'adresses entièrement publiques. L'utilisation d'adresses IPv4 privées lorsque cela est possible est une bonne pratique. Cela réduit votre surface d'attaque. Cela donne un meilleur contrôle des sorties. L'espace d'adressage IPv4 est rare et le devient de plus en plus, il y a un aspect éthique à consommer plus de cette ressource que ce dont vous avez besoin. Il semble en outre logique que si vous continuez à demander au support AWS d'augmenter le nombre d'adresses autorisé, il commencera à un moment donné à poser des questions. VPC a été conçu pour fonctionner de cette façon. Pouvez-vous inverser le système et utiliser toutes les adresses IP publiques? Oui. Est-ce que c'est une bonne idée? No.
Michael - sqlbot
27

Je suggérerais une approche différente - abandonnez les sous-réseaux "privés" et les instances / passerelles NAT. Ils ne sont pas nécessaires. Si vous ne souhaitez pas que la machine soit accessible depuis Internet, ne la placez pas dans un groupe de sécurité qui autorise un tel accès.

En abandonnant l'instance / la passerelle NAT, vous éliminez le coût de fonctionnement de l'instance / de la passerelle et vous éliminez la limite de vitesse (que ce soit 250 Mbits ou 10 Go).

Si vous avez une machine qui n'a pas non plus besoin d'accéder directement à Internet (et je vous demanderais comment vous la corrigez *), alors n'attribuez pas d'adresse IP publique.

* Si la réponse ici est une sorte de proxy, eh bien, vous encourez des frais généraux, mais chacun est le sien.

Phil
la source
5
Je ne pourrais pas être plus d'accord. Plus je travaille avec les questions, moins je vois l'utilisation des sous-réseaux privés. Cela ressemble plus à une relique de l'apparence des réseaux sur site et du fait que leur existence réside principalement dans la familiarité. Je suis sûr qu'il y a des cas extrêmes où ils peuvent encore être valides, mais en termes généraux, je dis de ne pas les utiliser. Le fait que la première (et très longue réponse) à cette question n'aborde pas la question réelle est une indication de leur redondance.
Carl
1
Je suis entièrement d'accord avec la théorie ici, mais dans la pratique, j'ai constaté qu'AWS vous limite à 20 EIP par région par défaut, et je suis sceptique sur le fait qu'ils seraient prêts à augmenter cette limite pour autoriser des centaines d'adresses IPv4 publiques. Ce sont des ressources rares sur Internet.
Nic
1
@Nic Vous n'avez pas besoin d'EIP, rappelez-vous, il s'agit d'abandonner le NAT - nous ne nous soucions pas de l'IP publique d'une machine sans visage, et nous ne nous soucions pas si elle change.
Phil
1
Aujourd'hui, AWS a publié IPv6 dans le monde entier. Laissez mourir IPv4. :-)
Phil
3
Abandonner les sous-réseaux privés suppose intrinsèquement que les erreurs ne se produisent jamais. Avec des dizaines d'instances et des centaines de règles de sécurité qui s'entrecroisent entre elles, et un personnel multiple impliqué dans la maintenance, la possibilité que quelqu'un ouvre accidentellement un port sur le monde ne peut être négligée. Une posture défensive limitant l'accès public par conception aux quelques instances qui en ont besoin est une meilleure approche de la sécurité. Pour ceux d'entre vous qui sont infaillibles, allez-y. Pour le reste d'entre nous, simples mortels, faire preuve de prudence n'est pas une si mauvaise idée.
Jim Walker
23

Je n'ai pas la réputation d'ajouter un commentaire à la réponse de Michael ci-dessus, ajoutant donc mon commentaire en tant que réponse.

Il est à noter que la passerelle gérée par AWS est ~ 3 fois plus chère qu'à la date par rapport à l'exécution de votre propre instance. Ceci suppose bien sûr que vous n'avez besoin que d'une seule instance NAT (c'est-à-dire que vous n'avez pas plusieurs instances NAT configurées pour le basculement, etc.), ce qui est généralement vrai pour la plupart des scénarios d'utilisation petits à moyens. En supposant un transfert de données mensuel de 100 Go via la passerelle NAT,

Coût mensuel de l'instance NAT gérée = 33,48 USD / mois (0,045 USD / heure * 744 heures par mois) + 4,50 USD (0,045 USD par Go de données traitées * 100 Go) + 10 USD (frais de transfert de données AWS standard de 0,10 USD / Go pour toutes les données transférées via le Passerelle NAT) = 47,98 $

Instance t2.nano configurée en tant qu'instance NAT = 4,84 USD / mois (0,0065 USD * 744 heures par mois) + 10 USD (frais de transfert de données AWS standard de 0,10 USD / Go pour toutes les données transférées via l'instance NAT) = 14,84 USD

Cela change bien sûr lorsque vous optez pour des instances NAT redondantes, car la passerelle NAT gérée par AWS dispose d'une redondance intégrée pour la haute disponibilité. Si vous ne vous souciez pas des 33 $ supplémentaires / mois, alors l'instance NAT gérée vaut certainement le mal de tête réduit de ne pas avoir à maintenir une autre instance. Si vous exécutez une instance VPN (par exemple OpenVPN) pour accéder à vos instances dans le VPC, vous pouvez simplement configurer cette instance pour qu'elle agisse également comme votre passerelle NAT, et vous n'avez pas à maintenir une instance supplémentaire uniquement pour NAT ( bien que certaines personnes puissent désapprouver l'idée de combiner VPN et NAT).

Jim Walker
la source
4
D'accord - cependant, avec l'instance t2.nano, vous allez voir un débit maximal de peut-être 250 Mbit / s, par rapport au pic criard de 10 Gbit / s de la passerelle NAT. Ne vous méprenez pas, je trouve le prix un peu élevé aussi, et il y a d'autres limitations - j'utilise toujours des instances NAT pratiquement partout ... mais, en toute honnêteté, vous payez, en partie, pour une certaine puissance de commutation de paquet brut assez sérieuse et une connectivité réseau avec la passerelle.
Michael - sqlbot
1
Mais pourquoi NAT Gateway si cher? La traduction des adresses nécessite-t-elle beaucoup de ressources informatiques? Je peux comprendre que pour une application vraiment énorme, le NAT peut proxy un grand nombre de demandes hors de VPC, mais si nous parlons de moyennes entreprises et de petits projets habituels, 0,045 $ l'heure et chaque Go est assez surestimé.
Sergey Cherepanov
15

La réponse de Michael - sqlbot fait l'hypothèse implicite que des adresses IP privées sont nécessaires. Je pense qu'il vaut la peine de remettre en question cette hypothèse - devons-nous même utiliser des adresses IP privées en premier lieu? Au moins un intervenant a posé la même question.

Quel est l'avantage d'un serveur sur un sous-réseau privé avec une instance NAT [par rapport] à un serveur [dans un] sous-réseau public avec une politique de sécurité stricte? - abhillman 24 juin 14 à 23:45

Imaginez un scénario dans lequel vous utilisez un VPC et attribuez des adresses IP publiques à toutes vos instances EC2. Ne vous inquiétez pas, cela ne signifie pas qu'ils sont nécessairement joignables sur Internet, car vous utilisez des groupes de sécurité pour restreindre l'accès exactement de la même manière que les choses fonctionnaient avec EC2 classic. En utilisant des adresses IP publiques, vous avez l'avantage de pouvoir facilement exposer certains services à un public limité sans avoir besoin d'utiliser quelque chose comme un ELB. Cela vous évite d'avoir à configurer une instance NAT ou une passerelle NAT. Et comme vous avez besoin de moitié moins de sous-réseaux, vous pouvez choisir d'utiliser une allocation CIDR plus petite pour votre VPC ou vous pouvez créer des sous-réseaux plus grands avec la même taille de VPC. Et moins de sous-réseaux signifie que vous paierez également moins pour le trafic inter-AZ.

Alors, pourquoi ne pas faire ça? Pourquoi AWS dit-il que la meilleure pratique consiste à utiliser des adresses IP privées?

Amazon Web Services dispose d'une offre limitée d'adresses IPv4 publiques, car Internet dans son ensemble a une offre limitée d'adresses IPv4 publiques. Il est dans leur meilleur intérêt pour vous d'utiliser des adresses IP privées qui sont effectivement illimitées, plutôt que de consommer excessivement des adresses IPv4 publiques rares. Vous pouvez voir des preuves de cela dans la façon dont AWS prix les adresses IP Elastic; un EIP attaché à une instance est gratuit, mais un EIP inutilisé coûte de l'argent.

Mais pour les besoins de l'argumentation, supposons que nous ne nous soucions pas de la pénurie d'adresses IPv4 publiques sur Internet. Après tout, ma candidature est spéciale. Que se passe-t-il ensuite?

Il n'y a que deux façons d'attacher une adresse IP publique à une instance EC2 dans un VPC.

1. Adresse IP publique associée

Vous pouvez demander une adresse IP publique lors du lancement d'une nouvelle instance EC2. Cette option apparaît comme une case à cocher dans la console, comme l' indicateur --associate-public-ip-address lors de l'utilisation de aws-cli et comme l' indicateur AssociatePublicIpAddress sur un objet d'interface réseau intégré lors de l'utilisation de CloudFormation. Dans tous les cas, l'adresse IP publique est attribuée à eth0(DeviceIndex = 0). Vous ne pouvez utiliser cette approche que lors du lancement d'une nouvelle instance. Cependant, cela présente certains inconvénients.

Un inconvénient est que la modification du groupe de sécurité d'une instance qui utilise un objet d'interface réseau intégré forcera le remplacement immédiat de l'instance, du moins si vous utilisez CloudFormation.

Un autre inconvénient est qu'une adresse IP publique attribuée de cette manière sera perdue lors de l'arrêt de l'instance.

2. IP élastique

En général, les IP Elastic sont l'approche préférée car ils sont plus sûrs. Vous êtes assuré de continuer à utiliser la même adresse IP, vous ne risquez pas de supprimer accidentellement des instances EC2, vous pouvez librement attacher / détacher une adresse IP Elastic à tout moment et vous avez la liberté de modifier les groupes de sécurité appliqués à vos instances EC2.

... Mais AWS vous limite à 5 EIP par région. Vous pouvez en demander plus et votre demande pourrait être acceptée. Mais AWS pourrait tout aussi probablement refuser cette demande sur la base du raisonnement que j'ai mentionné ci-dessus. Vous ne voudrez donc probablement pas vous fier aux EIP si vous prévoyez de faire évoluer votre infrastructure au-delà de 5 instances EC2 par région.

En conclusion, l'utilisation d'adresses IP publiques présente de nombreux avantages, mais vous rencontrerez des problèmes d'administration ou de mise à l'échelle si vous essayez d'utiliser exclusivement des adresses IP publiques. J'espère que cela aidera à illustrer et à expliquer pourquoi les meilleures pratiques sont telles qu'elles sont.

Nic
la source
4
La limite par défaut pour les EIP est en fait de 5 par région et non de 20. "Après tout, ma candidature est spéciale." Cette phrase mérite son propre vote.
Michael - sqlbot
4
D'où vient l'idée que vous ne pouvez pas changer les groupes de sécurité à la volée pour une machine avec une IP publique qui n'est pas un EIP? Ce n'est tout simplement pas vrai!
Phil
1
@Phil Correct. Cette affirmation est fausse. Dire que vous ne pouvez pas modifier le groupe de sécurité d'une instance à laquelle une adresse IP publique est attachée annule en quelque sorte toute sa réponse. Je sais que cela peut être un peu dur, mais comment pouvez-vous induire les lecteurs en erreur avec de fausses déclarations qui sont au cœur de votre message. Quoi qu'il en soit, je suis d'accord avec Nic sur le fait que vous pouvez abandonner les sous-réseaux privés et simplement utiliser des sous-réseaux publics avec une configuration de pare-feu appropriée en place,
Geo C.
1
J'ai maintenant supprimé les fausses déclarations concernant l'impossibilité de changer de groupe de sécurité.
JP
Certaines de ces déclarations sont toujours là;)
Tim Malone