Pourquoi avons-nous besoin d'un sous-réseau privé dans VPC?
Il existe 4 scénarios dans AWS VPC configure. 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é.
Dans la mesure où toute instance lancée dans un sous-réseau public n'a pas EIP (sauf si elle est assigné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?
Mise à jour: à la fin de décembre 2015, AWS annoncé une nouvelle fonctionnalité, un Géré NAT Gateway for VPC . Ce service facultatif fournit un mécanisme alternatif permettant aux instances de VPC d’un sous-réseau privé d’accéder à Internet, alors que la solution commune était auparavant une instance EC2 sur un sous-réseau public du VPC. en tant qu '"instance NAT", fournissant une traduction d'adresse réseau (techniquement, port traduction d'adresse) pour des instances dans d'autres sous-réseaux privés, permettant à ces machines d'utiliser le NAT = adresse IP publique de l'instance pour son accès Internet sortant.
Le nouveau service géré NAT ne modifie pas fondamentalement l'applicabilité des informations suivantes, mais cette option n'est pas traitée dans le contenu qui suit. Une instance NAT peut toujours utilisé comme décrit, ou le service de passerelle géré NAT peut être provisionné à la place. Une version développée de cette réponse intégrant plus d'informations sur NAT et comment elle se compare à une instance NAT), ces deux éléments étant pertinents pour le paradigme de sous-réseau privé/public dans le VPC.
Notez que Internet Gateway et NAT Gateway sont deux caractéristiques différentes. Toutes les configurations de VPC avec un accès Internet auront un objet virtuel Internet Gateway.
Pour comprendre la distinction entre les sous-réseaux "privés" et "publics" dans Amazon VPC, vous devez comprendre le fonctionnement du routage IP et de la traduction d'adresses réseau (NAT) en général et leur implémentation spécifique dans VPC.
La différenciation essentielle 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 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, ce qui ne peut être qu'une des deux choses suivantes:
- l'objet "Internet Gateway" du VPC, dans le cas d'un sous-réseau "public", ou
- un NAT périphérique), c’est-à-dire une passerelle NAT ou une instance EC2, exécutant le rôle "instance NAT", dans le cas d’une "instance privée"). "sous-réseau.
La passerelle Internet ne fait aucune traduction d'adresse réseau pour les instances sans adresse IP publique; par conséquent, une instance sans adresse IP publique ne peut pas se connecter vers l'extérieur à Internet - pour télécharger des mises à jour logicielles, ou accéder à d'autres ressources AWS telles que S31 et SQS - si la route par défaut sur son sous-réseau VPC est l'objet Internet Gateway. Donc, si vous êtes une instance sur un sous-réseau "public", alors vous besoin une adresse IP publique afin de faire un grand nombre de choses que les serveurs doivent faire habituellement.
Pour les instances avec uniquement une adresse IP privée, il existe un autre moyen d'accès sortant à Internet. C’est là que la traduction d’adresses réseau² et une instance NAT entrent en jeu).
Les machines d’un sous-réseau privé peuvent accéder à Internet car la route par défaut d’un sous-réseau privé est pas l’objet "Internet Gateway" de VPC - c’est une instance EC2 configurée en tant que NAT instance.
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é-construites 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 retransmet à l'adresse privée de la machine d'origine (il peut également réécrire le port source et, dans tous les cas, mémoriser les mappages. afin de savoir quelle machine interne doit recevoir les paquets de réponse) Une instance NAT) ne permet à aucun trafic entrant "inattendu" d'atteindre les instances privées, à moins d'être 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 la destination semble provenir de l'adresse IP publique de la NAT instance ... le trafic de réponse revient donc à l'instance NAT. Ni le groupe de sécurité attribué à l'instance NAT ni le groupe de sécurité attribué l’instance privée doivent être configurés pour "autoriser" ce trafic de réponse, car les groupes de sécurité sont à état dynamique. Ils réalisent que le trafic de réponse est corrélé aux sessions créées en interne, de sorte qu’il est automatiquement autorisé. Le groupe de sécurité est configuré pour le permettre.
Contrairement au routage IP classique, où votre passerelle par défaut se trouve sur votre même sous-réseau, son fonctionnement dans VPC est différent: l’instance NAT pour un sous-réseau privé donné est toujours située sur un sous-réseau différent et L’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 exécute NAT sur le trafic)), et Le trafic entrant en provenance d’Internet atteindrait l’adresse IP publique de l’instance, mais les réponses essaieraient d’acheminer vers l’extérieur par l’instance NAT, qui soit abandonner le trafic (puisqu'il serait composé de réponses à des connexions dont il n'a pas connaissance, afin qu'elles soient considérées comme non valides) ou réécrire le trafic de réponse pour qu'il utilise sa propre adresse IP publique, ce qui ne fonctionnerait pas car l'origine externe n'accepterait pas les réponses provenant d'une adresse IP autre que celle avec laquelle ils essayaient d'établir des communications.
En résumé, les désignations "privée" et "publique" ne concernent 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.
Comme VPC dispose d'itinéraires implicites de tous les sous-réseaux VPC vers tous les autres sous-réseaux VPC, l'itinéraire 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 "à partir" de leur adresse IP privée, et non "de" 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 alors être techniquement déployées sur un sous-réseau "public" et seraient toujours inaccessibles depuis Internet ... mais sous une telle configuration, il leur est impossible de générer du trafic sortant vers Internet, ce qui inclut des connexions avec d'autres services d'infrastructure AWS, comme S3.1 ou SQS.
1. En ce qui concerne S3, indiquer spécifiquement que l'accès Internet est toujours est une simplification excessive qui prendra probablement de l'ampleur au fil du temps et s'étendra à d'autres services AWS, à mesure que les capacités de VPC continueront de croître. et évoluer. Il existe un concept relativement nouveau appelé VPC Endpoint , qui permet à vos instances, y compris celles qui ne possèdent que des adresses IP privées, d’accéder directement à S3 à partir de sous-réseaux sélectionnés au sein du VPC, sans toucher à "Internet". en utilisant une passerelle NAT ou ou NAT, mais cette opération nécessite une configuration supplémentaire et n'est utilisable que pour accéder aux compartiments situés dans la même région AWS que votre VPC.) Par défaut, S3 - qui est, à l’heure de cette écriture, le seul service à avoir exposé la possibilité de créer des points de terminaison VPC - n’est accessible que depuis VPC via Internet. Lorsque vous créez un point de terminaison VPC, une liste de préfixes est créée ( 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 le problème de la limitation 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 ou d'un bloc de destination - et un point de terminaison V3 VPC peut être soumis à des déclarations de stratégie supplémentaires. , en limitant l’accès au seau de l’intérieur, selon les besoins.
2. Comme indiqué dans la documentation, ce qui est réellement discuté ici concerne la traduction des ports ainsi que celle des adresses réseau. Il est courant, bien que techniquement un peu imprécis, de qualifier l'opération combinée de "NAT". Cela ressemble un peu à la façon dont beaucoup d’entre nous ont tendance à dire "SSL" alors que nous voulons dire réellement "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 est à la fois la traduction d'adresse et la traduction d'adresse de port (PAT). "
Je suggérerais une solution différente - des sous-réseaux "privés" et des NAT instances/passerelles. Ils ne sont pas nécessaires. Si vous ne voulez pas que la machine soit accessible depuis Internet, ne la placez pas dans un groupe de sécurité autorisant un tel accès.
En abandonnant l'instance/passerelle NAT, vous éliminez le coût de fonctionnement de l'instance/passerelle et la limite de vitesse (que ce soit 250 Mbits ou 10 Gbits).
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 certainement pas d'adresse IP publique.
* Si la réponse est une sorte de procuration, eh bien, vous encourez des frais généraux, mais chacun envers les siens.
Je n'ai pas la réputation d'ajouter un commentaire à la réponse de Michael ci-dessus, d'où l'ajout de mon commentaire comme réponse.
Il est à noter que la passerelle gérée AWS est environ 3 fois plus chère que la date à laquelle vous exécutez votre propre instance. Cela 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 petites à moyennes entreprises. scénarios de cas d'utilisation. En supposant un transfert de données mensuel de 100 Go via la passerelle NAT,
Coût mensuel géré par NAT instance = 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 par Go) pour toutes les données transférées via la 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 (0,10 USD/Go standard de frais de transfert de données AWS pour toutes les données transférées via le NAT instance) = 14,84 $
Bien entendu, cela change lorsque vous choisissez des instances NAT redondantes, car la passerelle gérée par AWS NAT dispose d'une redondance intégrée pour la haute disponibilité. Si vous ne vous souciez pas des 33 € de plus par mois, l'instance gérée NAT vaut certainement la peine que vous avez de la peine de gérer 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 en tant que passerelle NAT. instance supplémentaire juste pour NAT (bien que certaines personnes puissent s’opposer à l’idée de combiner VPN et NAT).
La réponse par Michael - sqlbot suppose implicitement que des adresses IP privées sont requises. Je pense que cela vaut la peine de remettre en question cette hypothèse: devons-nous même d'abord utiliser des adresses IP privées? 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) [contre] un serveur [dans un] sous-réseau public avec une politique de sécurité stricte? - abhillman 24 juin '14 à 23h45
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 pour autant qu'ils sont nécessairement accessibles via Internet, car vous utilisez des groupes de sécurité pour restreindre l'accès de la même manière que les choses fonctionnaient avec EC2 classic. En utilisant des adresses IP publiques, vous avez la possibilité d'exposer facilement certains services à un public limité sans avoir à utiliser quelque chose comme un ELB. Cela vous évite d'avoir à configurer une passerelle NAT ou NAT. Et vous avez besoin de deux fois moins de sous-réseaux, vous pouvez choisir d'utiliser un plus petit L'allocation CIDR pour votre VPC ou vous pouvez créer des sous-réseaux plus grands avec le même VPC de taille identique, ce qui signifie que vous payerez également moins pour le trafic inter-AZ.
Alors, pourquoi ne faisons-nous pas cela? Pourquoi AWS indique-t-il que la meilleure pratique consiste à utiliser des adresses IP privées?
Amazon Web Services dispose d'un nombre limité d'adresses IPv4 publiques, car Internet dans son ensemble dispose d'un nombre limité d'adresses IPv4 publiques. Il est dans leur intérêt d’utiliser des adresses IP privées qui sont effectivement illimitées, plutôt que de consommer excessivement d’adresses IPv4 publiques rares. Vous pouvez en voir quelques preuves dans la manière dont AWS tarifie les IP élastiques; un EIP attaché à une instance est gratuit, mais un EIP non utilisé 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, mon application est spéciale. Qu'est-ce qui se passe ensuite?
Il n'y a que deux façons d'attacher une adresse IP publique à une instance EC2 dans un VPC.
1. Associer l'adresse IP publique
Vous pouvez demander une adresse IP publique lors du lancement d'une nouvelle instance EC2. Cette option apparaît sous forme de case à cocher dans la console, sous la forme de l’indicateur - associate-public-ip-address lors de l’utilisation de aws-cli, et en tant que l’option AssociatePublicIpAddress sur une objet d'interface réseau 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 des inconvénients.
Un inconvénient est que la modification du groupe de sécurité d'une instance utilisant un objet d'interface réseau intégré entraîne 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 lorsque l'instance est arrêtée.
2. IP élastique
En général, les IP élastiques sont l’approche privilégiée car elles sont plus sûres. Vous avez la garantie 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 êtes libre de modifier les groupes de sécurité appliqués à vos instances EC2.
... Mais AWS vous limite à 5 EIP par région. Vous pouvez demander plus, et votre demande peut-être être accordée. Mais AWS pourrait tout aussi bien refuser cette demande sur la base du raisonnement que j'ai mentionné ci-dessus. Par conséquent, vous ne voudrez probablement pas vous fier aux EIP si vous envisagez de faire évoluer votre infrastructure au-delà de 5 instances EC2 par région.
En conclusion, l’utilisation d’adresses IP publiques présente certains avantages Nice, 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 ce qu'elles sont.