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?
Réponses:
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:
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)."
la source
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.
la source
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).
la source
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.
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.
la source