À propos des VPC
Les Virtual Private Clouds (VPC) sont des réseaux virtuels dédiés à votre compte au sein d’une Région, dans lesquels vous pouvez lancer des ressources Cloud. Ces ressources doivent être lancées dans des subnets et peuvent être connectées à internet ou non.
Vous utilisez des route tables pour router le trafic de chaque subnet, et des security groups pour protéger vos ressources. Les VPC vous permettent également de créer une peering connection avec un autre VPC, d’utiliser plusieurs network interfaces pour vos instances et de créer des connexions DirectLink ou VPN.
VPC et subnets
Un VPC est un réseau virtuel que vous définissez, qui est isolé au sein du Cloud OUTSCALE et qui est dédié à votre compte. Vous pouvez lancer des instances et créer des ressources dans votre VPC. Les VPC sont créés pour une Région.
Lorsque vous créez un VPC, vous spécifiez la plage d’IP en notation CIDR, qui peuvent ensuite être utilisées pour vos ressources lancées dans ce VPC. Le bloc CIDR doit être inclus dans les plages RFC 1918, qui sont constituées des trois blocs suivants :
-
10.0.0.0 - 10.255.255.255 (préfixe 10/8)
-
172.16.0.0 - 172.31.255.255 (préfixe 172.16/12)
-
192.168.0.0 - 192.168.255.255 (préfixe 192.168/16)
Pour en savoir plus, voir la documentation RFC 1918.
Vous ne pouvez pas modifier le bloc CIDR d’un VPC une fois celui-ci créé. Si votre VPC devient trop petit pour vos ressources, vous pouvez en créer un plus grand et migrer vos instances dans celui-ci à l’aide d’OUTSCALE machine images. Pour en savoir plus, voir OUTSCALE Machine Images (OMI). |
Après avoir créé un VPC, vous devez créer un ou plusieurs subnets dans celui-ci, les ressources devant être lancées dans des subnets. Les subnets correspondent à des sous-réseaux au sein de votre VPC, auxquels vous attribuez une plage d’IP en notation CIDR. Le bloc CIDR de chaque subnet doit faire partie du bloc CIDR du VPC, et les blocs CIDR des subnets ne doivent pas se chevaucher. Les subnets sont créés dans une Availability Zone (AZ), et vous pouvez créer un ou plusieurs subnets dans chaque AZ de la Région du VPC.
Dans chaque subnet d’un VPC, 3DS OUTSCALE réserve les quatre premières IP ainsi que la dernière du bloc CIDR. Vous ne pouvez pas assigner ces IP à des ressources. Par exemple, dans un subnet avec le bloc CIDR 10.0.0.0/24, les IP suivantes sont réservées :
|
Un VPC ou un subnet peut être dans un des états suivants :
-
pending
: Le processus de création est en cours. -
available
: Le VPC ou le subnet est créé et vous pouvez y lancer des ressources. -
deleted
: Le VPC ou le subnet est supprimé.
Les états |
Lorsque vous utilisez un Virtual Private Cloud (VPC), vous pouvez spécifier l’option d’allocation pour l’ensemble du VPC lors sa création. Si vous paramétrez l’option d’allocation du VPC sur default
, vous devez paramétrer l’attribut tenancy
de chaque instance que vous souhaitez placer sur un serveur dédié sur dedicated
. Si vous paramétrez l’option d’allocation du VPC sur dedicated
, l’attribut tenancy
de toutes les instances lancées dans ce VPC est automatiquement paramétré sur dedicated
. Vous ne pouvez pas modifier l’option d’allocation une fois votre VPC créé.
Pour en savoir plus à propos de l’allocation des instances, voir À propos des instances.
Routage et sécurité d’un subnet
Chaque subnet doit être associé à une route table afin de spécifier les routes autorisées pour le trafic sortant qui quitte le subnet. Une route table, appelée route table principale, est créée par défaut pour votre VPC, et chaque subnet lui est automatiquement associée à sa création. Vous pouvez également créer vos propres route tables et les associer à vos subnets. Les routes contenues dans la route table principale peuvent être modifiées. Vous pouvez également créer vos propres route tables et les associer à vos subnets, ou les spécifier comme la route table principale. Il est recommandé d’utiliser une route table par subnet. Pour en savoir plus à propos des route tables, voir À propos des route tables.
Les security groups vous permettent de contrôler l’accès à vos instances dans votre VPC. Les security groups agissent comme un ensemble de règles de firewall qui, dans un VPC, contrôlent les flux entrants et sortants. Lorsque vous lancez des instances dans un VPC, vous devez les associer à un ou plusieurs security groups. Si vous ne spécifiez aucun security group, l’instance est automatiquement associée avec le security group par défaut qui est créé automatiquement avec votre VPC. Vous pouvez ensuite modifier les règles du security group que vous avez créé ou du security group par défaut selon votre architecture et les contrôles que vous souhaitez configurer. Pour en savoir plus sur les security groups et les règles de security groups, voir Security Groups.
Dans un VPC, vous pouvez autoriser l’accès vers et depuis :
|
Par défaut, grâce à une amelioration du réseau, les instances dans un même subnet peuvent communiquer entre elles sans aucune règle de security group nécessaire. Ceci vous permet de réduire la latence entre deux instances et éviter des conflits avec des protocoles spécifiques, tels que ceux utilisés par Microsoft Windows. Si vous voulez une sécurité accrue entre vos instances, (par exemple, une sur un DLZ et l’autre sur un réseau interne), placez les dans des subnets différents ou désactivez cette fonctionnalité. Vous pouvez désactiver cette fonctionnalité en ajoutant, avant de créer des subnets, le tag osc.fcu.enable_lan_security_groups à votre VPC à l’aide de la méthode Ajouter des tags à vos ressources. La valeur que vous spécifiez pour ce tag n’est pas prise en compte. Une fois ce tag ajouté, vous devez donc ajouter les règles appropriées aux security groups de vos instances placées dans un même subnet pour les autoriser à communiquer les unes avec les autres. Ce comportement ne peut être modifié en ajoutant ou retirant ce tag une fois que des subnets sont créés dans votre VPC. |
De la même manière qu’il est recommandé d’utiliser une route table par subnet, il est également recommandé d’utiliser un security group par subnet. Ceci correspond à créer un subnet pour une application, avec sa route table et son security group appropriés.
Vous pouvez également utiliser Elastic Identity Management (EIM) pour contrôler qui peut accéder, créer et gérer des ressources dans votre VPC. Pour en savoir plus, voir Elastic Identity Management (EIM).
IP et accès à internet
Chaque instance lancée dans un VPC a une IP privée principale attribuée, qui n’est pas accessible depuis internet et qui peut être utilisée pour la communication entre les instances du VPC. Contrairement au Cloud public, vous pouvez choisir l’IP privée associée aux instances lancées dans le subnet d’un VPC. Si vous ne spécifiez aucune IP privée lors du lancement de l’instance, celle-ci est automatiquement choisie dans la plage d’IP du subnet.
Les requêtes API RunInstances vous permettent de choisir les IP privées de plusieurs instances que vous lancez en même temps à l’aide du paramètre |
Vous pouvez ajouter des IP privées additionnelles, appelées IP secondaires, à une instance dans un VPC à l’aide des flexible network interfaces. Pour en savoir plus, voir Flexible network interfaces (FNI).
Par défaut, les instances lancées dans un VPC n’ont pas d’IP publiques attribuées, et peuvent uniquement avoir accès entre elles. Pour connecter des instances dans un VPC à internet, vous devez utiliser des IP externes (EIP), qui sont des IP publiques statiques que vous pouvez associer à une instance, une interface réseau ou une Network Address Translation (NAT) gateway. Pour en savoir plus, voir External IPs (EIP).
Vous pouvez connecter des instances d’un VPC à internet de manière directe ou indirecte :
-
Pour directement connecter des instances d’un VPC à internet, vous devez leur associer une EIP et utiliser une Internet gateway pour envoyer le trafic vers et depuis internet. Pour en savoir plus, voir Utiliser les Internet gateways pour des connexions directes.
-
Pour indirectement connecter des instances d’un VPC à internet, vous devez utiliser une NAT gateway qui porte l’EIP et qui envoie le trafic vers et depuis internet au nom des instances. Pour en savoir plus, voir Utiliser les NAT gateways pour des connexions indirectes.
Dans les deux cas, vous devez router le trafic 0.0.0.0/0 du subnet dans lequel se trouvent les instances vers l’Internet gateway ou la NAT gateway. Vous devez également ajouter les règles appropriées aux security groups de vos subnets. Permettre l’accès indirect à internet permet à vos instances, par exemple, de rechercher les mises à jour disponibles.
Pour accéder à des serveurs NTP, les instances doivent être connectées à internet. Ainsi, pour permettre à vos instances dans un VPC d’accéder à des serveurs NTP, vous devez ajouter une des routes suivantes à la route table associée à leur subnet :
Vous pouvez utiliser l’IP d’un des serveurs NTP OUTSCALE. Pour en savoir plus, voir IP publiques OUTSCALE. |
VPC et les autres services
Les VPC peuvent être connectés à d’autres réseaux à l’aide des services 3DS OUTSCALE suivants, qui requièrent également une virtual private gateway (VGW) et, pour les connexions VPN, une customer gateway (CGW) :
-
DirectLink : Vous pouvez mettre en place une connexion physique entre votre réseau internet et un site DirectLink où se trouve votre VPC pour accéder directement à vos ressources. Pour en savoir plus, voir DirectLink.
-
VPC Peering : Vous pouvez appairer deux VPC pour autoriser les ressources dans chacun d’eux à communiquer entre elles. Pour en savoir plus, voir Travailler avec les VPC peering connections.
Page connexe