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.
A VPC is a virtual network that you define, isolated in the 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.
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.
In each subnet of a VPC, 3DS OUTSCALE reserves the first four IP addresses and the last IP address of the CIDR block. You cannot assign these IP address to resources. For example, in a subnet with CIDR 10.0.0.0/24, the following IP addresses are reserved:
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 server. If you set the VPC tenancy to
tenancy attribute of instances launched in the VPC is automatically set to
dedicated. You cannot modify the tenancy option of your VPC once created.
For more information about instances tenancy, see About Instances
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:
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 Adding or Removing Tags. 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).
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 choose 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
You can add additional private IP addresses, called secondary IP addresses, to an instance in a VPC using flexible network interfaces. For more information, see Flexible Network Interfaces (FNIs).
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 gateway that bears the EIP and forwards traffic to and from the Internet on behalf of the instances. For more information, see Using NAT Gateways for Indirect Connections.
In either case, you need to route the 0.0.0.0/0 traffic of the subnet in which the instances are located to the Internet gateway or the NAT gateway. 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.
By default, instances in a VPC use a preconfigured OUTSCALE domain name. If you launched your instances using an official OMI, a default OUTSCALE NTP server is also configured for them within the OMI with no action required on your side. For more information about OUTSCALE NTP servers, see OUTSCALE NTP Servers.
To use another domain name or NTP server for your instances in a VPC, you can create a DHCP options set with the options you need and attach it to the VPC. For more information, see About DHCP Options.
VPCs can be connected to other networks using the following OUTSCALE services, which also require to create a virtual private gateway (VGW) and, for VPN connections, a customer gateway (CGW):
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.