Virtual Private Clouds (VPCs) are virtual networks dedicated to your account in a Region, in which you can launch Cloud resources. These resources must be launched in subnets and can either be connected to the Internet or not.

You use route tables to route traffic from each subnet, and security groups to protect your resources. VPCs also enable you to create a peering connection with another VPC, to use multiple network interfaces for your instances, and create DirectLink or VPN connections.

The following topics are discussed: 

VPCs and Subnets

A VPC is a virtual network that you define, isolated in Outscale Cloud and dedicated to your account. You can launch instances and create resources in your VPC. VPCs are created for a whole Region.

When creating a VPC, you specify a range of IP addresses in CIDR notation, that can then be used for your resources launched into this VPC. This CIDR block follows the RFC 1918 limitations. For more information, see RFC 1918 documentation.

  • The first four IP addresses and the last IP address of the CIDR block of a VPC cannot be assigned to resources, as they are dedicated to the network layer.
  • You cannot modify the CIDR block of a VPC once created. If your VPC becomes too small for your resources, you can create a larger one and migrate your instances into it using Outscale machine images. For more information, see Outscale Machine Images (OMIs).

After creating a VPC, you need to create one or more subnets into it, as resources must be launched into subnets. Subnets correspond to sub-networks within your VPC, to which you assign a range of IP addresses in CIDR notation. The CIDR block of each subnet must be part of the VPC CIDR block, and subnets CIDR blocks must not overlap. Subnets are created in an Availability Zone (AZ), and you can create one or more subnets in each AZ of the VPC Region. If you do not specify any AZ, the AZ A is used by default.

VPC and Subnets Architecture

A VPC or a subnet can be in one of the following states:

  • Pending: The creation process is in progress.
  • Available: The VPC or subnet is created and you can launch resources into it.

When using a Virtual Private Cloud (VPC), you can set the tenancy option for the whole VPC when creating it. If you set the VPC tenancy to default, you have to set the tenancy attribute to dedicated for each instance you want to be on a dedicated servers. If you set the VPC tenancy to dedicated, the tenancy attribute of instances launched in the VPC are automatically set to dedicated. You cannot modify the tenancy option of your VPC once created.
For more information about instances tenancy, see About Instances

Subnet Routing and Security

Each subnet must be associated with a route table to specify the allowed routes for outbound traffic leaving the subnet. A route table, called the main route table, is created by default in your VPC, and every subnet is automatically associated with it at creation. The routes contained in the main route table can be modified. You can also create your own route tables and associate them with your subnets, or set one of them as the main one. It is recommended to use one route table per subnet. For more information about route tables and routes, see About Route Tables.

Security groups enable you to control access to your instances in your VPC. Security groups act as a set of firewall rules that, in a VPC, control both inbound and outbound flows. When launching an instance in your VPC, you must associate it with one or more security groups. If you do not specify any security group, the instance is automatically associated with the default security group that is automatically created with your VPC. You can then modify the rules of your custom security group or of the default security group depending on your architecture and the controls you want to configure. For more information about security groups and security group rules, see Security Groups.

In a VPC, you can allow access to and from:

  • Another security group in the VPC or in a peered VPC
  • A CIDR block
  • An Outscale service using a prefix list 

By default, thanks to a network enhancement, instances within a same subnet can communicate with one another without any security group rules required. This enables to reduce overall latency between two instances and avoid issues for specific protocols, like those used by Microsoft Windows. If you want to have further security between two instances (for example, one in a DMZ and one in an internal network), place them in different subnets or disable this feature.

You can disable this feature by adding, before creating subnets, the osc.fcu.enable_lan_security_groups tag key to your VPC using the method described in Tagging Your Resources. The value you specify for this tag is not taken into account. Once this tag is set, you then need to add appropriate rules to the security groups of your instances placed in the same subnet to allow them to communicate with one another.

This behavior cannot be modified by adding or removing this tag once you create one or more subnets in the VPC.

As it is recommended to use a route table per subnet, it is also recommended to use one security group per subnet too. This corresponds to creating a subnet for one application, with its appropriate route table and security group.

You can also use Elastic Identity Management (EIM) to control who can access, create and manage resources in your VPC. For more information, see Elastic Identity Management (EIM).

IP Addressing and Access to the Internet

Every instance launched in a VPC is assigned a primary private IP address, that is not reachable over the internet and that can be used for communication between instances in the VPC. Contrary to the public Cloud, you can specify the private IP address associated with instances launched in a VPC subnet. If you do not specify a private IP address when launching them, this one is automatically chosen within the subnet range.

RunInstances API requests let you choose the private IP addresses of multiple instances you launch at the same time using the PrivateIpAddresses parameter. However, most SDKs do not support this feature. Therefore, if you want to launch several instances and specify their private IP address, you either need to forge an API request or to launch them one by one using a SDK.

By default, instances launched in a VPC are not assigned a public IP address, and can only access one another. To connect instances in a VPC to the Internet, you must use External IP addresses (EIPs), that are static public IP addresses that you can associate to an instance, a network interface or a Network Address Translation (NAT) gateway. For more information, see External IP Addresses (EIPs).

You can connect instances in a VPC to the Internet directly or indirectly:

  • To directly connect instances in a VPC to the Internet, you must associate them with an EIP and use an Internet gateway to forward traffic to and from the Internet. For more information, see Using Internet Gateways for Direct Connections.
  • To indirectly connect instances in a VPC to the Internet, you must use a NAT device that bears the EIP and forwards traffic to and from the Internet on behalf of the instances. For more information, see Using NAT Devices for Indirect Connections.

In either case, you need to route the traffic of the subnet in which the instances are to the Internet gateway or the NAT device. You also need to add appropriate rules to the security groups of your subnets. Allowing indirect access to the Internet enables, for example, instances to search for available updates.

To access NTP servers, instances require an Internet connection. Therefore, to enable your instances in a VPC to access NTP servers, you need to add one of the following routes to the route table associated with their subnet:

  • A route that grants them access to the whole Internet, with as destination and an Internet gateway or a NAT device as target
  • A route that only grants them access to an NTP server, with the IP address of the NTP server as destination and an Internet gateway or a NAT device as target

You can use the IP address of one of Outscale NTP servers.

VPCs and Other Services

VPCs can be connected to other networks using the following Outscale services, which also requires to create a virtual private gateway (VGW) and, for VPN connections, a customer gateway (CGW):

  • Virtual Private Network (VPN): You can create a VPN connection between your network and your VPC to access your resources. For more information, see VPN Connections
  • DirectLink: You can set up a physical connection between your internal network and a DirectLink location where your VPC is to directly access your resources. For more information, see DirectLink.
  • VPC Peering: You can peer two VPCs to allow resources in each one of them to communicate with one another. For more information, see Working with VPC Peering Connections.


Windows® is a registered trademark of Microsoft Corporation in the United States and/or other countries.

AWS™ and Amazon Web Services™ are trademarks of Amazon Technologies, Inc or its affiliates in the United States and/or other countries.

See Legal Mentions.