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.

Les sujets suivants sont abordés : 


VPC et subnets

Un VPC est un réseau virtuel que vous définissez, qui est isolé au sein du Cloud 3DS 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'adresses IP en notation CIDR, qui peuvent ensuite être utilisées pour vos ressources lancées dans ce VPC. Le bloc CIDR suit les limitations RFC 1918. Pour en savoir plus, voir la documentation RFC 1918.

  • Les quatre premières adresses IP ainsi que la dernière du bloc CIDR d'un VPC ne peuvent pas être attribuées à des ressources, celles-ci étant dédiées à la couche réseau.
  • 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'adresses 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. Si vous ne spécifiez aucune AZ, l'AZ A est utilisée par défaut.

VPC and Subnets Architecture

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.

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 automatique 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 :

  • Un autre security group du VPC ou d'un VPC pair
  • Un bloc CIDR
  • Un service 3DS OUTSCALE à l'aide d'une prefix list

Par défaut, grâce à une amélioration du réseau, les instances au sein d'un même subnet peuvent communiquer entre elles sans règles de security group requises. Ceci permet de réduire la latence entre deux instances et d'éviter des problèmes avec des protocoles spécifiques, comme ceux utilisés par Microsoft Windows. Si vous souhaitez mettre en place un plus grande sécurité entre deux instances (par exemple une en DMZ et une autre dans un réseau interne), placez-les dans des subnets différents ou désactiver 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 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).


Adresses IP et accès à internet

Chaque instance lancée dans un VPC a une adresse 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 spécifier l'adresse IP privée associée aux instances lancées dans le subnet d'un VPC. Si vous ne spécifiez aucune adresse IP privée lors du lancement de l'instance, celle-ci est automatiquement choisie dans la plage d'adresses IP du subnet.

Les requêtes API RunInstances vous permettent de choisir les adresses IP privées de plusieurs instances que vous lancez en même temps à l'aide du paramètre PrivateIpAddresses. Cependant, la plupart des SDK ne supportent pas cette fonctionnalité. Si vous souhaitez lancer plusieurs instances et choisir leur adresse IP privée, vous devez soit forger votre requête API, soit les lancer une par une avec un SDK.

Vous pouvez ajouter des adresses IP privées additionnelles, appelées adresses 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'adresses IP publiques attribuées, et peuvent uniquement avoir accès entre elles. Pour connecter des instances dans un VPC à internet, vous devez utiliser des External IP addresses (EIP), qui sont des adresses IP publiques statiques que vous pouvez associer à une instance, une interface réseau ou un Network Address Translation (NAT) gateway. Pour en savoir plus, voir External IP Addresses (EIP).

Vous pouvez connecter des instances d'un VPC à internet de manière directe ou indirecte :

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 le système de NAT. 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 :

  • Une route qui leur autorise à accéder à l'ensemble d'internet, avec 0.0.0.0/0 pour destination et une Internet gateway ou un système de NAT pour target
  • Une route qui leur autorise à accéder uniquement à un serveur NTP, avec l'adresse IP du serveur NTP pour destination et une Internet gateway ou un système de NAT pour target

Vous pouvez utiliser l'adresse IP d'un des serveurs NTP 3DS OUTSCALE.


VPC et 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) :

  • Virtual Private Network (VPN) : Vous pouvez créer une connexion VPN entre votre réseau et votre VPC pour accéder à vos ressources. Pour en savoir plus, voir Connexions VPN.
  • 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.



Windows® est une marque déposée de Microsoft Corporation aux Etats-Unis et/ou dans les autres pays.

AWS™ et Amazon Web Services™ sont des marques de commerce d'Amazon Technologies, Inc. ou de ses affiliées aux Etats-Unis et/ou dans les autres pays.

Voir Mentions légales.